Long and not friendly container names

[xarly]

I'm testing dockbix to monitor google cloud container engine (kubernetes)

Dockbix discover items like k8s_nginx.eb9a4879_nginx-701339712-8rcxq_default_e1bca122-3650-11e7-83f6-42010a840180_b89a0cd9

and with some items it cannot create them Cannot create graph: value "State of k8s_kube-proxy.1dc32eb9_kube-proxy-gke-zabbix-test-default-pool-d2963b18-l63q_kube-system_cb6d4d0528f97c31a8e3c883bfdc0994_cda8690c container" is too long.

Can be modified to capture the friendly name (as kubectl get pods)

Thanks

[jangaraj]

k8s_nginx.eb9a4879_nginx-701339712-8rcxq_default_e1bca122-3650-11e7-83f6-42010a840180_b89a0cd9 is a friendly name of container; full not friendly id of that container can be for example 9ad36fe0c6d7b60f979082e51ce1b110eb683fef13077003e34e24ff90813620.

Note: container != pod. A pod is a group of one or more containers =>your request is not a correct. You need a Kubernetes monitoring, not a container monitoring.

Kubernetes monitoring is not implemented in https://github.com/monitoringartist/zabbix-docker-monitoring (module used by Dockbix agent). I'm happy to review your pull request - you will need to implement Kubernetes API communication (to get info about pods, services, nodes, ...) and then existing Docker monitoring can be used for low-level container monitoring.

That Kubernetes monitoring is not in my short term TODO, so I'm closing this issue. But as I said - I'm happy to review/merge if someone will create pull request.

[xarly]

Thanks for answer and for so awesome job. Then this agent is not fully useful to monitoring kubernetes containers since zabbix is not able to read names so long, or I am missing something?

I thought it was implemented because in repo description says "Docker/Kubernetes/Mesos/Marathon/Chronos/LXC/LXD/Swarm container monitoring", well maybe it can agent can read metrics but zabbix cannot parse those names...

Thanks

[jangaraj]

Docker/Kubernetes/Mesos/Marathon/Chronos/LXC/LXD/Swarm container monitoring is right title. You just have to deal with technology limitations - in this case maximum lenght of Zabbix item. Nobody is stopping you to write your own LLD discovery, which will connect to Kubernetes/Docker API and then it will create Zabbix items with nice human readable names. These items will use existing CPU/MEM/... metrics available from my current Zabbix docker module. Another options can be to set env variable per each container (!=pod) and then use them as a ID in discovery, for example: env variable HNAME and LLD discovery key: docker.discovery[Config,Env,HNAME=]. Everything depends on your skill/available time/budget.