Posts by NRGYDrink

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

    Hallo zusammen


    für den Feiertag gestern hatte ich das Datum in "Holidays" eingetragen, leider ist heute weiter an das Handy eskaliert worden.

    Als Grund konnte ich feststellen, dass Icinga wohl noch das Datum "2016-05-26" von letztem Jahr genommen hat.

    Hatte es zum Test nochmal eskaliert bevor ich das Datum raus genommen hab und danach.

    Ohne das Datum wurde nicht mehr eskaliert.


    Kann jemand meine Konfiguration verifizieren und/ oder ggf. den "Bug" nachstellen?



    Meine timeperiods.conf

    Zum Test bei TimePeriod "holidays" innerhalb ranges {} hinzufügen:

    Code
    1. "2016-05-25" = "00:00-24:00"

    Meine Version:

    Hab die Downtime so abgeändert, die Anzeige ist immernoch 20:00 bis 00:00 Uhr


    Nachtrag: Hat mich gerade etwas verwundert, hab es daher auf einem komplett anderen Host getestet, 20:00 bis 00:00 Uhr


    Nachtrag 2: Hab auch "00:00-04:00,20:00-23:59" getestet, ob es vielleicht am Tageswechsel liegt, 20:00 bis 23:59 Uhr, mehr nicht

    Hallo,


    über Nacht laufen Backups und ich habe schon ein paar Mal festgestellt, dass Icinga2 eskaliert, da der Zielhost relativ ausgelastet ist und deshalb nicht antwortet.


    Eine "scheduled downtime" wäre daher sinnvoll, ich habe aber gemerkt, dass die Downtime über Mitternacht nicht richtig angezeigt wird, lediglich die bis 0 Uhr erscheint.


    Folgendes wird mir in der ClassicUI unter "Downtimes" angezeigt:

    Code
    1. SSH 04-03-2017 12:15:59 icingaadmin Downtime 04-03-2017 20:00:00 04-04-2017 00:00:00 Fixed


    Nach 0 Uhr sollte eine weitere Downtime bis 4 Uhr erfolgen, die fehlt jedoch.


    Meine downtimes.conf


    Im Service ist die folgende Variable hinterlegt:

    Code
    1. downtime = "20:00-24:00,00:00-04:00"


    Ist das ein vielleicht Anzeigefehler in der ClassicUI?

    Gibt es eine andere Möglichkeit sich die aktuellen Downtimes anzeigen zu lassen (z. B. commandline)?


    Danke

    So, war leider die Tage nicht mehr dazu gekommen hier zu antworten.

    Hab das Schema aktualisiert, funktioniert jetzt wieder


    Code
    1. [2017-02-14 15:07:41 +0100] information/DbConnection: Resuming IDO connection: ido-mysql
    2. [2017-02-14 15:07:41 +0100] information/IdoMysqlConnection: MySQL IDO instance id: 1 (schema version: '1.14.2')
    3. [2017-02-14 15:07:56 +0100] information/IdoMysqlConnection: Query queue items: 2, query rate: 669.817/s (40189/min 40189/5min 40189/15min);
    4. [2017-02-14 15:07:57 +0100] information/IdoMysqlConnection: Finished reconnecting to MySQL IDO database in 15.3629 second(s).
    5. [2017-02-14 15:08:11 +0100] information/IdoMysqlConnection: Query queue items: 0, query rate: 676.75/s (40605/min 40605/5min 40605/15min);
    6. [2017-02-14 15:08:26 +0100] information/IdoMysqlConnection: Query queue items: 0, query rate: 677.383/s (40643/min 40643/5min 40643/15min);

    Bzgl. Icingaweb2 muss ich schauen, ob sich die Kollegen drauf einlassen.

    Das letzte Mal als ich die GUI gesehen habe ist auch schon über ein Jahr her, hat sich sicher einiges getan

    Danke für die Hilfe :)

    Ok, danke soweit.

    ClassicUI ist meines Erachtens nach nur wieder genommen worden, da das die Kollegen noch vom alten Icinga kannten.


    Das mit dem Abbruch kann sein, kann ich gerade aber nicht mehr genau sagen.


    Ich hab das Feature eben wieder aktiviert und in der Config den Login zur DB angegeben.

    Code
    1. [2017-02-14 14:07:27 +0100] information/DbConnection: Resuming IDO connection: ido-mysql
    2. [2017-02-14 14:07:27 +0100] critical/IdoMysqlConnection: Schema version '1.14.1' does not match the required version '1.14.2' (or newer)! Please check the upgrade documentation.
    3. Context:
    4. (0) Reconnecting to MySQL IDO database 'ido-mysql'

    Nach dem Logeintrag erscheint nichts mehr und Icinga steht.

    UI sagt: Warning: Status data OUTDATED! Last status data update was 325 seconds ago!


    Dementsprechend natürlich erstmal wieder deaktiviert.

    Ich werde später mit vorheriger Sicherung das Schema aktualisieren


    https://docs.icinga.com/icinga…hapter/upgrading-icinga-2

    Hallo,


    ich habe im icinga2.log gesehen, dass Icinga wohl keinen Zugriff auf die IDO-DB hat:


    Code
    1. [2017-02-13 17:30:30 +0100] critical/IdoMysqlConnection: Connection to database '
    2. Context:
    3. (0) Reconnecting to MySQL IDO database 'ido-mysql'
    4. [2017-02-13 17:30:30 +0100] critical/IdoMysqlConnection: Exception during database operation: Verify that your database is operational!


    In "/etc/icinga2/features-enabled/ido-mysql.conf" stehen keine Verbindungsparameter:


    Code
    1. library "db_ido_mysql"
    2. object IdoMysqlConnection "ido-mysql" {
    3. user = "",
    4. password = "",
    5. host = "localhost",
    6. database = ""
    7. }


    Ich bin Ende Januar auf Version 2.6.0-1 gegangen.

    Da ich das System damals nicht aufgesetzt habe, kann leider nicht mehr nachvollziehen, ob da überhaupt jemals etwas drin stand, bzw. eingetragen wurde.

    Den Fehler im Log hab ich bisher auch nicht wahrgenommen.


    Aktuell läuft hier als GUI die Icinga2-ClassicUI und Ingraph.

    Dafür brauch ich die IDO-DB jedoch nicht, ist das richtig?


    Ich habe das IDO-Feature jetzt zum Test deaktiviert, um zu sehen was passiert, bisher nichts.

    Hab ich dadurch irgendwelche Nachteile bzw. benötige ich das doch für irgendwas und merke es gerade nur nicht?


    Danke schonmal :)

    Habe auch Master + Sat im Einsatz und vor kurzem ein ähnliches Verhalten festgestellt.
    Grundsätzlich funktioniert alles, es sind nur einige einzelne Checks, welche nicht funktionieren, jedoch auch nur bei manchen Hosts und nicht bei allen...



    Der Icinga2-Sat prüft selbst, ob Port 22 erreichbar ist, es wird also nicht auf irgendwas externes wie NRPE gewartet.

    Der Pfad stimmt schon, ich komme ja genau bei den Reports raus mit:

    Code
    1. https://icinga.meinedomain.de/cgi-bin/icinga2-classicui/avail.cgi?blabla


    nur eben nicht mehr wie im alten Icinga möglich mit:

    Code
    1. https://user:passwort@icinga.meinedomain.de/cgi-bin/icinga2-classicui/avail.cgi?blabla

    Wenn ich den User und das Passwort nicht über URL mitgeben kann, bleibt das Script an der Anmeldemaske hängen und gibt "401 - Unauthorized" zurück
    Im alten Icinga war das ganze nicht ans AD gebunden, weshalb ich die Vermutung habe, dass es eben daran liegt.
    Da waren diverse Benutzer direkt in der cgi.cfg drin.


    Hier noch ein paar Konfigurationen:


    /etc/icinga2-classicui/cgi.cfg

    Code
    1. ...
    2. url_cgi_path=/cgi-bin/icinga2-classicui
    3. ...


    /etc/icinga2-classicui/apache.cfg


    Hallo zusammen,


    wir haben im alten Icinga immer automatisiert "Availability Reports" über Cronjobs per Mail als PDF verschickt.
    Das ganze war mit PHP realisiert, grob vereinfacht gesagt, hat das Script über PHP die Seite des benötigten Hosts mit entsprechendem Datum aufgerufen und anschließend in ein PDF gepackt.


    Ich hab das ganze jetzt erneut für Icinga2 verwenden wollen, jedoch funktioniert der Login per URL nicht mehr:

    Code
    1. https://user:passwort@icinga.meinedomain.de/cgi-bin/icinga2-classicui/avail.cgi?blabla


    Ich bekomme die Rückgabe:

    Quote

    Die Datei
    ...:<password>@icinga.meinedomain.de/cgi-bin/icinga2-classicui/...
    wurde nicht gefunden. Überprüfen Sie die Schreiweise, und versuchen Sie es erneut.

    Wenn ich den Username:Password und das @ weglasse, komme ich bis zum Login.
    Die Benutzerinformationen kann ich dort eingeben, klappt alles, komme auf der Reportseite raus.


    Icinga2 ist mit dem AD gekoppelt, könnte es vielleicht daran liegen?
    Gibt es irgendwelche einfach umzusetzende Alternativen?


    Danke und viele Grüße :)

    Danke für die Infos, hab grad gesehen, dass die Konfiguration auf dem Satellit unter "/var/lib/icinga2/api/zones/ZONE/_etc" abliegt, funktioniert also soweit, auch im Web siehts richtig aus :)


    Wie genau müsste es denn aussehen bzw. wie funktioniert es, wenn ich die Konfiguration von conf.d unter zones.d ablege?
    Die Hosts aus conf.d sollten weiterhin vom Master geprüft werden, lediglich Services und so weiter wären für Master und Sats wichtig.
    Kann ich das irgendwo nachlesen?

    Hallo,


    ich habe für ein anderes Netz (nicht dasselbe wie mein Master) einen Satellit installiert (nach dieser Anleitung: http://docs.icinga.org/icinga2…er/distributed-monitoring )
    Der Plan ist, dass ich alles vom Master aus konfiguriere, dieser die Konfiguration an den Sat. schickt und der Sat. es ausführt und die Infos an den Master weiterleitet.


    Somit sah die Konfiguration "6.9.3. Top Down Config Sync" für mich passend aus.
    Ich habe also die Testkonfiguration (mein Sat selbst) im Master unter zones.d/netzxy eingerichtet.
    Der Check wird jetzt auch in der Weboberfläche angezeigt.


    Woran erkenne ich nun, dass dieser Check auf den Sat gesynct wurde und nicht vom Master geprüft wird? Gibt es da ein Verzeichnis/ eine Datei auf dem Sat?


    Desweiteren hat mich der folgende Satz etwas verwirrt:
    -> Note: You can only have one so-called "config master" in a zone which stores the configuration in the zones.d directory. Multiple nodes with configuration files in the zones.d directory are not supported.


    Heißt, ich kann einen Master haben, der die Konfigurationen verteilt, aber es ist möglich, in zones.d weitere Sats mit unterschiedlichen Konfigurationen (z. B. Hosts) auf dem Master anzulegen oder?


    Und zu guter letzt, ich habe einige Hosts und Services, sowie die Notifications etc. auf dem Master unter conf.d konfiguriert, wenn ich diese Services und Grundkonfigurationen auch für die Sats verwenden will, würde es funktionieren, diese als Symlink in zones.d zu kopieren?
    Ich möchte z. B. die notifications.conf stehts identisch halten, die global-templates würden ja nur die selbe Konfigurationen für alle Satelliten nehmen, jedoch nicht die aus conf.d richtig?


    Danke schonmal :)


    Gruß
    Jonas