Hallo,
es kommt ja bei Docker doch häufiger mal vor, dass ein Container durch einen Container mit einer neuen ID ersetzt wird, z.B. wenn man mit docker-compose arbeitet.
mk_docker_container_piggybacked nimmt ja die Container ID als Hostname, die sich bei jedem Deployment eines neuen Images ändert.
D.h. ich muss nach jedem Deployment neue Hosts anlegen oder zumindest die "Hostname translation for piggybacked hosts" anpassen.
Hat da jemand eine Anleitung für eine automatisierte Lösung?
Ich sehe nur, dass ich die Info aus docker_container_labels verwenden könnte, um einen Container zu identifizieren und einem Host in CMK zuzordnen. Aber wie könnte ich das in Check_MK einbauen?
Mein erster Gedanke wäre, einen Cronjob zu schreiben, der ständig die Piggyback-Daten in tmp/check_mk/piggyback auswertet und ggf. die piggyback_translation neu schreibt. Dann müsste ich aber auch noch einen "cmk restart" machen (in CRE), um die neue Translation Table zu aktiviere? Das klingt mir alles relativ abenteuerlich...
Oder sollte man mk_docker_container_piggybacked links liegen lassen und gleich auf die 1.6 warten?
Mit freundlichen Grüßen,
Gregor Hoffleit
···
--
MediaSupervision Software Consulting GmbH - www.mediasupervision.de
Der Spezialist für Verlage und Medienunternehmen
Niederlassung: Carl-Theodor-Str. 5, 68723 Schwetzingen
Tel: +49 (0)6221 705079-22, E-Mail: gregor.hoffleit@mediasupervision.de
Hauptsitz: Georg-Friedrich-Händel-Str. 13, 69214 Eppelheim / Heidelberg
Amtsgericht Mannheim HRB 336821; Geschäftsführer: Reinhard Kratzke
Hallo,
es kommt ja bei Docker doch häufiger mal vor, dass ein Container durch
einen Container mit einer neuen ID ersetzt wird, z.B. wenn man mit
docker-compose arbeitet.
mk_docker_container_piggybacked nimmt ja die Container ID als Hostname,
die sich bei jedem Deployment eines neuen Images ändert.
D.h. ich muss nach jedem Deployment neue Hosts anlegen oder zumindest die
"Hostname translation for piggybacked hosts" anpassen.
Hat da jemand eine Anleitung für eine automatisierte Lösung?
Ich habe mir damit geholfen, dasss ich für das piggyback nicht die
Container-ID, sondern den Container-Namen verwende. Den Namen kann ich ja in
Docker mit "docker run --name ..." explizit setzen.
Was dafür zu tun ist, habe ich hier beschrieben:
https://lists.mathias-kettner.de/pipermail/checkmk-en/2019-April/027700.html
Man muss natürlich aufpassen, dass die Namen in der überwachten Umgebung
nicht mehrfach vorkommen, etwa auf verschiedenen Docker Hosts.
Gruß, Harald
Hallo Gregor,
wir hatten bei uns vor kurzer Zeit das selbe Problem und die Lösung war es das Piggybacked Script umzuschreiben sodass es statt der ID die Containernamen zurück liefert. Man trägt dann als Host den Containernamen ein statt der ID. Man muss lediglich darauf achten das man dann keinen Container mit gleichen Namen hat denn diese sind Unique.
Ich poste hierzu kurz die Antwort von Harald Weidner aus der englischen CHECK_MK Mailingliste vom 17.04.2019.
Hello,
As we have many services containerized we would like to monitor Docker
containers too. For that purpose we added the piggyback script and the
docker support script first and then added the first hosts. Basically
everything is working but on aspect I think we got wrong and I would like
to know how other people handle that (possible?) problem 
In the documentation it is written that we have to add new a host and we
have to use the Docker container ID as host name. What is the reason to
use the container ID instead of the container name? From our point of
view (if we are not mistaken that only ID is possible) its a bit
complicated.
I think you got it right. It you prefer to see the container names in the
Multisite console, you can use the WATO rule “Hostname translation for
piggybacked hosts” to translate a container ID into the desired hostname.
See also https://mathias-kettner.de/cms_monitoring_docker.html
When we deploy new images the ID would usually change as we remove the
older container and create a new one and then we would have to change the
IDs manually in CHECK_MK. Is that on purpose that only ID is used instead
of the actual container name or is there a way to define the docker
container name instead of the ID?
There is no configuration option to send piggyback data for the container
name instead of the ID. However, the desired behavior can be achieved by
changing one line to the agent plugin mk_docker_container_piggybacked:
Search for the line
for CONTAINER_ID in $(docker container ls -q --all); do
and replace it by
for CONTAINER_ID in $(docker container ls --all --format “{{.Names}}”); do
Ich hoffe das es dir weiterhilft, bei uns klappt es auf jeden fall gut
Viele Grüße,
Stefan
···
On 6. Jun 2019, at 14:54, Gregor Hoffleit gregor.hoffleit@mediasupervision.de wrote:
Hallo,
es kommt ja bei Docker doch häufiger mal vor, dass ein Container durch einen Container mit einer neuen ID ersetzt wird, z.B. wenn man mit docker-compose arbeitet.
mk_docker_container_piggybacked nimmt ja die Container ID als Hostname, die sich bei jedem Deployment eines neuen Images ändert.
D.h. ich muss nach jedem Deployment neue Hosts anlegen oder zumindest die “Hostname translation for piggybacked hosts” anpassen.
Hat da jemand eine Anleitung für eine automatisierte Lösung?
Ich sehe nur, dass ich die Info aus docker_container_labels verwenden könnte, um einen Container zu identifizieren und einem Host in CMK zuzordnen. Aber wie könnte ich das in Check_MK einbauen?
Mein erster Gedanke wäre, einen Cronjob zu schreiben, der ständig die Piggyback-Daten in tmp/check_mk/piggyback auswertet und ggf. die piggyback_translation neu schreibt. Dann müsste ich aber auch noch einen “cmk restart” machen (in CRE), um die neue Translation Table zu aktiviere? Das klingt mir alles relativ abenteuerlich…
Oder sollte man mk_docker_container_piggybacked links liegen lassen und gleich auf die 1.6 warten?
Mit freundlichen Grüßen,
Gregor Hoffleit
–
MediaSupervision Software Consulting GmbH - www.mediasupervision.de
Der Spezialist für Verlage und Medienunternehmen
Niederlassung: Carl-Theodor-Str. 5, 68723 Schwetzingen
Tel: +49 (0)6221 705079-22, E-Mail: gregor.hoffleit@mediasupervision.de
Hauptsitz: Georg-Friedrich-Händel-Str. 13, 69214 Eppelheim / Heidelberg
Amtsgericht Mannheim HRB 336821; Geschäftsführer: Reinhard Kratzke
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
Verwaltung & Abmeldung unter
https://lists.mathias-kettner.de/cgi-bin/mailman/listinfo/checkmk-de
Hallo Stefan,
vielen Dank! Super, genau in der Zeile kribbelte es bei mir schon, das umzustellen. Ich war nur irritiert, dass ich da überhaupt nichts gefunden habe. Der Thread in der englischen Liste ist mir irgendwie durchgegangen!?
MediaSupervision Software Consulting GmbH - www.mediasupervision.de
Der Spezialist für Verlage und Medienunternehmen
Niederlassung: Carl-Theodor-Str. 5, 68723 Schwetzingen
Tel: +49 (0)6221 705079-22, E-Mail: gregor.hoffleit@mediasupervision.de
Hauptsitz: Georg-Friedrich-Händel-Str. 13, 69214 Eppelheim / Heidelberg
Amtsgericht Mannheim HRB 336821; Geschäftsführer: Reinhard Kratzke
···
Den Container-Namen zu verwenden scheint mir in der Mehrzahl der Fälle, die ich mir vorstellen kann, deutlich plausibler als die Container-ID.
Habe es auch schon getestet - funktioniert wunderbar!
Was bei mir irgendwie noch nicht funktioniert, ist dann eine Hostname Translation, um diese Container-Namen noch sprechender zu machen. Trotz Eintrag bespielt er noch immer die Container-Namen. Das ist aber sicherlich ein anderes Problem.
Mit freundlichen Grüßen,
Gregor Hoffleit
–
Von: “Stefan Mayer-Popp” smp@symentis.com
An: “gregor hoffleit” gregor.hoffleit@mediasupervision.de
CC: “checkmk-de” checkmk-de@lists.mathias-kettner.de
Gesendet: Donnerstag, 6. Juni 2019 15:16:22
Betreff: Re: [Check_mk (deutsch)] mk_docker_container_piggybacked und Änderungen der Container IDs (z.B. docker-compose)
Hallo Gregor,
wir hatten bei uns vor kurzer Zeit das selbe Problem und die Lösung war es das Piggybacked Script umzuschreiben sodass es statt der ID die Containernamen zurück liefert. Man trägt dann als Host den Containernamen ein statt der ID. Man muss lediglich darauf achten das man dann keinen Container mit gleichen Namen hat denn diese sind Unique.
Ich poste hierzu kurz die Antwort von Harald Weidner aus der englischen CHECK_MK Mailingliste vom 17.04.2019.
Hello,
As we have many services containerized we would like to monitor Docker
containers too. For that purpose we added the piggyback script and the
docker support script first and then added the first hosts. Basically
everything is working but on aspect I think we got wrong and I would like
to know how other people handle that (possible?) problem
In the documentation it is written that we have to add new a host and we
have to use the Docker container ID as host name. What is the reason to
use the container ID instead of the container name? From our point of
view (if we are not mistaken that only ID is possible) its a bit
complicated.
I think you got it right. It you prefer to see the container names in the
Multisite console, you can use the WATO rule “Hostname translation for
piggybacked hosts” to translate a container ID into the desired hostname.
See also https://mathias-kettner.de/cms_monitoring_docker.html
When we deploy new images the ID would usually change as we remove the
older container and create a new one and then we would have to change the
IDs manually in CHECK_MK. Is that on purpose that only ID is used instead
of the actual container name or is there a way to define the docker
container name instead of the ID?
There is no configuration option to send piggyback data for the container
name instead of the ID. However, the desired behavior can be achieved by
changing one line to the agent plugin mk_docker_container_piggybacked:
Search for the line
for CONTAINER_ID in $(docker container ls -q --all); do
and replace it by
for CONTAINER_ID in $(docker container ls --all --format “{{.Names}}”); do
Ich hoffe das es dir weiterhilft, bei uns klappt es auf jeden fall gut
Viele Grüße,
Stefan
On 6. Jun 2019, at 14:54, Gregor Hoffleit gregor.hoffleit@mediasupervision.de wrote:
Hallo,
es kommt ja bei Docker doch häufiger mal vor, dass ein Container durch einen Container mit einer neuen ID ersetzt wird, z.B. wenn man mit docker-compose arbeitet.
mk_docker_container_piggybacked nimmt ja die Container ID als Hostname, die sich bei jedem Deployment eines neuen Images ändert.
D.h. ich muss nach jedem Deployment neue Hosts anlegen oder zumindest die “Hostname translation for piggybacked hosts” anpassen.
Hat da jemand eine Anleitung für eine automatisierte Lösung?
Ich sehe nur, dass ich die Info aus docker_container_labels verwenden könnte, um einen Container zu identifizieren und einem Host in CMK zuzordnen. Aber wie könnte ich das in Check_MK einbauen?
Mein erster Gedanke wäre, einen Cronjob zu schreiben, der ständig die Piggyback-Daten in tmp/check_mk/piggyback auswertet und ggf. die piggyback_translation neu schreibt. Dann müsste ich aber auch noch einen “cmk restart” machen (in CRE), um die neue Translation Table zu aktiviere? Das klingt mir alles relativ abenteuerlich…
Oder sollte man mk_docker_container_piggybacked links liegen lassen und gleich auf die 1.6 warten?
Mit freundlichen Grüßen,
Gregor Hoffleit
–
MediaSupervision Software Consulting GmbH - www.mediasupervision.de
Der Spezialist für Verlage und Medienunternehmen
Niederlassung: Carl-Theodor-Str. 5, 68723 Schwetzingen
Tel: +49 (0)6221 705079-22, E-Mail: gregor.hoffleit@mediasupervision.de
Hauptsitz: Georg-Friedrich-Händel-Str. 13, 69214 Eppelheim / Heidelberg
Amtsgericht Mannheim HRB 336821; Geschäftsführer: Reinhard Kratzke
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
Verwaltung & Abmeldung unter
https://lists.mathias-kettner.de/cgi-bin/mailman/listinfo/checkmk-de