2.4　通知

如果用户没有配置过通知，那么Nagios会在每次状态改变为确定状态时发送一次通知，或者当主机或服务处于问题状态足够长的时间时发送后续通知。在多种对象的定义中，有很多选项能够对通知是否发出产生影响，这导致我们很难清楚地记住所有的通知逻辑。通知框架强大而灵活的功能是Nagios赠送给大多数系统管理员的一份惊喜的礼物，但是因为其可配置性过强，常常会被新手们误解。

我发现对于通知逻辑的介绍是引入大量基础概念的一个重要方式，如果读者能够明白Nagios通知的工作机制，就能明白Nagios中的很多内容。我将从最上层开始剖析，对通知选项可配置的多种级别进行介绍，并指出这种方式中一些潜在的“陷阱”。

2.4.1　全局陷阱

Nagios，如同在它之前的无数个UNIX程序一样，都可以通过文本文件的方式进行配置。所以，通常文本文件中的定义将决定Nagios运行的状态。但是，某些配置可以被Nagios运行时修改，所以无法通过配置文件中的某些特定设置反映出Nagios正在干什么。一个关键的示例就是启用全局通知（enable notification）的设置。这个选项能够在程序范围内启用或禁用通知功能，可能是运行时可以修改的最危险的配置选项。

该选项相当重要，因为用户可以将Nagios配置为持久程序状态，所以读者需要注意到通知开启的实际状态。这就是说，当Nagios关闭后，它会将当前运行配置状态写入到一个文件中，当重新启动时，会直接读取之前保存的状态并启动。当Nagios启用保留状态信息选项（retain_state_information）以持久化程序状态的方式启动后，将会使用状态文件中的设置覆写配置文件中的设置。这意味着虽然我们在配置文件中启用了通知选项，但是Nagios运行时将其设置为禁用，那么这个设置就会持久保留，无论应用程序重启或者某人查看了配置确定通知是启用的—其实，通知是关闭的。

以后读者如果遇到了通知问题，一定要先检查NagiosGUI中的CGI程序“战术概览”（Tactical Overview），以确保通知功能是全局启用的。如果读者感觉重启Nagios能够解决问题，那么确保关闭保留程序状态信息选项，或者在重新启动Nagios前删除状态文件。在Nagios运行的时候删除状态文件没什么效果，因为Nagios将会在关闭前写一份新文件。所以先关闭，然后删除，最后再启动。

2.4.2　通知选项

不论主机还是服务，都有很多选项能够影响Nagios通知的具体行为。首先要注意的是通知选项的设置。在每个主机或服务的配置中，可以设置对Nagios跟踪的哪些状态发送（或者不发送）通知。主机和服务的状态略有区别，因为现实中主机和服务就有所不同。表2-2总结了主机和服务的所有状态。

表2-2　主机和服务的通知状态

Nagios创造了术语“振荡”用于描述服务状态不稳定、在正常和故障状态来回切换的情况。读者可以配置Nagios，从而实现将服务振荡作为通知的条件，但因为服务振荡可能导致很多不必要的通知，所以默认是关闭的。读者在设置通知选项时，需要列出希望Nagios发送通知的条件。比如希望CPU在严重而非警告时通知，那么应当设置通知选项为c。如果读者想要在服务从故障状态恢复时接收通知，那么应当明确列出r，其他情况依此类推。

除了在主机和服务定义中需要设置通知选项外，联系人定义中也需要设置通知选项。联系人定义用来描述Nagios发送通知的对象。除了联系人姓名和邮件地址这样显而易见的选项外，每一个联系人定义还需要设置主机和服务通知选项。在这些选项的共同作用下，能够实现对特定联系人发送通知类型的过滤作用。比如，某个程序员可能希望接收由他负责的应用程序的问题通知，但是他不希望在恢复时接收通知，因为他知道问题什么时候修复—其实，他就是参与问题修复工作的一员。

2.4.3　模板

通常，在定义时还有一个潜在陷阱，这就是模板定义的概念。为了方便对大量对象的定义，读者可以通过Nagios创建通用的定义，该定义通常包含了特定类型系统的共有选项设置。Web服务器可能都有通用的通知联系人和阈值，比如，当为Web服务器创建服务定义时，可以先建立名为web-servers的通用服务定义，然后在其他的服务定义中引用它。通过这种方式，只需要定义阈值和通知联系人一次，而无须在每个服务中都定义。这些通用定义称作模板，使用这种方式能够节省大量的文字输入。

服务定义中显示定义的选项会覆盖所引用模板中设置的选项。但是，当继承了从模板中设置的通知选项，在服务定义中就不能直接看出服务状态通知的设置。我通常显式设置通知选项，建议各位读者也这样操作。在处理Nagios的配置时，通常大家的做法是复制、粘贴，如果定义没有显式设置通知选项，那么就应当了解所继承的模板内容并注意其中的通知选项设置。关于模板的更多信息详见第4章。

2.4.4　时间段

在配置设置中，会影响Nagios通知行为的还有时间段（time period）。与Nagios的其他参数一样，时间段也可以由用户定义，其用途是指定时间区间，如周一～周五，早上9点～下午6点，在服务和主机定义中将会引用时间段的信息，从而推导出操作时间。服务定义中通过两种方式引用时间段：通知时段定义了Nagios可以发送服务通知的时间区间，检测时段定义了Nagios调度服务检测的时间区间。

Nagios不仅仅是一套监控系统，同时也是一套信息收集程序。Nagios可以收集监控对象的利用率及状态信息，并将这些信息发送到其他程序中进行图形化展示或数据挖掘。如对CPU利用率这样的服务，在24×7的时段内收集收据是没有问题的，但是用户不一定想在相同的时段内接收通知，因为诸如备份这类CPU密集的工作，通常都会在深夜发生。上述的案例能够很好地说明用户如何区分对通知时段和检测时段的设置。

如果服务检测结果超出了阈值，而且不在上述两个时间段内，那么Nagios不会发送通知。如果超出阈值时在通知时段之外，那么Nagios将只会跟踪其状态，由正常到待定错误再到确定错误，但不会发送通知，因为用户明确告知它不在通知时段之外发送通知。相反的，如果超出阈值时不在检测时段之内，那么Nagios也不会注意到，因为用户明确告知它该时段不调度服务检测。如同其他服务定义中的选项一样，如果没有显式设置，时间段也可以从模板继承，所以需要注意从模板中继承的时间段，否则将会在通知上遇到问题。

和通知选项的设置相同，时间段也需要以逐个联系人的方式进行配置，尽管阈值超出的事件发生在服务定义中的时段内，联系人的配置也有可能将这个通知过滤掉。

2.4.5　计划宕机时间、状态确认以及升级规则

还有一些变量会对Nagios通知决定产生影响，它们就是升级规则（Escalation）、状态确认（Acknowledgement）以及计划宕机时间（Scheduled Downtime）。如果计划对一台或多台主机开展维护工作，就要在Naiogs的Web界面上为主机设置计划宕机时间。如果某台主机正处于计划宕机时间段内，Nagios将会按照正常的方式调度检测，并持续跟踪主机的状态，但是不会发送该主机及其服务的任何通知。进一步来说，Nagios在多个Web报表中会对实际宕机时间和计划宕机时间进行区分。

升级规则的存在是为了提供一种通知途径—在主机或服务故障太长时间时，通知额外的联系人。比如，如果服务器1宕机，用户可能希望Nagios通知管理员，但是当服务器1宕机7个小时时，用户就可能需要通知管理员及经理。升级规则是独立定义的，所以它们不是服务定义的一部分。当Nagios认为是时候发送通知时，它首先会检查以确保没有升级规则符合当前通知。如果Nagios发现有匹配的升级规则，则会按照升级规则发送通知，并替代原始的通知。

各位读者需要认识到，Nagios要么按照服务定义发送通知，要么按照升级规则发送通知。通常情况下这种方式没什么问题，因为升级规则和服务中定义的通知是等价的，除非升级规则中定义了一些额外的联系人。读者们可以使用升级规则定义完全不同的联系人以及通知命令。如果读者想让系统管理员和经理都能够收到通知，那么就要确保升级规则中不仅包含原有通知中的系统管理员，还要包含经理。

状态确认主要是在修复故障过程中，抑制重复发生的后续通知消息。如果配置了升级，那么在进行状态确认时就相当于告诉Nagios，我们已经知道并正在处理故障，所以无须继续并通知经理。状态确认可以通过Nagios的Web界面发送，确认同时还会有一个选填的注释信息。当发送了状态确认之后，Nagios会将问题已被确认及确认人的信息通知给原始收件人列表中的人。之后，Nagios将会禁用后续的通知直到服务状态恢复至正常。