Linux

Definitely a nice idea! Supporting systemd items natively will allow us to monitor 'services' on Linux almost the same way as we do on windows.
I.e., running state, description, etc.

root@localhost:~# service cron status

• cron.service - Regular background program processing daemon
  Loaded: loaded (/lib/systemd/system/cron.service; enabled)
  Active: active (running) since Tue 2015-07-21 09:44:33 CEST; 2 days ago
  Docs: man:cron(8)
  Main PID: 490 (cron)
  CGroup: /system.slice/cron.service
  ├─ 490 /usr/sbin/cron -f
  └─30342 /usr/bin/atop -a -w /var/log/atop/atop_20150723 600

Jul 23 14:17:01 localhost CRON[687]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 23 14:17:01 localhost CRON[688]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 23 14:17:01 localhost CRON[687]: pam_unix(cron:session): session closed for user root
Jul 23 14:30:01 localhost CRON[690]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Jul 23 14:39:01 localhost CRON[710]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 23 14:39:01 localhost CRON[711]: (root) CMD ( [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
Jul 23 14:45:01 localhost CRON[733]: pam_unix(cron:session): session opened for user www-data by (uid=0)

If done in the right way, this might enable the use of the service.discovery, service.info[service,<param>] and services[<type>,<state>,<exclude>] items on Linux

Is there any movement on this request? 90% of my systems are running CentOS 7.2 (with systemd) and having the ability to monitor systemd service status would be very beneficial.
Currently relying on proc.num[<service>] only indicates that the process is running and not guaranteed to be in a working state.

Michael, you may use some custom config like mine:

# checks to determine if specified unit is active, failed or enabled
UserParameter=systemd.unit.is-active[*],systemctl is-active --quiet '$1' && echo 1 || echo 0
UserParameter=systemd.unit.is-failed[*],systemctl is-failed --quiet '$1' && echo 1 || echo 0
UserParameter=systemd.unit.is-enabled[*],systemctl is-enabled --quiet '$1' && echo 1 || echo 0

It will create these checks:

systemd.unit.is-active[<unit name>]  # 1 if unit is active, 0 if inactive
systemd.unit.is-failed[<unit name>]  # 1 if unit if in failed state, 0 if not
systemd.unit.is-enabled[<unit name>] # 1 if unit is enabled, 0 if not

Hi Anton,

I'm running a check much the same;

UserParameter=custom.service.check[*],if systemctl status $1 | grep running >> /dev/null; then echo 0; else echo 1; fi;

But I think I will add in your checks as they are a little more conclusive, plus I like the shorthand if statements.

I've ran into lots of selinux issues with this, will the zabbix selinux policy eventually allow systemctl access? How did you combat the selinux denials?

The nuisance is I've created a custom policy to allow specific services to be monitored, in the event I want to monitor something new I have to create additional policies, very annoying.

-----------------------------
You may find this helpful when setting up new hosts, I like to check everything is in order before I add them to my zabbix templates; note I swapped the outputs from the checks, 0 is a postitive result 1 is something negative.

#!/bin/bash

checks=(is-active is-failed is-enabled);
services=(firewalld postfix ntpd crond sshd fail2ban);

if [ -z "$1" ]; then
	echo "enter host address";
	read host;
else
	host=$1;
fi

echo -e "checking host $host\n";

for service in "${services[@]}"; do
	echo "$service:";
	for check in "${checks[@]}"; do
		echo -en "\t$check:";
		test=`zabbix_get -s $host -k "systemd.unit.$check[$service]"`
		if [ "$test" = 0 ]; then
			echo -e "\t$test - success";
		else
			echo -e "\t$test - failed";
		fi
	done
	echo "";
done

I've created a loadable module to query systemd directly, via the D-Bus API. Aims to be be comprehensive as well as offering zabbix-friendly wrappers such as systemd.service.info.

https://github.com/cavaliercoder/zabbix-module-systemd

I'll create installation packages soon, but please take a look and file issues on GitHub if it doesn't work for you

This is great! Is it usable with Zabbix 3.0?

All Zabbix versions with loadable module option are supported - that's Zabbix 2.2+

Compiled and running in agent. For those who have to deal with the yum repository that doesn't have *-devel packages (there's an issue here for that too, I voted it up: ZBXNEXT-2182) here's the steps. I assume a x64 server. (Who the netherworld uses a 32 bit server these days anyway?) Otherwise you can lose the --libdir switch in the ./configure command line. @Ryan, maybe you'd want to include these in your README?

• Download the exact version of the Zabbix sources that correspond to your running version. Mine is 3.0.9, I put it under /root/src
• yum groupinstall "Development Tools"
• yum install dbus-devel libtool gettext autoconf automake
• ./autogen.sh
• ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib64 --with-zabbix=/root/src/zabbix-3.0.9
• make && make install
• service zabbix-agent restart
• pidof zabbix_agentd

That's it. Now I'm going to import the template in Zabbix and see if this actually works. Be right back.

In order to import the template in 3.0 I had to edit the version tag to 3.0 and remove an empty <httptests /> tag. Waiting for auto-discovery of items now. Should work like filesystems do, yes?

Juan: https://github.com/cavaliercoder/zabbix-module-systemd is 3rd party project, so this Jira is not a right place for issue reporting of that module. Please use Github issue tracker. Feel free to create pull request if you think that README should be improved.

That template is only example template and yes it was made for 3.2. Ryan has released https://github.com/cavaliercoder/zabbix-template-converter. Try to use it and convert that template to your 3.0 version.

Hola Juan Carlos,

Funciono en Zabbix 3.0 ?

Gracias por tu respuesta.

Saludos Pablo