我在监控解决方案中寻找什么？

Question

这是一个规范问题关于监控软件。

还相关：您使用什么工具来监控您的服务器？

我需要监控我的服务器；在决定监控解决方案时，我需要考虑什么？

Answer 1

有很多监控解决方案。每个人都有自己的喜好，每个企业都有自己的需求，所以没有正确的答案。但是，我可以帮助您找出在选择监控解决方案时可能需要寻找的内容。

监控系统有什么用？

一般来说，监控系统有两个主要目的。首先是随着时间的推移收集和存储数据。例如，您可能希望收集 CPU 使用率并随时间绘制图表。第二个目的是在事情没有响应或不在特定阈值内时发出警报。例如，如果无法通过 ping 访问某个服务器或 CPU 利用率高于某个百分比，您可能需要警报。还有诸如 Splunk 之类的日志监控系统，但我将它们单独处理。

这两个主要角色有时出现在单个产品中，有时更常见的是有一个专用于每个目的的产品。

监控系统的主要组件和功能是什么？

轮询器：
所有监控系统都需要某种轮询器来收集数据。并非所有数据都以相同的方式收集。您应该查看您的环境并决定您需要哪些数据以及如何收集这些数据。然后确保您选择的监控系统支持您的需求。一些常见的方法包括：

• SNMP（简单网络管理协议）
• WMI（Windows 管理规范）
• 运行脚本（例如，在被监视的机器上运行脚本或从使用自己的轮询方法的监视框本身运行脚本）。这些可以包括 Bash 脚本、Perl 脚本、可执行文件和 Powershell 脚本等内容
• 基于代理的监控。有了这些，一个进程在每个客户端上运行并收集该数据。该数据要么推送到监控服务器，要么监控服务器轮询代理。一些管理员可以使用代理，其他人不喜欢它们，因为它会在被监控的服务器上留下更大的足迹。
• 重点 API（即 VMWare API 或运行 SQL 查询的能力）

如果您的环境中主要有一个操作系统或一个主操作系统，那么某些系统可能比其他系统有更多的选择。

配置：
在监控系统中，往往有很多对象重用。例如，您想在一堆服务器上监控某个应用程序，例如 Apache 或 IIS。或者您希望将某些阈值应用于服务器组。您可能还有某些人要“随叫随到”。因此，一个好的模板系统对于监控系统来说是至关重要的。

配置通常通过用户界面或文本文件完成。用户界面选项通常更容易，但文本文件往往更适合重用和变量。因此，根据您的 IT 员工，您可能更喜欢简单而不是强大。

用户界面：
如今监控系统最常见的界面是 Web 界面。关于 Web 界面要评估的一些事项是：

• 很好的概述
• 良好的详细信息页面
• 速度（当您需要在危机模式下查找信息时，缓慢的界面可能会非常令人沮丧
• 感觉一般。您将在界面上花费大量时间，如果感觉笨拙，您的 IT 人员会拒绝使用它
• 定制。每个组织都有某些重要的事情和其他不重要的事情。能够根据您的需要对其进行定制很重要

警报引擎：
警报引擎必须灵活可靠。有很多不同的通知方式，包括：

• 短信
• 电子邮件
• 电话
• 其他诸如 IM/Jabber 之类的东西

要寻找的其他功能是：

• 升级（如果其他人没有确认或修复警报，则通知某人）
• 轮换和移位
• 组（某些组需要通知某些事情）

请务必相信，当出现问题时，您会收到警报。这归结为两件事：

1. 可靠的系统
2. 一个警告免费配置。在监控系统中，认为您应该收到警报并不少见，但由于配置中的一些细节，警报从未被触发。

数据存储：
如果系统收集和存储数据（即包含图形的系统），则系统存储数据。例如，存储和图形的一个非常常见的实现是 RRD。

要从数据存储中查找的一些功能是：

• 对数据的原始访问。这对于使用 Excel 之类的工具开发或创建自定义图形非常有价值。
• 可扩展性。根据您收集的数据量，它可以快速累加，如果您要收集大量数据，则要确保它可以扩展。

图形库：
图形可用于快速识别趋势并根据某事物的历史记录为其当前状态提供上下文。一些包括趋势，这有助于在事情发生之前进行预测（即磁盘空间不足）。确保图表以清晰的方式为您提供您认为需要的信息。

访问控制：
如果您有一个大型组织，您可能需要访问控制，因为某些管理员应该只能调整某些事情。您可能还需要面向公众的仪表板。如果这很重要，您应该确保监控系统具有您需要的控件。

其他特性

报告：
提供良好报告的系统可以帮助您确定需要长期改进的内容。例如，它可以很好地回答诸如“哪些系统出现故障最多？”之类的问题。当您试图说服管理层在某些事情上花钱时，这可能很重要 - 业务就像确凿的证据。

特殊功能：
某些监控系统针对特定产品或比其他监控系统具有更多支持。例如，如果您需要监控的主要内容是 SQL 服务器，或者如果您大量使用 VMWare 产品，您应该了解这些产品的支持情况。

预定义监控模板：
带有大量预定义模板（或拥有创建了许多模板的用户群）的系统可以节省大量时间。

发现：
如果你有一个大的或不断变化的环境。某些系统提供通过 API 添加新系统或运行扫描以查找新服务器或组件的能力。

分布式监控：
如果您有多个位置要监控，那么在每个位置都有监控轮询器而不是许多独立系统通过 WAN 进行监控会很有帮助。

一些流行的监控系统

那里有很多监控系统。我们有一个关于这个老问题的摘要列表。为了快速参考，我听到最多的是：

• 纳吉欧斯
• 仙人掌
• 开放网管系统
• 太阳风
• 扎比克斯
• 各种基于云的监控系统
• 微软系统中心
• 这个还不流行，但是 Stack Exchange 已经开源了它的监控系统http://bosun.org

如何根据以上判断

我不能告诉你使用什么的原因是因为每个组织都有自己的需求。如果您想做出正确的选择，您应该仔细考虑上述所有组件，并弄清楚哪些功能对您的组织很重要。然后找到一个或多个声称可以提供您需要的系统并试用它们。其中一些花费很少、很多，或者是免费的。考虑到所有这些，您就可以做出选择。从我用过的来看，它们都远非完美，但至少你可以尝试得到适合的东西。

Answer 2

区分监视和警报很有帮助。监控意味着收集数据并制作图表。警报意味着当服务器在半夜出现故障时向我发送短信。

Nagios 用于警报。Cacti 和 Munin 用于监控。其他产品结合了这两种功能。Zenoss 和 Zabbix 就是例子。

我首先回答一些问题：

您是否需要监控服务器、网络设备、应用程序或三者？

您可以使用哪些方法进行监控是否有限制？你能在服务器上安装像 NRPE 这样的监控客户端吗，或者你会使用 SNMP，或者两者兼而有之？

谁将使用图表，谁将使用警报？你希望最终的结果是什么样的？界面的外观和感觉是否重要（业务人员会使用它，还是只使用技术人员？）

您在时间、技能和硬件方面的资源是什么？你至少有适度的脚本能力吗？您需要开箱即用的解决方案吗？

在我看来，警报和监控的第一条规则应该是保持简单！一个组织的生死取决于它如何发出警报和收集数据，而且在大多数情况下，无论如何它都会变得复杂。从基础开始，然后从那里开始构建。