1. 可观测性系统概述与Elastic技术栈定位

可观测性（Observability）最初来自控制论，指一个系统仅凭其对外输出，就能推断其内部状态的程度。放到软件系统里，它回答的是一个非常具体的问题：当线上出现延迟升高、错误率上升或用户投诉时，我们能否在不重启、不改代码、不猜测的前提下，从系统已经产生的数据中还原出"到底发生了什么"。这与传统监控有本质区别——监控是"预先假设会坏什么，然后盯着它"，可观测性是"不预设故障，而是保留足够丰富的现场证据，事后任意切片分析"。

三大支柱：日志、指标、追踪

业界通常用"三大支柱"来组织可观测性数据，它们不是三种工具，而是三类互补的证据形态。

• 日志（Logs）：离散的、带时间戳的事件记录，粒度最细，信息最丰富。例如一条 Nginx 访问日志、一段 Java 异常堆栈。它擅长回答"这一条请求为什么失败"，但数据量大、结构不统一，直接聚合分析成本高。
• 指标（Metrics）：按固定时间间隔采样的数值，如 CPU 使用率、HTTP 5xx 计数、P99 延迟。它是可聚合、可长期低成本存储的，擅长回答"整体趋势是否异常、异常从什么时候开始"，但缺乏单次请求的上下文。
• 追踪（Traces）：一次请求跨多个服务流转的完整调用链，由若干 Span 组成，每个 Span 记录服务名、操作、耗时、父子关系。它擅长回答"这次慢，慢在调用链的哪一跳"。

三者的关系可以这样理解：指标告诉你"出事了"，追踪告诉你"事出在哪一跳"，日志告诉你"那一跳具体报了什么错"。真正可用的可观测性系统，必须让这三类数据能够通过统一标识（如 trace_id、service.name、host.name）互相跳转，而不是三个孤立的系统。

Elastic 在三大支柱中的角色

Elastic Stack 的定位是"统一的可观测性数据平台"：用一套存储与查询引擎承载日志、指标、追踪三类数据，避免多套系统之间的数据割裂。

• 日志：这是 Elastic 的传统强项。通过 Filebeat、Fluent Bit、Logstash 采集，写入 Elasticsearch 的 data stream，配合 Kibana 的 Discover 与日志流（Logs）应用做检索、字段统计和异常定位。
• 指标：通过 Metricbeat、Elastic Agent 采集主机、容器、Kubernetes、中间件指标，写入以 metrics- 开头的 data stream。Elasticsearch 对时序数据做了专门优化（如 TSDB 索引模式、降采样 downsampling），降低长期存储成本。
• 追踪：通过 Elastic APM（基于 OpenTelemetry 或 Elastic APM Agent）采集分布式追踪数据，写入 traces-apm-* 数据流，在 Kibana APM 应用中查看服务地图、事务耗时分布和 Span 明细。

关键在于，这三类数据在 Elasticsearch 中共享同一套索引生命周期管理（ILM）、同一套查询语言（KQL / ES|QL / DSL）和同一个 Kibana 界面。当你在 APM 里看到某个事务变慢，可以直接跳到对应的日志，或查看同一时段的指标曲线，这种"横向关联"正是统一平台的价值。

Elastic Stack 核心组件与选型依据

一个典型的 Elastic 可观测性部署包含以下组件：

选型的核心判断依据有三条。第一，数据量与保留期：日志全量保留 30 天与保留 7 天，对集群规模和 ILM 策略的要求完全不同；指标和追踪通常采样或降采样。第二，采集路径的复杂度：如果只是标准的主机、容器、Nginx、MySQL 指标，Elastic Agent 的集成开箱即用；如果需要从 Kafka 消费、做字段富化或脱敏，才引入 Logstash。第三，查询与关联需求：如果团队需要 trace 到 log 的一键跳转，就必须保证 trace_id 等关联字段在日志中被正确解析和索引，这决定了采集阶段的字段处理策略，而不是事后补救。

从数据产生到关联分析的整体链路

下面这张图把本节的核心关系串起来：左侧是三类可观测性数据及其采集组件，中间是 Elasticsearch 的统一存储与索引生命周期，右侧是 Kibana 中面向不同问题的分析入口，底部则标出贯穿三者的关联字段。