[ 知识是人生的灯塔，只有不断学习，才能照亮前行的道路 ]

📢 大家好，我是 WeiyiGeek，一名深耕安全运维开发（SecOpsDev）领域的技术从业者，致力于探索DevOps与安全的融合（DevSecOps），自动化运维工具开发与实践，企业网络安全防护，欢迎各位道友一起学习交流、一起进步 🚀，若此文对你有帮助，一定记得倒点个关注⭐与小红星❤️，收藏学习不迷路 😋 。

文章目录：

前言简述

温故而知新，可以为师矣。

之前，作者在【Prometheus 入门学习】专栏中，简单介绍构建企业设备资源监控预警、以及可视化监控面板的搭建与实践，但是随着云原生、微服务架构蓬勃发展下，也随着作者的深入学习日志监控、链路追踪实践，随着监控系统在企业中越来越重要，作者也愈发感觉到，监控系统的三大支柱（指标、日志、链路追踪）对于运维人员来说要求也越来越高了。

在此基础上，作者也撰写了【可观测性监控实践】专栏，算是针对监控系统的三大支柱（指标、日志、链路追踪）的学习经验总结，最后用过一个实践案例，帮助各位看友从0️⃣到1️⃣，切实将监控可观测性入门到落地实践，希望大家多多支持，另外也可加入作者【全栈工程师修炼指南】知识星球获取实时专栏文章，相关工具脚本、可视化模板更新，以及问题答疑（推荐）。

原文连接：https://articles.zsxq.com/id_56lc2dpzeuiw.html

监控系统的需求背景

当下在云原生、微服务架构蓬勃发展下，作为一名资深的运维工程师，我深知监控系统对于维护服务稳定运行的重要性，这也是为保护数据资产必备，当系统出现宕机、服务不可用时，可以第一时间感知及处理，防止系统服务异常对企业造成经济损失。当然，随着各项技术的发展，我们对监控系统提出了更多的诉求，比如：

• 通过监控指标数据趋势，预测系统故障，提前进行干预，以后在故障发生后排除复盘；

• 通过监控系统资源状态，比如：CPU、内存、磁盘使用率等，为服务扩缩容提供数据支撑。

• 通过监控应用与服务指标，比如：请求数、响应时间等，为服务优化提供数据支撑，特别是一些中间件参数的调优，例如 Nginx、Tomcat 等等。

• 通过监控系统与服务日志，快速定位问题原因，缩短故障恢复时间。

目前监控系统越来越重要，同时也越来越完备。不但能够很好地解决上面这几点诉求，还沉淀出了很多监控系统中的稳定性相关的知识。当然，这得益于对监控体系的持续运营，特别是一些资深工程师的持续迭代更新的成果。

监控系统的可观测性三大支柱

当下企业级监控系统可观测性（Observability）的三大支柱通常包括指标（Metrics）、 日志（Logging） 和 链路追踪（Tracing），其中指标监控是其中的核心部分，日志解决程序异常定位和操作审计的关键工具，链路追踪是解决分布式系统复杂性问题的关键工具。

• 指标监控（Metrics）：通常只处理数字，但它的历史数据存储成本较低，实时性好，生态庞大，是可观测性领域里最重要的一根支柱，通过采集系统、应用与服务运行时的关键性能指标，比如CPU使用率、内存占用、请求数等，帮助我们了解系统的健康状况和性能表现，开源产品有：Zabbix、Open-Falcon、Nagios、Prometheus 推荐、Nightingale，VictoriaMetrics 推荐 等。例如作者企业中使用的是Prometheus + Grafana，通过 Grafana 搭建可视化面板，实现对指标数据的实时展示。

weiyigeek.top-Prometheus、grafana 图

• 日志监控（Logging）：通常处理文本，但它的历史数据存储成本较高，实时性较差，生态庞大，对于了解软件的运行情况、业务的运营情况都很关键。比如，网络接入层的日志、操作系统的日志、应用服务运行日志，都是重要的数据源，在网络接入层可获取外部访问以及设备网络网口事件，在操作系统日志中，获得系统操作审计日志，从应用服务可查询到访问信息，异常信息以及堆栈调用信息等，这也是满足等保日志存储要求必备的，开源产品有：ELK（Elasticsearch + Kibana + Filebeat）、PLG(Promtail + Loki + Grafana)、victoriametrics (victorialogs + vmui) 推荐、商业产品Splunk和Datadog等，例如作者企业中使用的是Promtail + Victoriametrics，通过 VMUI 可视化面板，实现对日志数据的实时展示。

weiyigeek.top-victorialogs 日志图

• 链路追踪（Tracing）：通常记录单个请求在分布式系统中流转的完整路径，包括经过的服务、调用的依赖、各阶段的耗时和状态。其流程是为每个请求生成一个唯一的标识符（TraceID），并通过这个标识符追踪请求在系统中的流转路径。通过这种方式，我们可以清晰地看到每个请求是如何在整个系统中被处理的，从而快速定位性能瓶颈或故障点（如慢查询、服务调用失败等）。例如，如果一个用户请求导致了服务延迟或失败，我们可以通过 TraceID 找到该请求。开源产品有：Zipkin、Skywalking、Jaeger 推荐、OpenTelemetry 推荐等。

企业级的监控系统结合上述的三大支柱，才能实现从宏观（指标）到微观（日志）、从聚合到单请求的全方位观测。例如，当应用发生故障，我们经常会从日志中提取指标，转存到指标监控系统，或者从日志中提取链路信息来做分析，所以说监控系统领域，对于我们运维人员来说要求也越来越高了。

作者将结合自身学习以及工作实践，撰写此文，为各位运友从零到一帮助你在工作中快速落地实践，希望各位运友也多多支持【可观测性监控实践】专栏。

监控系统的方案选型

为企业搭建部署一套监控系统，需要考虑的方面有企业环境的现状、监控系统的可扩展性、监控数据的存储成本、监控系统的易用性和维护成本等，此外，还需要考虑监控系统的开源产品社区活跃度、文档完善程度以及技术支持等因素；当然你也可以购买商业产品，这样也可以为你的企业监控提供定制化的服务；

但是作者所在企业体量没有这么庞大，更重要的是经费确实有限（等同于零），所以只能在开源的监控产品中兜兜转转，丢丢捡捡，所以开源且免费为主。

下面作者，简要列举一些目前主流的开源监控系统，供大家参考，想了解更多的可以参考作者后续文章，以及开源产品的Github或者官网：

• 指标监控系统：Nightingale（国产，方案整合商）、VictoriaMetrics、Prometheus、Zabbix、Nagios、Cacti

• 日志监控系统：VictoriaLog、PLG (Promtail + Loki + Grafana)、ELK (Elasticsearch + Kibana + Filebeat)

• 链路追踪系统：OpenTelemetry、Jaeger、SkyWalking、Zipkin

指标监控相关产品

在了解指标监控系统之前，我们先来回顾一下指标监控的发展历史：

时期	代表工具/技术	核心特点	局限性或挑战
1980s	SNMP (Simple Network Management Protocol)	早期网络设备监控标准，基于UDP协议，支持基础指标采集。	功能单一，扩展性差，安全性弱。
1990s	RRDtool (Round Robin Database)	时间序列数据存储和可视化，环形数据库设计节省空间。	手动配置复杂，缺乏分布式支持。
2000s	Nagios、Zabbix	支持告警、插件扩展（如NRPE），Zabbix加入自动化发现和可视化仪表盘。	集中式架构，大规模部署性能瓶颈。
2010s	Graphite、Prometheus	Graphite引入时间序列数据库；Prometheus采用拉模型、多维数据模型和PromQL。	Graphite无原生告警；Prometheus无长期存储。
2015+	InfluxDB、Telegraf	专为时序数据优化，支持高写入吞吐和SQL-like查询（InfluxQL）。	集群版本闭源，资源消耗较高。
2017+	Prometheus + Thanos/Cortex	通过Thanos/Cortex解决Prometheus长期存储和全局视图问题。	架构复杂度显著增加。
2020s	OpenTelemetry Metrics	统一指标标准，与Tracing/Logging集成，支持多后端导出（Prometheus等）。	生态仍在成熟中。
云平台	AWS CloudWatch、Grafana Cloud	云厂商全托管服务，结合AIops自动异常检测。	供应商锁定风险，成本随规模激增。

Zabbix - 老一代解决方案