- Nagios Core Administrators Cookbook
- Tom Ryder
- 744字
- 2021-08-05 18:11:58
Customizing an existing command
In this recipe, we'll customize an existing command definition. There are a number of reasons why you might want to do this, but a common one is if a check is "overzealous", sending notifications for WARNING
or CRITICAL
states, which aren't actually terribly worrisome. It can also be useful if a check is too "forgiving" and doesn't detect actual problems with hosts or services.
Another reason is to account for peculiarities in your own network. For example, if you run HTTP daemons on a large number of hosts on the alternative port 8080
that you need to check, it would be convenient to have a check_http_altport
command available. We can do this by copying and altering the definition for the vanilla check_http
command.
Getting ready
You should have a Nagios Core 3.0 or newer server running with a few hosts and services configured already. You should also already be familiar with the relationship between services, commands, and plugins.
How to do it...
We can customize an existing command definition as follows:
- Change to the directory containing the objects configuration for Nagios Core. The default location is
/usr/local/nagios/etc/objects
:# cd /usr/local/nagios/etc/objects
- Edit the
commands.cfg
file, or any file which is at an appropriate location for thecheck_http
command:# vi commands.cfg
- Find the definition for the
check_http
command. In a default Nagios Core configuration, it should look similar to the following:# 'check_http' command_definition define command { command_name check_http command_line $USER1$/check_http -H $HOSTADDRESS$ $ARG1$ }
- Copy this definition into a new definition directly below it and alter it to look similar to the following code snippet, renaming the command and adding a new option to its command line:
# 'check_http_altport' command_definition define command { command_name check_http_altport command_line $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$ }
- Validate the configuration and restart the Nagios Core server:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg # /etc/init.d/nagios restart
If the validation passed and the server restarted successfully, we should now be able to use the check_http_altport
command, which is based on the original check_http
command, in a service definition.
How it works...
The configuration we added to the commands.cfg
file reproduces the command definition for check_http
, but changes it in two ways:
- It renames the command from
check_http
tocheck_http_alt
, which is necessary to distinguish the commands from one another. Command names in Nagios Core, just like host names, must be unique. - It adds the option
-p 8080
to the command-line call, specifying the time when the call tocheck_http
is made. The check will be made using TCP port8080
, rather than the default value for TCP port80
.
The check_http_alt
command can now be used as a check command in the same way as a check_http
command. For example, a service definition that checks whether the sparta.naginet
host is running an HTTP daemon on port 8080
might look similar to the following code snippet:
define service { use generic-service host_name sparta.naginet service_description HTTP_8080 check_command check_http_alt }
There's more...
This recipe's title implies that we should customize the existing commands by editing them in place, and indeed, this works fine if we really do want to do things this way. Instead of copying the command definition, we could just add the -p 8080
or another customization to the command line and change the original command.
However, this is bad practice in most cases, mostly because it could break the existing monitoring and be potentially confusing to other administrators of the Nagios Core server. If we have a special case for monitoring—in this case, checking a non-standard port for HTTP—then it's wise to create a whole new command based on the existing one with the customizations we need.
There is no limit to the number of commands you can define, so you can be very liberal in defining as many alternative commands as you need. It's a good idea to give them instructive names that say something about what they do, as well as to add explanatory comments to the configuration file. You can add a comment to the file by prefixing it with a #
character:
# # 'check_http_altport' command_definition. This is to keep track of # servers that have panels running on alternative ports. # define command { command_name check_http_altport command_line $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$ }
See also
- The Creating a new command recipe in this chapter
- The Creating a new service recipe in Chapter 1, Understanding Hosts, Services, and Contacts
- PyTorch深度學習實戰:從新手小白到數據科學家
- 算法競賽入門經典:習題與解答
- Learning Spring Boot
- Hadoop與大數據挖掘(第2版)
- 數據庫開發實踐案例
- Oracle高性能自動化運維
- 軟件成本度量國家標準實施指南:理論、方法與實踐
- OracleDBA實戰攻略:運維管理、診斷優化、高可用與最佳實踐
- 一個64位操作系統的設計與實現
- Proxmox VE超融合集群實踐真傳
- Hadoop大數據開發案例教程與項目實戰(在線實驗+在線自測)
- Power BI智能數據分析與可視化從入門到精通
- Oracle高性能SQL引擎剖析:SQL優化與調優機制詳解
- 數據庫查詢優化器的藝術:原理解析與SQL性能優化
- MySQL數據庫實用教程