Sometimes we are not interested in the exact details of every service, and we might have to configure an item and trigger for each of them manually. Instead, we might want to see a high-level overview; for example, whether any of the services that are started automatically have stopped. Zabbix provides an item that allows you to make such a comparison very easily: services. It allows us to retrieve lists of services based on different parameters, including ones that should be started automatically and are stopped. How can we use this?

An item should be added with the following key:

services[automatic,stopped]

This will take care of getting the required data. Whenever a service that is set to start automatically is stopped, it will be listed in the data from this item.

It is also possible that on some Windows versions there will be services that are supposed to start up automatically and shut down later. In this case, they would appear in the listing and break our monitoring. Luckily, Zabbix has a solution for such a problem, too—we can add third parameter to this key and list services to be excluded from this check. For example, to exclude the RemoteRegistry and sppsvc services, the key would be:

services[automatic,stopped,"RemoteRegistry,sppsvc"]

Notice how the services to be excluded are comma-delimited, and the whole list is included in double quotes.

But how do we check that everything is good in a trigger? If the list is empty, the Zabbix agent returns 0. As a result, by simply checking whether the last value was zero, we can trigger when an automatically started service is stopped. A trigger expression for such a check would be:

{Windows host:services[automatic,stopped].last()}<>0

Of course, you can apply a method—such as using the count() function—to only fire the trigger after it has been non-zero for more than a single check:

{Windows host:services[automatic,stopped].count(#3,0)}=0

Such a trigger expression will only fire if there has been at least one such stopped service in all of the last three checks.

The preceding method just tells you that some service that was supposed to be running has stopped. To see which service that is, we'd have to look at the item values. We can actually monitor all services individually, as Zabbix has supports Windows service discovery since version 3.0. Let's discover all Windows services and monitor some parameter on all of them—we can choose the service description here.

Navigate to Configuration | Hosts, click on Discovery next to Windows host, and click on Create discovery rule. Fill in the following:

We used a built-in agent key and increased the update interval. In production, it is probably a good idea to increase the interval even more; an average default interval for discovery rules of one hour is likely a good idea. When done, click on the Add button at the bottom. We have the rule itself; now we need some prototypes—click on Item prototypes, then click on Create item prototype. Before we fill in the data, it would be useful to know what this discovery item returns—an example for one service is as follows:

{
    "{#SERVICE.STARTUP}" : 0,
    "{#SERVICE.DISPLAYNAME}" : "Zabbix Agent",
    "{#SERVICE.DESCRIPTION}" : "Provides system monitoring",
    "{#SERVICE.STATENAME}" : "running",
    "{#SERVICE.STARTUPNAME}" : "automatic",
    "{#SERVICE.USER}" : "LocalSystem",
    "{#SERVICE.PATH}" : ""C:\zabbix\zabbix_agentd.exe" --config "c:\zabbix\zabbix_agentd.win.conf"",
    "{#SERVICE.STATE}" : 0,
    "{#SERVICE.NAME}" : "Zabbix Agent"
}

This snippet also shows what other things we could monitor for each service. For now, we want to extract descriptions for all services, but to add the items we need the actual service names. Although the description is available here, we will query it in the item, so for item prototypes it will actually be the macro {#SERVICE.NAME}. With this knowledge, we are ready to fill in the item prototype form:

When done, click on the Add button at the bottom. With our discovery running every five minutes, it might take up to five minutes for this prototype to generate actual items, and then it would take up to six minutes for these items to get their first value—the added time of configuration cache update and item interval. First, go to item configuration for the Windows host. After a while, our discovery rule should add the items:

There will likely be a fairly large number of such items. Visiting Monitoring | Latest data, after a few more minutes we should see descriptions for all services:

A more common approach would be to monitor the current service state or its startup configuration—anything the service.info key supports should be possible.