Hallo zusammen,
mich würde interessieren, ob Änderungen an den gesammelten Inventory-Daten in Checkmk möglich sind.
Hintergrund:
Wir wollen die Daten aus Checkmk in i-doit übernehmen. Leider kommt es dabei zu Fehlern. Checkmk sammelt u.a. Daten zu netzwerkinterfaces mit MAC-Adressen ein. Auf unserem kubernetes wird dabei ein Tunnel-Interface mit der MAC-Adresse “0:0:0:0” eingesammelt. Dies führt beim Importversuch in i-doit zu Fehlern, da die Prüfung der MAC-Adresse ein falsches Format entdeckt.
Daher würde ich gerne die Daten so modifizieren, dass entweder das Interface nicht mit in Checkmk aufgenommen wird, das Interface aus den eingesammelten Daten gelöscht wird oder die “MAC” des Interfaces auf “0:0:0:0:0:0” o.ä. geändert wird.
Hallo,
du kannst konfigurieren das bestimmte Interfaces nicht von checkmk überwacht werden.
Das Thema ist erst in den letzten Tagen englisch sprachig hier durch gekommen.
Gruß
Ich würde hier mal einfach sagen, es muss der Import zum i-doit angepasst werden.
Im CheckMK die Inventur Daten manuell zu editieren geht ist aber meiner Meinung nach nicht unbedingt trivial und kann auch zu kaputten Daten führen.
Bei der HW/SW Inventur werden erstmal alle Interfaces erfasst welche auf den Devices vorhanden sind. Nur wenn die Porttypen für die Tunnel Interfaces andere sind wie die restlichen Interfaces lässt sich auch in der HW/SW Inventur ein Filter einschalten diese zu filtern.
Hardware / Software Inventory → Parameters for switch port inventory
Unter den “Parameters for switch port inventory” lassen sich offenbar nur Positivlisten führen. Da die als “tunl0” bezeichneten Interfaces aber dem selben Typ (6 - ethernetCsmacd) wie die anderen Interfaces zugeordnet bekommen, kann ich hier keinen Filter erstellen. Ich werde nochmals bei i-doit wegen der Konfiguration des Importers anfragen. Vielleicht hilft die einheitliche Bezeichnung der Interfaces durch Checkmk.
Aus Erfahrung kann ich sagen der Importer im i-doit ist arg rudimentär für solche Aufgaben.
Das Problem mit dem Typ hab ich mir so auch fast gedacht.
Was meinst damit genau? Die Bezeichnung der Interfaces stammen von deinem überwachten System da macht CMK erstmal gar nix damit. Der Interface Typ wird halt pauschal auf ethernetCsmacd gesetzt da es ein Interface ist welches vom Agent reported wird.
Einzig auf Agenten Seite wäre eine Filterung möglich, dass die Tunnel Interfaces erst gar nicht mit übertragen werden.
Alle Tunnel-Interfaces auf allen Systemen mit dem Problem haben die Bezeichnung “tunl0” und zeigen in der Abfrage des Agenten “link/ipip 0.0.0.0 brd 0.0.0.0” an (sonst steht an der Stelle link/ether und die MAC von Interface und brd).
Bleibt noch herauszufinden, wie ich entweder das Interface bei der Erfassung filtere oder aus den “0.0.0.0” was wie “00:00:00:00:00:00” mache.
if [[ "$eth" -eq "tunl0" ]]; then
echo -e "\tAddress: 00:00:00:00:00:00\n"
else
echo -e "\tAddress: $(cat "/sys/class/net/$eth/address")\n"
fi
ersetze. Das ist eine quick and dirty Lösung und ein Abgleich des Adressformats wäre sauberer aber in diesem Spezialfall ausreichend.
Jetzt noch schauen wie die Änderung automatisch in die betreffenden Agenten gebracht werden kann.
So, nachdem dem i-doit-Importer für checkmk mit der Version 2.1 nicht zurecht kam habe ich jetzt wieder eine lauffähige Version erhalten. Natürlich wurden die Agenten inzwischen alle aktualisiert und der manuelle Hack ist raus geflogen.
Gibt es eine Möglichkeit das inventory-Plugin des Agenten zentral und dauerhaft zu modifizieren oder (besser) per zusätzlichem Plugin die Ausgabe vor der Übertragung zu parsen und ggf. zu modifizieren?
Nochmal zur Situation:
Auf dem (Kubernetes-)Host werde jede Menge Interfaces erkannt.
Die Interfaces werden mit folgenden Eigenschaften ausgegeben:
Index|Description|Alias|Status|Admin|Used|Speed|Physical Address (MAC)|Type|
|1|lo|lo|up|||0 bit/s|00:00:00:00:00:00|24 - softwareLoopback|
|2|ens6|ens6|up||used|0 bit/s|52:54:00:7D:00:20|6 - ethernetCsmacd|
|3|tunl0|tunl0|up||used|0 bit/s|00:00:00:00|6 - ethernetCsmacd|
|4|cali0268a6fa0e8|cali0268a6fa0e8|up||used|10 Gbit/s|EE:EE:EE:EE:EE:EE|6 - ethernetCsmacd|
|5|cali02df9a49136|cali02df9a49136|up||used|10 Gbit/s|EE:EE:EE:EE:EE:EE|6 - ethernetCsmacd|
…
Ziel:
Ich möchte alle Interfaces mit der Description tunl0.* und cali.* bereits vor der Übertragung an CheckMK los werden.
Wo werden denn die gesammelten Daten des Plugins ausgegeben? Gibt es eine Ausgabedatei, welche vom Agenten nach Fertigstellung des Inventory gelesen wird?
Idee: Dann könnte ich die Datei nach den unerwünschten Einträgen parsen lassen und diese entfernen.
Du willst, dass die Dinger nicht in der HW/SW Inventory kommen, oder? Für den Export in Idoit, weil die das von dort auslesen?
Weil von den Services kannst du es leicht entfernen. Bei den Calico-Interfaces auch nachvollziehbar, weil irrelevant.
Die Daten werden vom Agenten erzeugt. Du kannst den Agenten natürlich anpassen, dass er einfach die Interfaces dazu nicht ausgibt…
Genau. Die Interfaces sollen nicht im Inventory auftauchen. Wie ich sie aus den Services entferne habe ich beschrieben gefunden. Leider werden Sie im inventory noch immer aufgeführt.
Da ich im Agenten inventory Daten eigentlich per Plugin nur hinzufügen aber nicht entfernen kann, dachte ich, vielleicht kann ich auch die Ausgabedatei per Plugin (Script) bearbeiten lassen. Leider finde ich die Ausgabedatei nicht. Prinzipiell müsste es ja eine geben, da das Auffüllen des Inventories das Abfrageintervall des restlichen Agenten überschreiten dürfte.
Wo finde ich denn die “Vorlage” des Agenten in CheckMK (wir haben es in Docker laufen)? Dann könnte ich die Änderungen dort persistent für weitere Agentenupdates unterbringen.
wir nutzen auch i-doit und spielen die Daten alle 24 Stunden automatisch ein. Ich habe das so gelöst, dass der CheckMK-Server die Inventur macht einmal am Tag und die Daten auf dem Server ablegt (das macht CheckMK von sich aus).
Als erstes kopiert ein Script die Daten einmal sicherheitshalber in ein temporäres Verzeichnis. Anschließend läuft ein Python-Script, das mir aus dem Python Dictionary ein JSON-File erzeugt. Nun gehe ich mit PHP dran und modifiziere mir alle Daten die ich brauche und schreibe alles in eine große CSV-Datei zusammen.
In i-doit importiere ich dann automatisch nur noch die CSV über die console.php in i-doit über einen Cronjob nachts. Somit habe ich jeden Morgen die aktuellen Server in i-doit für die Doku.
Vielleicht hilft dir dieser Denkanstoß weiter, wie wir das lösen.
Hallo,
das hört sich interessant an. In i-doit, habe ich jetzt erfahren, kann man die Prüfung der MAC abschalten, welche oben die Probleme gemacht hat. Das führt bei uns aber zu einer irrsinnigen Zahl an Objekten, da im Software-Inventory natürlich jedes kleine Paket aus den Linux-Systemen auftaucht und eine eigene Anwendung in i-doit darstellt. Von i-doit aus gibt es aktuell keine Filtermöglichkeit und ich könnte nur den Software- und Serviceimport generell abschalten.
Wenn das nach deiner Methode geht, dan könnten wir gleich die Anwendungen per Whitelist nach Lizenzierten Programmen filtern und hätten zur Versionsprüfung noch immer die Daten in CheckMK.
Leider kenne ich mich mit der Datenablage von CheckMK nicht aus (und wir haben es in Docker laufen was es nicht einfacher macht). Holt ihr euch die Daten per WebAPI oder direkt aus dem Dateisystem?
mit dem Update auf CheckMK 2.1.0p16 wurde wohl der json-Output der APIs in CheckMK unerwartet abgeschaltet. Damit ist das i-doit-Plugin wieder funktionslos…
Warte also auf das Plugin und werde wohl 2-gleisig fahren: Alles bis auf Software und Pakete über das Plugin nach i-doit holen und die Software hole ich per Script über eine csv nach i-doit. Die notwendige Struktur einer csv für den vollständigen Import der Host-Daten nach i-doit erscheint mir extrem (zu) aufwändig als das ich dies selbst programmieren möchte. Software und Pakete aus der API-Ausgabe filtern und als Liste gefiltert in eine csv zu schreiben funktioniert problemlos und schnell über ein paar Zeilen Python.
Bin gespannt, wann das Plugin wieder funktioniert. Mein Python-Script war schnell von json auf ein python-dict umgeschrieben.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
