wir nutzen die Virtuelle Appliance mit derzeit Version 1.4.8 und cmk Version 1.6.0p13 in einem Distributed Monitoring. Die Konfiguration erfolgt über eine Master Site.
Seit Update von 1.5 -> 1.6 haben wir das Problem das wir einzelne Service nicht mehr disable’n oder removen können.
Beispiel: Nach klick auf Wato und dann Services erschienen einige rote Netzwerk Interface. Wir wollen nun als Beispiel drei davon Disable’n. Klick auf das jeweilige Kästchen vor dem Netzwerk Interface und dann Disable. Das System macht ein Update, aber die Devices bleiben sichtbar und werden nicht nach Disabled Services verschoben.
Es klappt auch nicht mit dem roten Button disable. Das einzige was funktioniert ist der Button fix all vanished/new. Das Problem ist aber das wir nicht alle fixen möchten.
Interessanterweise klappt es mit grünen Services ohne Probleme.
Getestet auf Windows mit IE 11, Linux Chrome und Firefox.
Manchmal ist mir passiert, dass es seltsame alte Regeln gab welche verhinderten Services zu disablen. Deshalb habe ich mir angewöhnt nach einem Update erstmal alle Deprecated und Ineffective Rules zu kontrollieren. Bei einzelnen Hosts kann es auch sinnvoll sein zu kontrollieren welche Rules dort alle wirken und diese auf Ihre Sinnhaftigkeit zu prüfen. Ich könnte mir durchaus vorstellen, dass die automatisch generierten Regeln und schon im System befindliche Regeln sich teilweise in die Quere kommen können. Trifft das Problem wirklich auf alle Hosts zu?
Ein schneller Test wäre auf dem gleichen Monitoring Host eine Test Site erzeugen mal 1-2 Hosts dort anlegen die zur Zeit das Problem haben und probieren ob dort das disablen geht.
War ein Ansatz. Habe mir mal kurz einen Host geschnappt. Leider liegen auf dem Ordner weder Deprecated noch ineffective Rules.
Selbst auf Main-Ordner keine Deprecated und einige wenige ineffective, die aber alle gar nix mit dem Beispiel Host zu tun haben.
Es klappt ja auch auf diversen Subsites nicht.
Interessant ist das CMK ja auch einen Change meldet, aber eben nix tut. Ebenso das der “Fix all vanished/new” button funktioniert. Sollte ja bei einer fehlerhaften Regel auch nicht klappen oder?
Äh ja vanished Service kann man nicht ignorieren nur mittels des Mülleimer Symbols entfernen.
Oder aber über die “Remove” Schaltfläche alle vanished Services entfernen.
Über das Disable Icon sollte der Service selbst aber auch verschwinden nur sieht man das nirgends da der Service ja vanished ist und einfach verschwindet nach dem Disable.
Naja, aber das ist ehrlich gesagt totaler Mist und war in den pre 1.6 Versionen nicht so. Das Problem ist das CMK seit 1.6. Interface die Down gehen bzw. kurz gezogen werden, einfach als Vanished markiert. Damit kann ich dann nicht sagen ich möchte dieses Interface nicht haben. Prinzipiell kann man das sicher über eine Rule machen, was aber absolut unpraktikabel ist. Ich möchte dieses Interface z.B. in Zukunft Ignorieren. Das würde bedeuten so wie es jetzt ist muss ich eine Rule erstellen obwohl es einen Knopf für Disable gibt.
Nächste Frage ist, warum gibt es einen Button Disable, wenn er nutzlos ist?
Aus dieser ganzen Situation enstehen mehrere Probleme, die CMK im Netzwerk fast Nutzlos machen und die Akzeptanz meiner Nutzer im Netzwerksegment weiter nach unten drücken.
Das stimmt nicht. Dieses Verhalten ist über die Interface Discovery Regel konfigurierbar und war es auch vorher schon.
Der Button macht nix anderes als eine Rule erstellen.
Ich kann wirklich nicht nachvollziehen was hier das wirkliche Problem ist.
Wie schaut den in deinem System die Discovery Regel für Interfaces aus und wie die dazu gehörige “Default” Regel für die Überwachung? Es gibt schöne Lösungen welche bei mir ohne Probleme in Systemen mit 30k Ports funktionieren.
Diese Regel inventarisiert alle physischen Ports welche entweder Up od. Down sind. Benutzt dabei den Alias zu Beschriftung.
Passend dazu gibt es dann folgende Regel zur Überwachung.
Durch diese Regel wird erreicht, dass alle Ports welche unbeschriftet sind eh keine Fehler produzieren Falls diese Up/Down wechseln. Beschriftete Ports werden automatisch mit Ihrem inventarisierten Zustand überwacht. Es ist natürlich möglich die Regeln weiter auszubauen, dass auch Ports welche mit “Client…” oder ähnlichen beschriftet sind ignoriert werden im Status.
Das Spiel lässt sich so gestalten, dass selbst in meinen ganz großen Netzwerken nur 2-3 Regeln für Ports existieren und sonst alles automatisch überwacht wird.
Bei so einem Regelwerk ist es auch nicht notwendig explizit Ports zu ignorieren. Dies ist aber durchaus möglich. Es gib bei mir nur Vanished Services falls ein Port umbenannt wird. Dies lässt sich aber auch automatisieren wenn man Service Discovery mit automatischer Aktivierung der Änderungen benutzt.
Naja daran wurde ja aber eben nichts verändert und vorher hat es funktioniert.
Aber das tut er ja eben nicht wenn der Port Vanished ist.
Ok etwas besser ausgedrückt, meine User wollen da nen Knopf drücken, mit mehr wollen die Netzwerkadmins sich nicht beschäftigen. Unabhängig davon das diese eh lieber andere Tools verwenden würden und damit die Akzeptanz für CMK schon gering ausfällt. Erhöht dieses Problem noch die Abneigung. Oh Ton: “so nicht nutzbar und Administrierbar.” Ich will ja nicht jeden Quark selber machen.
Ist quasi alles auf Default. Haben da wenig bis gar nichts dran geändert.
Ich schau aber Montag nochmal nach und melde mich. Dann schaue ich mir gleichmal deine Ansätze an, auch wenn bei uns leider oftmals keine Description (nicht meine Hoheit, nicht Fragen
) angelegt wird und darum wiederum das nicht ganz so funktioniert.
Also wie vermutet werden nur UP Interface Inventarisiert. Dadurch konnten die Down Interface nicht Disabled werden. Warum der Button zum Disablen bei Vanished Service erschient erschließt sich mir nicht und ist etwas Userunfreundlich. Ein Button der da ist sollte auch eine Funktion haben.
Ob dieses verhalten in der Default Rule vor 1.6 anders war konnte ich mangels Zeit und Testumgebung nicht mehr nachvollziehen.
Any Way, Wir haben die Regel jetzt auf die DOWN Interface erweitert und disablen diese per Rule oder Hand.
Hat er auch - der Button erzeugt im Hintergrund genau wie sonst auch eine Regel für das Ignorieren der Services. Nur hast halt danach die Auswirkung der Regel nicht direkt gesehen.
Das ist halt etwas seltsam geb ich zu wenn man das System noch nicht seit Ewigkeiten benutzt.
Ansonsten ist es ja gut wenn es nun funktioniert.
Ein Vorschlag noch am Rande. Interfaces nie im Monitoring per Regel ignorieren sondern per Regel konfigurieren, dass es egal ist ob Up od. Down und auch den Speed auf egal einstellen.
Diese Regeln macht man am besten an der Beschriftung fest und hat somit ein konsistentes Monitoring über die gesamte Infrastruktur. Gleichzeitig hat man durch die konsistente Beschriftung die leidige Dokumentationspflicht erfüllt
Hat sich vor allem dann bewährt wenn es später mal um den Punkt Troubleshooting geht.
Naja dann sollte die Regel aber da sein und auch greifen. Es ist aber keine Regel da das ist ja was ich seltsam finde, und wenn eine Regel da wäre dann müsste es auch egal sein ob Vanished oder nicht. Zumindest nach meiner Logik.
Das verhalten ist mir in den letzten sieben Jahren nie aufgefallen. Wobei wir die ersten 4 Jahre noch alles ohne Wato gemacht haben. Deshalb bin ich ja der Meinung das das in früheren Versionen anders war.
der Speed steht schon immer auf Ignore. Den Rest nehme ich mal so mit, ist halt nicht meine Abteilung. Ich habe den Vorschlag gemacht die Ports per Description und entsprechendem Tag zu Monitoren.
.