NagiosconfigurationGUI

我们已经在我们的networking上实施了Nagios服务，并且运行良好。通知很好，各种configuration选项非常方便。到目前为止，我们直接通过修改文件来完成所有的configuration。

当我们开始向一些其他pipe理员开放这个，我想实现一个GUI，这将减less错误的可能性。我已经检查了几个不同的GUI项目，到目前为止，看起来NagiosQL和NConf是目前最有竞争力的。

这两者之间是否有任何build议，或者应该考虑的其他build议？如何安装和使用的故事，“陷阱”和技巧可能有助于决定？

我们在同一个决定面前，目前nconf是我们最喜欢的。它具有大型分布式环境devise的巨大优势。

它会自动为不同的nagios服务器创buildconfiguration文件，一个是某种收集器，另一个是监视器，只接收来自收集器的被动检查。

缺点是，目前你不能用nconf处理升级！

我们在工作中使用OpsView 。这是一个基于Web的GUI，可以处理诸如通过集群扩大Nagios服务的function。您可以通过networking添加新的主机，新的服务，并确认中断。它也logging服务的历史观点，如果你想知道一些服务器经常需要多lessCPU。

但是，您仍然无法通过networking添加Nagios脚本。

我们在Opsviewpipe理Nagios方面有很好的经验。然而，把它看作Nagios的“前端”是错误的，相反，将其视为一个使用Nagios作为其基础引擎的监控系统。

Nagiosconfiguration存储在数据库中，Nagiosconfiguration文件是以编程方式生成的，所以如果您习惯于将您的Nagiosconfiguration存储在源代码控制中，或者使用您自己的一些脚本生成它们，则需要放弃这些程序。

你取而代之包括以下内容：

史蒂夫

我很遗憾的一个问题是，configuration前端有时候会创build真正垃圾的configuration文件，如果以后需要的话，这些configuration文件不能直观地用手编辑。这对于任何使用机器生成的configuration文件的系统来说都是一个问题，即使它不直观也能很好地理解。

我通常使用Nagios的方法是广泛使用模板和inheritancefunction，并将我的configuration分割成许多，许多，许多文件。

在这里值得注意的是，Nagios社区最近因为主要开发者缺乏领导技能而被分离出来，Nagios在十年内确实没有得到改善或改变。 Icinga据说是新的酷，但我还没有尝试过。

编辑

今天新的官方 nagios交易所也开放了，这里有一个链接到configuration部分以供快速参考：

Nconf不支持服务和主机升级

但，

你可以通过pipe理菜单“扩展”应用程序直接从web gui支持它，在每个新类中创build两个新的类“hostescalation”和“serviceescalation”，你必须定义一个名为“Naming Attribute”的升级属性，而不是输出一个专用的configuration文件

然后定义与升级相关的任何属性，并且必须写入configuration文件，例如：host_name链接到主机类contact_groups到contactgroups类的列表等等

出于同样的原因，我们必须实施一个前端。就我个人而言，我发现他们都有点笨拙，宁愿手工pipe理configuration文件（less花钱）。但似乎你没有太多的select。

我们使用君主，但我不喜欢这一切。

我还没有尝试任何其他的东西，但你可以从这里开始…

我肯定会推荐Centreon作为Nagios前端。它不仅简化了configuration过程，而且还可以用于状态显示和Nagios检查返回的性能数据的收集，而不是转换成漂亮的graphics。因此，在某种程度上，也是过时的仙人掌。

零售产品NagiosXI价格合理，隐藏了所有底层的文本configuration文件。我们已经使用了大约六个月，并且对它的成本/收益感到满意。