我需要将具有大量节点和服务的 Nagios 实例迁移到 Icinga2。我遇到了以下文档： http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#migration
没有提到是否有自动方式将 Nagios 的所有配置转换为 Icinga2 配置格式。它说如何手动进行。有没有人通过自动配置转换将 Nagios 迁移到 Icinga2。或任何建议以不那么痛苦的方式这样做。
谢谢
【问题讨论】：
标签： monitoring nagios icinga
如果您不打算寻找相似之处或模式，那么这也是评估不同配置方法的好时机。并重新开始。
我已经看到很多 Nagios/Icinga1 安装随着时间的推移而增长，而不是“修复”问题，您只需复制例如一个现有的检查命令，给它一个新的名字，然后使用那个。或者死于没有人写过文档的一堆对象技巧。有时，由于核心中的错误，此类配置也“有效”。有些已经在 Icinga 1.x 中修复，但我确实知道 Nagios Core 中的一些在构建配置时仍然非常烦人。
事实证明，如果您为当前环境使用笔、纸和绘图板，您将了解现有的瓶颈，或了解进行检查的新方法。示例：不关心 VM 上的负载和交换？然后不要为您的监控和警报添加检查。
已经有某种配置管理堆栈和使用 Puppet、Ansible、Chef、Salt 的自动化环境？选择一个原生模块，让它根据你的客户事实生成配置。
更喜欢以自动化方式创建对象？使用 Icinga 2 REST API 并在运行时创建对象而无需重新启动。想要将这些对象同步到卫星节点？设置区域属性。有效。
如果您碰巧有 CMDB、NDO 数据库、PuppetDB/Foreman 等，您也可以选择 Icinga Director，它 1) 使用同步规则导入现有事实 2) 与 Icinga 2 API 对话并管理您的配置包.奖励：您还将获得 Icinga 2 的配置 UI。
如您所见，有很多可能性，人们仍然喜欢拥有它们。
在您的用例中，我会通过一些简单的示例来学习新语言。使用贵公司的网络服务器，让它通过 Icinga 2 进行监控。
一旦您获得成功，请寻找替代方案。甚至更好的方法来生成配置对象。
应用规则和申请规则只定义一次。对于服务、通知、依赖项。使用条件（if then else）根据主机自定义属性分配不同的阈值。
使用类似于您从应用规则中知道的 assign where 表达式的组分配。这样你就可以例如匹配您用户的电子邮件属性，并创建一个用户组。在通知应用规则中使用它。
添加/删除主机。它将获取应用规则生成的服务、通知、依赖项。
添加/删除用户。他/她会收到通知（如果电子邮件匹配）。如果用户被删除，则不再有通知。 （当然 - 无需编辑任何主机/服务或联系人组成员）
好吧，我可以整天谈论它。也许你有机会加入我们的 Icinga 夏令营（请查看 https://www.icinga.org 了解公告）:-)
【讨论】：
有一些配置转换器，但我运气不错。
我个人不会这样做。相当快速的方法是注意配置中的模式并使用 icinga2 的编程规则来最小化必要的工作量。困难的部分是那些不属于这些通用规则的单一服务。与在 nagios 中相比，您的打字仍然少得多。
如有必要，使用脚本快速模板化配置文件的重复样板代码，这是我所做的。
最终的结果是你以更紧凑的配置结束。有多种技术可以让 icinga2 的函数为您完成大部分繁重的工作。
最节省时间的事情是使用带有 nagios 的 Thruk UI，而不是 livestatus。它提供了一种查看每次检查的完整命令调用的方法，扩展了所有 args，您可以将任何自定义视图导出到 csv 文件中进行处理。
【讨论】：