我想问一下集体对分布式监控系统的意见和看法,你使用了什么,你知道哪些可能会勾选我的方框？
要求非常复杂;
>没有单点故障.真.我死得很认真！需要能够容忍单个/多个节点故障,“主”和“工作者”,并且您可以假设没有监控位置(“站点”)其中有多个节点,或者在同一网络上.因此,这可能会排除传统的HA技术,如DRBD或Keepalive.
>分布式逻辑,我想在多个数据中心和多个大陆的多个网络中部署5个节点.我希望从我的客户的角度看我的网络和应用程序的“鸟眼”视图,当你有50个节点,甚至500个节点时,监控逻辑的奖励点不会陷入困境.
>需要能够处理相当合理数量的主机/服务检查,la Nagios,为球场数据假设每台主机有1500-2500台主机和30台服务.如果添加更多监控节点允许您相对线性地扩展,可能在5年内我可能希望监控5000个主机和每个主机40个服务,这真的很好！从我上面关于’分布式逻辑’的说明中添加它可以说：
>在正常情况下,这些检查必须在$n或n％的监控节点上运行.
>如果检测到故障,则运行对另外$n或n％节点的检查,关联结果,然后使用它们来确定是否已满足标准以发出警报.
>图表和管理友好的功能.我们需要跟踪我们的SLA并了解我们的“高可用性”应用程序是否全天候运行是否有用.理想情况下,您提出的解决方案应该以最小的faff进行“开箱即用”的报告.
>必须有一个可靠的API或插件系统来开发定制检查.
>需要对警报有所了解.我不一定知道(通过短信,凌晨3点！)一个监控节点认为我的核心路由器已关闭.我确实想知道他们中确定的百分比是否同意某些时髦的事情;)基本上我在这里谈论的是“法定人数”逻辑,或者对分布式疯狂应用理智！
我愿意考虑商业和开源选项,虽然我更倾向于避开花费数百万英镑的软件:-)我也愿意接受可能没有什么东西可以勾选所有这些盒子,但是想问集体那个.
在考虑监控节点及其位置时,请记住,大多数节点都是随机ISP网络上的专用服务器,因此很大程度上超出了我的控制范围.依赖BGP提要和其他复杂网络滑稽动作的解决方案可能不适合.
我还应该指出,我过去评估,部署或大量使用/定制了大多数开源风味,包括Nagios,Zabbix和朋友 – 他们真的不是坏工具,但它们在整体上是不平衡的“分布式“方面,特别是关于我的问题和’智能’警报中讨论的逻辑.
很高兴澄清所需的任何要点.干杯男人和女孩:-)
不是真正的答案,而是一些指示：>明确地看一下关于nagios @ goldman sachs的演示文稿.他们遇到了你提到的问题 – 冗余,可扩展性：成千上万的主机,还有自动配置生成.
>我有冗余的nagios设置,但规模要小得多 – 80台服务器,总共约1k服务.一个专用的主服务器,一个从服务器每天几次定期从主服务器提取配置.两台服务器都覆盖了对同一台机器的监控,它们之间进行了健康的交叉检查.我主要使用nagios作为调用自定义产品特定检查的框架[执行脚本执行’人工流量控制’的一堆cron作业,结果仓库记录到sql,nrpe插件检查成功/失败执行最后x分钟的那些].一切都很好.
>你的仲裁逻辑听起来不错 – 有点类似于我的“人工流动” – 基本上继续,实现你的自我; – ].并且让nrpe只检查某种标志[或带有timestamp-status的sql db]事情是怎么做的.
>您可能希望构建一些可扩展的层次结构 – 您将拥有一些收集其他节点概述的节点,请从第一点开始查看演示文稿.对于每一项检查,默认的nagios forking对于更多的受监控服务来说都是过度的.
回答一些问题：
>在我的情况下,监控的环境是典型的主从设置[主sql或app服务器热备用],没有主 – 主.
>我的设置涉及’人工过滤因子’ – 解析器组,他是短信通知的“备份”.已经有一批技术人员由于其他原因有24/5轮班,他们“检查nagios邮件”作为额外的任务,不会给他们太多的负担.并且他们负责确保db-admins / it-ops / app-admins实际起来并解决问题; – ]
>我听说过很多关于zabbix的好事 – 用于警示和绘制趋势,但从未使用它.对我来说munin可以解决这个问题,我已经攻击了简单的nagios插件,检查munin服务器列表上是否有“任何红色”[关键]颜色 – 只是另外一项检查.您还可以从munin rrd文件中读取值,以减少发送到受监视计算机的查询数.