这是唯一正确答案是“视情况而定”的通用问题之一。标准是什么？
任何依赖 SNMP 来监控服务器的行为都是失败的。SNMP 存在一些基本问题，无法正确监控服务器。此外，大多数 SNMP 代理都很糟糕。Net-SNMP 真的很糟糕。
通常这样的问题会被忽略，只要生成漂亮的图表。我告诉开发经理他们正在查看的数据是无用的，我们这样做只是为了满足生成漂亮图表的要求，他们对此表示同意，并继续询问有关图表的问题。
例如，获取单个线程的信息大约需要 20 个 SNMP 请求。在需要每分钟轮询一次的具有 100 万个线程的系统上，每分钟需要监控 2000 万个数据包！我意识到一百万个线程很多，并不是每个人都需要每分钟轮询一次，但这也并非不合理，很多人需要更多。
通常“空闲”内存的含义是混淆的。我已经看到这被忽略了，因为它允许购买额外的内存 - 在忙碌的一天可能导致 3 倍的正常内存使用量以及管理层拒绝为这些峰值调整大小的金融环境中非常有益。谎言基本上被抵消了。
通常用于监控交换机/路由器的监控工具将通过 SNMP 获取服务器的每个 CPU 统计信息，并在显着位置报告数据。许多人不想听到每个 CPU 的统计数据不是他们想要的，而每个线程的统计数据才是。
无论数据如何检索，许多常见问题都需要亚分钟甚至亚秒轮询才能理解。幸运的是，Linux sar 可以毫无问题地以 1 秒的间隔对数据进行采样。它不会保存 iostat 所做的所有数据，这可以使理解存储瓶颈的猜测成为可能。我也只保存“iostat -x 1”数据。例如，如果用户抱怨亚秒级冻结（或者，如果客户抱怨他们通常需要 10 毫秒的事务有时需要 200 毫秒），则所有进程/线程统计信息的亚秒级轮询很有用。遗憾的是，很少有内核提供合理的机制来做到这一点。（没有正当理由为什么我不能在一个系统调用中以结构化的方式提取这些数据，而且我不应该在内核中处理数据到十进制的转换，
未能以合理的方式保存磁盘性能统计数据是一种常见的疏忽。
没有良好同步的时钟是一个常见问题。许多人都忽略了始终需要 NTP 的事实。NTP 配置不当可能意味着您不知道两个时钟的同步程度是一个常见问题。一个严肃的企业应该把钱花在自己的 GPS 时钟上这一事实经常被忽略。对于参与纳斯达克交易的公司，我指着法规，为我们的客户写一篇关于期望什么时间准确度的解释（他们经常问），并在要求批准这个解释时，描述我们需要遵守法规的设置，遵守我们对客户的承诺，并与依赖时间同步的供应商一起解决问题。
传递警报是一个常见问题。基本上，您需要确保一个人会对警报做出响应，一个人对他们确认的警报负责，并且如果未确认警报将通过另一条路径重新发送或发送给另一个人。如果人们收到阻止他们认真对待页面的虚假警报，则需要关注监控系统。
了解趋势和错误警报之间的区别很重要。
在系统日志中报告错误很重要，因为有一种机制来识别新类型的错误，即使它不及时。
我在这里触及了一些非常重要的东西。但没有什么比这更重要 - 无论您购买哪种监控/趋势/警报解决方案，为您的环境设置和定制都会产生巨大的成本。没有可用的解决方案可以显着降低设置/维护成本。一个常见的失败是不断购买新的监控系统，将它们保留在默认设置中，让它变得无用。
供应商承诺他们将帮助免费定制是没有用的。除非你写得很清楚。供应商承诺将向您出售昂贵的定制服务是没有用的 - 您不能相信他们会胜任。
如果您有关键的自定义内部应用程序，而您的开发人员拒绝为他们的应用程序添加检测、日志记录和其他监控帮助，那么您就有问题了。基本上，疏忽的开发人员不关心他们软件的操作方面。另一方面，开发人员需要参与讨论要监控他们软件的哪些方面，因此可以设计一种方便的方法来公开这一点。他们可能面临添加功能的压力，而没有考虑可靠性或问题警报。
小智 5
Nagios 曾经是一个较小的低端系统，但我想说最近的版本确实是“企业级”。基于 SNMP 的开源软件集成了从 Cacti 到 RRDTool 的所有内容。您需要花时间配置和构建自定义报告脚本，但老实说，商业工具也是如此。
Traverse（以前是 NetVigil）是一个比“旧 Nagios”更大的商业工具，即使不是比当前的 Nagios 稍好，也可以与之相提并论。
有很多中档监控系统。
在高端，您有 HP OpenView、IBM Tivoli、CA Unicenter 和许多其他产品。许可和实施咨询的价格可能高达数百万美元，这是一项要求。
无论您在频谱中的哪个位置，监控软件都需要花费您的时间。它很容易成为大型商店中监控系统的护理和喂养的全职工作。