Hi there, @speculatrix,
Of course, zabbix users want to have monitor on one place, as much as possible.
Here are some basic checking for zabbix according to manual: https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/zabbix_agent (part of proc.num, i.e. checking if process is active, at least one for each monitored instance)
Creating several Items.
For nginx :
key: proc.num[nginx,,all]
For postgres:
key: proc.num[postgres,gitlab-psql,all]
For redis-server:
key: proc.num[redis-server,,all]
Triggers for nginx:
Problem expression
{gitlab:proc.num[nginx,,all].last(0)}<1
Recovery:
{gitlab:proc.num[nginx,,all].last(0)}>0
And triggers respectively for postgres and redis-server:
{gitlab:proc.num[postgres,gitlab-psql,all].last(0)}<1
{gitlab:proc.num[redis-server,,all].last(0)}<1
(on the same manner putting recovery triggers).
I’ve put a checking within a “Web scenario” (web checks, define URL and expected text on the page)
and trigger like:
{gitlab:web.test.fail[Availability of Gitlab].sum(#3)}>0
These are just a basic monitoring fields, certainly this can be better. I couldn’t find the proper way to check unicorn process. The name is not just a unicorn , not catching the process even with combinations visible on linux typical commands like ps aux | grep unicorn
However, I hope someone might find this useful.