Missing zabbix-sender package dependency for ceph manager zabbix module.

[laser84]

Bug Report

When I enable Ceph Manager Zabbix module with the command:
ceph mgr module enable zabbix

Sending data crash with an error:

ceph FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/zabbix_sender': '/usr/bin/zabbix_sender

Please install the zabbix-sender package dependency to the Centos 8 container, with the command:
rpm -ivh https://repo.zabbix.com/zabbix/4.4/rhel/8/x86_64/zabbix-release-4.4-1.el8.noarch.rpm && yum install -y zabbix-sender

[dsavineau]

Sorry we won't accept third party packages like this as we don't want to have all external mgr dependencies by default (like Influx).

If you want this package then you could create a new image on top on the current one. Something like

$ cat <<'EOF' > Dockerfile
FROM docker.io/ceph/ceph:v15.2
RUN yum install -y https://repo.zabbix.com/zabbix/4.4/rhel/8/x86_64/zabbix-release-4.4-1.el8.noarch.rpm && yum install -y zabbix-sender && yum clean all
EOF
$ docker build -f Dockerfile -t docker.io/ceph/ceph:v15.2.zabbix .

[jeevadotnet]

So ceph offers the ability for you to enable zabbix, but it doesn't include the tools in the container for you to send data to the zabbix server. What a backwards storage system.

Why not just completely remove zabbix & the zabbix docs from ceph then...

[izzy]

Just came across this, can only agree with @jeevadotnet here. Why would you even give people an option that seems to be standard when it's not intended to work without additional non-standard configuration? Not to mention that the recommended "solution" here - a Dockerfile - is neither update-friendly nor the full solution - how do I integrate that? How do I make sure this survives a pool upgrade?

And most importantly: Why is all of this this not mentioned in the ceph docs, even in latest, but instead it still just says "oh sure, install those packages with apt or dnf" when the recommended installation is with cephadm as orchestrator? Like seriously, where is the advantage of containers when I then have to go out of my way and possibly break things just to make basic things like monitoring work?

But here we are, Issue is closed without an actual solution, which means parts of ceph are broken for some of us, meanwhile grafana, etc. are treated like first class citizens.

[andral]

Just came across this, can only agree with @jeevadotnet here. Why would you even give people an option that seems to be standard when it's not intended to work without additional non-standard configuration? Not to mention that the recommended "solution" here - a Dockerfile - is neither update-friendly nor the full solution - how do I integrate that? How do I make sure this survives a pool upgrade?

And most importantly: Why is all of this this not mentioned in the ceph docs, even in latest, but instead it still just says "oh sure, install those packages with apt or dnf" when the recommended installation is with cephadm as orchestrator? Like seriously, where is the advantage of containers when I then have to go out of my way and possibly break things just to make basic things like monitoring work?

But here we are, Issue is closed without an actual solution, which means parts of ceph are broken for some of us, meanwhile grafana, etc. are treated like first class citizens.

If I didn't already have a github account, I would have created one just to like your comment.
We ran across this today as well after we containerized our deployments and noticed that the zabbix monitoring is no longer working.
Very frustrating indeed! I asked the same question, why go containers when it's just more work in the end for the customer...

An ugly workaround for the time being:
create a cronjob that copies the binary into the container
podman cp /bin/zabbix_sender ceph-mgr-$(hostname -s):/bin/zabbix_sender

[izzy]

For those who still want to monitor using Zabbix, my coworker found that "Ceph by Zabbix agent 2" works pretty well with the provided capabilities that a cluster orchestrated with cephadm brings. It's REST API based pull instead of push, so all you need is the restful module enabled and a user configured for that, it has discovery, etc. so seems like a pretty solid alternative, especially given that it doesn't need any janky container changes that may or may not survive the next update.

[jeevadotnet]

@izzy @andral , I use Ceph By Zabbix Agent 2 as well for my monitoring after i couldn't find a solution that doesn't require the container to be butchered 📦

[guits]

So ceph offers the ability for you to enable zabbix, but it doesn't include the tools in the container for you to send data to the zabbix server. What a backwards storage system.

Why not just completely remove zabbix & the zabbix docs from ceph then...

This is the same with non-containerized deployments.
ie: with non-containerized deployment, if you don't configure the zabbix repository and install the zabbix_sender package, it won't work. You have to do additional manual operations.

For security and maintenance reasons, it definitely makes sense to not include third-party packages.

And most importantly: Why is all of this this not mentioned in the ceph docs, even in latest, but instead it still just says "oh sure, install those packages with apt or dnf" when the recommended installation is with cephadm as orchestrator?

Yes, I can agree with you on that, the documentation might be outdated and/or lacks details. That being said, Ceph is an open-source project, PRs are welcome 🙂