While the things we learned about using Zabbix agents, creating items and yes, even user parameters are useful, there are some things that are specific to Windows system monitoring which we will look at now. For this section you will need a Windows machine that is accessible from the Zabbix server.
Installing Zabbix agent for Windows
To install the agent, it first has to be obtained. On Windows, compiling software is less common and most users get binary distributions, which is exactly what we will do now.
The Windows build of the Zabbix agent can be obtained from two official locations—either from the download page at http://www.zabbix.com/download.php, or from the source archive. This time it is suggested to use the one included inside the archive to make sure the versions match.The agent executable is located in the subdirectory bin/win32 or bin/win64—choose the one that is appropriate for your architecture and place it on some directory in the Windows machine.For simplicity, we'll use C:\zabbix this time, but you are free to use any other directory. We will also need the configuration file, so grab the example provided at misc/conf/zabbix_agentd.win.conf and place it in the same directory. Before we continue with the agent itself let's figure out whether we need to alter the configuration in any way.Open C:\zabbix_agentd.win.conf in your favorite text editor and look for any parameters we might want to change. Firstly, the log file location isn't quite optimal—it's set to c:\zabbix_agentd.log, so let's change it to read:
We have already learned that the server line, which currently reads Server=127.0.0.1, will have to be changed. Replace the 127.0.0.1 part with the IP address of your Zabbix server. As this is not a Zabbix server, replace the Hostname directive to read:
Now let's try to start the agent up. Execute:
C:\zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf
While the agent daemon does start up, it doesn't like being started like that and prints a warning:
!!!ATTENTION!!! ZABBIX Agent started as a console application.
So what can we do to make it happier? First stop it by pressing Ctrl+C.The agent daemon executable on windows has additional options that can be passed to it, so execute in the command prompt (when located in the directory where zabbix_agentd.exe resides):
While the start of the output does not differ notably, we can see several additional parameters at the end of the help.
ZABBIX Agent Win32 (service) v1.8.1 (revision 9692) (27 January 2010)
usage: zabbix_agentd.exe [-Vhp] [-idsx] [-m] [-c <file>] [-t <metric>]
-c --config <file> Specify configuration file. Use absolute path
-h --help give this help
-V --version display version number
-p --print print supported metrics and exit
-t --test <metric> test specified metric and exit
Note that -t and -p switches do not work with user parameters. Use
-i --install install Zabbix agent as service
-d --uninstall uninstall Zabbix agent from service
-s --start start Zabbix agent service
-x --stop stop Zabbix agent service
-m --multiple-agents service name will include hostname
The Zabbix agent daemon for Windows includes functionality to install it as a standard Windows service, which is controlled by the last set of options. Unless you are simply doing some testing, you'll want to properly install it, so let's do that now.
C:\zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf -i
The Zabbix agent daemon is installed as a Windows service using the configuration file, specified by the -c flag.
zabbix_agentd.exe : Service "ZABBIX Agent" installed
zabbix_agentd.exe : Event source "ZABBIX Agent" installed
You can verify in the Windows Control Panel, Services section, that the Zabbix service has indeed been installed:
While it has been set to start up automatically, it is stopped now. We can start it by either right clicking the Zabbix Agent service entry and choosing Start, or by using command line switch to zabbix_agentd.exe. Let's try the latter method now:
C:\zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf -s
Supposedly service was started successfully.
zabbix_agentd.exe : Service "ZABBIX Agent" started successfully.
Again, let's verify in the services list that the Zabbix service has started up:
It looks like everything is fine on the monitored host, which we will now have to configure in the frontend. Open Configuration | Hosts, and click Create Host, then fill in the following values:
- Name: Enter Windows box.
- Groups: Select Windows servers in the Other Groups box, then click on the < < button. If there's any other group in the In Groups box, remove it.
- IP address: Enter the IP address of that host.
When you are done, click Save. Now select Windows servers in the Group dropdown and click on Items next to the Windows box, then click Create Item. Enter these values:
- Description: Enter CPU Load
- Key: Enter system.cpu.load
- Type of information: Select Numeric(float)
- Update interval: Enter 60
- Keep history: Enter 7
When you are done, click Save. We can now check out incoming data at Monitoring|Latest data—select Windows servers in the Group dropdown.
We have now successfully retrieved data on the CPU load for this Windows machine. Notice how the key syntax is the same as for Linux. This is true for several other keys, and you can check out the Zabbix documentation to determine which keys are supported on which platform.
Querying performance counters
While many keys match between platforms, there's a whole category that is specific to Windows. Zabbix supports Windows' built-in metrics gathering system, performance counters. People who are familiar with Windows probably know that these can be found at Control Panel | Administrative Tools | Performance, with a lot of counters to add. In this window, we can click on the + icon in the child toolbar, or press Ctrl+I to see available counters.
In this dialog, we can gather the information required to construct performance counter string. First, the string has to start with a backslash, \. The Performance object follows, in this case, Processor. Then we have to include the desired instance in parenthesis, which would make our string so far \Processor(_Total) (notice the leading underscore before Total). The counter string is fi nished by adding individual counter string from the Select counters from list list box, again separated by a backslash. So the fi nal performance counter string looks like this:
\Processor(_Total)\% Idle Time
Now that we have constructed it, what do we do with it? Create an item, of course. Back in the frontend, navigate to Configuration | Hosts, click on Items next to the Windows box and click Create Item. Fill in these values:
- Description: Enter CPU idle time, %
- Key: This is where things get more interesting, although the principle is quite simple—the perf_counter key has to be used with the performance counter string like the one we constructed before as a parameter, thus enter perf_counter[\Processor(_Total)\% Idle Time] here
- Type of information: Select Numeric (float)
- Update interval: Enter 60
- Keep history: Enter 7
When you are done, click Save. This item should show us the total time all CPUs spend idling on the machine, so let's look at Monitoring | Latest data with Windows box selected in the Host dropdown. We can see that the data is directly fetched from the built-in performance counter.
Looking at the list of available performance objects and corresponding counters, we can see many different metrics. Navigating this window is cumbersome at best, thanks to small widgets, no fi ltering or searching capabilities, and the fact that constructing the required string to be used as key is a manual typing job as entries can't be copied. Luckily there's a solution available on recent versions of Windows—the command line utility typeperf.exe. To see how it can help us, execute:
C:\zabbix>typeperf -qx > performance_counters.txt
This will direct all output of this command to be saved in the file performance_counters.txt. Open that file with a text editor and observe the contents. You'll see lots and lots of performance counter strings, covering various software and hardware information. There is no need to struggle with that clumsy dialog any more, we can easily search for and copy these strings
Using numeric references to performance counters
If you have a localized Windows installation, you have probably noticed by now that all performance counters are in the localized language, not in English. This becomes especially cumbersome to handle if you have to monitor several Windows machines with different locales confi gured for them. For example, a counter that on an English Windows installation is \System\Processes, would be \Système\Processes in a French one. Would it be possible to use some other, more universal method to refer to the performance counters? Indeed it is, we can use numeric references, but fi rst we have to find out what they are.
Launch regedit and look for the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows NT\CurrentVersion\Perflib. Under this key you'll see one or more entries, with one being 009, which is entry for the English language. Select this entry and pay attention to the Counter key, which has suspiciously similar contents to performance counter names.
Double click this value to see its contents in a somewhat more manageable form:
So each performance counter string can be translated to a number. But fi guring out exact conversion in this tiny window is awfully hard, so let's copy all contents and save them to some fi le, which we'll be able to search then—name it numeric.txt. To see how this works, let's translate performance counter string we used before—\Processor(_Total)\% Idle Time.
First we have to translate the performance object, Processor. While it is possible to search these contents in any text editor, it soon becomes cumbersome, especially if we have to translate lots of values. In that case we can turn to the basic GNU tools like grep, which you might have installed on the Windows machine—if not, copy this file over to the Zabbix server:
$ grep -B 1 "^Processor$" numeric.txt
This command will search for a line containing the string Processor exactly and will also output the line immediately before it, which contains the numeric ID of this performance object.
If you are using grep on the Zabbix server, saved file might contain Windows style newlines and you might get no output. In that case, convert newlines by executing:
$ sed -i 's/\r//' numeric.txt
Now that we have the numeric value for the first part, do the same for the second part of the performance counter.
$ grep -B 1 "^% Idle Time$" numeric.txt
% Idle Time
We now have numeric values for all parts of the performance counter except the _Total—how can we translate that? We don't have to, this string is used as is on all locales. Our resulting performance counter would then look like this:
As we already have an item gathering this information, we won't add another one. Instead let's test with the zabbix_get utility. On the Zabbix server, execute:
$ zabbix_get -s <Windows box IP> -k "perf_counter[\238(_Total)\1482]"
This should return the same data as \Processor(_Total)\% Idle Time key does.
Using aliases for performance counters
Another method to unify item keys that are using Zabbix configuration (so that a single template could be used for all hosts) is to specify performance counter aliases. To do that, add Alias directive to Zabbix agent configuration file. For example, if we wanted to refer to the performance counter we used, \Processor(_Total)\% Idle Time, as cpu.idle_time, we would add the following:
Alias = cpu.idle_time:perf_counter[\Processor(_Total)\% Idle Time]
Systems with another locale alias would use a different performance counter, but from now on we can use the same item key for all systems—cpu.idle_time.
Monitoring Windows services
Performance counters are a Windows-specific metric category, and there's another one as well—a dedicated key for Windows service state monitoring. Let's try to monitor some service now. First we have to figure out how to refer to this service. For that, open the services list and then open up the details of some service—let's choose DNS Client.
Look at the top of this tab. Service name is the name we will have to use, and we can see that it differs notably from the display name—instead of using DNS Client, the name is Dnscache. Let's create item now—navigate to Configuration | Hosts, click on Items next to the Windows box, then click Create Item. Enter these values:
- Description: Enter DNS client service state
- Key: Key service_state allows access to information about system services, thus enter service_state[Dnscache] here
- Update interval: Enter 60
- Keep history: Enter 7
When you are done, click Save. open Monitoring | Latest data, and look for our newly added item.
So data is gathered, and the state is "0". That's probably normal, but how could we know what the state number means? Back in Configuration | Hosts, select Items in the first dropdown and click on DNS client service state in the Description column. Look at our old friend, the Show value throw map property. Click on the throw map link and examine the mapping with most entries.
It turns out, there's already a predefined mapping for Windows service states available. Close this window and choose Windows service state in the Show value throw map dropdown, then click Save. Back at Monitoring | Latest data, verify that service state is now displayed in a much more user friendly way:
Now we will be able to easily identify different service states in the frontend.
Checking whether an automatic service has stopped
Sometimes we are not interested in exact details about every service, and we would have to confi gure 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. Since version 1.8.1, Zabbix provides an item that allows 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:
This will take care of getting the needed data. Whenever a service that is set to start automatically is stopped, it will be listed in the data from this item. But how do we check for that in a trigger? If the list is empty, the Zabbix agent returns 0. As a result, by simply checking whether last value was zero we can trigger whenever an automatically started service is stopped. A trigger expression for such a check would be:
Of course, you can apply some method to only fire the trigger after it has been non-zero for more than a single check.
Such a trigger expression will only fire if there has been at least one such stopped service in all of the last three checks.
We learned the specifics of monitoring Windows machines, like setting up a Zabbix agent on Windows as a system service and querying Windows-specific values. We also learnt about built-in performance counters and system service states. Coupled with the generic monitoring and reporting knowledge we have by now, this should allow to efficiently monitor Windows installations as well.
If you have read this article you may be interested to view :