介绍
状态“跟踪”是大多数用户可能不会使用的功能。启用后，即使主机或服务的状态没有更改，它也可以记录输出服务和主机检查中的更改。为特定主机或服务启用跟踪功能后，Nagios Core将非常仔细地监视该主机或服务，并记录检查结果输出中看到的任何更改。如您所见，它在以后分析日志文件时对您很有帮助。
它是如何工作的？
在正常情况下，仅在主机或服务自上次检查以来已更改状态时才记录主机或服务的检查结果。对此有一些例外，但是在大多数情况下，这是规则。
如果您对特定主机或服务的一个或多个状态启用跟踪功能，则Nagios Core将记录该主机或服务检查的结果，如果该检查的输出与先前检查的输出不同。采取以下对服务进行八次连续检查的示例：
| 服务检查编号： | 服务状态： | 服务检查输出： | 正常记录 | 跟踪记录 |
|---|---|---|---|---|
| X | 好 | RAID阵列最佳 | — | — |
| +1 | 好 | RAID阵列最佳 | — | — |
| x + 2 | 警告 | RAID阵列降级（1个驱动器损坏，1个热备用重建） | 是 | 是 |
| x + 3 | 危急 | RAID阵列降级（2个驱动器损坏，1个主机备用在线，1个热备用重建） | 是 | 是 |
| x + 4 | 危急 | RAID阵列降级（3个驱动器损坏，2个热备用在线） | — | 是 |
| x + 5 | 危急 | RAID阵列发生故障 | — | 是 |
| x + 6 | 危急 | RAID阵列发生故障 | — | — |
| x + 7 | 危急 | RAID阵列发生故障 | — | — |
按照这种检查顺序，您通常只会看到两个针对此灾难的日志条目。当服务从OK状态更改为WARNING状态时，第一个将在服务检查x + 2处发生。当服务从“警告”状态更改为“严重”状态时，第二条日志条目将出现在服务检查x + 3处。
无论出于何种原因，您都可能希望在日志文件中包含此灾难的完整历史记录。也许可以帮助您向经理解释情况很快变得失控的原因，也许只是在当地一家酒吧喝了几杯后就笑了起来。
好吧，如果您已为CRITICAL状态启用了跟踪此服务的功能，则除了记录x + 2和x + 3的事件外，还将记录x + 4和x + 5的事件。为什么是这样？启用状态跟踪后，Nagios Core将检查每个服务检查的输出，以查看其是否与前一个检查的输出不同。如果两次检查之间的输出不同且服务的状态未更改，则将记录更新的服务检查的结果。
跟踪的类似示例可能位于检查您的Web服务器的服务上。如果check_http插件由于404错误而首先返回警告状态，而在随后的检查中由于未找到特定模式而返回警告状态，则您可能想知道这一点。如果您没有为服务的警告状态启用状态跟踪功能，那么只会记录第一个警告状态事件（404错误），并且您不会（将来在存档日志中回头）有任何想法要知道将来的警告状态不是由于404，而是由于某些文本模式在返回的网页中找不到。
我应该启用跟踪功能吗？
首先，您必须确定是否确实需要分析存档的日志数据以找到问题的确切原因。您可能会决定某些主机或服务需要此功能，但并非全部都需要。您可能还会发现只需要为某些主机或服务状态而不是所有状态启用跟踪功能。例如，您可能决定对服务的“警告”和“关键”状态启用跟踪功能，但对“正常”和“未知”状态启用跟踪功能。
对特定主机或服务启用状态跟踪的决定还取决于您用来检查该主机或服务的插件。如果插件始终为特定状态返回相同的文本输出，则没有理由为该状态启用跟踪功能。
如何启用跟踪？
您可以使用主机和服务定义中的stalking_options指令为主机和服务启用状态跟踪。
跟踪与易失性服务服务有何不同？
易失性服务与跟踪雷士，但是将导致通知和事件处理程序运行。跟踪纯粹是处于记录目的。
通知跟踪
Nagios Core 4.4.0 上有基于通知特别跟踪选项N。定义此特殊选项后，每次发出通知时，都会记录事件状态。这意味着，如果每隔1个小时收到一次通知，并且设置了此选项，则当主机或服务的通知失效时，您将每小时看到一次记录的事件状态。
注意事项
您应该意识到，启用跟踪可能会带来一些潜在的问题。这些都与各种CGI中的报告功能（直方图，警报摘要等）有关。由于状态跟踪将导致记录其他警报条目，因此报告生成的数据将显示警报数量膨胀的证据。
作为一般规则，我建议您在未仔细考虑的情况下不要对主机和服务启用跟踪。不过，如果您需要并想要它，它就会在那里。
