以前我们使用nagios和nagiosql进行手动设置,对于少数服务器来说非常舒服.
最近服务器的数量发生了变化,nagiosql的手动配置变得不舒服.我们使用厨师开始新的实例,我想知道是否有良好的做法,一起使用厨师和nagios.作为一个选项,我们每次启动新实例时都可以使用nagios并重写nagios的配置文件(基于服务器角色).
例如,场景可能是这样的,启动新的mysql服务器,有一个专门的配方重写nagios设置文件.食谱可以从厨师数据包中获取有关每个服务器的所有数据,并根据厨师中的角色构建设置.
在过去的18个月里,我使用Chef为Nagios监控实施了三种略有不同的解决方案.它们都基于Chef的模板资源,用于使用ERB语法生成配置文件,并且该位运行得非常好.您有一个 Ruby数组或主机和服务的哈希,并生成Nagios配置文件.它非常容易测试和调试.>完全基于数据包的配置.在这种情况下,有一个nagios_hosts和一个nagios_services数据包,每个主机都有一个密钥,说明运行哪些服务检查,例如check_load,check_disk.这种设置很快就能开始并且工作得相当好,但是如果删除主机或添加新主机,则必须有人来更新数据包.在实践中很容易忘记这一点,事情可能会过时,这可能会导致麻烦.
> Chef基于属性的配置.在这里,我使用Chef REST API查询一个或多个Chef服务器,以下拉节点列表,并根据分配的角色为它们分配服务检查.对Chef的依赖意味着很难监视非Chef系统,例如设备,网络设备或因任何原因不运行Chef的节点. Chef最终通过网络为大量节点发送大量JSON数据,处理所有这些数据会在Chef服务器和Nagios服务器生成配置文件时加载.
> Rails应用程序生成Nagios配置文件.我最终通过在数据库中存储Nagios配置信息并让Rails应用程序生成配置文件来打破Chef依赖性.每个Nagios服务器发出一个REST请求并下载使用ERB和MySQL数据库生成的配置文件.要实现这一目标需要相当多的工作,但到目前为止它仍然适用于监控Chef和非Chef节点.
因此,在完成所有这些之后,我可能会建议使用类似#2的选项来处理小型(数十到数百个)节点.我会尽量保持简单.我使用Chef的属性系统来定义和覆盖基于角色的服务检查的阈值,当它工作时,它太复杂了,而且菜谱最终变成了一个难以维护的混乱.
祝好运！