我需要将具有大量节点和服务的 Nagios 实例迁移到 Icinga2。我遇到了以下文档： http ://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#migration
它没有提到是否有自动方式将 Nagios 的所有配置转换为 Icinga2 配置格式。它说如何手动进行。有没有人通过自动配置转换将 Nagios 迁移到 Icinga2。或任何建议以不那么痛苦的方式这样做。
谢谢
问问题
7998 次
2 回答
1
如果您不打算寻找相似之处或模式，那么这也是评估不同配置方法的好时机。并重新开始。
我已经看到许多 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了解公告）:-)
于 2016-04-13T17:54:28.057 回答
0
有一些配置转换器，但我有他们的运气。
我个人不会这样做。相当快速的方法是注意配置中的模式并使用 icinga2 的编程规则来最小化必要的工作量。困难的部分是那些不属于这些通用规则的单一服务。你仍然比在 nagios 中少打字。
如有必要，使用脚本快速模板化配置文件的重复样板代码，这是我所做的。
最终结果是您以更紧凑的配置结束了相同的操作。有多种技术可以让 icinga2 的功能为您完成大部分繁重的工作。
最节省时间的事情是使用 Thruk UI 和 nagios，而不是 livestatus。它提供了一种查看每个检查的完整命令调用的方法，所有参数都展开了，您可以将任何自定义视图导出到 csv 文件中进行处理。
于 2016-04-07T08:51:47.100 回答