将Nagios的问题缩放为CaSC

Question

如果Nagios服务器在更大的组织中使用CasC配置源，这种方法是否存在设计缺陷，从而限制了扩展？

为了避免配置中断，可以在CI环境中验证Nagios的测试实例。

使用场景:设想一个中心Nagios服务，它的用户数量超过了您想要破坏它的用户，这些用户希望添加他们的服务来进行监视。

Answer 1

就我个人而言，我不认为使用CasC本身会产生任何负面的可伸缩性影响。

从根本上说，CasC意味着实际的配置文件不是手动维护的，而是按照版本控制的规则自动生成的--这可能要可靠得多。

但是，一旦生成了配置文件--使用它们的服务就像用手工构建的配置文件进行编辑一样。

如果有什么需要的话--使用CasC会使这样大的nagios系统更加可靠--如果正确的话，CasC应该可以减少/消除修改配置文件时出现人为错误的风险。

Answer 2

根据我在使用版本控制配置文件和CI/CD管理Nagios部署方面的经验，它确实工作得很好。您可以更容易地与其他团队协作，因为您可以授予对git存储库的访问权限，并且您可以获得CI/CD的所有好处，例如回滚和自动测试。有一件事可能是瓶颈，那就是重新加载Nagios的频率有多高，但只有当您每小时有很多部署时，才会出现问题。

Nagios本身也有许多限制，并且缺少一些现代环境的关键特性(缩放、配置继承、API)，但严格地说，这并不妨碍将CasC与Nagios一起使用。

Answer 3

拥有CasC设置意味着您能够更好地处理以后应该出现的任何可伸缩性问题。您应该需要一段时间才能最大限度地使用nagios盒。只要您没有让它缺少内存或其他东西，就应该能够在一个nagios盒子上得到数千个节点。有多少取决于你做了多少次支票，以及这些支票有多贵。但是，如果你到了一个nagios盒子还不够的地步，在CasC的情况下，你就有能力以一种方便的方式分割东西，然后继续生活。如果你不得不亲力亲为的话，人工干预就会少得多。

对于单个实例，您可能不会达到最大值，但希望每个数据中心都有本地nagios框的可靠性。有了CasC，您就可以更容易、更透明地完成这一任务。