Nagios-核心管理秘籍-全-

Nagios 核心管理秘籍（全）

原文：annas-archive.org/md5/2a65ba8acd5ecd8eabef27310d48a8a3

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Nagios Core，作为 Nagios 监控框架的开源版本，是托管在类似 Unix 系统上的网络监控行业标准，如 GNU/Linux 或 BSD。它通常被网络和系统管理员用于检查主机之间的连接性，并确保网络服务按预期运行。

许多自家编写的脚本执行网络检查时，可能会迅速变得无法维护，而且对新手管理员来说，定制起来也不安全。而 Nagios Core 提供了一个严格且可配置的监控框架，以一致的方式进行检查，并向适当的人员和系统发送通知，告知它检测到的任何问题。

这使得 Nagios Core 成为一个非常通用的监控框架，而不是一个开箱即用的监控解决方案，这也让它在初学者中显得有些不友好，即便是经验丰富的管理员，也会觉得它有点像一个“黑盒子”。繁忙的管理员在设置 Nagios Core 系统时，通常会将其配置为每隔几分钟向一组主机发送 PING 请求，并在出现任何问题时发送电子邮件通知，而其他部分则不再处理。对于那些刚接触该系统的冒险型管理员，他们可能会设置一些 HTTP 检查，确保公司网站响应正常。

Nagios Core 的功能远不止这些，本书的食谱旨在强调精细化和控制 Nagios Core 检查、通知和报告的各种方法，而不仅仅是列出使用特定插件的指令，网上有成百上千个插件可以在 Nagios Exchange 平台上找到，网址为exchange.nagios.org/。本书的根本目标是让管理员对 Nagios Core 的潜力产生兴趣，超越基础的默认检查行为，从而能够利用更多框架的功能，使其成为网络监控的核心。

这还包括安装甚至编写自定义插件，超出标准的 Nagios 插件集，编写和优化自己的检查，使用非常强大的简单网络管理协议（SNMP），记录和报告性能数据，优化通知行为，仅在适当的时间将适当的通知发送给适当的人或系统，基本的可视化选项，识别网络路径中的故障，巧妙使用默认的 Web 界面，甚至通过其他开源程序扩展 Nagios Core，所有这些都是为了检查几乎任何类型的主机属性或网络服务，适用于任何网络。

在可能的情况下，本书着重介绍由 Nagios 团队自己编写的插件，特别是 NRPE 和 NSCA。它省略了对流行的 NRPE 替代品check_mk以及 Nagios Core 的流行分支（如 Icinga）的讨论。为了深入理解高级 Nagios Core 配置，书中也未讨论任何配置前端或向导工具，如 NConf。最后，作为一本聚焦于免费可用的 Nagios Core 的 Packt 开源系列书籍，它也没有直接讨论 Nagios XI 的使用——这是 Nagios 团队支持的商业版软件。这样做是为了深入理解 Nagios Core 本身，而不是反映作者的个人观点；有兴趣的管理员应当研究所有这些项目（特别是check_mk）。

本书内容概述

第一章，理解主机、服务和联系人，解释了 Nagios Core 配置的基本构建块及其相互关系，并讨论了如何与每个构建块一起使用组。

第二章，使用命令和插件，解释了插件和命令的架构，包括安装新插件、定义现有插件的自定义使用，并通过用 Perl 编写新插件的过程进行讲解。

第三章，使用检查和状态，解释了 Nagios Core 如何执行检查以及如何自定义此行为，包括为主机和服务安排停机时间，以及管理那些一直上下波动的主机或服务的“波动”问题。

第四章，配置通知，解释了 Nagios Core 如何根据什么标准通知，何时通知以及通知给谁，包括实施自定义通知方法、对在一定时间内未解决的通知进行升级以及调度联系人轮换的示例。

第五章，监控方法，给出了一些标准 Nagios 插件集的使用示例，从基本的网络连接检查（如 PING 和 HTTP）到涉及 SNMP 使用的更复杂、更强大的检查。

第六章，启用远程执行，展示了如何使用 NRPE 来绕过无法直接通过网络检查系统属性的问题，并演示了更高级的check_by_ssh方法。

第七章，使用 Web 界面，展示了 Web 界面的一些不常用功能，实际控制 Nagios Core 的行为并查看高级报告，而不仅仅是查看当前状态信息。网络图的使用没有在此讨论，而是在下一章中进行介绍。

第八章，管理网络布局，解释了如何使 Nagios Core 了解您的网络的结构和功能，重点是主机和服务之间的相互依赖，以确保其正确运行，包括监控集群，并利用这些布局信息构建网络状态图，必要时可添加图标和背景。

第九章，配置管理，展示了如何在不使用前端的情况下，精简、优化并控制 Nagios Core 的配置。它专注于巧妙地使用组、模板和宏，并给出了使用模板语言m4程序化生成配置的示例。

第十章，安全性与性能，展示了如何管理简单的访问控制、调试运行时问题以及监控 Nagios Core 的性能，并演示了基本的监控冗余。

第十一章，自动化与扩展 Nagios Core，解释了如何通过命令文件将来自其他程序（包括 NSCA）的检查结果提交，从而提供有关外部进程的信息，并介绍了一些流行的插件（NDOUtils、NagVis 和 Nagiosgrapher）。

本书所需的内容

为了配合“标准”安装的 Nagios Core，本书中的配方假设已按照 nagios.sourceforge.net/docs/3_0/quickstart.html 中的 Nagios 快速入门指南，将 Nagios Core 3.0 或更高版本以及 Nagios 插件集安装在/usr/local/nagios目录下。

如果您的系统的软件包库包含您希望使用的 Nagios Core 3.0 或更高版本的包，这仍然是可能的，但所有文件的路径可能会非常不同。这在 Debian 或 Ubuntu 系统中的nagios3包上尤其常见。如果您熟悉您的打包系统所强加的安装布局差异，您仍然应该能够通过仅更改路径来跟随本书中的配方。

对于网页界面的截图，使用的是经典的 Nagios UI（白底黑字的菜单），这是从 3.0 版本起作为默认界面使用了多年，直到较新的“Exfoliation”风格（黑底白字菜单）成为了默认界面。虽然某些图形元素和样式不同，但所有文本内容和位置都相同，因此如果您已经安装了 Exfoliation 风格，就不必安装经典 UI，也能跟随本书进行操作。

如果您确实想要使用经典界面，以便您看到的内容与截图完全匹配，您可以通过在安装过程的最后一步添加以下内容来安装它：

# make install-classicui

本书是在 Nagios Core 4.0 的 alpha 版本测试期间编写的。我已经审阅了该 alpha 版本的更改日志，并且有信心所有的食谱在这个新版本的正式发布中都能正常工作。如果在 Nagios Core 4.0 发布后，您确实发现某些食谱存在问题，请参考“勘误”章节，告知出版商和作者。

本书适合谁阅读

本书面向那些熟悉通过命令行进行基本类 Unix 系统管理的系统和网络管理员。虽然本书最适合 GNU/Linux 管理员，但对于 BSD 管理员也应该适用。本书特别关注前言中提到的管理员类型：即那些熟悉使用类 Unix 系统，可能已经完成了一个基础的 Nagios Core 安装并且做了一些 PING 检查，现在希望学习如何更好地利用框架的强大功能，并深入理解其配置的管理员。

管理员应当熟悉为本书中讨论的扩展、插件和附加组件安装库依赖项。我们会尽量提到任何依赖项；然而，如何最佳安装这些依赖项将取决于系统及其软件包仓库。在几乎所有情况下，这应该仅仅是安装一些常见的库及其头文件，通常通过包管理系统进行安装。对于一些更复杂的情况，提供了 Debian 和 Ubuntu 的包名。

本书前五章中的较简单的食谱涉及到一些 Nagios Core 对象配置基础的回顾。对于刚刚安装了 Nagios Core 并完全没有相关经验的用户，建议在完成《Nagios 快速入门指南》后，从第一章《理解主机、服务和联系人》开始，因为后续章节假设读者已具备一定的知识。

约定

本书中，您将看到多种文本样式，用来区分不同类型的信息。以下是一些样式的示例，并附有它们的解释。

书中的代码词显示如下：“Nagios Core 只需要 PING 工具在其check_ping命令中需要的任何信息。”

代码块的设置方式如下：

define service {
    use                    generic-service
    host_name              sparta.naginet
    service_description    HTTP
    check_command          check_http
}

当我们希望引起您对代码块中特定部分的注意时，相关的行或项会以粗体显示：

define host {
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    max_check_attempts     3
    check_period           24x7
    check_command          check-host-alive
    contacts               nagiosadmin
 notification_interval  60
    notification_period    24x7
}

任何命令行输入或输出都会按如下格式书写：

# cd /usr/local/nagios/etc/objects
# vi sparta.naginet.cfg

新术语 和 重要词汇 会以粗体显示。您在屏幕上看到的词汇，例如菜单或对话框中的内容，会以这种方式出现在文本中：“如果服务器成功重启，网络界面应显示一个新的主机，在 Hosts 列表中，处于 PENDING 状态，等待进行检查该主机是否存活”。

读者反馈

我们始终欢迎读者的反馈。请告诉我们您对本书的看法——您喜欢什么或不喜欢什么。读者反馈对我们开发您真正能从中获益的书籍至关重要。

若要向我们发送一般反馈，只需发送电子邮件至 <feedback@packtpub.com>，并在邮件主题中提及书名。

如果您在某个领域拥有专业知识，并且有兴趣为书籍写作或贡献内容，请参阅我们的作者指南：www.packtpub.com/authors。

客户支持

现在，您已经成为一本 Packt 图书的骄傲拥有者，我们提供了一些帮助您最大化购买价值的内容。

下载示例代码

您可以从您在 www.packtpub.com 购买的账户中下载所有 Packt 图书的示例代码文件。如果您是从其他地方购买的此书，您可以访问 www.packtpub.com/support，并注册直接通过电子邮件接收文件。

勘误

尽管我们已尽一切努力确保内容的准确性，但错误难免发生。如果您在我们的书籍中发现任何错误——可能是文本或代码中的错误——我们非常感谢您将其报告给我们。通过这样做，您可以帮助其他读者避免困扰，并帮助我们改进后续版本的书籍。如果您发现任何勘误，请访问 www.packtpub.com/support 报告，选择您的书籍，点击勘误提交表格链接，并填写勘误的详细信息。经核实后，您的勘误将被接受并上传到我们的网站，或添加到该书籍的现有勘误列表中。

盗版

互联网版权材料的盗版问题在所有媒体中都是一个持续存在的问题。在 Packt，我们非常重视保护我们的版权和许可。如果您在互联网上发现任何我们作品的非法复制品（无论何种形式），请立即向我们提供该地址或网站名称，以便我们采取措施。

请通过 <copyright@packtpub.com> 与我们联系，并提供涉嫌盗版资料的链接。

感谢您的帮助，保护我们的作者，以及帮助我们继续为您提供有价值的内容。

问题

如果你在书中的任何方面遇到问题，可以通过 <questions@packtpub.com> 联系我们，我们将尽力解决。

第一章：理解主机、服务和联系人

在本章中，我们将涵盖以下内容：

创建一个新的网络主机
创建一个新的 HTTP 服务
创建一个新的电子邮件联系人
验证配置
创建一个新的主机组
创建一个新的服务组
创建一个新的联系人组
创建一个新的时间段
在组内所有主机上运行服务

引言

Nagios Core适用于监控各种主机上的服务和状态，其主要优点之一是配置可以根据需要简单或复杂。许多 Nagios Core 用户只会将该软件用作向本地网络或可能的互联网中的少数主机发送 PING 请求，并在没有收到回复时向管理员发送电子邮件或寻呼机消息。Nagios Core 能够监控比这更复杂的系统，从简单的局域网配置扩展到作为监控整个网络的基石。

然而，对于 Nagios Core 的简单和复杂配置来说，最基本的配置构建块是主机、服务和联系人。这些是即使是非常简单的网络设置的管理员最终也会编辑和可能创建的三项内容。如果你是 Nagios Core 的初学者，可能曾在这里和那里更改过主机名，或者复制过配置中的某个段落以使其按预期工作。在本章中，我们将更深入地探讨这些配置的作用。

在 Nagios Core 配置中：

主机通常对应某种计算机。这可以是通过网络访问的物理或虚拟机器，或者是监控服务器本身。然而，从概念上讲，主机可以监控任何类型的网络实体，例如 VPN 的终端。
服务通常对应于 Nagios Core 检查主机某些内容的安排，无论是像获取主机的 PING 响应这样的简单操作，还是像检查 SNMP OID 的值是否在可接受范围内这样更复杂的操作。
联系人定义了一种在我们的主机上发生事件时通知某人的方式，例如无法获得 PING 响应，或无法发送测试电子邮件消息。

在本章中，我们将添加这三项内容，并学习如何将它们的定义组合在一起，以使配置更具可读性，并以组的形式操作主机，而不必单独编辑每个主机。我们还将为通知设置一个自定义时间段，这样像我们这样的辛勤系统管理员就不会在午夜时分不必要地接到通知了！

创建一个新的网络主机

在本教程中，我们将从默认的 Nagios Core 配置开始，并为响应我们本地网络上 PING 的服务器设置一个主机定义。最终结果是，Nagios Core 在启动时将我们的新主机添加到内部表中，并会定期自动检查它（可能使用 PING）。在本示例中，我将使用我的 Nagios Core 监控服务器，域名系统（DNS）名称为olympus.naginet，并为 DNS 名称为sparta.naginet的 web 服务器添加主机定义。这一切都在我的本地网络上 – 10.128.0.0/24。

准备工作

你需要安装一个能够运行的 Nagios Core 3.0 或更高版本，并且必须有一个 Web 界面，以及安装了所有 Nagios Core 插件。如果你尚未安装 Nagios Core，应该先从快速入门指南开始：nagios.sourceforge.net/docs/3_0/quickstart.html。

我们假设 Nagios Core 启动时读取的配置文件位于/usr/local/nagios/etc/nagios.cfg，这是默认安装时的配置。将新主机定义放入配置文件的哪个位置不应该有太大影响，只要 Nagios Core 最终会读取该文件，但最好是为每个主机在单独的对象目录中创建一个文件，正如我们在这里所做的那样。你应该能在服务器上访问 shell，并使用你喜欢的编辑器编辑文本文件；我将使用vi。你需要通过su或sudo获得服务器的 root 权限。

你应该知道如何在服务器上重启 Nagios Core，以便将你即将添加的配置应用到系统中。通常不需要重启整个服务器！在类 Unix 系统中，启动/关闭脚本的常见位置是/etc/init.d/nagios，我将在这里使用这个路径。

你还应该准备好你想要监控的服务器的主机名或 IP 地址。如果可能，最好使用 IP 地址，这样即使 DNS 不可用，你的检查依然能正常工作。你不需要子网掩码之类的东西；Nagios Core 只需要 PING 工具所需要的任何信息来执行它自己的check_ping命令。

最后，你应该先测试一下；通过从 shell 中直接检查来确认你是否能够通过 PING 从 Nagios Core 服务器访问该主机，确保你的网络堆栈、路由、防火墙和子网掩码都是正确的：

tom@olympus:~$ ping 10.128.0.21
PING sparta.naginet (10.128.0.21) 56(84) bytes of data.
64 bytes from sparta.naginet (10.128.0.21): icmp_req=1 ttl=64 time=0.149 ms

如何操作...

我们可以按照以下步骤为sparta.naginet创建新的主机定义：

切换到/usr/local/nagios/etc/objects目录，并创建一个名为sparta.naginet.cfg的新文件：
```
# cd /usr/local/nagios/etc/objects
# vi sparta.naginet.cfg
```

将以下内容写入文件，并根据你自己的设置适当更改粗体部分的值：

define host {
 host_name              sparta.naginet
 alias                  sparta
 address                10.128.0.21
 max_check_attempts     3
    check_period           24x7
    check_command          check-host-alive
    contacts               nagiosadmin
    notification_interval  60
    notification_period    24x7
}

切换到/usr/local/nagios/etc目录，并编辑nagios.cfg文件：
```
# cd ..
# vi nagios.cfg
```

在文件末尾添加以下一行：

cfg_file=/usr/local/nagios/etc/objects/sparta.naginet.cfg

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

如果服务器成功重启，网页界面应显示一个全新的主机，在Hosts列表中处于PENDING状态，等待进行存活检查：

在接下来的几分钟内，它应该变为绿色，显示检查已通过，主机处于UP状态，假设检查成功：

如果测试失败，并且在三次尝试后 Nagios Core 未能从目标机器获取到 PING 响应，无论出于何种原因，那么它的界面可能会显示如下所示的截图：

它是如何工作的...

本节中我们包含的配置将主机添加到 Nagios Core 的主机列表中。它将通过发送 PING 请求定期检查该主机，查看是否收到回复，并根据 Nagios Core 网页界面中的显示更新主机的状态。我们尚未定义要检查的其他服务，也没有指定如果主机宕机应采取何种措施。不过，Nagios Core 将定期自动检查该主机，并且我们可以随时在网页界面中查看其状态。

我们在前面的配置中定义的指令如下所示：

host_name：此项定义了机器的主机名，Nagios Core 在内部用来引用该主机。它将在配置的其他部分中使用。
alias：此项定义了一个更易于识别的、可读性强的主机名称，显示在网页界面中。它还可以用于为主机提供一个完整的文本描述。
address：此项定义了机器的 IP 地址。这是 Nagios Core 用来联系服务器的实际值；一般来说，使用 IP 地址而非 DNS 名称是最佳实践，因为即使 DNS 无法正常工作，检查仍然能够继续进行。
max_check_attempts：此项定义了如果检查失败，Nagios Core 应重试的次数。在此，我们定义了3次，这意味着如果主机首次被发现宕机，Nagios Core 将在接下来的两次尝试中再次 PING 目标主机。
check_period：此项引用了应检查主机的时间段。24x7是 Nagios Core 默认配置中定义的时间段。这个值对于主机来说是合理的，因为它意味着主机将始终被检查。这项设置定义了 Nagios Core 检查主机的频率，而非通知频率。
check_command：此项引用了将用于检查主机是否处于UP、DOWN或UNREACHABLE状态的命令。在本例中，QuickStart Nagios Core 配置将check-host-alive定义为 PING 检查，这对于测试基本的网络连接性是一个很好的方法，且是大多数主机的合理默认配置。实际上，这个指令对于创建有效的主机并非必需，但在大多数情况下你仍然需要包含它；没有它，检查将不会执行。
contacts：这指的是将收到主机状态变化通知的联系人。在这个例子中，我们使用了nagiosadmin，它在 QuickStart 的 Nagios Core 配置中有定义。
notification_interval：这定义了主机在出现问题时应多频繁地重复发送通知。在这里，我们使用了值60，表示 60 分钟或一小时。
notification_period：这指的是 Nagios Core 在出现问题时应发送通知的时间段。在这里，我们再次使用了24x7时间段；对于其他主机，像workhours这样的时间段可能更为合适。

请注意，我们将定义添加到一个名为sparta.naginet.cfg的文件中，然后在主配置文件nagios.cfg中引用它。这仅仅是一种传统的主机布局方式，实际上这是一种相当整洁的管理方式，通过将定义保存在各自的文件中来保持清晰。

还有更多...

还有许多其他有用的主机参数，但我们使用的这些已经涵盖了所有必需的内容。

虽然这种指定主机的方式完全有效，但通常更常见的做法是基于某些模板定义主机，并定义主机应多久检查一次，状态变化时应该联系谁，以及联系的依据等类似属性。Nagios Core 的 QuickStart 示例配置定义了一个简单的模板主机，名为generic-host，可以通过使用use指令扩展主机定义来使用它：

define host {
 use                 generic-host
    name                sparta
    host_name           sparta.naginet
    address             10.128.0.21
    max_check_attempts  3
    contacts            nagiosadmin
}

这使用了为generic-host定义的所有参数，然后添加了需要检查的特定主机的详细信息。请注意，如果使用generic-host，则需要在主机定义中定义check_command。如果你想查看generic-host中定义了什么内容，可以在/usr/local/nagios/etc/objects/templates.cfg中找到它的定义。

另见

第二章中的使用替代的主机检查命令实例，工作与命令和插件
第三章中的指定检查主机的频率实例，工作与检查和状态
第九章中的在目录中分组配置文件和使用继承简化配置实例，配置管理

创建新的 HTTP 服务

在这个食谱中，我们将创建一个新的服务来检查现有的主机。具体来说，我们将检查我们的sparta.naginet服务器，看看它是否在常用的 HTTP TCP 端口 80 上响应 HTTP 请求。为此，我们将使用一个预定义的命令check_http，该命令又使用 Nagios Core 插件集中的一个标准插件，名为check_http。如果你还没有在 Nagios Core 中定义一个作为主机的 Web 服务器，你可以尝试本章中的创建一个新的网络主机食谱。

完成这些步骤后，不仅check_command会检查我们的主机是否有 PING 响应，Nagios Core 还会定期检查该机器上的 HTTP 服务是否能响应同一主机上的请求。

准备工作

你需要一个运行正常的 Nagios Core 3.0 或更高版本的安装，并且有一个 Web 界面，安装了所有 Nagios 插件，并且至少定义了一个主机。如果你需要先为你的 Web 服务器设置主机定义，你可以阅读本章中的创建一个新的网络主机食谱，要求与此相同。

在设置检查之前，最好先测试一下 Nagios Core 服务器是否能够联系到 Web 服务器，以确保我们即将设置的检查能够成功。标准的telnet工具是一个很好的方法，用来测试是否能从 TCP 端口 80 获得我们期望的 Web 服务器响应：

tom@olympus:~$ telnet sparta.naginet 80
Trying 10.128.0.21...
Connected to sparta.naginet.
Escape character is '^]'.

操作步骤...

我们可以按如下方式为sparta.naginet创建服务定义：

切换到包含sparta.naginet主机定义的文件所在目录，并按如下方式编辑该文件：
```
# cd /usr/local/nagios/etc/objects
# vi sparta.naginet.cfg
```

将以下代码片段添加到文件末尾，并替换主机的host_name指令的值：

define service {
 host_name              sparta.naginet
    service_description    HTTP
    check_command          check_http
    max_check_attempts     3
    check_interval         5
    retry_interval         1
    check_period           24x7
    notification_interval  60
    notification_period    24x7
    contacts               nagiosadmin
}

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

如果服务器成功重启，Web 界面应该会在服务部分显示一个新的服务，其状态为PENDING，等待首次检查：

几分钟后，当检查成功并获得HTTP/1.1 200 OK响应（或类似响应）时，服务的状态应该变为OK：

如果检查出现问题，可能是因为目标服务器上的 HTTP 守护进程未运行，那么检查可能会显示CRITICAL。这可能并不意味着配置有问题；更可能是网络或 Web 服务器未正常工作：

工作原理...

我们添加的配置为现有主机添加了一个简单的服务检查定义，用于检查该主机上的 HTTP 守护进程是否响应一个简单的HTTP/1.1请求，最多检查三次。如果 Nagios Core 无法得到响应，它将标记该服务的状态为严重，并会在发送通知之前再尝试两次。该服务将在 Nagios Core 的 Web 界面中可见，我们可以随时查看其状态。Nagios Core 将定期测试服务器，并标记检查是否成功。

需要注意的是，服务像是某个特定主机的一个属性；我们为特定主机定义一个服务进行检查，在这个例子中是 sparta.naginet Web 服务器。这就是为什么获取正确的 host_name 定义很重要。

我们在前面配置中定义的指令如下：

host_name：这是指该服务应适用的主机定义。这将与适当主机的 host_name 指令相同。
service_description：这是服务本身的名称，应该是一个易于识别的名称，将出现在警报中以及 Web 界面的服务部分。在这个例子中，我们使用了 HTTP。
check_command：这是指用于检查服务状态的命令。在这里，我们指的是 Nagios Core 默认配置中定义的 check_http 命令，该命令是 Nagios Core 插件集中同名插件的引用。
max_check_attempts：这是定义当 Nagios Core 发现服务状态不是 OK 时，应该尝试重新检查服务的次数。
check_interval：这是定义当服务处于 OK 状态时，或者当超过 max_check_attempts 中给定的检查次数后，Nagios Core 应该等待多久再进行下次检查。
retry_interval：这是定义 Nagios Core 在第一次发现服务状态不是 OK 后，应该在重新尝试检查时等待的时间。
check_period：这是指 Nagios Core 应该在该时间段内运行服务检查。在这里，我们使用了在 Nagios Core 默认配置中定义的合理时间段 24x7。请注意，这可以与 notification_period 不同；我们可以检查服务的状态，而不一定需要通知联系人。
notification_interval：这是定义当服务处于非 OK 状态时，Nagios Core 应该在重新发送通知时等待的时间。
notification_period：这是指 Nagios Core 应该在何时发送通知，如果它发现主机处于问题状态。在这里，我们再次使用了 24x7，但对于一些不太重要的服务，使用诸如 workhours 的时间段可能更合适。

请注意，我们在与主机定义相同的文件中添加了服务定义，并且紧跟其后。我们实际上可以将定义放在任何我们喜欢的位置，但这样做有助于保持组织结构。

还有更多...

我们在sparta.naginet上设置的监控服务是 HTTP 服务，但这只是我们可以在网络上监控的众多服务之一。Nagios Core 为其核心插件集定义了许多不同的命令，如check_smtp、check_dns等。这些命令实际上指向执行检查并将结果返回给 Nagios Core 服务器处理的程序。关键是要知道，服务几乎可以监控任何东西，而且在 Nagios Exchange 网站上有成百上千个可用于常见网络监控检查的插件：exchange.nagios.org/。

服务有更多可能的指令，在实际应用中，即使是简单的设置，我们也更有可能希望扩展一个服务模板。这样，我们就可以为多个服务定义我们可能需要的值，例如在发生通知事件之前，服务应处于CRITICAL状态多长时间，以及何时有人被联系以处理问题。

Nagios Core 默认配置中定义的一个模板叫做generic-service，我们可以通过use关键字引用它，将其作为我们新服务的基础：

define service {
 use                    generic-service
    host_name              sparta.naginet
    service_description    HTTP
    check_command          check_http
}

这对你来说可能非常有效，因为generic-service模板中设置了许多非常合理的默认值，这使得事情变得更加简单。我们可以通过查看/usr/local/nagios/etc/objects/templates.cfg中的模板定义来检查这些值。这与我们之前可能使用过的generic-host定义位于同一个文件中。

参见

本章中的创建新服务组配方
在第三章中，指定检查服务的频率和为主机或服务安排停机时间配方，与检查和状态一起工作
在第五章中，监控 Web 服务配方，监控方法

创建一个新的电子邮件联系人

在本配方中，我们将创建一个新的联系人，使主机和服务能够进行交互，主要是通知它们主机或服务状态的变化。我们将使用设置电子邮件联系人的最简单示例，并配置现有主机，以便当 Nagios Core 的主机检查失败并且主机显然无法访问时，此人会收到电子邮件消息。在这个例子中，当我的主机sparta.naginet的状态从DOWN变为UP，或反之时，我将让它给我发送电子邮件，邮件地址是nagios@sanctum.geek.nz。

准备工作

你应该有一个正常运行的 Nagios Core 3.0 或更高版本的服务器，带有 Web 界面，并且至少有一个需要监控的主机。如果你需要先做这一步，请参见本章中的创建一个新的网络主机部分。

对于这种特定类型的联系人，你还需要在监控服务器上运行一个正常工作的 SMTP 守护进程，如Exim或Postfix。你应该验证是否能够将消息发送到目标地址，并且这些消息能够成功送达预期的邮件服务器。

如何操作...

我们可以按如下方式将一个简单的新联系人添加到 Nagios Core 配置中：

切换到 Nagios Core 的对象配置目录；理想情况下，这里应该有一个专门用于联系人配置的文件，比如这里的contacts.cfg，并编辑该文件：
```
# cd /usr/local/nagios/etc/objects
# vi contacts.cfg
```

将以下联系人定义添加到文件的末尾，根据需要替换加粗的属性值：

define contact {
 contact_name                   spartaadmin
 alias                          Administrator of sparta.naginet
 email                          nagios@sanctum.geek.nz
    host_notification_commands     notify-host-by-email
    host_notification_options      d,u,r
    host_notification_period       24x7
    service_notification_commands  notify-service-by-email
    service_notification_options   w,u,c,r
    service_notification_period    24x7
}

编辑sparta.naginet主机的定义，并为适当的主机将contacts定义添加或替换为我们的新spartaadmin联系人：

define host {
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    max_check_attempts     3
    check_period           24x7
    check_command          check-host-alive
 contacts               spartaadmin
    notification_interval  60
    notification_period    24x7
}

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

完成后，下次我们的主机状态发生变化时，我们应该收到类似以下的消息：

当主机再次可用时，我们应该收到类似以下的恢复消息：

如果可能，值得通过一个我们可以安全关闭并重新启动的测试主机来测试此设置，以检查是否能收到适当的通知。

如何操作...

该配置将一个新联系人添加到 Nagios Core 配置中，并在某个主机的配置中引用它，作为当主机出现问题时使用的合适联系人。

我们已定义了联系人所需的指令，以及其他几个指令，具体如下：

contact_name：此项定义了联系人的唯一名称，以便我们可以在主机和服务定义中，或者在 Nagios Core 配置的任何其他地方引用它。
alias：此项定义了联系人的人性化名称，可能简要说明此人或小组的身份和/或其负责的内容。
email：此项定义了联系人的电子邮件地址，因为我们将通过电子邮件发送消息。
host_notification_commands：此项定义了当主机状态变化并触发通知时，应该运行的命令或命令集合。在这种情况下，我们将使用一个预定义的命令notify-host-by-email，通过电子邮件将结果发送给联系人。
host_notification_options：此项指定应通知此联系人的不同主机事件类型。这里我们使用的是d,u,r，意味着此联系人将接收关于主机DOWN、变为UNREACHABLE或恢复UP时的通知。
host_notification_period: 这定义了此联系人可以在任何主机事件通知期间内被通知的时间段。如果生成了主机通知，并且定义为发送给此联系人，但它不在此时间段内，则通知将不会被发送。
service_notification_commands: 这定义了在服务状态变化时运行的命令或命令，以便向此联系人发送通知。在本例中，我们将使用预定义命令 notify-service-by-email 将结果通过电子邮件发送给联系人。
service_notification_options: 这指定了应向此联系人通知的不同类型的服务事件。在这里，我们使用 w,u,c,r，这意味着我们希望收到关于进入 WARNING、UNKNOWN 或 CRITICAL 状态的服务的通知，以及当它们恢复并回到 OK 状态时的通知。
service_notification_period: 这与 host_notification_period 相同，只是此指令是关于服务的通知，而不是关于主机的。

请注意，我们将联系人的定义放在了 contacts.cfg 中，这是一个相当合理的地方。但是，我们可以将联系人定义放在 Nagios Core 将作为配置的一部分读取的任何文件中；我们可以按照自己喜欢的方式组织我们的主机、服务和联系人。选择一种系统有助于我们在需要添加、更改或删除它们时，能够轻松地识别定义可能出现的位置。

还有更多……

如果我们定义了许多具有相似选项的联系人，可能适合使个体联系人扩展联系人模板，以便它们可以继承这些共同的设置。QuickStart Nagios Core 配置包括一个名为 generic-contact 的模板，我们可以将我们的新联系人定义为此模板的扩展，如下所示：

define contact {
 use    generic-contact
    alias  Administrator of sparta.naginet
    email  nagios@sanctum.geek.nz
}

要查看 generic-contact 定义的指令，你可以检查 /usr/local/nagios/etc/objects/templates.cfg 文件中的定义。

参见

在本章中的 创建新的联系人组 配方
自动化联系轮换 和 为重复通知定义升级 在第五章, 监控方法

验证配置

在本配方中，我们将学习关于调试 Nagios Core 配置的最基本步骤，即验证配置。在重新启动 Nagios Core 服务器以加载更改的配置之前进行这一步骤非常有用，因为它将警告我们可能存在的问题。如果由于配置问题而无法在任何时候启动 Nagios Core 服务器，而是获得类似以下输出，则这是一个很好的配方可供遵循：

# /etc/init.d/nagios restart
Running configuration check... CONFIG ERROR!  Restart aborted.  Check your Nagios configuration.

准备就绪

你应该有一个运行良好的 Nagios Core 3.0 或更高版本服务器。

怎么做……

我们可以按以下方式验证 Nagios Core 配置：

运行以下命令，如果需要，可以替换为 Nagios 二进制文件的路径和我们的主配置文件nagios.cfg：
```
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
```
如果输出非常长，可能最好通过一个分页程序来显示，比如less：
```
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg | less
```
检查输出并查看警告和问题。如果我们的配置正确，以下是我们可能期望的输出的一部分示例：

如果出现某些问题，我们可能会看到类似下面的输出，这只是一个可能的错误示例；我的配置出错是因为我尝试为一个名为athens.naginet的主机添加服务，但实际上我还没有配置该主机。所以，Nagios Core 很正确地对我发出了警告：

它是如何工作的...

配置会被解析，就像 Nagios Core 即将启动一样，以检查配置是否合理。它会执行基本的检查，比如查找语法错误，也会检查是否至少有一个主机和服务在监控之中。它报告的某些内容是警告，意味着这些不一定是问题；例如，主机没有任何被监控的服务，或者没有定义任何联系人。

这是检查 Nagios Core 配置是否合理并能正常工作的最快方式。每当重新启动 Nagios Core 服务器遇到问题时，最好首先检查此命令的输出。实际上，养成在重新启动前检查配置的好习惯是很有帮助的，尤其是当我们不确定配置变更时，或者当监控服务器正在检查一些非常重要的内容时！这意味着，如果最终发现我们的配置有问题，那么 Nagios Core 守护进程将继续使用我们更改之前的配置运行，我们可以在重启前修复问题。

还有更多...

/usr/local/nagios/bin/nagios程序实际上与运行 Nagios Core 服务器的程序是相同的，但是命令中的-v部分是一个用于验证配置的开关，而不是启动服务器，它会显示配置中的任何问题。第二个路径是 Nagios Core 启动时使用的配置文件，它会导入对象的配置文件，例如联系人、主机和服务定义。

另请参见

第十章中的将调试信息写入 Nagios Core 日志文件教程，安全与性能

创建一个新的主机组

在这个教程中，我们将学习如何创建一个新的主机组；在这个案例中，我们将创建一个主机组来将两个网页服务器归为一组。这对于拥有不同属性的主机组非常有用，例如它们可能由不同的团队进行监控，或者运行不同类型的监控服务。它还允许我们在 Nagios Core 网页界面中查看组的详细信息，并将一个服务应用于整个主机组，而不是单独应用。这意味着，我们可以通过将主机添加到一个组来为新主机设置服务，而无需手动指定配置。

准备工作

您应该有一个运行中的 Nagios Core 3.0 或更高版本的服务器，并且该服务器有一个网页界面。

您还应该至少有两台主机组成一个有意义的组；也许它们是相似类型的服务器，如网页服务器，或者由同一团队进行监控，或者都位于同一个物理位置。

在这个例子中，我们有两台网页服务器，sparta.naginet和athens.naginet，我们将它们添加到一个名为webservers的组中。

如何操作...

我们可以通过以下方式将新的主机组webservers添加到 Nagios Core 配置中：

如果/usr/local/nagios/etc/objects/hostgroups.cfg文件尚不存在，请创建它：
```
# cd /usr/local/nagios/etc/objects
# vi hostgroups.cfg
```

将以下代码添加到新文件中，并根据您的布局替换加粗的名称：

define hostgroup {
 hostgroup_name  webservers
 alias           Webservers with Greek names
}

向上移动一个目录，然后编辑nagios.cfg文件：
```
# cd ..
# vi nagios.cfg
```

将以下行添加到文件的末尾：

cfg_file=/usr/local/nagios/etc/objects/hostgroups.cfg

对于我们希望添加到组中的每个主机，找到它们的定义，并添加一个hostgroups指令，将它们放入新主机组中。在本例中，sparta.naginet和athens.naginet的定义最终看起来如下：

define host {
    use         linux-server
    host_name   sparta.naginet
    alias       sparta
    address     10.128.0.21
    hostgroups  webservers
}
define host {
    use         linux-server
    host_name   athens.naginet
    alias       athens
    address     10.128.0.22
    hostgroups  webservers
}

重启 Nagios：
```
# /etc/init.d/nagios restart
```

现在我们应该能够访问网页界面中的主机组部分，并看到一个包含两个成员的新主机组：

它是如何工作的...

我们添加的配置包括一个新文件，并将新的主机组插入到 Nagios Core 配置中，同时将适当的主机插入到该组中。目前，这样做只是为我们在网页界面中创建一个单独的部分，以便快速查看该特定组中的所有主机。

还有更多...

我们将主机添加到组的方式其实并不是唯一的做法。如果我们愿意，可以在组定义中为该组命名主机，使用members指令，这样我们就可以得到类似以下的代码片段：

define hostgroup {
    hostgroup_name  webservers
    alias           Webservers with Greek names
    members         athens.naginet,sparta.naginet
}

这扩展到允许我们创建一个始终包含所有主机的主机组，如果我们觉得这有用：

define hostgroup {
    hostgroup_name  all
    alias           All hosts
 members         *
}

如果我们在 Nagios Core 配置中广泛使用主机组，那么我们应该选择最适合我们配置的方式。如果有需要，我们也可以同时使用这两种方法。

值得注意的是，一个主机可以属于多个组，并且我们声明的组数量没有限制，因此我们可以在将主机分组到有用的类别时更加灵活。示例可以是按功能、制造商或托管客户组织服务器，或按 BGP 或 OSPF 使用组织路由器；这完全取决于我们监控的网络类型。

另见

本章中的创建新主机和在组内所有主机上运行服务配方
在第九章的通过继承简化配置配方中，管理配置。

创建一个新的服务组

在这个配方中，我们将创建一个新的服务组。这允许我们将一组任意的服务组成有意义的组，以便在网页管理区域的独立部分中查看这些服务的状态。

准备工作

你应该已经运行着一个正常工作的 Nagios Core 3.0 或更高版本的服务器，并且具备网页界面。

你还应该定义至少两个服务，它们形成一个有意义的组；这些服务可能是类似类型的服务，如邮件服务，或者由同一团队监控，或者都位于同一物理位置的服务器上。

在这个示例中，我们有三台执行邮件功能的服务器：smtp.naginet、pop3.naginet和imap.naginet，分别运行 SMTP、POP3 和 IMAP 守护进程。所有三台主机和它们的服务都已经在 Nagios Core 中设置好了。我们将把它们添加到一个名为mailservices的新服务组中。

下面是示例中使用的主机和服务的定义，你可以看到它们是如何配合工作的：

define host {
    use                 linux-server
    host_name           smtp.naginet
    alias               smtp
    address             10.128.0.31
    hostgroups          webservers
}
    define service {
        use                  generic-service
        host_name            smtp.naginet
        service_description  SMTP
        check_command        check_smtp
    }
define host {
    use                 linux-server
    host_name           pop3.naginet
    alias               pop3
    address             10.128.0.32
    hostgroups          webservers
}
    define service {
        use                  generic-service
        host_name            pop3.naginet
        service_description  POP3
        check_command        check_pop
    }
define host {
    use                 linux-server
    host_name           imap.naginet
    alias               imap
    address             10.128.0.33
    hostgroups          webservers
}
    define service {
        use                  generic-service
        host_name            imap.naginet
        service_description  IMAP
        check_command        check_imap
    }

如何操作...

我们可以通过以下步骤添加新的服务组：

切换到我们的 Nagios Core 配置对象目录，并编辑一个名为servicegroups.cfg的新文件：
```
# cd /usr/local/nagios/etc/objects
# vi servicegroups.cfg
```

将以下定义添加到新文件中，替换粗体部分的值为你自己的值：

define servicegroup {
 servicegroup_name  mailservices
 alias              Mail services
}

向上移动一个目录，然后编辑nagios.cfg文件：
```
# cd ..
# vi nagios.cfg
```

将以下行添加到文件末尾：

cfg_file=/usr/local/nagios/etc/objects/servicegroups.cfg

对于我们想要添加到组中的每个服务，找到它们的定义，并添加一个servicegroups指令，将它们加入到新的服务组中。定义可能最终类似于以下代码片段：

define service {
    use                  generic-service
    host_name            smtp.naginet
    service_description  SMTP
    check_command        check_smtp
 servicegroups        mailservices
}
define service {
    use                  generic-service
    host_name            pop3.naginet
    service_description  POP3
    check_command        check_pop
 servicegroups        mailservices
}
define service {
    use                  generic-service
    host_name            imap.naginet
    service_description  IMAP
    check_command        check_imap
 servicegroups        mailservices
}

使用以下命令重启 Nagios：
```
# /etc/init.d/nagios restart
```

现在我们应该能够访问网页界面的服务组部分，并看到一个包含三个成员的新服务组：

如何工作...

我们添加的配置包括一个新文件，其中包含一个新的服务组，并将适当的服务插入到该组中。这在网页界面中为我们创建了一个单独的部分，让我们可以快速查看该特定组中的所有服务。

还有更多...

我们将服务添加到组中的方式实际上并不是唯一的方式。如果我们愿意，我们可以在组定义中使用 members 指令来命名服务（及其适用的主机），从而拥有类似以下的代码片段：

define servicegroup {
    servicegroup_name  mailservices
    alias              Mail services
 members            smtp.naginet,SMTP,pop3.naginet,POP3
}

请注意，我们需要指定服务所在的主机，然后列出该主机上要监控的服务，服务之间用逗号分隔。主机名先出现，然后是服务。

这也扩展到允许我们创建一个始终包含每个单独服务的服务组，如果我们认为这有用的话：

define servicegroup {
    servicegroup_name  all
    alias              All services
 members            *
}

如果我们打算在 Nagios Core 配置中广泛使用服务组定义，我们应该使用我们认为最易于维护的两种方法中的任意一种来将服务添加到组中。

值得注意的是，一个服务可以属于多个组，而且我们声明的组数量没有限制，因此我们可以非常灵活地将服务归类到不同的类别中。举例来说，可以根据通知的相应联系人、内部功能或面向客户的功能来组织服务。

另见

本章中的创建新服务和在组内所有主机上运行服务食谱
第九章中的使用继承简化配置食谱，配置管理

创建一个新的联系人组

在这个食谱中，我们将创建一个新的联系人组，向其中添加我们的联系人。像主机组和服务组一样，联系人组主要是便捷的快捷方式。在这种情况下，它允许我们定义一个联系人组作为主机或服务定义的通知接收者。这意味着我们可以定义一个名为 ops 的组，然后即使人员加入或离开该组，我们也无需更改主机或服务的任何定义。

准备工作

你应该运行一个正常工作的 Nagios Core 3.0 或更高版本的服务器。

你还应该至少有两个联系人组成一个有意义的组。在这种情况下，我们有两位员工，John Smith 和 Jane Doe，他们都是我们网络运维团队的一部分。我们希望他们都能接收到所有相关主机和服务的通知，因此我们将把他们添加到一个名为 ops 的组中。以下是我们正在使用的定义：

define contact {
    use           generic-contact
    contact_name  john
    alias         John Smith
    email         john@naginet
}
define contact {
    use           generic-contact
    contact_name  jane
    alias         Jane Doe
    email         jane@naginet
}

如何操作...

我们可以按如下方式创建新的 ops 联系人组：

进入我们的 Nagios Core 对象配置目录，并编辑 contacts.cfg 文件：
```
# cd /usr/local/nagios/etc
# vi contacts.cfg
```

向文件中添加以下定义，并根据需要替换加粗部分的值：

define contactgroup {
 contactgroup_name  ops
 alias              Network operators
}

对于我们想要添加到组中的每个联系人，找到他们的定义并为他们添加 contactgroups 指令。定义最终会类似于以下代码片段：

define contact {
    use            generic-contact
    contact_name   john
    alias          John Smith
    email          john@naginet
 contactgroups  ops
}
define contact {
    use            generic-contact
    contact_name   jane
    alias          Jane Doe
    email          jane@naginet
 contactgroups  ops
}

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

它是如何工作的...

设置好这个组后，我们现在可以在contactgroups指令中使用它，指定应接收通知的联系人组。通知将发送到该组中的所有地址。这可以替代contacts指令，其中我们逐个列出联系人。

还有更多...

这意味着，例如，替代具有如下类似服务定义：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP
    check_command        check_http
 contacts             john,jane
}

我们可以使用以下代码片段：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP
    check_command        check_http
 contact_groups       ops
}

如果 John Smith 离开了操作团队，我们只需删除他的联系人定义，其他的无需更改；从此以后，只有 Jane Doe 会收到服务通知。此方法在联系人和他们接收通知的主机与服务之间提供了一层抽象。

另请参见

本章中的创建新联系人示例
第四章中的自动化联系人轮换示例，配置通知
第九章中的使用继承简化配置示例，管理配置

创建新的时间段

在这个示例中，我们将在 Nagios Core 配置中添加一个新的时间段定义，以便我们仅在工作日进行主机和服务的监控。这里有一个默认配置定义为workhours，几乎适合我们的需求，除了它没有包括晚上时间。我们将从头开始创建一个新的，并且还会再创建一个用于覆盖周末的时间段。

准备工作

你应该有一个运行正常的 Nagios Core 3.0 或更高版本的服务器。

如何操作...

我们可以如下设置新的时间段，命名为weekdays：

切换到我们的 Nagios Core 配置对象目录，并编辑名为 timeperiods.cfg 的文件：
```
# cd /usr/local/nagios/etc/objects
# vi timeperiods.cfg
```

将以下定义添加到文件的末尾：

define timeperiod {
    timeperiod_name  weekdays
    alias            Weekdays
    monday           00:00-24:00
    tuesday          00:00-24:00
    wednesday        00:00-24:00
    thursday         00:00-24:00
    friday           00:00-24:00
}
define timeperiod {
    timeperiod_name  weekends
    alias            Weekends
    saturday         00:00-24:00
    sunday           00:00-24:00
}

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

它是如何工作的...

在我们的主机和服务定义中，有两个指令，check_period 和 notification_period。这些指令用于定义主机或服务应检查的时间，以及应发送通知的时间。24x7 和 workhours 时间段已在我们刚刚编辑的 timeperiods.cfg 文件中定义，并且在多个示例和模板中使用。

我们刚刚又添加了两个这样的时间段，现在可以在主机和服务的定义中使用它们。第一个称为weekdays，表示工作日的任何时间；第二个称为weekends，表示任何非工作日的时间。请注意，在这两种情况下，我们通过命名每一天并指定对应的时间，来定义了日期和时间。

还有更多...

日期的定义非常巧妙，可以通过多种方式进行定义。以下都是有效的天数和时间段定义：

june 1 - july 15 00:00-24:00：从 6 月 1 日到 7 月 15 日的任何时间（含这两天）
thursday -1 00:00-24:00：每月的最后一个星期四的任何时间
day 1 - 10 13:00-21:00：每月的 1 号至 10 号期间，从下午 1 点到晚上 9 点的时间段

很可能，标准的 24x7 和 workhours 定义已经适合日常监控，也许可以添加一个 weekdays 和 weekends 的定义。然而，可能会有某个时候，我们需要对某个主机或服务进行不常规的监控，特别是如果我们正在调试一个仅在某个特定时间出现的问题，或者需要管理大量联系人，或者有一个复杂的轮值安排。

请注意，Nagios Core 在某些情况下可能表现异常，特别是在正常运行时间报告方面，如果我们对主机和服务的监控时间段总和不到 24 小时。理想情况下，我们应当全天候检查并通知所有主机和服务，但根据日程安排以不同的方式处理通知；例如，工作时间内可以通过分页通知系统管理员关于非关键系统的情况，但当他们睡觉时，只需通过电子邮件通知他们！

另请参见

第四章中的自动化联系轮换、配置通知时段和配置通知组的教程，配置通知

在组内所有主机上运行服务

在本教程中，我们将创建一个新服务，但不是将其应用到现有的主机上，而是将其应用到现有的主机组上。在这种情况下，我们将创建一个名为 webservers 的组。执行此操作的步骤与为单个主机添加服务非常相似；唯一不同的是有一条指令。

准备工作

你应该运行一个工作中的 Nagios Core 3.0 或更高版本的服务器，并且具有 Web 界面。你应熟悉如何向单个主机添加服务。

你还应至少定义一个主机组，并且该组中至少有一个主机；我们将使用一个名为 webservers 的组，并在其中定义主机 sparta.naginet 和 athens.naginet。

作为参考，以下是该主机组的定义及其包含的两个主机定义：

define hostgroup {
    hostgroup_name  webservers
    alias           Webservers
}
define host {
    use         linux-server
    host_name   athens.naginet
    alias       athens
    address     10.128.0.22
    hostgroups  webservers
}
define host {
    use         linux-server
    host_name   sparta.naginet
    alias       sparta
    address     10.128.0.21
    hostgroups  webservers
}

如何操作...

我们可以如下为 webservers 组创建服务定义：

进入包含定义 webservers 主机组的文件所在的目录，并进行编辑：
```
# cd /usr/local/nagios/etc/objects
# vi hostgroups.cfg
```

在主机组定义后添加以下代码片段。将粗体部分修改为适合你自己模板和主机组名称的内容：

define service {
 use                    generic-service
 hostgroup_name         webservers
    service_description    HTTP
    check_command          check_http
}

重启 Nagios Core 服务器：
```
# /etc/init.d/nagios restart
```

需要特别注意的是，如果我们已经通过每个主机的同名服务在监控这些主机，那么我们也需要删除这些定义；如果同一主机上已经定义了相同描述的服务，Nagios Core 可能无法启动。

它是如何工作的...

将服务添加到主机组的方式与添加到单个主机完全相同，不同之处在于，它只需要一个定义，然后应用于组内所有主机。这意味着它是保持 Nagios Core 配置整洁的一个非常好的方式。如果我们有一个包含 50 个不同 Web 服务器的主机组，并且我们需要基于相同的标准监控它们的 HTTP 服务，那么我们就不需要为每个服务器创建 50 个服务定义；我们只需为主机组创建一个服务定义，这样配置更简洁且更易于更新。

还有更多...

与服务的host_name指令类似，hostgroup_name指令实际上可以定义多个主机组，这些主机组通过逗号分隔。这意味着我们可以将相同的服务应用于多个主机组，而不仅仅是一个。如果我们希望在多个不同的主机组上运行某个服务（例如，基本的 PING 监控），这将使得配置更加灵活。

另见

本章中的创建新服务和创建新主机组配方
第九章中的使用继承简化配置配方，管理配置

第二章：使用命令和插件

在本章中，我们将涵盖以下内容：

查找插件
安装插件
移除插件
自定义现有命令
使用替代的主机检查命令
从零开始编写新插件

介绍

Nagios Core 也许最好被视为一个监控框架，而不仅仅是一个监控工具。它的模块化设计可以使用任何能够根据某种检查返回适当值的程序，例如用于主机或服务的 check_command 插件。这就是命令和插件概念发挥作用的地方。

对于 Nagios Core，插件是任何可以用来收集有关主机或服务信息的程序。为了确保主机响应 PING 请求，我们可以使用一个插件，如 check_ping，当该插件针对主机名或地址运行时，无论是否由 Nagios Core 执行，都会返回一个状态码，指示是否在一定时间内收到了 PING 请求的响应。这个状态码和任何附带的消息就是 Nagios Core 用来确定主机或服务状态的依据。

插件通常就像 Unix 类系统上的任何其他程序；它们可以从命令行运行，受限于权限和所有者的限制，可以用任何编程语言编写，并且可以接受参数和选项来修改其工作方式。最重要的是，它们与 Nagios Core 本身完全独立（即使是由同一个团队编写的），并且它们在应用程序中的使用方式是可以更改的。

为了允许插件在使用时具有更大的灵活性，Nagios Core 根据命令定义的条款使用这些程序。特定插件的命令定义了该插件的使用方式，包括它在文件系统中的位置、应该传递的任何参数以及其他选项。特别是，参数和选项通常包括 WARNING 和 CRITICAL 状态的阈值。

Nagios Core 通常与一组插件一起下载和安装，这些插件称为Nagios 插件，可以在www.nagiosplugins.org/上找到，本书假设你已经安装了这些插件。这些插件之所以被选择，是因为作为一个整体，它们能够很好地覆盖监控基础设施中最常见的需求，包括对常见服务的检查，如 web、邮件服务和 DNS 服务，以及更通用的检查，如检查服务器上 TCP 或 UDP 端口是否可访问并且开放。对于大多数监控需求，我们可能不需要其他插件；但如果需要，Nagios Core 使得通过自定义命令定义、在 Nagios Exchange 网站上添加由贡献者编写的第三方插件，或者在一些特殊情况下从零开始编写自定义插件成为可能。

查找插件

在这个食谱中，我们将遵循一个良好的流程，找到适合特定监控任务的插件。我们将首先检查是否已经有现有的插件可以完全满足我们的需求。如果找不到，我们将检查是否可以使用其他更通用的插件来解决问题。如果仍然没有合适的插件，我们将访问 Nagios Exchange 并在那里搜索合适的插件。

准备工作

你应该已经运行了一个 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务，你需要在其中一台主机上配置一个特定的服务，而你不确定如何监控它。

我们将以一个简单的问题作为示例；我们有一台名为troy.naginet的服务器，运行一个rsync进程，该进程在端口873上监听。我们已经通过PING监控了主机的网络连接，但我们希望 Nagios Core 检查rsync服务器是否始终可用并监听，以防它在运行时崩溃或在系统重启时未能启动。

如何操作...

我们可以通过以下步骤找到适合任何监控任务的新插件：

首先，由于我们已经安装了 Nagios Core Plugins 集，我们将检查其中的任何插件是否可以直接应用于我们的问题。我们将从访问 Nagios Core 服务器上的/usr/local/nagios/libexec目录开始，并获取目录列表：
```
# cd /usr/local/nagios/libexec
# ls
check_apt       check_ide_smart     check_nntp      check_simap
check_breeze    check_ifoperstatus  check_nntps     check_smtp
check_by_ssh    check_ifstatus      check_nt        check_spop
...
```
这里有一长串插件，但没有一个像check_rsync或check_backup，所以看起来核心中似乎没有一个插件能完全满足我们的需求。
然而，有一个名为check_tcp的插件。搜索其名称时，Nagios Plugins 网站的手册页面作为第一个结果出现，描述了它的功能：

“这个插件测试与指定主机（或 Unix 套接字）的 TCP 连接。”

我们不仅仅需要检查端口，所以这也不太适合我们。
搜索check_rsync，这是插件的合适名称，搜索结果中出现了 Nagios Exchange 网站的一页，正好有一个名为check_rsync的插件。我们现在找到了一个合适的插件：

它是如何工作的...

如果我们只需要检查rsync是否在端口873上监听，而不需要真正监控其实际功能，那么check_tcp插件可能足够了。然而，在我们的案例中，我们可能需要找到一种方法，不仅检查端口是否开放，还需要检查特定目录或rsync模块是否可访问。

阅读check_rsync的描述，它看起来正好具备我们需要的功能——检查服务器上是否有某个rsync模块。在这一点上，我们可以下载插件并按照其安装说明进行安装。

还有更多...

本操作指南旨在强调，除了将一组功能强大的插件作为 Nagios Core 插件集的一部分外，Nagios Core 插件网站上提供的在线文档 nagiosplugins.org/ 以及 Nagios Exchange 上提供的其他插件 exchange.nagios.org/ 使得找到适合特定监控问题的插件相对简单。

请注意，当我们下载第三方插件时，重要的是要检查是否信任该插件以确保它能执行我们需要的操作。Nagios Exchange是一个有管理的社区，遵循一定的编码标准，但插件的使用风险自负；如果我们不理解某个插件的功能，应该谨慎安装或使用它，且需阅读其代码、文档及评论。

另请参见

本章中的安装插件、移除插件和从零开始编写插件的操作指南

安装插件

在本操作指南中，我们将把从 Nagios Exchange 下载的自定义插件安装到 Nagios Core 服务器上，以便将其用作 Nagios Core 命令，从而检查服务。

准备工作

你应该已经有一个 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务，同时找到一个合适的插件来解决某个特定的监控需求。你的 Nagios Core 服务器应该具有互联网连接，能够直接从网站下载插件。

在这个示例中，我们将使用check_rsync插件，它可以在网上找到，网址是 exchange.nagios.org/directory/Plugins/Network-Protocols/Rsync/check_rsync/details。

这个插件非常简单，由一个 Perl 脚本和一些基本的依赖项组成。如果你希望安装此脚本作为示例，那么服务器还需要安装 Perl 解释器；在许多系统中，它安装在/usr/bin/perl路径下。

本示例还将直接测试运行rsync守护进程的服务器，主机名为troy.naginet。

如何操作...

我们可以按如下方式下载并安装新插件：

复制check_rsync插件的最新版本下载链接：
转到 Nagios Core 服务器的插件目录。默认位置是/usr/local/nagios/libexec：
```
# cd /usr/local/nagios/libexec
```

使用wget命令将插件下载到名为check_rsync的文件中。请确保将 URL 用引号括起来：

# wget 'http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=307&cf_id=29' -O check_rsync

使用chmod和chown命令使插件可执行：

# chown nagios.nagios check_rsync
# chmod 0770 check_rsync

直接运行插件，且不带任何参数，以检查它是否能够运行并获取使用说明。建议使用nagios用户通过su或sudo来测试：

# sudo -s -u nagios
$ ./check_rsync
Usage: check_rsync -H <host> [-p <port>] [-m <module>[,<user>,<password>] [-m <module>[,<user>,<password>]...]]

尝试直接对运行rsync的主机运行插件，查看它是否能正常工作并报告状态：

$ ./check_rsync -H troy.naginet
Output normally starts with the status determined, with any extra information after a colon:
OK: Rsync is up

如果这一切正常，那么插件现在已经安装并且可以正常工作。

它是如何工作的...

因为 Nagios Core 插件本身就是程序，所以安装插件就相当于将一个程序或脚本保存到合适的目录；在这个案例中是/usr/local/nagios/libexec，在那里存放着所有其他插件。它接下来可以像任何其他插件一样使用。

插件一旦正常工作，下一步就是在 Nagios Core 配置中定义一个命令，以便它可以用于监控主机和/或服务。这可以通过本章中的创建新命令部分来完成。

还有更多...

如果我们检查 Perl 脚本，我们可以看到它的工作原理。它像其他 Perl 脚本一样工作，不同之处在于它的返回值定义在一个名为%ERRORS的哈希表中，选择的返回值取决于它尝试检查rsync进程时发生的情况。这是为 Nagios Core 实现插件的最关键部分。

不同插件的安装过程各不相同。特别是许多插件是用像 C 这样的语言编写的，因此需要编译。一个这样的插件是流行的check_nrpe。这些插件通常不仅仅是保存到一个目录并使其可执行，它们往往遵循配置、编译和安装的常规模式：

$ ./configure
$ make
# make install

对于许多以这种方式构建的插件，通常该过程的最后一步会将编译好的插件安装到合适的目录。一般来说，如果插件附带了说明文档，最好阅读它们，以确保我们正确安装插件。

参见

本章中的查找插件、删除插件和创建新命令部分

删除插件

在这个实例中，我们将删除一个我们不再需要的插件，作为我们 Nagios Core 安装的一部分。可能是它无法正常工作，或者它监控的服务不再可用，或者使用它存在安全或许可问题。

准备工作

你应该已经运行了一个 Nagios Core 3.0 或更高版本的服务器，并且已经配置了几个主机和服务，同时有一个你想从服务器中删除的插件。在本例中，我们将从 Nagios Core 服务器中删除现在不再需要的check_rsync插件。

操作方法...

我们可以按照以下步骤从 Nagios Core 实例中删除插件：

删除任何使用该插件的配置部分，包括使用它的主机或服务的check_command，以及引用该程序的命令定义。举个例子，以下定义的命令在我们删除check_rsync插件后将不再有效：
```
define command {
    command_name  check_rsync
    command_line  $USER1$/check_rsync -H $HOSTADDRESS$
}
```
使用grep等工具是查找命令和插件引用的一个好方法：
```
# grep -R check_rsync /usr/local/nagios/etc
```
在 Nagios Core 服务器上切换到保存插件的目录。默认位置是/usr/local/nagios/libexec：
```
# cd /usr/local/nagios/libexec
```
使用rm命令删除插件：
```
# rm check_rsync
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

它是如何工作的...

Nagios Core 插件仅仅是服务器用来执行主机和服务检查的外部程序。如果不再需要插件，只需从我们的配置中删除对它的引用（如果有），然后从/usr/local/nagios/libexec目录中删除插件程序即可。

还有更多内容...

通常，即使 Nagios Core 没有使用插件程序，将其保留在服务器上也不会有什么害处。它不会导致任何性能问题或其他麻烦，而且以后可能会需要。Nagios Core 的插件通常是非常小的程序，不会在现代服务器上占用太多磁盘空间。

另见

本章中的查找插件，安装插件和创建新命令方法

创建一个新命令

在这个例子中，我们将为刚刚安装到 Nagios Core 服务器上/usr/local/nagios/libexec目录中的插件创建一个新命令。这将定义 Nagios Core 如何使用该插件，从而允许它作为服务定义的一部分被使用。

准备工作

你应该已经运行了 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务，并安装了你希望为其定义新命令的插件。这将允许你将它作为服务定义的一部分使用。在这个例子中，我们将为已安装的check_rsync插件定义一个命令。

如何操作...

我们可以按照以下方式在配置中定义一个新命令：

切换到包含 Nagios Core 对象配置的目录。默认位置是/usr/local/nagios/etc/objects：
```
# cd /usr/local/nagios/etc/objects
```
编辑commands.cfg文件：
```
# vi commands.cfg
```

在文件底部，添加以下命令定义：

define command {
    command_name  check_rsync
 command_line  $USER1$/check_rsync -H $HOSTADDRESS$
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

如果验证通过并且服务器成功重启，我们应该能够在服务定义中使用check_rsync命令。

它是如何工作的...

我们添加到commands.cfg文件中的配置定义了一个名为check_rsync的新命令，定义了使用同名插件监控服务的方法。这使我们能够在服务声明中使用check_rsync作为check_command指令的值，类似于以下代码片段：

define service {
    use                  generic-service
    host_name            troy.naginet
    service_description  RSYNC
 check_command        check_rsync
}

命令定义只需要两个指令，我们已经定义了这两个指令：

command_name：这定义了我们可以在主机或服务定义中引用该命令时使用的唯一名称。
command_line：这定义了 Nagios Core 应该执行的命令行，以进行适当的检查。

这个特定的命令行还使用了两个宏：

$USER1$ ：它展开为/usr/local/nagios/libexec，这是插件二进制文件的存放位置，包括check_rsync。它在文件/usr/local/nagios/etc/resource.cfg的示例配置中定义。
$HOSTADDRESS$ ：它展开为任何主机的地址，且该命令用于该主机或服务定义。

所以，如果我们在检查troy.naginet上的rsync服务器时使用了这个命令，那么完成的命令可能会像下面这样：

$ /usr/local/nagios/libexec/check_rsync -H troy.naginet

我们可以直接以 nagios 用户身份从命令行运行它，看看它返回什么样的结果：

$ /usr/local/nagios/libexec/check_rsync -H troy.naginetOK: Rsync is up

还有更多内容...

一个插件可以用于多个命令。如果我们有一个特定的rsync模块，配置名称为backup，我们可以编写另一个命令check_rsync_backup，如下所示，检查此模块是否可用：

define command {
    command_name  check_rsync_backup
 command_line  $USER1$/check_rsync -H $HOSTADDRESS$ -m backup
}

或者，如果我们的一个或多个rsync服务器运行在另一个端口上，比如端口5873，那么我们可以为此定义一个单独的命令check_rsync_altport：

define command {
    command_name  check_rsync_altport
 command_line  $USER1$/check_rsync -H $HOSTADDRESS$ -p 5873
}

因此，命令可以根据我们的需求定义得非常精确。在本章的自定义现有命令配方中，我们将详细探讨这一点。

另见

本章中的安装插件和自定义现有命令配方

自定义现有命令

在这个配方中，我们将自定义一个现有的命令定义。你可能会出于多种原因想这么做，其中一个常见的原因是检查过于“积极”，在WARNING或CRITICAL状态时发送通知，尽管这些状态实际上并不严重。它还可以有用，如果一个检查过于“宽容”，没有检测到主机或服务的实际问题。

另一个原因是考虑到你自己网络的特殊情况。例如，如果你在大量主机上运行 HTTP 守护进程，并且这些守护进程都使用备用端口8080，那么需要检查它们，最好有一个check_http_altport命令可用。我们可以通过复制并修改原始check_http命令的定义来实现这一点。

准备工作

你应该已经运行了 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务。你还应该已经熟悉服务、命令和插件之间的关系。

如何操作...

我们可以按照如下方式自定义现有的命令定义：

切换到包含 Nagios Core 对象配置的目录。默认位置是/usr/local/nagios/etc/objects：
```
# cd /usr/local/nagios/etc/objects
```
编辑commands.cfg文件，或者编辑位于适当位置的其他文件，以适应check_http命令：
```
# vi commands.cfg
```

查找check_http命令的定义。在默认的 Nagios Core 配置中，它应该类似于以下内容：

# 'check_http' command_definition
define command {
 command_name  check_http
 command_line  $USER1$/check_http -H $HOSTADDRESS$ $ARG1$
}

将此定义复制到新定义中，并将其更改为类似于以下代码片段，重命名命令并向命令行添加一个新选项：

# 'check_http_altport' command_definition
define command {
 command_name  check_http_altport
 command_line  $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

如果验证通过且服务器成功重启，我们现在应该能够在服务定义中使用基于原始check_http命令的check_http_altport命令。

它是如何工作的...

我们添加到commands.cfg文件中的配置重新定义了check_http命令，但在两个方面做了更改：

它将命令从check_http重命名为check_http_alt，这是为了区分这些命令。Nagios Core 中的命令名称，就像主机名一样，必须是唯一的。
它在命令行调用中添加了选项-p 8080，指定了何时调用check_http。检查将使用 TCP 端口8080，而不是默认的 TCP 端口80。

check_http_alt命令现在可以像check_http命令一样作为检查命令使用。例如，检查sparta.naginet主机是否在8080端口上运行 HTTP 守护进程的服务定义可能类似于以下代码片段：

define service {
    use                  generic-service
    host_name            sparta.naginet
 service_description  HTTP_8080
 check_command        check_http_alt
}

还有更多...

这道配方的标题暗示我们应该通过直接编辑现有命令来进行自定义，实际上，如果我们确实希望以这种方式操作，这种方法是有效的。我们可以在命令行中直接添加-p 8080或其他自定义选项，而不是复制命令定义，并修改原始命令。

然而，在大多数情况下，这种做法是不可取的，主要是因为它可能会破坏现有的监控，并且可能会让其他 Nagios Core 服务器的管理员感到困惑。如果我们有一个特殊的监控案例——在这种情况下，检查非标准端口的 HTTP——那么明智的做法是基于现有命令创建一个全新的命令，并进行必要的自定义。

你可以定义任意数量的命令，因此在定义所需的替代命令时可以非常自由。建议给它们起一些具有指导意义的名字，描述它们的功能，并在配置文件中添加解释性注释。你可以通过在文件前加#字符来添加注释：

#
# '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$
}

另请参见

本章中的创建新命令配方
第一章中的创建新服务配方，理解主机、服务和联系人

使用备用检查命令检查主机

在这个配方中，我们将学习如何处理网络监控中的一个稍微棘手的情况——监控一个不响应 PING 的服务器，但仍然提供需要检查的某些网络服务。

在可能的情况下，允许 PING 是一个良好的实践，因为它是RFC 1122中的一项规定，并且是一个非常有用的诊断工具，不仅用于监控，也用于故障排除。然而，有时只被少数人访问的服务器可能被配置为不响应这些消息，可能是出于保密的原因。家庭路由器通常会这样配置。

这个问题的另一个非常常见的原因，也是我们在这里处理的示例，是检查位于IPv4 NAT防火墙后面的服务器。我们无法通过RFC1918地址（如192.168.1.20）直接访问主机，因为它不能从公共互联网进行访问。因此，单纯地对路由器的公共接口进行 ping 测试并不能告诉我们，路由器正在转换地址的主机是否正常工作。

然而，SSH 的端口22从外部转发到该服务器，正是我们需要检查其可用性的服务。

我们将通过 SSH 检查主机是否正常，因为我们无法像通常那样从外部 ping 它。

准备工作

您应该已经运行了 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务。您也应该已经熟悉服务、命令和插件之间的关系。

如何操作...

我们可以按如下方式为主机指定替代的检查方法：

切换到包含 Nagios Core 对象配置的目录。默认位置是/usr/local/nagios/etc/objects：
```
# cd /usr/local/nagios/etc/objects
```
找到包含无法响应 PING 的主机定义的文件，并进行编辑。在本例中，我们要编辑的是crete.naginet主机：
```
# vi crete.naginet.cfg
```
更改或定义主机的check_command参数，使用我们想要用于检查的命令，而不是通常的check-host-alive或check_ping插件。在这种情况下，我们希望使用check_ssh。最终的主机定义可能类似于以下代码片段：
```
define host {
    use            linux-server
    host_name      crete.naginet
    alias          crete
    address        10.128.0.23
    check_command  check_ssh
}
```
请注意，即使我们使用的是主机模板，如generic-host或linux-server，定义check_command依然有效。最好检查主机是否会按预期响应我们的检查：
```
# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_ssh -H 10.128.0.23
SSH OK - OpenSSH_5.5p1 Debian-6+squeeze1 (protocol 2.0)
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，接下来的对crete.naginet服务器的计划检查应该会显示该主机为UP，因为它是通过check_ssh命令而非通常的check-host-alive命令进行检查的。

它是如何工作的

我们为crete.naginet主机添加的配置使用check_ssh来检查主机是否UP，而不是使用 PING 的检查。这是合适的，因为从crete.naginet访问的唯一公共服务是其 SSH 服务。

check_ssh命令通常用于检查服务的可用性，而不是主机。然而，Nagios Core 允许我们将其作为主机检查命令使用。大多数服务命令都是这样工作的；您也可以通过check_http检查位于 NAT 后面的 Web 服务器。

还有更多...

请注意，为了完整性，适当地通过 PING 或其他适合其公共地址的检查监控 NAT 路由器也是合适的。这样，如果 SSH 服务器的主机检查失败，我们可以检查位于前面的 NAT 路由器是否仍然可用，这有助于排查问题是否出在服务器本身还是前面的 NAT 路由器上。你还可以通过将 NAT 路由器设置为 SSH 服务器的父主机，来使这个设置更有用，这一点可以在第八章中的 创建网络主机层次结构 方案，理解网络布局 中找到。

另见

第五章中的 监控 SSH 以检查任何主机 和 检查替代 SSH 端口 方案，监控方法
第六章中的 使用 NRPE 监控远程主机上的本地服务 方案，启用远程执行
第八章中的 创建网络主机层次结构 和 建立主机依赖关系 方案，理解网络布局

从零开始编写一个新的插件

即便有 Nagios 插件集中非常有用的标准插件，以及 Nagios Exchange 上大量可用的自定义插件，随着我们的监控设置变得更加精细，我们有时也会发现，某些服务或主机的某个属性我们希望进行检查，但似乎没有合适的插件可用。每个网络都是不同的，有时候其他人慷慨为社区制作的插件并不能完全覆盖你的需求。通常，监控需求越具体，可用的插件就越少，甚至没有一个插件能够完全满足你的要求。

在这个示例中，我们将处理一个非常具体的问题，我们假设这个问题无法通过任何已知的 Nagios Core 插件有效解决，因此我们将使用 Perl 编写一个插件来解决。下面是示例问题：

我们的 Linux 安全团队希望能够自动检查我们的服务器是否运行着有已知漏洞的内核。然而，他们并不担心所有存在漏洞的内核，而是关注特定的版本。他们已经提供了三个内核的版本号，这些内核有一些小漏洞，虽然他们并不特别担心，但确实需要打补丁，还有一个内核是他们非常担心的。

假设小漏洞存在于版本号为 2.6.19、2.6.24 和 3.0.1 的内核中，而严重漏洞存在于版本号为 2.6.39 的内核中。请注意，这些版本号是任意的，并不一定反映任何真实的内核漏洞！

团队可以单独登录到所有服务器进行检查，但这些服务器的年龄和访问方式各不相同，由不同的人管理。他们还需要多次手动检查，因为有可能某个未经经验的管理员会升级到一个在旧版中已知存在漏洞的内核版本，而且他们可能还想以后添加其他受影响的内核版本进行检查。

因此，团队要求我们通过 Nagios Core 监控来解决问题，我们决定最好的解决方式是编写自己的插件 check_vuln_kernel，该插件检查 uname 的输出中的内核版本字符串，然后执行以下操作：

如果是略微有漏洞的内核版本，它将返回一个 WARNING 状态，提醒我们安全团队在下次有时间时应当处理此问题。
如果是高度易受攻击的内核版本，它将返回一个 CRITICAL 状态，安全团队知道必须立即安装修补后的内核。
如果 uname 给出了错误或我们无法理解的输出，它将返回一个 UNKNOWN 状态，提醒团队插件中可能存在错误或服务器可能存在更严重的问题。
否则，它将返回一个 OK 状态，确认该内核版本没有已知漏洞。
最后，他们希望能够一目了然地在 Nagios Core 监控中看到内核版本，并判断它是否存在漏洞。

出于这个示例的目的，我们只监控 Nagios Core 服务器本身，但通过 NRPE，我们可以在其他需要监控的服务器上安装这个插件，它们也能正常工作。你可以在第六章的 使用 NRPE 监控远程机器的本地服务 中学习如何操作。

尽管这个问题非常具体，我们将以一种非常通用的方式来处理它，你可以将这种方式适应到任何需要 Nagios 插件的解决方案中：

执行命令并将其输出存储到变量中。
检查输出中是否存在或不存在某些模式。
根据这些测试返回适当的状态。

这意味着如果你能做到这一点，你将能够通过 Nagios Core 有效地监控服务器上的任何东西！

准备工作

你应该已经有一个运行着的 Nagios Core 3.0 或更新版本的服务器，并且已经配置了一些主机和服务。你还应该熟悉服务、命令和插件之间的关系。你还需要安装 Perl。

这将是一个相当长的教程，涵盖了许多 Nagios Core 的概念。你应该熟悉以下所有概念：

定义新主机和服务，以及它们之间的关系。
定义新命令，以及它们如何与调用的插件相关联。
安装、测试和使用 Nagios Core 插件。

一些 Perl 的基础知识也会有所帮助，但不是必需的。我们会在插件中包含注释，解释每一段代码的作用。

如何做到这一点...

我们可以按如下方式编写、测试并实现我们的示例插件：

切换到包含 Nagios Core 插件二进制文件的目录。默认位置是/usr/local/nagios/libexec：
```
# cd /usr/local/nagios/libexec
```
开始编辑一个新的文件，名为check_vuln_kernel：
```
# vi check_vuln_kernel
```

在其中包含以下代码；请注意注释，它们解释了每一段代码的作用：

#!/usr/bin/env perl

#
# Use strict Perl style and report potential problems to help us write this
# securely and portably.
#
use strict;
use warnings;

#
# Include the Nagios utils.pm file, which includes definitions for the return
# statuses that are appropriate for each level: OK, WARNING, CRITICAL, and
# UNKNOWN. These will become available in the %ERRORS hash.
#
use lib "/usr/local/nagios/libexec";
use utils "%ERRORS";
#
# Define a pattern that matches any kernel vulnerable enough so that if we find
# it we should return a CRITICAL status.
#
my $critical_pattern = "^(2\.6\.39)[^\\d]";

#
# Same again, but for kernels that only need a WARNING status.
#
my $warning_pattern = "^(2\.6\.19|2\.6\.24|3\.0\.1)[^\\d]";

#
# Run the command uname with option -r to get the kernel release version, put
# the output into a scalar $release, and trim any newlines or whitespace
# around it.
#
chomp(my $release = qx|/bin/uname -r|);

#
# If uname -r exited with an error status, that is, anything greater than 1,
# then there was a problem and we need to report that as the UNKNOWN status
# defined by Nagios Core's utils.pm.
#
if ($? != 0) {
 exit $ERRORS{UNKNOWN};
}

#
# Check to see if any of the CRITICAL patterns are matched by the release
# number. If so, print the version number and exit, returning the appropriate
# status.
#
if ($release =~ m/$critical_pattern/) {
 printf "CRITICAL: %s\n", $release;
 exit $ERRORS{CRITICAL};
}

#
# Same again, but for WARNING patterns.
#
if ($release =~ m/$warning_pattern/) {
 printf "WARNING: %s\n", $release;
 exit $ERRORS{WARNING};
}

#
# If we got this far, then uname -r worked and didn't match any of the
# vulnerable patterns, so we'll print the kernel release and return an OK
# status.
#
printf "OK: %s\n", $release;
exit $ERRORS{OK};

使插件归nagios用户所有，并使用chmod命令使其可执行：

# chown nagios.nagios check_vuln_kernel# chmod 0770 check_vuln_kernel
Run the plugin directly to test it:
# sudo -s -u nagios
$ ./check_vuln_kernel
OK: 2.6.32-5-686

现在我们应该能够像使用任何其他命令一样，在命令中使用该插件，从而在服务检查中使用它。请注意，本书的代码包中包含了该插件的代码，方便您参考。

它是如何工作的...

我们在新插件文件check_vuln_kernel中添加的代码其实非常简单：

它运行uname -r来获取内核的版本号。
如果这不起作用，它会以UNKNOWN状态退出。
如果版本号与包含关键版本号的模式匹配，它会以CRITICAL状态退出。
如果版本号与包含警告版本号的模式匹配，它会以WARNING状态退出。
否则，它会以OK状态退出。

它还会打印状态作为字符串，并附带内核版本号，如果它能够成功获取的话。

我们可能会按如下方式为此插件设置命令定义：

define command {
    command_name  check_vuln_kernel
    command_line  $USER1$/check_vuln_kernel
}

反过来，我们可能会按如下方式为该命令设置服务定义：

define service {
    use                  local-service
    host_name            localhost
    service_description  VULN_KERNEL
 check_command        check_vuln_kernel
}

如果内核没有漏洞，服务在 Web 界面中的显示可能类似于以下截图：

然而，如果监控服务器本身运行的是一个有漏洞的内核，那么它的显示可能更接近以下截图（并且如果配置了通知，它会发送后续通知）：

还有更多...

这可能是一个简单的插件，但它的结构可以泛化为各种监控任务。如果我们能找出正确的逻辑，在合适的编程语言中返回我们想要的状态，那么我们就可以编写一个插件，几乎做任何事情。

这样一个插件同样可以用 C 语言编写，以提高性能，但为了简便起见，我们假设插件不需要高性能。相反，我们可以使用更适合快速临时脚本的语言；在这种情况下，我们使用 Perl。文件utils.sh，也在/usr/local/nagios/libexec中，如果我们更喜欢，也允许我们使用 Shell 脚本编写。

如果您编写了一个插件，认为它对 Nagios 社区有普遍的使用价值，请考虑将其置于自由软件许可证下，并提交到 Nagios Exchange，以便其他人也能从您的工作中受益。社区的贡献和支持使 Nagios Core 成为一个如此出色的监控平台，并在广泛使用中。

通过这种方式发布的任何插件应该符合 Nagios 插件开发指南。在撰写本文时，这些指南可在nagiosplug.sourceforge.net/developer-guidelines.html找到。

最后，您应该注意，示例中使用的utils.pm方法可能在未来版本的 Nagios Core 中被弃用。为了简便起见，这里使用了这种方法。新的包含方式是通过一个名为Nagios::Plugin的 CPAN 模块来实现的。

另见

本章中的创建新命令和定制现有命令食谱
本章中的创建新服务食谱，见第一章，理解主机、服务和联系人
本章中的使用 NRPE 监控远程机器上的本地服务食谱，见第六章，启用远程执行

第三章：与检查和状态的工作

本章将涵盖以下内容：

指定检查主机或服务的频率。
更改 PING RTT 和数据包丢失的阈值。
更改磁盘使用的阈值。
为主机或服务安排停机时间。
通过波动管理短期停机。
调整服务的波动百分比阈值。

引言

一旦在 Nagios Core 中配置了主机和服务，它的行为主要由它所执行的检查决定，以确保主机和服务按预期运行，并且根据这些检查得出的结论，主机和服务必须处于的状态。

检查主机和服务的频率以及何时标记主机或服务为存在问题，取决于服务的性质及其始终运行的重要性。比如，若检查位于世界另一端的主机，且在繁忙时段它的往返时间超过 100 毫秒，那么这可能并不会引起任何关注，甚至可能不需要标记为 WARNING 状态，更不用说 CRITICAL 状态了。

然而，如果同一主机位于本地网络，期望往返时间小于 10 毫秒，那么超过 100 毫秒的往返时间可能就会被视为一个严重问题，可能是局部网络出现了数据包风暴或其他问题，并且我们需要立即通知相关管理员。同样，对于像 Web 服务器这样的主机，可能对于繁忙的共享网站主机上页面的响应时间超过一秒并不关心。但如果公司网站或专用托管客户的响应时间变得如此糟糕，可能就需要通知 Web 服务器管理员。

因此，主机和服务并不是完全相同的。Nagios Core 提供了几种方式来更精确地定义行为，具体如下：

使用适当的 check_command 插件，规定主机或服务应被检查的频率。
检查结果必须达到多差，才会触发 WARNING 或 CRITICAL 问题，若有的话。
为主机或服务定义一个停机时间段，使得 Nagios Core 知道在指定时间段内不需要期望它运行，通常用于升级或其他维护。
是否自动容忍“波动”，即主机和服务看似频繁上下波动的情况。

本章将使用一些常见的主机和服务行为问题实例，展示如何配置它们。

指定检查主机或服务的频率。

在这个示例中，我们将配置一个非常重要的主机，每三分钟检查一次，如果 Nagios Core 发现该主机因检查失败而处于 DOWN 状态，它将在一分钟后重新检查该主机，然后再将状态通知其定义的联系人。我们将通过自定义现有主机的定义来完成这一操作。

准备工作

您应该已经配置了至少一个主机的 Nagios Core 3.0 或更新版本的服务器。我们将以sparta.naginet为例，它是在其自己的文件中定义的主机。

您还应该了解命令和插件的基础知识，特别是check_command指令的含义。相关内容在第二章中有讲解，命令与插件的使用。

如何操作...

我们可以按如下方式自定义主机的检查频率：

转到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果您将主机定义放在其他文件中，请转到该文件所在的目录：
```
# cd /usr/local/nagios/etc/objects
```

编辑包含您主机定义的文件，并找到该文件中的主机定义：

# vi sparta.naginet.cfg

主机定义可能类似于以下内容：

define host {
    use                 linux-server
    host_name           sparta.naginet
    alias               sparta
    address             10.128.0.21
}

将check_interval指令的值设置或编辑为3：

define host {
    use                 linux-server
    host_name           sparta.naginet
    alias               sparta
    address             10.128.0.21
 check_interval      3
}

将retry_interval指令的值设置或编辑为1：

define host {
    use                 linux-server
    host_name           sparta.naginet
    alias               sparta
    address             10.128.0.21
    check_interval      3
 retry_interval      1
}

将max_check_attempts的值设置或编辑为2：

define host {
    use                 linux-server
    host_name           sparta.naginet
    alias               sparta
    address             10.128.0.21
    check_interval      3
    retry_interval      1
 max_check_attempts  2
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 将每三分钟对该主机运行相关的check_command插件（可能类似于check-host-alive）；如果失败，它将标记该主机为“停机”状态，并在一分钟后再次检查，只有当第二次检查也失败时，才会向定义的联系人发送通知。

如何工作...

上述配置更改了主机对象类型的三个属性，以实现我们所需的更改：

check_interval：这定义了在正常条件下，连续检查主机之间需要等待的时间。我们将其设置为3，即三分钟。
retry_interval：这定义了在首次发现主机问题后，跟进检查之间的等待时间。我们将其设置为1，即一分钟。
max_check_attempts：这定义了在发送通知之前需要运行多少次检查。我们将其设置为2，即进行两次检查。这意味着在第一次检查失败后，Nagios Core 会在一分钟后再进行一次检查，只有当第二次检查也失败时，才会发送通知。如果进行了两次检查且主机仍然处于问题状态，它将从SOFT状态转换为HARD状态。

请注意，在从模板派生的主机中设置这些指令（如我们示例中的情况）将覆盖模板中的相同指令。

还有更多内容...

需要注意的是，我们还可以定义check_interval和retry_interval命令使用的单位。它们默认只使用分钟，检查通常在 Nagios Core 的根配置文件中定义的interval_length设置，默认路径为/usr/local/nagios/etc/nagios.cfg：

interval_length=60

如果我们想要改为以秒为单位来指定这些时间段，我们可以将其值设置为1而不是60：

interval_length=1

这将使我们能够例如将check_interval设置为15，每隔 15 秒检查一次主机。请注意，如果我们有很多主机，并且检查时间很长，这样紧密的检查计划可能会过度负担 Nagios Core 进程。

不要忘记，更改大量主机的这些属性可能很繁琐，因此，如果有必要为多个主机设置这些指令的公共值，那么将这些值设置为主机模板中，并使这些主机从中继承可能是合适的做法。有关详细信息，请参阅《第九章》的使用继承简化配置配方，配置管理。请注意，同样的三个指令也适用于服务声明，并且具有相同的含义。我们可以定义与以下类似的声明来为sparta.naginet上的服务定义相同的通知行为：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP
    check_command        check_http
    address              10.128.0.21
 check_interval       3
 retry_interval       1
 max_check_attempts   2
}

另请参见

在本章的Scheduling downtime for a host配方中
在《第九章》的使用继承简化配置配方中，配置管理，Chapter 9。

更改 PING RTT 和数据包丢失的阈值

在本配方中，我们将为监视 PING 的主机设置一个服务，并查看如何调整WARNING和CRITICAL状态的阈值，使用命令参数完成。我们将通过为已经使用check-host-alive等插件检查的现有主机设置一个服务来实现这一点。我们的服务将用于监控主机是否完全DOWN，而是是否在合理时间内响应 PING 请求。

这对于通知并帮助诊断服务或主机的实际连通性问题可能非常有用。

因此，本配方将作为向命令提供参数以及调整特定服务的WARNING和CRITICAL阈值概念的良好示范。

准备工作

您应该拥有一个 Nagios Core 3.0 或更新的服务器，至少已经配置了一个主机，并且正在使用check_command插件check-host-alive。我们将使用sparta.naginet的例子，这是在其自己的文件中定义的主机。

您还应了解主机和服务在 Nagios Core 配置中如何配合，并熟悉通过check_command指令使用命令和插件的基础知识。

如何做...

我们可以按如下方式将我们的 PING 服务添加到现有主机，并设置自定义的往返时间和数据包丢失阈值：

更改到 Nagios Core 对象配置目录。默认值为/usr/local/nagios/etc/objects。如果您将主机的定义放在不同的文件中，则请转到其目录：
```
# cd /usr/local/nagios/etc/objects
```
编辑包含主机定义的文件：
```
# vi sparta.naginet.cfg
```

在文件末尾添加以下定义。在这里最感兴趣的是check_command指令的值：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  PING
 check_command        check_ping!100,20%!200,40%
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 不仅会对原始主机运行check-host-alive主机检查以确保其处于正常状态，还会作为服务运行更严格的 PING 响应检查，以确保机器有足够的响应能力：

如果往返时间（RTT）大于 100ms（但小于 200ms），Nagios Core 将标记为WARNING状态。
如果 PING 响应的 RTT 大于 200ms，Nagios Core 将标记为CRITICAL状态。
如果超过 20%（但少于 40%）的 PING 请求未收到响应，Nagios Core 将标记为WARNING状态。
如果超过 40%的 PING 请求未收到响应，Nagios Core 将标记为CRITICAL状态。

在这两种情况下，如果已配置通知，则会将通知发送给服务定义的联系人。

否则，该服务与其他服务的工作方式相同，并会出现在 Web 界面中。

工作原理...

我们为现有主机添加的配置创建了一个新服务，其service_description为 PING。对于check_command，我们使用check_ping命令，该命令使用同名插件。这里有趣的部分是check_command定义后面跟着的内容：字符串!100,20%!200,40%。

在 Nagios Core 中，!字符用作分隔符，传递给命令的参数。在check_ping的情况下，第一个参数定义了阈值或条件，如果满足这些条件，Nagios Core 将为该服务标记为WARNING状态。同样，第二个参数定义了CRITICAL状态的阈值。

这两个参数的每个值都由两个以逗号分隔的术语组成：第一个数字是触发状态的 PING 请求及其响应的 RTT 阈值，第二个数字是应该容忍的丢包百分比，超过该值会触发相同的状态。

这种参数模式是check_ping特有的；它们不适用于其他命令，如check_http。

还有更多...

如果我们想更详细地查看这些参数是如何应用的，可以检查check_ping的命令定义。默认情况下，这在/usr/local/nagios/etc/objects/commands.cfg文件中，内容类似于以下内容：

define command {
    command_name  check_ping
    command_line  $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

在command_line的值中，使用了四个宏：

$USER1$ ：这会展开为/usr/local/nagios/libexec，即 Nagios Core 插件（包括check_ping）通常存放的目录。
$HOSTADDRESS$ ：这会展开为命令所用主机或服务定义的主机名。在此例中，它展开为10.128.0.21，即sparta.naginet主机的address指令的值。
$ARG1$ ：这会展开为命令第一个参数的值，在我们本例中，是字符串100,20%。
$ARG2$ ：此选项扩展为命令的第二个参数的值；在我们的配方中，字符串为200,40%。

对于我们特定检查的完整命令行调用，应用所有这些替换后，应该类似于以下内容：

/usr/local/nagios/libexec/check_ping -H 10.128.0.21 -w 100,20% -c 200,40% -p 5

此命令行利用了check_ping程序的四个参数：

-H：此选项指定要检查的主机的地址
-w：此选项指定提升为WARNING状态的阈值
-c：此选项指定提升为CRITICAL状态的阈值
-p：此选项指定要发送的 PING 请求的数量

我们可以直接从 Nagios Core 服务器的命令行运行此命令，以查看检查结果可能是什么：

# /usr/local/nagios/libexec/check_ping -H 10.128.0.21 -w 100,20% -c 200,40% -p 5

上述命令输出包括检查的OK结果，还包括一些性能数据，具体如下：

PING OK - Packet loss = 0%, RTA = 0.17 ms|rta=0.174000ms;100.000000;200.000000;0.000000 pl=0%;5;10;0

命令中指定的参数因此用于定制check_command的行为，以适应特定主机或服务的编辑。

另见

本章中的磁盘使用阈值变化配方
第一章中的创建新服务配方，理解主机、服务和联系人
第二章中的自定义现有命令和创建新命令配方，使用命令和插件
本章中的监控任何主机的 PING配方在第五章中，监控方法

磁盘使用阈值变化

在这个配方中，我们将配置 Nagios Core 服务器来检查其自身的磁盘使用情况，并根据磁盘剩余的可用空间多少，标记为WARNING或CRITICAL状态。我们将通过向已定义的localhost添加一个名为DISK的新服务来实现这一点，该服务将运行check_local_disk命令来检查服务器上挂载卷的状态。

由于不断增长的磁盘使用情况可能会悄然增加，对于任何系统管理员来说，如果磁盘在没有任何警告的情况下突然完全填满，这将产生严重的影响，因此这是任何网络中最重要的监控内容之一。

为简便起见，我们仅在监控服务器本身上演示这一点，作为一个名为localhost的主机，IP 地址为127.0.0.1。这是因为check_disk插件无法直接检查远程服务器的磁盘使用情况。然而，这里讨论的原则可以适应使用check_nrpe在远程服务器上运行检查。NRPE 的使用在第六章，启用远程执行中的所有配方中都有讨论。

准备工作

你应该拥有一个 Nagios Core 3.0 或更新版本的服务器，并且应有一个针对 localhost 的定义，这样监控主机才能对自身进行检查。localhost 的主机定义包含在 /usr/local/nagios/etc/objects/localhost.cfg 中的示例配置文件中。你还应该了解 Nagios Core 配置中主机和服务的基本结构，并熟悉通过 check_command 指令使用命令和插件。

我们将以 olympus.naginet 作为我们的 Nagios Core 服务器进行自检的例子，其中有一个磁盘的块设备，设备文件位于 /dev/sda1。

如何执行...

我们可以通过以下方式将 DISK 服务添加到现有主机中，并自定义使用阈值：

切换到 Nagios Core 的对象配置目录。默认目录是 /usr/local/nagios/etc/objects。如果你将主机定义放在了不同的文件中，请转到相应的目录：
```
# cd /usr/local/nagios/etc/objects
```
编辑包含主机定义的文件：
```
# vi localhost.cfg
```

将以下定义添加到文件的末尾。这里最重要的是 check_command 指令的值：

define service {
    use                  local-service
    host_name            localhost
    service_description  DISK
 check_command        check_local_disk!10%!5%!/dev/sda1
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这些操作后，为 localhost 创建了一个新服务，检查 /dev/sda1 上的磁盘使用情况。如果可用空间低于 10%，该服务将标记为 WARNING 状态；如果低于 5%，则标记为 CRITICAL 状态。

在这两种情况下，都会向服务的已定义联系人发送通知（如果已配置）。

它是如何工作的

我们为现有主机添加的配置创建了一个新的服务，service_description 为 DISK。对于 check_command，我们使用了 check_local_disk 命令，该命令又使用了 check_disk 插件来检查本地机器的磁盘。这里的重点是 check_local_disk 定义后面的内容：字符串 !10%!5%!/dev/sda1。

在 Nagios Core 中，! 字符用作分隔符，用于分隔应传递给命令的参数。在 check_local_disk 的例子中，前两个参数定义了阈值或条件，当条件满足时，Nagios Core 将标记服务为 WARNING 状态（第一个参数，10%）或 CRITICAL 状态（第二个参数，5%）。第三个参数定义了要检查的磁盘设备名，即 /dev/sda1。

还有更多内容...

如果我们想更详细地查看这些参数是如何应用的，可以检查 check_local_disk 的命令定义。默认情况下，该定义位于 /usr/local/nagios/etc/objects/commands.cfg 文件中，类似于以下内容：

define command {
    command_name  check_local_disk
    command_line  $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$
}

在这种情况下，command_name 和 command_line 中使用的插件名称不同。

在 command_line 的值中，使用了四个宏：

$USER1$ ：该参数展开为 /usr/local/nagios/libexec，即通常存放 Nagios Core 插件的目录，包括 check_disk。
$ARG1$ ：该参数展开为命令的第一个参数的值；在此案例中，该值为字符串 10%。
$ARG2$ ：此参数展开为命令的第二个参数值；在此例中，字符串为 5%。
$ARG3$ ：此参数展开为命令的第三个参数值；在此例中，字符串为 /dev/sda1。

对我们特定检查的完整命令行调用，所有这些替换完成后，将如下所示：

/usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/sda1

该命令行使用了 check_disk 程序的三个参数：

-w：此参数指定触发 WARNING 状态的阈值
-c：此参数指定触发 CRITICAL 状态的阈值
-p：此参数指定要检查的磁盘的设备文件

我们可以直接从 Nagios Core 服务器的命令行运行这个命令，查看检查的结果是什么：

# /usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/sda1

输出包括检查的 OK 结果，以及一些性能数据：

DISK OK - free space: / 2575 MB (71% inode=78%);| /=1044MB;3432;3051;0;3814

另请参阅

本章中的更改磁盘使用阈值示例
第一章中的创建新服务的示例，理解主机、服务和联系人
第二章中的定制现有命令和创建新命令的示例，与命令和插件一起工作
第五章中的监控主机的 PING的示例，监控方法

为主机或服务安排停机时间

在这个示例中，我们将学习如何在 Nagios Core 中为主机或服务安排停机时间。这对于优雅地抑制某些可预测时间段的通知非常有用；一个很好的例子是当服务器需要停机进行升级或硬件检查时。

在此示例中，我们将演示如何为名为 sparta.naginet 的主机安排停机时间，并查看它在 Web 界面中的变化。

准备工作

你应该有一个 Nagios Core 3.0 或更新版本的服务器，并至少定义了一个主机和一个服务，并对你希望安排停机时间的时段有所了解。同时，你应该根据 Nagios Core 3.0 的快速入门安装指南拥有一个可用的 Web 界面。

你还应该配置好 Nagios Core 来处理外部命令，并为你的 Web 界面用户授予应用这些命令的权限。如果你按照推荐的快速入门指南以 nagiosadmin 用户登录，那么你可以通过在 /usr/local/nagios/etc/nagios.cfg 中使用以下指令来检查是否已经配置好：

check_external_commands=1

从 Web 界面提交外部命令的权限定义在 /usr/local/nagios/etc/cgi.cfg 中；检查你的用户名是否被包含在这些指令中：

authorized_for_all_service_commands=nagiosadmin
authorized_for_all_host_commands=nagiosadmin

如果你按照 Nagios Core 快速入门指南操作，那么你可能会发现它已经正常工作：nagios.sourceforge.net/docs/3_0/quickstart.html。

如何操作...

我们可以按照以下方式为我们的主机和服务设置一个固定的计划停机时间：

登录到 Nagios Core 的 Web 界面。
点击左侧菜单中的主机：
点击弹出表格中主机名称，以查看该主机的详细信息：
在主机命令菜单中点击为此主机安排停机时间：
在结果表单中填写相关字段，包括以下细节：
- 主机名称：您为其安排停机时间的主机名称。此项应已为您填写。
- 作者：您的姓名，用于记录是谁安排了停机时间。这项可能会显示为灰色，并显示Nagios 管理员；这没问题。
- 注释：解释停机原因的注释。
- 开始时间：安排的停机时间应开始的时间，届时状态通知将结束。
- 结束时间：安排的停机时间应结束的时间，届时状态通知将恢复。
在这种情况下，我们的停机时间将是 2012 年 6 月 15 日晚上 8:00 到 9:00。
点击提交以提交停机时间定义，然后在接下来的屏幕中点击完成。

完成此操作后，我们可以在指定的时间内安全地将sparta.naginet主机下线，并且在停机时间结束之前，任何与该主机及其服务相关的通知都会被抑制。

请注意，重启 Nagios Core 在此步骤中不是必需的，因为通常对于 Nagios Core 配置文件的更改，重启是必须的。此更改是“即时生效”的。

还要注意，注释现在会出现在主机和服务的详细信息中，定义了停机时间，并包括为其指定的原因。

它是如何工作的...

上述步骤为sparta.naginet服务器及其所有服务指定了一个停机时间段。这实现了两件事：

它会抑制主机或服务在适当时间段内的所有通知（无论是电子邮件还是其他形式的通知），包括恢复通知。唯一的例外是停机开始和停机结束通知。
它会在主机或服务上添加注释，显示已安排的停机时间，以便其他可能使用 Web 界面的用户参考。

Nagios Core 跟踪所有主机和服务的停机时间，并在此期间阻止它通常会发送的通知。请注意，它仍然会进行检查并记录主机和服务的状态，即使在停机期间也是如此。被抑制的只是通知，而不是实际的检查。

还有更多...

请注意，单个服务的停机时间也可以通过类似的方式应用，方法是在 Web 界面中点击为此服务安排停机时间，位于服务命令下。

本食谱中定义的是一种定义固定停机时间的方法，在这种方法中，我们提前知道主机或其服务何时可能不可用。如果我们实际上不知道停机开始的时间，但我们知道它可能持续多久，那么我们可以定义一个灵活的停机时间。这意味着停机可以在指定的时间段内的任何时间开始，并且从那时起会持续我们指定的时间。

当主机或服务开始停机时，会触发一个通知事件，称为DOWNTIMESTART，停机结束时会触发另一个通知事件，称为DOWNTIMEEND。如果相关联系人或联系人组希望在这种情况下接收通知，这可能是一个有用的通知。可以通过确保主机或服务配置为发送这些消息来安排此操作，在主机和服务的notification_options指令中包括s标志，并相应地在联系人定义中进行配置：

notification_options  d,u,r,f,s

另见

本章中的管理短暂的停机并处理波动和调整服务的波动百分比阈值食谱
第四章中的指定要通知的状态和容忍一定数量的失败检查食谱，配置通知
第七章中的在网页界面上添加主机或服务的评论食谱，使用 Web 界面

管理短暂的停机并处理波动

在本食谱中，我们将学习如何使用 Nagios Core 的状态波动检测和处理功能，避免在主机或服务的状态变化过于频繁时发送过多的通知。这在主机或服务在最后 21 次检查中频繁地在OK、WARNING和CRITICAL状态之间变化时非常有用。如果状态变化的百分比过高，Nagios Core 将抑制进一步的通知，并在主机或服务上添加一个图标和注释，显示它正在波动。

波动检测通常在 Nagios Core 的快速启动配置中启用，并且是示例generic-host主机模板和generic-service服务模板的一部分。因此，大多数服务器上可能已经启用了该功能，我们只需要检查它是否仍然有效。

准备工作

你应该已经配置了一个 Nagios Core 3.0 或更高版本的服务器，并且至少有一个主机和一个服务已配置。你还应该能够访问 Nagios Core 服务器的工作网页界面。如果你正在监控一个可以启停的测试服务以触发波动检测来进行测试，那会很有帮助；一个未使用的 Web 服务器可能很适合这个目的。

你应该熟悉主机和服务因检查而改变状态的方式，并了解与主机和服务相对应的不同状态，以便理解波动检测的基本原理。

如何操作...

我们可以通过以下方式检查是否已启用 Nagios Core 服务器、主机和服务的波动检测：

切换到 Nagios Core 的配置目录。默认路径是/usr/local/nagios/etc。
```
# cd /usr/local/nagios/etc
```
编辑nagios.cfg文件。
```
# vi nagios.cfg
```
查找enable_flap_detection指令的现有定义，并检查其是否设置为1：
```
enable_flap_detection=1
```
如果未将其设置为1，则在我们更改后，可能还需要暂时禁用同一文件中的use_retained_program_state指令：
```
use_retained_program_state=0
```
编辑我们特定主机或服务的文件。我们应该检查至少满足以下之一的情况：
- 主机或服务继承自一个模板，该模板将enable_flap_detection指令设置为1。例如，默认在/usr/local/nagios/etc/objects/templates.cfg中定义的generic-host和generic-service模板都做到了这一点。
- 主机或服务本身在其定义中将enable_flap_detection指令设置为1。
  
  在后一种情况下，主机或服务的配置可能类似于以下代码片段：
```
define host {
    ...
 flap_detection_enabled 1
}
define service {
    ...
 flap_detection_enabled 1
}
```

如果之前的配置有所更改，请验证新的配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

检查希望启用波动检测的主机或服务的详细信息中，是否出现了ENABLED字样：

完成此操作后，如果主机或服务在 21 次检查内频繁更改状态，则会被标记为波动，并在该主机或服务的视图中显示自定义图标：

在主机或服务上也会有一条注释，解释发生了什么，以便任何在 Web 界面查看该主机或服务的人理解为什么通知停止：

主机或服务的详细信息中还会有一个指示器，定义主机或服务是否处于波动状态：

对于未启用波动检测的主机或服务，该字段将简单地显示N/A，并且下方的Flap Detection字段将显示为DISABLED。

它是如何工作的...

确定波动检测的逻辑实际上是相当复杂的。就我们的目的而言，足以将波动检测解释为基于主机或服务在其最后 21 次检查中是否过于频繁地更改状态——这些阈值通常以百分比表示。

这在 Nagios Core 3.0 文档中有详细讨论，包括用于确定波动状态的公式，文档可以在线查阅，网址如下：

nagios.sourceforge.net/docs/3_0/flapping.html

还有更多内容...

振荡的常见原因是检查条件过于严格。举个例子，如果你检查一个共享 Web 服务器的响应时间是否小于 50ms，而服务器正在忙碌，那么检查可能会通过或失败，但并未准确反映服务是否正常工作。在这种情况下，适当放宽服务的阈值，通过提高其百分比阈值，使得它不那么容易因为一些其实并不令人担忧的问题就标记为WARNING或CRITICAL状态。振荡检测有助于诊断此类情况。

我们还可以通过 Web 界面为主机启用或禁用振荡检测；在主机和服务的详细信息屏幕中，主机命令下有一个菜单项，标记为为此主机启用/禁用振荡检测，在服务命令下还有一个标记为为此服务启用/禁用振荡检测。

当我们希望暂时启用或禁用特定主机或服务的振荡检测时，这些配置可能会很有用，可能因为在某些情况下使用该功能不合适或不必要。为了永久设置并保持清晰，最好按照配方中所示的方式在配置中显式包含它。

另见

本章中的调整服务的振荡百分比阈值配方
第四章中的容忍一定数量的失败检查配方，配置通知
第七章中的在 Web 界面上添加主机或服务的注释配方，与 Web 界面协作

调整服务的振荡百分比阈值

在这个配方中，我们将学习如何调整主机或服务的振荡检测百分比阈值。这意味着我们可以调整主机或服务在其最后 21 次检查中必须发生多少次状态变化，才能让 Nagios Core 认为它正在振荡，并抑制通知，直到它的状态再次变得稳定。

准备工作

你应该已经配置了至少一台主机和一项服务的 Nagios Core 3.0 或更高版本的服务器。你还应该可以访问 Nagios Core 服务器的工作 Web 界面。

你应该熟悉主机和服务如何因其检查而改变状态，以及与主机和服务对应的不同状态，以理解振荡检测如何工作的基本原理。振荡检测也应该已经为适当的主机和服务启用并正常工作。

操作方法...

我们可以按如下方式调整特定主机或服务的振荡检测阈值：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```
编辑包含我们要设置阈值的主机或服务定义的文件：
```
# vi sparta.naginet.cfg
```

在主机或服务定义中，将low_flap_threshold和/或high_flap_threshold值设置为适当的百分比：

define host {
    ...
 high_flap_threshold 50.0
 low_flap_threshold 25.0
}
define service {
    ...
 high_flap_threshold 45.0
 low_flap_threshold 20.0
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，主机或服务的波动阈值应适当调整，以便进行未来的检查。

它是如何工作的...

前述的配置更改包括以下指令：

high_flap_threshold：如果主机或服务在一定时间内发生状态变化的百分比，必须超过此百分比阈值，才会被确定为波动状态。
low_flap_threshold：如果主机或服务已经处于波动状态，则其状态变化百分比必须低于此阈值，波动状态才会结束。

关于状态变化百分比如何计算的详细信息，请参见 Nagios Core 3.0 的在线文档，网址如下：

nagios.sourceforge.net/docs/3_0/flapping.html

还有更多...

如果合适，我们还可以通过在/usr/local/nagios/etc/nagios.cfg文件中添加以下指令，设置主机和服务的全局默认波动阈值。以下值为示例：

high_host_flap_threshold=50.0
low_host_flap_threshold=25.0
high_service_flap_threshold=45.0
low_service_flap_threshold=20.0

这些值对应于状态变化的百分比，方式与每个主机和服务的配置相同。

请注意，在这种情况下，主机和服务有各自的指令。如果为特定服务或主机指定了阈值，如我们在示例中所做的，这些值也会被覆盖。

另见

本章中的管理短暂故障与波动示例

第四章：配置通知

在本章中，我们将涵盖以下内容：

配置通知周期
配置组的通知
指定需要通知的状态
容忍一定数量的检查失败
自动化联系人轮换
为重复通知定义升级
定义自定义通知方法

简介

Nagios Core 中的通知是指当主机或服务状态变化时触发的事件和生成的消息，目的是通知相关人员或系统。

例如，当与主机的连接丢失时，它会离开UP状态并在下次检查时进入DOWN状态。这最终会生成一个通知事件，只要设置了适当的标志并且有可用的联系人，关于状态变化的消息就会生成并按照配置的方式处理。

此类通知的默认文本详细描述了问题，包括来自相应插件命令的输出：

***** Nagios *****
Notification Type: PROBLEM
Host: sparta.naginet
State: DOWN
Address: 10.128.0.21
Info: CRITICAL - Host Unreachable (10.128.0.21)
Date/Time: Sat May 19 16:27:39 NZST 2012

因此，随着事件生成这种文本，接下来的问题是 Nagios Core 应该如何处理它。大多数 Nagios Core 管理员都会熟悉通过系统邮件发送此文本作为电子邮件消息的常见通知方法，但同样生成的消息可以以多种方式使用。就像命令可以灵活定义其运行的命令行一样，适用于特定联系人的操作也可以非常灵活地定义，使用任何联系人被配置接收的通知文本。

在本章中，我们将学习如何优化 Nagios Core 中的通知管理，以确保适当的人或系统能收到相关网络事件的通知，而不被不重要的事件打扰。我们还将学习如何设置超越简单电子邮件消息的通知方法，并且当问题在一定时间内未得到解决时，如何升级通知。

配置通知周期

在本例中，我们将调整配置，解决一个在深夜频繁发出通知的服务。我们将安排对主机sparta.naginet进行 24 小时全天候监控，但我们会使用默认 Nagios Core 配置中的两个预定义时间周期，避免其在工作时间以外发送通知。

准备工作

你应该已经拥有一个 Nagios Core 3.0 或更新版本的服务器，并且至少配置了一个主机。我们将使用sparta.naginet作为示例，这个主机在其自己的文件中定义。

如何操作...

我们可以为主机定义check_period和notification_period插件，如下所示：

进入 Nagios Core 的对象配置目录。默认目录是/usr/local/nagios/etc/objects。如果你的主机定义在其他文件中，则转到其目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件，并在文件中找到相应的定义：

# vi sparta.naginet.cfg

主机定义可能类似于以下代码片段：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
}

将 check_period 指令的值添加或编辑为 24x7：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
 check_period         24x7
}

将 notification_period 指令的值添加或编辑为 workhours：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
    check_period         24x7
 notification_period  workhours
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 将始终对主机进行检查（每天 24 小时，每周 7 天），包括记录 UP 和 DOWN 状态，并在网页界面和报告中显示，但只会在工作时间内（默认从早上 9 点到下午 5 点，周一至周五）向指定的联系人发送通知。

它是如何工作的……

上述配置更改了主机对象类型的两个属性，以实现所需的更改：

check_period：此指令定义了应检查主机的时间段；我们选择了预定义的时间段24x7，意味着无论白天还是夜晚，都会对主机进行检查。
notification_period：此指令定义了主机应在何时向适当的联系人发送通知；我们选择了预定义的时间段 workhours，意味着通知只会在早上 9 点到下午 5 点之间发送，周一至周五。

相同的配置可以精确地应用于服务，而不是主机：

define service {
    ...
 check_period         24x7
 notification_period  workhours
}

这个新配置所涉及的两个时间段本身是在 Nagios Core 配置中定义的。我们使用的 24x7 和 workhours 是默认包含的标准时间段，保存在 /usr/local/nagios/etc/objects/timeperiods.cfg 文件中。例如，workhours 的定义类似于以下代码片段：

define timeperiod {
    timeperiod_name  workhours
    alias            Normal Work Hours
    monday           09:00-17:00
    tuesday          09:00-17:00
    wednesday        09:00-17:00
    thursday         09:00-17:00
    friday           09:00-17:00
}

这里使用的只是常见时间段的示例。我们可以非常精确地定义时间段；有关如何操作的更多细节，请参考第一章中的 创建新时间段 章节。

还有更多……

这两个指令的区别非常重要。在大多数情况下，我们会希望 check_period 指令对应全天候服务的时间段，因为这样可以保留该服务的长期正常运行时间信息。而保留一个独立的 notification_period 指令，主要是为了控制通知的发送时间，可能是因为否则通知会发送到寻呼机，打扰到一位心情不佳的系统管理员，尤其是对于一些相对不重要的系统！

在 Nagios Core 配置中，将 check_period 插件设置为较短的时间段（例如 workhours）是有效的。但除非主机在这些时间段之外会实际停止运行，否则通常不需要这么做。在大多数情况下，适当的做法是将 24x7 时间段作为 check_period 的值。

另请参阅

本章中的配置组通知食谱
在第一章中的创建新时间段食谱，理解主机、服务和联系人
在第三章中的指定检查主机或服务的频率食谱，使用检查和状态

配置组通知

在本食谱中，我们将学习如何为主机定义一个联系人组。我们将展示这是如何作为一种通用最佳实践来实现的，即将通知发送到联系人组，而不是单个联系人，这样可以更灵活地将单个联系人分配到适当的组中，以接收相应的通知。

准备工作

您应当已经有一个 Nagios Core 3.0 或更高版本的服务器，并且至少配置了一个主机。我们将使用sparta.naginet的示例，这是一个在其自己文件中定义的主机，我们将配置它将通知发送到一个名为noc的现有联系人组。

操作步骤...

我们可以按照以下方式配置通知，发送到我们的联系人组：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果您将主机的定义放在了其他文件中，请转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```
确保为您打算发送通知的组定义了一个适当的contact_group。有效的定义可能类似于以下代码片段，可能存放在contacts.cfg中：
```
define contactgroup {
    contactgroup_name  noc
    alias              Network Operations
    members            john,jane
}
```

如果组中引用了任何联系人，您应确保这些联系人也已定义。它们可能类似于以下代码片段：

define contact {
    use            generic-contact
    contact_name   john
    alias          John Smith
    email          john@naginet
}
define contact {
    use            generic-contact
    contact_name   jane
    alias          Jane Doe
    email          jane@naginet
}

编辑包含主机定义的文件，并在文件中找到相应的定义：

# vi sparta.naginet.cfg

主机定义可能类似于以下代码片段：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21notification_period  24x7
}

将contact_groups指令的值添加或编辑为noc：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
    notification_period  24x7
 contact_groups       noc
}

如果主机已经定义了联系人，您可能希望将它们删除，尽管这不是必须的。

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此步骤后，所有针对此主机的通知应发送给noc组的每个成员；在我们的示例中，联系人是jane和john。

工作原理...

定义应该接收特定主机通知的联系人，可以通过单独引用它们、作为组或两者结合来完成。我们本可以通过将主机的contacts指令定义为jane,john，直接引用单个联系人，而不是通过其组名，来实现与前面相同的结果。

设置服务的联系人组（而不是主机）时，几乎相同的配置过程适用；我们只需在service定义中为contact_groups指令添加一个值：

define service {
    ...
 contact_groups  noc
}

当主机或服务发生事件并触发通知时，如果该事件设置了有效的notification_option标志，Nagios Core 将检查主机的contacts和contact_groups指令的值，以确定向谁发送通知。在我们的例子中，服务器发现contact_groups的值是noc，因此会引用该联系人组以识别其中的单个联系人，并将通知发送给每个联系人。

还有更多...

选择哪种方法来定义主机或服务的联系人，无论是通过单独的联系人引用还是通过组，这取决于你自己。对于大量的主机和服务，通常将通知定向到适当的组比定向到个人更为容易，因为它可以通过简单地更改组中的个人来为我们提供更多灵活性，选择发送通知给谁。

你需要为主机或服务定义至少一个联系人或联系人组，或者通过模板继承一个联系人组，才能使其成为 Nagios Core 的有效配置。

另见

本章中的配置通知周期、指定需要通知的状态以及自动化联系人轮换教程
第一章中的创建新联系人和创建新联系人组教程，理解主机、服务和联系人。

指定需要通知的状态

在这个教程中，我们将学习如何细化由主机或服务发送的通知类型，以及特定联系人应接收哪些通知。我们将通过修改主机和服务应生成的通知类型，以及配置联系人的接收通知类型来实现这一目标。

准备工作

你应该拥有一个 Nagios Core 3.0 或更高版本的服务器，并且已经配置了至少一个主机。我们将使用sparta.naginet的例子，它是一个在自己文件中定义的主机，我们将配置它仅发送DOWN和RECOVERY通知，忽略其他如WARNING和UNKNOWN的通知。它将把通知发送给名为john的现有联系人；我们会确保这个联系人已经配置为接收这些通知。

如何操作...

我们可以按如下方式配置主机的通知类型：

切换到 Nagios Core 的objects配置目录。默认目录是/usr/local/nagios/etc/objects。如果你将主机的定义放在了不同的文件中，则转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。它可能看起来像以下代码片段：

define host {
    use                    linux-server
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    contacts               john
    notification_period    24x7
}

为notification_options指令添加一个值。在我们的例子中，我们将使用d,r，对应于DOWN和RECOVERY状态的通知：

define host {
    use                    linux-server
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    contacts               john
    notification_period    24x7
 notification_options   d,r
}

我们还应确保该主机的通知已启用，具体来说，notifications_enabled应设置为1。设置此项以及其他相关指令的一个简单方法是让主机继承一个模板，如之前所做的linux-server，但如果我们愿意，也可以显式地设置它：

define host {
    use                    linux-server
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    contacts               john
    notification_period    24x7
    notification_options   d,r
 notifications_enabled  1
}

编辑包含主机指定联系人定义的文件，或其指定联系人组内的联系人。在这种情况下，我们正在编辑主机的指定联系人john。定义可能如下所示：
```
define contact {
    use           generic-contact
    contact_name  john
    alias         John Smith
 email         john@naginet
}
```
编辑或设置每个联系人的host_notification_options指令，以包括与您为主机设置的相同值。在这种情况下，我们将其设置为d、u、r，这意味着John Smith可以接收有关主机的DOWN、UNREACHABLE和RECOVERY通知：
```
define contact {
    use                        generic-contact
    contact_name               john
    alias                      John Smith
    email                      john@naginet
 host_notification_options  d,u,r
}
```
同样，您应确保联系人配置为接收主机通知，方法是将host_notifications_enabled指令设置为1。我们可以通过继承一个模板，如generic-contact，这通常更简单，或者我们可以显式地设置它：
```
define contact {
    use                         generic-contact
    contact_name                john
    alias                       John Smith
    email                       john@naginet
    host_notification_options   d,r
 host_notifications_enabled  1
}
```
接收服务通知的类似指令是service_notifications_enabled。

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，当主机进入DOWN状态时，发送的通知应发送给联系人，并且当主机恢复到OK状态时也应发送通知，但不应发送有关该主机的其他通知（例如UNREACHABLE或DOWNTIMESTART通知）给联系人john。

它是如何工作的...

主机应产生的通知类型由其notification_options指令定义，而定义的联系人应接收的主机通知类型由其host_notification_options指令配置。两者都采用以逗号分隔的值的形式。

notification_options指令对于主机对象的有效值是：

d: 主机处于DOWN状态时的通知
u: 主机处于UNREACHABLE状态时的通知
r: 主机从问题中恢复（变为UP）时的通知
f: 主机开始或结束颠簸状态时的通知
s: 主机开始或结束计划的停机时间时的通知

例如，对于一个主机，当其进入DOWN或UP状态时应发送通知，但忽略UNREACHABLE或颠簸的通知事件，我们可以定义如下：

define host {
    ...
 notification_options d,r
}

对于服务对象，合法的指令稍有不同：

w: 服务处于WARNING状态时的通知
u: 服务处于UNKNOWN状态时的通知
c: 服务处于CRITICAL状态时的通知
r: 服务从故障中恢复（变为OK）时的通知
f: 服务开始或结束颠簸状态时的通知
s: 服务开始或结束计划的停机时间时的通知

例如，对于一个主机，我们希望它为所有这些事件发送通知，但排除波动和计划停机状态，我们可能会定义以下内容：

define service {
    ...
 notification_options  w,u,c,r
}

上述所有值可以在联系对象定义中使用，通过service_notification_options指令来限制特定联系人应接收的服务通知：

define contact {
    ...
 service_notifications_enabled  1
 service_notification_options   w,u,c,r
}

还有更多内容...

除非我们有特别的原因让某些联系人不接受某种特定类型的通知，否则最好配置联系人以接收所有发送给他们的通知，通过在联系人指令中包括所有标志：

define contact {
    ...
 host_notification_options     d,u,r,f,s
 service_notification_options  w,u,c,r,f,s
}

这意味着该联系人将处理所有发送给它的通知，我们可以通过限制由该联系人管理的主机和服务发送的通知类型来替代这一点。对于新的配置，通常最好从发送过多的信息开始，然后在适当时删除不必要的通知标志，而不是因为从未发送而错过重要消息。

如果我们打算对所有的联系人执行此操作，可能需要将这些指令作为联系模板的一部分，并通过use指令从中继承。默认配置中包含的generic-contact联系模板可能适用。

如果你想完全禁用给定主机、服务或联系人的通知，可以为notification_options、host_notification_options和service_notification_options使用单一值n来实现。

另见

本章中的配置组通知、自动化联系人轮换和定义自定义通知方法配方
本书中第九章的使用继承简化配置配方，配置管理

容忍一定数量的失败检查

在本配方中，我们将学习如何安排 Nagios Core 配置，仅在主机或服务的检查失败且重复一定次数后，才发送关于问题的通知。

这对于那些偶尔会出现“波动”或短暂宕机的非关键主机来说是一个理想的配置安排，只有在多次检查后仍然处于宕机状态时才会变得有问题。

准备就绪

你应该有一个 Nagios Core 3.0 或更新版本的服务器，并且已经配置了至少一个主机。我们将使用sparta.naginet这个例子，它是一个在其自身文件中定义的主机。我们将安排它仅在进行五次连续失败检查后才向我们发送通知。

如何操作...

我们可以配置容忍失败检查的次数，然后才发送通知，方法如下：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你的主机定义在其他文件中，请转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件，并找到其中的定义。它可能类似于以下代码片段：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
    notification_period  24x7
}

将max_check_attempts的值添加或编辑为5：

define host {
    use                  linux-server
    host_name            sparta.naginet
    alias                sparta
    address              10.128.0.21
    notification_period  24x7
 max_check_attempts   5
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此设置后，Nagios Core 将在主机进入DOWN状态之前，不会发送通知，直到检查已尝试了五次且每次都失败。在以下截图中，尽管已经进行了四次检查并失败，但没有发送通知，并且状态被列为SOFT：

SOFT状态表示，尽管 Nagios Core 已将主机标记为DOWN，它将继续重试检查，直到用尽max_check_attempts。此时，它将标记主机为HARD DOWN状态并发送通知。

然而，如果主机在下一次检查之前恢复，那么状态将会恢复为UP，而不会发送任何通知：

它是如何工作的...

前面的配置修改了主机的max_check_attempts指令，用于指定在主机标记为HARD DOWN或UNREACHABLE状态并生成通知事件之前，需要失败的检查次数。

更改服务在发送通知之前的最大尝试次数的过程是相同的；我们向服务的定义中添加相同的指令和值：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP
    check_command        check_http
 max_check_attempts   5
}

还有更多...

在发送任何通知之前，主机的连续重试检查之间的时间间隔也可以通过retry_interval指令进行自定义。默认情况下，间隔以分钟为单位，因此如果我们想配置两分钟的重试等待时间，可以向主机或服务添加此指令：

define host {
    ...
 retry_interval  2
}
define service {
    ...
 retry_interval  2
}

另见

第三章中的指定检查主机或服务的频率和通过抖动管理短期故障配方，与检查和状态一起工作

自动化联系人轮换

在这个配方中，我们将学习如何自动安排通知，以便它们仅在特定时间由某些组中的联系人接收。

对于拥有多名专职网络工作人员的公司，通常会有一个值班名单，某个员工在一定时间内（可能是一周或两周）担任专职值班人员。我们在这里配置的这种设置允许过滤通知，使其仅在适当的时间发送给联系人；通知由主机和服务生成，并发送给指定组中的所有联系人，但实际上只有一个（或者多个）联系人会接收到它。

我们将通过使用联系人属性中的两个设置来完成此配置，允许我们限制他们应接收通知的时间段：host_notification_period 和 service_notification_period。

准备工作

您应该有一个 Nagios Core 3.0 或更高版本的服务器，并且已经配置了至少一个联系人组，并且该组中至少有两个联系人。您应该熟悉配置时间段，并理解本章前面讨论的通知基础知识。

我们将使用一个非常简单的例子，假设有三个网络运营商，分别命名为联系人alan、brenden和charlotte，他们每周轮流值班监控。三者都是ops组的成员，该组在网络上所有主机和服务的contact_groups指令中指定。

如何操作...

我们可以为接收通知的操作员设置一个基本的交替时间表，如下所示：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果您将主机的定义放在了其他文件中，请转到其目录。
```
# cd /usr/local/nagios/etc/objects
```

检查相关文件或文件，以确保您的联系人已定义，并且他们是适当联系人组的成员。此类信息的一个好位置是在contacts.cfg文件中。配置可能看起来类似于以下代码片段：

define contactgroup {
    contactgroup_name  ops
    alias              Network Operations
    members            alan,brenden,charlotte
}
    define contact {
        use           generic-contact
        contact_name  alan
        alias         Alan Jones
        email         alan@pager.naginet
    }
    define contact {
        use           generic-contact
        contact_name  brenden
        alias         Brenden Peters
        email         brenden@pager.naginet
    }
    define contact {
        use           generic-contact
        contact_name  charlotte
        alias         Charlotte Franks
        email         charlotte@pager.naginet
    }

在这种情况下，所有我们的主机和服务都已配置为向ops联系人组发送消息：

    define host {
        ...
 contact_groups  ops
    }
    define service {
        ...
 contact_groups  ops
    }

定义时间段，以对应每个联系人应该接收消息的时间。我们将使用时间段定义的特殊语法来设置这个轮换的定义：

define timeperiod {
    timeperiod_name  alan-pageralias            Alan pager schedule
    2012-06-05 / 21  00:00-24:00
    2012-06-06 / 21  00:00-24:00
    2012-06-07 / 21  00:00-24:00
    2012-06-08 / 21  00:00-24:00
    2012-06-09 / 21  00:00-24:00
    2012-06-10 / 21  00:00-24:00
    2012-06-11 / 21  00:00-24:00
}
define timeperiod {
    timeperiod_name  brenden-pageralias            Brenden pager schedule
    2012-06-12 / 21  00:00-24:00
    2012-06-13 / 21  00:00-24:00
    2012-06-14 / 21  00:00-24:00
    2012-06-15 / 21  00:00-24:00
    2012-06-16 / 21  00:00-24:00
    2012-06-17 / 21  00:00-24:00
    2012-06-18 / 21  00:00-24:00
}
define timeperiod {
    timeperiod_name  charlotte-pager
    alias            Charlotte pager schedule
    2012-06-19 / 21  00:00-24:00
    2012-06-20 / 21  00:00-24:00
    2012-06-21 / 21  00:00-24:00
    2012-06-22 / 21  00:00-24:00
    2012-06-23 / 21  00:00-24:00
    2012-06-24 / 21  00:00-24:00
    2012-06-25 / 21  00:00-24:00
}

返回并使用host_notification_period和service_notification_period指令配置每个联系人，以便仅在他们的专用时间段内接收通知：

define contact {
    use                          generic-contact
    contact_name                 alan
    alias                        Alan Jones
    email                        alan@pager.naginet
 host_notification_period     alan-pager
 service_notification_period  alan-pager
}
define contact {
    use                          generic-contact
    contact_name                 brenden
    alias                        Brenden Peters
    email                        brenden@pager.naginet
 host_notification_period     brenden-pager
 service_notification_period  brenden-pager
}
define contact {
    use                          generic-contact
    contact_name                 charlotte
    alias                        Charlotte Franks
    email                        charlotte@pager.naginet
 host_notification_period     charlotte-pager
 service_notification_period  charlotte-pager
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，配置的联系人应该仅在其专用的呼叫器时间内接收通知。如果这些是我们唯一的联系人，那么所有生成的通知将在任何给定时间只发送给一个人。

它是如何工作的...

在我们联系人的定义中，host_notification_period和service_notification_period指令用于限制这些联系人应接收通知的时间段。在这个例子中，我们的每个联系人都有自己定义的时间段，以对应他们在呼叫器时间表中的部分。

我们来看看 Alan 的例子：

    define timeperiod {
        timeperiod_name  alan-pager
        2012-06-05 / 21  00:00-24:00
        2012-06-06 / 21  00:00-24:00
        2012-06-07 / 21  00:00-24:00
        2012-06-08 / 21  00:00-24:00
        2012-06-09 / 21  00:00-24:00
        2012-06-10 / 21  00:00-24:00
        2012-06-11 / 21  00:00-24:00
    }

指令的第二行，2012-06-05 / 21 00:00-24:00，可以分解为如下：

从 6 月 5 日开始，
每 21 天，
从午夜到第二天午夜（即整天）。

配置然后继续为 Alan 值班的第一周的剩余几天做相同的配置，并指定他将在 21 天（即 3 周）后的同一天继续值班。对于联系人brenden和charlotte，分别设置了类似的配置，但分别从一周和两周后开始。

还有更多...

请注意，时间段不一定不能重叠。如果我们觉得合适，可以安排多个联系人接收通知。类似地，如果某个时间段内不需要通知，我们也可以在时间表中留出空隙。

Nagios Core 中的时间段非常灵活；要查看你可以用来定义它们的各种语法示例，可以参考第一章中的创建新的时间段教程，理解主机、服务和联系人。

另见

本章节中的配置群组的通知和指定要通知的状态教程
第一章中的创建新的联系人、创建新的联系人组和创建新的时间段教程，理解主机、服务和联系人

为重复通知定义升级

在这个教程中，我们将学习如何配置 Nagios Core，使得在重复一定次数后，关于主机或服务的故障通知会升级到另一个联系人，而不是（或除了）通常定义的联系人。这是通过定义一个名为主机或服务升级的独立对象类型来实现的。

这种配置可能对提醒更资深的网络人员注意一个无法解决的问题非常有用，尤其是在经验较少的人无法解决问题时，也可以作为“安全阀”，确保主机的故障通知最终能传达到其他人那里，若问题依旧未被修复。

准备工作

你应该拥有一个 Nagios Core 3.0 或更新版本的服务器，且已经配置了至少一个主机或服务，并且至少有两个联系人组——一个用于前几次通知，另一个用于升级通知。你应该理解如何生成通知，并将其发送到主机或服务的contacts和contact_groups。

我们以名为sparta.naginet的主机为例，该主机通常会将通知发送到一个名为ops的组。我们将配置使得第四次及以后的所有通知也发送到一个名为emergency的联系人组。

如何操作...

我们可以如下配置主机或服务的升级：

切换到 Nagios Core 的对象配置目录。默认目录为/usr/local/nagios/etc/objects。如果你将主机的定义放在了不同的文件中，则进入其所在的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。该定义可能类似于以下代码片段：

define host {
    use                    linux-server
    host_name              sparta.naginet
    alias                  sparta
    address                10.128.0.21
    contact_groups         ops
    notification_period    24x7
    notification_interval  10
}

在主机定义下面，添加一个新的hostescalation对象的配置：

define hostescalation {
    host_name              sparta.naginet
    contact_groups         ops,emergency
    first_notification     5
    last_notification      0
    notification_interval  10
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此配置后，当遇到主机问题并生成通知时，超过第五个通知的所有通知将同时发送到ops联系组和emergency联系组，扩展了接收到通知的人或系统的数量，从而更有可能让问题得到解决或修复。也许 ops 团队的某个成员把他们的寻呼机弄丢了。

它是如何工作的...

前面一节中添加的配置最好被看作是针对特定主机的特殊情况或覆盖，因为它指定了一系列应该发送到不同联系组的通知。可以将其分解如下：

host_name：这是在主机定义中给定的host_name的相同值；我们指定了sparta.naginet。
contact_groups：这是应该接收满足此特殊情况的通知的联系人组。我们指定了emergency组和ops组，以便匹配的通知都发送给这两个组。请注意，它们是用逗号分隔的。
first_notification：这是应该与此升级匹配的第一次通知计数；我们选择了第五次通知。
last_notification：这是应该与此升级匹配的最后一次通知计数。我们将其设置为零，这意味着first_notification之后的所有通知应发送给指定的联系人或联系组。通知将持续发送，直到手动关闭或问题解决。
notification_interval：与主机和服务的同名指令一样，它指定如果主机仍处于问题状态，Nagios Core 应等待多长时间后发送新通知。在这里，我们选择了十分钟。

个人联系人也可以使用contacts指令（或替代）进行指定，而不是使用contact_groups。

服务升级的工作原理与此相似；不同之处在于，你需要通过service_description指令指定服务以及其主机名。其他部分的工作方式相同。一个类似的服务检查升级，service_description为HTTP，运行在sparta.naginet上的代码片段可能如下所示：

define serviceescalation {
    host_name              sparta.naginet
    service_description    HTTP
    contact_groups         ops,emergency
    first_notification     5
    last_notification      0
    notification_interval  10
}

还有更多...

前面的升级会继续将通知发送给原始的ops组和emergency组的成员。通常最好这样做，而不是仅仅将通知发送给升级组，因为升级的目的是在问题没有被处理时扩大通知的覆盖范围，而不是单纯地尝试联系另一组人。

这一原则同样适用于堆叠升级；如果我们有一个包含所有联系人主机组，可能名为everyone，我们可以定义第二次升级，以便从第十个通知开始，所有通知都发送给每个联系人：

define hostescalation {
    host_name              sparta.naginet
    contact_groups         everyone
    first_notification     10
    last_notification      0
    notification_interval  10
}

正如我们可以指定多个主机升级一样，通知的范围也可以重叠，这样就可以应用多个升级。

通过一点数学运算，你可以安排升级，使它们在主机或服务处于问题状态一段时间后生效。例如，我们在配方中指定的升级将在主机处于问题状态 40 分钟后应用，因为 notification_interval 指定 Nagios Core 应该在重新发送通知之间等待 10 分钟。

参见

本章中的 配置组的通知 配方
在第一章中，创建新的联系人组 配方，理解主机、服务和联系人

定义一个自定义通知方法

在这个配方中，我们将学习如何为联系人指定一种替代方法，以便接收有关服务的通知。联系人接收通知的一种非常典型的方法是通过电子邮件发送到他们的联系地址；电子邮件消息可以发送到收件箱或分页设备。

然而，通知仅仅是文本；我们可以像配置主机或服务检查一样，通过任何我们希望的命令来处理它们。在这个配方中，我们将设置一个名为 motd 的新联系人，当它接收到通知时，会将通知写入服务器的 /etc/motd 目录，以便在登录时显示。

准备工作

你应该拥有一个 Nagios Core 3.0 或更高版本的服务器，并且至少已经配置了一个主机或服务。你需要了解通知是如何生成的，并且理解它们默认的行为是如何发送到主机或服务的 contacts 和 contact_groups。

我们将使用一个名为 troy.naginet 的主机示例，该主机配置为将通知发送到 ops 联系人组。我们将在这个组中添加一个名为 motd 的新联系人。

如何操作...

我们可以如下安排我们的自定义通知方法：

确保你的 /etc/motd 文件可以被 Nagios Core 写入，并且它是一个静态文件，系统在启动时不会覆盖该文件。如果你以推荐的默认用户和组 nagios 运行 Nagios Core 服务器，可以像下面这样操作：
```
# chgrp nagios /etc/motd
# chmod g+w /etc/motd
```
通过 su 或 sudo 测试用户是否能够写入该文件会是个好主意：
```
# sudo -s -u nagios
$ echo 'test' >>/etc/motd
```
切换到 Nagios Core 的 objects 配置目录。默认路径是 /usr/local/nagios/etc/objects。如果你将主机的定义放在了其他文件中，那么请转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含通知命令定义的文件。默认情况下，这些定义在 commands.cfg 文件中。将以下定义附加到该文件：

define command {
    command_name    notify-host-motd
    command_line    /usr/bin/printf "%s\n" "$SHORTDATETIME$: $HOSTALIAS$ is $HOSTSTATE$" >>/etc/motd
}
define command {
    command_name    notify-service-motd
    command_line    /usr/bin/printf "%s\n" "$SHORTDATETIME$: $SERVICEDESC$ on $HOSTALIAS$ is $SERVICESTATE$" >>/etc/motd
}

编辑包含联系人定义的文件。在 QuickStart 配置中，这些定义在 contacts.cfg 文件中。将以下定义附加到该文件：

define contact {
    use                            generic-contact
    contact_name                   motd
    contact_groups                 ops
    alias                          MOTD
    host_notification_commands     notify-host-motd
    service_notification_commands  notify-service-motd
}

编辑包含主机和/或服务定义的文件，确保它们在 contact_groups 指令中指定了 ops：

define host {
    host_name       troy.naginet
    ...
 contact_groups  ops
}
    define service {
        host_name       troy.naginet
        ...
 contact_groups  ops
    }

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，接下来的主机和服务通知不仅应通过电子邮件发送给 ops 组中的任何联系人，还应由 motd 联系人写入 /etc/motd，以便在登录时显示：

06-30-2012 17:24:05: troy is DOWN
06-30-2012 17:24:05: HTTP on troy is CRITICAL
06-30-2012 17:25:07: troy is DOWN
06-30-2012 17:25:07: HTTP on troy is CRITICAL

它是如何工作的...

我们添加的配置的第一部分是定义新的通知命令。这些实际上是命令定义，就像用于主机和服务的 check_command 定义一样；区别在于，它们被联系人用于将通知发送给相关人员（或在这种情况下，将通知写入文件）以适当的方式。

如果你使用的是默认的 Nagios Core 配置，commands.cfg 中已经定义的命令应包括 notify-host-by-email 和 notify-service-by-email。我已经截断了完整的命令行，因为它非常长：

define command {
    command_name    notify-host-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification...
}
define command {
    command_name    notify-service-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification...
}

这些命令使用系统的 printf 实现，并结合许多 Nagios Core 宏来构建适当的通知字符串，该字符串通过 shell 管道发送到系统邮件程序并通过电子邮件发送给适当的联系人。

如果我们检查定义了 generic-contact 模板的 templates.cfg 文件，我们可以看到这两个方法在两个指令中被引用：

define contact {
    ...
    service_notification_commands notify-service-by-email
    host_notification_commands notify-host-by-email
}

该配置因此定义了一个特定的通知命令，供从 generic-host 模板派生的主机使用。

我们自己的命令定义类似地通过调用 printf 来构建字符串。但不同的是，它不是将输出写入管道发送到系统邮件程序，而是将其附加到 /etc/motd 文件中。

我们为 motd 联系人处理主机通知所指定的 command_line 指令如下：

/usr/bin/printf "%s\n" "$SHORTDATETIME$: $HOSTALIAS$ is $HOSTSTATE$" >>/etc/motd

Nagios Core 在成功触发该联系人的通知事件时，首先会替换它的宏值， $SHORTDATETIME$ 、 $HOSTALIAS$ 和 $HOSTSTATE$ ：

/usr/bin/printf "%s\n" "06-30-2012 17:24:05: troy is DOWN" >>/etc/motd

生成的字符串随后由正在运行的 Nagios Core 用户（默认为 nagios）作为命令执行，只要该用户具有适当的权限，它将被附加到 MOTD 的末尾。

还有更多内容...

向 MOTD 添加消息对于所有网络管理员来说可能没有用，特别是对于大型或更敏感的网络，因为这些网络每天可能会生成数百个通知。这里需要记住的主要内容是，Nagios Core 可以根据需要配置为处理通知事件，只要：

我们可以定义一个命令行，确保它在执行时能始终按照 Nagios Core 为我们执行宏替换的结果完成所需的操作
nagios 用户，或者说 Nagios Core 服务器运行的用户，拥有执行该命令所需的所有相关权限

电子邮件通知，特别是发送到移动分页设备，对于大多数管理员来说，是一个非常合理的通知基础。然而，如果需要其他通知方式，例如插入数据库或管道传递到 Perl 脚本中，这也是可以实现的。

请注意，最好为我们在这些命令中使用的任何二进制文件或文件指定完整路径，因此使用/usr/bin/printf而不仅仅是printf。这样可以确保我们实际打算运行的程序被正确运行，并避免需要处理nagios用户的$PATH配置。

另请参见

本章中的为组配置通知教程
第二章中的创建新命令和自定义现有命令教程，使用命令和插件

第五章：监控方法

本章中，我们将涵盖以下内容：

监控任何主机的 PING
监控任何主机的 SSH
检查一个备用 SSH 端口
监控邮件服务
监控网页服务
检查网站是否返回特定字符串
监控数据库服务
监控 SNMP 查询的输出
监控 RAID 或其他硬件设备
创建一个 SNMP OID 进行监控

介绍

Nagios Core 最好被视为一个监控框架，利用插件对主机和服务进行适当的检查，并以其理解的格式返回状态结果，用于发送通知并长期跟踪状态。

设计相当灵活。如第二章《使用命令和插件》中所述，命令和插件使用，Nagios Core 可以将任何命令行应用程序用作插件，只要它返回的值符合 Nagios Core 头文件、Perl 库或 Shell 脚本中定义的适当返回值。反过来，Nagios Core 可以通过配置以多种方式使用相同的插件，利用插件提供的任何开关调整其行为，包括通过 Nagios Core 宏的值（如 $HOSTADDRESS$ ）向其提供元数据。

Nagios Exchange 网站上可用的插件集合相当庞大，详细记录所有插件超出了本书的范围。然而，一些最有用的插件作为 Nagios 插件集的一部分被包含在内，并作为 Nagios Core 推荐快速入门指南的一部分进行安装，地址为nagios.sourceforge.net/docs/3_0/quickstart.html。这些插件包括用于以常见方式监控典型网络特征的程序，例如监控基础网络连接、网页服务、邮件服务器等。插件网站本身的网址是nagiosplugins.org/。

本章将演示此插件集一些最有用组件的使用方法，假设你已经安装了这些插件。重点将放在监控任务上，这些任务与大多数或甚至所有不同规模的网络相关，旨在帮助读者不再仅仅将 Nagios Core 视为一个发送 PING 请求的过程。最后几节将展示如何使用简单网络管理协议（SNMP）作为检查任何通用网络服务或系统属性的方法，这些可能并不在标准的 Nagios 插件集中涵盖。

监控任何主机的 PING

在本教程中，我们将学习如何为主机设置 PING 监控。我们将使用check_ping插件及其同名命令，向主机发送ICMP ECHO请求。我们将这作为一个简单的诊断检查，确保主机的网络栈以一致和及时的方式响应，就像管理员可能会使用ping命令来检查相同的属性一样。

准备工作

你应该已经有一个 Nagios Core 3.0 或更高版本的服务器，并且至少已经配置了一个主机。我们将使用corinth.naginet的例子，它是一个在独立文件中定义的主机。你还应该理解主机和服务之间的基本关系，这在第一章，理解主机、服务和联系人一节中有详细介绍。

如何操作...

我们可以按照如下方式，为现有主机添加一个新的 PING 服务检查：

更改为 Nagios Core 的对象配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机的定义放在了不同的文件中，请转到该目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        windows-server
    host_name  corinth.naginet
    alias      corinth
    address    10.128.0.27
}

在主机定义下方，放置一个引用check_ping的服务定义。你可以使用generic-service模板，如下所示：

define service {
    use                  generic-service
    host_name            corinth.naginet
    service_description  PING
    check_command        check_ping!100,20%!200,40%
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成后，新的服务检查将开始运行，并且当发生以下情况时，相关联系人和联系人组将收到通知：

如果请求及其响应的往返时间（RTT）超过了 200ms，或者在检查过程中丢失了超过 40%的数据包；无论哪种情况，都会为该服务触发一个CRITICAL通知。
如果没有触发CRITICAL通知，并且请求及其响应的 RTT 超过了 100ms，或者在检查过程中丢失了超过 20%的数据包；此时，会为该服务触发一个WARNING通知。

有关阈值的信息将在check_ping命令的check_command指令定义中作为参数给出。

关于该服务的更多信息也会在 Web 界面的服务部分显示。

它是如何工作的...

前一节中添加的配置定义了一个新的服务检查，用于检查现有的corinth.naginet主机，确保ICMP ECHO请求及其响应的 RTT 和丢包率在可接受的范围内。

对于大多数网络配置，主机本身很可能也会通过命令check-host-alive被check_ping检查。不同之处在于，这个命令的 RTT 和丢包的阈值通常设置得非常高，因为它的目的是判断主机是否在线，而不是主机的响应速度。

还有更多...

在大多数主机都配置为响应ICMP ECHO请求的网络中，可能值得对配置中的所有主机配置服务检查。可以使用*通配符在定义host_name时实现这一点：

define service {
    use                  generic-service
    host_name            *
    service_description  PING
    check_command        check_ping!100,20%!200,40%
}

这将使用PING的service_description指令，应用相同的检查到数据库中配置的所有主机。这种方法可以避免为所有主机单独配置服务的麻烦。

如果网络中的某些主机未响应 PING，则可能更合适将响应的主机放入一个主机组中，主机组的名称可以是icmp之类的：

define hostgroup {
    hostgroup_name  icmp
    alias           ICMP enabled hosts
    members         sparta.naginet,corinth.naginet
}

然后，单个服务可以应用于该组中的所有主机，使用service定义中的hostgroup_name指令：

define service {
    use                  generic-service
    hostgroup_name       icmp
    service_description  PING
    check_command        check_ping!100,20%!200,40%
}

通常来说，尽可能让网络主机响应 ICMP 消息是一个好主意，这样可以遵循 RFC1122 中的建议并简化调试过程。

最后，注意 RTT 和丢包的阈值不是固定的；事实上，它们是在服务定义中的check_command行中定义的。对于那些由于网络负载或拓扑导致延迟较高的主机，可能需要调整这些阈值，具体内容可以参考第三章中的更改 ping RTT 和丢包阈值的食谱，工作与检查和状态。

另见

在第一章中，创建新主机、创建新服务和创建新主机组的示例，理解主机、服务和联系人。
在第二章中，使用替代检查命令的食谱，工作与命令和插件。
在第三章中，更改 ping RTT 和丢包阈值的食谱，工作与检查和状态。

监控任意主机上的 SSH

在本食谱中，我们将学习如何使用check_ssh插件及其同名命令检查远程主机上的 SSH 守护进程是否响应请求。这将使我们在连接到 SSH 服务时遇到问题时，能够及时收到通知。

准备工作

您应该有一个 Nagios Core 3.0 或更新版本的服务器，并且已经配置了至少一个主机。我们将使用 troy.naginet这个例子，主机定义在其自己的文件中。您还应该了解主机和服务之间的基本关系，具体内容可以参考第一章中的食谱，理解主机、服务和联系人。

首先验证您要添加监控的主机当前是否正在运行需要检查的 SSH 服务可能是个好主意。可以通过运行ssh客户端连接到主机来进行验证：

$ ssh troy.naginet

我们还应检查插件本身在作为nagios用户运行时是否返回所需的结果。

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_ssh troy.naginet

如果你无法从目标机器上的 SSH 服务获得正面响应，即使你确定它正在运行，这可能是与连接性或过滤问题无关的症状。例如，我们可能需要将运行 Nagios Core 的监控服务器添加到任何适用防火墙或路由器的 SSH（通常是 TCP 目标端口22）白名单中。

如何操作...

我们可以按照以下方式将新的 SSH 服务检查添加到现有主机：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，则应转到该文件所在目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  troy.naginet
    alias      troy
    address    10.128.0.25
}

在主机定义下方，放置一个服务定义，引用check_ssh。使用generic-service模板或其他合适的模板可能会有所帮助，如下所示：

define service {
    use                  generic-service
    host_name            troy.naginet
    service_description  SSH
    check_command        check_ssh
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此步骤后，将开始进行新的服务检查，当尝试连接到 SSH 服务器失败时，相关联系人和联系人组将收到通知。服务检查将在 Web 界面上的服务页面中显示。

它是如何工作的...

上述配置定义了一个新的服务，其service_description为SSH，适用于现有的troy.naginet主机，使用generic-service模板中的值，并另外定义了check_command指令check_ssh。

这意味着除了之前检查主机是否启动的check-host-alive，Nagios Core 还将检查运行在主机上的 SSH 服务是否正常工作，方法是尝试与其建立连接。如果在进行适当次数的测试后发现服务有问题，它还会通知相关联系人。

例如，如果插件发现主机可以访问但未响应客户端测试，则可能会通知如下文本：

Subject: ** PROBLEM Service Alert: troy.naginet/SSH is CRITICAL **

***** Nagios *****

Notification Type: PROBLEM

Service: SSH
Host: troy.naginet
Address: troy.naginet
State: CRITICAL

Date/Time: Wed May 23 13:35:21 NZST 2012

Additional Info:

CRITICAL - Socket timeout after 10 seconds

请注意，我们不需要为 SSH 检查提供凭证；插件仅确保服务正在运行并响应连接尝试。

还有更多内容...

如果我们对插件如何实际作为命令应用感到好奇，应该检查check_ssh命令的定义，这在/usr/local/nagios/etc/objects/commands.cfg的 QuickStart 配置中有定义：

define command {
    command_name  check_ssh
    command_line  $USER1$/check_ssh $ARG1$ $HOSTADDRESS$
}

这表明 check_ssh 命令已配置为在 $USER1$ 中运行 check_ssh 二进制文件，该宏通常扩展为 /usr/local/nagios/libexec，并针对适用服务器的主机地址执行。它在之前添加任何其他参数。在本教程中我们没有使用任何参数，因为我们只是想对其默认端口上的 SSH 服务进行常规检查。

此检查应适用于大多数符合 SSH2 标准的服务器，尤其是流行的 OpenSSH 服务器。

检查 SSH 可访问性是服务器上常见的任务，您可能希望设置一个 SSH 服务检查，应用于一个主机组，而不仅仅是单个主机。例如，如果您有一个名为 ssh-servers 的组，其中包含多个服务器，这些服务器应使用 check_ssh 进行检查，那么您可以通过 hostgroup_name 指令配置它们，以便通过一个服务定义对它们进行检查：

define service {
    use                  generic-service
    hostgroup_name       ssh-servers
    service_description  SSH
    check_command        check_ssh
}

这会将相同的服务检查应用于组中的每个主机，这样，如果以后需要更改或删除检查，定义将更容易更新。

请注意，check_ssh 插件与 check_by_ssh 插件不同，后者用于在远程机器上执行检查，类似于 NRPE。

另请参阅

本章中的 检查替代 SSH 端口 教程
在第一章中，创建新主机、创建新服务 和 创建新主机组 的教程，理解主机、服务和联系人
在第六章中，使用 key 认证的 check_by_ssh 替代 NRPE 和 在远程机器上使用 NRPE 监控本地服务 的教程，启用远程执行

检查替代 SSH 端口

在本教程中，我们将学习如何处理机器运行 SSH 守护进程且监听替代端口的常见情况。因此，使用 check_ssh 的服务定义，如 监控任何主机的 SSH 教程中所示，由于插件默认使用标准 SSH TCP 端口号 22，因此会失败。

这种设置在 SSH 服务器不应向公众开放的情况下非常常见，通常作为一种“通过模糊性提高安全性”的方法，用于减少对服务器的自动化攻击。因此，SSH 守护进程配置为监听其他端口，通常是更高的端口号；需要使用它的管理员会被告知端口号。

我们将处理这种情况，并在 Nagios Core 中监控该服务，即使它运行在非标准端口上。我们将通过定义一个新命令来检查指定端口上的 SSH，并创建一个使用该命令的服务定义。该命令将接受要检查的端口号作为参数。

这里的原则应当很好地适用于任何需要检查备用端口的情况，前提是用于执行检查的 Nagios Core 插件支持在替代端口上执行此操作。

准备工作

你应该已经配置好一个 Nagios Core 3.0 或更新版本的服务器，并且至少配置了一个主机。我们将以 troy.naginet 为例，它是一个在自己文件中定义的主机，监听非标准的 SSH 端口 5022。你还应该了解主机和服务的基本关系，这部分内容在第一章中有介绍，理解主机、服务和联系人。

一个好的第一步是验证我们是否能够从监控服务器访问指定端口上的 SSH 守护进程。我们可以使用 ssh 客户端从命令行进行验证，并通过 -p 选项指定端口号：

$ ssh troy.naginet -p 5022

或者，你也可以直接从命令行运行 check_ssh 插件：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_ssh -p 5022 troy.naginet

如何操作……

我们可以按照以下方式设置一个针对非标准端口的 SSH 服务检查：

切换到 Nagios Core 的 objects 配置目录。默认路径是 /usr/local/nagios/etc/objects。如果你将主机定义放在其他文件中，则需要转到该文件所在目录。
```
# cd /usr/local/nagios/etc/objects
```
编辑一个包含命令定义的合适文件，找到 check_ssh 命令的定义。在默认安装中，该文件是 commands.cfg。check_ssh 的定义类似于以下代码片段：
```
define command {
    command_name  check_ssh
    command_line  $USER1$/check_ssh $ARG1$ $HOSTADDRESS$
}
```

在 check_ssh 定义下方，添加一个新的命令定义，如下所示：

define command {
    command_name  check_ssh_altport
 command_line  $USER1$/check_ssh -p $ARG1$ $HOSTADDRESS$
}

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  troy.naginet
    alias      troy
    address    10.128.0.25
}

在主机定义下方，使用我们的新命令添加一个新的服务定义：

define service {
    use                  generic-service
    host_name            troy.naginet
    service_description  SSH_5022
    check_command        check_ssh_altport!5022
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这些步骤后，Nagios Core 将开始使用 check_ssh 插件进行服务检查，但会在连接尝试时使用备用的目标端口 5022，其 service_description 为 SSH_5022。

工作原理……

前面部分添加的配置几乎和添加一个默认的 check_ssh 服务完全相同，唯一的区别是检查的端口不同，以便建立连接。我们使用 check_ssh_altport 命令来实现这一点，其语法与 check_ssh 定义非常相似。

区别在于，该命令接受一个参数，该参数作为 -p 选项的值传递给 check_ssh 插件，用于检查指定的端口号；在此情况下是 TCP 端口 5022，而不是默认的端口 22。

还有更多……

由于 Nagios Core 中的参数可以包含空格，我们也可以将服务检查定义如下，而无需额外定义命令：

define service {
    use                  generic-service
    host_name            troy.naginet
    service_description  SSH_5022
    check_command        check_ssh!-p 5022
}

这是因为 $ARG1$ 宏表示的参数仍然在原始的 check_ssh 命令中使用，但它需要包括选项及其值。两者的主要区别在于偏好问题，取决于我们认为哪种方式更清晰和更易于维护。可以考虑一下是否使用一个命名明确的命令有助于其他人理解我们配置的含义。

另请参见

本章中的 监控任何主机的 SSH 配方
第一章中的 创建新主机 和 创建新服务 配方，理解主机、服务和联系人
第二章中的 创建新命令 配方，与命令和插件协作

监控邮件服务

在本配方中，我们将学习如何监控指定主机的三项常见邮件服务：SMTP、POP 和 IMAP。我们还将了解如何使用相同的结构，为这些服务的加密版本添加额外的检查：SMTPS、POPS 和 IMAPS。

为了简化起见，我们假设在本示例中这三项服务都运行在同一主机上，但这个过程很容易推广到常见的情况，即为一个或多个先前提到的功能指定专用服务器。

准备工作

你应该已经配置了至少一台主机的 Nagios Core 3.0 或更新版本的服务器。我们将使用 troy.naginet 作为示例，这是在独立文件中定义的主机。你还应该了解主机和服务之间的基本关系，这在第一章，理解主机、服务和联系人中有涉及。

检查目标服务器上所需服务的连接性也是个好主意，以确保监控服务器将在适当的协议和端口上建立的自动连接能够按预期工作。对于未加密的邮件服务，可以通过 Telnet 连接到相应的端口来完成检查。对于 SMTP：

$ telnet marathon.naginet 25
Trying 10.128.0.34...
Connected to marathon.naginet.
Escape character is '^]'.
220 marathon.naginet ESMTP Postfix

对于 POP：

$ telnet marathon.naginet 110
Trying 10.128.0.34...
Connected to marathon.naginet.
Escape character is '^]'.
+OK Hello there.

对于 IMAP：

$ telnet marathon.naginet 143
Trying 10.128.0.34...
Connected to marathon.naginet.
Escape character is '^]'.
* OK CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE...

对于安全服务，检查的一种可能方式是使用 openssl 客户端。对于 SMTPS，其“经典”端口号为 465：

$ openssl s_client -host marathon.naginet -port 465
CONNECTED(00000003)
...
220 marathon.naginet ESMTP Postfix

对于 POPS：

$ openssl s_client -host marathon.naginet -port 995
CONNECTED(00000003)
...
+OK Hello there.

对于 IMAPS：

$ openssl s_client -host marathon.naginet -port 993
CONNECTED(00000003)
...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE...

如果你愿意，也可以使用网络扫描工具如 nmap 来测试端口是否开放并响应。

一旦我们验证了所需邮件服务的连接性，并且确认主机本身是否已在 Nagios Core 中配置并检查过，我们就可以添加适当的服务检查。

如何操作...

我们可以为主机添加未加密邮件服务的检查，包括 SMTP、POP 和 IMAP 服务，方法如下：

切换到 Nagios Core 的 objects 配置目录。默认路径是 /usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，请转到该文件所在目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  marathon.naginet
    alias      marathon
    address    10.128.0.34
}

在主机定义下，放置三个新的服务定义，每个适用于一个相应的邮件服务：

define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  SMTP
    check_command        check_smtp
}
define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  POP
    check_command        check_pop
}
define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  IMAP
    check_command        check_imap
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此步骤后，将开始进行三项新的服务检查，适当的联系人和联系组会在尝试连接任何服务失败时收到通知。这些服务的详细信息也将在网页界面的服务部分中显示。

它是如何工作的...

上一节中添加的配置将三项新的服务检查添加到现有的 marathon.naginet 主机：

SMTP，使用 check_smtp 命令打开 SMTP 会话
POP，使用 check_pop 命令打开 POP 会话
IMAP，使用 check_imap 命令打开 IMAP 会话

在这三种情况下，都会检查服务的连接性和响应性，并在它返回适当值且在可接受时间范围内时判定为 OK。

需要注意的是，此处定义的配置并不实际发送或接收任何电子邮件；它仅检查服务的基本连接性，以及是否能响应简单的请求。因此，仅仅因为状态为 OK 并不意味着电子邮件消息被正确传递；它可能仅意味着服务在响应。

还有更多...

如果需要检查这些服务的安全 SSL/TLS 版本，则配置非常相似，但需要事先进行一些额外设置。这是因为尽管 Nagios 插件中包含用于检查它们的插件，但它们并未被配置为作为命令使用。请注意，这一点在未来的 Nagios Core 版本中可能会发生变化。

为了添加适当的命令，可以将以下段落添加到命令配置文件中，通常是 /usr/local/nagios/etc/objects/commands.cfg：

define command {
    command_name  check_ssmtp
    command_line  $USER1$/check_ssmtp $ARG1$ -H $HOSTADDRESS$
}
define command {
    command_name  check_spop
    command_line  $USER1$/check_spop $ARG1$ -H $HOSTADDRESS$
}
define command {
    command_name  check_simap
    command_line  $USER1$/check_simap $ARG1$ -H $HOSTADDRESS$
}

完成此步骤后，可以将以下服务定义添加到适当的主机中，既可以替换也可以补充未加密服务的检查。它们与未加密版本相同，只是将 service_description 和 check_command 中添加了 s：

define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  SSMTP
 check_command        check_ssmtp
}
define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  SPOP
 check_command        check_spop
}
define service {
    use                  generic-service
    host_name            marathon.naginet
    service_description  SIMAP
 check_command        check_simap
}

最后，注意如果你管理着多台邮件服务器，并且这些服务器运行着上述服务中的一个或多个，那么最好将服务应用到包含所有适用主机的主机组，而不是为每个服务创建新的服务定义。请参阅[第一章中的在组内所有主机上运行服务部分，了解如何操作。

另见

在第一章的创建新主机、创建新服务、在组内的所有主机上运行服务和创建新主机组等配方中，有涉及到这些内容。
第二章的创建新命令配方中介绍了如何操作。

监控网络服务

在这个配方中，我们将设置一个服务检查，用来监控 HTTP 和 HTTPS 服务器的响应性。我们将使用 check_http 命令及其在 Nagios 插件集中提供的同名插件，向 web 服务器发起 HTTP 和 HTTPS 请求，以确保它返回适当且及时的响应。这在需要检查网站是否仍在正常运行的情况下非常有用，特别是当网站在承受高负载或遭遇拒绝服务攻击时。

准备工作

你应该已经有一个 Nagios Core 3.0 或更新版本的服务器，并且至少配置了一个主机。我们将使用 sparta.naginet 作为示例，这是一个在其自身文件中定义的主机。你还应该理解主机和服务之间的基本关系，这在第一章的理解主机、服务和联系人中有介绍。

一个合适的第一步是确保我们打算检查的服务可以从运行 Nagios Core 的监控服务器访问。这可以通过命令行完成，使用如 curl 或 wget 这样的 HTTP 客户端：

$ wget http://sparta.naginet/
$ curl http://sparta.naginet/

check_http 插件二进制文件也可以直接调用来测试连接性；我们期望收到一个 HTTP OK 响应，状态码为 200：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_http -I sparta.naginet
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0.004 second response time |time=0.004264s;;;0.000000 size=453B;;;0

可选地，我们也可以以相同的方式检查 HTTPS，只需要为插件添加 -S 选项：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_http -S -I sparta.naginet
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0.058 second response time |time=0.057836s;;;0.000000 size=453B;;;0

这两者可能需要安装一个默认页面由主机提供服务，通常是像 index.html 或 default.asp 这样的文件，具体取决于使用的 web 服务器软件。

一旦验证了从监控服务器到主机的 HTTP 连接正常，并且收到了合适的响应，我们就可以继续添加我们的服务检查。

如何操作...

我们可以按以下方式为主机添加 web 服务检查：

切换到 Nagios Core 的 objects 配置目录。默认路径为 /usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，请转到相应的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  sparta.naginet
    alias      sparta
    address    10.128.0.21
}

在主机定义下方，放置一个新的服务定义来进行 HTTP 检查：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP
    check_command        check_http
}

如果还需要进行 HTTPS 检查，可以添加一个可选的第二个服务定义：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTPS
    check_command        check_http!-S
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，一个名为 HTTP 的新服务，以及一个可选的 HTTPS 服务，将会被添加到sparta.naginet主机中，并且服务器将定期发起 HTTP 请求，报告连接失败或返回意外状态的情况。这些服务将在 Web 界面的服务部分中可见。

它是如何工作的...

前面部分中添加的配置使用check_http插件对sparta.naginet服务器进行定期请求。默认情况下，请求的是首页，因此请求的形式如下：

GET / HTTP/1.0
User-Agent: check_http/v1.4.15 (nagios-plugins 1.4.15)
Connection: close

插件等待响应，然后根据以下标准返回状态：

是否在可接受的时间范围内收到了格式良好的 HTTP 响应。如果响应过慢，可能会在插件超时时引发CRITICAL状态。
是否收到 HTTP 响应的响应码为200 Found，表示已找到并返回了一个文档。默认情况下，如果收到404 Not Found的响应码，则会触发CRITICAL状态。

查看/usr/local/nagios/etc/objects/commands.cfg中默认check_http命令的定义，可以更好地了解它如何使用同名插件：

define command {
    command_name  check_http
    command_line  $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}

这使用了三个 Nagios Core 宏：

$USER1$ ：这表示插件脚本和二进制文件所在的目录；通常是/usr/local/nagios/libexec。
$HOSTADDRESS$ ：这是服务关联主机中定义的address指令的值；在本例中为10.0.128.21。
$ARG1$ ：这是一个额外的参数，如果命令中定义了该参数；它允许我们在check_http调用中添加-S选项，以便进行 HTTPS 检查。

还有更多...

check_http插件有很多其他非常有用的选项；通过输入没有参数的命令可以查看它们的列表：

# ./check_http
check_http: Could not parse arguments
Usage:
 check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
 [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-a auth]
 [-b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>]
 [-e <expect>] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>]
 [-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>]
 [-A string] [-k string] [-S] [--sni] [-C <age>] [-T <content-type>]
 [-j method]

一个特别有用的选项是-u选项，它允许我们从服务器请求除默认索引文档以外的特定 URL。如果我们需要为站点上的多个页面设置检查，这个选项就非常有用，也可以作为代码单元测试的一个很好的补充，尤其是在站点部署或更新时。

例如，如果我们想检查三个页面是否返回200 Found响应：about.php、products.php和contact.php，那么我们可以设置一个类似以下的命令来检查特定页面：

define command {
    command_name  check_http_page
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -u $ARG1$
}

这将允许我们使用新命令进行三个类似的服务检查，如下所示：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-about
 check_command        check_http_page!/about.php
}
define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-products
 check_command        check_http_page!/products.php
}
define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-contact
 check_command        check_http_page!/contact.php
}

这些服务检查的运行方式与食谱中展示的相同，唯一不同的是它们每个都会请求一个特定的页面。请注意，URL 前面的斜杠是必需的。

类似地，-H选项允许您指定主机名，这在托管多个站点的服务器上非常有用。可以通过如下配置命令来实现：

define command {
    command_name  check_http_host
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -H $ARG1$
}

这将允许你检查同一主机上的两个站点，www.naginet/ 和 dev.naginet/，分别进行服务检查：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-www
 check_command        check_http_host!www.naginet
}
define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-dev
 check_command        check_http_host!dev.naginet
}

值得注意的是，check_http请求会与常规请求一起出现在服务器日志中。如果你担心这些扭曲的统计数据或报告中出现不需要的值，那么使用其User-Agent头部值过滤这些请求可能是最简单的办法，User-Agent中包含字符串check_http。

另见

本章中的检查网站返回指定字符串
第一章中的创建新主机和创建新服务教程，理解主机、服务和联系人
第二章中的创建新命令和定制现有插件教程，工作与命令和插件

检查网站是否返回指定字符串

在本教程中，我们将基于本章中监控网页服务教程中建立的基本网页服务监控，学习如何创建一个使用check_http插件的命令，以确保 HTTP 响应中包含特定字符串。

默认情况下，Nagios Core 没有定义使用插件的命令，所以这个教程将包括在作为服务检查的一部分之前定义命令。

如果我们正在监控的服务器上的网站可能不会返回404 Not Found或类似错误，这些错误会在 Nagios 中标记为WARNING或CRITICAL状态，那么这样做可能是必要的；与其单纯检查文档是否存在，我们可以检查其是否匹配某个字符串，以确认它是否符合我们预期的特定文档。

这种设置是网站或 Web 应用程序代码单元测试套件的一个很好的补充。

准备工作

你应该已经有一个 Nagios Core 3.0 或更高版本的服务器，并且至少已经配置了一个主机。我们将使用sparta.naginet作为示例，该主机定义在自己的文件中，并且我们将检查它是否在响应中返回简单字符串naginet。你还应该理解主机和服务之间的基本关系，这在第一章，理解主机、服务和联系人的教程中有所涵盖。

你应该先为主机设置基本的 HTTP 监控，如本章中的检查网页服务教程所述，以确保监控服务器与主机之间有连接，并且请求和响应都正常工作，并返回适当的错误码。

如何操作...

我们可以设置一个包含 HTTP 响应内容检查的服务检查，如下所示：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，则转到相应的目录。
```
# cd /usr/local/nagios/etc/objects
```
编辑包含命令定义的适当文件，并找到check_http命令的定义。在 QuickStart 安装中，该文件是commands.cfg。check_http定义类似于以下代码片段：
```
define command {
    command_name  check_http
    command_line  $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}
```

在check_http定义下方，添加一个新的命令定义，如下所示：

define command {
    command_name  check_http_content
 command_line  $USER1$/check_http -I $HOSTADDRESS$ -s $ARG1$
}

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  sparta.naginet
    alias      sparta
    address    10.128.0.21
}

在主机的定义下方以及任何可能使用check_http的检查下方，使用我们的新命令放置一个新的服务定义：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  HTTP-content
    check_command        check_http_content!naginet
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 应开始像check_http一样发出 HTTP 请求以监控该服务，唯一不同的是，只有在网站内容包含naginet字符串时，才会返回OK状态。否则，它将生成警报，并将该服务标记为CRITICAL，消息类似如下：

HTTP CRITICAL: HTTP/1.1 200 OK - string 'naginet' not found on 'http://10.128.0.21:80/' - 453 bytes in 0.006 second response time

它是如何工作的……

check_http的众多选项之一是-s，即--string的缩写，它接受一个指定的字符串作为参数，该字符串必须出现在内容中，才能使服务检查返回OK状态。

当收到 HTTP 响应时，check_http会检查响应中的文本，看看它是否与指定的字符串匹配，并且除了标记WARNING或CRITICAL状态用于连接或超时问题外，还会执行通常的行为。

请注意，为了使这个功能工作，有必要定义一个新的命令，使用第一个参数（在此例中是字符串naginet）作为-s选项传递给check_http。执行的完整命令行类似于以下命令：

$ /usr/local/nagios/libexec/check_http -H sparta.naginet -s naginet

还有更多……

check_http插件提供的功能远远超出了单个字符串检查，如果需要测试内容中是否存在正则表达式，可以使用-r或--regex选项。我们可以定义一个命令来检查正则表达式，如下所示：

define command {
    command_name  check_http_regex
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -r $ARG1$
}

如果需要检查某个特定的正则表达式是否不匹配内容，可以通过添加--invert-regex标志来实现：

define command {
    command_name  check_http_noregex
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -r $ARG1$ --invert-regex
}

使用此命令进行的服务检查如果响应匹配作为check_command指令第一个参数提供的模式，将返回CRITICAL。

其他类似的选项包括-e或--expect，它允许指定一个由逗号分隔的字符串集，至少其中一个字符串必须与检查通过的头部的第一行匹配。

另请参见

本章中的监控 Web 服务示例
第一章中的创建新主机和创建新服务示例，了解主机、服务和联系人
第二章中的创建新命令和自定义现有插件食谱，命令和插件的使用。

监控数据库服务

在本食谱中，我们将学习如何使用 Nagios Core 监控数据库服务器的状态。我们将以流行的 MySQL 为例，使用check_mysql插件，并讨论在本食谱的更多内容部分中运行实际的测试查询和为 PostgreSQL 指定类似的检查。

准备工作

你应该已经拥有一个 Nagios Core 3.0 或更高版本的服务器，并且至少配置了一个主机。我们将以delphi.naginet为例，这是一个在自己文件中定义的主机。你还应该理解主机和服务之间的基本关系，这在第一章，理解主机、服务和联系人的食谱中有介绍。

对于从监控服务器检查远程主机，数据库服务器需要在适当的网络接口上监听。还需要确保存在一个适当的数据库用户帐户，以便check_mysql插件进行身份验证。最好将此帐户设置为一个没有任何数据库权限的专用用户，因为凭据需要以纯文本存储，如果使用更敏感的凭据，可能会带来安全风险。

对于 MySQL，我们可以使用以下命令创建一个没有权限的新用户，假设监控服务器olympus.naginet的 IPv4 地址是10.128.0.11。这里使用了随机生成的密码：

mysql> CREATE USER 'nagios'@'10.128.0.11' IDENTIFIED BY 'UVocjPHoH0';

然后，我们可以使用监控服务器上的mysql客户端检查连接性：

$ mysql --host=delphi.naginet --user=nagios --password=UVocjPHoH0
mysql>

或者，直接以nagios用户身份从命令行运行插件：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_mysql -H delphi.naginet -u nagios -p UVocjPHoH0
Uptime: 1631  Threads: 1  Questions: 102  Slow queries: 0  Opens: 99 
Flush tables: 1  Open tables: 23  Queries per second avg: 0.62

如果在构建 Nagios 插件时没有安装 MySQL 库，可能会发现/usr/local/nagios/libexec目录下没有check_mysql和check_mysql_query二进制文件。我们可以通过在监控系统上安装 MySQL 共享库，重新构建并重新安装 Nagios 插件包来解决此问题。

默认情况下，还需要定义新命令以实际使用这些插件，这将在本食谱中完成。

如何操作...

我们可以如下设置一些基本的 MySQL 服务器数据库监控：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机的定义放在其他文件中，请转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含命令定义的适当文件，可能是commands.cfg，并添加以下定义：

define command {
    command_name  check_mysql
 command_line  $USER1$/check_mysql -H $HOSTADDRESS$ -u $ARG1$ -p $ARG2$
}

编辑包含主机定义的文件。主机定义可能看起来像以下代码片段：

define host {
    use        linux-server
    host_name  delphi.naginet
    alias      delphi
    address    10.128.0.51
}

在主机的定义下方，放置一个新的服务定义，用于 MySQL 检查，包括之前选择的用户名和密码作为参数：

define service {
    use                  generic-service
    host_name            delphi.naginet
    service_description  MYSQL
 check_command        check_mysql!nagios!UVocjPHoH0
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，将为 delphi.naginet 主机添加一个新的服务检查，描述为 MYSQL，它将使用 check_mysql 插件来报告 MySQL 服务器的状态。输出还将包括其正常运行时间、打开的表以及查询平均值等统计信息，和所有服务输出一样，将在 Web 界面的 Services 下显示。

它是如何工作的……

此配置定义了一个名为 check_mysql 的新命令，使用同名插件，接受两个参数；第一个是测试的 Nagios Core 用户名，在此为 nagios，第二个是该用户的密码。check_mysql 插件作为 MySQL 客户端，使用提供的凭据，向数据库请求诊断信息，并将其作为检查的一部分返回。

如果连接或使用 MySQL 服务器时遇到问题，它将标记为 CRITICAL 状态，并生成相应的通知。

还有更多……

我们可以通过为 -d 参数提供值，选择性地检查对特定数据库的访问权限。此数据库应该是 nagios 用户已被授予访问权限的数据库，否则检查将失败。

如果我们想检查在连接后是否能够实际运行查询，我们可以进一步扩展，使用 check_mysql_query 插件：

define command {
    command_name  check_mysql_query
 command_line  $USER1$/check_mysql_query -H $HOSTADDRESS$ -u $ARG1$ -p $ARG2$ -d $ARG3$ -q $ARG4$
}
define service {
    use                  generic-service
    host_name            delphi.naginet
    service_description  MYSQL_QUERY
 check_command        check_mysql_query!nagios!UVocjPHoH0!exampledb!"SELECT COUNT(1) FROM exampletbl"
}

上述代码片段将尝试在 exampledb 数据库上运行 SELECT COUNT(1) FROM exampletbl 查询。请注意，将查询用引号括起来很重要，以便它作为一个参数而不是多个参数进行处理。

类似于本食谱中指定的服务检查，可以使用 check_pgsql 插件（同样是标准 Nagios 插件集的一部分）为 PostgreSQL 数据库服务器配置。命令和服务检查定义可能类似于以下代码片段：

define command {
    command_name  check_pgsql
    command_line  $USER1$/check_pgsql -H $HOSTADDRESS$ -p $ARG1$
}
define service {
    use                  generic-service
    host_name            delphi.naginet
    service_description  PGSQL
    check_command        check_pgsql!N4Nw8o8X
}

在上述示例中，需要在 PostgreSQL 服务器的 pg_hba.conf 文件中授予监控服务器 IP 地址的访问权限，并访问默认的标准 template1 数据库。

在生产环境中，通常出于安全或编程策略的原因，数据库服务器并未配置为接受通过网络接口的直接连接，即使是在安全的接口上。许多系统上的打包 MySQL 和 PostgreSQL 服务器实际上默认仅在 localhost 接口 127.0.0.1 上监听。

这可能会稍微复杂化监控设置，但通常可以通过在数据库服务器上安装远程 Nagios 插件执行代理来解决，比如 NRPE 或 NSclient++。NRPE 的使用在第六章，启用远程执行中有详细讲解，使用的是这样配置的 MySQL 服务器作为示范。

另见

第一章中的创建新主机和创建新服务示例，理解主机、服务和联系人
第二章中的创建新命令示例，使用命令和插件
第六章中的使用 NRPE 监控远程机器上的本地服务示例，启用远程执行

监控 SNMP 查询的输出

在本示例中，我们将学习如何使用 check_snmp 插件来监控 简单网络管理协议（SNMP）请求返回的输出。

尽管名字中有“简单”二字，SNMP 实际上并不是一个非常简单的协议，但它是访问许多种类网络设备信息的常见方法，包括监控板、使用计量器、存储设备，以及工作站、服务器和路由设备。

由于 SNMP 得到了广泛的支持，并且通常能够向受信任的主机提供大量的信息，因此它是从主机收集信息的极好方式，这些信息无法通过网络服务获取。例如，虽然检查来自大型路由器的 PING 响应很简单，但可能没有简单的方法来检查它的接口状态，或者其路由表中某条路由的存在与否。

在 Nagios Core 中使用check_snmp可以自动从设备中获取这些信息，并生成相应的警报。虽然它的设置有些复杂，但值得学习如何使用它，因为它是 Nagios Core 中最强大的插件之一，尤其对于网络管理员来说，通常可以在大型网络的配置中看到定义了几十个命令来使用它。它通常可以用来补充或甚至替代远程插件执行守护进程，如 NRPE 或 NSclient++。

准备工作

你应该有一个已配置至少一个主机的 Nagios Core 3.0 或更高版本的服务器。你还应该了解主机和服务之间的基本关系，这些内容在第一章的示例中有讲解，理解主机、服务和联系人。

本文档假设您具有关于 SNMP 的基本知识，包括其一般预期用途、SNMP 社区的概念，以及 SNMP MIB 和 OID 的含义。特别是，如果您希望监视网络设备的某个属性，该属性通过 SNMP 可用，您应该知道该数据的 OID 是什么。这些信息通常可以在网络设备的文档中找到，或者可以通过针对主机运行适当的snmpwalk命令来查看所有 OID 的输出来推断出来。

您应该检查目标主机上是否运行了 SNMP 守护程序，并且监控主机上是否可用check_snmp插件。它作为标准 Nagios 插件的一部分包含在内，因此只要在编译这些插件时系统中可用了 Net-SNMP 库，该插件应该是可用的。如果没有，请在监控系统上安装 Net-SNMP 库并重新编译插件。

我们将使用从主机名为ithaca.naginet的 Linux 服务器检索总进程计数的示例，并在适当的高范围内标记WARNING和CRITICAL状态。我们还将讨论如何测试字符串的存在或不存在，而不是数值阈值。

测试主机是否以预期形式响应 SNMP 查询是个好主意。我们可以使用snmpget进行测试。假设社区名称为public，我们可以写：

$ snmpget -v1 -c public ithaca.naginet .1.3.6.1.2.1.25.1.6.0
iso.3.6.1.2.1.25.1.6.0 = Gauge32: 81

我们还可以通过直接作为nagios用户运行插件来测试该插件：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_snmp -H ithaca.naginet -C public -o .1.3.6.1.2.1.25.1.6.0
SNMP OK - 81 | iso.3.6.1.2.1.25.1.6.0=81

如何做...

我们可以定义一个命令和服务检查来检查 Linux 进程计数的 OID，如下所示：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果您将主机定义放在不同的文件中，则改为移动到其目录。
```
# cd /usr/local/nagios/etc/objects
```

编辑包含命令定义的适当文件，可能是commands.cfg，并将以下定义添加到文件末尾。

define command {
    command_name  check_snmp_linux_procs
 command_line  $USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -o .1.3.6.1.2.1.25.1.6.0 -w 100 -c 200
}

编辑包含主机定义的文件。主机定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  ithaca.naginet
    alias      ithaca
    address    10.128.0.61
}

在主机定义之后，使用我们的新命令添加一个新的服务定义。如果不同，请用您的 SNMP 社区名称替换public：

define service {
    use                  generic-service
    host_name            ithaca.naginet
    service_description  SNMP_PROCS
 check_command        check_snmp_linux_procs!public
}

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，将添加一个新的服务检查，其描述为SNMP_PROCS，添加到ithaca.naginet主机中，并且check_snmp插件将按照其正常检查请求指定 OID 的值。如果计数大于100，它将标记为WARNING状态；如果大于200，则标记为CRITICAL状态，并相应通知。所有这些都将显示在 Web 界面中的Services菜单项中，与任何其他服务一样。

如何工作...

上述配置定义了一个新的基于 check_snmp 插件的命令，并依此为 ithaca.naginet 服务器使用该命令进行新的服务检查。SNMP 请求的社区名称 public 作为参数传递给命令；其他一切，包括要请求的 OID，都是固定在 check_snmp_linux_procs 命令定义中的。

定义的命令行的一部分包括 -w 和 -c 选项。对于像我们这样的数值输出，这些选项用于定义超出值的限制，以便分别触发WARNING或CRITICAL状态。在这种情况下，我们定义了 100 个进程的WARNING阈值和 200 个进程的CRITICAL阈值。

同样，如果由于连接问题或语法错误导致 SNMP 检查完全失败，将报告UNKNOWN状态。

还有更多...

也可以测试 SNMP 检查的输出，以查看它们是否与特定的字符串或模式匹配，从而确定检查是否成功。例如，如果我们需要检查系统的主机名是否为ithaca.naginet（可能是一个应该始终成功的简单测试 SNMP 查询），那么我们可以设置如下的命令定义：

define command {
    command_name  check_snmp_hostname
 command_line  $USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -o .1.3.6.1.2.1.1.5.0 -r $ARG2$
}

具有以下相应服务检查：

define service {
    use                  generic-service    host_name            ithaca.naginet
    service_description  SNMP_HOSTNAME
 check_command        check_snmp_hostname!public!ithaca
}

这个特定的检查只有在 SNMP 查询成功并返回与第二个参数指定的字符串ithaca匹配的字符串时才会成功。

另见

本章中的创建 SNMP OID 以进行监控
本书中第一章的创建新主机和创建新服务配方，理解主机、服务和联系人
本书中第二章的创建新命令配方，与命令和插件一起工作

监控 RAID 或其他硬件设备

在这个配方中，我们将学习监控硬件设备属性的一般策略。由于厂商实现硬件的方式不同，这通常比监控标准网络服务更复杂。

至少有四种一般方法可以解决这个问题。

准备工作

你需要知道一些你想要监控的硬件的具体信息，包括型号。你最好还应该有一个带有 Net-SNMP 库编译的 Nagios Core 3.0 服务器，以便构建check_snmp插件，这是 Nagios 插件集的一部分。

如何做...

我们可以通过以下方式找到在本地或远程机器上监控任意硬件设备的方法：

检查是否已经存在用于轮询特定设备的官方或非官方 Nagios Core 插件。最好的起点是 Nagios Exchange，网址为http://exchange.nagios.org/，只需搜索硬件品牌，看看是否已有插件，按照第二章中的寻找插件食谱来进行。你可以按照同一章节中的安装插件食谱来安装插件。
检查你从硬件中需要的任何值是否已经作为 SNMP OID 导出，或者是否可以导出，以便使用本章中的监控 SNMP 查询的输出食谱进行检查。
如果没有，但有一个命令行诊断工具输出，或者一个可以用作检查的返回值，你可以考虑将其作为自定义 OID 导出到 SNMP 服务器中，使用本章中的创建一个新的 SNMP OID 来监控食谱。
最后，我们可能不得不自己编写插件。实际上，这并不像看起来那么困难；这一过程在第二章中的从零开始编写新插件食谱中有所讨论。这可能是定制硬件或非常罕见硬件的唯一选择。

工作原理...

如果我们在网上找到适合硬件的插件，主要的难点在于我们不仅要通过在硬件的OK和CRITICAL状态下测试插件来确保其有效（这可能很难做到），还要确保插件是安全的。Nagios Exchange 上的插件在添加之前会进行审查，但你在任何其他网站上找到的插件代码可能不安全运行。

尽可能使用 SNMP 进行这些类型的检查有两个优势：一是可以通过标准的 Nagios 插件check_snmp来检查这些值，二是这些值可以通过网络读取，这意味着我们可能不需要依赖如 NRPE 或 NSclient++之类的远程执行守护进程来获取这些信息。

另见

本章中的监控 SNMP 查询的输出和创建一个新的 SNMP OID 来监控食谱
第二章中的寻找插件、安装插件和从零开始编写新插件食谱，使用命令和插件

创建一个 SNMP OID 用于监控

在本食谱中，我们将学习如何在 Linux 服务器上配置一个 Net-SNMP snmpd服务器，以便通过 SNMP OID 返回命令的输出。这可以作为 NRPE 监控的替代方案，用于检查网络服务中无法直接访问的信息，以便 Nagios Core 可以通过其标准的check_snmp方法进行检查。

例如，这可以是监控硬件设备的一个非常好的方式，例如远程服务器上的RAID阵列，其中提供命令行诊断工具来报告状态为数字或字符串，但这些工具仅在本地有效，并且不会在 SNMP MIB 树中包含任何信息。

准备就绪

我们要检查的主机应运行 Net-SNMP snmpd服务器，允许对指定社区字符串（如public）的 MIB 树进行完全的读取访问。该 SNMP 服务器应能够在配置中使用exec指令，在 SNMP 客户端请求时返回命令的输出作为 SNMP OID 的值。因此，您需要了解 SNMP 的基础知识。

您还需要一个启用了 SNMP 的 Nagios Core 3.0 或更新版本的服务器，才能实际监控 OID，这将在监控 SNMP 查询输出方法中说明。

在本示例中，我们将处理一个简单的脚本，它在目标主机ithaca.naginet上运行，脚本路径为/usr/local/bin/raidstat，它返回一个整数：零表示 RAID 状态良好，非零则表示有问题。我们假设该工具可以以任何用户身份运行，并且不需要 root 权限。

如何操作...

我们可以按照以下方式设置自定义 SNMP OID：

将以下行添加到目标主机上的snmpd.conf文件中，替换生成所需输出的命令路径：
```
exec raidstat /usr/local/bin/raidstat
```
重新启动目标主机上的snmpd服务器，具体操作可能如下，具体取决于系统：
```
# /etc/init.d/snmpd restart
```

在监控服务器上，我们可以遍历.1.3.6.1.4.1.2021 OID，找到我们的raidstat OID 及其值：

$ snmpwalk -v1 -c public ithaca.naginet .1.3.6.1.4.1.2021 | less
...
iso.3.6.1.4.1.2021.8.1.2.1 = STRING: "raidstat"
iso.3.6.1.4.1.2021.8.1.3.1 = STRING: "/usr/local/bin/raidstat"
iso.3.6.1.4.1.2021.8.1.100.1 = INTEGER: 0
iso.3.6.1.4.1.2021.8.1.101.1 = STRING: "GOOD"
...

现在我们知道可以使用本章中的监控 SNMP 查询输出方法来查询检查 OID，并可以直接通过snmpget测试获取它：
```
$ snmpget -v1 -c public ithaca.naginet .1.3.6.1.4.1.2021.8.1.100.1
```

它是如何工作的...

snmpd配置中的exec调用定义了一个应该执行的程序，用于返回 OID 树中的新值。我们在输出中找到的四个 OID 如下：

1.3.6.1.4.1.2021.8.1.2.1: 这是我们分配的 OID 名称，raidstat
1.3.6.1.4.1.2021.8.1.3.1: 这是被调用脚本的完整路径，/usr/local/bin/raidstat
1.3.6.1.4.1.2021.8.1.100.1: 这是来自调用的返回值，以整数形式表示
1.3.6.1.4.1.2021.8.1.101.1: 这是来自调用的任何输出，以字符串形式表示

因此，这种设置可以用来检查任何命令的返回值和字符输出，只要该命令是snmpd用户能够执行的，对于像这样的特定情况，这是一个很好的临时监控方法。

还有更多...

如果需要，可以向服务器配置中添加多个exec命令。例如，如果我们需要通过命令tempstat检查 CPU 温度的状态，那么我们可能会定义：

exec raidstat /usr/local/bin/raidstat
exec tempstat /usr/local/bin/tempstat

这两个的返回值和输出将显示在 SNMP 输出中，并且在不同的 OID 中。

如果需要，命令定义后还可以跟随参数：

exec tempstat /usr/local/bin/tempstat --cpu=0

本书不涉及exec和类似的pass配置在 Net-SNMP 中的工作原理，但在本书编写时的文档中有广泛讨论，文档可以通过www.net-snmp.org/docs/readmefiles.html访问。

请注意，如果通过 SNMP 导出值不适用，远程监控的替代方法是使用Nagios 远程插件执行器 (NRPE) 在目标服务器上运行检查，并将结果返回给监控服务器。有关这方面的内容，请参见第六章，启用远程执行中的配方。

另请参见

本章中的创建 SNMP OID 以进行监控配方
第一章中的创建新主机和创建新服务配方，理解主机、服务和联系人
第二章中的创建新命令配方，与命令和插件一起工作
第六章中的使用 NRPE 监控远程机器上的本地服务配方，启用远程执行

第六章：启用远程执行

在本章中，我们将介绍以下几个教程：

使用 NRPE 监控远程机器上的本地服务
设置 NRPE 的监听地址
设置 NRPE 的允许客户端主机
安全地创建新的 NRPE 命令定义
给 NRPE 授予有限的 sudo 权限
使用 check_by_ssh 结合密钥认证来代替 NRPE。

介绍

对于一个可以访问网络相关部分的专用 Nagios Core 服务器，通过使用能进行 ICMP、TCP 和 UDP 连接的命令和插件来进行检查相对简单，以此来判断网络主机和服务的运行状态。这些方法可用于检查任何类型的网络服务，而无需在目标机器上安装任何东西。例如，当使用 check_http 插件检查 Web 服务器时，其工作方式与浏览器发起请求的方式相同。

然而，彻底监控一个网络通常不只是检查网络连接和可用性。检查网络的一些属性也很重要，这些属性并不直接对应于网络服务，因此不能通过网络连接直接进行检查。

这些通常是硬件或底层系统的属性，例如磁盘空间或系统负载平均值，或仅配置为本地监听的进程，通常用于数据库服务器。

我们可能会在所有系统上安装 Nagios Core，但这将使维护变得困难。更好的方法是有某种远程执行诊断程序的手段，使它们能直接在目标主机上运行，以获取所需的信息，然后通过专用网络服务将结果返回到单一的 Nagios Core 服务器。

解决这个问题有三种常见方法：

使用 check_nrpe 在目标机器上运行标准的 Nagios Core 插件，并将其结果透明地返回给监控服务器。
使用 check_by_ssh 通过 SSH 连接到目标机器，然后从监控服务器上运行任意命令。
使用 check_snmp 检查已配置提供返回值和目标主机上某些命令输出的 SNMP OID。

本章介绍前两种解决方案，重点讲解更常用的 Nagios 远程插件执行器（NRPE），并解释它与 check_by_ssh 解决方案的区别。关于 SNMP 配置的一些信息，请参见第五章中的 监控 SNMP 查询输出 和 创建 SNMP OID 进行监控 部分。

使用 NRPE 监控远程机器上的本地服务

在这个教程中，我们将学习如何在目标主机 roma.naginet 上安装并运行 NRPE 服务器。我们将使用它来通过 check_load 插件检查该主机的负载平均值。

这些检查的插件将在目标服务器上由 NRPE 守护进程执行，但结果将返回到我们的 Nagios Core 监控服务器olympus.naginet。这要求在监控服务器上安装check_nrpe插件，并在目标服务器上安装完整的 Nagios 插件集（但不包括 Nagios Core 本身）。

这是一个相对较长且深入的教程，因为它涉及在两台服务器上安装总共三种软件包。

准备工作

你需要一台安装了 Nagios Core 3.0 或更高版本的监控服务器。同时，你还应该有一个类 UNIX 的目标主机，打算监控该主机，并且能够运行 NRPE 守护进程。大多数现代类 UNIX 系统，包括 Linux 和 BSD，应该都能做到这一点。监控服务器和目标主机都需要互联网连接，并且你应该已经通过主机定义在监控目标主机，接下来我们会为它添加服务检查。

如果你的服务器没有直接连接到互联网的网关，你可以通过将相关文件下载到工作站或其他有互联网访问的机器后上传，来解决这个问题。

你应该了解从源代码配置、编译和安装软件的基本知识。在大多数情况下，通常的./configure、make和make install过程就足够了，本教程会带你完成这一过程。你需要安装make工具，并且还需要为配置和构建过程准备好其他工具，包括如gcc这样的 C 编译器。

你还应该对 Nagios Core 中主机和服务的相互关系有一个清晰的理解，这在第一章中有讨论，并且了解 Nagios Core 如何使用命令和插件，这部分内容在第二章中有说明。你不需要深入理解任何特定插件的使用；本教程会展示如何使用相关插件。

最后，你应该能够配置任何防火墙，以允许 Nagios Core 服务器与目标服务器之间通过 TCP 目的端口5666建立连接。

如何操作…

本教程的第一部分在目标服务器上完成：

下载并安装最新的 Nagios 插件包。写作时，链接可通过nagiosplugins.org/download/访问。

$ wget http://downloads.sourceforge.net/project/nagiosplug/nagiosplug/1.4.16/nagios-plugins-1.4.16.tar.gz
$ tar -xzf nagios-plugins-1.4.16.tar.gz

配置、编译并安装插件，就像在新的监控服务器上做的那样。你需要拥有root权限来执行make install命令。
```
$ cd nagios-plugins-1.4.16
$ ./configure
$ make
# make install
```
你可能需要为某些插件安装一些共享库和头文件，例如libssl实现。./configure脚本的输出应该会提示你遇到的任何此类问题。
从 Nagios Exchange 网站下载并安装 NRPE 的最新版本。在本文写作时，链接可通过 exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE--2D-Nagios-Remote-Plugin-Executor/details 访问。
```
$ wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.13.tar.gz
$ tar -xzf nrpe-2.13.tar.gz
```
进入 nrpe-2.13 源目录，配置、编译并安装守护进程及其默认配置。您将需要 root 权限才能执行 make install-daemon 和 make install-daemon-config 命令：
```
$ cd nrpe-2.13
$ ./configure
$ make all
# make install-daemon
# make install-daemon-config
```
如果目标主机上没有 nagios 用户，您可能需要先创建一个用户，才能正确安装守护进程：
```
# groupadd nagios
# useradd -r -g nagios nagios
```
编辑新安装的文件 /usr/local/nagios/etc/nrpe.cfg，找到以 allowed_hosts 开头的行。在此行添加逗号和监控服务器的 IP 地址。在本例中，我们添加了 IP 地址 10.128.0.11：
```
allowed_hosts=127.0.0.1,10.128.0.11
```

启动 nrpe 守护进程，并通过使用 pgrep 或 ps 搜索进程表来检查它是否正在运行：

# /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d
# pgrep nrpe
18593
# ps -e | grep [n]rpe
nagios 18593 1 0 21:55 ? 00:00:01 nrpe

如果您希望 nrpe 守护进程在启动时自动启动，请根据您的系统添加适当的 init 脚本。在 ./configure 时，源目录会生成一个示例 init-script。对于 Debian 派生系统和 SUSE 系统，也会分别生成 init-script.debian 和 init-script.suse。具体的操作方法将取决于您的系统，您可能需要查阅其文档。

接下来的部分将在监控服务器上完成。

再次以与目标服务器相同的方式下载 NRPE 的最新版本：

$ wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.13.tar.gz
$ tar -xzf nrpe-2.13.tar.gz

再次配置并构建软件。然而，需要注意的是，这一次的安装命令不同，因为我们安装的是 check_nrpe 插件，而不是 nrpe 守护进程：
```
$ cd nrpe-2.13.tar.gz
$ ./configure
$ make all
# make install-plugin
```
检查插件是否正确安装。它应保存在 /usr/local/nagios/libexec/check_nrpe 目录下：
```
$ ls /usr/local/nagios/libexec/check_nrpe
/usr/local/nagios/libexec/check_nrpe
```
转到包含 Nagios Core 对象配置的目录。默认情况下，这是 /usr/local/nagios/etc/objects：
```
$ cd /usr/local/nagios/etc/objects
```
编辑适当的文件以定义新命令。对于默认安装，/usr/local/nagios/etc/objects/commands.cfg 是一个不错的选择。在该文件末尾添加以下定义：
```
define command {
    command_name  check_nrpe
    command_line  $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
```

编辑定义目标主机为对象的文件。定义可能类似于以下代码片段：

define host {
    use        linux-server
    host_name  roma.naginet
    alias      roma
    address    10.128.0.61
}

在主机的定义下，其他已定义的服务之后，添加以下服务定义：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  LOAD
    check_command        check_nrpe!check_load
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此步骤后，一个名为 LOAD 的新服务将出现在 Web 界面中，准备进行检查，并将显示适当的状态，包括从目标主机上的 nrpe 守护进程读取的负载平均值：

我们可以在服务的详细页面查看有关检查执行方式及其结果的更多细节：

如果roma.naginet上的负载平均值超过了在目标主机的/usr/local/nagios/etc/nrpe.cfg中为check_load命令定义的限制，服务将进入WARNING或CRITICAL状态，并会在配置了通知的情况下发送通知，所有这一切都与非 NRPE 服务相同。

它是如何工作的...

NRPE 插件和守护进程用于在目标主机上运行 Nagios Core 插件，而不是在监控服务器上运行。这些检查的结果会被传回监控服务器，并由 Nagios Core 以与在监控服务器上运行插件（例如check_http或check_ssh）相同的方式记录和分析。

我们遵循的食谱主要做了四件事：

我们将最新的 Nagios 插件包安装到目标主机上，包括check_load插件。这是必要的，因为该插件实际上是在目标主机上运行的，而不是在监控服务器上，后者的插件用于检查网络服务。
我们将nrpe守护进程安装到目标主机，并附带了一个默认的配置文件nrpe.cfg。这是一个网络服务，通过它，check_nrpe插件可以请求在目标主机上运行命令。插件将由这个进程运行，通常是作为nagios用户。
我们将check_nrpe插件安装到监控主机，并定义了一个同名的命令来使用它。该命令接受一个在 $ARG1$ 宏中的参数；其值是应该在目标主机上运行的命令。在这种情况下，我们为此参数提供了check_load。
我们设置了一个服务，通过check_nrpe监控标准check_load插件的输出。

与其他 Nagios Core 插件一样，check_nrpe程序也可以直接从命令行运行。如果我们想要测试在前一部分中配置的响应，那么我们可能会运行以下命令：

$ /usr/local/nagios/libexec/check_nrpe -H roma.naginet -c check_load
OK - load average: 0.00, 0.00, 0.00|load1=0.000;15.000;30.000;0;
load5=0.000;10.000;25.000;0; load15=0.000;5.000;20.000;0;

在这种情况下，OK状态和通过check_load检索的负载平均值作为check_nrpe调用的结果，由nrpe守护进程返回。

需要特别注意的是，这个简单的 NRPE 配置默认并不完全安全。在另见部分列出的食谱提供了一些基本的手段来保护 NRPE 实例不被滥用。这些措施应该与合理的防火墙策略一起使用。

还有更多...

当然，check_load并不是唯一可以通过这种方式在目标服务器上运行的插件。如果我们检查目标主机上的/usr/local/nagios/etc/nrpe.cfg文件，在文件的末尾，我们会找到一些其他的命令定义，这些命令将在监控服务器发出的请求中由check_nrpe运行：

command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/nagios/libexec/check_procs -w 150 -c 200

我们识别出check_load是这其中的第二个。请注意，它已经在其-w和-c参数中包括了一些WARNING和CRITICAL警告的阈值。

如果我们还想检查该服务器上的进程数量，我们可以为roma.naginet添加一个服务检查，定义如下：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  PROCS
    check_command        check_nrpe!check_total_procs
}

如果进程数量超过 150，该服务将生成一个WARNING警报，超过 200 则生成CRITICAL警报。同样，插件是在目标服务器上运行的，而不是在监控服务器上。

check_nrpe的另一个有用且常见的应用是在数据库服务器上进行远程检查，使用如check_mysql和check_pgsql等插件，这通常发生在服务器因安全原因不在网络接口上监听时。相反，它们仅在localhost或 UNIX 套接字上监听，因此无法访问监控服务器。为了解决这个问题，我们可以在目标服务器的nrpe.cfg末尾添加一个新的命令定义，如下所示：

command[check_mysql]=/usr/local/nagios/libexec/check_mysql -u nagios -d nagios -p wGG7H233bq

随后，在监控服务器上可以使用check_mysql命令进行相应的检查：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  MYSQL
    check_command        check_nrpe!check_mysql
}

请参阅第五章中的监控数据库服务食谱，了解如何使用check_mysql和check_pgsql插件的详细信息。

因此，NRPE 不仅对检查系统属性或硬件有用，还适用于任何需要在目标主机上运行而不是在监控主机上运行的插件。

最后，需要注意的是，默认nrpe.cfg文件中包含的命令定义仅作为示例；你可能需要微调其中一些命令的参数，并移除不使用的命令，同时添加你自己的命令。

另见

本章中的设置 NRPE 监听地址、设置允许的客户端主机、安全创建新的 NRPE 命令定义和授予 NRPE 有限的 sudo 权限食谱
第五章中的监控数据库服务食谱

设置 NRPE 的监听地址

在本食谱中，我们将学习如何让 NRPE 在目标主机的特定 IP 地址上监听。这可能在具有多个网络接口的主机上进行，以防止来自不受信任接口（例如公共互联网）对nrpe守护进程的无效请求。此方法也适用于将守护进程配置为仅在受信任的 VPN 接口上监听。

此配置在服务器具有一个专用管理网络接口，并且监控服务器也能访问该接口时特别有用，可以防止nrpe守护进程在其他接口上不必要地响应请求，从而关闭潜在的安全漏洞。

准备工作

你应该已在 Nagios Core 3.0 或更高版本的监控服务器上配置了目标主机。目标主机应该运行nrpe守护进程，并在所有接口上监听（我们会进行修复）。你可以通过pgrep或ps验证nrpe是否正在运行：

# pgrep nrpe
29964
# ps -e | grep [n]rpe
nagios 29964 1 0 21:55 ? 00:00:01 nrpe

你可以通过检查netstat的输出，查看nrpe守护进程是否在所有接口上监听：

# netstat -plnt | grep nrpe
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN 29964/nrpe

0.0.0.0地址表明nrpe正在所有接口上监听，这是我们想要更正的地方。

如何操作...

我们可以通过以下方式配置nrpe守护进程仅监听一个地址：

编辑nrpe守护进程的配置文件。默认位置是/usr/local/nagios/etc/nrpe.cfg。查找以server_address开头的行，默认情况下通常会被注释掉：
```
#server_address=127.0.0.1
```
如果你没有这样的行，可以在文件末尾添加它。
如果该行被注释掉，取消注释，去掉前面的#字符，并将127.0.0.1地址更改为你希望限制nrpe进程监听的地址：
```
server_address=10.128.0.61
```
重启nrpe守护进程。如果你为它安装了init脚本，你可以通过以下方式重启：
```
# /etc/init.d/nrpe restart
```
如果没有，你可以通过向其发送HUP信号来重启该进程，使用kill命令，它将提示进程重新读取配置文件并恢复运行：
```
# pgrep nrpe
29964
# kill -HUP 29964
```

完成这些设置后，nrpe守护进程现在应该只会在指定的地址上监听。我们可以通过使用netstat来验证这一点：

# netstat -plnt | grep nrpe
tcp 0 0 10.128.0.61:5666 0.0.0.0:* LISTEN 29964/nrpe

工作原理...

我们在前面章节中调整的配置定义了nrpe守护进程应该监听的地址，并暗示它不应该响应其他地址的请求。

由于nrpe服务器明确设计用于应远程服务器的请求运行命令，因此在适当的地方采取像这样的措施非常重要，以防止攻击者利用该服务。

另请参阅

本章中的在远程机器上监控本地服务使用 NRPE食谱。

设置 NRPE 允许的客户端主机

在这个食谱中，我们将学习如何配置 NRPE 守护进程，使其只响应来自特定 IP 地址的请求，通常是指定的 Nagios Core 服务器或监控你的网络的服务器。这意味着nrpe不会执行插件或返回任何来自不在此列表中的 IP 地址的check_nrpe请求的结果。

这是运行 NRPE 服务器的基本安全步骤。应该与硬件或软件防火墙和安全策略一同实施。如果目标主机的接口或路由连接到不受信任的网络，则可能会有攻击者发送虚假请求来获取系统信息，导致日志被大量检查请求占满硬盘，甚至可能会利用nrpe守护进程或 Nagios 插件。

准备工作

你应该在 Nagios Core 3.0 或更高版本的监控服务器上为目标主机配置检查。目标主机应运行nrpe守护进程。你可以使用pgrep或ps命令验证nrpe是否正在运行：

# pgrep nrpe
29964
# ps -e | grep [n]rpe
nagios 29964 1 0 21:55 ? 00:00:01 nrpe

我们可以通过尝试打开telnet或netcat连接来验证目标主机是否没有配置为响应特定的 IP 地址。如果我们不是被允许的主机之一，nrpe会立即关闭会话，而无需等待任何输入：

$ telnet roma.naginet 5666
Trying 10.128.0.61...
Connected to 10.128.0.61.
Escape character is '^]'.
Connection closed by foreign host.

这假设 NRPE 正在监听其默认端口号5666。在这个示例中，我们将把 IP 地址10.128.0.12添加到允许从 NRPE 请求信息的主机列表中。

如何操作……

我们可以按照以下方式配置nrpe守护进程，以响应新的地址：

编辑nrpe守护进程的配置文件。默认位置是/usr/local/nagios/etc/nrpe.cfg。查找以allowed_hosts开头的行。它可能类似于以下代码片段：
```
allowed_hosts=127.0.0.1,10.128.0.11
```
向该行添加或删除 IP 地址，用逗号分隔。对于这个示例，我们将添加一个新地址：
```
allowed_hosts=127.0.0.1,10.128.0.11,10.128.0.12
```
重启nrpe守护进程。如果你已经为其安装了init脚本，你可以使用类似以下的命令来重启它：
```
# /etc/init.d/nrpe restart
```
如果没有，你可以通过使用kill命令发送HUP信号来重启该进程，这将促使它重新读取配置文件并继续运行：
```
# pgrep nrpe
29964
# kill -HUP 29964
```

完成此操作后，nrpe守护进程现在应该只对指定的主机做出响应，其他请求将立即关闭连接。我们可以通过另一个telnet测试来验证我们的新主机是否被允许与roma.naginet上的nrpe服务通信：

$ telnet roma.naginet 5666

请注意，nrpe守护进程现在正在等待输入，而不是像之前那样立即关闭连接。这意味着我们现在可以从10.128.0.12运行check_nrpe检查（如果需要的话）。

它是如何工作的……

我们上面调整的配置定义了一组地址，如果有请求发出，nrpe守护进程应该响应，并且意味着它应该拒绝来自任何其他地址的请求。

nrpe守护进程检查传入连接的 IP 地址，如果定义了allowed_hosts指令，它会检查该地址是否在列表中。如果不在，它会关闭连接并拒绝运行任何插件，更不用说返回任何插件的输出了。

还有更多……

allowed_hosts指令实际上是可选的；如果我们愿意的话，我们可以将nrpe服务器设置为响应任何 IP 地址的请求。然而，默认安装和示例配置默认启用了它，允许来自本地主机 IP 127.0.0.1的请求，以及./configure运行时主机拥有的任何网络地址。

这是一个明智的策略，因为 Nagios Core 插件是由第三方在开源社区中设计的，旨在用于受信任网络中的监控目的，并不一定非常安全。一个插件实际上不需要有安全漏洞就能引发这样的问题；例如，如果它所执行的检查非常消耗资源，像是打开大量 TCP 连接或查询一个大型数据库，攻击者只需要在短时间内发出大量的check_nrpe请求，就可能在目标主机上引发问题（如果允许的话）。

另见

本章中的使用 NRPE 监控远程机器上的本地服务配方

安全地创建新的 NRPE 命令定义

在本节中，我们将学习如何安全地为 nrpe 创建新的命令定义，以便在监控服务器请求时运行。我们需要这么做，因为即使在目标主机上安装了大量插件并运行 nrpe，该守护进程也只会运行其配置文件中定义的命令。

我们还将学习如何在严格必要的情况下将参数传递给这些命令，以及这可能带来的负面安全后果。

准备工作

你应该在 Nagios Core 3.0 或更高版本的监控服务器中配置一个目标主机进行检查。目标主机应运行 nrpe 守护进程。你可以使用 pgrep 或 ps 来验证 nrpe 是否正在运行：

# pgrep nrpe
29964
# ps -e | grep [n]rpe
nagios 29964 1 0 21:55 ? 00:00:01 nrpe

我们可以通过查找配置文件中的 command 指令来检查 nrpe 已经配置运行的命令列表。默认情况下，这个文件是 /usr/local/nagios/etc/nrpe.cfg，并且默认的命令定义通常在文件的末尾：

command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/nagios/libexec/check_procs -w 150 -c 200

我们将向这组命令中添加另一个命令，用于检查可用的交换空间是否超过特定的阈值，使用标准的 Nagios Core 插件 check_swap。我们可以通过在目标主机上运行它来测试是否工作正常：

$ /usr/local/nagios/libexec/check_swap -w 10% -c 5%
SWAP OK - 100% free (216 MB out of 217 MB) |swap=216MB;21;10;0;217

为了完整起见，我们还将展示如何在 Nagios Core 监控服务器上使用这个新插件定义服务检查。

如何操作...

我们可以按照如下方式向 nrpe 配置添加一个新的命令定义：

编辑 nrpe 守护进程的配置文件。默认位置是 /usr/local/nagios/etc/nrpe.cfg。查找以 command 开头的行，这些行默认通常位于文件末尾。

在文件末尾添加以下行：

command[check_swap]=/usr/local/nagios/libexec/check_swap -w 10% -c 5%

重启 nrpe 守护进程。如果你为其安装了 init 脚本，你可能可以使用类似以下命令来完成此操作：
```
# /etc/init.d/nrpe restart
```
如果没有，你可以通过发送 HUP 信号来重启进程，使用 kill 命令，迫使其重新读取配置文件并恢复运行：
```
# pgrep nrpe
29964
# kill -HUP 29964
```

完成此步骤后，假设我们的监控服务器已包含在 allowed_hosts 指令中并且可以联系目标主机，则在监控主机上调用 check_nrpe 应该返回目标主机上 check_swap 插件的状态和输出：

$ /usr/local/nagios/libexec/check_nrpe -H roma.naginet -c check_swap
SWAP OK - 100% free (216 MB out of 217 MB) |swap=216MB;21;10;0;217

反过来，这允许我们在监控服务器上使用服务定义中的检查，通过 check_nrpe 命令：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  SWAP
    check_command        check_nrpe!check_swap
}

它是如何工作的...

上一节中添加的配置在 nrpe.cfg 中定义了一个名为 check_swap 的新命令。在 nrpe.cfg 中定义新命令的一般形式如下：

command[command_name] = command_line

我们为 NRPE 定义了一个命令 check_swap。它不接受任何参数，而实际的 check_swap 插件需要这些参数；相反，参数被硬编码到命令定义中，两个选项 -w 10% 和 -c 5% 设置了可用交换空间的阈值。

除了检查系统属性（如负载平均值或交换空间）之外，这些属性通常只能通过像 SNMP 这样的系统来直接获取，NRPE 的另一个常见用途是报告仅在本地监听的网络服务的状态，或者监控主机无法直接访问的服务。数据库服务器监控就是一个很好的例子。我们可以在nrpe.cfg中定义以下命令：

command[check_mysql] = /usr/local/nagios/libexec/check_mysql -u nagios -d nagios -p NFmxenQ5

假设在目标主机上安装了check_mysql插件，如果在编译时提供了 MySQL 客户端库和头文件，那么这个命令将启用从监控主机执行此检查：

$ /usr/local/nagios/libexec/check_nrpe -H roma.naginet -c check_mysql
Uptime: 420865  Threads: 1  Questions: 172  Slow queries: 0  Opens: 99
Flush tables: 1  Open tables: 23  Queries per second avg: 0.0

这可以配置为使用适当的check_nrpe命令定义来进行服务检查，如下所示：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  MYSQL
    check_command        check_nrpe!check_mysql
}

因此，我们能够在不直接连接到 MySQL 服务器的情况下获取远程主机roma.naginet上 MySQL 服务器的状态；我们安排目标主机上的 NRPE 服务代表监控服务器执行此操作。

这不仅对在目标主机上运行的网络服务有用。它还可以用来委托任何远程主机可以执行的检查，而监控服务器无法执行。通过使用 NRPE，也可以绕过 NAT 的可寻址性问题，因为运行在像192.168.1.1这样的地址上的服务从网络外部是无法寻址的。如果 NRPE 在 NAT 网关上运行，我们可以利用它通过本地地址寻址适当的系统。

还有更多...

此外，在nrpe.cfg文件的底部，你将找到一些关于如何将参数作为check_nrpe请求的一部分提供给 NRPE 命令的信息，而不是硬编码它们。文件中包含的注释非常明确地指出，这样做存在一些风险：

以下示例允许用户提供的参数，并且仅在 NRPE 守护进程编译时支持命令参数，并且此配置文件中的dont_blame_nrpe指令设置为'1'时才能使用。这带来潜在的安全风险，因此在执行此操作之前，请确保阅读SECURITY文件。

重要的是要理解，当在目标主机上运行 NRPE 时，你是在运行一个允许网络机器在目标机器上执行命令的服务，而没有强认证，这也是为什么保持 NRPE 安全如此重要。如果你允许向命令传递参数，你需要意识到这样做的全部后果和风险，推荐的SECURITY文件对此做了很好的解释。

如果你真的想使用它，需要重新配置并重新编译nrpe守护进程，并使用--enable-command-args开关：

$ ./configure --enable-command-args
$ make all
# make install-daemon

然后将nrpe.cfg中的dont_blame_nrpe参数设置为1，否则默认值为0：

dont_blame_nrpe=1

在重新启动nrpe后（如果你重新构建了它，这次你需要完全重启它，而不仅仅是发送HUP信号），这将允许我们使用类似于以下的命令定义：

command[check_mysql_args]=/usr/local/nagios/libexec/check_mysql -H localhost -u $ARG1$ -d $ARG2$ -p $ARG3$

这个命令允许像这样从监控服务器进行检查，使用 check_nrpe 的 -a 选项：

# /usr/local/nagios/libexec/check_nrpe -H roma.naginet -c check_mysql_args -a nagios nagios NFmxenQ5

由于安全问题，我建议你尽可能避免使用命令参数。如果你确实需要使用它们，确保流量是加密的，特别是当它包含用户名和密码时。这方面的建议可以在 nrpe 守护进程的 SECURITY 文档中找到。

另见

本章中的 在远程机器上使用 NRPE 监控本地服务 和 给 NRPE 赋予有限的 sudo 权限 食谱
第五章中的 监控数据库服务 食谱，监控方法

给 NRPE 赋予有限的 sudo 权限

在这个食谱中，我们将学习如何解决 NRPE 执行权限的问题。大多数标准的 Nagios 插件不需要特别的权限来运行，尽管这取决于你系统的安全限制有多严格。然而，一些插件需要以 root 用户，或许是以 nrpe 以外的其他用户身份运行。这种情况通常发生在那些需要请求系统级资源的插件，例如检查 RAID 阵列的完整性。

解决此问题有四种常见方法：

不推荐：一种方法是将插件设置为 setuid，意味着它们将始终以拥有它们的用户身份运行，无论是谁执行它们。这样做的问题在于，设置这个标志会允许任何人以 root 用户身份运行程序，而不仅仅是 nrpe，这是一个非常常见的攻击向量。
更糟糕的是：另一种方法是以 root 用户身份运行 nrpe，或者以适当的用户身份运行。这是通过在 nrpe.cfg 中更改 nrpe_user 和 nrpe_group 属性来实现的。这种做法更加危险，完全违反了最小权限原则；我们应该尽可能给用户最少的权限，只让它完成所需的工作。绝对不要这样做！
较好：第三种方法是使用 nrpe.cfg 中的 command_prefix，将 /usr/bin/sudo 作为前缀添加到所有命令中，并为 nrpe 提供完全的 sudo 权限，仅运行 /usr/local/nagios/libexec 中的插件。这种方法稍好，但仍然相当冒险，因为我们可能并不需要每个命令都以 root 用户身份运行，只有一两个命令需要。
最佳：最佳的方法是使用 sudo 为 nrpe 用户分配有限的权限，仅限于它需要运行的命令，并且仅限于必须由它运行的用户身份。

最后一种解决方案是最可能安全的，因此我们将在这里查看一个示例。我们将以 root 用户身份运行 check_procs 插件，以获取进程计数。在大多数情况下，你不需要 root 权限就能获取所有进程的完整计数，但在安装了非常严格的 grsecurity 补丁的系统上，可能需要 root 权限。

准备工作

你应该在 Nagios Core 3.0 或更高版本的监控服务器上配置一个目标主机进行检查。目标主机应当运行nrpe守护进程，并在所有接口上监听。你可以通过pgrep或ps验证nrpe是否正在运行：

# pgrep nrpe
29964
# ps -e | grep [n]rpe
nagios 29964 1 0 21:55 ? 00:00:01 nrpe

你还应该在目标系统上安装并配置好sudo，并理解它的作用。我们将编辑/etc/sudoers文件，为我们的nrpe用户授予root权限，仅限于某个程序。这个步骤假设nrpe守护进程是以nagios用户和nagios组运行的。

操作步骤如下...

我们可以为nrpe用户授予有限的root权限，仅限于一个命令，具体操作如下：

编辑/etc/sudoers文件。最安全的做法通常是使用visudo命令，它会创建文件的临时副本并验证其语法是否正确，然后再安装：
```
# visudo
```
将以下行添加到文件中，并保存：
```
nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_procs
```
请注意，如果requiretty指令出现在你的/etc/sudoers文件中的任何位置，你可能需要将其移除才能使其正常工作。
使用sudo切换到nagios用户，测试运行命令是否以root身份执行，并且没有密码提示：
```
# sudo -s -u nagios
$ sudo /usr/local/nagios/libexec/check_procs
PROCS OK: 89 processes
```
编辑nrpe守护进程的配置文件。默认位置是/usr/local/nagios/etc/nrpe.cfg。查找check_total_procs的命令定义，如果没有的话，创建一个。请注意，/usr/bin/sudo已经添加到命令的开头：
```
command[check_total_procs]=/usr/bin/sudo /usr/local/nagios/libexec/check_procs -w 150 -c 200
```
重启nrpe守护进程。如果你为其安装了init脚本，你可以尝试使用类似以下命令来重启：
```
# /etc/init.d/nrpe restart
```
如果没有，你可以通过发送HUP信号使用kill命令重启该进程，这将促使其重新读取配置文件并继续运行：
```
# pgrep nrpe
29964
# kill -HUP 29964
```

完成此操作后，我们现在应该能够从监控服务器发出check_nrpe调用，并获得成功的响应：

$ /usr/local/nagios/libexec/check_nrpe -H roma.naginet -c check_total_procs
PROCS OK: 89 processes

它是如何工作的...

上述配置并不会对nrpe的行为产生太大变化；大部分配置实际上是在它的主机系统上完成的。我们所做的唯一更改是修改check_total_procs的命令定义，使其通过sudo运行。

为了实现不需要密码的操作，我们在/etc/sudoers文件中进行了定义，使得nagios用户执行该程序时无需密码，以root权限运行。由于nrpe是以nagios用户身份运行的，因此它只能够对该命令使用sudo，且不需要密码。

这意味着，当我们从监控服务器调用check_total_procs命令时，它会返回插件的完整输出，正如它以root权限运行时的输出，但nagios用户没有root权限来运行任何其他可能危险的命令，如rm或halt。

还有更多内容...

尽管这是一种更安全的方式来允许以另一个用户身份运行nrpe，但仍然需要信任以root权限运行的插件是安全的，并且无法轻易被利用。在运行自定义代码或从网上找到的插件之前，务必非常小心！

如果你打算允许nagios用户运行多个不同的程序，那么在/etc/sudoers中通过Cmnd_Alias定义它们可能会显得更整洁：

Cmnd_Alias NAGIOS = /usr/local/nagios/libexec/check_procs, /usr/local/nagios/libexec/check_load
nagios ALL=(ALL) NOPASSWD: NAGIOS

另请参见

本章中的使用 NRPE 监控远程机器上的本地服务和使用check_by_ssh和密钥认证代替 NRPE的示例

使用`check_by_ssh`和密钥认证代替 NRPE

尽管本章中的所有前面示例都表明 NRPE 可以非常有效地被限制并加以保护，但我们可能需要某种身份验证手段来访问目标主机，以便在其上运行相应的 Nagios 插件。nrpe守护进程不需要任何身份验证即可返回关于主机状态的信息；只要 IP 地址匹配，并且命令已定义为可执行，它就会返回信息。

如果你已经在网络中使用 SSH 密钥进行公钥基础设施，那么你可能会更倾向于使用check_by_ssh插件，它允许你在运行任何命令之前，通过公钥认证与目标主机进行认证。这仅在目标主机运行ssh守护进程时适用。

在本例中，我们将重复本章第一篇示例中针对check_load插件的设置，使用 NRPE 监控远程机器上的本地服务，但我们将改为使用check_by_ssh插件。

准备工作

你应该准备好一个 Nagios Core 3.0 或更新版本的服务器，并安装了ssh客户端软件，同时目标主机应运行sshd。OpenSSH 实现应该能正常工作。

目标主机应该安装所有 Nagios 插件；在此案例中，我们使用的是check_load。

你应该了解公钥认证及其优缺点。维基百科有一篇关于公钥加密和认证的精彩文章，地址是en.wikipedia.org/wiki/Public-key_cryptography。

有一个关于使用密钥基础设施进行 SSH 认证的流行介绍，详见support.suso.com/supki/SSH_Tutorial_for_Linux。

我们将通过合理的密钥基础设施设置进行操作，但最好了解其工作原理，以防此设置不适合你的配置。

如何操作...

我们可以通过check_by_ssh从远程主机获取check_load的输出，如下所示：

在监控服务器上，为nagios用户决定私钥和公钥的位置。我建议将它们放在/usr/local/nagios/keys中。创建此目录并将其归nagios用户所有，只允许该用户读取：
```
# KEYSDIR=/usr/local/nagios/keys
# mkdir -p $KEYSDIR
# chown nagios.nagios $KEYSDIR
# chmod 0700 $KEYSDIR
```
使用su或sudo切换到nagios用户：
```
# su nagios
# sudo -s -u nagios
```
使用ssh-keygen生成一对私钥和公钥。这里我们使用了 2048 位的 RSA 密钥；根据你的网络设置选择适当的密钥长度和加密算法。
```
$ ssh-keygen -b 2048 -t rsa -f /usr/local/nagios/keys/id_rsa
```
当提示输入密码短语时，直接按Enter键表示你不需要密码短语。

这应该会在/usr/local/nagios/keys目录中创建两个文件，分别叫做id_rsa和id_rsa.pub。第一个是私钥，应该始终保密。第二个是公钥，可以安全地分发并安装到其他机器上。

确定目标主机上authorized_keys文件的位置。最简单的方式可能是为nagios用户指定一个$HOME目录，并在适当时创建它：

# NAGIOSHOME=/home/nagios
# usermod -d $NAGIOSHOME nagios
# mkdir -p $NAGIOSHOME/.ssh
# chown -R nagios.nagios $NAGIOSHOME
# chmod 0700 $NAGIOSHOME/.ssh

将/usr/local/nagios/keys/id_rsa.pub文件从监控服务器复制到目标机器的/home/nagios/.ssh/authorized_keys。执行此操作的方法有很多种，一种可能的方法是使用scp：
```
$ whoami
nagios
$ scp /usr/local/nagios/keys/id_rsa.pub roma.naginet:.ssh/authorized_keys
```
你可能需要为目标主机上的nagios用户暂时设置一个密码，以完成此操作：
```
# passwd nagios
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully.
```

检查是否可以现在从监控服务器以nagios用户身份无密码登录到目标服务器：

$ whoami
nagios
$ ssh -i /usr/local/nagios/keys/id_rsa roma.naginet
Linux roma 2.6.32-5-686 #1 SMP Mon Oct 3 04:15:24 UTC 2011 i686
Lost login: Sun Jul 29 18:23:14 2012 from olympus.naginet

返回监控服务器，检查是否能够运行check_by_ssh插件，以调用远程服务器上的一个已安装插件；在此示例中，我们调用的是check_load：

$ whoami
nagios
$ /usr/local/nagios/libexec/check_by_ssh \
 -H roma.naginet \
 -i /usr/local/nagios/keys/id_rsa \
 -C '/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,24,20'
OK - load average: 0.00, 0.00, 0.00|load1=0.000;15.000;30.000;0;
load5=0.000;10.000;24.000;0; load15=0.000;5.000;20.000;0;

请注意，-C选项的值需要用引号括起来。

现在我们已经验证了check_by_ssh在我们的基础设施中能够正常工作，我们可以在/usr/local/nagios/etc/objects/commands.cfg中定义一个命令来使用它：
```
define command {
    command_name  check_by_ssh
    command_line  $USER1$/check_by_ssh -H $HOSTADDRESS$ -i /usr/local/nagios/keys/id_rsa -C '$ARG1$'
}
```

我们可以将该命令应用到roma.naginet的新服务检查，如下所示，最好将其放在主机定义下方：

define service {
    use                  generic-service
    host_name            roma.naginet
    service_description  LOAD_BY_SSH
    check_command        check_by_ssh!/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，带有描述LOAD_BY_SSH的新服务应出现在 Web 界面中，准备进行检查，并将显示相应的状态，包括通过SSH读取的目标主机的负载平均值。对 Nagios Core 来说，检查结果与通过 NRPE 获取的结果完全相同。

它是如何工作的...

通过 NRPE 和 SSH 检查服务实际上是一个相似的过程；核心思想是我们使用监控服务器和目标主机之间共享的另一个网络服务，指示目标主机运行一个插件，并将结果返回给监控服务器。

在check_by_ssh的情况下，这是通过 SSH 连接完成的。管理员通常通过ssh客户端在远程主机上运行命令，只需将要运行的命令添加到命令行中：

$ hostname
olympus.naginet
$ ssh roma.naginet hostname
roma.naginet

check_by_ssh插件的作用仅仅是将此过程正式化为 Nagios 插件的上下文。我们定义的命令行指令的command_line值可以分解为以下几个部分：

$USER1$/check_by_ssh：这是插件的路径，按照命令定义的惯例，使用 $USER1$ 宏来扩展为/usr/local/nagios/libexec。
-H $HOSTADDRESS$：这指定了插件应该连接到任何使用该命令的主机或服务。
-i /usr/local/nagios/keys/id_rsa：这指定了用于与远程主机进行身份验证的私钥的路径。
-C '$ARG1$'：这指定了check_by_ssh在目标主机上运行的命令，这个命令在服务的check_command定义中作为第一个参数；在本例中，我们的命令是：
```
/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
```

请注意， $ARG1$ 需要加上引号，因为我们希望将整个命令作为一个参数传递给check_by_ssh。

还有更多...

使用check_by_ssh代替check_nrpe可以通过公钥进行完全身份验证，而不仅仅是通过拥有正确的 IP 地址。它还隐式加密所有流量，从而最大限度地减少敏感数据（如用户名或密码）被拦截的风险。你应该使用哪一个插件，很大程度上取决于你的网络性质和安全策略。如果你愿意，完全可以同时使用这两者。

请小心不要将这个插件与check_ssh混淆，后者检查 SSH 服务本身是否运行，并在第五章的监控 SSH 服务示例中讨论，监控方法。

另见

本章中的在远程机器上监控本地服务（使用 NRPE）示例
第五章中的监控任何主机的 SSH示例，监控方法

第七章：使用网页界面

在本章中，我们将涵盖以下内容：

使用战术概览
查看和解释可用性报告
查看和解释趋势
查看和解释通知历史
在网页界面中添加主机或服务的注释
查看网页界面中的配置
从网页界面安排检查
通过网页界面确认问题

简介

Nagios Core 的网页界面是管理员查看被监控网络当前状态的首选方式。通过 CGI 和 PHP 脚本，它可以提供所有被监控主机和服务的总体性能概况。它还提供有关其当前状态的信息以及如何执行检查。这比通常在电子邮件通知中包含的细节要多得多。

在大多数方面，Nagios Core 的网页界面（没有任何插件）是为了显示信息而设计的，而不是用来控制或配置服务器，但有些操作可以通过它来实际改变 Nagios Core 的运行方式。这些操作包括以下内容：

禁用或启用主动检查和被动检查、事件处理程序、通知和波动检测，无论是针对所有主机和服务还是特定的主机和服务
发送关于主机或服务的自定义通知，这些通知不一定与实际状态变化相对应
重新安排检查，通常是在管理员认为问题已经解决并希望重新检查时，优先进行检查
确认问题，以便管理员可以抑制关于他们正在修复的问题的进一步通知
安排停机时间以抑制某一时间段内的通知；这在第三章《与检查和状态的协作》中“为主机或服务安排停机时间”的例子中已讨论过
为任何其他管理员留下关于主机和服务的注释，供他们检查；列表中的许多其他操作将隐式地执行此操作

我们不会在这里提供网页界面的全面概述，因为它的许多功能在其他章节中已经解释，或者是相当直观的。相反，我们将探索通过网页界面进行的一些运行时行为变化，这些变化列在前一节中，并且在左侧导航菜单中的报告部分下使用和解释可用的报告。

网页界面的另一个重要且极其有用的部分，网络状态图，在第八章《管理网络布局》中有几个例子进行了讨论。我们在这里不讨论它，因为它非常有用，值得单独成为一个章节。

使用战术概览

在本节中，我们将查看 Nagios Core Web 界面的战术概览屏幕。顾名思义，这个屏幕提供了对当前受监控主机和服务以及 Nagios Core 服务器本身的运行状态的单页概述。

入门

你需要访问 Nagios Core 的 Web 界面。在 QuickStart 安装中，nagiosadmin用户将具备所有必要的权限。

如何操作...

我们可以按如下方式查看战术概览：

登录到 Nagios Core Web 界面。
点击左侧菜单中的战术概览项：

你应该能看到战术监控概览屏幕出现在右侧框架中：
尝试点击主机和服务下的一些项，例如主机下的正常计数。请注意，你会看到该部分所包含的所有主机的列表。
返回战术概览，然后尝试点击监控功能标题下的一些项，例如波动检测下的启用项。请注意，点击这些项会带你到一个可以快速开启或关闭相关功能的屏幕（前提是你的用户具有相应的权限）。

它是如何工作的...

战术概览是你在发现受监控网络出现问题时的第一个重要入口，特别是当你有理由相信问题不仅仅出现在一个主机上时。它也是调整监控功能的好地方。例如，如果网络中有大规模的区域将会停机，而对所有受影响的主机安排停机时间不太实际，那么你可以简单地暂时完全抑制通知，以便在解决问题时不受干扰。

请注意，屏幕的右上角包含了对服务器监控性能的整体评估；如果你怀疑监控服务器无法跟上任务的处理，或者想了解它进行的检查数量，这里是一个非常有用的起始位置。

在其下方是一个简单的条形图，显示网络的总体状态。它会根据问题的严重程度变化颜色；在之前的截图中，网络中部分主机和服务出现了严重问题，因此该条形图较短且为红色。

还有更多内容...

如果你觉得战术概览很有用，可能可以考虑将其设置为 Web 界面的首页，而不是默认的页面，后者主要展示 Nagios Core 的品牌、版本和一些链接。我们可以通过修改/usr/local/nagios/share/index.php文件中$corewindow的值，将其从main.php改为cgi-bin/tac.cgi来实现这一点：

$corewindow=”cgi-bin/tac.cgi”;

完成此操作后，当我们访问监控主机上的/nagios/ URL 时，战术概览应该会立即显示。可以通过菜单中的任何页面来完成此操作。服务项也是一个很好的选择，可以作为备用主页。

另见

本章中的Web 界面中的查看配置教程

查看和解释可用性报告

在本教程中，我们将学习如何使用可用性报告来构建一个表格，显示主机、主机组、服务或服务组的正常运行时间统计信息。这对于快速评估整体可用性非常有用，可能用于满足服务级别协议的条款。

入门

您需要访问 Nagios Core Web 界面，并有权限从 CGI 执行命令。通过遵循快速入门指南安装的示例配置，在通过 HTTP 身份验证时，nagiosadmin 用户将获得所有必要的权限。

如果您发现自己没有此权限，请检查 /usr/local/nagios/etc/cgi.cfg 中的 authorized_for_all_services 和 authorized_for_all_hosts 指令，并将您的用户名包含在其中；例如，对于用户tom，指令可能类似于以下内容：

authorized_for_all_servicess=nagiosadmin,tom
authorized_for_all_hosts=nagiosadmin,tom

另外，如果您使用与您想要检查的主机或服务的指定联系人相同的用户名进行身份验证，您也应该能够看到该主机或服务的信息。有关详细信息，请参见第十章中的使用经过身份验证的联系人教程，安全性和性能。

在这个示例中，我们将查看troy.naginet上的PING服务的一个月历史记录，这是一个 Linux 服务器。

如何操作...

我们可以为我们的troy.naginet服务器安排上个月的可用性报告，具体如下：

登录到 Nagios Core Web 界面。
点击左侧菜单中的可用性链接，位于报告下：如何操作...
选择报告类型，可以是主机(s)、主机组(s)、服务(s) 或 服务组(s)：如何操作...
选择一个特定的主机或服务进行报告，或者选择为所有主机、主机组、服务或服务组运行报告：如何操作...
为报告定义一些选项。默认设置是合理的，所以我们现在使用它们；我们将在下一节中讨论其他字段的影响。完成后点击创建可用性报告！：如何操作...

您应该看到一个表格，显示主机或服务在每个状态中所花费的时间百分比。一个健康的服务可能类似于以下截图，只有少数几次波动，甚至没有：

一个问题较多的服务可能会有大量时间处于WARNING或CRITICAL状态：

表格上方显示了每个状态下所花费时间的快速可视化总结，点击后将链接到具有相同标准的趋势报告。此外，表格下方显示了服务或主机状态变化的任何日志条目。

它是如何工作的...

Nagios Core 从其日志文件中汇总指定时间段内的状态变化，并按百分比构建状态变化表格。因此，可用性报告仅适用于归档日志文件覆盖的时间段。构建报告的第三步涉及许多可能的选项：

报告时间段：此下拉菜单允许选择一个相对于当前日期的固定时间段；或者，可以选择最后的自定义时间段选项，选择接下来两个字段中的日期：
- 开始日期（包含）：此字段指定报告应开始的日期，如果已设置自定义时间段选项。
- 结束日期（包含）：此字段指定报告应结束的日期，如果已设置自定义时间段选项。
报告时间段：这是评估可用性的时间段。默认值为无，这意味着将在任何时间点使用服务或主机的状态进行计算。例如，您可以将其设置为workhours，以查看服务器预期繁忙期间的正常运行时间百分比。
假定状态保持：如果在报告期间 Nagios Core 被重启过一次或多次，选中此选项将使报告假设在任何重启之前的状态被 Nagios Core 保留，直到它重新启动；此选项通过nagios.cfg中的retain_state_information指令启用。
假定初始状态：如果 Nagios Core 无法确定报告开始时服务的初始状态，直到第一次检查时，它将基于首次假定主机状态或首次假定服务状态字段的值来假定状态。
假定程序停机期间的状态：如果 Nagios Core 发现其日志文件中记录了停机时间，它将假定在停机前从主机或服务读取的最终状态。
包含软状态：Nagios Core 将绘制SOFT状态，这意味着它将包括发生的状态变化，但会在max_check_attempts未耗尽之前恢复到其先前的状态。否则，它将只绘制通过重试检查的状态，或HARD状态。
首次假定主机状态或首次假定服务状态：如果 Nagios Core 无法从日志文件中确定主机或服务的状态，则应假定该状态的值。
回溯档案：此字段指定 Nagios Core 进程应检查的已归档日志文件的数量，以尝试查找主机或服务的初始状态。

还有更多...

你还可以选择为主机组或服务组运行报告，这将生成一个索引表，显示每个主机或每个服务的状态时间百分比，以及该组中所有主机或服务的平均正常运行时间。

参见

本章中的查看和解释趋势以及查看和解释通知历史教程
本章中的使用认证联系人教程见第十章，安全与性能

查看和解释趋势

在这个教程中，我们将学习如何使用主机和服务状态趋势报告工具，通过主机或服务显示在一段固定时间内的状态图表。这可以帮助我们不仅确定整体的可用性，或许是为了满足服务级别协议的条款，还能了解是否有特定的时间段或间隔，主机会进入非OK状态。这是查看主机停机模式的一个好方法。

开始

你需要访问 Nagios Core Web 界面，并且有权限从 CGI 运行命令。通过快速入门指南安装的示例配置会在通过HTTP身份验证时，授予nagiosadmin用户所有必要的权限。

如果你发现自己没有这个权限，检查authorized_for_all_services和authorized_for_all_hosts指令在/usr/local/nagios/etc/cgi.cfg中的配置，并在其中添加你的用户名；例如，对于用户tom，指令可能如下所示：

authorized_for_all_services=nagiosadmin,tom
authorized_for_all_hosts=nagiosadmin,tom

另外，如果你使用的用户名与主机或服务的指定联系人相同，你也应该能够查看该主机或服务的信息。

在这个例子中，我们将查看athens.naginet（一个我们正在运行检查的 Web 服务器）上 HTTP 服务的一个月历史。

如何操作...

我们可以为我们的athens.naginet服务器安排一个过去一个月的服务状态趋势报告，如下所示：

登录到 Nagios Core Web 界面。
点击左侧菜单中的趋势链接，位于报告下方：
选择报告类型，主机或服务：
选择你希望报告的特定主机或服务：
定义报告的一些选项。默认设置是合理的，我们暂时使用这些设置；我们将在下一节中详细说明其他字段的作用。完成后点击创建报告：

你应该能看到一张展示主机或服务随时间变化的状态图表，并标明状态变化的时间，以及右侧的状态百分比分布。

一个健康的服务可能看起来像下面的截图，只有一些小的波动，或者根本没有：

更具问题性的服务可能会长时间处于警告或严重状态：

你可以点击图表的某些部分以进行“缩放”，前提是你没有在选择报告选项页面选择禁止图像映射选项。

它是如何工作的...

Nagios Core 从指定时间段的日志文件中汇总状态变化，并通过颜色构建状态变化图，横轴标出日期并按固定间隔划分。因此，趋势图仅适用于存档日志文件所涵盖的时间段。构建报告的第三步涉及许多可能的选项：

报告周期：此下拉菜单允许选择一个固定的周期，方便地与当前日期进行比较；或者，可以通过选择自定义时间周期选项并在接下来的两个字段中选择日期来使用自定义时间周期：
- 开始日期（包含）：此字段指定如果设置了自定义时间周期选项，报告应该开始的日期。
- 结束日期（包含）：此字段指定如果设置了自定义时间周期选项，报告应该结束的日期。
假设状态保留：如果 Nagios Core 在报告周期内重启过一次或多次，勾选此选项将使报告假定在任何重启之前的状态被 Nagios Core 保留，直到它重新启动；此选项通过在 nagios.cfg 中启用 retain_state_information 指令来启用。
假设初始状态：如果 Nagios Core 无法在报告开始到第一次检查时确定服务的初始状态，它将根据首次假定主机状态或首次假定服务状态字段的值进行假设。
假设程序停机期间的状态：如果 Nagios Core 在其日志文件中发现它曾在一段时间内停机，它将假定在停机期间从主机或服务读取的最终状态。
包括软状态：Nagios Core 将绘制软状态，意味着它会包括发生的状态变化，但这些变化会在max_check_attempts未耗尽之前恢复到先前的状态。否则，它只会绘制那些通过重试检查持续存在的状态，或称为硬状态。
首次假定主机状态或首次假定服务状态：这是 Nagios Core 在无法从日志文件中确定主机或服务状态时应假定的值。
回溯存档：此项指定 Nagios Core 进程应回溯多少个存档日志文件，以尝试为主机或服务查找初始状态。
禁止图像映射：这会防止图表被点击以放大特定区域，可能是出于浏览器兼容性原因。
禁止弹出窗口：这会防止图表在悬停时显示弹出窗口，可能是出于浏览器兼容性原因。

还有更多...

请注意，确保在运行报告的整个期间，检查实际上是持续运行的非常重要，否则状态细分部分的统计数据会被扭曲。对于仅存在六个月的主机，运行一年的报告是没有意义的！通常，检查越频繁和一致，趋势图的准确性就越高。

另见

本章中的查看和解释可用性报告 和查看和解释通知历史 配方

查看和解释通知历史

在这个配方中，我们将看到如何获取由 Nagios Core 对主机和服务状态变化生成的警报和通知的完整列表和方便的摘要。这些选项都可以在侧边栏的报告部分下找到：

在本节中区分警报和通知非常重要。警报是响应事件（如主机或服务状态变化）生成的。通知则可能会或不会作为对该警报的响应生成，并发送给相关联系人。SOFT 状态变化构成警报；通常只有 HARD 状态变化才会生成通知。

在生产监控服务器中，可能不会为每个警报发送通知，特别是如果你很好地使用了 max_check_attempts、计划停机和问题确认功能。你应该确保正在检查正确的部分。

入门

你需要访问 Nagios Core 的 web 界面并且拥有从 CGI 执行命令的权限。通过快速入门指南安装的示例配置会在通过 HTTP 身份验证时为 nagiosadmin 用户授予所有必要的权限。

如何操作……

我们可以通过以下方式概览在 Nagios Core 服务器上生成的通知、警报和其他事件：

从通知报告开始。结果页面应该显示当前日志文件中读取的当天通知。
请注意，如果你使用的是 Nagios Core 的日志轮换功能，并且已通过 log_rotation_method 指令进行配置，那么你可以使用表格上方的箭头导航到前一周期的监控（通常为 24 小时）。此外，请注意，信息包含以下内容：
- 生成通知的主机和服务链接
- 这些通知发送到的联系人
- 执行的通知命令
- 触发警报和通知的命令输出
另外，请注意，你可以使用右上角的表单过滤任何特定类型的通知，并更改排序顺序：
接下来，转到警报或警报 | 历史报告。与表格格式不同，这会以列表形式展示由主机和服务生成的所有警报，并使用红色感叹号图标表示CRITICAL或DOWN状态，绿色图标表示OK状态，其他状态则显示不同的图标。该列表按一小时的间隔划分：

请注意，这些警报还包括服务器启动或关闭的情况。还要注意，您可以再次使用右上角表单筛选特定的警报类型。
警报菜单中的另外两个选项允许生成包含多个条件的复杂报告。第一个，摘要，根据表单中输入的条件以表格格式呈现结果。现在，尝试点击第一页底部的创建摘要报告，在所有字段使用默认值的情况下，感受一下它生成的结果：

直方图报告生成类似的内容，展示在固定时间段内为指定主机或服务生成的警报的细分情况：

它是如何工作的……

Nagios Core 会长期保存警报和通知的数据，从而允许动态生成此类报告。请注意，这些报告中展示的数据是警报和通知，而不是服务随时间变化的实际状态。要获得有用的统计信息，如正常运行时间百分比，您将需要生成可用性报告，正如本章中的查看和解释可用性报告方法所讨论的那样。

相同的通知数据还可以通过 NDOUtils 扩展转换为 MySQL 数据库格式，从而使得能够以编程方式读取警报和通知数据，以生成自定义报告。有关如何操作的详细信息，请参见第十一章中的将状态读取到 MySQL 数据库与 NDOUtils方法，自动化和扩展 Nagios章节。

还有更多……

菜单中的剩余项是事件日志，它呈现了 Nagios Core 整体活动的更全面总结，而不仅仅过滤警报或通知。此屏幕可以包括例如外部命令应用等信息。它通常比较冗长，但它是通过 Web 界面读取nagios.log文件的有用方式。要使用此功能，您的用户名需要包含在 /usr/local/nagios/etc/cgi.cfg中的authorized_for_system_information指令中：

authorized_for_system_information=nagiosadmin,tom

另见

本章中的查看和解释可用性报告和查看和解释趋势方法
第十一章中的将状态读取到 MySQL 数据库与 NDOUtils方法，自动化和扩展 Nagios

在 Web 界面中添加主机或服务的评论

在本教程中，我们将学习如何在 Nagios Core 网页界面中向主机或服务添加评论，以便为所有网页界面用户跟踪相关信息。

入门

你需要访问 Nagios Core 网页界面，并且具有从 CGI 运行命令的权限。按照快速入门指南安装的示例配置将为nagiosadmin用户授予所有必要的权限，前提是通过HTTP进行身份验证。你还需要至少一个主机或服务。

如果你发现自己没有此权限，请检查/usr/local/nagios/etc/cgi.cfg中的authorized_for_all_service_commands和authorized_for_all_host_commands指令，并将你的用户名添加到两者中；例如，对于用户tom，指令可能类似于以下内容：

authorized_for_all_service_commands=nagiosadmin,tom
authorized_for_all_host_commands=nagiosadmin,tom

如何操作...

我们可以通过以下方式向主机或服务添加评论：

登录到 Nagios Core 网页界面，点击你希望留下评论的主机名或服务描述。你可以通过主机或服务菜单项进入此页面。在这里，我正在对我的sparta.naginet主机添加评论：
点击页面底部的添加新评论链接：
填写结果表单并包括以下细节：
- 主机名：这是应该添加评论的主机或服务的主机名。此项应自动填写。
- 持久化：如果希望即使在重启 Nagios Core 后评论仍然保留在主机上，请勾选此框。
- 作者（你的名字）：这是确认故障的人的名字。此项应默认为你的名字或用户名；根据/usr/local/nagios/etc/cgi.cfg中lock_author_names的设置，可能会显示为灰色且不可更改。
- 评论：这是评论的具体内容。
请注意，解释性说明也会出现在命令描述的右侧。完成后，点击提交：

完成此操作后，评论应已添加到主机或服务。处理命令可能需要一点时间。你会发现主机或服务的链接菜单中添加了一个图标，并且已添加评论：

工作原理...

与大多数从 Nagios Core 网页界面发出的更改一样，向主机或服务添加评论也是一个发往服务器处理的命令，服务器的主要任务是执行插件和记录状态。这就是为什么即使在空闲服务器上，应用评论有时也需要几秒钟的原因。这些信息会被写入命令文件，默认保存在/usr/local/nagios/var/rw/nagios.cmd，Nagios Core 系统会定期读取该文件。

当命令被执行时，评论将被添加到主机或服务，任何具有适当权限的用户都可以在网页界面中查看。

还有更多...

你可以通过侧边栏中的评论链接查看所有评论的列表：

这将列出所有主机和服务的完整评论，包括自动和手动的评论：

另见

本章中的 通过 web 界面确认问题 实例

在 web 界面中查看配置

在这个实例中，我们将学习如何查看当前为运行中的 Nagios Core 实例配置的所有对象的表格。这是一个非常方便的方式来查看系统如何理解你的配置。如果你使用了很多配置技巧，比如对象继承和主机名模式，这确实可以帮助你理解配置。

一些管理员可能不了解这个功能，因为它隐藏在 Nagios Core web 界面导航菜单的底部。使用起来非常简单，只有两个步骤。

入门

你需要访问 Nagios Core web 界面，并有权限从 CGI 执行命令。按照快速入门指南安装的示例配置，授予了 nagiosadmin 用户通过 HTTP 认证时所需的所有权限。

如果你发现自己没有这个权限，可以检查 /usr/local/nagios/etc/cgi.cfg 中的 authorized_for_configuration_information 指令，并将你的用户名添加进去；例如，对于用户 tom，指令可能如下所示：

authorized_for_configuration_information=nagiosadmin,tom

如何操作...

我们可以在 web 界面中查看不同对象类型的配置，如下所示：

登录到 Nagios Core web 界面，并点击导航菜单中的配置项：
选择你希望查看的对象类型，然后点击继续。在这个例子中，我想查看我定义的所有主机：

你应该会看到一个完整的表格，显示你系统中所有定义主机的指令值。这个表格可能比屏幕宽，因此需要水平滚动。

它是如何工作的...

这只是一个方便的快捷方式，用于查看 Nagios Core 理解的主机配置。以下对象类型可以查看：

主机
主机依赖
主机升级
主机组
服务
服务组
服务依赖
服务升级
联系人
联系人组
时间段
命令
命令扩展

这个快捷方式对于有时可能非常复杂的定义尤其方便，比如从模板继承的主机和服务，或时间段定义。这是一个检查 Nagios Core 是否按照预期解读你配置的好方法。

还有更多...

需要注意的是，输出实际上并没有告诉你主机或服务的状态；它仅显示它们的配置。如果你需要以易于处理的格式获取配置和状态信息，可以使用 NDOUtils 插件，它允许你将这些信息转换为 MySQL 数据库格式。有关如何实现这一点的详细信息，请参阅第十一章中的 将状态读入 MySQL 数据库与 NDOUtils 章节，自动化与扩展 Nagios Core。

参见

第十一章中的 将状态读入 MySQL 数据库与 NDOUtils 和 编写定制的 Nagios Core 报告 章节，自动化与扩展 Nagios Core

从 Web 界面调度检查

在本节中，我们将学习如何通过 Web 界面手动调度主机和服务的检查，覆盖 Nagios Core 通常执行的自动调度。这对于加快刚刚添加的主机或服务的检查，或者解决刚发生问题的主机或服务，或者强制进行检查即使主机上的主动检查因为某些原因被禁用，都非常方便。

在这个例子中，我们将调度一个服务的检查，但主机的检查也可以以相同的方式进行。

入门

你需要访问 Nagios Core Web 界面，并有权限从 CGI 运行命令。按照快速入门指南安装的示例配置会在通过 HTTP 认证后，授予 nagiosadmin 用户所有必要的权限。

如果你发现自己没有这个权限，请检查 /usr/local/nagios/etc/cgi.cfg 中的 authorized_for_all_service_commands 和 authorized_for_all_host_commands 指令，并将你的用户名加入其中；例如，对于用户 tom，这些指令可能看起来像以下这样：

authorized_for_all_service_commands=nagiosadmin,tom
authorized_for_all_host_commands=nagiosadmin,tom

如何操作...

我们可以如下调度一个现有服务的检查：

登录到 Nagios Core Web 界面，找到你想要调度检查的主机或服务的链接。在这个例子中，我们正在强制对 sparta.naginet 主机上的 LOAD 服务进行检查：
点击右侧菜单中的 重新调度此服务的下一次检查 或 重新调度此主机的下一次检查 链接：
完成生成的表单并包括以下细节：
- 主机名：这是出现问题的主机或服务的主机名。此项应该会自动填写。
- 服务：这是出现问题的服务的描述（如果适用）。此项同样会自动填写。
- 检查时间：这是 Nagios Core 应重新调度检查的时间。
- 强制检查：指定是否需要强制执行检查，即使该主机或服务的活动检查已被禁用。
请注意，解释性说明也会显示在命令描述的右侧。完成后点击提交：

完成此操作后，在 Nagios Core 处理新命令后，查看服务时应该会显示下次计划检查的新时间，检查将在指定时间运行，并正常处理返回值。

工作原理...

以这种方式调度检查是一种为特定主机或服务“跳过队列”的方法。检查调度通常是一个自动化过程，Nagios Core 根据主机和服务指令（如check_interval和retry_interval）来决定。

和所有从网络界面发出的外部命令一样，命令会被写入命令文件，通常位于/usr/local/nagios/var/rw/nagios.cmd，由系统处理。

还有更多内容...

我们可以通过点击侧边栏系统部分下的调度队列链接来检查排队的检查任务：

这将显示待处理检查的列表，以及它们将执行的时间：

我们还可以通过使用nagios命令的-s标志来获取有关排队过程和性能的更详细信息：

# /usr/local/nagios/bin/nagios -s /usr/local/nagios/etc/nagios.cfg

这会打印大量信息到终端，太多了，无法在此复述！使用诸如less的分页工具可能会更有帮助，方便阅读：

# /usr/local/nagios/bin/nagios -s /usr/local/nagios/etc/nagios.cfg | less

另见

本章中的查看和解读通知历史教程
第十章中的使用 Nagiostats 检查 Nagios Core 性能教程，安全与性能
第十一章中的允许被动检查和通过 NSCA 从远程主机运行被动检查教程，自动化与扩展 Nagios Core

通过网络界面确认问题

在本篇教程中，我们将学习如何确认主机或服务的问题，以防止收到进一步的通知，并标明问题正在处理中。如果有多个管理员可以访问 Nagios Core 网络界面，这个方法尤其有用，可以避免多个管理员同时尝试解决同一个问题，并防止在操作团队已知问题后仍然收到不必要的长期通知。确认时产生的行为变化会在提交时定义。

入门

要确认一个通知，必须至少有一个主机或服务遇到问题。任何处于WARNING、CRITICAL或UNKNOWN状态的主机或服务都可以进行确认。

您需要访问 Nagios Core 的 Web 界面，并且需要有从 CGI 运行命令的权限。快速启动配置会在通过HTTP认证时授予nagiosadmin用户所有必要的权限。

如果您发现自己没有此权限，请检查/usr/local/nagios/etc/cgi.cfg中的authorized_for_all_service_commands和authorized_for_all_host_commands指令，并将您的用户名添加到两者中；例如，对于用户tom，指令可能如下所示：

authorized_for_all_service_commands=nagiosadmin,tom
authorized_for_all_host_commands=nagiosadmin,tom

如何操作...

我们可以通过以下方式确认主机或服务的问题：

登录到 Nagios Core 的 Web 界面，点击左侧菜单中的主机或服务部分，访问出现问题的主机或服务。在此示例中，我正在确认我机器athens上APT服务的问题；Nagios Core 报告有可用的升级，但它们不是关键性问题，我现在无法执行它们。因此，我将确认这些问题，以便其他管理员知道我已经有解决问题的计划：
点击服务命令菜单下的确认此服务问题链接：
完成生成的表单，并包含以下细节：
- 主机名称：这是出现问题的主机或服务的主机名。此项应自动填写。
- 服务：这是出现问题的服务描述（如果适用）。此项也将自动填写。
- 粘性确认：如果勾选此项，通知将被抑制，直到问题解决；如果 Nagios Core 被重启，确认将不会消失。
- 发送通知：如果勾选此项，ACKNOWLEDGEMENT通知将会发送给所有相关主机或服务的联系人和联系人组。
- 持续评论：确认总是对相关的主机或服务留下评论。默认情况下，这些评论会在主机或服务恢复时被移除，但如果您愿意，您可以勾选此项以安排让它们变为永久评论。
- 作者（您的姓名）：这是确认故障的人的名字。此项应默认填写您的姓名或用户名；根据/usr/local/nagios/etc/cgi.cfg中的lock_author_names值，它可能是灰色并且不可更改。
- 评论：这是确认的说明；通常这是一个放置预期解决时间以及正在做什么以解决问题的好地方。
请注意，解释性说明也会出现在命令描述的右侧。完成后，点击提交：

完成此操作后，您选择的停机效果应该很快生效。处理命令可能需要一点时间。您会发现，主机或服务链接的菜单中添加了一个确认图标，且已经添加了评论：

你的联系人可能还会收到一个确认通知：

它是如何工作的...

像大多数通过 Nagios Core Web 界面发出的更改一样，确认主机或服务是一条命令，由服务器处理，除了执行插件和记录状态这一主要任务外。这就是为什么即使在空闲的服务器上，应用此操作有时也需要几秒钟时间的原因。所有这些操作都会写入命令文件，该文件默认存储在/usr/local/nagios/var/rw/nagios.cmd路径下。只要在/usr/local/nagios/etc/nagios.cfg中启用了外部命令处理，Nagios Core 系统会定期读取此文件。

当命令被执行并且选择了固定确认选项时，其效果是，Nagios Core 通常应用的过滤器会注意到主机或服务在发送通知之前已经确认了问题，因此会阻止通知的发送。

当主机恢复（恢复事件）时，会发送相应的通知，并且确认会被移除，因为它不再需要。即使主机或服务出现的再次是完全相同的问题，未来的任何问题仍然需要重新确认。

还有更多...

确认主机和服务问题对于管理员来说是一个非常好的习惯，尤其是当在团队中工作时，因为这可以避免很多混乱或重复的工作。因此，它与评论一样有帮助，有助于让你的团队了解网络的最新状况。

计划停机和确认之间的区别非常重要。停机时间是为了主机或服务的计划性停机而设置的；确认则是用于通知一个未预见的问题已经发生，并且正在处理中的手段。

如果我们不断收到已经知道的问题的通知，并且已经使用了确认功能，那么可能需要审查适用主机或服务的notification_interval指令，以限制通知发送的频率。例如，如果我们只希望每四小时发送一次重复通知，可以编写以下代码片段：

define host {
    ...
    notification_interval  240
}

例如，对于低优先级的主机，可能并不需要每 10 分钟发送一次通知！

不要将此指令与notification_period混淆，notification_period用于定义可发送通知的时间段，另一个可能需要审查的指令：

define host {
    ...
    notification_period  24x7
}

另见

本章中的在 Web 界面上为主机或服务添加评论示例
第三章中的为主机或服务安排停机时间示例，工作与检查和状态

第八章：管理网络布局

本章将涵盖以下内容：

创建网络主机层次结构
使用网络地图
为主机选择图标
建立主机依赖关系
建立服务依赖关系
监控集群中的独立节点
将网络地图用作覆盖层

介绍

虽然当 Nagios Core 配置为仅监控简单的主机和服务列表时仍然非常有用，但它包括一些可选指令，允许定义监控网络的一些结构和功能属性；特别是，主机和服务如何相互关联。通过在配置中描述这种结构，可以在监控和通知中实现 Nagios Core 的一些附加智能行为。

在 Nagios Core 中处理网络结构的主要方法有两种：

主机父级定义允许管理员从 Nagios Core 服务器的“视角”定义监控主机的连接层次结构。例如，可能有一台位于另一个子网中的服务器，它通过路由器与 Nagios Core 服务器相连。如果路由器进入 DOWN 状态，它会触发 Nagios Core 的主机可达性逻辑，自动确定哪些主机变得无法访问，并将这些主机标记为 UNREACHABLE 而非 DOWN，从而实现更细致的通知行为。
主机和服务依赖关系允许在主机或服务之间建立关系，通常是为了抑制不必要的通知。例如，可能有一个服务用来测试登录邮件服务，而该服务本身需要一个数据库服务才能正常工作。如果 Nagios Core 发现数据库服务和登录服务都出现故障，服务依赖关系可以抑制有关登录服务的通知；因此，管理员只会收到关于数据库服务故障的通知，这更可能是实际的问题所在。

这里的功能有一些重叠，但一般的模式是，主机父级定义描述了从监控服务器的视角来看网络的结构，而主机和服务依赖关系描述了它如何运作，与监控服务器无关。我们将在本章中定义父级定义和依赖关系，主要目标是过滤并改进 Nagios Core 在检测失败时发送的通知，这将极大地帮助诊断问题。

我们还将探讨在建立主机父级定义时的另一个更微妙的好处，即如何使 Nagios Core 网络接口的网络地图变得有用，一旦设置了基本的层次结构，我们将展示如何自定义地图的外观（包括为主机定义图标），使其通常作为网络天气图变得有用。

创建网络主机层次结构

在这个教程中，我们将学习如何在一个非常简单的网络中为两台主机建立父子关系，以便利用 Nagios Core 的可达性逻辑。更改此配置非常简单；只需要添加一个指令，并可选地更改一些通知选项。

准备就绪

你需要运行 Nagios Core 3.0 或更新版本的服务器，并且至少有两台主机，其中一台只能通过另一台主机访问。允许与其他主机通信的主机是父主机。你应该相当有信心，如果与父主机的连接丢失，意味着子主机无法从监控服务器访问。

访问 Nagios Core 的 Web 界面也很有用，因为做出这个更改会改变网络地图的显示，这部分内容在本章的使用网络地图教程中有所讨论。

我们的示例将使用一台 Nagios Core 监控服务器olympus.naginet，监控三台主机：

calpe.naginet，一台路由器
janus.naginet，另一台路由器
corsica.naginet，一台 Web 服务器

主机按照以下图示连接：

请注意，Nagios Core 服务器olympus.naginet只能在路由器calpe.naginet正常工作的情况下与corsica.naginet Web 服务器通信。如果calpe.naginet进入DOWN状态，我们也会看到corsica.naginet进入DOWN状态：

这有点误导，因为我们并不知道corsica.naginet是否宕机。它可能宕机，但由于主机间的路由器未正确工作，Nagios Core 无法得知。对于该主机，更准确的状态应该是UNREACHABLE；这就是我们接下来要添加的配置所安排的状态。

如何操作...

我们可以按以下方式为我们的两台主机配置父子关系：

更改到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，请进入该目录。
```
# cd /usr/local/nagios/etc/objects
```
编辑包含子主机定义的文件。在我们的示例中，子主机是corsica.naginet，即 Web 服务器。主机定义可能类似于以下代码片段：
```
define host {
    use        linux-server
    host_name  corsica.naginet
    alias      corsica
    address    10.128.0.71
}
```
在主机定义中添加新的parents指令，并为其设置与其依赖的连接主机的host_name指令相同的值。在我们的示例中，这台主机是calpe.naginet。
```
define host {
    use        linux-server
    host_name  corsica.naginet
    alias      corsica
    address    10.128.0.71
 parents    calpe.naginet
}
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，如果父主机进入DOWN状态且无法联系到子主机，则子主机将进入UNREACHABLE状态，而不是被标记为DOWN：

只要在主机的notification_options和联系人的host_notification_options中包含u标志，子主机的联系人也会收到UNREACHABLE通知，而不是子主机的DOWN通知。有关详细信息，请参见第四章中的指定要通知的状态一节，配置通知部分。

它是如何工作的...

这是 Nagios Core 可达性逻辑的一个简单应用。当对calpe.naginet的检查第一次失败时，Nagios Core 会注意到它是一个父主机，拥有一个子主机corsica.naginet。如果在检查子主机时发现无法与其通信，它会标记为UNREACHABLE状态，而不是DOWN状态，触发一个不同的通知事件。

这种方式的主要优点有两个：

DOWN通知仅发送给最近出现问题的父主机。所有超出该主机的其他主机会触发UNREACHABLE通知。这意味着 Nagios Core 的可达性逻辑会自动确定从它的角度看失败的节点，这在诊断实际出现问题的主机时非常有用。
如果主机是大量其他主机的父主机，可以通过配置来避免为UNREACHABLE主机发送紧急通知。当一个非常核心的路由器宕机时，向管理员发送一百个电话或电子邮件通知可能没有太大意义；他们已经知道下游主机出现了问题，因此我们只是在用无用的信息分散他们的注意力。

通过一些规划和对网络的了解，我们只需在主机定义中添加几个parents指令，就能构建一个简单的网络结构，结果是 Nagios Core 会表现得更加智能。这是改进 Nagios Core 通知行为的最简单方法之一，值得强烈推荐！

还有更多内容...

请注意，一个子主机本身可以成为其他主机的父主机，从而允许形成嵌套的网络结构。也许在另一种情况下，我们会发现corsica.naginet服务器距离监控服务器有两个路由器之远：

在这种情况下，不仅corsica.naginet是calpe.naginet的子主机，而且calpe.naginet本身也是janus.naginet的子主机。我们可以以完全相同的方式指定这种关系：

define host {
    use        linux-router
    host_name  calpe.naginet
    alias      calpe
    address    10.128.0.129
 parents    janus.naginet
}

还可以为主机设置多个父主机，如果有两条可能的路径通向同一台机器：

define host {
    use        linux-server
    host_name  corsica.naginet
    alias      corsica
    address    10.128.0.71
 parents    calpe.naginet,janus.naginet
}

在此配置下，只有当corsica.naginet的两个父主机都宕机时，corsica.naginet才会被认为是UNREACHABLE。这种配置有助于考虑网络中的冗余路径；应用场景可能包括生成树技术或动态路由故障切换。

在您使用 parents 指令为您的网络设置了良好的基本结构之后，务必查看本章中的 使用网络地图 方案，以便从新的配置中获得有关网络结构的自动可视化反馈。

另见

本章中的 使用网络地图 和 建立主机依赖关系 方案
第四章中的 指定需要通知的状态 和 配置通知组 方案，配置通知

使用网络地图

在本方案中，我们将在 Nagios Core Web 界面中检查网络地图（或状态图）中的网络层次结构。网络地图以生成的图形形式展示主机层次结构及其当前状态。您可以在本章中的 创建网络主机层次结构 方案中学习如何建立这样的层次结构。网络地图允许过滤以显示特定主机，并可以点击主机以在更大的网络中导航。

准备工作

您需要运行 Nagios Core 3.0 或更新版本的服务器，并且可以访问其 Web 界面。您还需要查看主机状态的权限，最好是所有主机。您可以通过将您的用户名添加到 authorized_for_all_hosts 指令中来安排此权限，通常该指令位于 /usr/local/nagios/etc/cgi.cfg 中；例如，对于用户 tom，我们可能会将该指令配置为如下：

authorized_for_all_hosts=nagiosadmin,tom

默认情况下，nagiosadmin 用户应该具有查看完整地图所需的所有权限。

如果您的主机尚未配置至少一些 parents 指令并按层次结构排列，那么网络地图就不会特别有用。因此，如果您尚未为主机设置任何 parents 指令，您可能希望首先阅读本章中的 创建网络主机层次结构 方案，并按其说明安排您的监控主机。

操作步骤...

我们可以按如下方式检查我们新配置的主机层次结构的网络地图：

登录到 Nagios Core Web 界面。
点击左侧菜单中的地图项：

您应该看到一个生成的图形，显示您的用户有权限查看的所有网络主机：
将鼠标悬停在任何主机上，即可看到一个面板，分解主机的当前状态：
默认情况下，网络地图围绕 Nagios 进程图标居中。尝试点击您的某个主机以重新居中地图；在此示例中，它已经重新居中在 calpe.naginet 上：

它是如何工作的...

网络地图是从您的主机配置中自动生成的。默认情况下，它将主机排列在扇区中，从中央的 Nagios 进程图标向外辐射，使用线条显示依赖关系，并将背景颜色调整为绿色表示 UP 状态，红色表示 DOWN 或 UNREACHABLE 状态。

这张地图是通过GD2 库生成的，该库由 Thomas Boutell 编写。它采用链接图像地图的形式。这意味着您可以简单地右击图像保存它，在网络处于特定状态时以便稍后参考，并且还可以点击单个节点以将地图重新集中在指定主机上。这对于具有大量主机和许多父/子主机关系层级的网络特别有用。

还有更多...

请注意，右上角面板中的表单允许直接定制地图的外观：

布局方法：这允许您选择用于排列和绘制主机的算法。值得尝试这些方法中的每一种，以查看哪一种最适合您特定的网络布局。
缩放因子：在此更改值以减少或增加地图图像的大小；0.0到1.0之间的值将减小图像的大小，而大于1.0的值将增大它。
绘制图层：如果您的主机已组织成主机组，您可以筛选地图，仅显示属于特定组的主机。
图层模式：如果您在绘制图层选项中选择了任何主机组，这允许您选择是否将这些组中的主机包含在地图中，或将它们排除在外。
抑制弹出窗口：如果您觉得当将鼠标悬停在主机上时出现的黄色信息弹出窗口很烦人，您可以通过勾选此复选框来关闭它们。

选择或更改任何这些选项后，您需要点击更新才能应用它们。

通过更改 Nagios Core 配置文件中的指令，并向主机添加一些指令，状态地图的外观可以配置得远远超过此内容；请查看本教程中另见部分下的示例，了解如何实现此功能。

另见

本章节中的自定义网络地图外观、选择主机图标、指定主机在网络地图中的坐标和使用网络地图作为叠加层教程

选择主机图标

在本教程中，我们将学习如何为主机选择图形，并在 Nagios Core 的 Web 界面中的不同部分显示它们。这是通过向主机添加指令来指定适当的图像路径，以代表该主机。

添加这些定义不会影响 Nagios Core 的监控行为；它们主要是外观上的变化，尽管在网络地图上，快速查看某个节点是服务器还是工作站仍然很有用。

准备工作

您需要运行 Nagios Core 3.0 或更高版本的服务器，并能够访问其 Web 界面。您还必须能够编辑服务器的配置文件。

最好检查一下你是否确实安装了所需的图像。默认的图标集包含在 /usr/local/nagios/share/images/logos 中。不要与其父目录 images 混淆，后者包含的是作为 Nagios Core Web 界面一部分的图像。

在 logos 目录中，你应该能找到多个不同格式的图像。在这个示例中，我们关心的是 router 和 rack-server 图标：

$ ls /usr/local/nagios/share/images/logos/{router,rack-server}.*
/usr/local/nagios/share/images/logos/rack-server.gd2
/usr/local/nagios/share/images/logos/rack-server.gif
/usr/local/nagios/share/images/logos/router.gd2
/usr/local/nagios/share/images/logos/router.gif

为了充分利用这些图标，你可能希望熟悉使用网络图，并可以访问你自己 Nagios Core 实例中的相应主机。网络图将在本章的 使用网络图 这一小节中介绍。

如何操作...

我们可以定义要用于显示主机的图像如下：

切换到 Nagios Core 的 objects 配置目录。默认路径是 /usr/local/nagios/etc/objects。如果你把主机定义放在了不同的文件中，请转到该目录。
```
# cd /usr/local/nagios/etc/objects
```

向每个你想应用图标的主机添加三个新指令。在此示例中，rack-server 图标分配给 corsica.naginet，而 router 图标分配给 calpe.naginet 和 corsica.naginet：

define host {
    use              linux-server
    host_name        corsica.naginet
	alias            corsica
	address          10.128.0.71
 icon_image       rack-server.gif
 icon_image_alt   Rack Server
 statusmap_image  rack-server.gd2
}
define host {
    use              linux-router
    host_name        janus.naginet
    alias            janus
	address          10.128.0.128
 icon_image       router.gif
 icon_image_alt   Router
 statusmap_image  router.gd2
}
define host {
    use              linux-router
    host_name        calpe.naginet
    alias            calpe
	address          10.128.0.129
 icon_image       router.gif
 icon_image_alt   Router
 statusmap_image  router.gd2
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，访问状态图应该显示带有图标的主机，而不是问号：

主机列表还应包括图像的缩小版：

它是如何工作的...

当生成主机列表、服务列表或网络状态图时，它会检查每个主机对象中是否存在 icon_image 或 statusmap_image 值，如果定义了，则读取相应的图像，并将其作为处理的一部分。网络状态图默认仅在缺少 statusmap_image 指令的值时显示问号。

请注意，对于 statusmap_image 指令，我们选择了图标的 .gd2 版本，而不是 .gif 版本。这是出于性能考虑；状态图是通过 GD2 库生成的，它能够更高效地处理本地的 .gd2 格式。

icon_image_alt 指令定义了在 <img> HTML 标签中显示图像时 alt 属性的值。大多数浏览器在鼠标悬停在图标上时会简要显示该标签的内容。

Nagios Core 3.0 允许你将这些指令放在一个单独的 hostextinfo 对象中，但该对象类型在 Nagios Core 4.0 中已被正式弃用，因此建议避免使用它。

还有更多

如果你有多个主机需要共享相同的镜像，最佳做法是从一个公共的主机模板继承，并设置适当的指令。对于我们的示例，我们可以定义一个模板如下：

define host {
    name             router-icon
    icon_image       router.gif
    icon_image_alt   Router
    statusmap_image  router.gd2
    register         0
}

然后，我们可以通过从该模板继承并将其添加到use指令中，直接应用图像设置到我们的两个路由器：

define host {
 use        linux-router,router-icon
    host_name  janus.naginet
    alias      janus
    address    10.128.0.128
}
define host {
 use        linux-router,router-icon
    host_name  calpe.naginet
    alias      calpe
    address    10.128.0.129
}

如果你不喜欢附带的图标集，可以在 Nagios Exchange 网站上找到许多图标集，exchange.nagios.org/。如果你愿意，你甚至可以使用物理硬件的图片制作自己的图标，保存为标准的 PNG 或 GD2 格式。

另见

本章中的使用网络地图和指定网络地图上主机的坐标食谱

建立主机依赖关系

在这个食谱中，我们将学习如何在两个主机之间建立主机依赖关系。这个功能可以用来控制 Nagios Core 如何检查主机，并在某些情况下，如果一个主机处于DOWN状态，意味着至少有一个其他主机也必定处于DOWN状态时通知我们出现问题。

准备工作

首先，非常重要的一点是，值得注意的是，这与主机处于UNREACHABLE状态并不完全相同，parents指令正是为此目的而设计的，正如本章中的创建网络主机层次结构食谱所讨论的那样。大多数情况下，主机处于DOWN状态并不意味着其他主机会因此处于DOWN状态。通常，子主机会处于UNREACHABLE状态；它可能正常工作，但由于路径中的DOWN主机，Nagios Core 无法检查它。

然而，有一个特别广泛的领域，主机依赖关系肯定是有用的：虚拟机的主机/客户机关系。如果你同时监控一台物理主机和一台或多台客户机虚拟机，那么这些虚拟机肯定依赖于主机；如果主机机器处于DOWN状态且没有冗余故障切换，那么这意味着客户机也处于DOWN状态，而不仅仅是UNREACHABLE。

我们将以虚拟化为例，在主机ephesus.naginet上运行两台虚拟机zeus.naginet和athena.naginet。这三台机器已经在监控中，但我们将建立主机依赖关系，这样如果 Nagios Core 判断主机处于DOWN状态，它就不会通知任何人关于虚拟机的状态。

你需要一个 Nagios Core 3.0 或更新版本的服务器，并具有更改其后端配置的 Shell 访问权限。

如何操作...

我们可以按照以下方式建立主机依赖关系：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在其他文件中，则请转到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```
创建或编辑一个适当的文件，该文件将被配置文件/usr/local/nagios/etc/nagios.cfg包含。一个合理的选择是/usr/local/nagios/etc/objects/dependencies.cfg：
```
# vi dependencies.cfg
```

添加一个hostdependency定义。在我们的例子中，定义类似于以下代码片段。请注意，你可以通过用逗号分隔主机名来包含多个依赖主机：

define hostdependency {
    host_name                      ephesus.naginet
    dependent_host_name            zeus.naginet,athena.naginet
    execution_failure_criteria     n
    notification_failure_criteria  d,u
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这一设置后，如果ephesus.naginet主机宕机并使zeus.naginet和athena.naginet主机也一同宕机，那么对这三台主机的检查将继续进行，但对两台依赖主机的通知将被抑制。

它是如何工作的...

主机依赖对象的四个指令如下：

host_name：这是至少有其他一个主机依赖于它的主机名称。我们将其称为依赖主机。这个名称也可以是以逗号分隔的主机名称列表。
dependent_host_name：这是依赖主机的名称。同样，这也可以是以逗号分隔的列表。
execution_failure_criteria：定义依赖主机的状态列表。如果该主机处于这些状态中的任何一个，Nagios Core 将跳过对依赖主机的检查。这可以是以下任何标志的逗号分隔列表：
- o：依赖主机是开启
- d：依赖主机是关闭
- u：依赖主机是无法访问。
- p：依赖主机是待定（尚未检查）
另外，也可以使用单一标志n（如本例中所示），指定无论依赖主机的状态如何，都应进行检查。
notification_failure_criteria：定义依赖主机的状态列表。如果该主机处于这些状态中的任何一个，那么将不会发送对依赖主机的通知。标志与execution_failure_criteria相同；在本例中，我们选择如果依赖主机处于关闭或无法访问状态时抑制通知。

当 Nagios Core 发现zeus.naginet或athena.naginet主机因主机检查失败而显得关闭时，它会参考其配置检查该主机是否有依赖项，发现它们依赖于ephesus.naginet。

它接着检查ephesus.naginet的状态，发现它是关闭状态。参考execution_failure_criteria指令并找到n，它继续对两个依赖主机执行检查，状态为正常。但是，参考notification_failure_criteria指令并找到d,u，它决定在主机恢复到开启状态之前抑制通知。

还有更多...

我们可以使用hostgroup_name和dependent_hostgroup_name指令指定主机组，而不是主机名称来处理依赖关系：

define hostdependency {
 hostgroup_name                 vm-hosts
 dependent_hostgroup_name       vm-guests
    execution_failure_criteria     n
    notification_failure_criteria  d,u
}

我们还可以提供以逗号分隔的依赖主机列表：

define hostdependency {
 host_name            ephesus.naginet,alexandria.naginet
    dependent_host_name  zeus.naginet,athena.naginet    
    execution_failure_criteria     n
    notification_failure_criteria  d,u
}

如果一个主机依赖于多个主机，则只有当其任何一个依赖项没有满足时，检查或通知规则才会生效，而不是所有依赖项都未满足时。以之前的例子为例，这意味着如果ephesus.naginet处于关闭状态，而alexandria.naginet处于开启状态，那么依赖关系仍然会抑制所有依赖主机的检查或通知。

这意味着在冗余场景中，主机依赖关系并不真正适用，因为丢失一个被依赖的主机并不意味着丢失其所有依赖的主机。你可能会发现将节点作为集群进行监控更适合这种情况；这在本章的作为集群监控单独节点食谱中有讨论。

另请参见

本章中的建立服务依赖关系、创建网络主机层次结构和作为集群监控单独节点食谱

建立服务依赖关系

在本教程中，我们将学习如何在两个服务之间建立服务依赖关系。这个功能可以用来控制 Nagios Core 如何检查服务，并在一种服务处于PROBLEM状态时通知我们，意味着至少另一个服务也必然处于PROBLEM状态。

准备就绪

你需要一台 Nagios Core 3.0 或更新版本的服务器，并具有 shell 访问权限以更改其后端配置。你还需要至少定义两个服务，其中一个服务依赖于另一个；这意味着如果被依赖的服务进入CRITICAL状态，那么它将意味着被依赖的服务也会是CRITICAL。

我们将使用一个简单的示例：假设我们正在测试对邮件服务器marathon.naginet的身份验证，服务为MAIL_LOGIN，同时在同一主机上检查一个数据库服务MAIL_DB，它存储登录用户名和密码哈希值。

在这种情况下，如果MAIL_DB无法正常工作，MAIL_LOGIN几乎肯定也无法正常工作。如果是这样，我们可以配置 Nagios Core，使其知道MAIL_LOGIN服务依赖于MAIL_DB服务。

如何操作...

我们可以如下建立服务依赖关系：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，请转到该目录。
```
# cd /usr/local/nagios/etc/objects
```
创建或编辑一个适当的文件，该文件将被/usr/local/nagios/etc/nagios.cfg中的配置包含。一个合理的选择可能是/usr/local/nagios/etc/objects/dependencies.cfg：
```
# vi dependencies.cfg
```

添加一个servicedependency定义。在我们的例子中，定义类似于以下代码片段：

define servicedependency {
    host_name                      marathon.naginet
    service_description            MAIL_DB
    dependent_host_name            marathon.naginet
	dependent_service_description  MAIL_LOGIN
    execution_failure_criteria     c
    notification_failure_criteria  c
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此设置后，如果MAIL_DB服务因任何原因失败并进入CRITICAL状态，MAIL_LOGIN服务将跳过对该服务的检查，也会跳过它通常会发送的任何关于其自身问题的通知（如果有的话）。请注意，Web 界面可能仍显示 Nagios Core 正在调度检查，但实际上不会执行这些检查。

它是如何工作的...

服务依赖对象的五个指令如下：

host_name：这是与这些服务关联的主机名称。我们将其称为依赖主机。
service_description：这是被依赖服务的描述，可以是逗号分隔的列表。我们将其称为依赖服务。
dependent_service_description：这是依赖服务的描述，也可以是逗号分隔的列表。
execution_failure_criteria：定义了依赖服务的状态列表。如果该服务处于这些状态之一，Nagios Core 将跳过对依赖服务的检查。它可以是逗号分隔的以下标志的列表：
o：依赖服务处于 OK 状态
- w：依赖服务处于 WARNING 状态
- c：依赖服务处于 CRITICAL 状态（如本示例所示）
- u：依赖服务处于 UNKNOWN 状态
- p：依赖服务处于 PENDING 状态（尚未检查）
另外，可以使用单个标志 n 来指定无论依赖服务的状态如何，都应进行检查。在本示例中，我们选择了 c 值，仅在依赖服务处于 CRITICAL 状态时才抑制服务检查。
notification_failure_criteria：定义了依赖服务的状态列表。如果该服务处于这些状态之一，则不会发送有关依赖服务的通知。标志与 execution_failure_criteria 相同；在本示例中，我们再次选择了 c 值，仅当依赖服务处于 CRITICAL 状态时才抑制通知。

当 Nagios Core 检测到 MAIL_DB 服务因服务检查失败而进入 CRITICAL 状态时，它会查阅其配置，检查该服务是否有任何依赖关系，并发现它依赖于 MAIL_LOGIN 服务。

然后它检查 MAIL_DB 的状态，发现其处于 CRITICAL 状态。查阅 execution_failure_criteria 指令并发现 c，它会阻止对两个依赖服务的检查。查阅 notification_failure_criteria 指令并发现 c，它也决定在服务恢复到其他状态之前抑制通知。

还有更多内容...

请注意，服务不需要在同一主机上才能相互依赖。我们可以添加 dependent_host_name 或 dependent_hostgroup_name 指令来指定其他主机：

define servicedependency {
 host_name                      marathon.naginet
    service_description            MAIL_DB
 dependent_host_name            sparta.naginet
    dependent_service_description  WEBMAIL_LOGIN
    execution_failure_criteria     c
    notification_failure_criteria  c
}

在此示例中，sparta.naginet 上的 WEBMAIL_LOGIN 服务被定义为依赖于 marathon.naginet 上的 MAIL_DB 服务。请注意，host_name 和 dependent_host_name 的值是不同的。

在 Nagios Core 3.3.1 之前的版本中，即使 dependent_host_name 和 host_name 相同，依然需要定义 dependent_host_name 指令。

另见

本章中的建立主机依赖关系和将单独的节点作为集群进行监控的示例

监控集群中的单独节点

在这个示例中，我们将学习如何使用标准 Nagios 插件中的check_cluster插件监控集群中的主机。能够集体监控多个主机在冗余环境下非常有用；如果某一台主机处于DOWN状态，可能是为了节省能源或进行维护，这不一定需要通知。然而，如果更多的主机或所有主机都宕机，我们就确实需要被通知。使用check_cluster可以实现这一点。

准备工作

你需要一个 Nagios Core 3.0 或更新版本的服务器，并且需要有 Shell 访问权限以更改其后端配置。你还需要至少有两个被监控的主机，并且它们在冗余设置中执行某些功能，比如数据库复制、DNS 服务器或负载均衡的 Web 服务器。

你还应熟悉如何定义主机和服务，特别是如何定义命令；这些概念在第一章，理解主机、服务和联系人中有讨论。

在这个示例中，我们将使用三台刀片服务器，它们的主机名分别是achilles.naginet、odysseus.naginet和agamemnon.naginet，这些服务器在冗余集群中运行，以支持虚拟主机环境。所有三台主机已经在监控中，如果其中一台发生故障，将发送电子邮件通知。我们将安排一个check_cluster服务在“虚拟主机”上，以便：

如果没有刀片服务器宕机，服务为OK。
如果其中一台刀片服务器宕机，服务进入WARNING状态，并再次适当通知我们。
如果两台或三台刀片服务器都宕机，服务进入CRITICAL状态，再次适当通知我们。

如何操作……

我们可以按照如下方式为我们的主机安排集群检查：

切换到 Nagios Core 的objects配置目录。默认路径是/usr/local/nagios/etc/objects。如果你将主机定义放在了其他文件中，则切换到该文件所在的目录。
```
# cd /usr/local/nagios/etc/objects
```
创建或编辑一个适当的文件来定义新命令。一个合理的选择可能是/usr/local/nagios/etc/objects/commands.cfg。

在此文件中定义两个新命令，check_dummy和check_host_cluster：

define command {
    command_name  check_dummy
    command_line  $USER1$/check_dummy $ARG1$ $ARG2$
}
define command {
    command_name  check_host_cluster
    command_line  $USER1$/check_cluster -h -d $ARG1$ -w $ARG2$ -c $ARG3$
}

创建或编辑一个适当的文件，该文件将被/usr/local/nagios/etc/nagios.cfg配置文件包含。一个合理的选择可能是/usr/local/nagios/etc/objects/clusters.cfg。

为集群定义一个虚拟主机，使用以下值：

define host {
    use                 generic-host
    host_name           naginet-blade-cluster
    alias               Naginet Blade Cluster
    address             127.0.0.1
    max_check_attempts  1
    contact_groups      admins
    check_command       check_dummy!0!"Dummy host only"
}

请注意，address指令的值为127.0.0.1；这是故意设置的，因为虚拟主机本身并不需要被主动检查或发送任何通知。

为虚拟主机添加一个服务：

define service {
    use                   generic-service
    host_name             naginet-blade-cluster
    service_description   CLUSTER
 check_command         check_host_cluster!$HOSTSTATEID:achilles.naginet$,$HOSTSTATEID:odysseus.naginet$,$HOSTSTATEID:agamemnon.naginet$!@1:!@2:
    notification_options  c,w,r
}

从generic-service继承的建议仅仅是一个示例；你可能希望使用自己的模板或值。请注意，check_command的值是单行的，并且没有空格。你应该替换为你自己机器的主机名。

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成后，naginet-blade-cluster虚拟主机上的CLUSTER服务应该可以查看。如果集群中的主机上线或宕机，它将像任何其他服务一样更改状态并发送通知：

它是如何工作的…

本配方中添加的主机仅仅是CLUSTER服务的一个“钩子”，实际的检查由该服务执行。这就是为什么我们使用一个通过check_dummy插件返回OK状态的命令：

# /usr/local/nagios/libexec/check_dummy 0 "Dummy host only"
OK: Dummy host only

check_cluster命令实际上非常简单。它不会执行实际的检查。相反，它基于其他主机或服务的当前状态来确定状态。

这就是为什么在服务的check_command指令中使用 $HOSTSTATEID:hostname$ 宏；它会计算出一个数字，表示主机的状态，并在冒号后指定主机名。

例如，如果achilles.naginet和odysseus.naginet处于UP状态，但agamemnon.naginet处于DOWN状态，那么 Nagios Core 运行的检查命令在宏展开后将类似于以下代码片段：

/usr/local/nagios/libexec/check_cluster -h -d 0,0,1 -w @1: -c @2:

我们可以作为nagios用户自己运行此命令以检查输出：

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_cluster -h -d 0,0,1 -w @1: -c @2:
CLUSTER WARNING: Service cluster: 2 ok, 1 warning, 0 unknown, 0 critical

在插件的-d选项中给出的以逗号分隔的状态对应于两个主机处于UP状态（状态 ID 为0），一个主机处于DOWN状态（状态 ID 为1）。-w选项的值@1:意味着如果一个或多个主机处于宕机状态，则会进入WARNING状态。同样，-c选项的值@2:意味着如果两个或更多主机宕机，则会进入CRITICAL状态。

这使您可以根据DOWN状态的主机数量自定义通知，而不仅仅是单独监控各个主机。一旦您确信此配置正常工作，您甚至可以选择阻止单个主机向您的寻呼机发送通知，而让CLUSTER服务来代替。

还有更多…

如果您需要监控的是一组服务而非主机，可以通过使用check_cluster的-s选项来完成，而不是使用-h选项。在这种情况下，您将使用 $SERVICESTATEID:<host_name>:<service_description>$ 宏，而不是 $HOSTSTATEID:<host_name>$ 宏。一个示例配置可能看起来像以下代码片段，适用于一个由两台 Web 服务器sparta.naginet和athens.naginet组成的集群，并给一个名为naginet-http-cluster的虚拟主机：

define command {
    command_name  check_service_cluster
 command_line  $USER1$/check_cluster -s -d $ARG1$ -w $ARG2$ -c $ARG3$
} 
define service {
    use                  generic-service
	host_name            naginet-http-cluster
	service_description  CLUSTER_HTTP
 check_command       check_service_cluster!$SERVICESTATEID:sparta.naginet:HTTP$,$SERVICESTATEID:athens.naginet:HTTP$!@1:!@2:
}

另见

本章中的建立主机依赖关系配方

使用网络地图作为覆盖层

在本配方中，我们将学习如何使用网络地图的背景，并故意将主机放置在地图的特定位置，制作一种网络状态天气图，以便在地理上下文中一目了然地查看主机状态。

准备开始

你需要一个 Nagios Core 3.0 或更高版本的服务器，并且需要有 shell 访问权限以更改其后端配置。你还应该至少配置几个主机用于在地图上显示，并了解如何使用 Nagios 网络地图和主机图标。这些内容在本章的 使用网络地图 和 为主机选择图标 章节中有讨论。

你还应该选择一个背景图像，在其上可以有意义地放置主机。如果你正在监控一个办公室网络，背景图像可以是建筑物或服务器机房的平面图。如果你在监控一个全国性的互联网服务提供商，则可以使用你所在州或国家的地图。有些管理员甚至喜欢使用物理设备的照片，并将 Nagios Core 主机放置在它们的物理类比上。在本示例中，我们将使用一张澳大利亚地图，大小为 640 x 509 像素，这是一张来自自然地球网站的公共领域图像：

背景图像可以是任何你喜欢的内容，并且可以使用包括 PNG 在内的多种图形格式。然而，为了快速渲染地图，建议使用 GD2 文件格式的图像，扩展名为 .gd2。如果你拥有 PNG 格式的图像，可以使用免费的工具pngtogd2将其转换为 GD2 图像：

$ pngtogd2 australia.png australia.gd2 0 1

该工具可以在基于 Debian 的系统上通过 libgd-tools 软件包获得。其源代码也可以在 www.libgd.org/ 在线访问。

如何操作...

我们可以按如下方式设置网络地图的背景：

将你的 GD2 格式图像复制到 physical_html_path 目录下的 images 子目录中。在默认安装中，该目录为 /usr/local/nagios/share/images；如果有所不同，你可以在 /usr/local/nagios/etc/cgi.cfg 中找到 physical_html_path 的定义。
```
# cp /home/tom/australia.gd2 /usr/local/nagios/share/images
```
切换到 Nagios Core 的配置目录。在默认安装中，该目录为 /usr/local/nagios/etc。编辑文件 cgi.cfg。
```
# cd /usr/local/nagios/etc
# vi cgi.cfg
```
在此文件中查找指令statusmap_background_image。取消注释并将其值设置为你的图像名称：
```
statusmap_background_image=australia.gd2
```
在同一文件中查找指令default_statusmap_layout。将其更改为0，对应于用户自定义坐标布局。
```
default_statusmap_layout=0
```

切换到 Nagios Core 的 objects 配置目录。在默认安装中，该目录为/usr/local/nagios/etc/objects。向你希望在地图上显示的每个主机添加2d_coords指令。你可能还希望在此处包括statusmap_image的定义，方法如下：

# vi australia.cfg
define host {
    use              linux-server
    host_name        adelaide.naginet
	address          10.128.0.140
    2d_coords        390,360
 statusmap_image  rack-server.gd2
}
define host {
    use              linux-server
    host_name        cairns.naginet
    address          10.128.0.141
    2d_coords        495,100
 statusmap_image  rack-server.gd2
}
... etc ...

对于指令2d_coords，提供两个逗号分隔的值，描述主机放置的坐标。例如，adelaide.naginet距离左侧 390 像素，距离顶部 360 像素。获取坐标的便捷方法是使用 GIMP，这是一个开源的图像工具，或者甚至可以使用简单的工具如 MS Paint；加载图像并悬停在希望使用的点上，以查找其像素坐标。

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这些步骤后，通过在 Nagios Core Web 界面左侧菜单上点击地图，访问网络地图，您的主机将放置在其相应的位置上，包括用于指定子父关系和可达性的正常线条和颜色：

工作原理...

指令default_statusmap_layout默认将网络地图固定为用户提供的坐标模式。在此模式下，仅显示具有2d_coords值的主机，并且它们显示在地图上的固定点，而不是动态放置。

如果需要，我们可以在没有背景的情况下使用此显示模式，但是通过使用实际背景图像，我们可以为生成的网络图片提供大量有用的背景信息。

请注意，如果没有定义坐标的主机，您将收到类似以下截图的错误：

还有更多...

在带有图像背景的网络地图中，可以特别帮助快速查看单个主机的状态，但是在多个主机故障的情况下，还可以寻找可能的地理原因。如果城市或国家的某一部分的所有节点同时宕机，我们可以一目了然地看到这一点。这使得网络地图成为网络监控显示的绝佳选择，或者在诊断大规模问题时的首选。

以这种方式，网络地图非常有用，从图形上讲，它可能是 Nagios Core Web 界面中最令人印象深刻的部分。如果您希望获得更多选项和更广泛的主机状态可视化，您可能希望考虑查看出色的NagVis扩展，它本身可能填写整本书。在第十一章的使用 NagVis 获得额外的可视化食谱中简要介绍了其用法。

另见

本章节中的创建网络主机层次结构、使用网络地图和为主机选择图标食谱
第十一章的使用 NagVis 获得额外的可视化食谱，自动化和扩展 Nagios

第九章：配置管理

本章中，我们将覆盖以下配方：

将配置文件分组到目录中
保持配置在版本控制下
使用组配置主机角色
使用正则表达式构建组
使用继承简化配置
在资源文件中定义宏
动态构建主机定义

介绍

Nagios Core 配置灵活性的一个主要缺点是，如果没有适当的管理，配置很容易膨胀成成百上千个文件，包含数千个对象，且所有对象之间的依赖关系不明确。当尝试对配置进行重大更改时，或者即使只是像删除主机这样简单的操作时，这种情况会令人沮丧，因为你需要筛选出依赖关系，找出导致配置错误并阻止你重新启动 Nagios Core 的原因。

因此，仔细构建配置非常重要，尽可能多地使用抽象，以便能够轻松地添加、更改和删除主机和服务定义，并避免配置的重复。Nagios Core 提供了几种方法来处理此问题，最显著的就是明智地使用组和模板来管理基本对象。还应避免重复网络特定的和易变的数据，例如密码；最好的做法是使用在资源文件中定义的自定义宏来处理。

本章的配方将展示一些大规模网络配置的最佳实践。最重要的配方是前两个，将配置文件分组到目录中和使用组配置主机角色。如果你希望理顺并重构一个杂乱的配置，那么这两个配方是最好的起点。

本章的最后一个配方，动态构建主机定义，将展示整洁配置的主要优势之一，即能够根据保存在其他外部信息源中的主机和服务列表，轻松生成配置，如配置管理数据库（CMDB）。

将配置文件分组到目录中

在这个配方中，我们将学习如何将配置文件分组到目录中，以极大地简化配置的管理。我们将通过配置 Nagios Core 加载给定目录中所有以.cfg扩展名结尾的文件，包括递归遍历子目录来实现。最终结果是，要让 Nagios Core 加载一个文件，我们只需要在该目录中包含它，并使用适当的扩展名；我们不需要在nagios.cfg中精确指定加载了哪些文件。

准备工作

你需要一台运行 Nagios Core 3.0 或更高版本的服务器，并且需要有命令行权限来修改其配置。你应该熟悉使用cfg_file指令在/usr/local/nagios/etc/nagios.cfg中加载单独的配置文件。

特别是，你应该准备一个目录，包含你希望被 Nagios Core 加载的所有配置文件。在这个例子中，我们将准备一个名为/usr/local/nagios/etc/naginet的新目录，它将包含三个配置文件，每个文件定义一个主机的信息：

# ls -1 /usr/local/nagios/etc/naginet
athens.cfg
ithaca.cfg
sparta.cfg

你需要确保目录、文件和其中的子目录对nagios用户是可读的（尽管不一定是该用户拥有的）。

如何执行...

我们可以按以下方式安排 Nagios Core 包含目录中的所有文件：

切换到包含nagios.cfg文件的目录。在默认安装中，它位于/usr/local/nagios/etc/nagios.cfg。
```
# vi nagios.cfg
```
编辑文件，并在任何其他cfg_file或cfg_dir指令下面，添加以下一行，指向包含.cfg文件的目录的绝对路径：
```
cfg_dir=/usr/local/nagios/etc/naginet
```
请注意，此指令是cfg_dir，而不是cfg_file。
删除指向新目录中.cfg文件的任何cfg_file定义。这样可以防止加载相同的对象两次。在我们的例子中，我们需要注释掉之前加载这些文件的规则：
```
#cfg_file=/usr/local/nagios/etc/naginet/sparta.cfg
#cfg_file=/usr/local/nagios/etc/naginet/athens.cfg
#cfg_file=/usr/local/nagios/etc/naginet/ithaca.cfg
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 应该已加载naginet目录或其任何子目录中找到的所有.cfg扩展名的文件，从而省去我们单独指定它们的麻烦。

它是如何工作的...

在加载时，Nagios Core 解释cfg_dir指令的意思是它应该识别特定目录中所有的.cfg文件，包括递归遍历其子目录。它会忽略没有该扩展名的文件，允许我们包括元数据或其他文件类型（例如版本控制信息目录），而不会引起问题。

结果是，定义一个新主机或服务变得像将文件添加到合适的包含目录一样简单，无需编辑nagios.cfg。

还有更多...

需要注意的是，此指令也会包含子目录中的所有.cfg文件。这可能允许我们对配置文件进行有意义的分组：

$ find /usr/local/nagios/etc/naginet
/usr/local/nagios/etc/naginet
/usr/local/nagios/etc/naginet/hosts
/usr/local/nagios/etc/naginet/hosts/athens.cfg
/usr/local/nagios/etc/naginet/hosts/sparta.cfg
/usr/local/nagios/etc/naginet/hosts/ithaca.cfg
/usr/local/nagios/etc/naginet/commands
/usr/local/nagios/etc/naginet/commands/webserver-checks.cfg
/usr/local/nagios/etc/naginet/services
/usr/local/nagios/etc/naginet/services/webservers.cfg

对于大型网络，值得为目录决定一个合适的组织原则。一种常见的方法是为主机、服务和命令定义分别创建独立的目录，这些目录与特定的域名系统（DNS）区域或较大子网相关。

如果你想防止某个文件在任何时候被包含，你只需要将其移出目录，或者将其重命名，使其不再具有.cfg扩展名。一个可能的做法是添加后缀.exclude：

# mv unwanted-file.cfg unwanted-file.cfg.exclude

这将防止 Nagios Core 将其作为cfg_dir搜索算法的一部分加载。

另见

本章中的使用继承简化配置和将配置保留在版本控制下的实例

将配置保留在版本控制下

在本教程中，我们将把 Nagios Core 配置目录置于版本控制之下，目的是跟踪对其所做的更改，并使我们能够在出现问题时撤销更改。

准备工作

你应该选择一个合适的版本控制系统。根据你选择的系统，具体步骤会有所不同；这里无法演示所有的选项，因此我们将使用流行的开源内容管理工具Git，它非常适合进行这种类型的版本控制，并且不需要外部服务器。不过，如果你更喜欢使用Subversion或Mercurial也是完全可以的。你需要在服务器上安装所选系统的客户端（如git、hg、svn等）。

这将适用于任何版本的 Nagios Core。它不涉及直接更改任何 Nagios Core 配置的部分，仅仅是跟踪其中的文件。

如何操作...

我们可以按如下方式将配置目录放入版本控制：

切换到配置目录的根目录。在默认安装中，该目录为/usr/local/nagios/etc：
```
# cd /usr/local/nagios/etc
```

运行git init以在当前目录中初始化一个仓库：

# git init
Initialized empty Git repository in /usr/local/nagios/etc/.git/.

使用git add将配置目录中的所有文件添加到版本控制中：
```
# git add .
```

使用git commit提交文件：

# git commit -m "First commit of configuration"
[master (root-commit) 6a2c605] First commit of configuration.
 39 files changed, 3339 insertions(+), 0 deletions(-)
 create mode 100644 naginet/athens.naginet.cfg
 create mode 100644 naginet/ithaca.naginet.cfg
 create mode 100644 naginet/sparta.naginet.cfg
 ...

完成后，我们应该在/usr/local/nagios/etc下拥有一个.git仓库，跟踪所有对配置文件的更改。

它是如何工作的...

现在可以使用git status查看对该目录中配置文件的更改。例如，如果我们更改了其中一个主机的 IP 地址，我们可以通过输入以下命令来检查更改：

# git status -s
M naginet/hosts/sparta.cfg

然后我们可以提交这个更改并附上说明信息：

# git commit -am "Changed IP address of host"
[master d5116a6] Changed IP address of host
1 files changed, 1 insertions(+), 1 deletions(-)

我们可以使用git log查看更改记录：

# git log --oneline
d5116a6 Changed IP address of host
6a2c605 First commit of configuration

如果我们稍后想检查到底做了哪些更改，可以使用git diff，后跟前一输出中的第一列短提交 ID：

# git diff 6a2c605
diff --git a/naginet/hosts/sparta.cfg b/naginet/hosts/sparta.cfg
index 0bb3b0b..fb7c2a9 100644
--- a/naginet/hosts/sparta.cfg
+++ b/naginet/hosts/sparta.cfg
@@ -2,7 +2,7 @@ define host {
 use                 linux-server
 host_name           sparta.naginet
 alias               sparta
-    address             10.128.0.101
+    address             10.128.0.102
}

Git 的完整功能，包括回退到旧版本，并不在本教程的范围内。你可以通过 Scott Chacon 的精彩著作《Pro Git》了解更多关于如何使用 Git 的内容，该书可以在git-scm.com/book免费在线阅读。

还有更多...

版本控制在多人编辑配置时特别有用，因为它能帮助我们确定是谁在什么时候做了更改。它还允许我们查看确切的变更集，审查为什么会做出这些更改，并在发生问题时撤销或修改这些更改。

如果你打算使用此方法，最好保持配置的适当粒度，使用多个文件而不是仅使用一两个文件。即使你只有两个大文件，如hosts.cfg和services.cfg，它也能正常工作，但每次提交之间的差异就不那么清晰了。因此，这是一个与本章中的将配置文件分组到目录中教程结合使用的非常好的做法。

与其仅仅将配置目录纳入版本控制，你可能更愿意将整个 Nagios Core 目录都纳入版本控制，包括插件和其他脚本与二进制文件。如果你在安装中升级到新版本并希望查看文件中发生了哪些更改，以防止出现问题，这样做会特别有用。在这种情况下，请小心使用你所选择的版本控制系统的“忽略”功能，以防止跟踪临时文件或日志文件。对于 Git，可以查看git help ignore的输出。

另见

使用组配置主机角色

在本教程中，我们将学习如何利用主机和服务组的抽象化，以便构建一个配置，使得主机和服务能够更轻松地添加或移除。我们将通过使用主机组结构为主机定义角色，然后将相关服务分配给主机组，而不是单独分配给各个主机。

准备工作

你需要一台运行 Nagios Core 3.0 或更高版本的服务器，能够访问命令行以更改其目录，并理解主机和服务组的基本工作原理。这些内容可以在第一章中的创建新主机组和创建新服务组教程中找到。

在这个例子中，我们将创建两个简单的主机组：一个叫做servers，它的成员主机应进行PING检查，另一个叫做webservers，它的成员主机应进行HTTP检查。一旦完成设置，我们将向两个组中添加一个示例主机sparta.naginet，从而将所有适当的服务在一个定义中轻松分配给该主机，我们可以通过删除主机来干净地移除它。

如何做到这一点…

我们可以如下创建基于组的主机角色：

切换到objects配置目录。在默认安装中，该目录为/usr/local/nagios/etc/objects。如果你已经按照本章中的将配置文件分组到目录中这一教程操作，那么你的目录可能会有所不同。
```
# cd /usr/local/nagios/etc/objects
```

在一个适当的文件中，也许是hostgroups.cfg，定义新主机组，名称应与主机的角色相对应。暂时不要为它们分配任何成员。

define hostgroup {
    hostgroup_name  servers
    alias           Servers
}
define hostgroup {
    hostgroup_name  web-servers
    alias           Web Servers
}

在另一个适当的文件中，也许是services.cfg，定义新服务并为它们分配hostgroup_name值，值应与上一步骤中添加的主机组相对应：

define service {
    use                  generic-service
 hostgroup_name       servers
    service_description  PING
    check_command        check_ping!100,10%!200,20%
}
define service {
    use                  generic-service
 hostgroup_name       web-servers
    service_description  HTTP
    check_command        check_http
}

请注意，generic-service 模板的使用仅是一个示例；你可能更希望从你自己特定的服务模板中继承。

使用 hostgroups 指令，添加或编辑现有主机，使其成为适当主机组的一部分：

define host {
    use         linux-server
    host_name   sparta.naginet
    alias       sparta
    address     10.128.0.21
 hostgroups  servers,web-servers
}
define host {
    use         linux-server
    host_name   athens.naginet
    alias       athens
    address     10.128.0.22
 hostgroups  servers,web-servers
}

如果你已经有与此配方中添加的服务相同的 service_description 指令的服务，你需要删除它们，因为这可能会与前一步添加的服务发生冲突。

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这一步后，你应该会发现你为所创建的主机组定义的所有服务都已附加到相应的主机上：

它是如何工作的...

前面部分添加的配置避免了直接将服务分配给主机，而是将它们分配给主机组，从而为服务创建了角色，主机可以通过成为组的一部分或离开该组来采纳或丢弃这些角色。

除了使配置更简洁之外，这种方法的另一个优点是，如果以这种方式添加服务，添加或删除 Nagios Core 配置中的主机只需要添加或删除主机定义。类似地，如果主机承担了其他角色（例如，一个 web 服务器添加了数据库功能），我们只需通过修改其主机组来修改其检查的服务。这比在其他文件中添加依赖关系要容易得多。

另一个优点是，通过主机功能组织主机组有助于进行批量操作，比如在一个简单的操作中安排计划的停机时间，或者检查某种特定类型主机的所有服务。一旦定义了主机组，我们可以通过点击其名称，在任何主机组视图中对其中的所有主机执行操作：

例如，如果我们有二十台即将停机的 web 服务器，这比为每台服务器单独安排停机时间要容易得多！

还有更多内容...

值得注意的是，主机组可以有子组，这意味着添加到任何子组中的所有主机都会隐式地添加到父组中。

例如，我们可以使用 hostgroup_members 指令，将 web 服务器定义为 servers 主机组的子组：

define hostgroup {
    hostgroup_name     servers
    alias              Servers
 hostgroup_members  web-servers
}

这将允许我们隐式地将主机添加到两个组中，而无需引用父组，并且将所有分配给这两个组的服务也分配给主机：

define host {
    use         linux-server
    host_name   athens.naginet
    alias       athens
    address     10.128.0.22
 hostgroups  web-servers
}

这对于排序“子类别”服务非常有用。其他示例可能包括一个 dns-servers 组，带有子组 dns-authoritative-servers 和 dns-recursive-servers，或者一个 database-servers 组，带有子组 oracle-servers 和 mysql-servers。

另见

本章中的 使用正则表达式构建组 和 利用继承简化配置 配方
在第一章中的创建新主机组、创建新服务组和在主机组中的所有主机上运行服务的食谱中，了解主机、服务和联系人

使用正则表达式构建主机组

在本食谱中，我们将学习如何使用正则表达式快速构建主机组，通过与主机名进行匹配来实现。

如果你的主机采用了命名规范，允许根据位置、功能或其他有用的标准通过主机名中的公共字符串合理分组，那么这个食谱可能会对你有用。

准备工作

你需要有一台运行 Nagios Core 3.0 或更高版本的服务器，能够访问命令行以更改其配置，并理解主机组和服务组的基本原理。这些内容在第一章中的创建新主机组和创建新服务组食谱中有涉及。

在这个示例中，我们将把三个已有的主机web-server-01、web-server-02和web-server-03仅通过它们的主机名分组到一个新的主机组web-servers中。

对正则表达式有一定了解会有所帮助，但本食谱包括了一个简单的示例，应该能满足许多使用场景。关于正则表达式的一个优秀网站，包括教程，可以参考www.regular-expressions.info/。

如何操作...

我们可以通过将正则表达式与主机名匹配来构建主机组，如下所示：

切换到 Nagios 配置目录。在默认安装中，该目录是/usr/local/nagios/etc。编辑该目录中的nagios.cfg文件。
```
# cd /usr/local/nagios/etc
# vi nagios.cfg
```
搜索use_regexp_matching指令。如有必要，取消注释该指令并设置为1。
```
use_regexp_matching=1
```
搜索use_true_regexp_matching指令。如有必要，取消注释该指令，并确保它设置为0，默认情况下应该是这样。
```
use_true_regexp_matching=0
```
切换到objects配置目录。在默认安装中，该目录是/usr/local/nagios/etc/objects。如果你已经按照本章中的将配置文件分组到目录中的食谱操作过，则你的目录可能有所不同。
```
# cd /usr/local/nagios/etc/objects
```
在适当的文件中，可能是hostgroups.cfg，添加类似以下的定义。在此例中，.+表示“任何长度至少为一个字符的字符串”；你可能需要根据自己的主机名设计一个合适的模式。
```
define hostgroup {
    hostgroup_name  web-servers
 members         web-server-.+
    alias           Web Servers
}
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，如果你的正则表达式正确匹配了所有适当的主机名，那么你应该发现这些主机已经成为该组的一部分：

工作原理...

当use_regexp_matching指令设置为1时，Nagios Core 将尝试将包含 *、?、+ 或 \. 的主机名字符串作为正则表达式来匹配主机名。因为 web-server-01、web-server-02 和 web-server-03 都匹配在 web-servers 主机组的 members 指令中给出的正则表达式 web-server-.+，所以这三个主机都被添加到该组中。

我们将use_true_regexp_matching关闭。如果它开启，它将把每个主机名模式都当作正则表达式来匹配，不管其中是否包含特殊的正则表达式字符。对于大多数配置，这显然不是你想要的。

还有更多...

这种匹配不仅适用于主机组定义；例如，你也可以在服务的 host_name 定义中使用它：

define service {
    use                  generic-service
 host_name            web-server-.+
    service_description  HTTP
    check_command        check_http
}

这是 Nagios Core 手册中为简化对象定义提出的一些非常好的建议之一：nagios.sourceforge.net/docs/3_0/objecttricks.html。

另请参见

本章中的使用正则表达式构建组和利用继承简化配置教程
第一章中的创建新主机组和创建新服务组教程，理解主机、服务和联系人

使用继承简化配置

在这个教程中，我们将学习如何使用继承来处理主机和服务共享大量相同值的情况，从而避免配置中的冗余。

一些 Nagios Core 对象，特别是主机和服务，有一个相当长的可能指令列表，这些指令的默认值并不总是合适的。因此，能够声明你想要的指令值，并通过从模板复制这些值，仅用几行代码定义实际主机，会使配置变得更加简洁、易读。

本书中的前面示例已经演示了如何通过继承 linux-server 主机模板或 generic-service 服务模板来简化配置，为了简洁起见；在这个例子中，我们将定义自己的模板，并展示如何使用这些模板来简化配置。

准备工作

你需要运行 Nagios Core 3.0 或更高版本的服务器，能够访问命令行来更改配置，并且熟悉如何定义主机和服务。这些内容在第一章的创建新主机和创建新服务教程中有介绍。

在这个示例中，我们将定义一个模板 critical-host，作为任何需要全天候检查和通知的主机的基础，设置一个非常严格的 check_command 指令，并启用所有通知类型。我们还将定义两个名为 phobos.naginet 和 deimos.naginet 的主机，它们继承自这个模板。

如何操作...

我们可以定义一个主机模板，然后定义主机从中继承，如下所示：

切换到 objects 配置目录。在默认安装中，这个目录是 /usr/local/nagios/etc/objects。如果你已经按照本章中的 按目录分组配置文件 配方进行操作，那么你的目录可能有所不同。
```
# cd /usr/local/nagios/etc/objects
```

在一个合适的文件中，可能是 templates.cfg，添加以下定义。注意使用了特殊的指令 name 和 register：

define host {
 name                   critical-host
 register               0
    check_command          check_ping!25,10%!50,20%
    max_check_attempts     3
    check_interval         1
    notification_interval  1
    notification_period    24x7
    notification_options   d,u,r,f,s
    check_period           24x7
    contact_groups         admins
}

在另一个文件中，或者如果你更喜欢每个文件只包含一个主机，可以定义从这个模板继承的主机。添加其余所需的主机指令，并包含一个 use 指令，引用已建立的模板：

define host {
 use        critical-host
    host_name  phobos.naginet
    alias      phobos
    address    10.128.0.151
}
define host {
 use        critical-host
    host_name  deimos.naginet
    alias      deimos
    address    10.128.0.152
}

验证配置并重启 Nagios Core 服务器：
```
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart
```
你可能会收到关于主机没有定义服务的警告，但现在可以忽略这些警告。

完成此步骤后，应该有两个新主机被注册到你的配置中，phobos.naginet 和 deimos.naginet：

不应添加其他新主机，因为模板本身显式未作为对象通过 register 指令注册。

它是如何工作的...

前面章节中添加的配置定义了一个新的模板，name 指令为 critical-host。由于主机的 register 指令的值为 0，而通常默认为 1，所以该主机并未作为对象注册到 Nagios Core 中。相反，它变成了一个配置片段，可以通过引用其名称，供相同类型的真实对象使用。

请注意，在模板中，通常需要的 host_name、alias 和 address 值缺失；这意味着该主机是不完整的，如果我们尝试将其注册为实际主机，它将无法工作。

相反，我们使用它的值作为其他主机的基础，phobos.naginet 和 deimos.naginet。这两个主机都继承自 critical-host，并在自己的定义中补充其余缺失的值。这使得我们无需在两个不同的主机中重复相同的指令。

如果一个对象从其父对象继承了某个指令的值，可以通过在继承对象定义中重新定义该指令来覆盖它。例如，如果我们希望 phobos.naginet 的 max_check_attempts 值不同，我们可以在其定义中添加：

define host {
    use                 critical-host
    host_name           deimos.naginet
    alias               deimos
    address             10.128.0.152
 max_check_attempts  5
}

还有更多...

模板最重要的注意事项是它们适用于各种 Nagios Core 对象，最重要的包括主机、服务和联系人。因此，你可以以相同的方式设置并继承一个服务模板：

define service {
    name      critical-service
    register  0
    ...etc...
}
define service {
    use       critical-service
    ...etc...
}

或者是联系人模板：

define contact {
    name      critical-contact
    register  0
    ...etc...
}
define contact {
    use       critical-contact
    ...etc...
}

请注意，继承是可以堆叠的。例如，critical-host 可以通过添加自己的 use 指令来继承自模板，可能是 generic-host：

define host {
 use       generic-host
    name      critical-host
    register  0
    ...etc...
}

这允许设置一个任意复杂度的继承结构，但你应避免过多的深度，以免自己或其他人阅读配置时感到困惑。两级深度可能是一个合适的限制。

关于继承处理的规则在 Nagios Core 手册中有更详细的讨论，包括多重继承的处理。了解这些规则是有用的，但为了保持配置清晰，最好谨慎使用： nagios.sourceforge.net/docs/3_0/objectinheritance.html。

另见

本章中的 使用组配置主机角色 配方
第一章中的 创建新主机、创建新服务 和 创建新联系人 配方，理解主机、服务和联系人

在资源文件中定义宏

在本节中，我们将学习如何在资源文件中定义自定义用户宏。这是用于 check_command 定义或其他由多个主机或服务共享的指令中的字符串的良好实践。例如，代替在 command_name 指令中写出完整路径，如下所示：

command_name=/usr/local/nagios/libexec/check_ssh $HOSTADDRESS$

我们也可以改为写成：

command_name=$USER1$/check_ssh $HOSTADDRESS$

结果是，如果 check_ssh 脚本的位置发生变化，我们只需要在适当的资源文件中更改 $USER1$ 的值，以更新配置中所有的引用。

Nagios Core 中的大多数宏是由监控服务器自动定义的，但最多可以使用 32 个用户定义的宏，形式为 $USERn$ 。

准备工作

你需要运行 Nagios Core 3.0 或更高版本的服务器，并且需要有命令行访问权限以更改其配置，特别是 resource.cfg 文件。

在这个示例中，我们将添加一个新的宏， $USER2$ ，用于包含 SNMP 社区名 snagmp，如在各种 check_snmp 请求中使用的那样。

如何操作…

我们可以按如下方式定义我们的用户宏：

切换到 Nagios 配置目录。在默认安装中，该目录为 /usr/local/nagios/etc。编辑该目录中的 resource.cfg 文件。
```
# cd /usr/local/nagios/etc
# vi resource.cfg
```
确保 $USER2$ 宏尚未在文件中定义。如果已经定义，我们可以改为定义 $USER3$ ，依此类推。
将以下定义添加到文件末尾：
```
$USER2$=snagmp
```
切换到 Nagios Core 的 objects 配置目录。在默认安装中，该目录为 /usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```

编辑你希望使用宏值的任何object配置文件，并将内联值替换为 $USER2$ 。在我们的示例中，我们可能会发现多个地方使用了字面值checksnmp社区字符串：

define command {
    ...
    command_line  $USER1$/check_snmp -H $HOSTADDRESS$ -C snagmp -o .1.3.6.1.2.1.1.5.0 -r $ARG1$
}
define service {
    ...
    check_command  check_snmp!snagmp
}

我们可以将这些替换为使用宏：

define command {
    ...
 command_line  $USER1$/check_snmp -H $HOSTADDRESS$ -C $USER2$ -o .1.3.6.1.2.1.1.5.0 -r $ARG1$
}
define service {
    ...
 check_command  check_snmp!$USER2$
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，所有监控应与之前相同，但我们现在使用宏展开来集中配置。

它是如何工作的...

在 Nagios Core 处理像command_line和check_command这样的指令之前，它会首先展开所有引用的宏，包括我们在resource.cfg资源文件中添加的用户定义宏。

$USERn$ 宏的一个常见用途是定义 Nagios Core 资源（如插件或事件处理脚本）所在目录的完整路径——事实上，Nagios Core 中包含的示例配置将resource.cfg中的 $USER1$ 定义为/usr/local/nagios/libexec，这是插件脚本和二进制文件的默认位置。

值得注意的是，你可以通过在/usr/local/nagios/etc/nagios.cfg中添加更多的resource_file指令来加载多个资源文件。例如，要加载另一个名为resource-extra.cfg的文件，我们可以添加第二行，如下所示：

resource_file=/usr/local/nagios/etc/resource.cfg
resource_file=/usr/local/nagios/etc/resource-extra.cfg

还有更多内容...

使用资源文件还有安全性上的好处——对于敏感信息，我们可以通过将其设置为仅对nagios用户可读，来防止其他用户读取它们：

# cd /usr/local/nagios/etc
# chown nagios.nagios resource.cfg
# chmod 0600 resource.cfg

这使得它成为存储凭据的一个不错方式，例如用户名和密码，用于在check_command中对 MySQL 进行验证：

define command {
    command_name  check_mysql_secure
 command_line  check_mysql -H $HOSTADDRESS$ -u naguser -d nagdb -p $USER3$
}

你还可以通过在主机定义中使用以下划线开头的自定义指令来定义每个主机的宏：

define host {
    use                 critical-host
    host_name           sparta.naginet
    alias               sparta
    address             10.128.0.21
 _mac_address        08:00:27:7e:7c:d2
}

在前面的示例中，我们能够在自定义指令中包含主机的 MAC 地址；这可以在服务中引用为 $_HOSTMAC_ADDRESS$ ：

define service {
    use                  generic-service
    host_name            sparta.naginet
    service_description  ARP
    check_command        check_arp!$_HOSTMAC_ADDRESS$
}

同样的技巧也可以应用于联系人和服务。这种自定义宏的特殊用法在 Nagios 文档的自定义对象变量章节中有讨论，地址是nagios.sourceforge.net/docs/3_0/cu。

另请参见

第五章中的监控 SNMP 查询输出配方，监控方法
第八章中的集群中单个节点的监控配方，理解网络布局

动态构建主机定义

在本配方中，我们将学习构建 Nagios 配置的一个可能方法，以避免为新主机或服务编写或复制大量指令。换句话说，本配方是关于使用模板生成配置的。

为了演示这个工具的用途，我们将使用 m4 宏语言工具，它应该在几乎所有类 UNIX 系统上都可用，包括 GNU/Linux 和 BSD。作为一个设计用于宏展开的工具，m4 特别适合创建冗长的纯文本配置文件，如 Nagios Core 使用的文件。

这里的原则同样适用于你偏好的编程语言或模板语言，可能是 Python 或 Perl，或是 shell 脚本。

准备就绪

你需要确保你有 m4 宏语言工具，最好但不一定是与运行 Nagios Core 的系统相同的系统。它是一个非常标准的工具，应该已经安装，或者作为包的一部分提供。这个例子使用的版本是 GNU m4，文档请参见 www.gnu.org/software/m4/manual/m4.html。这个示例不假定你对 m4 有任何了解，它将向你展示基础知识。

你可能希望在你的主目录中创建一个新的子目录：

$ mkdir $HOME/nagios-dynamic-hosts
$ cd $HOME/nagios-dynamic-hosts

如何操作...

我们可以按照以下方式创建并应用一个示例 Nagios Core 配置模板：

创建一个新的文件 host-service-template.m4，内容如下：

define(`NAGHOST', `
    define host {
        host_name              $1
        alias                  $2
        address                $3
        contact_groups         ifelse(`$#', `4', `$4', `admins')
        check_command          check-host-alive
        check_interval         5
        check_period           24x7
        max_check_attempts     3
        notification_interval  30
        notification_options   d,r
        notification_period    24x7
    }
    define service {
        host_name              $1
        contact_groups         ifelse(`$#', `4', `$4', `admins')
        check_command          check_ping!100,10%!200,20%
        check_interval         5
        check_period           24x7
        max_check_attempts     3
        notification_interval  30
        notification_period    24x7
        retry_interval         1
        service_description    PING
    }
')

在相同目录中创建一个名为 sparta.host.m4 的第二个文件，内容如下：

include(`host-service-template.m4')
NAGHOST(`sparta', `Sparta Webserver', `10.0.128.21')

在相同目录中创建一个名为 athens.host.m4 的第三个文件，内容如下：

include(`host-service-template.m4')
NAGHOST(`athens', `Athens Webserver', `10.0.128.22', `ops')

运行以下命令并记录输出：

$ m4 sparta.host.m4
define host {
 host_name              sparta
 alias                  Sparta Webserver
 address                10.0.128.21
 contact_groups         admins
 check_command          check-host-alive
 check_interval         5
 check_period           24x7
 max_check_attempts     3
 notification_interval  30
 notification_options   d,r
 notification_period    24x7
}
define service {
 host_name              sparta
 contact_groups         admins
 check_command          check_ping!100,10%!200,20%
 check_interval         5
 check_period           24x7
 max_check_attempts     3
 notification_interval  30
 notification_period    24x7
 retry_interval         1
 service_description    PING
}
$ m4 athens.host.m4
define host {
 host_name              athens
 alias                  Athens Webserver
 address                10.0.128.22
 contact_groups         ops
 check_command          check-host-alive
 check_interval         5
 check_period           24x7
 max_check_attempts     3
 notification_interval  30
 notification_options   d,r
 notification_period    24x7
}
define service {
 host_name              athens
 contact_groups         ops
 check_command          check_ping!100,10%!200,20%
 check_interval         5
 check_period           24x7
 max_check_attempts     3
 notification_interval  30
 notification_period    24x7
 retry_interval         1
 service_description    PING
}

如前面的输出所示，我们现在可以使用一个两行的 m4 脚本，引用一个模板，通过简单地将输出写入 .cfg 文件来生成一个基本的主机和服务配置：

$ m4 sparta.host.m4 > sparta.cfg

它是如何工作的...

文件 sparta.host.m4 和 athens.host.m4 都调用了一个带有参数的 m4 宏，在包含了主机和服务模板的 host-service-template.m4 文件后。这些被展开为完整的定义，并按以下方式替换了给定的参数：

$1 被替换为第一个参数，host_name
$2 被替换为第二个参数，alias
$3 被替换为第三个参数，address
$4 被替换为第四个参数，contact_group

请注意，这两个值，$1 和 $4，在主机和 PING 服务定义中都有使用。

同样注意，参数 $4 是可选的；if-else 结构会测试参数的数量，如果发现有四个参数，则使用第四个参数的值；对于 athens.naginet，这是联系组 ops。如果没有第四个参数，则默认使用 admins 的值。这允许我们在需要时为参数设置默认值。

其余的指令都直接写入模板中。通过这个过程生成的配置对于 Nagios Core 是有效的，前提是所使用的 check_command 和 contact_groups 已定义。

还有更多...

为了进一步自动化，我们可以使用make命令根据以下Makefile，自动生成所有扩展名为.host.m4的.cfg文件：

%.cfg : %.host.m4
    m4 $< > $*.cfg

请注意，正确的Makefile语法通常需要使用一个实际的Tab字符来缩进第二行，而不是四个空格。

将所有前述文件与此文件放在同一目录下，为了构建sparta.naginet主机的配置，我们只需要使用make命令来生成文件：

$ make sparta.cfg
m4 sparta.host.m4 > sparta.cfg
$ make athens.cfg
m4 athens.host.m4 > athens.cfg

请注意，最好避免重复指令，而是使用主机组、主机和服务模板来为新主机定义“角色”。这样可以更轻松地添加和删除主机，这两个过程将在本章的使用组配置主机角色和利用继承简化配置部分进行讲解。

David Douthitt 在administratosphere.wordpress.com/2009/02/19/configuring-nagios-with-m4/中更深入地探讨了使用m4进行 Nagios 配置的可能性。

另见

本章中的使用组配置主机角色和利用继承简化配置部分

第十章：安全性与性能

在本章中，我们将介绍以下内容：

要求 Web 界面进行身份验证
使用认证联系人
将调试信息写入 Nagios 日志文件
使用 Nagiostats 监控 Nagios 性能
通过预缓存对象文件来提高启动时间
设置冗余监控主机

介绍

即使是中型网络的大多数管理员，也会选择为监控软件专门分配一台服务器，有时甚至为 Nagios Core 配置一台独立服务器。这主要是因为大多数综合性 Nagios Core 设置都有两个主要因素：

它们拥有很多特权，因为为了检查如此多不同主机和服务的运行状态，它们需要被授予适当的网络访问权限。这通常意味着它们的 IP 地址在整个网络中都被列为白名单。能够获得这些特权的用户可能会造成很大损害。
它们有大量工作要做，因此理想情况下需要专用的软件和硬件资源来顺利运行数千个主机和服务检查，并及时发现问题和恢复。如果 Nagios Core 服务器无法跟上检查计划，可能会导致对非常重要的服务的通知延迟。

因此，在构建配置时，非常重要的一点是要考虑到你的 Nagios Core 服务器的安全性和性能。

一般的最佳网络安全实践适用于 Nagios Core 管理，这些内容在此不再详细讨论。以下通用指南对于保护 Nagios Core 服务器与保护任何其他类型的服务器同样重要：

不要以 root 用户运行服务器：除非你自己修改了配置，否则这通常不是一个问题，因为如果你按照快速入门指南安装，服务器应该已设置为以非特权的nagios用户运行。在大多数情况下，Nagios Core 不需要 root 权限。
使用防火墙：Nagios Core、NSCA 和 NRPE 的主机检查所提供的保护非常基础，不能替代软件或硬件防火墙策略。即便是一个简单的iptables或pf软件防火墙，也非常有助于保护监控服务器。
使用最小特权原则：不要给予 Nagios Core 或其任何插件或进程超过所需的权限，且应将可写文件（如logs）和状态信息限制为仅对适当的用户可写。类似地，仅允许通过防火墙让 Nagios Core 访问它所需检查的内容，其他的不要开放。
加密敏感信息：如果可以避免，尽量不要将凭证以明文形式写入任何配置文件中；如果无法避免，请将它们定义在只有 nagios 用户可读的资源文件中。

因此，你不应将本章视为一个完整的 Nagios Core 服务器安全和优化指南。有关安全性和优化程序的更全面内容，务必查阅 Nagios Core 文档中的以下页面：

安全性考虑：nagios.sourceforge.net/docs/3_0/security.html
增强 CGI 安全性和 认证：nagios.sourceforge.net/docs/3_0/cgisecurity.html
调优 Nagios 以获得最大 性能：nagios.sourceforge.net/docs/3_0/tuning.html

本章特别关注保护 CGI，因为 web 界面会将 Nagios Core 的信息暴露给外界，如果配置不当，容易受到滥用攻击。本章还将包括评估 Nagios Core 性能的方法。

为 web 界面要求认证

在本教程中，我们将探讨为 Nagios Core web 界面使用基本认证的方法，这可能是防止恶意用户滥用软件的最重要配置步骤。

默认情况下，Nagios Core 的安装过程采取了一个明智的步骤，即在其推荐的 Apache 配置文件中默认锁定认证，使用标准的 HTTP 认证，并为名为nagiosadmin的默认用户设置了完全权限。

不幸的是，一些管理员会删除此认证或从不安装它，尽管安装指南中已有推荐。即便在私人网络上，也建议安装并保留认证，特别是当运行 Nagios Core 的服务器以任何方式连接到互联网时（通常不推荐这样做）。

这样做不仅是因为安全性方面的好处，还因为它允许你设置基本的访问控制，赋予特定用户在某些资源上读取状态或执行命令的权限，但对其他资源则没有权限。它还有其他更微妙的好处，比如记录执行操作的用户姓名，以便日志记录。

准备工作

你需要访问 Nagios Core 服务器的后台，版本要求为 3.0 或更高，以便更改其配置并重启服务器。你还需要一个正常工作的 web 界面。本教程大部分内容假设 web 界面运行在推荐的Apache HTTPD 服务器上；你可能还需要能够编辑该配置。这里假定你对 Apache HTTPD 有一定的了解；如果需要查阅，网上的文档非常详细：

httpd.apache.org/docs/

本教程分为两部分：首先，我们将确保所有推荐的设置已到位，以正确要求身份验证；接着，我们将演示如何添加一个名为helpdesk的用户，该用户拥有只读权限，用于访问服务器的 Web 界面。该用户将能够查看所有主机和服务的状态，但无法执行（例如）命令或提交被动检查结果。

如何做...

我们可以确保 Nagios Core Web 界面已正确启用身份验证，如下所示：

清除浏览器中的所有 cookie 和已保存的身份验证数据，然后尝试访问 Web 界面。如果浏览器没有像下面那样要求您输入用户名或密码，那么可能是您的身份验证已被禁用或未正常工作：
在服务器上，进入 Nagios Core 配置目录并打开cgi.cfg文件。在默认安装中，该文件保存在/usr/local/nagios/etc/cgi.cfg中。
```
# cd /usr/local/nagios/etc
# vi cgi.cfg
```
确保use_authentication的值未被注释掉并设置为1：
```
use_authentication=1
```
确保default_user_name指令已被注释掉：
```
#default_user_name=guest
```
在 Apache 配置中的nagios.conf文件中，检查以下行是否包含，指向htpasswd.users文件：
```
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
```
此文件应位于 Apache 的配置目录中，例如/etc/apache/conf.d/nagios.conf。如果需要更改 Apache 的配置来修复此问题，您需要重启 Apache 使更改生效。

我们可以按如下方式添加一个名为helpdesk的只读用户：

使用htpasswd（Apache HTTPD 密码管理器）将用户添加到htpasswd.users文件中。其位置会根据系统的不同而有所变化；常见的位置有/usr/bin和/usr/local/apache/bin。
```
# htpasswd /usr/local/nagios/etc/htpasswd.users helpdesk
New password:
Re-type new password:
Adding password for user helpdesk
```
如果您担心系统上的用户会窃取哈希值，可以将htpasswd.users文件设置为仅 Web 服务器用户可读。
在cgi.cfg中，取消注释authorized_for_read_only指令，并将新添加的helpdesk用户添加到其值中：
```
authorized_for_read_only=helpdesk
```
将该用户添加到authorized_for_all_services和authorized_for_all_hosts指令的值中：
```
authorized_for_all_services=nagiosadmin,helpdesk
authorized_for_all_hosts=nagiosadmin,helpdesk
```
小心不要将这些与authorized_for_all_service_commands和authorized_for_all_host_commands指令混淆。

您通常不需要像其他.cfg文件一样重启 Nagios Core 服务器来使这些更改生效。

完成这些设置后，您应该只能使用有效的用户名和密码访问 Nagios Core Web 界面。安装时创建的默认nagiosadmin用户应具有完全权限，而在本教程中添加的helpdesk用户应能够查看主机和服务的状态，但无法执行任何命令，如重新调度检查或提交被动检查结果。

它是如何工作的...

需要注意的是，实际上并不是 Nagios Core 自身在提示用户名和密码并执行认证检查；这项功能由 Web 服务器执行，如 nagios.conf 文件所指定，推荐与 Apache HTTPD 一起安装使用。

然而，在登录后，Nagios Core 会每次访问 Web 界面中的 CGI 脚本时，使用 cgi.cfg 文件中定义的权限，以确保通过 Web 服务器身份验证的用户具有查看请求页面或执行请求操作的权限。

我们通过注释掉 default_user_name 指令来禁用它，因为该指令指定了 Nagios Core 在没有身份验证的情况下访问 CGI 的用户。这是一个潜在的危险设置，在大多数情况下最好避免，尤其是对于具有公开可访问地址的服务器。

以下 cgi.cfg 文件中的指令允许细化使用 CGI 的权限，形成一种简单的访问控制列表：

authorized_for_configuration_information: 指定的用户允许在 Web 界面中查看主机的配置信息
authorized_for_system_information: 指定的用户允许查看 Nagios Core 的进程和性能信息
authorized_for_system_commands: 指定的用户允许运行影响 Nagios Core 进程的命令，如关机和重启
authorized_for_all_services: 指定的用户允许查看所有服务的状态信息和历史记录
authorized_for_all_hosts: 指定的用户允许查看所有主机的状态信息和历史记录
authorized_for_all_service_commands: 指定的用户允许在所有服务上运行命令，如重新安排检查或提交被动检查结果
authorized_for_all_host_commands: 指定的用户允许在所有主机上运行命令，如重新安排检查或提交被动检查结果

进一步细化每项服务和每台主机的访问权限可以通过认证联系人完成，在本章的使用认证联系人示例中有展示。这对于职责混合、需要访问相同 Nagios Core Web 界面的团队非常推荐。

还有更多...

除了通过 Apache HTTPD 进行身份验证外，通常也可以限制允许访问 Nagios Core 实例的 IP 地址，使用 Order 和 Allow Apache 指令。我们可以如下扩展由 Apache 加载的 nagios.conf 文件：

<Directory "/usr/local/nagios/sbin">
    Options ExecCGI
    AllowOverride None
    AuthName "Nagios Access"
    AuthType Basic
    AuthUserFile /usr/local/nagios/etc/htpasswd.users
    Require valid-user
 Order Allow,Deny
 Deny from all
 Allow from 127.0.0.0/16
 Allow from 10.128.0.1
</Directory>

这将只允许本地地址和 10.128.0.1 访问 CGI，其他任何人都会被拒绝访问并返回 403 Forbidden。类似地，我们也可以安排只允许通过 HTTPS 连接，或许使用 SSLRequireSSL 指令；一般来说，我们可以配置 Apache 来严格控制访问 CGI，何况是滥用它们。

请注意，这一切不应替代适当的防火墙解决方案和策略。监控服务器应像任何其他关键任务服务器一样得到保护。

另见

本章中的使用经过身份验证的联系人示例
第七章中的Web 界面中的查看配置和Web 界面中调度检查示例，使用 Web 界面

使用经过身份验证的联系人

在这个示例中，我们将学习如何使用经过身份验证的联系人来精细控制 Nagios Core Web 界面中信息的访问权限。这个示例适用于某个用户需要查看特定主机和服务的状态，但不应被允许查看其他主机和服务的情况，这种设置无法通过cgi.cfg中的指令进行管理。

作为一个简单示例，在某个监控服务器上，我们可能配置了如下两个主机：

define host {
    use        linux-server
    host_name  sparta.naginet
    alias      sparta
    address    10.128.0.21
    contacts   nagiosadmin
}
define host {
    use        linux-server
    host_name  athens.naginet
    alias      athens
    address    10.128.0.22
    contacts   nagiosadmin
}

我们可能想要添加一个新用户athensadmin，使其能够查看athens.naginet主机及其服务的状态，并对其执行命令，但不能查看sparta.naginet主机或其服务。

准备工作

你需要访问 Nagios Core 服务器的后台，版本为 3.0 或更高，以更改其配置并重新启动它。你还需要一个运行身份验证的有效 Web 界面，并熟悉其工作原理；本章中的要求 Web 界面进行身份验证示例说明了如何操作。

如何操作...

我们可以通过以下方式添加一个经过身份验证的联系人：

在htpasswd.users文件中使用htpasswd工具创建一个名为athensadmin的新用户：

# htpasswd /usr/local/nagios/etc/htpasswd.users athensadmin
New password:
Re-type new password:
Adding password for user athensadmin

使用刚刚添加的凭据登录到 Nagios Core Web 界面，点击左侧菜单中的主机，验证你暂时无法查看任何信息：
回到命令行，切换到 Nagios Core 对象配置目录。在快速入门安装指南中，这个目录是/usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```
编辑contacts.cfg文件，添加一个新的联系人对象定义athensadmin。在这里，我们使用了generic-contact模板。如果你愿意，也可以使用你自己的模板或值；contact_name的值是最重要的部分：
```
define contact {
    use           generic-contact
 contact_name  athensadmin
    alias         Athens Administrator
    email         athens@example.com
}
```
编辑你希望athensadmin用户访问的主机或服务，并将athensadmin添加到其联系人列表中。以我们的示例为例，这意味着athens.naginet的定义类似于以下代码片段：
```
define host {
    use        linux-server
    host_name  athens.naginet
    alias      athens
    address    10.128.0.22
 contacts   nagiosadmin,athensadmin
}
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成这些步骤后，使用athensadmin用户登录应该能查看athens.naginet主机的详细信息，但不能查看其他信息：

你还应该能够执行与该主机相关的命令，例如重新调度检查和确认问题。

工作原理...

当以经过身份验证的用户身份通过 Apache HTTPD 登录时，Nagios Core 会检查用户名是否与任何配置联系人中的 contact_name 指令匹配。如果匹配，则会授予检查该联系人关联的主机和服务状态的权限，并且只能对这些主机和服务执行命令。Web 界面其他方面的功能保持不变。对于经过身份验证的联系人而言，似乎没有其他主机或服务正在被监控。

如果你的网络包含同一位置的设备或具有混合监控职责的团队，这将允许你将 Nagios Core 界面限制为特定用户的某些主机。这对于保密性、透明性和委托目的非常有用。

还有更多…

如果你希望允许经过身份验证的用户只读访问他们关联的主机或服务的详细信息，你可以通过将其用户名添加到 cgi.cfg 中 authorized_for_read_only 指令的值来实现：

authorized_for_read_only=athensadmin

然后，athensadmin 用户仍然可以查看相同的主机和服务信息，但不能执行任何命令：

另见

本章中的 要求 Web 界面进行身份验证 食谱
本章节中第一章中的 创建新联系人 食谱，理解主机、服务和联系人

将调试信息写入 Nagios 日志文件

在本食谱中，我们将学习如何使用 Nagios Core 中的调试日志文件，从运行中的程序中获取各种进程信息，比标准 log_file 指令指定的文件中提供的信息多得多。这不仅对调试有用，特别是在 Nagios Core 在运行时执行了意外操作时，还能帮助你更好地了解服务器如何工作，特别是与你的配置相关的部分。

准备就绪

你将需要一个版本为 3.0 或更高版本的 Nagios Core 服务器。3.0 之后的版本提供了更多调试选项，但这些将在本食谱中提到。你需要能够修改 nagios.cfg 文件并重启服务器。

在本示例中，我们将简单地记录尽可能多的内容，然后在 工作原理…… 部分解释如何在必要时调整日志记录行为。

如何操作…

我们可以通过以下方式为我们的监控服务器启用非常详细的调试：

切换到 Nagios Core 的配置目录。在默认安装中，这是 /usr/local/nagios/etc。编辑 nagios.cfg 文件：
```
# cd /usr/local/nagios/etc
# vi nagios.cfg
```
查找 debug_level、debug_verbosity 和 debug_file 指令。确保它们没有被注释掉，或者如果它们不存在，则将其添加到文件末尾，并按如下定义：
```
debug_level=-1
debug_verbosity=2
debug_file=/usr/local/nagios/var/nagios.debug
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，/usr/local/nagios/var/nagios.debug文件应该会很快开始填充有关运行进程的信息。你可能会发现，使用tail -f监视它一段时间很有帮助，这样你可以实时看到文件内容的更新：

# tail -f /usr/local/nagios/var/nagios.debug
[1347529967.839794] [008.2] [pid=14621] No events to execute at the moment. Idling for a bit...
[1347529967.839799] [001.0] [pid=14621] check_for_external_commands()
[1347529967.839805] [064.1] [pid=14621] Making callbacks (type 8)...
[1347529968.089971] [008.1] [pid=14621] ** Event Check Loop
[1347529968.090027] [008.1] [pid=14621] Next High Priority Event Time: Thu Sep 13 21:52:52 2012
[1347529968.090038] [008.1] [pid=14621] Next Low Priority Event Time:  Thu Sep 13 21:53:00 2012
...

它是如何工作的...

debug_level指令指定应该写入调试日志的信息量（及其种类）。在这里，我们使用了值-1，这是指定所有调试信息写入调试日志文件的快捷方式。

然而，在实践中，我们通常只希望获取有关特定类型的 Nagios Core 任务的信息。在这种情况下，我们可以使用debug_level的OR值来指定需要的任务。

可以通过以下数字指定不同种类的调试信息：

1：功能进入和退出调试
2：配置调试
4：进程调试
8：计划事件调试
16：主机和服务检查调试
32：通知调试
64：事件代理调试

在 Nagios Core 3.3 及以后的版本中，还可以指定以下内容。后续版本中可能会有更多新增内容：

128：外部命令调试
256：命令调试
512：计划停机调试
1024：注释调试
2048：宏调试

为了指定多个调试类型，而不是用逗号分隔这些值，它们是相加的。例如，如果我们只想保存进程和计划事件的调试信息，而不包含其他内容，我们将使用4 + 8 = 12：

debug_level=12

我们可以通过将debug_level重新设置为0，即其默认值，完全关闭调试功能。

还有更多内容...

Nagios Core 在最高调试级别下生成大量信息，即使在最小配置下，每秒也会产生超过 30 行的信息，因此如果不总是需要它，最好不要永久运行调试，因为它可能会逐渐占满磁盘。你可以通过使用max_debug_file_size指令指定文件的最大字节数来避免这种情况。例如，如果希望限制文件大小为 1MB，我们可以定义如下：

max_debug_file_size=1000000

当调试日志的大小超过设定限制时，Nagios Core 将通过添加.old扩展名来“滚动”现有的调试日志，并开始新的日志。它还会在这样做时自动删除任何以前带有.old扩展名的日志文件。

另见

本章中的使用 Nagiostats 监控 Nagios 性能方法
第七章中的查看和解释通知历史记录方法，使用 Web 接口

使用 Nagiostats 监控 Nagios 性能

在本教程中，我们将学习如何使用nagiostats工具获取有关 Nagios Core 进程性能以及其监视的主机和服务状态的一些统计信息。

可选地，我们还将展示如何使用 Nagios Core 源代码分发中构建的mrtg.cfg文件，设置由mrtg（多路由器流量图形化器）构建的图表，并在 Web 界面的菜单中链接到这些图表。Nagios Core 源代码分发包含一些文件来帮助此操作，我们将在这里使用。

准备工作

你需要安装并运行 Nagios Core 3.0 或更新版本服务器来调用nagiostats。旧版本包含此实用程序，但返回的信息可能不如新版本详细。

如果你希望运行mrtg图表，这是强烈推荐的，你应该在系统上安装mrtg及其辅助程序indexmaker。如果你已经使用mrtg图表其他内容，不用担心，这个操作不会影响它们。

此操作不假设您对mrtg有任何熟悉程度，但如果您在使用中遇到任何问题，可以在线查阅其文档：oss.oetiker.ch/mrtg/doc/index.en.html。

你还应该可以访问 Nagios Core 安装时编译的源代码。如果需要重新获取源代码，可以从 Nagios Core 网站下载（www.nagios.org/）。

在这种情况下，您需要再次运行./configure来生成所需的文件sample-config/mrtg.cfg。

操作步骤...

我们可以随时在一步中调用nagiostats本身，以获取有关服务器性能的统计信息：

执行以下命令：

# /usr/local/nagios/bin/nagiostats -c /usr/local/nagios/etc/nagios.cfg

这将给你输出，从以下开始：

Nagios Stats 3.4.1
Copyright (c) 2003-2008 Ethan Galstad (www.nagios.org)
Last Modified: 05-11-2012
License: GPL
CURRENT STATUS DATA
------------------------------------------------------
Status File:                            /usr/local/nagios/var/status.dat
Status File Age:                        0d 0h 0m 2s
Status File Version:                    3.4.1
Program Running Time:                   2d 2h 25m 23s
Nagios PID:                             2487
Used/High/Total Command Buffers:        0 / 0 / 4096
Total Services:                         60
Services Checked:                       60
...

执行以下命令：
```
# /usr/local/nagios/bin/nagiostats -c /usr/local/nagios/etc/nagios.cfg --help
```
这将为您提供所有字段的名称和含义的完整列表，由nagiostats输出返回。

如果您希望包含此数据的mrtg图表，一个很好的起点是使用 Nagios Core 源代码分发中包含的示例配置，在sample-config/mrtg.cfg中。

将sample-config/mrtg.cfg复制到/usr/local/nagios/etc：

# cp nagios-3.4.1/sample-config/mrtg.cfg /usr/local/nagios/etc

创建一个目录来存储mrtg页面和图表，以便在 Nagios Core Web 界面中查看：
```
# mkdir /usr/local/nagios/share/stats
```
编辑/usr/local/nagios/etc/mrtg.cfg，在文件顶部包含一个WorkDir声明：
```
WorkDir: /usr/local/nagios/share/stats
```

运行mrtg以创建图表：

# mrtg /usr/local/nagios/etc/mrtg.cfg

对于第一次运行，我们可以安全地忽略任何关于缺少先前数据或备份日志文件的错误：

2012-09-16 17:01:04, Rateup WARNING: /usr/bin/rateup could not read the primary log file for nagios-n
2012-09-16 17:01:04, Rateup WARNING: /usr/bin/rateup The backup log file for nagios-n was invalid as well
2012-09-16 17:01:04, Rateup WARNING: /usr/bin/rateup Can't remove nagios-n.old updating log file
2012-09-16 17:01:04, Rateup WARNING: /usr/bin/rateup Can't rename nagios-n.log to nagios-n.old updating log file

如果您的 shell 中使用 UTF-8 语言环境，可能会导致mrtg运行失败。您可以使用env前缀在标准 C 语言环境中运行它：

# env LANG=C mrtg /usr/local/nagios/etc/mrtg.cfg

使用安装的mrtg中的indexmaker辅助程序运行，创建一个指向图表的索引：
```
# indexmaker /usr/local/nagios/etc/mrtg.cfg --output=/usr/local/nagios/share/stats/index.html
```
除非以后向mrtg.cfg添加或删除图表定义，否则只需要执行一次此操作。
访问http://olympus.naginet/nagios/stats，用你自己的 Nagios Core 服务器主机名替换olympus.naginet。在认证后（如果需要），我们应该能够看到一些空的mrtg图表：

不用担心它们为空；我们预计会是这样，因为目前每个图表只有一个数据点。
如果到目前为止一切顺利，我们可能需要添加一个每五分钟运行一次的 cron 任务，以向图表添加新的数据点。在这里，我们假设 mrtg 程序保存在 /usr/bin：
```
*/5 * * * *  root  /usr/bin/mrtg /usr/local/nagios/etc/mrtg.cfg
```
执行此操作的最佳方法因系统而异。您可以将其放入 /etc/crontab，或者如果您希望更整洁，可以将其放入 /etc/cron.d/nagiostats 中。

作为 root 用户运行它可能是安全的，但如果您对此有所担心，您也可以通过包括 --lock-file 选项，以 nagios 用户身份运行它：
```
*/5 * * * *  nagios  /usr/bin/mrtg --lock-file=/usr/local/nagios/var/mrtg.cfg.lock /usr/local/nagios/etc/mrtg.cfg
```
这可能需要修正已生成图表的权限：
```
# chown -R nagios.nagios /usr/local/nagios/share/stats
```

完成此操作后，如果 cron 任务安装正确，我们应该会在接下来的几个小时内开始看到数据被绘制：

它是如何工作的...

nagiostats 提供的统计信息既包含了 Nagios Core 本身的性能数据，如完成对所有对象检查所需的时间，以及每次检查所需的平均时间，还包括主机在不同状态下的数量等数据。默认情况下，运行它将以简洁但易读的格式返回数据；通过运行 --help，您可以更好地理解每个字段的含义，正如配方中所建议的。

mrtg.cfg 文件包含在 Nagios 源代码分发包中，该文件在 ./configure 阶段根据您的特定系统进行定制，包含了 mrtg 图表的示例定义，这些图表解析了从 nagiostats 获取的数据。这些图表并不是使用 nagiostats 提供的数据的唯一可能图表，但它们是有用的示例。

使用的数据与您从 shell 中调用 nagiostats 时读取的数据相同，但格式略有不同。如果您想查看传递给 mrtg 的数据，可以使用 --mrtg 选项运行它，并通过 --data 提供字段以包含在输出中；例如：

# /usr/local/nagios/bin/nagiostats -c /usr/local/nagios/etc/nagios.cfg --mrtg --data=AVGACTSVCPSC,AVGPSVSVCPSC,PROGRUNTIME,NAGIOSVERPID
0
0
1d 2h 43m 43s
Nagios 3.4.1 (pid=1080)

配方中调用的 indexmaker 是一个独立的程序，它会生成一个包含所有图表链接的 index.html 文件，仅仅是为了方便。与 mrtg 调用一样，它会引用配置文件 /usr/local/nagios/etc/mrtg.cfg 来确定需要执行的操作。

还有更多...

一旦您对图表网页的显示方式满意，您可能希望将它们添加到 Nagios Core 的侧边栏中。这可以通过编辑 /usr/local/nagios/share/side.php 并在 性能信息 链接下方添加一个名为 性能报告 的新链接来实现。新行可能类似于以下代码片段：

<li><a href="/nagios/stats/" target="<?php echo $link_target;?>">Performance Reports</a></li>

这将使图表的链接在 Web 界面中显示如下：

请注意，像这样的菜单自定义将在重新安装 Nagios Core 时被覆盖。

如果你喜欢 mrtg 处理这些数据的方式，你可能会喜欢看看Cacti，它是 rrdtool 的一个非常有用的前端，类似于 mrtg。它允许你在定义图表时拥有很大的灵活性，尽管学习起来需要一些时间（www.cacti.net/）。

如果你对 Nagios Core 性能和状态数据的更多图表感兴趣，你可能会喜欢 Nagiosgraph 扩展，该扩展在第十一章的使用 NagiosGraph 跟踪主机和服务状态食谱中进行了讨论，自动化和扩展 Nagios。

最后，请注意，Nagios Core 在其报告中包含了一些内置的主机和状态图表，因此在尝试为已经存在的报告构建图表之前，请务必查看这些内容！这些内容也在第七章的与 Web 界面协作中进行了讨论。请查看本食谱中另见部分中的参考资料。

另见

第七章的使用战术概览、查看和解读可用性报告、查看和解读趋势、查看和解读通知历史食谱，与 Web 界面协作。
在第十一章的使用 Nagiosgraph 跟踪主机和服务状态食谱中，自动化和扩展 Nagios。

通过预缓存对象文件来提高启动时间

在本食谱中，我们将学习如何缩短大型和/或复杂的 Nagios Core 配置的启动时间。这是通过预缓存来自配置的 Nagios Core 对象，应用所有适当的模板和组扩展到一个文件中，这样 Nagios Core 就能比更模块化、更具可读性的配置更快地读取。

如果你监控的主机或服务数量超过一百个，并且有一个相对复杂的模板和分组布局（如第一章和第九章中一些食谱所建议的那样），这可能会对你有兴趣。它在较小的安装上也能运行，但启动速度的提升可能非常有限。

如果你只运行一个小型设置，那么如果你想更好地理解 Nagios Core 如何扩展使用大量模板和其他配置技巧的配置，本食谱可能会对你有兴趣。

准备工作

你应该运行 Nagios Core 3.0 或更新版本的服务器，并且可以访问服务器以更改其配置。

你应该检查 /usr/local/nagios/etc/nagios.cfg 中的 precached_object_file 指令是否已取消注释，并定义为一个可访问的文件。快速启动配置中的设置是合理的：

precached_object_file=/usr/local/nagios/var/objects.precache

取消注释此指令并不会实际生成或使用预缓存对象文件；这需要明确执行，具体操作将在后面的步骤中解释。

不要将其与同一文件中的object_cache_file指令混淆，该指令应该保持当前设置不变。

在这个例子中，我们将使用一个相当大的配置，定义了大约 20,000 个对象，且运行在一台较慢的机器上。

如何实现...

我们可以通过使用预缓存的对象文件来获得一些性能提升的想法，如下所示：

运行nagios并使用-s选项，检查输出。这将打印出通常参与从配置文件构建完整对象定义的进程的概要。

# /usr/local/nagios/bin/nagios -s /usr/local/nagios/etc/nagios.cfg

在这种情况下，我们特别关注输出中用星号标记的部分，位于OBJECT CONFIG PROCESSING TIMES标题下，表示可以通过预缓存对象文件来提升的时间，包括在TOTAL字段末尾的节省时间估算：

OBJECT CONFIG PROCESSING TIMES      (* = Potential for precache savings with -u option)
----------------------------------
Read:                 8.285613 sec
Resolve:              0.001696 sec  *
Recomb Contactgroups: 0.000124 sec  *
Recomb Hostgroups:    1.972412 sec  *
Dup Services:         0.309333 sec  *
Recomb Servicegroups: 0.000029 sec  *
Duplicate:            0.000168 sec  *
Inherit:              0.102685 sec  *
Recomb Contacts:      0.000001 sec  *
Sort:                 0.000000 sec  *
Register:             0.826046 sec
Free:                 0.102805 sec
 ============
TOTAL:                11.600912 sec  * = 2.386448 sec (20.57%) estimated savings

我们可能会决定，2.3秒的节省时间对于我们的重启时间来说是值得的。也许我们真的不想错过任何重要的检查！

使用-p和-v选项运行nagios，验证配置并同时写入预缓存对象文件：
```
# /usr/local/nagios/bin/nagios -pv /usr/local/nagios/etc/nagios.cfg
```
使用-u和-s选项运行nagios，查看在指示使用预缓存对象文件时，启动和调度测试的耗时：
```
# /usr/local/nagios/bin/nagios -us /usr/local/nagios/etc/nagios.cfg
```

我们可能会注意到，TOTAL所需时间现在明显减少（比预估的改进还要多），并且许多时间已经为零秒，因为 Nagios Core 完全没有执行那个步骤：

OBJECT CONFIG PROCESSING TIMES      (* = Potential for precache savings with -u option)
----------------------------------
Read:                 4.975257 sec
Resolve:              0.000000 sec  *
Recomb Contactgroups: 0.000000 sec  *
Recomb Hostgroups:    0.000000 sec  *
Dup Services:         0.000000 sec  *
Recomb Servicegroups: 0.000000 sec  *
Duplicate:            0.000000 sec  *
Inherit:              0.000000 sec  *
Recomb Contacts:      0.000000 sec  *
Sort:                 0.000000 sec  *
Register:             0.828953 sec
Free:                 0.000758 sec
 ============
TOTAL:                5.804968 sec

完成此操作后，我们应该会发现，使用-d和-u标志重新启动 Nagios Core 的速度比以前更快。这个过程可以融入到任何启动脚本中（例如/etc/init.d/nagios）。这也意味着如果我们对配置进行了更改，我们必须记得再次运行nagios -pv来验证并重新生成预缓存对象文件。

它是如何工作的...

当使用-p选项运行时，Nagios Core 将正常解析配置，将其转化为可以使用的对象，扩展hostgroups、templates和其他配置快捷方式。它会将这些信息写入由precached_object_file指令指定的单一文件。

配置文件是人类可读的；如果你在文本编辑器中查看它，你将看到从配置中构建的扩展定义，包含所有对象继承、正则表达式的主机组和多主机服务定义。

在下一次重启时，可以通过包括-u选项指示 Nagios Core 使用这个文件，而不是重新解析整个配置。你可能需要在任何正在使用的init.d脚本中加入这个选项。

还有更多内容...

如果在 Nagios Core 重启时你没有速度问题，最好避免让这成为永久配置，因为这会给配置构建添加额外的复杂性；如果你在更改配置后忘记重建预缓存对象文件并重启 Nagios Core，它将继续使用先前的配置，而没有意识到差异。请谨慎使用！

另见

第一章中的在组内所有主机上运行服务食谱，理解主机、服务和联系人。
第九章中的使用组配置主机角色和使用继承简化配置的食谱，配置管理。

设置冗余监控主机

在本食谱中，我们将学习如何通过在另一台机器上运行第二个配置几乎相同的 Nagios Core 实例来实现 Nagios Core 的简单冗余。

这看起来好像不需要食谱就能实现。只需简单地复制 Nagios Core 系统的配置并同时运行，应该是比较直接的。然而，这里有两个主要问题：

网络上检测到的每个问题都会触发两次通知事件。负责看护传呼机的管理员可能会觉得这难以忍受！
一切都会被检查两次。在较小的网络中，如果检查较简单，这可能不会成为问题，但在更大、繁忙的网络中，可能会成为问题。

本食谱将通过配置从属监控服务器来抑制通知，直到它检测到主服务器的问题，从而解决第一个问题。在更多内容…部分中，我们将讨论如何扩展这个解决方案以解决第二个问题，通过防止从属服务器在主服务器活动时进行检查以及发送通知。

准备工作

这是本书中最复杂的食谱之一，也是最长的，涉及许多其他食谱和章节中的概念。要跟随这个食谱，你可能需要对以下内容有一定的工作知识：

Nagios Core 的构建模块——主机、服务、联系人、命令、插件和通知——在第 1 到第四章的所有食谱中都有解释。
通过check_nrpe进行远程执行——在第六章中的所有食谱中都有解释，启用远程执行。该食谱将在某个时刻告诉你需要在主服务器上安装 NRPE 以运行特定插件，因此你应该先学习如何做这一步。
事件处理程序及其写入命令文件的方法——在第十一章的设置事件处理程序脚本食谱中解释。

事件处理程序脚本是这个配置中最复杂的部分，幸运的是它们已经为我们写好了；我们将通过从 Nagios Core 源代码包中复制它们来展示如何实现。你需要确保有适用于你版本的 Nagios Core 的源代码。如果需要重新获取源代码，可以从 Nagios Core 的官网 www.nagios.org/ 重新下载。

本配方假设我们有两台监控服务器：olympus.naginet (10.128.0.11)，它将作为主监控服务器，和 everest.naginet (10.128.0.12)，它将作为从属服务器。这两台服务器配置为监控相同的三个主机，并进行 PING 服务检查：

sparta.naginet
athens.naginet
ithaca.naginet

这两台服务器的 Nagios Core 配置最初完全相同，且两者都将通知发送到适当的联系人组。然而，请注意，这两台服务器尚未互相监控；这是本配方中的一个重要部分。

如何执行...

我们可以为两台 Nagios Core 服务器安排一个简单的冗余设置，如下所示：

确认 check_nagios 插件在主服务器上可用，并尝试运行它：

# cd /usr/local/nagios/libexec
# ./check_nagios -e 5 -F /usr/local/nagios/var/status.dat -C /usr/local/nagios/bin/nagios
NAGIOS OK: 1 process, status log updated 3 seconds ago

在主服务器上安装 NRPE 守护进程，并在 nrpe.cfg 文件中定义命令 check_nagios（详见第六章）。

command[check_nagios]=/usr/local/nagios/libexec/check_nagios -e 5 -F /usr/local/nagios/var/status.dat -C /usr/local/nagios/bin/nagios

在 /usr/local/nagios/etc/nrpe.cfg 文件中，将从属服务器的地址包含在 allowed_hosts 指令中：
```
allowed_hosts=127.0.0.1,10.128.0.12
```
不要忘记重启 NRPE 以将此更改包含到配置中。
在从属服务器上，验证通过 check_nrpe 调用是否能够获取主服务器上 check_nagios 的结果：
```
# cd /usr/local/nagios/libexec
# ./check_nrpe -H olympus.naginet
NRPE v2.13
# ./check_nrpe -H olympus.naginet -c check_nagios
NAGIOS OK: 1 process, status log updated 2 seconds ago
```
你需要在从属服务器上安装 check_nrpe 插件来实现这一点。这个过程在 使用 NRPE 监控远程机器上的本地服务 这一配方中进行了说明，详见第六章。
在从属服务器上，将源代码包中的四个文件（两个事件处理程序和两个辅助脚本）复制到 /usr/local/nagios/libexec/eventhandlers 目录（你可能需要先创建这个目录）：
```
# EHD=/usr/local/nagios/libexec/eventhandlers
# mkdir -p $EHD
# cd /usr/local/src/nagios
# cp contrib/eventhandlers/enable_notifications $EHD
# cp contrib/eventhandlers/disable_notifications $EHD
# cp contrib/eventhandlers/redundancy-scenario1/handle-master-host-event $EHD
# cp contrib/eventhandlers/redundancy-scenario1/handle-master-proc-event $EHD
```
前面的命令假设你将 Nagios Core 分发包的源代码保存在 /usr/local/src 目录下。我们定义并使用 shell 变量 $EHD 来方便地引用事件处理程序目录。
在已安装的 handle-master-proc-event 脚本中，找到并将 active_service_checks 替换为 notifications。命令行工具 sed 非常适合这个操作：
```
# sed -i 's/active_service_checks/notifications/g' $EHD/handle-master-proc-event
```
这是因为提供的脚本发出的命令是切换活动检查，而不是通知。写作时，在 Nagios 3.3.1 中，handle-master-proc-event 脚本的第 49 行可能存在一个 bug，需要修正：
```
`eventhandlerdir/disable_active_service_checks`
```
它应该在第一个反引号后面加上一个美元符号：
```
`$eventhandlerdir/disable_active_service_checks`
```
确保事件处理程序由 nagios 用户拥有并且具有可执行权限：
```
# chown nagios.nagios $EHD/*
# chmod 0755 $EHD/*
```

在/usr/local/nagios/etc/objects/commands.cfg中，定义两个新的事件处理程序命令：

define command {
    command_name  handle-master-host-event
    command_line  $USER1$/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$ $HOSTATTEMPT$
}
define command {
    command_name  handle-master-proc-event
    command_line  $USER1$/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
}

在从属服务器上创建主机和服务定义来监控主服务器。它可能类似于以下代码片段；根据需要更改host_name、alias和address的值。所使用的模板仅为示例；你可能希望选择已定义的模板，以便频繁地进行检查，并在 24x7 的时间段内运行。

define host {
    use            critical-host-template
    host_name      olympus.naginet
    alias          olympus
    address        10.128.0.11
    event_handler  handle-master-host-event
}
    define service {
        use                  critical-service-template
        host_name            olympus.naginet
        service_description  NAGIOS
        check_command        check_nrpe!check_nagios
        event_handler        handle-master-proc-event
    }

如果愿意，你可以让主服务器也监控从属服务器。

请注意，你需要定义check_nrpe命令，正如第六章中使用 NRPE 监控远程机器上的本地服务配方所解释的那样。如果你已经按照该配方操作，那么你可能已经完成了此操作。如果没有，以下定义适用：
```
define command {
    command_name  check_nrpe
    command_line  $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
```
最后，在从属服务器的nagios.cfg中，将enable_notifications更改为0：
```
enable_notifications=0
```

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，两个 Nagios Core 服务器应该都在运行，但需要注意的是，从属服务器上的通知默认是禁用的，正如战术概览中所示：

然而，所有系统仍然在被监控，正如服务界面中所见，包括主机上的NAGIOS服务：

这意味着通知只会由主服务器发送，因为主服务器仍然启用了通知。然而，如果主服务器宕机或其 Nagios 进程停止工作，应该会调用事件处理程序，从属服务器上的通知会自动启用。当主服务器或其NAGIOS服务恢复时，通知将再次禁用，并且检查和状态变更将继续不中断地进行。因此，我们已经建立了一种简单的冗余。如果你使用此设置，应该彻底测试它，以确保从属 Nagios Core 服务器能根据每种情况（如主机宕机、服务宕机、服务恢复等）启用或禁用通知。

它是如何工作的...

在 Nagios Core 分发包中包含的事件处理程序，我们将其复制到eventhandlers目录中，旨在根据给定服务或主机的状态处理通知和主动检查的切换。它们是为了演示事件处理程序和像这样的冗余情况而提供的。

我们首先设置从属服务器，不仅监控运行主服务器的主机，还要监控 Nagios Core 服务本身，使用check_nagios插件。该插件检查日志文件的年龄和系统的进程表，以确保系统上确实在运行 Nagios Core 服务。由于这是一个本地插件，不适用于远程检查，因此我们通过 NRPE 从从属服务器进行检查。

从服务器会检查主服务器及其NAGIOS服务的状态，作为其正常的主动检查例程的一部分。当主服务器的主机或其NAGIOS服务状态发生变化时，两个事件处理程序handle-master-host-event和handle-master-proc-event都会被调用，这些事件处理程序在相应的命令中定义。

每次调用事件处理程序时，它们都会传递三个宏形式的参数。对于handle-master-host-event，这些参数是：

$HOSTSTATE$ ：这是主服务器的新状态。
$HOSTSTATETYPE$ ：这指定状态是SOFT还是HARD。
$HOSTATTEMPT$ ：这是尝试的主机检查次数，最大值为主机的max_check_attempts。

handle-master-proc-event传递三个类似的参数，唯一的区别是它们引用的是服务状态，而不是主机状态：

$SERVICESTATE$ ：这是主服务器上NAGIOS服务的新状态。
$SERVICESTATETYPE$ ：这指定服务状态是SOFT还是HARD。
$SERVICEATTEMPT$ ：这是尝试的主机检查次数，最大值为主机的max_check_attempts。

事件处理程序的编写方式是，只有当新状态为HARD时才会执行操作；也就是说，只有当max_check_attempts的次数达到时才会生效。在足够多次连续检查失败之前，它会忽略SOFT状态的变化，直到它能够合理地确认被监控的主机或服务出现了问题。

如果主机或服务进入HARD CRITICAL状态，事件处理程序会调用辅助脚本enable-notifications，在/usr/local/nagios/var/rw/nagios.cmd的commands文件中写入命令以供服务器处理。此命令的形式如下，其中包括写入命令时的 UNIX 时间戳：

[1348129155] ENABLE_NOTIFICATIONS;1348129155

当 Nagios Core 处理此命令时，其效果是先前禁用的通知被启用，所有由于检查而生成的后续通知都会被发送。

同样，当主机或服务从HARD CRITICAL状态恢复，进入HARD UP或HARD OK状态时，会调用disable-notifications辅助脚本，并以相同的方式写入命令：

[1348129231] DISABLE_NOTIFICATIONS;1348129231

其效果是，当主服务器被标记为宕机时，从服务器会注意到并采取相同的通知行为，而当主服务器恢复时，从服务器会停止自己的通知，再次允许主服务器恢复其角色。

还有更多内容...

如果网络带宽是一个问题，我们可以安排在不使用时让从服务器基本处于闲置状态，不仅默认关闭通知，还关闭服务检查。Nagios Core 发行版中也包含了相关的辅助脚本，分别是disable_active_service_checks和enable_active_service_checks脚本。

这个变更的主要问题是从属服务器在进行初始检查时丧失状态信息；这也可以绕过，正如 Nagios 核心文档中关于冗余的解释：nagios.sourceforge.net/docs/3_0/redundancy.html。

一旦这些步骤完成，设置的主要麻烦就是必须保持两个配置目录同步。每次配置需要更改时必须在两台服务器上进行更改，这既不理想又容易出错，因此你可能想考虑使用如rsync这样的快照工具来保持两个目录一致。更多关于rsync的信息可以在en.wikipedia.org/wiki/Rsync上找到。

使用版本控制管理的配置也在这里有所帮助，如第九章中的将配置纳入版本控制的示例所推荐。这样，你可以使用git clone或svn checkout快速复制并更新多个机器上的配置文件。

另见

本章中的将调试信息写入 Nagios 日志文件的示例
第六章中的在远程机器上监控本地服务与 NRPE的示例，启用远程执行
第九章中的将配置纳入版本控制的示例，配置管理
第十一章中的设置事件处理脚本的示例，自动化与扩展 Nagios

第十一章：自动化与扩展 Nagios Core

在本章中，我们将覆盖以下内容：

允许并提交被动检查
使用 NSCA 从远程主机提交被动检查
响应 SNMP 陷阱提交被动检查
设置事件处理脚本
使用 Nagiosgraph 跟踪主机和服务状态
使用 NDOUtils 将状态读入 MySQL 数据库
编写定制化的 Nagios Core 报告
获取额外的可视化效果与 NagVis

引言

除了作为独立的监控框架有用外，Nagios Core 还具有模块化设计，允许与其他程序和工具进行交互并进行扩展，主要是通过其外部命令文件来控制服务器的行为。

与 Nagios Core 服务器进行交互的最有用方式之一是通过使用被动检查：将检查结果直接提交给服务器，而不是作为服务器自身主动检查的结果。

被动检查的最简单应用是在监控一些可能需要不确定时间才能运行的过程，因此不适合主动检查；服务不进行主动检查，而是接受由另一个应用提交的检查结果，可能是在备份脚本完成后提交的结果。这些检查可以通过一个名为Nagios Service Check Acceptor（NSCA）的附加组件进行发送和接收。同样，插件和通知实际上是对外部命令的脚本化调用，如check_http和mail，事件处理程序也可以配置为每次主机或服务状态变化时执行指定的命令。这可以用于补充记录状态变化数据，或自动化地尝试解决问题，如重启远程服务器。我们还在第十章的设置冗余监控主机部分中看到事件处理程序的使用。

最后，本章还包括了安装程序和对一些流行的 Nagios Core 扩展的讨论：

Nagiosgraph：这是一个先进的基于 Web 的图表解决方案，用于 Nagios Core，能够绘制服务器性能、主机和服务状态的指标。
NagVis：这是一个高级的基于 Web 的可视化扩展，适用于 Nagios Core 数据，尤其适合那些需要比 Nagios Core 内置网络映射更全面功能的管理员。
NDOUtils：该工具将 Nagios Core 数据转换为标准数据库系统，如 MySQL；对于执行 Nagios Core 数据的高级查询非常有用，适用于定制系统，如监控显示或与变更控制系统的日志记录。

我们将通过两个单独的步骤来讨论 NDOUtils，它可能是所有 Nagios Core 扩展中最通用的；首先展示如何安装它，然后提供一些如何应用它的想法，创建我们自己的自定义 Nagios Core 报告应用程序，形式为用Perl编写的CLI 报告和用PHP编写的RSS 订阅。

允许并提交被动检查

在本步骤中，我们将学习如何配置 Nagios Core 接受服务的被动检查。这允许用户和外部应用程序直接向 Nagios Core 提交检查结果，而不是让应用程序通过插件（如 check_http 或 check_ping）执行轮询来主动获取结果。

我们将展示一个简单的被动检查示例，标记一个名为 BACKUP 的服务，该服务对应于现有主机。我们将展示如何通过 Web 界面操作，这非常简单，并通过外部命令文件操作，虽然稍微复杂一些，但更加灵活且易于自动化。

这个想法是，当用户或进程确认主机上的备份过程已正确完成时，他们能够直接向服务提供 OK 检查结果，而不需要 Nagios Core 自己进行轮询。

准备工作

你应该运行 Nagios Core 3.0 或更新版本的服务器。你还应该已经配置了一个主机，在该主机上你希望定义一个接受被动检查的服务。在这个示例中，我们将使用主机 ithaca.naginet，它可能如下所示：

define host {
    use        linux-server
    host_name  ithaca.naginet
    alias      ithaca
    address    10.128.0.21
}

你还需要一个工作的 Nagios Core Web 界面，以检查被动检查是否已启用，并尝试使用此步骤中的方法提交被动检查。

本步骤将分为两部分：仅启用并配置服务以接受被动检查，以及通过 Web 界面实际提交被动检查。在更多内容...部分，我们将展示如何通过外部命令文件提交检查结果，尽管这有点复杂，但它支持高级自动化行为。

如何操作...

我们可以定义一个只接受被动检查的新 BACKUP 服务，如下所示：

登录到 Web 界面，确保已启用被动检查。在战术概览部分，底部附近会有一个面板显示相关信息。检查它是否为绿色：

如果它不是绿色，你应该能够通过点击禁用栏再次启用检查。在这种情况下，你还应检查 /usr/local/nagios/etc/nagios.cfg 文件，确保 accept_passive_service_checks 选项设置为 1，以便 Nagios Core 在启动时允许被动检查。
切换到 Nagios Core 的 objects 配置目录。如果你使用的是示例配置，这通常会是 /usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```
编辑 commands.cfg 文件，并为 check_dummy 命令添加定义：
```
define command {
    command_name  check_dummy
    command_line  $USER1$/check_dummy $ARG1$ $ARG2$
}
```
如果你已经按照第八章中监控集群中的各个节点的教程操作过，那么你可能已经定义了这个命令，在这种情况下，你可以跳过此步骤，因为定义是相同的。
编辑包含现有主机定义的文件。在此示例中，主机定义在名为ithaca.naginet.cfg的文件中。
```
# vi ithaca.naginet.cfg
```

在文件末尾添加以下服务定义，替换host_name为适当的值。

define service {
    use                     generic-service
    host_name               ithaca.naginet
    service_description     BACKUP
 active_checks_enabled   0
 passive_checks_enabled  1
 check_command           check_dummy!1!"Unwanted active check!"
}

这个示例使用了generic-service模板。你可以使用任何你喜欢的服务模板；重要的指令是active_checks_enabled、passive_checks_enabled和check_command。

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，Nagios Core 网页界面应显示该服务仅接受被动检查，具体在服务列表中：

它将保持在PENDING状态，直到为其提交了被动检查结果。

我们可以通过网页界面提交被动检查结果，具体步骤如下：

点击服务列表中的服务名称，然后点击提交该服务的被动检查结果菜单项：
完成结果表单，输入以下值：
- 主机名：这是应该提交被动检查结果的主机名。这个信息应该已经为我们填写好。
- 服务：这是应该提交被动检查结果的服务描述。这个信息也应该已经填写为BACKUP。
- 检查结果：这是你希望为检查提交的特定结果。在本例中，我们选择OK来表示备份成功完成。如果需要，我们也可以选择提交CRITICAL结果。
- 检查输出：这是附加到状态的消息。在本例中，我们选择简单的消息夜间备份成功。
- 性能数据：这是关于被检查服务执行情况的可选额外细节。我们可以留空此项。
点击提交以提交被动检查结果：

稍等片刻后，服务的详细信息应显示反映被动检查结果，并明确显示已禁用主动检查：

它的工作原理...

前面一节中添加的配置将一个名为BACKUP的新服务添加到现有的ithaca.naginet主机，并旨在管理和报告该主机的备份状态。在我们的示例中，这不是 Nagios Core 可以手动检查的内容；ithaca.naginet上没有任何网络服务可以检查备份是否成功。

然而，假设作为管理员，我们每天早晨的确会收到一个备份报告，这样我们就能知道备份是成功还是失败，并希望将该状态注册到 Nagios Core，可能是为了记录存档或提醒其他管理员出现问题。

为此，我们禁用该服务的主动检查，并设置一个虚拟检查命令 check_dummy，我们不希望它运行。如果由于某种原因运行了主动检查，它将始终标记为 WARNING 状态，消息为 不需要的主动检查！。check_dummy 命令实际上不会检查任何内容，它被配置为始终返回其两个参数定义的状态和输出。

相反，我们为该服务启用被动检查并手动提交结果。如果备份失败，我们也可以轻松地记录一个 WARNING 或 CRITICAL 的被动检查结果。

还有更多内容...

也可以（并且通常是理想的）通过外部命令文件提交主动检查，这对于自动化非常有用。我们将检查的详细信息以单行格式写入命令文件，如下所示：

[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<service_description>;<service_status>;<plugin_output>

对于我们的示例，这一行类似于以下代码片段：

[1348806599] PROCESS_SERVICE_CHECK_RESULT;ithaca.naginet;BACKUP;0;Nightly backups were successful

我们可以如下所示直接将其写入外部命令文件：

# CHECK="[`date +%s`] PROCESS_SERVICE_CHECK_RESULT;ithaca.naginet;BACKUP;0;Nightly backups were successful"
# echo $CHECK >>/usr/local/nagios/var/rw/nagios.cmd

在此情况下，<service_status> 字段需要是一个整数，表示相应的状态。如果使用文本值 OK 或 WARNING，命令将无法按预期工作。

0 表示 OK
1 表示 WARNING
2 表示 CRITICAL
3 表示 UNKNOWN

如果语法正确，那么被动检查将以与通过网页界面提交时相同的方式注册。因此，写入命令文件使我们能够通过脚本和自动化系统提交被动检查结果，只需了解合适的 Shell 脚本语言，如 Bash 或 Perl。

我们将更详细地讨论如何使用外部命令来获取被动检查结果，包括在本章的 通过 NSCA 从远程主机提交被动检查 配方中提到的与 NSCA 插件的常见应用。如果你不希望手动输入被动检查结果，那么你很可能会对这个配方感兴趣，并且它也包括了新鲜度检查的相关解释。

另见

本章中的 通过 NSCA 从远程主机提交被动检查、响应 SNMP trap 提交被动检查 和 设置事件处理脚本 配方

通过 NSCA 从远程主机提交被动检查

在本配方中，我们将展示如何通过远程主机自动提交被动检查，使用一个被监控主机 ithaca.naginet 提交其 BACKUP 服务性能的被动检查到 Nagios Core 服务器的例子。

例如，如果备份过程成功完成，我们会配置被监控主机提交一个被动检查结果，指定 BACKUP 服务的状态应该是 OK。然而，如果备份出现问题，被监控主机可以发送一个带有 WARNING 或 CRITICAL 状态的被动检查结果。

在这两种情况下，Nagios Core 不进行自己的检查；它信任目标主机提交的结果。

为了实现这一点，我们将使用 NSCA 插件。我们将在 Nagios Core 服务器上安装 NSCA 服务器，并在被监控的主机上安装 NSCA 客户端程序 send_nsca。

准备工作

你应该已经按照本章中的允许并提交被动检查教程进行操作。在本教程中，我们将基于该教程中建立的配置进行操作；具体来说，我们假设你已经有一个只接受被动检查的服务配置的主机。

你需要能够在监控服务器（NSCA 服务器）和将提交被动检查的服务器（NSCA 客户端）上安装软件，并且理想情况下，对在类 UNIX 系统上从源代码安装软件的./configure、make和make install过程有一般性的了解。

你还应该能够定义任何必要的防火墙配置，以允许 NSCA 客户端将信息发送到 NSCA 服务器上的 TCP 端口5667。防火墙对于保护nsca守护进程免受滥用是绝对必要的。

操作步骤...

我们可以在监控服务器（本例中为olympus.naginet）上设置 NSCA 服务器，如下所示：

使用 wget 或类似工具下载最新版本的 NSCA。你可以在 Nagios Exchange 页面找到 NSCA 的下载链接：exchange.nagios.org/directory/Addons/Passive-Checks/NSCA--2D-Nagios-Service-Check-Acceptor/details。

在这个例子中，我们将在监控服务器的主目录中下载并编译它。
```
$ cd
$ wget http://downloads.sourceforge.net/project/nagios/nsca-2.x/nsca-2.7.2/nsca-2.7.2.tar.gz
```
解压 .tar.gz 文件：
```
$ tar -xzf nsca-2.7.2.tar.gz
```
进入新的 nsca-2.7.2 目录，配置并编译 nsca 守护进程。请注意，此过程可能会提示你安装libmcrypt库及其头文件，这些文件可能在系统的软件包管理器中的libmcrypt和libmcrypt-dev包中：
```
$ cd nsca-2.7.2
$ ./configure
$ make
```

手动安装 NSCA 服务器文件；你可能需要 root 权限：

# cp src/nsca /usr/local/nagios/bin
# cp sample-config/nsca.cfg /usr/local/nagios/etc

编辑新文件 /usr/local/nagios/etc/nsca.cfg：
```
# vi /usr/local/nagios/etc/nsca.cfg
```
取消注释 password 指令，并定义它。使用像 pwgen 或 makepasswd 之类的工具生成的随机密码就可以。不要使用下面的密码，它只是一个示例！
```
password=yV3aa6S2o
```
检查 NSCA 守护进程是否正常运行且没有错误：
```
# /usr/local/nagios/bin/nsca -c /usr/local/nagios/etc/nsca.cfg --single
```
如果是这样，你应该将此命令添加到适当的启动脚本中，可能是在/etc/rc.local中，以便守护进程在监控服务器启动时启动。你应该查阅系统文档以找到添加此命令的最佳位置。

我们可以按如下方式在被监控的服务器（在此示例中为ithaca.naginet）上设置 NSCA 客户端：

同样，下载并解压最新版本的 NSCA，然后配置和编译它：

$ cd
$ wget http://downloads.sourceforge.net/project/nagios/nsca-2.x/nsca-2.7.2/nsca-2.7.2.tar.gz
$ tar -xzf nsca-2.7.2.tar.gz
$ cd nsca-2.7.2
$ ./configure
$ make

手动安装 NSCA 客户端文件；你可能需要root权限，并且可能需要提前创建/usr/local/bin和/usr/local/etc目录：
```
# mkdir -p /usr/local/bin /usr/local/etc
# cp src/send_nsca /usr/local/bin
# cp sample-config/send_nsca.cfg /usr/local/etc
```
编辑新文件/usr/local/etc/send_nsca.cfg：
```
# vi /usr/local/etc/send_nsca.cfg
```
取消注释password指令，并将其定义为与监控服务器上的nsca.cfg中给定的密码相同：
```
password=yV3aa6S2o
```
运行send_nsca程序，尝试提交一个被动检查结果：
```
# CHECK="ithaca.naginet\tBACKUP\t0\tBackup was successful, this check submitted by NSCA\n"
# echo -en $CHECK | send_nsca -c /usr/local/etc/send_nsca.cfg -H olympus.naginet
1 data packet(s) sent to host successfully.
```
用适当的主机名替换监控服务器（olympus.naginet）、被监控服务器（ithaca.naginet）和服务描述BACKUP。

请注意，字段之间由\t字符分隔，该字符通过echo -en扩展为字面上的Tab字符。

如果这工作正常，你应该看到被动检查结果已经成功通过 Web 界面读取，并被监控服务器正确应用：

它是如何工作的...

安装在监控服务器上的nsca守护进程旨在监听来自send_nsca客户端提交的服务检查，前提是密码正确且数据格式正确：

<host_name>\t<service_description>\t<check_result>\t<check_output>\n

我们的示例被动检查采用了以下形式：

ithaca.naginet\tBACKUP\t0\tBackup was successful, this check submitted by NSCA\n

在这里，就像本地提交的被动检查一样，check_result对应于一个数值，表示以下之一：

0表示OK
1表示WARNING
2表示CRITICAL
3表示UNKNOWN

一旦nsca守护进程在监控服务器上接收到此信息，它将转换为一个被动检查结果命令，写入 Nagios Core 的外部命令文件/usr/local/nagios/var/rw/nagios.cmd，并以与本地提交的被动检查相同的方式处理。

这使我们能够在脚本的末尾（例如管理备份的脚本）中包含对send_nsca的调用，以立即并自动发送与备份脚本是否成功对应的被动检查结果。

由于 NSCA 守护进程设计非常简单，并且安全检查也非常基础，因此需要应用防火墙策略，以确保只有适当的主机能够写入监控系统上的 NSCA 端口。此处实现的密码是一个好的第一步，但不足以确保安全。确保阅读 NSCA 源代码中包含的SECURITY文件，以确保守护进程的配置是安全的。类似的安全指南适用于 NRPE 的安装，详细内容请参见第六章。

还有更多内容...

为了补充此设置，通常一个好主意是让 Nagios Core 检查其服务的时效性。如果我们有一个需要定期运行的进程，例如备份，我们可能希望在特定时间内没有收到来自主机的被动检查时得到通知。

这可以通过配置服务，在一段时间内没有被动检查后运行主动检查来管理。配置可能类似于以下代码片段，添加check_freshness和freshness_threshold的值：

define service {
    use                     generic-service
    host_name               ithaca.naginet
    service_description     BACKUP
    active_checks_enabled   0
    passive_checks_enabled  1
 check_freshness         1
 freshness_threshold     86400
    check_command           check_dummy!1!"No backups have run for 24 hours"
}

在这种情况下，freshness_threshold为 86400 秒，即 24 小时；如果 24 小时内没有提交任何被动检查，则会运行check_command，即使主动检查被禁用。check_command的定义是，当它实际运行时，通过check_dummy命令和插件为该服务标记WARNING状态，并附上适当的解释信息。

有关检查新鲜度的更多信息，请参阅 Nagios Core 文档中的《服务和主机新鲜度检查》部分，地址是nagios.sourceforge.net/docs/3_0/freshness.html。

请注意，服务的状态不一定非要来自同一主机。你可以从一台主机发送被动检查，以提交关于另一台主机的信息。实际上，这正是分布式监控设置的基础；一台主机可以提交其他任何数量主机的检查结果。

这种方法对于解决网络连接或路由问题尤其有用；如果 Nagios Core 与需要监控的主机完全没有连接，但与一个中间主机有连接，可以配置该主机代表无法访问的主机提交检查，这是一种稍显复杂但常常必要的设置。

另请参阅。

本章中的允许并提交被动检查、响应 SNMP 陷阱提交被动检查和设置事件处理脚本的配方。
第二章中的使用替代检查命令配方，与命令和插件一起工作。

响应 SNMP 陷阱提交被动检查。

在本配方中，我们将学习如何配置 Nagios Core 来处理简单网络管理协议（SNMP）陷阱，这是由被监控的网络设备发送到中央监控服务器的信息。

因为 SNMP 陷阱通常包含有关主机工作状态的有用或紧急信息，至少以某种方式处理它们会非常有帮助，特别是对于那些无法使用send_nsca以标准形式提交被动检查结果的固件网络设备，如从远程主机使用 NSCA 提交被动检查配方中所述。

举个例子，大多数支持 SNMP 的主机可以配置为在其某个网络接口的状态变化时发送 SNMP 陷阱，可能是由于网络电缆被拔掉。这些被称为linkUp和linkDown陷阱。监控这种特定类型的陷阱对具有大量接口的设备特别有用，例如交换机或路由器。

在 Nagios Core 中跟踪这些事件对于保持统一的监控界面非常有价值，而不必使用单独的应用程序来监控 SNMP 陷阱。

准备工作

要使这个方法有效，首先有一些前提条件。它是 Nagios Core 监控中最强大但也是最复杂的方法之一。

首先，这个方法假设你有一定的 SNMP 知识。尽管 SNMP 的名字中有“简单”一词，但它实际上并不简单！你应该熟悉SNMP 检查和SNMP 陷阱的概念。Net-SNMP（本示例中使用的 SNMP 实现）的文档可能会有所帮助：www.net-snmp.org/docs/readmefiles.html。

在与 Nagios Core 服务器（版本 3.0 或更高版本）相同的主机上，你应该安装snmptrapd来收集trap信息，以及snmptt，即SNMP 陷阱翻译器，用于从陷阱中过滤出有用的信息，并以可操作的格式将信息提交给 Nagios Core。SNMPTT 的文档可在snmptt.sourceforge.net/docs/snmptt.shtml找到。

这两个系统都是免费软件并且相对流行，因此你可以检查一下是否有适用于你的系统的安装包，以免麻烦地从源代码进行编译。例如，在像 Ubuntu 这样的 Debian 衍生系统中，它们可以在snmpd和snmptt软件包中找到。

我们将使用一个名为submit_check_result的事件处理程序，它在 Nagios Core 发行版中可用。因此，你需要能够访问原始的源代码。如果你丢失了它们，可以从 Nagios 网站再次下载：www.nagios.org/download。

还需要确保你为主机使用的host_name值能够与监控服务器通过 DNS 解析的主机名相对应。这是因为当 SNMP 陷阱被 SNMPTT 接收时，它只能通过 DNS 将其转换为主机名。你的主机的host_name可能是crete.naginet，但陷阱将来自像10.128.0.27这样的 IP 地址。因此，系统需要能够通过反向 DNS 查找解析它。测试这个是否有效的一个简单方法是使用host或dig：

$ host 10.128.0.27
27.0.128.10.in-addr.arpa domain name pointer crete.naginet.
$ dig -x 10.128.0.27 +short
crete.naginet.

最后，你当然需要有一个已配置的设备，将 SNMP 陷阱发送到你的监控服务器，而监控服务器则配置为通过snmpd守护进程来监听 SNMP 陷阱。我并不想鼓励你拔掉一个核心交换机来测试这个，所以我们将通过在被监控的服务器上手动生成一个陷阱，使用snmptrap来演示这个原理。

如何操作……

我们可以按照以下步骤为现有主机配置一个新的服务，以接收 SNMP 陷阱：

将事件处理脚本 contrib/eventhandlers/submit_check_result 从 Nagios Core 源文件复制到 /usr/local/nagios/libexec/eventhandlers。你可能需要先创建目标目录。你的源文件不一定要放在 /usr/local/src/nagios，这只是一个示例。
```
# mkdir -p /usr/local/nagios/libexec/eventhandlers
# cp /usr/local/src/nagios/contrib/eventhandlers/submit_check_result /usr/local/nagios/libexec/eventhandlers
```
此脚本应设置为可执行，执行用户为 snmptrapd 用户。
切换到监控服务器上的 Nagios Core objects 配置目录。默认配置的路径是 /usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```
编辑包含 SNMP 启用监控主机定义的文件。在此示例中，crete.naginet 的定义在其独立的文件 crete.naginet.cfg 中：
```
# vi crete.naginet.cfg
```
主机定义可能类似于以下代码片段：
```
define host {
    use        linux-server
    host_name  crete.naginet
    alias      crete
    address    10.128.0.21
}
```

为现有主机添加一个仅接受被动检查并标记为 volatile 的服务定义。在此，我们使用了示例配置中包含的 generic-service 模板。你也可以使用其他模板，但此处定义的所有值都很重要。

define service {
    use                     generic-service
    host_name               crete.naginet
    service_description     TRAP
 is_volatile             1
    check_command           check-host-alive
 active_checks_enabled   0
 passive_checks_enabled  1
    max_check_attempts      1
    contact_groups          admins
}

验证配置并重启 Nagios Core 服务器：
```
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart
```
在 Web 界面中，当前该服务应显示在 Services 部分：
通过在监控服务器上使用测试字符串调用 submit_check_result 脚本，检查它是否正常工作：
```
# /usr/local/nagios/libexec/eventhandlers/submit_check_result crete.naginet TRAP 0 "Everything working"
```
如果一切正常，经过短暂的延迟后，我们应该能看到 Web 界面中的服务状态发生变化，反映测试结果：

接下来，我们需要配置 snmptrapd 和 snmpd 来接收陷阱，并为我们调用 submit_check_result 脚本：

配置 snmpd 通过修改其配置文件 /etc/snmp/snmptrapd.conf 来将接收到的陷阱传递给 snmptt。以下配置可能有效：
```
traphandle default /usr/sbin/snmptt
disableAuthorization yes
donotlogtraps yes
```
重启 snmpd 以应用此更改：
```
# /etc/init.d/snmpd restart
```
配置 snmptt 将 IP 地址转换为主机名，在 /etc/snmp/snmptt.ini 中将 dns-enable 的值更改为 1：
```
dns_enable = 1
```
配置 snmptt 在启动时使用 Net-SNMP，方法是在 /etc/snmp/snmptt.ini 中设置：
```
net_snmp_perl_enable = 1
```

配置 snmptt 响应 SNMP 事件，在 /etc/snmp/snmptt.conf 中进行定义。这里我们使用了 OID .1.3.t6.1.6.3.1.1.5.3 定义的通用 linkDown 事件：

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" Normal
FORMAT Link down on interface $1\.  Admin state: $2\.  Operational state: $3
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 1 "linkDown for interface $1"
SDESC
A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state).  This other state is indicated by the included value
of ifOperStatus.
EDESC

根据你的发行版，可能已经定义了一个 linkDown 事件，在这种情况下，你可能只需要更改 EXEC 字段。

从监控主机发送一个 linkDown 事件的测试陷阱。将 olympus.naginet 替换为你的监控主机的名称或 IP 地址。这需要在该主机上安装 snmptrap 工具，并可能需要 root 权限。
```
# snmptrap -v 1 -c public olympus.naginet .1.3.6.1.6.3.1.1.5.3 localhost 2 0 '' .1.3.6.1.2.1.2.2.1.1.1 i 1
```
请注意，我们在此使用的是 public 社区字符串；你自己的可能会不同。

检查位于 /usr/local/nagios/var/nagios.log 的 Nagios Core 日志文件，查看事件处理器是否有新的输出：

[1348914096] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;crete.naginet;TRAP;1;linkDown for interface 1
[1348914100] PASSIVE SERVICE CHECK: crete.naginet;TRAP;1;linkDown for interface 1
[1348914100] SERVICE ALERT: crete.naginet;TRAP;WARNING;HARD;3;linkDown for interface 1
[1348914100] SERVICE NOTIFICATION: nagiosadmin;crete.naginet;TRAP;WARNING;notify-service-by-email;linkDown for interface 1

如果是这样，TRAP 服务的相同状态应该在 Web 界面中反映出来：

完成这一步后，我们已经确认来自crete.naginet主机的 SNMP 陷阱能够被olympus.naginet服务器接收并处理。我们可以通过将其他在网络中生成 SNMP 陷阱的主机配置为将其陷阱发送到 Nagios Core 监控服务器，并为预期的陷阱添加适当的处理程序，应用相同的设置。

如果这不起作用，首先要检查的是监控服务器是否实际上在相关的 IP 地址上监听检查请求，因为snmptrap在无法传送陷阱时不会抛出错误。在基于 Debian 的系统上，你应该检查snmptrapd进程是否实际在运行；可能需要修改/etc/defaults/snmp文件并重启snmpd。

它是如何工作的...

当一个 SNMP 陷阱生成并通过任意方式传送到监控服务器时，snmpd守护进程将它传递给snmptt程序进行处理。

snmptt处理程序检查事件 OID 是否与其在snmptt.conf中定义的任何陷阱匹配。在我们的示例中，它找到一个为 OID.1.3.6.1.6.3.1.1.5.3定义的处理器，它对应于linkDown事件，相关接口的编号作为额外参数$1。

使用这些信息，它会触发我们在教程第一部分安装的submit_check_result处理程序，将TRAP服务的状态设置为WARNING，并将linkDown信息（对于接口1）包含在submit_check_result的最终参数中，如EXEC处理程序所指定。服务可以设置为通知适当的联系人或联系人组，就像它监控一个主动监控的服务一样。

如果一个陷阱到达 Nagios Core 服务器，而 Nagios Core 并不认识该主机，即使它已经为snmptt定义了事件处理器，它也会忽略该陷阱。

还有更多内容...

为了“清除”服务的状态并将其恢复为OK，我们可以简单地通过 Web 界面调度一个主动检查，选择强制检查：

因为check_command定义为check-host-alive，只要监控主机实际响应PING，服务应该处于OK状态：

另见

本章中的从远程主机提交被动检查使用 NSCA、允许并提交被动检查和设置事件处理器脚本教程
第五章中的监控 SNMP 查询的输出和创建一个 SNMP OID 进行监控教程，监控方法

设置事件处理器脚本

在这个教程中，我们将学习如何为 Nagios Core 设置事件处理脚本。事件处理器是在每次主机或服务状态变化时执行的命令（无论是对所有主机或服务，还是仅对特定的主机或服务）。它们的定义方式与通知命令和插件的检查命令类似。

在这个示例中，我们将实现一个简单的事件处理程序，将日期、主机状态和检查尝试次数写入单个主机的单独文件。这是一个简单的示例，用于演示该概念；关于事件处理程序更实用和复杂的应用程序，参考第十章中的设置冗余监控主机示例。

准备工作

你需要一台运行 Nagios Core 3.0 或更高版本的服务器。你应该熟悉如何定义新命令，具体可参考第二章中的创建新命令示例和第四章中的写入低优先级通知到 MOTD示例，配置通知部分。

如何操作...

我们可以按如下方式为 Nagios Core 服务器设置一个新的事件处理程序：

切换到 Nagios Core 的objects配置目录。在快速启动指南安装中，该目录为/usr/local/nagios/etc/objects。编辑文件commands.cfg：
```
# cd /usr/local/nagios/etc/objects
# vi commands.cfg
```

添加以下命令定义：

define command {
    command_name    record_host_data
    command_line    /usr/bin/printf "%b" "$LONGDATETIME$: $HOSTSTATE$ (attempt $HOSTATTEMPT$)\n" >>/usr/local/nagios/var/states-$HOSTNAME$.log
}

编辑包含现有主机定义的文件，在此示例中为delphi.naginet。将event_handler指令与值record_host_data添加到你的主机定义中：

define host {
    use            linux-server
    host_name      delphi.naginet
    alias          delphi
    address        10.128.0.26
 event_handler  record_host_data
}

验证配置并重启 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成后，下次主机状态发生变化（无论是SOFT还是HARD状态），它应该会将信息记录在/usr/local/nagios/var/states-delphi.naginet.log文件中：

Sat Sept 29 23:53:54 NZST 2012: DOWN (attempt 1)
Sat Sept 29 23:54:04 NZST 2012: DOWN (attempt 2)
Sat Sept 29 23:54:14 NZST 2012: DOWN (attempt 3)
Sat Sept 29 23:57:14 NZST 2012: UP (attempt 1)

它是如何工作的...

我们定义的event_handler命令配置为使用printf将一行文本写入一个以主机名命名的文件。其定义由四个宏组成：

$LONGDATETIME$ ：这指定了日期和时间，采用易读的格式
$HOSTSTATE$ ：这指定了主机的状态（UP、DOWN或UNREACHABLE）
$HOSTATTEMPT$ ：这指定了在问题状态下，已对主机进行的检查尝试次数
$HOSTNAME$ ：这是主机名本身（用于构建文件名）

请注意，这种行为与通知略有不同。通知命令仅在主机或服务的max_check_attempts次数被超出时运行，用于警告问题。而事件处理程序则在SOFT和HARD状态变更时都运行，因此可以用来记录主机性能的更多信息，这些信息可能会被常规通知忽略。

服务事件处理程序可以通过向其定义中添加event_handler指令来以相同的方式定义：

define service {
    use                  generic-service
    host_name            crete.naginet
    service_description  PING
    check_command        check_ping!100,10%!200,20%
 event_handler        record_service_data
}

在这种情况下，我们可能希望使用服务状态的宏：

define command {
    command_name    record_service_data
    command_line    /usr/bin/printf "%b" "$LONGDATETIME$: $SERVICESTATE$ (attempt $SERVICEATTEMPT$)\n" >>/usr/local/nagios/var/states-$HOSTNAME$-$SERVICEDESC$.log
}

还有更多...

作为快捷方式，如果我们想在所有主机或所有服务上运行事件处理程序，可以在nagios.cfg中使用global_host_event_handler和global_service_event_handler指令：

global_host_event_handler=record_host_data
global_service_event_handler=record_service_data

这将为所有主机和服务应用适当的事件处理器，因此每当主机或服务状态发生变化时，都会运行。

还可以使用 Nagios Core 的性能数据功能，作为记录插件和检查的详细性能数据的事件处理器的专门案例，手册中有相关文档，网址为：nagios.sourceforge.net/docs/3_0/perfdata.html。

性能数据在每次检查时都会被写入，而不是在每次状态变化时写入，因此它对于评估插件和检查的性能非常有用。例如，Nagiosgraph 工具会使用性能数据，详见本章中的使用 Nagiosgraph 跟踪主机和服务状态食谱。

另请参见

本章中的使用 Nagiosgraph 跟踪主机和服务状态食谱
第二章中的创建新命令食谱，与命令和插件配合使用
第四章中的将低优先级通知写入 MOTD食谱，配置通知

使用 Nagiosgraph 跟踪主机和服务状态

在本食谱中，我们将学习如何安装和配置 Nagiosgraph，这个程序与 Nagios Core 的性能数据工具集成，生成显示有关主机和服务检查长期表现的图表。

准备工作

你需要运行 Nagios Core 3.0 或更高版本的服务器。Nagiosgraph 可能仍然可以与旧版本的 Nagios Core 一起工作，但配置可能会有所不同。源代码中包含的 INSTALL 文档详细解释了这些差异。

你应该对定义主机、服务和命令有透彻的理解，并能够以 root 用户身份在监控服务器上安装新软件。你还应该至少熟悉监控系统中 Apache HTTPD 服务器的布局；本食谱假设它安装在 /usr/local/apache。

由于 Nagiosgraph 依赖于许多 Perl 库，你需要在服务器上安装 Perl，并且可能还需要安装一些 Perl 模块作为依赖项。你的系统包管理器可能包含它们，或者你可能需要通过综合 Perl 存档网络（CPAN）下载它们：www.cpan.org/modules/INSTALL.html。

服务器需要已监控至少一个主机和至少一个服务，图表才会有用。Nagiosgraph 包含规则集，可以将已知的性能数据字符串转换为可用的统计信息。这意味着，对于输出格式可预测的熟悉插件，如 check_ping 或 check_http，图表生成将运行得很好，但对于较少使用的插件，可能需要进行一些自定义配置才能生成图表。

本食谱并不是对 Nagiosgraph 所有功能的全面概述；如果你喜欢这个功能，确保查看 Nagiosgraph 的在线文档：nagiosgraph.sourceforge.net/。

如何操作...

我们可以为监控服务器获取一些基本的 Nagiosgraph 功能，方法如下：

从其网站nagiosgraph.sourceforge.net/下载最新版的 Nagiosgraph，直接使用wget等工具下载到您的监控服务器：
```
$ cd
$ wget http://downloads.sourceforge.net/project/nagiosgraph/nagiosgraph/1.4.4/nagiosgraph-1.4.4.tar.gz
```

解压.tar.gz文件并切换到其中的目录：

$ tar -xzf nagiosgraph-1.4.4.tar.gz
$ cd nagiosgraph-1.4.4

以root用户身份运行install.pl脚本，并使用--check-prereq选项。这将为您提供一个依赖项的调查，您可能需要通过软件包或 CPAN 安装它们。当您安装完所有先决条件后，输出应该类似于以下代码片段：
```
# ./install.pl --check-prereq
checking required PERL modules
 Carp...1.11
 CGI...3.43
 Data::Dumper...2.124
 File::Basename...2.77
 File::Find...1.14
 MIME::Base64...3.08
 POSIX...1.17
 RRDs...1.4003
 Time::HiRes...1.9719
checking optional PERL modules
 GD...2.39
checking nagios installation
 found nagios at /usr/local/nagios/bin/nagios
checking web server installation
 found apache at /usr/sbin/apache2
```
这些都是比较标准的 Perl 库，因此在使用 CPAN 之前，不要忘记检查是否有可用的相关软件包。例如，我在我的 Debian 系统上能够按照以下方式安装 RRDs 和 GD 模块：
```
# apt-get install librrds-perl libgd-gd2-perl
```
如果在运行install.pl时无法找到 Nagios Core 或 Apache HTTPD 实例，可以查看install.pl --help的输出，以运行适合您系统类型的安装程序。有关详细信息，请参阅INSTALL文件。

以root用户身份运行install.pl脚本，并使用--install参数。安装过程中会多次提示您选择目录布局选项。默认选项以方括号显示，对于典型的 Nagios Core 安装应该是正确的，因此开始时只需在每个选项上按Enter键即可。

# ./install.pl --install
...Destination directory (prefix)? [/usr/local/nagiosgraph]
Location of configuration files (etc-dir)? [/usr/local/nagiosgraph/etc]
Location of executables? [/usr/local/nagiosgraph/bin]
Location of CGI scripts? [/usr/local/nagiosgraph/cgi]
Location of documentation (doc-dir)? [/usr/local/nagiosgraph/doc]
Location of examples? [/usr/local/nagiosgraph/examples]
Location of CSS and JavaScript files? [/usr/local/nagiosgraph/share]
Location of utilities? [/usr/local/nagiosgraph/util]
Location of state files (var-dir)? [/usr/local/nagiosgraph/var]
Location of RRD files? [/usr/local/nagiosgraph/var/rrd]
Location of log files (log-dir)? [/usr/local/nagiosgraph/var]
Path of log file? [/usr/local/nagiosgraph/var/nagiosgraph.log]
Path of CGI log file? [/usr/local/nagiosgraph/var/nagiosgraph-cgi.log]
URL of CGI scripts? [/nagiosgraph/cgi-bin]
URL of CSS file? [/nagiosgraph/nagiosgraph.css]
URL of JavaScript file? [/nagiosgraph/nagiosgraph.js]
Path of Nagios performance data file? [/tmp/perfdata.log]
URL of Nagios CGI scripts? [/nagios/cgi-bin]
username or userid of Nagios user? [nagios]
username or userid of web server user? [www-data]
Modify the Nagios configuration? [n]
Modify the Apache configuration? [n]
...

在完成上述选择后，文件应已安装并设置了适当的权限。输出的最后部分提供了将配置添加到 Nagios Core 和 Apache HTTPD 的说明，接下来我们将进行这些操作。

切换到 Nagios Core 的配置目录。在快速入门指南安装中，该目录为/usr/local/nagios/etc。
```
# cd /usr/local/nagios/etc
```

编辑核心配置文件nagios.cfg，并在文件末尾添加以下指令：

# process nagios performance data using nagiosgraph
process_performance_data=1
service_perfdata_file=/tmp/perfdata.log
service_perfdata_file_template=$LASTSERVICECHECK$||$HOSTNAME$||$SERVICEDESC$||$SERVICEOUTPUT$||$SERVICEPERFDATA$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=30
service_perfdata_file_processing_command=process-service-perfdata-for-nagiosgraph

切换到 Nagios Core 的objects配置目录。在快速入门指南安装中，该目录为/usr/local/nagios/etc/objects。
```
# cd /usr/local/nagios/etc/objects
```

编辑commands.cfg文件，添加以下命令定义：

# command to process nagios performance data for nagiosgraph
define command {
 command_name process-service-perfdata-for-nagiosgraph
 command_line /usr/local/nagiosgraph/bin/insert.pl
}

编辑 Apache HTTPD 服务器的httpd.conf文件，在文件末尾添加以下行：
```
Include /usr/local/nagiosgraph/etc/nagiosgraph-apache.conf
```
在 Apache HTTPD 的本地安装中，该文件通常位于/usr/local/apache/conf/httpd.conf，但其位置因系统而异。在 Debian 衍生的系统中，它可能位于/etc/apache2/apache2.conf。

验证 Apache HTTPD 服务器和 Nagios Core 服务器的配置，并重新启动这两个服务：

# /usr/local/apache/bin/apachectl configtest
# /usr/local/apache/bin/apachectl restart
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

在浏览器中访问olympus.naginet/nagiosgraph/cgi-bin/showconfig.cgi，将你的 Nagios Core 服务器的主机名替换其中，测试一切是否正常工作。你应该看到一个包含 Nagiosgraph 配置的长页面：
如果到此为止一切正常，剩下的就是为你想要生成图表的服务定义一个操作 URL，这样你就可以从 Nagios Core Web 界面点击直接跳转到该服务的图表。

最整洁且最直接的做法是定义一个服务模板：
```
define service {
    name        nagiosgraph
    action_url  /nagiosgraph/cgi-bin/show.cgi?host=$HOSTNAME$&service=$SERVICEDESC$
    register    0
}
```
然后，你可以通过将nagiosgraph添加到use指令的值中，使你想要生成图表的服务继承它以及它们所使用的其他模板。
```
define service {
 use                   generic-service,nagiosgraph
    host_name             corinth.naginet
    service_description   PING
    check_command         check_ping!100,10%!200,20%
}
```
你应该对所有需要生成图表的服务执行此操作。

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，访问 Web 界面的服务部分，应该会在每个已生成图表的服务后面看到操作图标：

点击其中一个应该会弹出一个图表界面；例如，使用check_ping的服务可能会显示类似以下截图的内容：

请注意，它包含两条线条以显示CRITICAL和WARNING状态的阈值，以及实际响应时间。同样请注意，前面的图表是几天前的；需要一段时间来积累足够的数据，以便看到明显的线条，直到 Nagiosgraph 从 Nagios 接收到性能数据之前，你可能看不到任何图表。

别忘了，图表不会对每个服务开箱即用。如果 Nagiosgraph 无法解析某个检查的性能数据，它会显示红色错误文本，而不是图表。我们将在更多内容...部分提到修复这个问题的方法。

它是如何工作的...

前面部分的配置更改会促使 Nagios Core 记录每个服务每次检查的性能数据，使用service_perfdata_file_processing_command指令。这个命令名为process-service-perfdata-for-nagiosgraph，其定义是将数据传递给新/usr/local/nagiosgraph目录中包含的bin/insert.pl脚本。

这个脚本进一步解析性能输出，比如以下来自使用check_ping的典型服务的输出：

PING OK - Packet loss = 0%, RTA = 174.19 ms

Nagiosgraph 根据在/usr/local/nagiosgraph/etc/map中定义的模板，使用 Perl 正则表达式从性能数据中提取数值信息。这些数据使用 Perl 的 RRD 库绑定记录，并使用 GD2 库生成图表，外观类似于 MRTG 生成的图表。

action_url 指令使用宏为每个服务定义一个 URL，显示其图形。在我们的示例中，对于主机 corinth.naginet 上的服务 PING，action_url 会展开为以下内容：

action_url  /nagiosgraph/cgi-bin/show.cgi?host=corinth.naginet&service=PING

当然，action_url 不仅仅有这种用法；它恰好在我们这种情况下非常有用。你可以让 action_url 定向到你希望的任何地方，用于指定的主机或服务。

还有更多...

如果你不打算为服务定义其他操作，可能希望将 action.gif 图像更改为比默认的红色污点更具描述性的内容。Nagiosgraph 源文件中包含了一个可能的替代图标，但你可以使用任何你想要的 GIF 图像。

# cp nagiosgraph-1.4.4/share/graph.gif /usr/local/nagios/share/images/action.gif

你可能正在运行某种 Nagiosgraph 无法绘制的检查，因为它无法理解性能输出的格式，也无法从中提取数值信息。默认的映射规则涵盖了许多标准插件的输出，但如果你对 Perl 有一定了解，你可能能够向 /usr/local/nagiosgraph/etc/map 中添加更多规则，以处理其他类型的插件输出。

除了映射文件中的示例外（包括编写新输出检查的说明），/usr/local/nagiosgraph/examples/map_examples 文件中还包含了更多此类定义的示例。

如果你在比较 Nagios 的图形解决方案，另一个值得尝试的流行解决方案是 PNP4Nagios，可在 docs.pnp4nagios.org/pnp-0.6/start 获取。

另见

本章中的使用 NagVis 获取额外可视化效果配方
第十章中的使用 Nagiostats 监控 Nagios 性能配方，安全与性能

使用 NDOUtils 将状态读入 MySQL 数据库

在本配方中，我们将学习如何安装 NDOUtils 扩展到 Nagios Core，以便将 Nagios Core 的所有配置和数据写入 MySQL 数据库。这使得使用 Perl 和 PHP 等语言及其与流行的 MySQL 服务器的标准接口，轻松开发定制的报告和界面，而不必与 Nagios Core 的日志或其数据格式交互。一些插件，如 NagVis，使用这种格式来读取有关 Nagios Core 配置和对象的信息。

准备工作

你需要一个版本为 3.0 或更高的 Nagios Core 服务器。NDOUtils 可能仍然可以在旧版本的 Nagios Core 上安装并正常工作，但安装过程略有不同；有关此信息，请参见 NDO 源中的 INSTALL 文件。

Nagios Core 使用其事件代理功能将信息写入 MySQL 数据库的套接字中。你需要使用 --enable-event-broker 标志编译 Nagios Core：

$ ./configure --enable-event-broker
$ make
# make install

如果你不确定是否使用此标志进行编译，最好重新编译并重新安装包含此标志的原始 Nagios Core 源代码。别忘了备份之前的安装，以防出现问题。

为了编译 NDOUtils 的 ndomod 部分，你需要在 Nagios Core 服务器上安装 MySQL 客户端库和头文件。你还需要准备一个 MySQL 服务器来存储数据。MySQL 服务器不必与 Nagios Core 运行在同一主机上，但 Nagios Core 服务器应能够连接到它。

最后，你应该注意 README 的开头段落，本文写作时指出 NDOUtils for Nagios Core 3.0 仍处于正式的 Beta 阶段；你应该阅读该备注并了解安装时的风险。然而，凭我的经验，代码非常稳定。目前写作时也没有保证此过程能够在未发布的 Nagios 4.0 上正确运行。

如何操作...

我们可以按照以下方式为 Nagios Core 安装 NDOUtils 包：

从其 Sourceforge 网站下载最新的 NDOUtils .tar.gz 文件：sourceforge.net/projects/nagios/files/ndoutils-1.x/。
```
$ wget http://downloads.sourceforge.net/project/nagios/ndoutils-1.x/ndoutils-1.5.2/ndoutils-1.5.2.tar.gz
```

解压 .tar.gz 文件并切换到该目录。

$ tar -xzf ndoutils-1.5.2.tar.gz
$ cd ndoutils-1.5.2

运行 ./configure 并构建软件。请注意，安装目标不存在；我们将手动执行安装。
```
$ ./configure
$ make
```

如果构建失败，请仔细查看 ./configure 的输出，以确定系统上是否缺少任何依赖项。./configure 的输出应以类似以下代码片段的内容结束：

*** Configuration summary for ndoutils 1.5.2 06-08-2012 ***:
General Options:
-------------------------
NDO2DB user:    nagios
NDO2DB group:   nagios
Review the options above for accuracy.  If they look okay,
type 'make' to compile the NDO utilities.

在 MySQL 服务器上，创建一个数据库来存储 Nagios Core 信息，并创建一个用户来访问它。在此示例中，MySQL 服务器与 Nagios Core 服务器运行在同一主机（olympus.naginet）上，因此访问将来自 localhost。
```
mysql> CREATE DATABASE nagios;
Query OK, 1 row affected (0.10 sec)
mysql> CREATE USER 'ndo'@'localhost' IDENTIFIED BY 'mPYxbAYqa';
Query OK, 0 rows affected (0.62 sec)
mysql> GRANT ALL ON nagios.* TO 'ndo'@'localhost';
Query OK, 0 rows affected (0.02 sec)
```
我们在 IDENTIFIED BY 后使用了一个随机密码。你应该生成自己安全的密码。

在源码目录中运行 installdb 脚本来创建 Nagios Core 将使用的各种数据库表。使用前一步骤中设置的数据库详细信息：

$ cd db
$ ./installdb -u ndo -p mPYxbAYqa -h localhost -d nagios
** Creating tables for version 1.5.2
 Using mysql.sql for installation...
** Updating table nagios_dbversion
Done!

不用担心以下错误消息；这是因为你是第一次安装此扩展：

DBD::mysql::db do failed: Table 'nagios.nagios_dbversion' doesn't exist at ./installdb line 51.

将编译后的 ndomod 模块复制到 /usr/local/nagios/bin 目录：
```
# cd ..
# cp src/ndomod-3x.o /usr/local/nagios/bin/ndomod.o
```
将模块的示例配置文件复制到 /usr/local/nagios/etc 目录：
```
# cp config/ndomod.cfg-sample /usr/local/nagios/etc/ndomod.cfg
```

确保该文件仅对 nagios 用户可读：

# chown nagios.nagios /usr/local/nagios/etc/ndomod.cfg
# chmod 0600 /usr/local/nagios/etc/ndomod.cfg

编辑你的 nagios.cfg 文件：
```
# vi /usr/local/nagios/etc/nagios.cfg
```
向文件中添加 broker_module 定义，并检查 event_broker_options 指令是否设置为 -1：
```
broker_module=/usr/local/nagios/bin/ndomod.o config_file=/usr/local/nagios/etc/ndomod.cfg
event_broker_options=-1
```
请注意，broker_module 和 config_file 定义应位于同一行，但 event_broker_options 应单独占一行。

完成此操作后，代理模块应该已成功安装，我们可以继续安装 ndo2db 守护进程。
将 ndo2db 二进制文件复制到 /usr/local/nagios/bin 目录：
```
# cp src/ndo2db-3x /usr/local/nagios/bin/ndo2db
```

将守护进程的示例配置复制到/usr/local/nagios/etc：

# cp config/ndo2db.cfg-sample /usr/local/nagios/etc/ndo2db.cfg

确保仅由nagios用户可读：

# chown nagios.nagios /usr/local/nagios/etc/ndo2db.cfg
# chmod 0600 /usr/local/nagios/etc/ndo2db.cfg

编辑安装的配置文件：
```
# vi /usr/local/nagios/etc/ndo2db.cfg
```

更改ndo2db.cfg中的值以反映数据库详细信息：

db_host=localhost
db_port=3306
db_name=nagios
db_user=ndo
db_pass=mPYxbAYqa

通过启动ndo2db守护进程并使用ps -e或pgrep验证它是否正在运行来测试：
```
# /usr/local/nagios/bin/ndo2db -c /usr/local/nagios/etc/ndo2db.cfg
# ps -e | grep '[n]do2db'
32285 ? 00:00:00 ndo2db
# pgrep ndo2db
32285
```
如果工作正常，应将此命令添加到系统的init脚本中，以便在启动时启动守护进程。

验证配置并重新启动 Nagios Core 服务器：

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

完成此操作后，应检查 MySQL 中的数据库表，以查看它们是否已被填充来自 Nagios Core 的信息，例如nagios_services表：

$ mysql --user=ndo --password --database=nagios
mysql> select count(1) from nagios_services;
+----------+
| count(1) |
+----------+
|       54 |
+----------+
1 row in set (0.00 sec)

工作原理...

实际上，NDOUtils 是一个组件集，其中两个我们在前面的章节中安装了：

ndomod被用作代理模块，将 Nagios Core 的事件和数据写入到位于/usr/local/nagios/var/ndo.sock中的 UNIX 套接字。它作为 Nagios Core 服务器的模块运行。
ndo2db被用作数据库后端，用于从ndomod写入的 UNIX 套接字中读取事件和数据，并将它们作为 MySQL 数据库操作应用。它作为系统上的守护进程独立运行，并执行 MySQL 连接和事务。

broker_module在运行插件时更新这些表，主机和服务更改状态，发出通知以及其他 Nagios Core 行为发生。它相当全面地涵盖了大多数感兴趣的数据。请注意，它包括：

配置指令
Nagios Core 对象类型的详细信息
主机的属性和当前状态
承认和计划的停机信息
通知历史和完整日志记录

安装 NDOUtils 的主要原因是将 Nagios Core 的数据放入标准化格式中，以便外部应用程序读取和处理，无论是简单的表格样式报告还是全新的应用程序界面，访问 Nagios Core 数据。这通常比自定义构建自己的 Nagios Core CGI 要容易得多！

还有更多...

本章中的另一个示例，编写定制的 Nagios Core 报告，在安装 NDOUtils 后应用它，演示了一些用于从其表中检索有用数据和总结的示例 MySQL 查询，包括在 Perl 中编写报告的示例，以及 PHP 中的简单 RSS 订阅。

要充分利用 NDOUtils，建议查看其文档，其中包括 MySQL 表内容的完整介绍：nagios.sourceforge.net/docs/ndoutils/NDOUtils.pdf。

参见

本章中的编写定制的 Nagios Core 报告和使用 NagVis 获取额外的可视化的示例

编写定制的 Nagios Core 报告

在本示例中，我们将尝试一些简单的 NDOUtils 数据库应用，通过尝试一些查询，将其中一个转换为 Perl 中的简单报告，并且还转换为基于 PHP 的 RSS 订阅。

准备工作

本食谱假设你已经安装了 NDOUtils，并且你的 Nagios Core 3.0（或更高版本）服务器至少正在监控一些主机和服务，以便我们尝试的查询能够实际返回一些数据。你还应该有执行 MySQL 查询的工具。mysql命令行客户端将完全适用；像 phpMyAdmin 这样的工具可能会让数据更易于探索。

如何操作...

我们可以针对 NDOUtils 数据库进行如下查询：

获取最新十条通知的内容和日期/时间：

mysql> SELECT start_time, long_output FROM nagios_notifications ORDER BY start_time DESC LIMIT 10;

获取最新十条主机或服务评论的内容和日期/时间：

mysql> SELECT entry_time, comment_data FROM nagios_commenthistory ORDER BY entry_time DESC LIMIT 10;

统计当前处于OK状态的主机数量：

mysql> SELECT COUNT(1) FROM nagios_hoststatus WHERE current_state = 0;

获取当前在计划停机中的所有主机的名称：

mysql> SELECT display_name FROM nagios_hosts JOIN nagios_hoststatus USING (host_object_id) WHERE scheduled_downtime_depth > 0;

请注意，此查询的语法假设 MySQL 版本至少为 5.0.12。

返回所有主机名称及其相关服务数量的列表：

mysql> SELECT nagios_hosts.display_name, COUNT(service_id) FROM nagios_hosts LEFT JOIN nagios_services ON nagios_hosts.host_object_id = nagios_services.host_object_id GROUP BY nagios_hosts.host_object_id;

我们可以实现一个 Perl 脚本，使用 DBI 模块打印最新的十条通知，代码如下：

#!/usr/bin/env perl

# Enforce Perl best practices
use strict;
use warnings;

# Import database modules
use DBI;
use DBD::mysql;

# Get connection to database
my $nagios = DBI->connect(
    'dbi:mysql:dbname=nagios;host=localhost',
    'ndo',
    'mPYxbAYqa'
) or die "Could not connect to database";

# Define an SQL query to run
my $query = q{
    SELECT
        notification_id, start_time, name1, long_output
    FROM
        nagios_notifications
    JOIN
        nagios_objects USING (object_id)
    ORDER BY
        start_time DESC
    LIMIT
        10
};

# Execute query and retrieve notifications
my $notifications = $nagios->selectall_hashref(
    $query,
    'notification_id'
) or die 'Could not retrieve notifications';

# Print each notification
foreach my $id (keys %{$notifications}) {
    my $notification = $notifications->{$id};
    printf {*STDOUT} "%s - %s: %s\n",
        $notification->{start_time},
        $notification->{name1},
        $notification->{long_output};
}

# Exit successfully
exit 0;

将其保存为文件latest-notifications.pl，然后我们可以如下运行：

$ chmod +x latest-notifications.pl
$ ./latest-notifications.pl
2012-10-06 10:11:27 - blog: PING OK - Packet loss = 0%, RTA = 160.31 ms
2012-10-06 10:48:17 - athens: PING OK - Packet loss = 0%, RTA = 155.82 ms
2012-10-06 14:08:17 - athens: PING WARNING - Packet loss = 16%, RTA = 171.79 ms
2012-10-06 14:13:17 - athens: PING OK - Packet loss = 0%, RTA = 164.39 ms
2012-10-06 10:56:17 - athens: PING CRITICAL - Packet loss = 28%, RTA = 164.65 ms
2012-10-06 10:38:17 - athens: PING CRITICAL - Packet loss = 28%, RTA = 166.10 ms
2012-10-06 10:06:27 - blog: PING WARNING - Packet loss = 16%, RTA = 163.72 ms
2012-10-06 13:39:27 - blog: PING WARNING - Packet loss = 16%, RTA = 163.78 ms
2012-10-06 13:44:27 - blog: PING OK - Packet loss = 0%, RTA = 167.10 ms
2012-10-06 13:29:27 - blog: PING CRITICAL - Packet loss = 28%, RTA = 159.55 ms

同样，我们可以使用 PHP5 和 PDO MySQL 实现一个简单的 RSS 通知源，代码如下：

<?php
// Get connection to database
$nagios = new PDO(
    'mysql:host=localhost;dbname=nagios',
    'ndo',
    'mPYxbAYqa'
);
// Define an SQL query to run
$query = '
    SELECT
        start_time, name1, long_output
    FROM
        nagios_notifications
    JOIN
        nagios_objects
    USING
        (object_id)
    ORDER BY
        start_time DESC
    LIMIT
        10
';
// Retrieve all the notifications as objects
$statement = $nagios->prepare($query);
$statement->setFetchMode(PDO::FETCH_OBJ);
$statement->execute();
// Read the notifications into an array
for ($notifications = array(); $notification = $statement->fetch(); ) {
    $notifications[] = $notification;
}
// Send an RSS header rather than an HTML one
header("Content-Type: application/rss+xml; charset=utf-8");
echo '<?xml version="1.0" encoding="UTF-8"?>';
?>
<rss version="2.0">
    <channel>
        <title>
            Latest Nagios Core Notifications
        </title>
        <link>
            http://olympus.naginet/nagios/
        </link>
        <description>
            The ten most recent notifications from Nagios Core
        </description>
<? foreach ($notifications as $notification): ?>
        <item>
            <description>
                <?= htmlspecialchars($notification->name1); ?>: <?= htmlspecialchars($notification->long_output) ?>
            </description>
            <pubDate>
                <?= htmlspecialchars(date('r', strtotime($notification->start_time))) ?>
            </pubDate>
        </item>
<? endforeach; ?>
    </channel>
</rss>

将其保存为名为latest-notifications.php的文件，我们可以在我们最喜欢的 RSS 阅读器中订阅此内容，例如Life rea (liferea.sourceforge.net/)：

它是如何工作的...

上一节中给出的示例仅用于让你开始编写非常简单的报告；在 NDOUtils 数据库中有大量数据可以供你探索。以下是一些其他的可能性：

按名称排序的系统中所有主机及其状态的详细信息，以 HTML 表格的形式呈现
列出一个月内停机超过一次的所有主机
所有主机的正常运行时间百分比

另见

本章中的将读取状态保存到 MySQL 数据库中使用 NDOUtils和使用 NagVis 获取额外的可视化效果食谱

使用 NagVis 获取额外的可视化效果

在本食谱中，我们将探讨如何超越第八章中讨论的默认网络地图，通过扩展 NagVis 来获得更多的可视化功能。NagVis 可以使用 NDOUtils 后端来构建各种风格的自定义地图。

NagVis 如果你有兴趣更广泛地可视化 Nagios 数据，它最有可能对你有用，特别是如果你遇到包含的 Nagios Core 状态地图的可扩展性问题。默认的状态地图适用于小型网络，但在渲染更大的网络时可能会出现延迟。

对 NagVis 功能的完整概述不可能在一个食谱中涵盖，但这个食谱将带你完成下载、安装和配置扩展的过程，提供一个简单的自动地图，让你入门。

准备工作

你应该有一个正在运行的 Nagios Core 服务器，版本为 3.0 或更高，并且已经成功安装 NDOUtils 后端，并正在填充一个 MySQL 数据库，你具有管理员访问权限。这个过程在本章的 使用 NDOUtils 将状态读取到 MySQL 数据库 章节中进行了讨论。

为了使自动地图功能更有用，你需要一个至少具有一些父子关系的网络——有关如何创建网络主机层次结构的详细信息，请参见第八章中的 创建网络主机层次结构 章节。

NagVis 包含一个安装脚本，可以很好地处理不同系统上 Nagios Core 的安装。然而，它仍然需要某些依赖项，特别是：

在与 Nagios Core 同一台服务器上使用 Apache 和 mod_php
PHP 5.3 或更高版本，并且需要以下模块：gd、gettext、mbstring、mysql、pdo、session、sqlite 和 xml
Graphviz 图形可视化软件，包含以下模块：circo、dot、fdp、neato、twopi
SQLite 3

你可能需要查阅系统文档来安装所有这些依赖项；如果系统有软件包管理器，检查一下它。对于 Ubuntu 和其他 Debian 派生的系统，通常以下软件包就足够了：

# apt-get install apache2 libapache2-mod-php5 libgd2-xpm libgd2-xpm-dev php5 php5-gd php5-mysql php5-sqlite graphviz sqlite3

在像 CentOS 和 Fedora 这样的系统上，以下软件包可能有效：

# yum install php php-gd php-gettext php-mbstring php-mysql php-pdo php-sqlite php-xml graphviz graphviz-gd graphviz-php

很难预料所有系统所需的确切软件包；在软件包管理器中搜索关键词（例如 php sqlite）可能会有所帮助。

如何操作...

我们可以按如下方式安装带有 NDO 后端的 NagVis：

从 www.nagvis.org/downloads 下载最新的 NagVis 源代码：

$ wget http://downloads.sourceforge.net/project/nagvis/NagVis1.7/nagvis-1.7.1.tar.gz

解压 .tar.gz 文件并进入该目录：

$ tar -xzf nagvis-1.7.1.tar.gz
$ cd nagvis-1.7.1

以 root 用户身份运行 install.sh 脚本：
```
# ./install.sh
```
脚本将尝试查找你的 Nagios Core 安装，并会要求你指定新 NagVis 文件的安装位置。在我们的例子中，默认设置是正确且可以接受的，因此我们可以直接按 Enter。
```
-- Checking paths --
Please enter the path to the nagios base directory [/usr/local/nagios]:
 nagios path /usr/local/nagios  found
Please enter the path to NagVis base [/usr/local/nagvis]:
```

脚本将尝试查找所有需要的前提条件，并会在找不到时提醒你。如果是这种情况，你应该按 Ctrl + C 中止安装，并在重新尝试之前先安装这些前提条件。

-- Checking prerequisites --
PHP 5.3                                  found
 PHP Module: gd 5.3                     found
 PHP Module: mbstring compiled_in       found
 PHP Module: gettext compiled_in        found
 PHP Module: session compiled_in        found
 PHP Module: xml compiled_in            found
 PHP Module: pdo compiled_in            found
 Apache mod_php                         found
Graphviz 2.26                            found
 Graphviz Module dot 2.26.3             found
 Graphviz Module neato 2.26.3           found
 Graphviz Module twopi 2.26.3           found
 Graphviz Module circo 2.26.3           found
 Graphviz Module fdp 2.26.3             found
SQLite 3.7                               found

脚本将提示你选择一个合适的后端作为 NagVis 的数据源进行配置。在这个示例中，我们只需要选择 ndo2db 后端，按 n 键跳过其他选项。

-- Checking Backends. (Available: mklivestatus,ndo2db,ido2db,merlinmy) --
Do you want to use backend mklivestatus? [y]: n
Do you want to use backend ndo2db? [n]: y
Do you want to use backend ido2db? [n]: n
Do you want to use backend merlinmy? [n]: n
 /usr/local/nagios/bin/ndo2db (ndo2db)  found

脚本将尝试检测你的 Apache HTTPD 设置。它在大多数系统上表现良好，但在按 Enter 键之前，你应该检查结果是否正确。允许它为你创建 Apache 配置文件也应该是安全的。

-- Trying to detect Apache settings --
Please enter the web path to NagVis [/nagvis]:
Please enter the name of the web-server user [www-data]:
Please enter the name of the web-server group [www-data]:
create Apache config file [y]:

脚本将给出关于安装软件的意图的总结，并要求你确认。通过按 Enter 键确认：

-- Summary --
NagVis home will be:           /usr/local/nagvis
Owner of NagVis files will be: www-data
Group of NagVis files will be: www-data
Path to Apache config dir is:  /etc/apache2/conf.d
Apache config will be created: yes
Installation mode:             install
Do you really want to continue? [y]:

重启 Apache HTTPD 服务器：

# apache2ctl configtest
# apache2ctl restart

如果以上操作都正确，安装完成后，您应该能够访问 NagVis 配置页面：olympus.naginet/nagvis/，并将主机名替换为您自己的 Nagios Core 服务器：

您可以使用默认用户名admin和密码admin登录，查看一些演示地图。

在我们使自动地图工作之前，还有一些步骤要完成：

在服务器上编辑/usr/local/nagvis/etc/nagvis.ini.php文件：
```
# vi /usr/local/nagvis/etc/nagvis.ini.php
```

查找并更改backend_ndomy_1部分中的以下指令，添加您在ndo2db安装中使用的值：

; hostname for NDO-db
dbhost="localhost"
; portname for NDO-db
dbport=3306
; database name for NDO-db
dbname="nagios"
; username for NDO-db
dbuser="ndo"
; password for NDO-db
dbpass="mPYxbAYqa"
; prefix for tables in NDO-db
dbprefix="nagios_"
; instance name for tables in NDO-db
dbinstancename="default"

确保所有前面的值没有被注释掉（即它们前面不应有分号）。

登录到 NagVis Web 界面，并在选项菜单下点击管理地图：
在创建地图下：
1. 对于地图名称，输入Automap。
2. 对于地图图标集，选择std_small。
3. 将背景留空。
4. 点击创建。
页面应该刷新并显示一个空白屏幕，因为我们还没有为地图选择数据源。
在编辑地图菜单下点击地图选项。
在弹出的对话框中：
1. 勾选sources复选框，并将值更改为automap。
2. 勾选backend_id复选框，并选择值ndomy_1。
3. 向下滚动到页面底部并点击保存。

完成这些操作后，页面应刷新并展示您的网络地图，该地图将根据您的配置自动生成，样式与 Nagios Core Web 界面状态地图相似。您还应能够悬停在单个节点上查看其详细信息。

它是如何工作的...

NagVis 的自动地图是从我们在 NDOUtils 教程中建立的数据库中的数据生成的。它生成地图的方式与默认状态地图类似，但对于较大的网络更具可扩展性。配置中定义的父子关系将被包含，以创建树状地图。

还有更多内容...

使用 NagVis 本身可以填充整本书，而自动地图只是许多可能地图中的一个，包括定义自己的背景、图标、标签和悬停行为。欲了解如何制作定制地图以及其他样式的自动地图的更多细节，请参考 NagVis 文档：www.nagvis.org/doc。

另见

本章中的将状态读取到 MySQL 数据库与 NDOUtils和编写定制的 Nagios Core 报告教程
第八章中的创建网络主机层级和使用网络地图教程，理解网络布局

posted @ 2025-07-05 19:50 绝不原创的飞龙阅读(20) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Nagios-核心管理秘籍-全-

Nagios 核心管理秘籍（全）

前言

本书内容概述

本书所需的内容

本书适合谁阅读

约定

读者反馈

客户支持

下载示例代码

勘误

盗版

问题

第一章：理解主机、服务和联系人

引言

创建一个新的网络主机

准备工作

如何操作...

它是如何工作的...

还有更多...

另见

创建新的 HTTP 服务

准备工作

操作步骤...

工作原理...

还有更多...

参见

创建一个新的电子邮件联系人

准备工作

如何操作...

如何操作...

还有更多……

参见

验证配置

准备就绪

怎么做……

它是如何工作的...

还有更多...

另请参见

创建一个新的主机组

准备工作

如何操作...

它是如何工作的...

还有更多...

另见

创建一个新的服务组

准备工作

如何操作...

如何工作...

还有更多...

另见

创建一个新的联系人组

准备工作

如何操作...

它是如何工作的...

还有更多...

另请参见

创建新的时间段

准备工作

如何操作...

它是如何工作的...

还有更多...

另请参见

在组内所有主机上运行服务

准备工作

如何操作...

它是如何工作的...

还有更多...

另见

第二章：使用命令和插件

介绍

查找插件

准备工作

如何操作...

它是如何工作的...

还有更多...

另请参见

安装插件