Remote Icinga instance 'Hostname' is not connected to 'MonitoringServerName'

This forum was archived to /woltlab and is now in read-only mode.

    Hi,


    i am sorry to create a new Thread on this, but i cant find anything very usefull for my problem at all. Maybe many threats would have helped.. but im Searching for a solution since 4 hours and i do not really find anything Helpfull.


    I set up a Icinga2 server (with Ubuntu) where i use Icingaweb2 with this "Icinga-Director" Module because that idea sounds awesome... the problem i have is that my XXXMON001 Monitoring-Server can actually ping the other server, but the service i added for the Diskinformation is not working, like its written in the Subject above or as you can see in the Host.png in the Attachements:


    Quote

    Remote Icinga instance 'Hostname' is not connected to 'MonitoringServerName'


    I added that WindowsServer by installing the .exe on it. Since at first the Manual installation did not work i used the Powershell Script.. after that worked i used the Manual installation again (because i tought it actually installs a Basic Services that you normally Monitor, like Load, Diskspace etc.


    I think that i more or less already know where the Problem is, when i put this global zone "director-global" into the zones.conf i get errors when i restart the icinga2 daemon.


    Thats my zones.conf:



    i Changed that manually, before it looked like this, even tough i used that Mastersetup on the Server:



    And this is the error out of the " /var/log/icinga2/startup.log ":


    Code
    1. information/cli: Icinga application loader (version: r2.7.0-1)
    2. information/cli: Loading configuration file(s).
    3. critical/config: Error: Object 'director-global' of type 'Zone' re-defined: in /etc/icinga2/zones.conf: 14:1-14:29; previous definition: in /etc/icinga2/zones.conf: 10:1-10:29
    4. Location: in /etc/icinga2/zones.conf: 14:1-14:29
    5. /etc/icinga2/zones.conf(12): }
    6. /etc/icinga2/zones.conf(13):
    7. /etc/icinga2/zones.conf(14): object Zone "director-global" {
    8. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    9. /etc/icinga2/zones.conf(15): global = true
    10. /etc/icinga2/zones.conf(16): }


    I am also not sure about those zone and node things in general, in the "constants.conf" both have my machines hostname:



    Somebody has an idea what i am doing wrong?

    Code
    1. object Zone "director-global" {
    2. endpoints = [ "XXXMON001" ]
    3. }

    that's not a global zone, seems you've mixed things up with your client setup.


    You'll have two Zone objects with the same name "director-global".

    Not really understanding that... so the Basic version that was created by Icinga2 Agent:


    Code
    1. /*
    2. * Generated by Icinga 2 node setup commands
    3. * on 2017-08-18 03:57:05 -0400
    4. */
    5. object Endpoint NodeName {
    6. }
    7. object Zone ZoneName {
    8. endpoints = [ NodeName ]
    9. }


    Is right?

    In what file do i put that, or is it already put somewhere from the Masternode Setup?:

    Code
    1. object Zone "director-global" {
    2.   global = true
    3. }



    Because the code at top is how i had it before and i got that error on the Icingadirector.


    Code
    1. critical/config: Error: Object 'director-global' of type 'Zone' re-defined: in /etc/icinga2/zones.conf: 14:1-14:29; previous definition: in /etc/icinga2/zones.conf: 10:1-10:29


    You have a zone definition called "director-global" in line 10 and in line 14, Icinga 2 tells you exactly that.


    I do believe that the first object should have a different name. While at it, I'd also suggest to configure a) the master zone and endpoint b) define the client's local zone with XXXMON001 as member, and "master" as parent. Details on that inside the documentation: https://www.icinga.com/docs/ic…6-distributed-monitoring/

    I'm Sorry because i still don't get this totally.. :'-(



    I have changed my config a bit but i still have some issues there... on the Client it now looks like this:



    On the Monitoring server it looks like this:



    So when i looked up that documentation it says: Note: Each client requires its own zone and endpoint configuration. Best practice is to use the client’s FQDN for all object names..


    Does this mean if i have 300 Clients that are Monitored i need to type 300 times the Cliient definitions and zones into the Monitoring Servers zones.conf? So that File will be like 1000-1500 rows big?


    Because actually with only the information of the Master/Monitoringserver in the File its not working, its giving me errors, but another documentation i found said i should add files to the conf.d folder, but it didnt say how to name them, maybe like "Clientname.conf" and put in the Zone Information there for each client?


    But the Documentation you send me says i should exclude the conf.d folder in the icinga2.conf (what i did) so that does not make sense to me at all.. =)



    Thats btw. the errors i get:



    Thanks in advance =)

    The post was edited 1 time, last by Alex91 ().

    Puh, so you're mixing this with the Director now. The latter takes care about deploying the Zone/Endpoint/Host objects for a new host defined in there, if set "agent: yes".


    I'm wondering where this mismatch (no XXXMON001 Zone found). Did you re-run the kickstart wizard after you've changed the master's zones.conf?


    In order to fix the problematic deployment:


    Code
    1. rm -rf /var/lib/icinga2/api/packages/director
    2. systemctl restart icinga2

    and then run the Director kickstart. I'm not a Director pro, so you'll need to consult the docs here.

    When you say "Kickstart wizard" you mean the node wizard on my Monitoring server and not the Icingaweb2 site/Director - Agent thing, right?

    Since my Client (WindowsHost) Leaks a director folder in C:\ProgramData\icinga2\var\lib\icinga2\api\packages your talking about the path on the Monitorig server, so i delete that and rerun the Node Wizard to get a new config?

    Okay, found out what you mean with Kickstart wizard, i deleted the directory on my Monitoring server, now Icingaweg does not show any server or ping anymore ( not even himself), when i try to run the Kickstart wizard it says


    Unable to authenticate, please check your API credentials

    But when i look into the /etc/icinga2/conf.d/api-users.conf its all like i created it before.

    The startuplog (service icinga2 restart leads into errors) tells me this:



    But the features say that API is activated =)


    I feel like every little change i do destroys even more of my setup :'(

    You did create an ApiUser object inside Icinga 2, and follow the graphical kickstart, right?


    https://www.icinga.com/docs/di…raphical-kickstart-wizard


    In terms of the error - you still need a local zones.conf for the Master node, including a zone and and endpoint.


    Something like this:


    Code
    1. object Endpoint "XXXMON001" {
    2. host = "localhost"
    3. }
    4. object Zone "master" {
    5. endpoints = [ "XXXMON001" ]
    6. }
    7. object Zone "director-global" {
    8. global = true
    9. }


    Hint: I'd advise you to get a book, or consult the docs on the main concepts of Zone, Endpoint and config validation errors.


    If you speak German (which I suppose you do according to your profile): https://www.icinga.com/2016/06/30/buch-buch-i-wer-narrisch/

    Well, i have re-added the zones.conf like i did it before.

    The Icinga2 restart on the Server does not give me errors anymore, but i still can't get the kickstart wizard to work again.

    The Api user is created in the conf.d/api-users.conf:

    Code
    1. object ApiUser "director" {
    2.   password = "Secret"
    3.   permissions = [ "*" ]
    4.   // client_cn = ""
    5. }

    API feature is also enabled.

    On the Director in the Webinterface i have the API user under Infrastructure, but when i try to run the wizard it still says wrong credentials.

    When i do not put the Icinga Host Address into the Kickstart options it gives a curl error:

    CURL ERROR: Failed to connect to XXXMON001 port 5665: Connection refused


    But php curl is still installed and it worked before i deleted that folder.. also, when i use telnet from the RDS Server, i can reach XXXMON001 on the port 5665, so thats not blocked somewhere.

    Took like 10 seconds but nothing happened, what does that mean? O=

    I Mean, does that even make sense? Thats like Pinging Localhost/127.0.0.1 isnt it?

    Okay, the first row was bullshit, i just copied it even tough that is just a placeholder servername.

    When i use my real servername just nothing happens... without a 10 seconds delay..

    Ah, when i use the IP Adress it States:


    <h1>Unauthorized. Please check your user credentials.</h1>root@XXXMON001:/#

    But i am not using the root user, i should create a API user called "director" thats what the Documentation said, and the username and password in that command is from the director.

    The post was edited 3 times, last by Alex91 ().

    Nope, it isn't. Ping is different to telnet which is different to what curl uses and does (http protocol). No offense - how good would you rate your Linux knowledge? I might adopt my answers a bit then. Normally I expect that you know Linux and how to troubleshoot connection issues.


    If your local test with curl cannot succeed, it is no wonder that the Director PHP application refuses to.


    I'd ensure that port 5665 is reachable (firewall), and that the API feature in Icinga 2 is enabled, Icinga 2 is running, and so on. You might just try to manually connect to the API using the openssl client, but I guess that also results in a connection timeout.


    Debugging the API connection issues is similar to the cluster protocol: https://www.icinga.com/docs/ic…hooting-connection-errors

    Well... i did first lvl support and Monitoring before i got a Job as a System Administrator.. but this is my first Project, set up a working Monitoring =)

    I didnt do quite much in Linux, i know like 20 commands and nearly all of them are for Oracle Databases.

    The Port is Reachable and firewall rules don't block it, Like i said, it worked on.. i think Friday when i used that Kickstart Setup.

    The API Feature is enabled and icinga2 is running at the moment.

    Is there something inside the icinga2.log file when you attempt to fire a curl request? You can also add "-v" to the curl command to see more.

    Its strange, since of the Documentation i exluded the conf.d folder where the api-users.conf was, i copied that file to zones.d because somebody said that would work - it didnt. Then i just reactivated the conf.d folder... and after some restarts i got strange errors with SQL. The curl command still does not work, but the kickstart wizard re-installed and now i have the 12 basic services (with ping etc.) of the Monitoring Server back in the Host Overview.

    Now i am again trying to install the Windows Client as a server that shall be Monitored.

    Oh... after i changed the name of the Client twice (to have something to press "deploy config") i now have the Ping and the WindowsDiskSpace for the Client in the Host Overview - and its BOTH WORKING =)


    Thank you =)