跳到主要内容

1 篇博文 含有标签「Tempo」

查看所有标签
在 EKS 上搭建 Metrics、Logs、Traces 一体化可观测平台

在 EKS 上搭建 Metrics、Logs、Traces 一体化可观测平台

Jacob
Jacob
虚心学习

一篇关于 Prometheus、OpenTelemetry、Loki、Tempo、Grafana 和 Nightingale 的生产实践笔记
配置快照：2026-09
本文已脱敏，账号、集群、域名、CIDR、ARN、bucket 和业务名称均使用占位符

本文同时收录于知识库：EKS Metrics、Logs、Traces 一体化可观测平台。

写在前面​

最早搭监控时，我们通常从 Prometheus 开始；遇到线上问题以后，又补一个 Loki；再往后为了分析跨服务调用，继续部署 Tempo 或 Jaeger。三个系统都有了，但数据还是割裂的：指标告诉我们“出问题了”，日志告诉我们“报了什么错”，Trace 才能解释“请求到底在哪一跳变慢”。

这次改造的目标不是简单把三个开源组件安装进 Kubernetes，而是把它们连接成一条完整的排障链路：

告警发现异常
  -> 指标确定受影响服务和时间窗口
  -> Trace 找到慢调用或错误调用
  -> trace_id 跳转到对应日志
  -> 回到 Pod、节点和 Kubernetes 事件定位根因

最终采用的核心组件是：

  • Prometheus：Kubernetes 与应用指标存储和 PromQL 查询；
  • OpenTelemetry Operator/Collector：Trace、日志采集、尾部采样和 Span Metrics；
  • Loki：容器日志存储和 LogQL 查询；
  • Tempo：分布式 Trace 存储和查询；
  • Grafana：Metrics、Logs、Traces 的统一查询与关联；
  • Nightingale：告警规则评估、事件管理和通知。

这篇笔记重点记录四件事：部署过程、架构设计、关键参数，以及系统上线以后仍需要继续优化的部分。