答案1
目前有很多监控解决方案。每个人都有自己的偏好，每个企业都有自己的需求，因此没有正确的答案。但是，我可以帮助您弄清楚在选择监控解决方案时可能需要注意什么。
监控系统有何用途？
一般来说，监控系统有两个主要用途。第一个是随时间收集和存储数据。例如，您可能希望收集 CPU 利用率并随时间绘制图表。第二个用途是当事物没有响应或不在特定阈值内时发出警报。例如，当某个服务器无法通过 ping 到达或 CPU 利用率超过特定百分比时，您可能希望发出警报。还有日志监控系统（如 Splunk），但我将它们视为单独的系统。
这两个主要作用有时出现在单个产品中，有时更常见的是每个用途都有一个专用的产品。
监控系统的主要组件和功能是什么？
轮询者：
所有监控系统都需要某种轮询器来收集数据。并非所有数据的收集方式都相同。您应该查看您的环境并确定需要哪些数据以及如何收集这些数据。然后确保您选择的监控系统支持您的需要。一些常用方法包括：
- 简单网络管理协议（简单网络管理协议）
- 威盛（Windows 管理规范）
- 运行脚本（例如，在被监控的机器上运行脚本，或从使用其自己的轮询方法的监控箱本身运行脚本）。这些可以包括 Bash 脚本、Perl 脚本、可执行文件和 Powershell 脚本等
- 基于代理的监控。通过这些，每个客户端上运行一个进程并收集数据。这些数据要么被推送到监控服务器，要么监控服务器轮询代理。有些管理员对代理很满意，但有些管理员不喜欢它们，因为它会在被监控的服务器上留下更大的空间。
- 重点 API（例如 VMWare API 或运行 SQL 查询的能力）
如果您的环境中主要有一个操作系统或一个主要操作系统，则某些系统可能比其他系统具有更多选项。
配置：
在监控系统中，往往会有大量对象重用。例如，您想要监控一组服务器上的某个应用程序（如 Apache 或 IIS）。或者您希望将某些阈值应用于服务器组。您可能还需要某些人员组“随叫随到”。因此，良好的模板系统对于监控系统至关重要。
配置通常通过用户界面或文本文件完成。用户界面选项通常更简单，但文本文件更适合重用和变量。因此，根据您的 IT 员工，您可能更喜欢简单而不是强大。
用户界面：
目前监控系统最常见的界面是 Web 界面。关于 Web 界面需要评估的一些事项包括：
- 很好的概述
- 良好的详细信息页面
- 速度（当你需要在危机模式下查找信息时，缓慢的界面可能会非常令人沮丧
- 总体感觉。您将在界面上花费大量时间，如果感觉笨重，您的 IT 员工将不愿意使用它
- 定制。每个组织都有一些重要的事情，而其他事情则不重要。能够根据你的需求进行定制很重要
报警引擎：
警报引擎必须灵活可靠。有很多不同的通知方式，包括：
- 短信
- 电子邮件
- 电话
- 其他类似 IM/Jabber 的东西
其他需要寻找的特征包括：
- 升级（如果其他人尚未确认或修复警报，则通知某人）
- 轮换和轮班
- 群组（特定群组需要获知特定事项）
重要的是要相信当出现问题时您会收到警报。这归结为两件事：
- 可靠的系统
- 无警告配置。在监控系统中，通常认为您应该收到警报，但由于配置中的一些细节，警报从未被触发。
数据存储：
如果系统收集并存储数据（即包含图表的系统），则系统会存储数据。例如，存储和绘图的一个非常常见的实现是 RRD。
需要从数据存储中寻找的一些特性包括：
- 原始数据访问。这对于开发或使用 Excel 等软件创建自定义图表非常有用。
- 可扩展性。根据您收集的数据量，数据量可能会快速增加，如果您要收集大量数据，您需要确保数据可以扩展。
图库：
图表有助于快速识别趋势，并根据历史情况提供当前状态的背景。有些图表包括趋势图，有助于在事情发生之前预测（例如磁盘空间不足）。确保图表能以清晰的方式提供您认为需要的信息。
访问控制：
如果您的组织规模较大，您可能需要访问控制，因为某些管理员只能调整某些内容。您可能还需要面向公众的仪表板。如果这很重要，您应该确保监控系统具有您需要的控制功能。
其他特性
报告：
提供良好报告的系统可以帮助您确定长期内需要改进的地方。例如，它可以很好地回答“哪些系统最容易出问题？”之类的问题。当您试图说服管理层在某些事情上花钱时，这一点很重要——业务就像确凿的证据。
专业功能：
某些监控系统针对特定产品，或者比其他系统提供更多支持。例如，如果您需要监控的主要内容是 SQL 服务器，或者如果您大量使用 VMWare 产品，则应该了解这些产品的支持情况。
预定义监控模板：
带有大量预定义模板的系统（或拥有创建了许多模板的用户群）可以节省大量时间。
发现：
如果您拥有大型或不断变化的环境。某些系统提供通过 API 添加新系统或运行扫描以查找新服务器或组件的功能。
分布式监控：
如果您需要监控多个位置，则在每个位置都有监控轮询器会很有帮助，而不是许多独立系统通过 WAN 进行监控。
一些流行的监控系统
目前有很多监控系统。我们有一份关于这个老问题的总结清单。作为快速参考，我听到最多的是：
- 纳吉奥斯
- 仙人掌
- 开放网络管理系统
- 太阳风
- 扎比克斯
- 各种基于云的监控系统
- 微软系统中心
- 这个还不流行，但是 Stack Exchange 已经开源了它的监控系统http://bosun.org
根据以上内容如何决策
我无法告诉您使用哪种系统，因为每个组织都有自己的需求。如果您想做出正确的选择，您应该仔细考虑上述所有组件，并找出哪些功能对您的组织很重要。然后找到一个或多个声称可以提供您所需的系统并试用它们。其中一些系统价格低廉，价格昂贵，或免费。考虑到所有这些因素，您就可以做出选择。从我使用过的产品来看，它们都远非完美，但至少您可以尝试获得适合的产品。
答案2
区分监控和警报很有帮助。监控意味着收集数据并制作图表。警报意味着当服务器半夜宕机时给我发短信。
Nagios 用于报警。Cacti 和 Munin 用于监控。其他产品结合了两种功能。例如 Zenoss 和 Zabbix。
我首先回答一些问题：
您需要监控服务器、网络设备、应用程序，还是三者都监控？
监控方法是否有限制？您可以在服务器上安装 NRPE 等监控客户端吗？或者您会使用 SNMP，或者两者兼而有之？
谁将使用图表，谁将使用警报？您希望最终结果是什么样子？界面的外观和感觉是否重要（业务人员会使用它，还是只有技术人员会使用它？）
您的资源（时间、技能和硬件）有哪些？您是否至少具备一定的脚本编写能力？您是否需要现成的解决方案？
我认为，警报和监控的第一条规则应该是保持简单！一个组织的生存或死亡取决于它如何警报和收集数据，而且大多数时候它本身就会变得复杂。从基础开始，然后从那里开始构建。
答案3
总结
想想您的软件提供的服务，当这些服务发生故障时发送警报，或者当失败的风险这些服务的增加。
服务等级协定
监控策略背后的理论是将监控和警报与某种服务水平协议。毕竟，您希望收到有关您正在亏损的事实的警报，而不一定是 nji0019.myserver.com 的 TCP 连接数量激增的警报。有各种工具可以为您提供大量警报，定义警报之间的依赖关系，但其中许多检查与服务你提供给某人。
违反服务
确定您提供的重要服务，例如为网站提供服务的能力，以及修改该网站的能力（例如某种 CMS）。应该检查这些服务（例如，通过监控您是否可以获取网页，以及您是否可以访问网页）。这两个服务（此处使用大写 S）的故障应该触发警报以通知您。
如果网站在合理的时间内做出响应很重要，那么也应该触发警报。如果你愿意的话，这可以说是一种“违反 SLA”。
风险增加
通常，服务失败存在固有风险，而通过引入冗余（例如第二台服务器、从属数据库或额外的网卡）通常可以降低风险...
当冗余度消失时，服务仍然可以正常运行，但是服务失败的风险却增加了。
这是触发警报的第二个主要原因；冗余已经消失（例如第二台服务器死机），或者存在风险增加的迫在眉睫的危险（例如磁盘只剩下 500Mb，或者磁盘趋势表明磁盘将在大约 5 小时后装满）。
所有这些指标怎么样？
但是 check_mk 给我每个主机 50-60 次检查，这些都是没有价值的吗？
不。所有这些并不意味着您想要放弃使用 check_mk 等获得的大量自动检查，但这意味着您应该尝试将每项检查分类为如果出现故障可能会影响哪些服务。
如果 /var/ 分区已满，哪些服务会受到影响？如果 eth0 接口关闭，哪些服务会受到影响？... 如果出站 TCP 连接被某些防火墙阻止？... 如果线程数超过 800？... 如果数据库崩溃？
例子
您有 2 台 Web 服务器和一台数据库服务器，该服务器位于您不拥有的负载均衡器（例如 ISP）后面，为网站提供服务。您提供的服务是两台服务器上的 80 端口，它们拥有巨大的缓存，可以承受数据库停机等情况（数据库位于第三台服务器上）。
在这种情况下，Web 服务器的彻底故障不会导致网站瘫痪。实际发生的情况是冗余消失了，因此失败的风险刚刚上去。 那应该触发警报。
由于缓存已调优，数据库彻底崩溃可能不会对网站服务能力产生任何影响；不影响服务为网站提供服务，但它可能会影响不同的服务，即更新网站或接受订单......
每项服务都有自己的服务级别，指定恢复服务或避免中断的重要性
保持敏捷
每次收到警报时，您都应该执行以下操作之一： - 更改被监控的系统以解决导致警报的问题（例如，更换驱动器或重新配置 logrotate 等） - 更改监控系统以避免在下次出现这种情况时发出警报。 （例如，更改“磁盘可用”级别，以便磁盘可以填充到 90％，而不仅仅是 80％）
我自己的经历
我最熟悉的是 Nagios 及其详细配置，从那时起就迷上了 Check-mk 的多站点。我最近了解到 check_mk 有这种商业智能的概念（自 1.11 版以来），这似乎与这种想法很吻合。您可以定义 nagios 中的检查是更大服务的一部分，并有规则将“服务”的状态定义为许多检查状态的函数，汇总到最差或者最好的状态。
答案4
如果您正在考虑远程系统监控，那么寻找测试执行的实际位置可能是一个好主意。连接问题不再是过去的事情，如果您的硬件正在为特定地区的一个团体提供服务，您可能希望确保您的资源在该特定位置可用。