有哪些常见的运维监控方向？
运维监控解析
在现代信息化环境中，运维监控是保障系统稳定运行、及时发现并处理潜在问题的基石。运维监控关乎硬件层面的健康状态，深入到软件、网络及应用等多个维度，形成一个全面、细致的监控体系。
本文说明几种常见的运维监控对象，结合自动化监控工具、数据可视化与报警通知等关键环节，为读者呈现一个完整的运维监控蓝图。
服务器监控
服务器监控是运维监控的核心组件，其重点在于实时监控服务器的关键性能指标，包括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平台来做统一的告警分发。
告警OnCall
告警 OnCall 平台和各类运维监控系统是协同的关系。告警 OnCall 平台的主要功能是统一告警的分发、排班、认领、升级等功能。告警 OnCall 平台通常会和各类监控系统对接，接收告警事件，然后根据告警事件的严重程度、告警事件的类型、告警事件的来源、标签等信息，进行告警的降噪、分发。
国外比较有名的告警 OnCall 平台有 PagerDuty、OpsGenie，国内比较有名的告警 OnCall 平台有 Flashduty，这类产品通常不开源，按量付费，毕竟这些平台会承担电话、短信费用，没法免费提供。
总结
运维监控是保障系统稳定运行、及时发现并处理潜在问题的基石。运维监控关乎硬件层面的健康状态，深入到软件、网络及应用等多个维度，形成一个全面、细致的监控体系。在实际操作中，运维人员通常会采用专业的监控工具，实时监控服务器、网络设备、数据库、应用等的运行状态，及时发现并解决潜在问题。同时，告警 OnCall 平台的出现，为运维人员提供了更加高效的告警管理方式，提高了运维效率。
