运维监控解析
在现代信息化环境中，运维监控是保障系统稳定运行、及时发现并处理潜在问题的基石。运维监控关乎硬件层面的健康状态，深入到软件、网络及应用等多个维度，形成一个全面、细致的监控体系。
本文说明几种常见的运维监控对象，结合自动化监控工具、数据可视化与报警通知等关键环节，为读者呈现一个完整的运维监控蓝图。
核心要点
- 运维监控的对象通常包括服务器、网络、数据库和中间件组件、应用、业务指标，以及告警 OnCall 流程。
- 服务器和网络监控解决基础资源与连通性问题；组件和应用监控解决服务运行质量问题；业务监控解决真实业务影响问题。
- 监控系统选型不应只看采集能力，还要看存储、可视化、告警、排班、认领、升级和降噪能力。
- 一个成熟体系通常会同时使用采集器、时序数据库、仪表盘、告警引擎和 OnCall 平台，而不是只依赖单一工具。
服务器监控
服务器监控是运维监控的核心组件，其重点在于实时监控服务器的关键性能指标，包括CPU利用率、内存使用情况、硬盘空间以及网络带宽等。这些指标直接反映服务器的负载能力和资源状况，是运维人员判断服务器性能瓶颈或资源不足的重要依据。
在实际操作中，运维人员通常会采用专业的服务器监控工具（比如 Zabbix、Prometheus、Nightingale、Open-Falcon 等）。这些工具能够实时收集服务器的运行数据，进行深度分析，并以报告或仪表盘的形式呈现给运维人员。通过这些数据，运维人员可以直观地了解服务器的当前状态，及时发现并解决潜在问题。
网络监控
网络监控是确保系统稳定运行不可或缺的一环。主要关注网络设备、交换机、路由器等的工作状态，以及带宽利用率、丢包率等关键参数。通过网络监控，运维人员可以及时发现网络故障和瓶颈，确保数据的顺畅传输。
在网络监控方面，部分工具表现出色。它们能够实时监控网络设备的运行状态，提供详细的性能报告，帮助运维人员快速定位并解决网络问题。
网络设备的监控主要是采用 SNMP 和 Telemetry 等技术，难点是不同的厂商指标定义方式不同，需要做大量的适配工作，才能实现统一的监控。
除了网络设备的监控，也别漏了网络连通性和网络质量的监控，典型的手段比如 ICMP Ping，典型的产品比如 Pingmesh，可以方便的得知各个网元之间的连通性和质量，Pingmesh 最初出自微软的一篇论文，Flashcat 中也包含了 Pingmesh 的功能。
组件监控
这里的组件是指数据库、中间件等一些常用的开源组件，社区里最常用的开源组件大概有上百种，比如 MySQL、Redis、Kafka、Nginx、Tomcat 等。当然，具体到某一个公司，不会用这么多，但也通常会用几十种。这些组件的监控，通常是通过它们的暴露的 API 来获取数据，然后通过监控工具进行展示。
这里的难点是不同的组件，暴露的指标方式不同，需要做大量的适配工作，而且每个组件，通常都暴露几十上百种指标，要理解这些指标的含义着实需要花费一些精力。通常需要对这些组件的原理有透彻理解才能更好的理解这些指标。
应用监控
应用监控通常是指对自研的各位微服务的监控。其实组件也可以看做应用监控的一种。应用监控通常分为 HTTP/TCP 监控以及后台跑批任务的监控。HTTP/TCP 监控主要是关注接口的吞吐（Request）、错误（Error）、延迟（Duration），也就是业内常说的 RED 方法论。后台跑批任务的监控，主要是关注任务的执行情况，比如任务是否正常执行，任务执行时间是否正常，任务执行结果是否正常等。
应用监控通常不止是指标层面的监控，还要对应用暴露的日志做采集监控，还要对应用统一埋点，做链路追踪，因为现在越来越多采用微服务架构，一个业务请求通常会经过多个微服务，如果没有链路追踪，很难定位问题。
业务监控
业务监控是指围绕业务量的监控，这类指标通常是一些老板比较关注的 BI 指标，但是相比 BI 数据，业务监控的数据通常要求实时性更好，对准确性倒不是特别关注，毕竟从监控角度，只要能发现数据的异常趋势就可以了，比如订单量下跌，至于是从 1000 跌到了 200 还是从 1005 跌到了 203，这里稍有不精确倒不是特别大的问题。
业务指标通常来自两个方面，一个是应用埋点，一个是从各种数据库中获取，比如订单量数据，通常都在关系型数据库里存着，只要定期去查询统计就可以了，但是不同公司会有不同的数据库选型，甚至有些公司是把关系型数据库里的数据同步到 ClickHouse、ElasticSearch、Hive 等数仓里了，这就需要监控产品能够适配各类数据源的查询。
运维监控系统选型
运维监控系统有很多，国内最常用的是 Zabbix、Prometheus、Nightingale，这些系统各有优劣和适用场景。通常来讲：
- Zabbix 适合小规模场景，擅长服务器、网络设备的监控
- Prometheus 适合 Kubernetes、微服务的监控，但是 Prometheus 需要配合 Grafana、VictoriaMetrics 等来使用，要不然 Prometheus 的可视化能力比较弱，存储是单机存储，都无法满足生产环境对稳定性的要求
- Nightingale 是国内开源的监控系统，适合大规模场景，其理念是对接各类存储做统一的告警引擎，这样就可以适配各类监控数据源
就笔者而言，数据采集推荐大家采用 Categraf 或各类 Exporter，监控数据存储建议大家采用 VictoriaMetrics，数据可视化建议大家采用 Grafana，告警引擎建议大家采用 Nightingale。
但实际情况是，各个公司通常都会采用不同的多套监控系统（加上云监控，数量就更多了），导致告警事件是从不同的监控系统产生的，有些监控系统支持告警聚合，有些不支持，大部分监控系统不支持告警排班、认领、升级这样的功能，这就需要一个统一的告警OnCall平台来做统一的告警分发。
常见监控方向对照表
| 监控方向 | 主要对象 | 典型指标或信号 | 主要价值 |
|---|---|---|---|
| 服务器监控 | 主机、虚拟机、容器节点 | CPU、内存、磁盘、网络、进程 | 发现资源瓶颈和基础故障 |
| 网络监控 | 交换机、路由器、链路、网元 | 带宽、丢包、延迟、连通性、设备状态 | 保障网络可达和传输质量 |
| 组件监控 | MySQL、Redis、Kafka、Nginx、Tomcat 等 | 连接、QPS、延迟、队列、缓存、错误 | 发现数据库和中间件异常 |
| 应用监控 | HTTP/TCP 服务、微服务、跑批任务 | RED 指标、日志、Trace、任务状态 | 定位接口和服务层问题 |
| 业务监控 | 订单、支付、用户、设备、交易链路 | 订单量、成功率、在线数、业务延迟 | 识别真实业务影响 |
| 告警 OnCall | 告警事件和响应流程 | 分派、排班、认领、升级、降噪 | 让告警进入闭环处理 |
建设顺序建议
- 先覆盖基础资源。服务器、网络和核心组件异常会影响上层所有系统，应该优先建立可视化和基础告警。
- 再覆盖应用入口。围绕接口的请求量、错误率和耗时建立应用健康视图。
- 补齐业务指标。用订单量、支付成功率、在线数等指标判断是否出现真实业务影响。
- 最后治理告警流程。把告警接入统一 OnCall，处理排班、分派、认领、升级和降噪。
告警OnCall
告警 OnCall 平台和各类运维监控系统是协同的关系。告警 OnCall 平台的主要功能是统一告警的分发、排班、认领、升级等功能。告警 OnCall 平台通常会和各类监控系统对接，接收告警事件，然后根据告警事件的严重程度、告警事件的类型、告警事件的来源、标签等信息，进行告警的降噪、分发。
国外比较有名的告警 OnCall 平台有 PagerDuty、OpsGenie，国内比较有名的告警 OnCall 平台有 Flashduty，这类产品通常不开源，按量付费，毕竟这些平台会承担电话、短信费用，没法免费提供。
总结
运维监控是保障系统稳定运行、及时发现并处理潜在问题的基石。它从服务器、网络、组件、应用延伸到业务指标，再通过告警 OnCall 完成响应闭环。在实际建设中，不要只追求“采集更多指标”，而要让每类监控对象都能回答一个清晰问题：哪里异常、影响什么、谁处理、下一步看哪里。
FAQ
Q1：运维监控应该先做哪一层？ A：通常先做服务器、网络和核心组件，再做应用监控和业务监控。基础层不稳定时，上层指标很难解释。
Q2：业务监控和 BI 数据有什么区别？ A：原文提到，业务监控更强调实时发现异常趋势，对绝对精确度的要求通常低于 BI；BI 更偏经营分析和报表口径。
Q3：为什么还需要告警 OnCall 平台？ A：监控系统负责发现异常，但告警还需要分发、排班、认领、升级和降噪。多套监控系统并存时，统一 OnCall 平台能让响应流程更清楚。
