最好/最差的监控系统是什么?

最好/最差的监控系统是什么?

这是一个通用问题,唯一正确的答案是“视情况而定”。标准是什么?

  • 监控什么?
    • 可达性、可用性?例如,链路是否连通/断开、主机是否响应 ICMP 等。
    • 服务?例如是否有东西在监听正确的端口、是否有命名的服务正在运行等等。
    • 资源?CPU 使用率?例如,总可能百分比、累计时间、总计或每个进程。磁盘使用情况?网络使用情况?例如,移入或移出的字节数或数据包。
    • 服务?例如是否有东西在监听正确的端口、是否有命名的服务正在运行等等。
    • 服务或应用程序特定指标?例如每秒的数据库事务数、发送或接收的 SMTP 消息等。
  • 如何发现/添加/设置/配置受监控元素?是否有自动发现?手动设置?
  • 如何监控特定元素?
    • 本地代理?例如定期执行“df”或“ps”或“ping”
    • SNMP?
    • JMX?
    • Windows 性能计数器?
  • 如何通知?例如控制台,电子邮件,寻呼机,短信,即时通讯等。
  • 元素和通知如何分组并排列优先顺序?
    • 例如,链路故障是否会触发该链路后面所有服务或可达性元素的通知?还是只触发一个元素的通知?还是可以配置的?
    • 例如,主机故障是否会引发托管在那里的所有服务或应用程序的通知以及缺乏资源监控数据?
    • 跟踪系统中是否自动创建案例/票证/问题?
  • 如何跟踪 SLA 指标?

答案1

任何依赖 SNMP 来监控服务器的做法都是失败的。SNMP 存在一些根本性问题,无法正确监控服务器。此外,大多数 SNMP 代理都很糟糕。Net-SNMP 真的很糟糕。

通常情况下,只要能制作出漂亮的图表,这类问题就会被忽略。我告诉开发经理,他们看到的数据毫无用处,我们这样做只是为了满足制作漂亮图表的要求,他们对此表示同意,并继续询问有关图表的问题。

例如,获取有关单个线程的信息大约需要 20 个 SNMP 请求。在具有一百万个线程且需要每分钟轮询一次的系统上,每分钟需要监控 2000 万个数据包!我知道一百万个线程很多,而且并非每个人都需要每分钟轮询一次,但这也并非不合理,许多人需要更多。

通常,“免费”内存的含义是令人困惑的。我见过有人忽略这一点,因为它允许购买额外的内存——这在财务环境中非常有益,因为繁忙的一天可能会导致内存使用量达到正常水平的 3 倍,而管理层拒绝为这些峰值调整大小。从本质上讲,谎言被抵消了。

通常,用于监控交换机/路由器的监控工具会通过 SNMP 获取服务器的每个 CPU 统计信息,并突出显示数据。许多人不想听到每个 CPU 统计信息不是他们想要的,而每个线程统计信息才是。

不管数据是如何检索的,许多常见问题都需要亚分钟甚至亚秒的轮询才能理解。幸运的是,Linux sar 可以以 1 秒的间隔对数据进行采样,没有任何问题。它不会像 iostat 那样保存所有数据,这会使理解存储瓶颈成为一种猜测。我也只保存“iostat -x 1”数据。例如,如果用户抱怨亚秒级冻结(或者,如果客户抱怨他们的交易通常需要 10 毫秒,但偶尔需要 200 毫秒),则对所有进程/线程统计信息进行亚秒级轮询很有用。遗憾的是,很少有内核提供合理的机制来执行此操作。(没有正当理由让我不能在一个系统调用中以结构化的方式提取这些数据,我也不应该在内核中将数据转换为十进制,在我的应用程序中从十进制转换为十进制,以及其他愚蠢的开销)。

无法以合理的方式保存磁盘性能统计数据是一个常见的疏忽。

时钟无法同步是一个常见问题。许多人都忽略了 NTP 始终必不可少的事实。不正确的 NTP 配置可能意味着您不知道两个时钟的同步程度,这是一个常见问题。一个严肃的企业应该花钱购买自己的 GPS 时钟,这一事实经常被忽略。对于参与纳斯达克交易的公司,我会指出法规,为我们的客户写一份关于预期时间准确度的解释(他们经常询问),并在请求批准此解释时,描述我们需要哪些设置才能遵守法规,遵守我们对客户的承诺,并解决依赖时间同步的供应商的问题。

警报的传递是一个常见问题。基本上,您需要确保有人会响应警报,有人对他们确认的警报负责,并且如果未确认,警报将通过另一条途径重新发送或发送给另一个人。如果人们收到虚假警报,导致他们无法认真对待页面,则监控系统需要引起注意。

了解趋势和错误警报之间的区别非常重要。

在系统日志中报告错误很重要,因为即使不及时,也要有一种识别新类型错误的机制。

我在这里提到了一些非常重要的东西。但没有什么比这更重要了——无论你购买什么监控/趋势/警报解决方案,设置和定制你的环境都需要花费大量成本。没有可用的解决方案可以显著降低设置/维护成本。一个常见的失败是继续购买新的监控系统,让它们保持默认设置,并让它毫无用处。

供应商承诺免费帮助定制是没用的。除非你有明确的书面承诺。供应商承诺向你出售昂贵的定制服务是没用的——你不能相信他们会胜任这项工作。

如果您拥有关键的自定义内部应用程序,而您的开发人员拒绝为其应用程序添加仪表、日志记录和其他监控帮助,那么您就会遇到问题。基本上,这些开发人员粗心大意,不关心其软件的操作方面。另一方面,开发人员需要参与讨论要监控其软件的哪些方面,因此可以设计一种方便的方法来公开这一点。他们可能面临添加功能的压力,而不考虑可靠性或问题警报。

答案2

Nagios 曾经是一个规模较小、低端的系统,但我认为最新版本确实已经是“企业级”了。基于 SNMP 的开源系统,可与从 Cacti 到 RRDTool 的所有产品集成。您需要花时间配置和构建自定义报告脚本,但老实说,商业工具也是如此。

Traverse(原为 NetVigil)是一款商业工具,它比“旧版 Nagios”更大,并且与当前的 Nagios 相当甚至略胜一筹。

有很多中档监控系统。

高端产品有 HP OpenView、IBM Tivoli、CA Unicenter 等。许可和实施咨询的价格可能高达数百万美元,这是必需的。

无论您处于哪个阶段,监控软件都需要您投入时间。在大型商店中,维护和维护监控系统很容易成为一份全职工作。

答案3

我们最近开始评估芝诺斯带有各种 Nagios 插件。它似乎非常易于配置。大约一年前我们尝试过 Nagios,但遇到了配置问题。Zenoss 似乎更容易使用。

我们还讨论过“哥们”但想要一个基于 *nix 的服务器。

我最近还遇到了一个信息世界文章详细介绍一些颇具价值的开源监控工具。

答案4

我非常喜欢 nagios,并已将其设置为监控我的所有服务器及其运行的许多服务。它是我经常修改的程序之一,尤其是因为我们做的事情经常发生变化。我甚至可以让它检查我们公共网站上的某些文本。

最初我将通知设置为电子邮件,但后来尝试了短信提醒,最近又尝试了即时通讯提醒。

我已经用了一年多了,但还远远没有达到完美状态。我发现的一个缺点是历史细节保存得不好,但这可能与我没有找到合适的插件有关。

相关内容