Serviceerkennung für spez. host im zeitintervall x

Michael0815 · May 22, 2024, 9:10am

Edition 2.2.0p16
Linux/Debian11

Hallo zusammen,

eine sehr simple Aufgabe, welche allerdings nicht funktioniert und ich nicht weiß weswegen.

Aufgabe: Führe für einen Host x eine periodische Serviceerkennung im Zeitintervall x durch.
Es wurde eine entsprechende Regel zur Serviceerkennung (periodical service discovery) erstellt, nur scheint diese nicht zu greifen. Bei einer manuell ausgelösten Serviceerkennung funktioniert alles.

Hier die Regel, welche erstellt wurde:

Es geht dabei um die erste Regel (Beschreibung): periodische serviceerkennung mit servicetracking

Die Regel ist damit gültig für Host cmk-switch-01 und soll jede Minute ausgeführt werden. Dabei soll angezeigt werden, wenn sich bei den Service etwas ändert, sowohl welche neu hinzukommen (nicht überwacht) oder wegfallen (verschwinden). Bei einer manuellen Auslösung funktioniert dies auch.

Das Problem ist, dass diese Regel eben nicht jede Minute angewendet wird. Warum nicht?

Hier noch die Liste aller definierten Regeln im System

Warum jede Minute? Es ist ein Test. Eine Minute ist das kleinste Zeitintervall.
Warum diese Überwachung? Es soll aufgezeigt werden, ob jemand sich an einem Switch zu schaffen gemacht hat, z.B. einen freien Port aktiviert hat. Man könnte auch alle Ports überwachen, doch ich möchte dies hierüber lösen. So wenig wie möglich und nur das notwendige Überwachen. Ich möchte auch keine unnötigen Regeln bezgl. nicht überwachte Services haben. Das ganze soll so schlank wie möglich bleiben.

Am Ende die Taskliste von CheckMK
Der letzte Eintrag ist doch der dazu gehörende Hintergrundjob, oder?

Dieser lief um 10:05:12. Mittlerweile steht die Uhr bei 11:10:xx, also deutlich über der Zeit.

Danke für Ideen und am besten einer funktionalen Lösung.

ChristianM · May 22, 2024, 2:02pm

Hallo Michael.
In der Regel musst du noch die Option “Servicekonfiguration automatisch aktualisieren” verwenden, damit die Discovery weiß, was du machen möchtest. Wenn du nur die Änderungen sehen möchtest, darfst du das autom. Übernehmen von Änderungen in der Option nicht setzen.
Viele Grüße,
Christian

Michael0815 · May 22, 2024, 2:16pm

Hallo Christian,

logischer Tipp, funktioniert allerdings nicht.

Ich habe mir hier extra eine vollkommen neue Instanz aufgesetzt und nur einen Switch eingehängt und die Serviceerkennung gestartet. Dabei die aktiven Ports in die Überwachung genommen.
Wenn ich nun auf einen freien Port, welcher nicht in der Überwachung ist und auch nicht ausgeschlossen ist, wird dieser dadurch nicht erkannt.

Für mich sieht es so aus als ob der Discovery überhaupt nicht statt findet, obwohl eben eine Minute als Intervall definiert ist.

Michael0815 · May 22, 2024, 4:16pm

Hab nun mittlerweile ein upgrade auf 2.3.0p2 für meine Testinstanz durchgeführt. Hätte ja ein Bug sein können, doch auch auf der neuen Version funktioniert dies nicht. Man muss den Vorgang immer manuell auslösen, was mich doch ziemlich nervt.
Ich hatte schon die Situation da war es genau umgekehrt, nämlich dass check_mk discovery immer wieder nicht zugewiesene services und auch labels gefunden hat und diese ständig angenörkelt hat.

Ja ich habe auch alle werks quittiert.
Es funktioniert auch alles zunächst, bis eben auf die Tatsache, dass immer noch kein Servicecheck nach vorgegebenem Intervall (hab es mal auf 3 Minuten gesetzt) durchgeführt wird, um eben neue Services auf dem Host zu entdecken.

Nochmal zur Aufgabe was erreicht werden soll:
Bei Ersteinrichtung des Hosts gibt es folgende Erkennung und Zuordnung (Ursprungszustand)

Nun wird in Port x des Switches ein weiteres Gerät eingesteckt und gewartet, 3 Minuten. Es geschieht nichts. Wird manuell eine Serviceerkennung auf dem Host durchgeführt erhält man folgendes Ergebnis

Der neue Service bleibt als nicht entschieden und siehe da der Service check_mk discovery bringt eine Warnung.

Nun wird die Verbindung dieses Ports getrennt…
Es wird also wieder der Ursprungszustand hergestellt. Damit wäre alles wieder in Ordnung, doch leider auch hier kein automatisches Erkennen der Änderung. Es muss wieder manuell eine Serviceerkennung auf dem Host durchgeführt werden.

Dies gilt auch wenn man den Check des Services manuell neu ansetzt.
grafik

Achso… es wurden keine Änderungen nach der Serviceerkennung durchgeführt, so dass immer der Ursprungszustand status quo war und ist.

StefanM · May 23, 2024, 2:54pm

Hallo Michael

Wann das funktionieren würde, wie du es einsetzen möchtest, wäre der Service maximal eine Minute auf WARN. Oder dann später halt für die eingestellte Zeit. Und das Gerät muss für 2x eingestellte Zeit eingesteckt sein (Check+scheduled Rediscovery).

Beispiel:
Neues Interface gefunden (1 Minute bis Rediscovery). Rediscovery durchgeführt, Interface hinzugefügt und Service wieder grün.

Umgekehrt: Interface verschwindet, Discovery geht auf WARN, Rediscovery wird gescheduled und nach einer Minute ist der Service wieder grün.

Hierzu muss die automatische Aktivierung aktiv sein. Sonst weiß die Discovery mit der zweiten Änderung nichts anzufangen, da sich zum ursprünglichen Zustand keine Änderung ergibt. Das Discovery bliebe dann auch nur auf WARN wenn es ein weiteres neues Interface oder ein zusätzlich fehlendes zum zuletzt gesetzten “Rediscovery” sieht.

Funktioniert seit 2.0 ohne Ausfälle für ca. 1800 gemischte Hosts bei uns. Wir übernehmen aber nur neue Interfaces und lassen ein WARN zurück, wenn Interfaces verschwinden.

Gruß
Stefan

Michael0815 · May 23, 2024, 3:07pm

Hallo Stefan,
bei mir passiert überhaupt nix. Ich stell mir den Timer auf 3 Minuten da ich nun ein Intervall von 3 Minuten für den Discovery check eingestellt habe. Könnte ja sein, dass eine Minute zu knapp ist. Aber weder kurz vor oder nach dem eingestellten Intervall tut sich da was. Der Status bleibt hartnäckig auf OK oder auf WARN, wenn eben beim letzten MANUELLEN!!! Serviceerkennung der Port da (WARN) oder eben wieder weg ist (OK), da im letzten Fall ja der ursprüngliche Zustand wiederhergestellt ist, also kein Zustätzliches Interface gefunden wird.

Für mich sieht es so aus als ob da überhaupt kein Discoery (Serviceerkennung) aktuell angestossen wird und ich meine mich zu erinnern, dass dies mal ging und mich eben wegen diesen Labels genervt hat.

Würde mich interessieren wie du das bei dir gelöst hast bzw. welche Einstellung/Regeln zu verwenden sind, damit das wieder funktioniert.

Die automatische Aktivierung ist mittlerweile seit dem letzten Tip aktiv.

Michael0815 · May 23, 2024, 3:24pm

Ich hab mir die Hintergrund-Job Übersicht angesehen…

heute hatte ich manuell eine Serviceerkennung gestartet

Das ist das was ich jetzt (23.05.2024, 17:18) finde. Es wurde seit 13:55:07 nicht aktualisiert, obwohl die Regel ja 3 Minuten Intervalle vorgibt.

Das Ergebnis nachdem der Vorgang manuell ausgelöst wurde

Allerdings sollte da nicht im Ergebnis eine Änderung stehen, denn es wurde ja ein neues Interface gefunden. Das wird sogleich auch im Dashboard angemängelt. Aber eben immer nur bei einer manuellen Auslösung. Wie bekommt man das automatisch in bestimmten Intervallen hin?

StefanM · May 24, 2024, 10:04am

Hypothese: Die Checks erzeugen keine Background-Jobs.

Die Discovery funktioniert bei uns:

Wenn was neues dazukommt, bleibt der Service auf OK, ein Rediscovery wird vorgemerkt, Rediscovery mit Neuaufnahme wird durchgeführt. Change wird automatisch übernommen. Service ist durchgehend auf OK. Es gibt dazu dann auch keine (neuen) Events. Das Intervall ist entweder 120 Minuten oder 24 Stunden.
Wenn ein Service verschwindet, geht der Check auf WARN bis jemand von Hand ein Discovery macht (wenn der neue Zustand korrekt ist). Hier gibt es einen Event wegen der Statusänderung.

Bei 80.000 Services mit monatlich konstantem Zuwachs vertraue ich dem Konzept schon ein Stück weit. Die “verlustigen” Services sind bislang auch alle nachvollziehbar und gewollt. Z.B. gezogene GBics an Switchen, entfernte Netzwerkkarten in VMs, gelöschte VMs auf vCentern). Und wenn neue VMs auf knapp 40 Instanzen von verschiedenen Kunden angelegt werden, werden die Services auch im Monitoring angelegt ohne händisches Zutun. Sonst hätten mich meine Kollegen schon irgendwo verscharrt.

Zum Ablauf des Tests:
Wenn du den Check alle 3 Minuten ausführen lässt, musst du mindestens 6 Minuten warten. Für die Feststellung des Deltas sogar 9 Minuten. Hier kommt es nicht auf die Frequenz an, sondern auf die Anzahl an durchgeführten Checks und die muss hier 2 sein (erstes Feststellen + Rediscovery) bzw. 3 wenn die Änderung als Statuswechsel sichtbar werden soll.

Gruß
Stefan

Michael0815 · May 24, 2024, 12:50pm

Das ist schön, bei mir anscheinend nicht.

Dann wäre die Idee von mir eh hinfällig, denn ich möchte ja eine Reaktion auf einen neuen Service haben.

Das möchte ich ja gerade nicht haben, sondern der neue Service soll als unentschieden drin bleiben, bis dieser eben verschwindet. Heißt also bei einem Switchport, dass ein noch nicht aktiver Port detektiert wird sobald dieser aktiv wird und dabei eine Meldung erzeugt und wenn dieser wieder deaktiviert wird, dann wieder alles beim Alten ist und deswegen auch keine Meldung erzeugt werden würde.

Woher kommen die 120 Minuten bzw. 24 Stunden?

Dies ist von mir aus auch soweit OK und gewollt.

Ich werde einfach mal einen vollkommen neunen und cleanen Server aufsetzen und checkmk vollständig neu installieren und darauf dann eben nur einen Host ins monitoring einbinden, eben einen Switch und diesen per snmp abfragen. Mal sehen was dabei rumkommt.

StefanM · May 24, 2024, 1:12pm

Aus dem Regelwerk für periodische Serviceerkennung:

Hast du mal was anderes als Tabula rasa probiert? Das schiebt dir immer alles platt. Da hast du nie eine Änderung. Das richtige wäre eher “Add unmonitored & remove vanished services and host labels”.

Michael0815 · May 24, 2024, 1:32pm

ja, ich hatte das aktiv gehabt wie beschrieben.
vorher ohne änderungen übernehmen
dann änderungen bemerken aber keine übernehmen etc.
alles durch
nix hilft

jetzt erstmal eine komplette neue und saubere kiste aufsetzen und nix machen. nur host mit 2 ports rein und mal sehen was dann am montag passiert ist.

Michael0815 · May 24, 2024, 4:38pm

Selbst bei einem cleanen, neue aufgsetztem System und neuem checkmk mit neuer Instanz ist das “Problem” verifizierbar. Weder der automatische noch der manuell ausgelöste “reschedule” am Service check_mk discovery zeigt mir eine Änderung bzw. einen neu gefundenen Service an. Das ist also scheinbar so. Das ganze funktioniert nur, wenn ich manuell einen rescan der Service am Host durchführe. Dann und nur dann meckert check_mk discovery und zeigt eine Änderung an. Ist allerdings nicht das was ich möchte. OK.

Also erzwungener Service auf alle Ports welche down sein sollen pro Switch. Das ist eine Menge Aufwand für so eine einfache Aufgabe: Zeige mir eine Veränderung des status quo auf ausgewählten Hosts an, also wenn ein Service dazukommt welcher noch nicht überwacht wird. Das geht anscheinend nicht oder eben nicht so einfach. Sehr schade.