Answers:
有很多监控解决方案。每个人都有自己的偏好，每个企业都有自己的需求，因此没有正确的答案。但是，我可以帮助您确定在选择监视解决方案时可能要寻找的内容。
通常，监视系统有两个主要目的。首先是随着时间的推移收集和存储数据。例如，您可能想收集CPU利用率并随时间绘制图形。第二个目的是在事物没有响应或不在特定阈值内时发出警报。例如，如果ping无法访问某个服务器，或者CPU利用率高于一定百分比，则可能需要警报。也有诸如Splunk之类的日志监视系统，但为此我将它们视为独立的。
这两个主要角色有时会出现在单个产品中，而有时更常见的是拥有一个专门用于每种目的的产品。
轮询器：
所有监视系统都需要某种轮询器来收集数据。并非所有数据都以相同的方式收集。您应该查看您的环境并确定所需的数据以及如何收集它们。然后确保您选择的监视系统支持所需的功能。一些常见的方法包括：
如果您的环境中主要是一个操作系统或一个主操作系统，则某些系统可能具有比其他系统更多的选择。
配置：
在监视系统中，往往有很多对象重用。例如，您要监视一堆服务器上的某些应用程序，例如Apache或IIS。或者，您希望某些阈值适用于服务器组。您可能还会有某些人在“待命”。因此，良好的模板系统对于监视系统至关重要。
配置通常是通过用户界面或文本文件完成的。用户界面选项通常会更简单，但是文本文件在重用和变量方面往往更好。因此，根据您的IT员工，您可能更喜欢简单而不是功能。
用户界面：
如今，监视系统最常用的界面是Web界面。关于Web界面需要评估的一些事情是：
警报引擎：
警报引擎必须灵活且可靠。有很多不同的通知方式，包括：
要寻找的其他功能是：
重要的是要相信，当出现问题时，您会收到警报。这归结为两件事：
数据存储：
如果系统收集和存储数据（即包含图形的系统），则比系统存储数据。例如，RRD是一种非常常见的用于存储和作图的实现。
从数据存储中寻找的一些功能包括：
图形库：
图形可用于快速识别趋势并根据其历史为当前状态提供上下文。其中包括趋势分析，有助于在事情发生之前进行预测（即，磁盘空间用尽）。确保图表可以清楚地为您提供您认为需要的信息。
访问控制：
如果您的组织规模较大，则可能需要访问控制，因为某些管理员只能调整某些内容。您可能还需要面向公众的仪表板。如果这很重要，则应确保监视系统具有所需的控件。
报告：
提供良好报告的系统可以帮助您确定需要长期改进的内容。例如，它可以很好地回答诸如“哪些系统故障最严重？”之类的问题。当您试图说服管理层将钱花在某些事情上时，这一点很重要。
特殊功能：
某些监视系统针对特定产品或具有比其他系统更多的支持。例如，如果您需要监视的主要对象是SQL Server，或者如果您大量使用VMWare产品，则应该了解它们的支持程度。
预定义的监视模板：
带有许多预定义模板（或具有创建了许多模板的用户群）的系统可以节省大量时间。
发现：
如果您的环境很大或正在变化。某些系统提供了通过API添加新系统或运行扫描以查找新服务器或组件的功能。
分布式监视：
如果要监视多个位置，则在每个位置都具有监视轮询器将很有帮助，而不是通过WAN监视许多独立的系统。
那里有很多监视系统。我们有一个清单，上面有关于这个老问题的摘要。作为快速参考，我听到最多的是：
我无法告诉您使用什么的原因是因为每个组织都有自己的需求。如果您要做出正确的选择，则应仔细考虑以上所有组件，并确定哪些功能对您的组织很重要。然后找到一个声称提供您所需要的系统，然后尝试一下。其中一些花费很少，很多或者是免费的。考虑到所有这些，您就可以做出选择。从我的使用来看，它们远非完美，但至少您可以尝试获得合适的东西。
区分监视和警报很有帮助。监视意味着收集数据并制作图表。警报意味着在半夜服务器关闭时向我发送一条SMS。
Nagios用于警告。仙人掌和穆宁用于监测。其他产品结合了这两种功能。Zenoss和Zabbix是示例。
我首先要回答一些问题：
您需要监视服务器，网络设备，应用程序还是全部三个？
可用于监视的方法是否有限制？您可以在服务器上安装诸如NRPE之类的监视客户端，还是使用SNMP，或者两者都使用？
谁将使用图表，谁将使用警报？您希望最终结果如何？界面的外观和感觉是否重要（商务人士将使用此界面，还是仅使用技术人员？）
您在时间，技能和硬件方面都有哪些资源？您至少具有适度的脚本编写能力吗？您是否需要开箱即用的解决方案？
我认为，警报和监视的第一条规则应该是保持简单！组织可以依靠或不依靠警报和收集数据而生存或死亡，并且在大多数情况下，无论如何它都会变得很复杂。从基础开始，然后从那里开始构建。
考虑您的软件提供的服务，在这些服务失败或这些服务失败的风险增加时发送警报。
监视策略背后的理论是将监视和警报与某种服务级别协议相关联。毕竟，您想提醒您您正在赔钱的事实，不一定是与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中的支票是较大服务的一部分，并具有将“服务”状态定义为许多支票状态的函数的规则，这些状态汇总到最差或最佳状态。
公司在选择监视解决方案时忘记的最关键的观点之一是，这不只是解决眼前的运营问题，而是解决明天的不可预见的问题！我的意思是，当然，解决眼前的问题固然重要，但请相信我，在很多情况下，这种短视策略无法保证公司的生存。
市场上有数十种出色的监控解决方案。列出满足您要求的一小部分解决方案是一项艰巨而漫长的任务，此外，找到适合您预算的解决方案更加困难。有趣的部分是找到一个与您现在和您的未来相符的东西。而且也没有评估过程来检测，它的经验+直觉+一个非常重要的因素的问题：信任，这并不是一件容易的事情破解。
根据经验，搜索并挖掘入围的监视解决方案集的成功案例，尤其是当它影响您所在行业的公司时。向供应商询问他们的成功故事，甚至向他们征求与他们的一位客户交谈的许可。不怕这种情况的公司表明，他们与客户之间有着真实的关系，而且他们并没有隐瞒这一点，这在当今是极为罕见的事情。
Zabbix，Icinga，Pandora FMS，op5，Datadog，New Relic ...它们都有起伏，但真正的问题是要找到哪种更适合您的未来。
如果您正在考虑进行远程系统监视，那么最好查找执行测试的实际位置。连接性问题已不再是过去的事情，如果您的硬件为特定区域中的某个组提供服务，则可能需要确保您的资源在该特定位置可用。