3 篇博文 含有标签「Kubernetes」

一篇关于 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：告警规则评估、事件管理和通知。

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

很多团队最早的测试环境都很简单：大家共用一套 dev，分支一提交，CI 构建镜像，然后更新部署仓库里的镜像 tag，最后由 ArgoCD 同步到 Kubernetes。

这套方式在团队规模小、需求串行推进时非常够用。但只要多个功能分支开始并行测试，问题就会迅速暴露：A 分支刚部署完，B 分支又覆盖了环境；测试同学发现一个问题，却很难判断当前环境到底对应哪个 PR、哪个 commit；开发排查时还要先问一句“现在 dev 上是谁的版本”。

在 EKS 上替掉 Cluster Autoscaler，换成 Karpenter 做节点弹性伸缩。这里记录一下最小可用配置和踩过的坑。