在 Kubernetes 管理数百个微服务之后，你会发现传统的"监控"已经不够用了。一个请求从网关进入，经过 6 个服务、3 个中间件、2 次数据库调用，最后返回 500——问题出在哪？是网络抖动、数据库慢查询、还是某个 Pod OOM？如果没有一套完整的可观测性体系，排障就像在黑箱里摸象。本文系统梳理云原生可观测性的技术栈，从三大支柱到具体落地方案，帮你建立全局视角。

如果你的微服务链路出了问题，排查时需要打开 Jaeger 查 Trace、切到 Grafana 看 Metrics、再跳到 ELK 搜 Logs——三条数据各自为战，靠人肉关联 TraceID，这就是可观测性碎片化的典型困境。OpenTelemetry（OTel）正是为了终结这种混乱而生：统一采集标准，解耦 SDK 与后端，让 Metrics、Logs、Traces 三种信号共享同一套语义和管线。

在云原生体系中，Prometheus 已经成为监控领域的事实标准。而真正让监控系统发挥价值的，不是安装 Prometheus 本身，而是你是否拥有丰富、准确、有业务含义的指标。本文从 Prometheus 数据模型出发，深入讲解如何使用 Go 客户端库开发自定义 Exporter，为你的应用和业务注入可观测性能力。

在微服务架构下，一个用户请求可能穿越十几个服务，当出现延迟或错误时，靠日志逐个排查如同大海捞针。分布式追踪（Distributed Tracing）通过记录请求在每一跳的耗时与状态，将散落的调用片段串联成完整链路，是可观测性体系中不可或缺的一环。Grafana Tempo 作为 Grafana Labs 推出的开源分布式追踪后端，以无索引架构和对象存储为基础，大幅降低了追踪数据的存储成本，同时与 Grafana 生态深度集成。

在云原生可观测性体系中，日志、指标、链路 tracing 构成三大支柱。Grafana Loki 作为日志聚合引擎，以"不索引日志正文"为核心设计哲学，将存储成本压到 Elasticsearch 的 1/5 到 1/10，同时与 Prometheus 标签体系完全对齐。本文深入解析 Loki 的架构设计、存储引擎、部署模式以及与 ELK 的对比选型。