业界主流运维监控比对

1、监控系统概述

监控系统是一种可以对特定设备、网络、应用程序或服务进行实时监控和管理的技术。监控系统的主要目的是检测和识别系统或服务的故障或异常，以便能够在问题发生之前识别和纠正它们。监控系统可以帮助企业或组织实时了解其系统或服务的健康状况，并做出相应的决策。

监控系统通常由以下几个组成部分：

1.监控代理：它们是在被监视的设备或服务上安装的软件或硬件组件，它们收集数据并将其发送到监控系统进行处理和分析。

2.监控服务器：它们是处理和存储来自监控代理的数据的计算机。监控服务器通常拥有强大的计算能力和存储能力，以便处理和存储大量的监控数据。

3.监控控制台：它是监控系统的用户界面，通常是一个Web应用程序或客户端，用户可以通过它来查看系统或服务的实时状态、性能和运行状况，以及查看历史数据和生成报告等。

监控系统通常可以监控网络流量、服务器资源使用率、应用程序性能、安全事件和用户活动等方面的数据。这些数据可以用来识别潜在的问题并及时解决它们，从而提高系统的可靠性、性能和安全性。

2、监控目标

监控系统的目标是提供实时、准确的系统性能和状态数据，以帮助管理员和运维人员及时发现和解决问题，从而实现以下几个目标：

1. 预防系统故障：监控系统可以及早发现系统中的异常，如网络拥塞、硬件故障、软件崩溃等，从而提前预防系统故障，减少停机时间和对业务的影响。
2. 提高系统性能：监控系统可以检测系统性能瓶颈和资源利用率，优化系统配置和调整资源分配，从而提高系统的性能和可扩展性。
3. 提高系统安全性：监控系统可以检测安全事件和gong击，如恶意软件、入侵、数据泄漏等，从而及时采取安全措施，保护系统和数据的安全性。
4. 优化运维效率：监控系统可以自动化和简化监控和管理任务，减少人工干预，从而提高运维效率和降低管理成本。
5. 改进用户体验：监控系统可以检测应用程序或服务的性能和可用性，从而帮助企业或组织提高用户体验，提高用户满意度。

监控系统的目标是为企业或组织提供实时的系统性能和状态数据，从而提高系统的可靠性、性能、安全性和用户体验，同时也为企业或组织提供更高效、更可靠的运维管理和资源利用方式。

3、监控作用和价值

监控系统是运维系统或平台系统中较为核心的组成部分，它承载了运维工作中数据闭环的部分。从功能角度，监控系统分为数据采集功能、数据上报功能、数据存储功能、告警功能、大屏功能、报表功能等功能模块；从技术场景角度，监控系统又可以分为机房监控、硬件监控、网络监控、操作系统监控、中间件监控、云平台监控、业务监控、拨测监控等垂直技术领域；从业务场景角度，监控系统还可以分为资源类监控、成本类监控、审计类监控、质量类监控、运营类监控、安全类监控等垂直业务领域。

监控系统在现代互联网技术中具有非常重要的作用和价值，主要体现在以下方面：

1. 系统可靠性和稳定性：监控系统可以实时监测系统的运行状态、性能指标和错误日志，及时发现故障并进行处理，从而保证系统的可靠性和稳定性。
2. 性能优化：监控系统可以通过分析性能数据，发现系统中的瓶颈和性能瓶颈，从而进行优化和改进，提高系统的性能和响应速度。
3. 安全保障：监控系统可以监测网络流量、安全日志和异常事件，发现和处理安全威胁，提高系统的安全性和防御能力。
4. 预测性维护：监控系统可以通过收集和分析设备传感器数据，预测设备故障，并及时进行维护，避免设备损坏和停机造成的损失。
5. 费用控制：监控系统可以通过数据分析和自动化处理，提高管理效率，减少不必要的人工成本和管理费用。
6. 决策支持：监控系统可以提供实时数据和分析结果，帮助管理者进行决策，优化业务流程和提高管理效率。

监控系统可以帮助企业和组织提高系统可靠性、性能、安全性和效率，降低成本和风险，为企业和组织的业务发展提供有力的支持和保障。

在稳定性保障体系中，核心就是在干一件事，减少故障。我们可以看一下故障的生命周期：

减少故障有两个层面的意思，一个是做好常态预防，不让故障发生；另一个是如果故障发生，要能尽快止损，减少故障时长。而监控的典型作用，就是帮助我们发现及定位故障，这两个环节对于减少故障时长至关重要。

运维人员和研发人员是典型的关注稳定性的人，不过侧重点不同。发生故障的时候，运维人员更希望快速找到问题根因，及时止损。而研发人员，更希望能“自证清白”。不管出于何种目的，监控都是不可或缺的工具。

其实，监控的作用还有很多，比如用于日常巡检，作为性能调优的数据佐证，提前发现一些设备、中间件不合理的配置。

随着时代的发展，监控也从最开始的一句话需求 -- 及时感知系统出现的问题，发展到了希望预知问题，并且可以洞察业务经营数据，越来越多的诉求让我们逐渐意识到监控的重要作用。

4、业界主流监控系统

现在运维监控工具非常多，对于监控系统的选型需要充分了解其优缺点再做决定，在个人职业生涯中，早期使用过cacti、nagios，在阿里期间先后使用过dragoon、alimonitor、sunfire，再到后面使用过zabbix、promethus，后面使用过小米开源的Open-Falcon、滴滴开源的Nightingale，一些商业版监控工具平台也了解过，接下来重点介绍开源监控系统。

4.1Cacti

Cacti是一套基于PHP，MySQL，SNMP及RRDTool开发的网络流量监测图形分析工具。简单的说Cacti就是一个PHP程序。它通过使用SNMP协议获取远端网络设备和相关信息（其实就是使用Net-SNMP 软件包的snmpget 和snmpwalk 命令获取）并通过RRDTOOL工具绘图，通过PHP程序展现出来。我们使用它可以展现出监控对象一段时间内的状态或者性能趋势图。

4.1.1Cacti监控服务器原理

Cacti是一款功能相对简单、易于使用的监控系统，具有以下优点和缺点：

4.1.2 优点：

1. 易于安装和配置：Cacti的安装和配置过程相对简单，可以快速搭建起一个基础的监控系统。
2. 数据源丰富：Cacti支持多种数据源，包括SNMP、MySQL、XML、JSON等，可以监测多种设备和应用程序。
3. 数据图表展示：Cacti可以创建各种类型的数据图表，包括线性图、条形图、面积图等，同时支持数据聚合、汇总和历史数据查询。
4. 自动化任务：Cacti支持自动化任务和计划，可以自动收集数据、生成报告、发送警报等。
5. 插件扩展：Cacti支持丰富的插件和主题扩展，可以增强其功能和视觉效果。

4.1.3 缺点：

1. 功能相对简单：相对于其他监控系统，Cacti的功能相对简单，不够灵活和扩展性。
2. 数据处理能力相对有限：Cacti的数据处理和查询能力相对有限，对于大规模和高复杂性的监控场景可能需要更为专业和灵活的监控系统。
3. 警报功能有限：Cacti的警报功能相对有限，不能实现复杂的警报规则和多种警报通知方式。
4. 界面视觉效果较弱：相对于其他监控系统，Cacti的界面视觉效果较弱，不够美观和易用。

总的来说，Cacti适用于中小型网络和系统管理，可以帮助用户监控其IT基础设施和应用程序的性能和可用性。但是，对于大规模和高复杂性的监控场景，可能需要更为专业和灵活的监控系统。

4.2Nagios

Nagios是一款开源的免费网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。

4.2.1Nagios监控服务器原理

Nagios的优点和缺点如下：

4.2.2优点：

1. 功能强大：Nagios的功能非常强大，可以满足各种监控需求，支持各种复杂的监控对象和规则。
2. 扩展性强：Nagios支持各种插件和扩展，可以实现自定义监控对象和规则，满足各种监控需求。
3. 可扩展性强：Nagios的配置文件和脚本语言具有很强的灵活性和扩展性，可以满足各种复杂的监控需求。
4. 社区活跃：Nagios拥有庞大的用户和开发社区，可以获得丰富的资源和支持。
5. 可靠性高：Nagios是一款成熟稳定的监控系统，被广泛应用于各种企业和组织中。

4.2.3缺点：

1. 学习成本高：Nagios的学习曲线相对陡峭，需要较长的学习时间和技能积累。
2. 配置复杂：Nagios的配置文件和脚本语言相对复杂，需要一定的编程技能和经验。
3. 界面较为简单：Nagios的界面较为简单，视觉效果和用户体验相对较弱。
4. 一些功能需要插件支持：Nagios一些功能需要插件和扩展支持，需要用户自行安装和配置。

Nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置，这样很容易出错，不宜维护。

4.3Zabbix

zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。

zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X等平台上。

4.3.1 Zabbix的工作原理

Zabbix agent 安装在被监控的主机上，zabbix agent负责定期收集客户端本地各项数据，并发至 Zabbix server端，zabbix server收到数据后，将数据存储到数据库中。

用户基于Zabbix Web可以看到数据在前端展现图像。

当Zabbix监控监控某个具体项目，该项目会设置一个触发器阈值，当被监控的指标超过触发器设定的阈值，会进行一些必要的动作，动作包括: 发送信息（邮件、微信、短信、电话，钉钉）、发送命令（shell命令、rebbot、restart、install等）

当告警后，根据告警机制可以先自动处理（比如使用shell脚本启动nginx服务等），自动处理不了的，就会通知对应的运维人员进行处理。

4.3.1原理总结：

zbbix_server 服务端可以通过主动或被动的方式获取到zabbix_agent客户端的数据，zabbix_server拿到数据后进行分析，存放到自己的数据库中，zabbix再将数据给到web_server，然后用户通过client访问web_server的UI界面访问

4.3.2 Zabbix的优点和缺点如下：

4.3.2.1 优点：

1. 功能强大：Zabbix的功能非常强大，可以满足各种监控需求，支持各种复杂的监控对象和规则。
2. 自定义性强：Zabbix支持自定义监控项和模板，可以实现自定义监控对象和规则，满足各种监控需求。
3. 界面友好：Zabbix的界面友好、直观，支持多语言，用户体验好。
4. 灵活性强：Zabbix的配置文件和脚本语言具有很强的灵活性和扩展性，可以满足各种复杂的监控需求。
5. 多平台支持：Zabbix可以在多种平台上运行，包括Linux、Unix、Windows等。
6. 社区活跃：Zabbix拥有庞大的用户和开发社区，可以获得丰富的资源和支持。

4.3.2.2 缺点：

1. 学习成本高：Zabbix的学习曲线相对陡峭，需要较长的学习时间和技能积累。
2. 配置复杂：Zabbix的配置文件和脚本语言相对复杂，需要一定的编程技能和经验。
3. 需要手动调整：Zabbix在某些情况下需要手动调整性能参数。

zabbix解决了cacti没有告警的不足，也解决了nagios不能通过web配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix也成为目前中小企业监控最流行的运维监控平台。

当然，zabbix也有不足之处，它消耗的资源比较多，如果监控的主机非常多时，可能会出现监控超时、告警超时等现象，不过也有很多解决办法，比如提高硬件性能、改变zabbix监控模式等。

4.4Open-Falcon

Open-Falcon是一款开源的分布式监控系统，用于监测大规模分布式系统的各种指标、状态和异常。Open-Falcon 出现在 Zabbix 之后，开发的初衷就是想要解决 Zabbix 的容量问题，Open-Falcon 最初来自小米，14 年开源。

4.4.1Open-Falcon架构

4.4.2 Open-Falcon的优点和缺点如下：

4.4.2.1优点：

1. 分布式架构：Open-Falcon采用分布式架构，可以方便地部署和扩展，支持多种数据源和存储方式。
2. 多种监控方式：Open-Falcon支持多种监控方式，可以监测网络设备、服务器、应用程序等多种对象。
3. 高可用性：Open-Falcon的各个组件均可部署多份，实现高可用性，支持故障自动切换。
4. 开放性强：Open-Falcon是一款开源的监控系统，具有开放性和灵活性，可方便地进行二次开发和扩展。
5. 界面友好：Open-Falcon的界面直观、易用，支持多语言，用户体验好。
6. 历史数据存储：Open-Falcon可以存储历史数据，并支持快速查询和可视化。

4.4.2.2缺点：

1. 学习曲线陡峭：Open-Falcon的学习曲线相对陡峭，需要一定的技能积累。
2. 配置复杂：Open-Falcon的配置较为复杂，需要一定的编程技能和经验。
3. 社区相对较小：Open-Falcon的用户和开发社区相对较小，生态不够庞大，是小米公司在主导，资源相对有限。

总的来说，Open-Falcon是一款功能强大、灵活性强的分布式监控系统，适合用于大规模分布式系统的监控和管理。

4.5Prometheus

Prometheus 的设计思路来自 Google 的 Borgmon，师出名门，就像 Borgmon 是为 Borg 而生的，而 Prometheus 就是为 Kubernetes 而生的。它针对 Kubernetes 做了直接的支持，提供了多种服务发现机制，大幅简化了 Kubernetes 的监控。

在 Kubernetes 环境下，Pod 创建和销毁非常频繁，监控指标生命周期大幅缩短，这导致类似 Zabbix 这种面向资产的监控系统力不从心，而且云原生环境下大都是微服务设计，服务数量变多，指标量也呈爆炸态势，这就对时序数据存储提出了非常高的要求。Prometheus 1.0 的版本设计较差，但从 2.0 开始，它重新设计了时序库，性能、可靠性都有大幅提升，另外社区涌现了越来越多的 Exporter 采集器，非常繁荣。

4.5.1 prometheus架构图

4.5.2 Prometheus的优点和缺点如下：

4.5.2.1 优点：

1. 多维数据模型：Prometheus以多维数据模型为基础，支持灵活的查询和聚合。
2. 支持多种数据源：Prometheus可以监控多种数据源，包括应用程序、操作系统、中间件等。
3. 实时查询：Prometheus支持实时查询，可以实时获取数据并进行监控。
4. 警报功能：Prometheus支持警报功能，可以根据自定义的规则进行警报。
5. 可视化：Prometheus可以将监控数据可视化，支持多种可视化方式，包括图表、仪表盘等。
6. 开放性强：Prometheus是一款开源的监控系统，具有开放性和灵活性，可方便地进行二次开发和扩展。

4.5.2.2 缺点：

1. 数据存储：Prometheus的数据存储机制比较特殊，不适合存储大量历史数据。
2. 学习曲线陡峭：Prometheus的学习曲线相对陡峭，需要一定的技能积累。
3. 依赖于exporter：Prometheus依赖于exporter进行数据采集，需要开发人员编写exporter。
4. 易用性差一些，比如告警策略需要修改配置文件，协同起来比较麻烦。当然了，对于 IaC 落地较好的公司，反而认为这样更好，不过在国内当下的环境来看，还无法走得这么靠前，大家还是更喜欢用 Web 界面来查看监控数据、管理告警规则。
5. 容量问题，Prometheus 默认只提供单机时序库，集群方案需要依赖其他的时序库。

总的来说，Prometheus是一款功能强大、灵活性强的监控系统，适合用于系统、应用程序、中间件等各种资源的监控和管理。但是，它也有一些局限性，例如数据存储机制不适合存储大量历史数据、告警配置繁琐等问题。

4.6 Nightingale

Nightingale  可以看做是  Open-Falcon  的一个延续，因为开发人员是一拨人，不过两个软件的定位截然不同，Open-Falcon  类似 Zabbix，更多的是面向机器设备，而 Nightingale  不止解决设备和中间件的监控，也希望能一并解决云原生环境下的监控问题。

但是在  Kubernetes  环境下，Prometheus  已经大行其道，再重复造*意义不大，所以  Nightingale  的做法是和  Prometheus  做良好的整合，打造一个更完备的方案。当下的架构，主要是把  Prometheus  当成一个时序库，作为  Nightingale  的一个数据源。如果不使用  Prometheus  也没问题，比如使用  VictoriaMetrics  作为时序库，也是很多公司的选择。

4.6.1Nightingale系统架构

4.6.2 Nightingale的优点和缺点如下：

4.6.2.1优点：

1. 有比较完备的 UI，有权限控制，产品功能比较完备，可以作为公司级统一的监控产品让所有团队共同使用。Prometheus 一般是每个团队自己用自己的，比较方便。如果一个公司用同一套 Prometheus 系统来解决监控需求会比较麻烦，容易出现我们上面说的协同问题，而 Nightingale 在协同方面做得相对好一些。
2. 兼容并包，设计上比较开放，支持对接 Categraf、Telegraf、Grafana-Agent、Datadog-Agent 等采集器，还有 Prometheus 生态的各种 Exporter，时序库支持对接 Prometheus、VictoriaMetrics、M3DB、Thanos 等。

4.6.2.2缺点：

1. 考虑到机房网络割裂问题，告警引擎单独拆出一个模块下沉部署到各个机房，但是很多中小公司无需这么复杂的架构，部署维护起来比较麻烦。
2. 告警事件发送缺少聚合降噪收敛逻辑，官方的解释是未来会单独做一个事件中心的产品，支持 Nightingale、Zabbix、Prometheus 等多种数据源的告警事件，但目前还没有放出。
3. 社区支持不够：相比于一些国际知名监控系统，Nightingale的社区支持相对不够，有些插件需要用户自行解决问题。