Zabbix module docker and trigger - problem

[forall]

Hi Jan,

Thanks for great work with zabbix docker monitoring. I have problem with docker monitoring when I create triggers. Module nice disover all running containers and I add triggers which inform me after down some containers. The problem appears when I must update/upgrade, in zabbix I see that container "down", becase they change ID. Something like that:

Container r-AppPom-1-0c7c20c7 is running - 0

Container r-AppPom-1-ed06bbd3 is running - 1

Can module monitoring the container e.g - Container r-AppPom-1 is running - 1 - without any ID...?

Thanks, Albert.

[jangaraj]

Set a name for your container(s).

For example:

docker run --name nginx -d nginx
docker restart nginx
docker rm -f nginx
docker run --name nginx -d nginx

=> module will use container name nginx as container ID (macro HCONTAINERID) for all items/triggers.

[forall]

Hi Jan,

Your solution is ok, but did you test your zabbix docker module in environment where you management it with Rancher? Rancher when create and start docker container, set name e.g --name nginx-random - random is a random id...

[jangaraj]

Yes, I understand. Rancher needs a unique name, but you need a unique and stable name for your use case. Or use Rancher monitoring, which will use Rancher API and not a Docker API to create monitored instances. You will have the same problem with Kubernetes, ECS, ...

[forall]

In my case if I need unique and stable name in zabbix, I can't use your module. The only way it's a create some script and cut the random id and add to the zabbix...

[jangaraj]

IMHO it doesn't help you, but you may try. You can still create your custom agent userparameter for your for LLD, which will use docker module discovery + some grep/awk/jq magic to remove random id from HCONTAINERID field, which will be used in the item/trigger names. But use SCONTAINERID/FCONTAINERID macro in the item keys in this case, because that name are used for Docker API, cgroups.

[forall]

it's possible to add that features in your docker module :)?

[jangaraj]

No, because it's specific per orchestration.

[forall]

It's really strange,why they can not use one common standard.