Icinga或Nagiosconfiguration中的服务定义可以具有名为max_attempts或max_check_attempts参数。
文档将max_attempts描述为：
如果您将服务定义的max_attempts选项configuration为大于1，Icinga将在确定存在真实问题之前重新检查该服务。 当服务正在被重新检查时（达到max_attempts次），它被认为处于“软”状态（如这里所描述的），并且服务检查按照由retry_interval选项确定的频率重新计划。
如果Icinga重新检查服务max_attempts时间并且它仍然处于非正常状态，Icinga会将服务置于“硬”状态，向联系人发送通知（如果适用），并开始重新计划将来的服务检查频率由check_interval选项确定。
和max_check_attempts一样：
当一个服务首先从一个OK状态改变到一个非OK状态时，Icinga使你能够暂时减慢或加速后续的服务检查将发生的时间间隔。 当服务第一次改变状态时，Icinga在决定它真正的问题之前将执行服务检查的max_check_attempts-1重试。 服务正在重试时，将根据retry_interval选项进行调度，该选项可能比正常的check_interval选项更快或更慢。 当服务正在重新检查（最多max_check_attempts-1次），服务处于软状态。 如果服务重新检查max_check_attempts-1次，并且它仍处于非正常状态，则服务将变为硬状态，并且随后将按照check_interval选项指定的正常速率重新安排时间。
在附注中，它指定max_check_attempts选项的值为1，该服务将不会按retry_interval选项指定的时间间隔进行检查。 相反，它会立即变成硬状态，并随后按照check_interval选项指定的速率重新安排。
这些对我来说听起来是一样的。 他们之间有什么区别，什么时候应该使用？
max_attempts是服务和主机的旧定义，它不再用于nagios Core 4.请参阅以了解您的对象的可能定义： 对象定义
随着Icinga2
# icinga2 -V icinga2 - The Icinga 2 network monitoring daemon (version: r2.6.3-1)
在服务中使用max_attempts会触发一个错误：
服务声明：
object Service "Intel(R) 82574L Gigabit Network Connection" { import "generic-service" host_name = "server" check_command = "check_netint" vars.interface = "Intel(R) 82574L Gigabit Network Connection" vars.warning= "650000" vars.critical ="800000" max_attempts=1 }
configuration检查：
# service icinga2 checkconfig [....] checking Icinga2 configuration information/cli: Icinga application loader (version: r2.6.3-1) information/cli: Loading configuration file(s). information/ConfigItem: Committing config item(s). critical/config: Error: Attribute 'max_attempts' does not exist. Location: in /etc/icinga2/conf.d/1.conf: 32:3-32:16 /etc/icinga2/conf.d/1.conf(30): vars.warning= "650000" /etc/icinga2/conf.d/1.conf(31): vars.critical ="800000" /etc/icinga2/conf.d/1.conf(32): max_attempts=1 ^^^^^^^^^^^^^^ /etc/icinga2/conf.d/1.conf(33): } /etc/icinga2/conf.d/1.conf(34): /* critical/config: 1 error [FAIL] checking Icinga2 configuration. Check '/var/log/icinga2/startup.log' for details. ... failed!