We can start by examining the existing scripts. Navigate to Administration | Scripts:

The same three scripts we saw in the menu can be seen here. Let's see what they do:

These three scripts are all are executed on the Zabbix server, so they should work for any host—a server with a Zabbix agent, a switch, a storage device, and so on.

We will discuss other options in a moment, but for now let's see whether all of these scripts work. Ping should work for most people. Traceroute will require the traceroute utility installed. As for operating system detection, it is unlikely to work for you out of the box. Let's try and make that one work.

Start by making sure nmap is installed on the Zabbix server. As the script uses sudo, edit /etc/sudoers (or use visudo) and add a line like this:

zabbix  ALL=NOPASSWD: /usr/bin/nmap

Adapt the nmap path if necessary. Similar to restarting the Apache web server, you might have to uncomment the requiretty option in /etc/sudoers. Again, all of these changes have to be done on the Zabbix server. When finished, run the operating system detection script from the menu—use one of the locations mentioned earlier:

Hooray, that worked! The nmap command took some time to run. When running global scripts on the agent, they obey the same timeout as the remote commands discussed earlier in this chapter. This script was run on the server. In this case, there's a 60-second timeout in the frontend.

Now on to examining other script options, and also configuring some scripts of our own. When there's a problem on a system, it might be resource starvation. We might want to find out which processes on a system are stressing the CPU the most. Navigate back to Administration | Scripts and click on Create script. For our first script, fill in the following:

When done, click on Add. For the top command, we told it to only print the process list and do so once only. Then we grabbed the header line and the next 10 lines after it—assuming the header line starts with any amount of spaces and a string PID.

Navigate to Monitoring | Events, click on Another host in the HOST column, and choose Top CPU using processes.

You may use any other location where this context menu is available—we listed these locations earlier:

In this specific case, the systemd process is using most of the CPU. The Zabbix agent, which is running on this system, is not even in the top 10 here. Well, to be fair, on this system nothing much is happening anyway—all of the processes are reported to use no CPU at all.

Other similar diagnostic commands might show some package details, Media Access Control (MAC) addresses, or any other information easily obtained from standard utilities. Note that getting a list of processes that use the most memory is not possible with top on most operating systems or distributions— the ps command will probably have to be used. The following code might provide a useful list of the top 10 memory-using processes:

ps auxw --sort -rss | head -n 11

We are grabbing the top 11 lines here because that also includes the header.

Now let's configure another script—one that would allow us to reboot the target system. Navigate to Administration | Scripts and click on Create script. Fill in the following:

We may also test what this confirmation message would look like—click on Test confirmation:

While the Execute button is disabled right now, we can see that this would look fairly understandable. Click on Cancel in the confirmation dialog. The final result should look like this—if it does, click on the Add button at the bottom:

Now let's see what this script would look like in the menu—navigate to Monitoring | Events and click on Another host in the HOST column. In the pop-up menu, move the mouse cursor over the entry Management:

Notice how the syntax we used created a submenu—the slash is used as a separator. We could group Ping, Traceroute, and Top CPU using processes as Diagnostics, add more entries in the Management section, and create a useful toolset. Note that we can also use zabbix_get on the server here and poll individual items that we might not want to monitor constantly. Entries can be nested this way as many times as needed, but beware of creating too many levels. Such mouseover menus are hard to use beyond the first few levels, as it is too easy to make a wrong move and suddenly all submenus are closed.

Regarding the Reboot entry, if it seemed a bit risky to add, fear not—it does not work anyway. First, we had to use sudo for it in the command. Second, we had to configure sudoers to actually allow the running of that command by the zabbix user.

Some of the global scripts added this way only make sense when used interactively—most of the data gathering or diagnostic ones would probably fall under this category. But our Reboot entry might be reused in action operations, too. Instead of configuring such commands individually in global scripts and each action, we would have a single place to control how the rebooting happens. Maybe we want to change the reboot command to issue a pending reboot in 10 minutes. That way a system administrator who might be working on the system has some time to cancel the reboot and investigate the problem in more detail.

We already have the global script for rebooting created. If we had a trigger that warranted rebooting the whole system, we would create an action with appropriate conditions. In the action properties, global scripts may be reused by choosing Remote command in the Operation type dropdown when editing an operation. Then, in the Type dropdown, Global script must be selected and a specific script chosen:

As these scripts can be used both from the frontend and in actions, they're not called just frontend scripts—they are global scripts.