Posts by log1c

Please read about the latest changes and upgrade.
Please note that your newly registered account needs to be manually activated by an admin. Just be patient, you cannot post to any forum before this happens. This is thanks to the unfortunate event of spammers recently. More details here.

    Hi all,


    I'm currently using Icinga2 2.6 with Icinga Director 1.3 and would like to reproduce dependencies in my monitoring environment, somehow.

    I know that the Director already has a feature request opened for this, but I'd still like to ask if this is already possible by a work-around?


    I have seen this thread Icingaweb2 Director und Parent Hosts were TomGelf posted a screenshot where there are dependencies listed in the config and the module "fileshipper" is mentioned. Are these dependencies solely configured via external files and imported with fileshipper?


    Or is there a way to configure the dependencies by hand (via normal icinga2 config?).

    What would happen if I do it this way or even edit the config written by the Director? Would these changes be preserved or do they get lost when the Director deploys a new config?

    Or would it even crash my config?


    I hope someone can get me started on how to implement dependencies for my current setup.



    Greetings and have a nice weekend!

    You seem to have active checks disabled and passive checks are not provided because the target is down.

    Active checks are enabled now. The problem with this host is, that it can't be pinged, so the host itself has a passive check that is always OK as host check.

    As long as the server (Azure machine) is online and NSClient is running, the checks are OK and get updates. In case the server goes down or can't reach the monitoring host the check should switch to a CRTICAL state given by the dummy command.

    Thanks for your answers!

    That goes for active checks.

    But with passive (only) checks that are late, the last known state is displayed, the red marker is turned on and the time increases.

    An active check is not triggered then.

    So the "next update" time is not directly linked to the threshold for the check result freshness mentioned in the documentation?

    enable_active_checks = true is required.

    Will try and give an update on the outcome.


    edit:

    Stopped the NSClient on the remote host and the service is still "OK" (see picture), though there was no update on the check for 30 minutes.

    Hi all,


    I'm having problems with some passive services, that get their input via NSCA from a Windows Host (NSClient++).


    As long as NSClient or NSCA-Server is running, everything is working fine. The checks get their input (e.g CPU usage or Mem usage) and get updated.


    The service looks like this:


    Now to my problem:

    If I stop NSClient or NSCA Server (to simulate that the host is down) the checks don't switch to CRITICAL state after some time.

    The "last update" time counts up, the dot gets red, the "next update" time goes "negative". (see picture)


    If I understand this (check-result-freshness) correctly:

    1. the "next update" time for my check should be 5 minutes (time when a check result is expected). Instead it always says 10 minutes, when a check result was received.

    2. If the "next update" time reaches 0 the check command should be triggered and set the service to CRITICAL

    Is that correct?


    NSCA Client on the Windows host is configured to schedule the checks every 4 minutes.


    Can anyone help?


    Best regards,


    Logic

    Es funktioniert jetzt, mit folgender Config:


    zones.conf auf dem Satellit:


    Endpoint-Objekt entfernt, endpoint für Zone "Satellit" von "nodeName" in "st-isr04-dev" umbenannt


    Anschließend Zone und Endpounkt im Director wieder konfiguriert.


    Problem ist scheinbar, dass der Director/oder icinga2 die Zonen nicht synct?!

    Aber es kann doch nicht sein, dass ich die Konfig, die mir der Node Wizard angelegt hat, ändern muss und diese Änderungen anschließend in den Director wieder einfüge?!


    Den Endpoint habe ich jetzt testweise im Director entfernt, so dass icinga2 auf dem Satellit wieder startet. Bringt aber, wie zu erwarten, nix.

    nach einem Reload/Restart nicht mehr, da gemeckert wird, dass der Endpoint "st-isr04-dev" doppelt definiert ist.
    Diesen habe ich manuell im Director angelegt, da über einen Import aus der CoreAPI nur die globale Zone sowie die Zone/der Endpunkt des Masters reinkommt.

    hab ich gemacht, der director-global ordner ist jetzt ebenfalls da.
    Der Host ist auch in der hosts.conf drin, checks werden aber nicht ausgeführt und bleiben weiterhin auf PENDING.


    Weitere Aufälligkeit: Auf dem Satellit ist keine icinga2.cmd unter cd /var/run/icinga2/cmd/ vorhanden. Problem?

    Ich habe gerade nochmal etwas rumgeschaut und da ist mir aufgefallen, dass auf dem Satellit die zone "director-global" fehlt.


    /var/lib/icinga2/api/zones auf Master:
    drwx------ 3 nagios nagios 4096 Jan 11 10:43 director-global/
    drwx------ 3 nagios nagios 4096 Jan 11 10:43 st-isr01-dev/
    drwx------ 3 nagios nagios 4096 Jan 11 10:43 st-isr04-dev/


    /var/lib/icinga2/api/zones auf Satellit:
    drwx------ 3 nagios nagios 4096 Jan 11 10:43 st-isr04-dev/


    Ist das vielleicht schon die Wurzel des Problems?



    Muss ich die Zone "director-global" auch auf dem Satellit noch von Hand in die zones.conf schreiben?

    Danke für deine Antwort!

    Nein, da du den Host nicht definiert sind.

    Diese Annahme kam daher, dass bei unserer produktiven Monitoring-Umgebung (aktuell v2.5.4, aufgesetzt im Juni/Juli '16) die Satelliten bzw. Endpunkte automatisch als Host (mit Services) im Moniotring drin waren. Und zwar mit dem Host-Checkcommand "cluster-zone" und der Ausgabe "Zone 'st-monpoll4' is connected. Log lag: less than 1 millisecond"

    Zunächst solltest du im Director einen Host und einen Endpoint für den Satellit hinzufügen.

    Laut Tom sollte dies ja automatisch bei Kickstart passieren, in der "alten" Umgebung habe ich auch keine Zonen/Endpunkte angelegt, um die Satelliten rein zu bekommen.
    Habe das aber trotzdem schon versucht, jedoch bleiben die Checks, die durch den Satelliten ausgeführt werden sollen, weiterhin auf PENDING stehen.


    • Accept config from master? [y/N]: y
    • Accept commands from master? [y/N]: y


    Ich habe keine Ideen mehr, woran es noch liegen könnte, würde aber nochmal darum bitten das Thema in den Icinga2 Core Bereich zu verschieben :)

    Hi zusammen und ein gutes neues Jahr!


    Ich habe gerade beide Maschinen nochmal komplett neu gemacht (2x Ubuntu16.04.1 up-to-date inkl. dist-upgrade).
    Auf beiden Maschinen Icinga2 aus dem Icinga PPA installiert(v2.6.0). Habe diesmal eine komplette Standard-Installation gemacht, ohne Dateien zu löschen.
    Anschließend auf dem Master und dem Satellit den icinga2 node wizard ausgeführt.



    Führe ich anschließend ein icinga2 node list auf dem Master aus, wird mir der Satellit auch angezeigt:




    In der anschließend installierten IcingaWeb2 Oberfläche taucht allerdings nur der Master als Host auf.


    Hier sollte doch aber auch schon der st-isr04-dev als Host aufgeführt sein, oder?


    Auch der Director-Kickstart importiert keine Zone und keinen Endpunkt mit Namen "st-isr04-dev".
    Director ist der aktuelle GIT-Master.



    Wo liegt bei mir das Problem?



    Danke und Gruß


    Logic


    PS: ggf. kann man das Thema ins Icinga2-Forum verschieben, das das Problem ja scheinbar eher im Core als im Direcotr zu suchen ist. :)



    edit:
    Nachfolgend ein Log-Auschnitt nach einem Restart des Icinga2 Dienstes.
    Ist hier Zeile 10 mein Problem?

    Kickstart reicht. Momentan musst wenn neue Satelliten dranhängst den Kickstart selbst nochmal antriggern, das soll in Zukunft automatisch vorgeschlagen werden.

    Hm, dann hat da bei mir wohl etwas nicht geklappt.


    Hast du es ohne command_endpoint schon probiert? Es wäre interessant zu wissen ob das etwas ändert.

    Habe das Template geändert, so dass nur noch die Zone gesetzt ist. Ändert aber leider nix. Wenn ich das Template auf die Master-Zone ändere, funktioniert es.

    Hi Tom,


    ist der command_endpoint also nicht die Einsteellung, die bewirkt, dass der Check von eben diesem Satelliten ausgeführt wird?


    Sollten mit dem Master verbundene Satelliten eigentlich direkt beim Kickstart mit importiert werden, oder ist da immer "handarbeit" angesagt?


    Vielleicht hat ja dnsmichi oder jemand anderes noch eine Idee :)

    Vielleicht hilft das noch jemandem weiter:


    Vorgeschichte zu diesem Problem war:
    Frisch aufgesetzte Ubuntu 16.04 LTS Maschine mit Icinga2, Web2, Director. -> Master
    Bestehende openSUSE 13 Maschine auf der Icinga2 installiert wurde. -> Satellit


    Beim ersten versuch (bzw. den ersten Versuchen) den Satelliten an den Master zu hängen (icinga2 node wizard) kam keine Verbindung zustande. erst mit Eingabe der IP anstelle des FQDN des Masters klappte es dann.


    Anschließend habe ich dann den Director auf dem Master installiert und den Kickstart ausgeführt.
    Auch hier kam der Satellit nicht automatisch mit rein.


    Nach einem manuellen Hinzufügen wurden dann auch Checks durch den Satelliten durchgeführt. Allerdings nur Host-Checks. Die Services, die über Template, Service-Set oder direkt über den Host konfiguriert wurden, wurden immer vom Master gecheckt...


    Daher habe ich die ganze Director-DB nochmal weggeschmissen, /var/lib/icinga2/api/packages/director/ gelöscht und von neuem angefangen.
    Ergebnis ist dieser Thread :S

    beides auf Master ausgeführt:
    curl -k -s -u icingaapi:meinpasswort 'https://192.168.63.35:5665/v1/objects/hosts/DC1-TestLab'



    icinga2 object list --name "DC1-TestLab"

    Hallo zusammen,


    habe gerade meine Icinga2 Demoumgebung wieder neu auf einem Ubuntu16.04.01 LTS aufgebaut und wollte hier jetzt ebenfalls ein Satelliten-Layout (ein Master und ein Satellit) implementieren.


    Habe mit dem icinga2 node wizard den Master und den Satelliten konfiguriert.


    Der anschließende Kickstart des Directors hat mir jedoch nur die Master- und die global-Zone importiert.
    Also habe ich Zone und Endpunkt des Satelliten via Director selbst angelegt. Über eine Import/Syncregel bekomme ich den ebenfalls nicht rein.


    Laut icinga2.log besteht auch eine Verbindung zum Satellit:

    Code
    1. [2016-12-13 14:05:38 +0100] information/ApiListener: New client connection for identity 'st-isr03-dev.ucs.testucs' to [192.168.63.130]:5665
    2. [2016-12-13 14:05:38 +0100] information/ApiListener: Sending config updates for endpoint 'st-isr03-dev.ucs.testucs'.
    3. [2016-12-13 14:05:38 +0100] information/ApiListener: Syncing global zone 'director-global' to endpoint 'st-isr03-dev.ucs.testucs'.
    4. [2016-12-13 14:05:38 +0100] information/ApiListener: Syncing zone 'st-isr03-dev.ucs.testucs' to endpoint 'st-isr03-dev.ucs.testucs'.
    5. [2016-12-13 14:05:38 +0100] information/ApiListener: Syncing runtime objects to endpoint 'st-isr03-dev.ucs.testucs'.
    6. [2016-12-13 14:05:38 +0100] information/ApiListener: Finished sending config updates for endpoint 'st-isr03-dev.ucs.testucs'.
    7. [2016-12-13 14:05:38 +0100] information/ApiListener: Sending replay log for endpoint 'st-isr03-dev.ucs.testucs'.
    8. [2016-12-13 14:05:38 +0100] information/ApiListener: Finished sending replay log for endpoint 'st-isr03-dev.ucs.testucs'.





    Auch werden die configs auf dem Satellit abgelegt:

    Code
    1. ll /var/lib/icinga2/api/zones/st-isr03-dev.ucs.testucs/director/
    2. total 12
    3. -rw-r--r-- 1 icinga icinga 126 Dec 13 13:34 endpoints.conf
    4. -rw-r--r-- 1 icinga icinga 131 Dec 13 12:59 host_templates.conf
    5. -rw-r--r-- 1 icinga icinga 160 Dec 13 14:09 hosts.conf



    Nachfolgend die Configs:


    global-Zone habe ich händisch reingeschrieben

    hier habe ich selbst Hand angelegt und die parent Zone von "master" auf "st-isr01-dev.ucs.testucs" umbenannt. So kommen immerhin die Configs auf das System.


    Satelliten-Zone im Director:

    Code: zones.d/st-isr01-dev.ucs.testucs/zones.conf
    1. object Zone "st-isr03-dev.ucs.testucs" {
    2. parent = "st-isr01-dev.ucs.testucs"
    3. endpoints = [ "st-isr03-dev.ucs.testucs" ]
    4. }

    Satelliten-Endpunkt im Director:


    Code: zones.d/st-isr03-dev.ucs.testucs/endpoints.conf
    1. object Endpoint "st-isr03-dev.ucs.testucs" {
    2. host = "st-isr03-dev.ucs.testucs"
    3. port = "5665"
    4. log_duration = 1d
    5. }


    für Hosts die vom Master überwacht werden sollen:


    für Hosts die vom Satellit überwacht werden sollen:


    Problem ist, dass die Hosts/Services nicht überprüft werden. Die stehen die ganze Zeit auf "pending".
    Führe ich einen force-check aus, taucht dieser auch im Log auf, aber es passiert nichts weiter.


    Code
    1. [2016-12-13 14:31:49 +0100] information/ExternalCommandListener: Executing external command: [1481635909] SCHEDULE_FORCED_HOST_CHECK;DC1-TestLab;1481635909
    2. [2016-12-13 14:31:50 +0100] information/ExternalCommandListener: Executing external command: [1481635910] SCHEDULE_FORCED_HOST_CHECK;DC1-TestLab;1481635910
    3. [2016-12-13 14:31:50 +0100] information/ExternalCommandListener: Executing external command: [1481635910] SCHEDULE_FORCED_HOST_CHECK;DC1-TestLab;1481635910
    4. [2016-12-13 14:31:54 +0100] information/IdoMysqlConnection: Query queue items: 0, query rate: 2.9/s (174/min 848/5min 2558/15min);
    5. [2016-12-13 14:31:58 +0100] information/ExternalCommandListener: Executing external command: [1481635918] SCHEDULE_FORCED_HOST_CHECK;DC1-TestLab;1481635918


    Ich hoffe es kann jemand helfen :)
    Falls weitere Infos gebraucht werden, bitte bescheid geben!


    danke und gruß


    Logic

    Die Lösung dürfte sein:


    Du hast im Director bei deiner Notification bzw. deinem Template bei "letzte Benachrichtigung" keinen Wert drin stehen, oder?


    Ich habe hier eine "1" drin stehen, so dass nach der ersten Benachrichtigung keine weitere versendet wird.