Yesterday I promised, or at least wrote, that I might not monitor my Qubes OS virtual machines. But, as a monitoring addict, I had to do that. As this is just boring usual Linux monitoring, let's at least use the automatic agent registration feature of Zabbix to do this.
Challenges monitoring Qubes OS
Qubes OS wants to be very secure, so by default any incoming connections are not allowed. Sure, one can poke holes in the firewall, but I don't want to defeat the purpose of Qubes OS of being secure when I eventually take my laptop to Zabbix Summit.
But, no worries as Zabbix agent has the active mode, in which it is pushing the data towards Zabbix server instead of Zabbix server polling the agent. Let's use that mode.
Creating the automatic agent registration rules
In Zabbix, I did go to Alerts --> Actions --> Autoregistration actions. Next, I did add a new action.
Let's take a closer look at that. I did add only one condition: agent metadata must contain the string WhatsupHome. In real world, you would use the metadata in more granular way to contain your server role, operating system and such details. For this demo, WhatsupHome is a good enough string.
For operations, you would have many to choose from, here's what I added: I asked Zabbix to add the new host, link it with Linux by Zabbix Agent Active template, add it to Virtual machines host group, and set the host inventory mode to automatic.
Install Zabbix agent
Next steps were simple; on my zabbixsummit Qube, I did run
dnf -y install zabbix-agentand modified the following lines of /etc/zabbix_agentd.conf file
Server=myzabbixserver
ServerActive=myzabbixserver:10051
HostMetadata=WhatsupHomeFinally just
systemctl enable zabbix-agent && systemctl start zabbix-agentDone!
Can I repeat this easily for multiple Qubes in Qubes OS?
Sure, though as in Qubes OS the master qube dom0 does not have any network access, you cannot use ssh or any other usual tools as easily for the task. Luckily, there's special set of qvm commands to help you out.
- qvm-run -u root anotherqube your_package_repository_command install zabbix-agent would install the Zabbix agent for you to a Qube called anotherqube
- qvm-copy-to-vm anotherqube /path/to/zabbix_agentd.conf would copy the /path/to/zabbix_agentd.conf file you would have on dom0 to anotherqube.
Wrap that to shell one-liner such as
for each in qube1 qube2 qube3; do qvm-run... && qvm-copy-to-vm....; doneYou get the idea. That works very well as long as you don't want to customize the Metadata part for each of your qubes to be something different. If you want to do that, look at HostMetadataItem parameter, too, as it can contain any dynamic info worth up to 64k of data.
Did it work?
Of course, here are the results moments after I started the Zabbix agent. The list goes on and on with all the usual details you'd expect Zabbix agent to return.
Could I monitor dom0 itself?
Not in traditional way. But, now that you know about the existence of qvm-copy-to-vm command, a cronjob on dom0 could very well generate some text/JSON/XML files, copy those to some qube, add that file as a new item to Zabbix, and use the master item & dependent items & low-level discovery for parsing the info. But, I did not bother. At least not yet.
This small little stunt shows the flexibility and easiness of Zabbix. Just with few clicks and few text lines one can make agents to register to Zabbix automatically, where they then are placed to correct host groups with correct templates with no additional effort needed from you.
Add new comment