Dynamic config klären woher ein Container stammt

Hallo,
ich ahbe hier eine Umgebung mit diversen Docker-Systemen und lese mit dynamic conf die Container ein. Das klappt soweit gut aber bei einigen Container habe ich das Problem das die Erkennung klemmt und keine Daten ausgibt. In disen Fällen habe ich auch im Wate keien Info von welchem Host die Systeme stammen. Gibt es eine Logdatei oder eine andere Quelle aus der ich erkennen kann woher ein Container stammt und eingelesen wurdeß

Gruß
Ralf

Ist der Container im Monitoring, sollte der Check_MK Check sagen, von wo die Piggyback-Daten stammen.

Das Verzeichnis $OMD_ROOT/tmp/check_mk/piggyback/<containername> enthält entsprechende
Dateien mit dem Hostnamen.

1 Like

Hallo,
da ist ja mein Problem.
Der check zeigt die Infos nict an weil es offenbar ein Problem gibt.
Ich schaue jetzt mal in den Ordnern nach.
Gruß

Ok,
gefunden.
Ursache ist jetzt klar und nicht abzustellen. Die Kollegen stoppen die Container statt sie zu löschen.
Kann ich im Moment aber auch nicht ändern das der Verantwortliche im Urlaub ist.
Die Container die das Problem haben fangen alle mit dcpnitjenkins im Namen an.
Was wäre der sinnvolste Ansatz diese Container erst mal zu managen so das das der Ping nicht check_icmp: No hosts to check meldet?
Gruß

Hallo Ralf,

du kannst diese Host in einem WATO Folder ablegen und dem Folder das Tag ‘do not Monitor’ zuweisen.

Viele Grüße

Anastasios

1 Like

Meine Frage wäre hier eher warum sind die Container überhaupt pingbar?
Normal bei allen Installationen welche ich hab kommt kein Container mit der Aussenwelt in Berührung ohne Reverse Proxy oder Loadbalancer.
Damit haben in den Monitoringumgebungen diese Container auch keine IP’s und damit keinen Ping.

1 Like

Das sind Testsysteme für die Entwickler. Wir arbeiten mit einem RFC2136 Forwarder der eine Namesaulösung ermöglicht. ist etwas spezieller hier.
Kann ich den Ping basiered auf dem Namen über eine Regel abschalten?

Gruß
Ralf