那里有很多监控解决scheme。 每个人都有自己的偏好，每个企业都有自己的需求，所以没有正确的答案。 但是，我可以帮助您找出在select监控解决scheme时可能需要考虑的内容。

什么是监测系统？

一般而言，监测系统有两个主要目的。 首先是随着时间的推移收集和存储数据。 例如，您可能希望收集CPU利用率并随时间绘制graphics。 第二个目的是在事件没有响应或不在特定阈值内时提醒。 例如，如果某个服务器无法通过ping到达，或者CPU利用率超过一定百分比，则可能需要警报。 还有日志监控系统，如Splunk，但我把这些分开处理。

这两个主要angular色有时会在一个单一的产品，其他时间，更常见的是产品致力于每个目的。

监控系统的主要组件和特点是什么？

轮询 ：
所有监控系统都需要某种轮询器来收集数据。 并非所有数据都以相同的方式收集。 你应该看看你的环境，并决定你需要什么样的数据以及如何收集数据。 然后确保你select的监控系统支持你所需要的。 一些常用的方法包括：

• SNMP （简单networkingpipe理协议）
• WMI （Windows Management Instrumentation）
• 运行脚本（例如，在监视的计算机上运行脚本，或者使用自己的轮询方法从监视框本身运行脚本）。 这些可以包括诸如Bash脚本，Perl脚本，可执行文件和Powershell脚本之类的东西
• 基于代理的监视。 通过这些stream程在每个客户端上运行并收集数据。 这些数据被推送到监控服务器或监控服务器轮询代理。 一些pipe理员可以与代理商合作，其他人不喜欢他们，因为它可以在被监控的服务器上留下更大的空间。
• 专注的API（即VMWare API或运行SQL查询的能力）

如果您的环境或主操作系统中主要有一个操作系统，则某些系统可能有更多的选项供其他人使用。

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

configuration通常通过用户界面或文本文件完成。 用户界面选项通常会更容易，但是文本文件往往更适合重用和variables。 因此，根据您的IT人员，您可能更喜欢简单而不是权力。

用户界面 ：
目前监控系统最常用的界面是一个Web界面。 有些事情要评估的networking界面是：

• 好的概述
• 良好的细节页面
• 速度（当您需要在危机模式下查找信息时，缓慢的界面会非常令人沮丧
• 一般的感觉。 您将花费大量的时间在界面上，如果感觉笨重，您的IT人员会感到使用它的阻力
• 定制。 每个组织都有一些重要的东西，其他的东西是不重要的。 能够根据您的需求定制它是非常重要的

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

• 短信
• 电子邮件
• 电话
• 其他东西像IM / Jabber

其他function要查找的是：

• 升级（如果其他人没有确认或修复警报，请通知他人）
• 旋转和转移
• 团体（某些团体需要通知某些事情）

重要的是要相信，如果出现问题，你会得到警报。 这归结为两件事情：

1. 一个可靠的系统
2. 一个警告免费的configuration。 在监视系统中，认为你应该得到警报并不罕见，但是由于configuration的细节，从来没有触发警报。

数据存储 ：
如果系统收集和存储数据（即包括图表的系统）比系统存储数据。 商店和graphics的一个非常常见的实现是RRD。

从数据存储中查找的一些function是：

• 原始访问数据。 这对开发反对或创build像Excel一样的自定义graphics是有价值的。
• 可扩展性。 根据您收集的数据量多less，如果您要收集很多数据，请确保数据可扩展。

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

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

其他特性

报告 ：
提供良好报告的系统可以帮助您确定长期需要改进的方面。 例如，它可以很好地回答诸如“什么系统最糟糕？”。 当你试图说服pipe理层把钱花在某些事情上时，这一点很重要 – 企业就像是一个很好的证据。

专业特点 ：
有些监控系统针对的是特定的产品，或者比其他产品有更多的支持。 例如，如果你需要监视的主要东西是SQL服务器，或者如果你大量使用VMWare产品，你应该看看它们是如何被支持的。

预定义的监控模板 ：
一个带有很多预定义模板的系统（或者有一个创build了很多模板的用户库）可以节省很多时间。

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

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

一些stream行的监测系统

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

• Nagios的
• 仙人掌
• OpenNMS的
• 太阳风
• 各种基于云的监控系统
• Microsoft系统中心
• 这个还不是很受欢迎，但是Stack Exchange已经开源了它的监控系统http://bosun.org

如何根据以上内容来决定

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

区分监视和警报是有帮助的。 监测意味着收集数据和制作图表。 警报意味着当服务器在深夜中停机时向我发送短信。

Nagios用于提醒。 仙人掌和Munin是监测。 其他产品结合了这两个function。 Zenoss和Zabbix就是例子。

我首先回答一些问题：

你需要监视服务器，networking设备，应用程序，还是三者？

您可以使用什么方法来监控是否有限制？ 你可以在服务器上安装NRPE等监控客户端，还是使用SNMP，或者两者兼而有之？

谁将使用图表，谁将使用警报？ 你想要什么样的最终结果？ 界面的外观和感觉是否会影响业务人员（或者只有技术人员）？

你在时间，技能和硬件方面的资源是什么？ 你是否至less有一定的脚本能力？ 你需要一个开箱即用的解决scheme吗？

在我看来，警报和监控的第一条规则应该是保持简单！ 一个组织可以生活或死亡的方式来提醒和收集数据，大多数情况下，它自己会变得复杂。 从基础开始，从那里build立。

TL;博士

考虑一下你的软件提供的服务，在这些服务失败时发送提醒，或者这些服务失败的风险增加。

服务等级协定

监控策略背后的理论是将监控和警报与某种服务级别协议联系起来 。 毕竟，你需要注意到你正在亏钱的事实，并不一定是与nji0019.myserver.com的TCP连接数量激增。 有各种各样的工具，会给你吨警报，定义警报之间的依赖关系，但其中许多检查是不直接与您提供给某人的服务相关。

违反服务

确定您提供的重要服务，例如为网站提供服务的能力，以及修改该网站（例如某种CMS）的能力。 这些应该检查（例如通过监视你可以得到的网页，你可以）。 这两个服务（在这里与大写字母S一起使用）的失败应该触发警报通知你。

如果站点在合理的时间内响应很重要，那么也应该触发警报。 如果您愿意的话，可以select“违反SLA”。

风险增加

通常情况下，服务出现故障的风险是固有的，通常情况下，由于引入冗余（如第二台服务器，从数据库或额外的网卡），风险可能会降低。

当这个冗余丢失的时候，服务还是不错的，但服务失败的风险只是上升了。

这是触发警报的第二个主要原因; （例如，第二台服务器死亡），或存在风险将会增加的迫切危险（例如，磁盘仅剩500Mb，或磁盘趋势表示磁盘将在大约5小时内满）。

那么所有这些指标呢？

但check_mk给我每个主机50-60检查，这些都是毫无价值的？

不是，所有这些并不意味着你想排除自动检查过多的情况，例如check_mk，但是这意味着你应该尝试将每个检查分类成哪些服务可能会受到影响。

如果/ var /分区填满了什么服务会受到影响？ 如果eth0接口closures，会影响哪些服务？ …如果出站TCP连接被某些防火墙阻止？ …如果线程数超过800？ 如果数据库closures了

例

你有2台Web服务器，还有一台数据库服务器，服务于你不拥有的负载均衡器（比如ISP）后面的站点。 您提供的服务是两台服务器上的端口80，并且它们具有巨大的caching，可以在数据库停机时间（第三台服务器上的数据库）中生存。

在这种情况下，Web服务器的完全故障不会导致网站停机。 发生的事情是冗余度消失了，所以失败的风险就上升了。 这应该会触发警报。

完全失败的数据库可能不会影响服务该网站的能力，因为调整好的caching已经到位; 这并不影响为网站提供服务，但可能会影响不同的服务，即更新网站或接受订单。

每个服务都有自己的服务级别，指明恢复服务或避免中断的重要性

敏捷

每当您收到警报时，您都应执行以下操作之一： – 更改要监控的系统，以解决导致警报的问题（例如更换驱动器或重新configuration日志转换器或其他） – 更换监控系统以避免警报在下一次出现这种情况时发出。 （例如更改“磁盘空闲”的级别，以便磁盘可以填充高达90％，而不是只有80％）

我自己的经验

我大多熟悉Nagios及其详细的configuration，并且已经被Check-mk的多站点所吸引。 我最近了解到check_mk有这个商业智能的概念（从1.11开始），这似乎很好地符合这个想法。 你可以定义在Nagios中的检查是一个更大的服务的一部分，并且有一些规则将“服务”的状态定义为许多检查状态的函数，聚合到最坏或最好的状态。

公司在select监控解决scheme时忽略了最重要的一点， 那就是解决即时的运营问题并不是全部，而是关于明天的无法预料的问题！ 我的意思是，当然，解决眼前的问题是重要的，但相信我，在很多情况下，这种短视的策略并不能保证公司的生存。

市场上有很多很棒的监控解决scheme。 根据您的要求筛选一小组解决scheme是一项困难且长期的任务，而且，find适合您的预算的解决scheme更为困难。 有趣的部分是find一个符合你的现在和你的未来 。 而且没有评估过程来检测，这是一个经验+直觉+一个非常重要的因素： 信任 ，这不是一件容易的事情破解 。

作为一个经验法则，您可以search和挖掘您的入围监控解决scheme的成功案例 ，特别是如果它影响到您所在行业的公司。 向供应商询问他们的成功案例，甚至要求他们允许与他们的客户交谈。 不怕这样的公司表明他们与客户有真正的关系，他们不会隐瞒这一点，这是现在发现的极为罕见的事情。

Zabbix，Icinga，Pandora FMS，op5，Datadog，New Relic …他们都有起起落落，但真正的问题是find哪一个更适应您的未来。

如果您正在考虑远程系统监视，那么查找执行testing的实际位置可能是个好主意。 连接性问题不是过去的事情，如果您的硬件在特定地区提供服务，则可能需要确保您的资源在特定位置可用。