什么是可观测性？监控、日志、追踪三者之间有什么区别？

原创 于 2025-06-30 11:49:15 发布 · 721 阅读 · 11 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #服务器 #数据库

一、引言：为什么现代系统需要“看得见”？

你是否遇到过这样的情况：系统运行突然变慢，但没人知道问题出在哪？随着微服务、云原生架构的普及，系统的复杂度越来越高，传统的“靠经验判断”已经无法满足需求。我们需要一种能力——可观测性（Observability），来帮助我们看清系统内部发生了什么。

本文将带你了解可观测性的三大核心支柱：监控（Metrics）、日志（Logs）、追踪（Traces），并解释它们之间的联系与区别。无论你是运维工程师、开发人员还是技术管理者，这篇文章都将为你提供宝贵的见解和实用技巧。

   

二、什么是可观测性？它和传统监控有何不同？

1. 可观测性的定义

可观测性指的是：通过观察系统的输出（如指标、日志、请求链路等），可以推断出系统内部状态的能力。它不仅仅是“看数据”，而是要能回答：“这个错误是怎么发生的？”、“为什么这个接口这么慢？”、“是哪个服务出了问题？”

2. 与传统监控的区别

特性传统监控可观测性
目标关注系统整体健康状态深入分析具体问题
数据类型预先定义好的指标动态获取上下文信息
适用场景单体应用、静态架构微服务、云原生、分布式系统
响应速度被动告警为主主动诊断、快速定位问题

传统监控通常只关注系统的基本健康状况，而可观测性则更注重于理解系统的行为和状态变化。它不仅能够告诉你哪里出了问题，还能告诉你为什么会出问题。

   

三、可观测性的三大支柱详解

✅ 1. Metrics（指标）——“宏观视角”的健康检查

（1）什么是 Metrics？

Metrics 是一组可聚合的数据点，通常以时间序列的形式存在，用于衡量系统的性能和状态。例如：CPU 使用率、内存占用、请求数量、响应时间等。

（2）常见的指标类型
  • 计数器（Counter）：只能递增，比如总请求数。
  • 计量器（Gauge）：可增可减，比如当前在线用户数。
  • 直方图（Histogram）：记录分布情况，如接口响应时间的 P50、P95 等。
（3）常用工具
  • Prometheus、Graphite、InfluxDB、Datadog
（4）适合解决的问题
  • “系统负载高吗？”
  • “某个接口的平均响应时间是多少？”
  • “今天请求量是不是比昨天多了很多？”

   

✅ 2. Logs（日志）——“微观视角”的详细记录

（1）什么是 Logs？

Logs 是系统在执行过程中产生的结构化或非结构化的文本记录，用于描述事件发生的时间、内容、严重程度等。

（2）日志的分类
  • 访问日志（Access Logs）：记录每次请求的基本信息，如 URL、状态码、耗时。
  • 错误日志（Error Logs）：记录异常、堆栈跟踪等调试信息。
  • 业务日志（Application Logs）：记录关键操作、流程节点等业务逻辑。
（3）日志的价值

提供上下文：不仅能告诉你“哪里错了”，还能说明“错在哪里”。支持搜索和过滤：方便排查特定用户、时间段或错误类型的日志。

（4）常用工具
  • ELK Stack（Elasticsearch + Logstash + Kibana）
  • Loki、Fluentd、Graylog
（5）适合解决的问题
  • “这个用户为什么会看到 500 错误？”
  • “为什么某个功能突然不生效了？”
  • “这段代码真的被执行了吗？”

   

✅ 3. Traces（追踪）——“端到端”的调用链分析

（1）什么是 Traces？

Traces 是对一次完整请求路径的记录，从客户端发起请求开始，经过多个服务、数据库、缓存等组件，直到返回结果为止。它关注的是“一个请求到底经历了哪些步骤”。

（2）基本概念
  • Trace ID：标识一次完整的请求。
  • Span：表示一个独立的操作单元，包含开始时间和持续时间。
  • Parent Span / Child Span：表示父子调用关系。
（3）典型应用场景
  • 微服务架构下的请求延迟分析
  • 分布式系统中故障定位
  • 性能瓶颈识别（如某个服务拖慢整个链路）
（4）常用工具
  • Jaeger、Zipkin、OpenTelemetry、SkyWalking、Datadog APM
（5）适合解决的问题
  • “这次请求到底卡在哪个服务了？”
  • “为什么这个接口花了 2 秒才返回？”
  • “有没有可能某个异步任务影响了主线程？”

   

四、三大支柱的关系与协作方式

维度MetricsLogsTraces
视角全局、统计型局部、事件型整体、路径型
时间粒度连续变化的时间序列单个事件记录请求级别的全生命周期
用途健康检查、趋势预测问题回溯、原因分析调用链分析、性能优化
工具组合建议Grafana + PrometheusKibana + ElasticsearchJaeger / Zipkin + OpenTelemetry

🎯 举个形象的例子：

  • 如果把系统比作一辆汽车：
    • Metrics 就像仪表盘上的油量表、转速表；
    • Logs 就像行车记录仪里的视频片段；
    • Traces 就像 GPS 的路线记录，告诉你车都去过哪。

   

五、实战案例：如何用可观测性解决一个线上问题？

背景介绍：

某电商平台首页加载缓慢，用户频繁刷新页面，导致服务器压力剧增。

初步分析：

  • 用户反馈“首页很慢”
  • 监控显示 QPS 正常，但平均响应时间上升

使用 Metrics 发现：

  • /api/homepage 接口的 P95 响应时间从 300ms 上升至 1800ms

查看 Logs：

  • 发现大量类似日志：

    [ERROR] Timeout when querying product service for featured products

分析 Traces：

  • 抽取部分 Trace，发现有 60% 的请求中，product-service 耗时超过 1s
  • 该服务依赖的 Redis 实例 CPU 达到 98%

最终结论：

  • Redis 实例资源不足，导致产品查询服务响应缓慢
  • 影响范围扩散到首页接口，最终造成用户体验下降

解决方案：

  • 扩容 Redis 实例
  • 添加缓存降级策略
  • 设置超时熔断机制

   

六、总结：可观测性不是锦上添花，而是雪中送炭

在复杂的现代系统中，可观测性已经成为运维、开发、SRE 必备的核心能力之一。它不仅帮助我们发现问题，更让我们能够主动预防问题的发生。

记住一句话：

监控告诉我们“系统有问题”，日志告诉我们“问题出在哪”，而追踪告诉我们“问题到底是怎么发生的”。

别再只盯着服务器 CPU 和内存了。现在就开始构建你的可观测性体系吧！

   

 推荐阅读

或者关注我的个人创作频道：点击这里

moppol
关注
使用 OpenTelemetry 打通全链路监控与可观测性
s13596191285的博客
05-25 90
使用 OpenTelemetry 打通全链路监控与可观测性
可观测性（一）
A13581861752的博客
04-21 4255
可观测性一词诞生于几十年前的控制理论。近年来，随着企业以微服务、⽆服务器和容器技术的形式迅速采⽤了AWS、阿里云等云原⽣基础设施服务。在这些分布式系统中追踪事件的起源需要在云上、本地或两者上运⾏的数千个进程。传统的监控技术和⼯具就很难跟踪这些分布式架构中的许多通信路径和相互依赖关系。更别提排查问题并定位根本原因了。 监控技术和工具革新迫在眉睫。 而可观测性一词近两年火起来的导火索是 CNCF 在云原生定义中提到 Observerbility，并声称这是云原生时代的必备能力。 于是从生产所需到...
监控(monitor)和可观测性(Observability)
legend050709的专栏
02-19 2746
可观测性
监控和可观测性之间的关系
u012516914的专栏
04-16 1479
讨论了监控和可观测性实践，以及它们如何帮助开发团队更好地理解软件中的 bug 和其他错误。IT 行业在最近已经变得指数级复杂——更多的环境、更多的连接设备、更多的数据和更多的发布更新。因此...
12 可观测性：监控与日志
汤瑞的博客
07-23 667
背景 监控和日志是大型分布式系统的重要基础设施，监控可以帮助开发者查看系统的运行状态，而日志可以协助问题的排查和诊断。 在k8s中，监控和日志属于生态的一部分，并不是核心组件，因此大部分的能力依赖上层的云厂商的适配。k8s定义了解毒的接口规范和标准，任何符合接口标准的组件都可以快速集成。 监控 监控的类型 资源监控 CPU、内存、网络等资源类的指标，常以数值、百分比为单位进行统计，是最...
可观测性与监控的区别和联系
爱死亡机器人
03-16 332
可观测性（Observability）是一种软件开发和系统构建的哲学，是对系统内部状态及行为的度量和推断能力，通常包括日志、指标、链路追踪等多个度量维度。也就是说，在软件开发和运维领域中，可观测性是指对于一个复杂的系统，能够通过监控、日志、指标、追踪等手段，快速地发现、诊断、解决问题的能力。
解惑“可观测性”与“监控”的不同
热门推荐
观测云的博客
03-23 1万+
在上一篇《运维,放过监控-也放过自己吧》中原作者提出了自己对于可观测性的三个困惑，本文围绕这三个问题展开讨论。 1.可观测性解决什么问题？ 其实可观测性最先解决的就是一个问题：就是监控工具太太太多了，在 Datadog 的招股书上就写得很明白一般企业要部署 5 套监控软件，而大型企业因为各种跨部门甚至要 15+，这种造成了资源浪费，学习曲线，认知成本，协同成本，系统更新等一系列的问题。 当然一切整合起来的可观测性，也和原来的监控不同了。其对象瞄准的恰恰是应用系统本身，也就是我们需要将自己所制造的.
IT系统为什么需要可观测性？
smth_mcmc的博客
11-22 869
争论 IT领域中，可观测性（observability）的争论源于2017年PeterBourgon（GoKit作者）的一篇文章《Metrics, tracing, and logging》。文中将可观测性问题映射到了如何处理指标（metrics）、追踪（tracing）、日志（logging）三类数据上。其后，Cindy Sridharan在其著作《DistributedSystemsObservability》中，进一步讲到指标、追踪、日志是可观测性的三大支柱（threepillars）。...
2024年云原生可观测性最佳实践：监控、日志与追踪
最新发布
AI云原生与云计算技术学院
05-30 928
在云原生时代，系统的复杂性和动态性呈指数级增长。微服务架构、容器化和Serverless技术的普及，使得传统的监控方式已无法满足现代分布式系统的需求。本文旨在为读者提供2024年最新的云原生可观测性实践指南，帮助构建高效、可靠且成本优化的可观测性系统。介绍可观测性的基本概念和三大支柱深入分析监控、日志和追踪的技术实现探讨现代可观测性架构设计提供实际案例和代码实现分析最佳实践和未来趋势可观测性(Observability): 通过系统外部输出推断内部状态的能力监控(Monitoring)
日志-全链路-可视化-可观测性-美团技术团队
Java程序员的知识博客
01-19 1187
传统的ELK方案是一种滞后的业务追踪，需要事后从大量离散的日志中搜集和筛选出需要的日志，并人工进行日志的串联分析，其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时，实时地完成了链路的动态串联，但由于是会话级别且仅关注于调用关系等问题，导致其无法很好地应用于业务追踪。因此，无论是传统的ELK方案还是分布式会话跟踪方案，都难以满足日益复杂的业务追踪需求。
What is observability?｜一文读懂什么是系统可观测性
观测云的博客
09-27 4337
什么是可观测性？ 可观测性是通过检查其输出来衡量系统内部状态的能⼒。如果仅使⽤来⾃输出的信息（即传感器数据）可以估计当前状态，则系统被认为是“可观测的”。虽然它似乎是最近的流⾏词，但该术语起源于⼏⼗年前的控制理论（它是关于描述和理解⾃我调节系统的）。然⽽，它越来越多地应⽤于提⾼分布式 IT 系统的性能。在这种情况下，可观测性使⽤三种类型的遥测数据⸺指标、⽇志和跟踪⸺来提供对分布式系统的深⼊可⻅性，并允许团队找到⼤量问题的根本原因并提⾼系统性能。 在过去⼏年中，企业以微服务、⽆服务器和容器技术的形式迅速采
什么是可观测性
u012516914的专栏
02-23 6166
想象一下，在没有财务预测的情况下经营企业，甚至不知道银行剩下多少钱。您怎么知道您是在巨大的现金缓冲中游泳还是由于资金不足而需要跳过客户午餐？如果不注意自己的财务状况，根本就不可能开展健康的...
可观测性介绍
回归心灵的专栏
02-13 8890
控制理论中的可观测性（observability）是指系统可以由其外部输出推断其其内部状态的程度。系统的可观测性和可控制性是数学上对偶的概念。可观测性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观测性。一系统具有可观测性当且仅当，针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别目前的状态。–维基百科。
架构10-可观测性
李宥的博客
12-04 1301
*定义：**可观测性是指“可以由系统的外部输出推断其内部状态的程度”。**日志收集：**记录离散事件，通过这些记录事后分析出程序的行为。**链路追踪：**主要用于排查故障，分析调用链的哪一部分、哪个方法出现错误或阻塞，输入输出是否符合预期。**聚合度量：**对系统中某一类信息的统计聚合，主要用于监控和预警，当某些度量指标达到风险阈值时触发事件。**计数度量器（Counter）：**对有相同量纲、可加减数值的合计量，例如销售额、服务调用次数等。
可观测性调研
Ds的博客
07-11 1334
可观测性调研
什么是可观测性？
ConstCpp的博客
02-07 630
当系统复杂到一定程度的时候，其线上会出现故障不是偶然而是必然，这就必须要有一种机制来进行线上的系统监控和实时诊断，甚至能够进行运营分析，那就不得不使用可观测性，即使其会引入额外的开发复杂度，增加额外的开发周期。通过上述的几个模块，我们可以知道一个可观测性平台已经是一个复杂的项目，如果企业有能力自建可观测平台，自然是一个最好的选择，因为通过第一节中什么是可观测性的讨论，我们已经知道要获取可观测性，需要很大程度的入侵现有代码，业务方需要埋点，需要引入SDK. 需要输出特征日志。
可观测技术概述
qq_27749613的博客
03-27 2567
可观测技术简介什么是可观测技术为什么需要可观测性涉及的数据MetricsTracesLogsProfilesDumps新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 什么是可观测技术 随着云计算、微服务和分布式系统的普及，
一文读懂什么是系统可观测性
云满笔记
11-23 2148
什么是可观测性?可观测性是通过检查其输出来衡量系统内部状态的能⼒。如果仅使⽤来⾃输出的信息(即传感器数据)可以估计当前状态, 则系统被认为是"可观测的"。虽然它似乎是最近的流⾏词, 但该术语起源于⼏⼗年前的控制理论(它是关于描述和理解⾃我调节系统的)。然⽽, 它越来越多地应⽤于提⾼分布式 IT 系统的性能。在这种情况下, 可观测性使⽤三种类型的遥测数据⸺指标、⽇志和跟踪⸺来提供对分布式系统的深⼊可⻅性, 并允许团队找到⼤量问题的根本原因并提⾼系统性能。
微服务架构学习与思考(14)：监控和可观测性详细介绍
九卷技术录
10-26 813
为什么需要监控，除了上面说的作用外，下面对监控的作用做一些总结。化被动为主动近实时了解业务运行的健康状况提前获知业务异常情况信息并告警通知帮助定位各种异常、bug等故障为排障提供详细信息业务运营信息的统计和监控监控系统资源使用情况，保障系统稳定运行对异常情况发出告警通知，及时进行处理维基上：控制理论中的可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。
运维开发的工作职责是什么？
03-29
<think>嗯，用户现在问的是运维开发的工作职责是什么。之前他们问过关于Java微服务集成EFK的问题，现在可能是在扩展了解相关职位的信息。用户可能是想转行或者想招聘相关岗位，需要明确职责范围。 首先，我需要确定运维开发（DevOps Engineer）和传统运维的区别。运维开发更偏向于自动化、工具链和CI/CD流程，而不仅仅是系统维护。可能需要分点解释，结构清晰。 用户可能想知道具体的工作内容，比如自动化部署、监控、工具开发等。要覆盖日常职责、技能要求，以及与其他团队的协作。同时，他们可能关心所需的技能，比如编程语言、熟悉哪些工具，比如Kubernetes、Docker、Ansible等。 还要注意用户可能的深层需求，比如职业发展路径或者如何进入这个领域。但问题直接是职责，所以重点在职责本身。需要包括基础设施管理、自动化脚本、CI/CD、监控日志、故障处理、安全合规，以及新技术研究等方面。 需要确保回答全面，但不过于技术化，用通俗易懂的中文，结构清晰，分点列出。可能还需要对比传统运维，突出运维开发的特点，比如开发自动化工具，促进开发和运维的协作。 另外，考虑到用户之前的问题涉及EFK，可能在日志管理方面有特别兴趣，可以强调日志系统的建设和维护也是职责之一。最后，总结所需的技能，帮助用户理解岗位要求。</think>以下是关于 **运维开发（DevOps Engineer）** 工作职责的详细介绍，涵盖核心任务、技能要求和典型工作场景： --- ### **一、运维开发的核心职责** #### 1. **基础设施自动化** - **目标**：通过代码（Infrastructure as Code, IaC）管理服务器、网络、存储等资源。 - **具体任务**： - 使用工具（如 **Terraform**、**Ansible**）自动化云资源（AWS/Azure/GCP）的创建、配置和销毁。 - 维护 Kubernetes（Docker、Helm）集群的部署与扩缩容策略。 - 设计高可用架构（如负载均衡、多区域容灾）。 ```yaml # Terraform 示例：自动化创建 AWS EC2 实例 resource "aws_instance" "web_server" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t2.micro" tags = { Name = "WebServer" } } ``` #### 2. **CI/CD 流水线建设** - **目标**：实现代码从提交到生产的全流程自动化。 - **具体任务**： - 搭建 Jenkins、GitLab CI 或 GitHub Actions 流水线，集成代码编译、测试、镜像构建和部署。 - 优化构建速度（如缓存依赖、并行任务）。 - 管理制品仓库（Nexus、Harbor）和版本发布策略（蓝绿部署、金丝雀发布）。 ```groovy // Jenkinsfile 示例：定义多阶段流水线 pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package' } } stage('Deploy') { steps { sh 'kubectl apply -f deployment.yaml' } } } } ``` #### 3. **监控与日志体系构建** - **目标**：保障系统可观测性，快速定位故障。 - **具体任务**： - 部署 Prometheus + Grafana 监控集群资源（CPU/内存/磁盘）和业务指标（QPS/延迟）。 - 集成 ELK（Elasticsearch + Logstash + Kibana）或 EFK（Fluentd 替代 Logstash）实现日志集中管理。 - 配置告警规则（如短信、邮件、钉钉机器人通知）。 ```bash # Prometheus 告警规则示例（检测 CPU 使用率） ALERT HighCpuUsage IF node_cpu_seconds_total{mode="idle"} < 20% FOR 5m LABELS { severity = "critical" } ANNOTATIONS { summary = "CPU 使用率过高", description = "实例 {{ $labels.instance }} 的 CPU 空闲率低于 20%" } ``` #### 4. **故障排查与性能优化** - **目标**：确保系统稳定性和高可用性。 - **具体任务**： - 分析生产环境故障（如内存泄漏、慢 SQL、网络抖动），制定修复方案。 - 优化数据库性能（索引、分库分表）、缓存策略（Redis 集群）和 API 响应速度。 - 设计容灾演练方案（如混沌工程模拟节点宕机）。 #### 5. **安全与合规** - **目标**：保护系统免受攻击，满足合规要求。 - **具体任务**： - 管理防火墙规则、SSL 证书和密钥（Vault）。 - 定期扫描漏洞（Nessus、Trivy）和修复基线（CIS Benchmark）。 - 审计日志归档与访问控制（RBAC）。 --- ### **二、运维开发的技能要求** #### 1. **技术栈** - **编程语言**：Python/Go/Shell（必备），Java/C++（加分）。 - **工具链**： | 工具类型 | 典型工具 | |----------------|-----------------------------------| | 云平台 | AWS/Azure/GCP/阿里云 | | 容器编排 | Kubernetes、Docker、Helm | | 配置管理 | Ansible、Chef、Puppet | | 监控日志 | Prometheus、ELK、Zabbix | | CI/CD | Jenkins、GitLab CI、ArgoCD | #### 2. **软技能** - **协作能力**：与开发、测试、产品团队紧密配合，推动 DevOps 文化落地。 - **文档习惯**：编写清晰的技术文档（如 SOP、故障复盘报告）。 - **学习能力**：快速掌握新技术（如服务网格 Istio、Serverless 框架）。 --- ### **三、与传统运维的区别** | **维度** | **传统运维** | **运维开发** | |----------------|-----------------------------------|-----------------------------------| | 工作重心 | 手动维护服务器、处理故障 | 自动化工具链开发、优化流程 | | 技术栈 | Shell 脚本、基础监控工具 | 编程语言、云原生技术栈 | | 交付速度 | 按周/月发布 | 按小时/分钟级持续交付 | | 协作模式 | 被动响应需求 | 主动推动开发与运维协作（DevOps） | --- ### **四、典型工作场景** 1. **紧急故障响应** - 凌晨收到告警：某服务 API 延迟飙升。 - 通过日志（Kibana）和链路追踪（SkyWalking）定位到数据库慢查询，临时扩容并优化 SQL 索引。 2. **新业务上线** - 开发团队提交微服务代码，运维开发编写 Helm Chart 部署到 Kubernetes，并配置 HPA 自动扩缩容。 3. **成本优化** - 分析 AWS 账单，发现某闲置 EC2 实例，通过 Terraform 脚本下线资源，节省 30% 云成本。 --- ### **五、职业发展路径** 1. **技术专家**：深入云原生、可观测性领域（如 CNCF 项目贡献者）。 2. **团队管理**：带领运维团队，制定技术战略。 3. **跨界转型**：转向 SRE（站点可靠性工程师）或架构师角色。 --- 运维开发的核心是通过 **自动化工具** 和 **工程化思维**，解决研发与运维的协作瓶颈，最终实现 **快速、安全、稳定** 的软件交付。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值