从Nagios迁移到Icinga2

Question

我需要将Nagios实例迁移到Icinga2，该实例具有大量被监视的节点和服务。我发现了以下文档：http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#migration

它没有提到是否有自动方法将Nagios的所有配置转换为Icinga2配置格式。它说的是如何手动操作。是否有人使用自动配置转换将Nagios迁移到Icinga2。或者任何以不那么痛苦的方式这样做的建议。

谢谢

Answer 1

如果您不打算寻找相似性或模式，那么现在也是评估不同配置方法的好时机。然后重新开始。

我已经看到许多Nagios/Icinga1安装随着时间的推移而增长，而不是“修复”问题，你只需要复制一个现有的checkcommand，给它一个新的名称，并使用它。或者死于没有人为之编写文档的对象技巧的地狱。有时，由于内核中的bug，这样的配置也会“工作”。其中一些已经在Icinga1.x中修复，但我知道Nagios Core中的一些在构建配置时仍然相当烦人。

事实证明，如果您在当前环境中使用笔、纸和绘图板，您将了解现有的瓶颈或触发检查的新方法。示例:不关心VM上的加载和交换吗？然后，不要为您的监控和警报添加检查。

已经有一些配置管理堆栈和自动化环境使用Puppet，Ansible，Chef，Salt？找到一个本机模块，让它根据您的客户端事实生成配置。

更喜欢以自动化的方式创建对象？使用Icinga 2 REST API并在运行时创建对象，而无需重启。想要将这些对象同步到卫星节点吗？设置zone属性。很管用。

如果您碰巧有CMDB、NDO数据库、PuppetDB/Foreman等，您还可以使用Icinga Director，它1)使用同步规则导入现有事实2)与Icinga 2 API对话并管理您的配置包。额外的好处:你也会得到一个Icinga2的配置UI。

正如你所看到的，有许多可能性，人们喜欢仍然拥有它们。

在你的用例中，我会用一些简单的例子来学习新的语言。使用你公司的let服务器，让它通过Icinga 2进行监控。

一旦你获得了成功，就去寻找替代方案。或者只是生成配置对象的更好的方法。

apply rules和apply-for规则只定义一次。用于服务、通知、依赖项。使用条件(if then else)根据主机自定义属性分配不同的阈值。

使用与您从应用规则中知道的assign where表达式类似的组分配。这样你就可以匹配用户的电子邮件属性，并创建一个用户组。在您的通知应用规则中使用它。

添加/删除主机。它将获得由应用规则生成的服务、通知和依赖项。

添加/删除用户。他/她将收到通知(如果电子邮件匹配)。如果用户被删除，则不再有通知。(当然-不需要编辑任何主机/服务或联系人组成员)

好吧，我可以说上一整天。也许你会有机会加入我们的冰雪夏令营(查看https://www.icinga.org的公告) :-)

Answer 2

有一些配置转换器，但我对它们的运气不好。

我个人是不会这样做的。合理快速的方法是注意配置中的模式，并使用icinga2的编程规则来最小化必要的工作量。困难的部分是那些不属于这些通用规则的单一服务。你仍然比在nagios中打字要少得多。

如果有必要，使用脚本快速模板配置文件的重复样板代码，这是我所做的事情。

最终的结果是，您最终得到了更紧凑的配置，可以做同样的事情。有各种技术可以让icinga2的函数为您完成大部分繁重的任务。

最节省时间的事情是在nagios上使用Thruk UI，而不是在livestatus上。它提供了一种查看每个检查的完整命令调用的方法，所有参数都展开了，并且您可以将任何自定义视图导出到csv文件中进行处理。