[ 知识是人生的灯塔,只有不断学习,才能照亮前行的道路 ]
📢 大家好,我是 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 - 老一代解决方案