可观测性三件套:Metrics、Logs、Traces 在排障里怎么配合

星期三, 4月 8, 2026 | 1分钟阅读 | 更新于 星期三, 4月 8, 2026

@

系统上 Kubernetes 之后,服务实例变多、生命周期变短,单靠 SSH 看日志往往不够。Metrics(指标)Logs(日志)Traces(链路) 三者互补,目标是把「哪里慢 / 哪里错」从小时级缩到分钟级。

Metrics:先看趋势与告警

  • 回答:CPU/内存/延迟/错误率是否异常,是否只在某副本、某区域。
  • 适合:容量规划、告警、SLO 视角(例如 P99 延迟)。

Logs:再看当时发生了什么

  • 回答:错误码、堆栈、业务关键字段(订单号、用户 ID 等)。
  • 建议:结构化日志 + 关联字段(如 trace id),便于跨服务检索。

Traces:把一次请求串起来

  • 回答:延迟花在哪段调用(下游 RPC、DB、缓存)。
  • 适合:微服务拆分后跨服务慢查询、重复调用、异常传播。

实际使用顺序(常见)

  1. 告警 / 大盘 发现异常(Metrics)。
  2. Trace 定位到具体服务与 span。
  3. 在同一时间窗口内 查日志 对齐细节。

落地提示

  • 三者都贵,先保证「能关联」(同一 trace id、同一时间戳),再追求大而全。
  • 采样策略要设计:全量链路在高峰期可能拖垮集群与存储。
关于我

大家好,我是 lew。这里主要记录学习、工作与阅读里的碎片想法——偏工程实践,少空话;写给自己备忘,也欢迎路过的你顺手翻翻。

经历与方向

从事互联网研发与技术管理十余年,长期负责团队建设、架构演进、技术选型与交付节奏;经历从客户端到服务端、从功能迭代到线上治理的完整链路,习惯在稳定性、成本与交付速度之间做权衡。

技术栈与工程

后端以 GolangNode.js(及常见服务端框架)为主;在分布式与实时服务微服务(RPC、服务发现、可观测)、容器与编排Docker / Kubernetes)、CI/CD 与云上架构上有较多实践。数据侧熟悉多种关系型 / 文档型数据库、缓存与消息队列;关注高可用、安全与弹性,也关注研发协作与发布效率。

AI / 大模型工程化

持续跟进 LLM 落地与工程化,方向包括但不限于 RAGLoRAAgentMCPSKILL 等缩写所指领域;更关心「模型能力」如何与业务约束、数据边界、可观测与发布节奏对齐,而不是单点炫技。文里会尽量直接用这些缩写,避免冗长中文释义。

管理与协作

在敏捷与 Scrum 实践、跨职能沟通与版本迭代上有较多经验;习惯用可度量的目标、评审与回顾推动改进,而不是只堆流程文档。

学习

MBA 在读,侧重创新创业与组织管理,用来补足商业与战略视角,和技术判断互相校准。

博客里可能写什么
  • LLMRAGAgent 等在实际业务里的取舍与踩坑
  • 后端、分布式与可观测的一得之见
  • 工具链、CI/CD 与个人工作流里的「人机协作」节奏

若你也关心 LLMRAG、软件工程或知识管理,欢迎偶尔回来看看。

联系可通过站点页脚邮箱;合作与交流请说明来意。