微服务可观测性

微服务架构下，服务数量众多、调用链路复杂，问题定位和性能分析变得困难。可观测性是通过系统的外部输出（日志、指标、链路）来理解系统内部状态的能力。

可观测性的三大支柱

Metrics（指标）

指标是数值型的时间序列数据，反映系统的运行状态。指标是聚合的、量化的，适合监控告警和趋势分析。

指标类型：Counter（计数器，只增不减，如请求数）、Gauge（仪表盘，可增可减，如 CPU 使用率）、Histogram（直方图，分布情况，如延迟分布）、Summary（摘要，统计信息，如 P95 延迟）。

指标的优势：紧凑、易于聚合、实时性好。指标的问题：丢失细节、无法定位具体问题。

Logs（日志）

日志是离散的事件记录，反映系统运行过程中的关键信息。日志是详细的、非结构化的，适合问题排查和审计。

日志级别：DEBUG（调试信息）、INFO（一般信息）、WARN（警告信息）、ERROR（错误信息）、FATAL（致命错误）。

日志的优势：详细、保留上下文、可追溯。日志的问题：占用存储大、查询困难、难以聚合。

Tracing（链路追踪）

链路追踪是记录一个请求经过的所有服务，形成调用链路。链路追踪是分布式的、关联的，适合定位故障和性能瓶颈。

链路追踪的核心概念：Trace（链路，完整的请求链路）、Span（跨度，单个服务调用）、Trace ID（链路 ID，唯一标识）、Span ID（跨度 ID，标识单个调用）、Annotation（注解，事件时间戳）。

链路追踪的优势：可视化调用链路、定位故障服务、分析延迟分布。链路追踪的问题：采样率限制、开销大、数据量大。

可观测性的关系

Metrics 告诉你发生了什么（What），Logs 告诉你为什么发生（Why），Tracing 告诉你在哪里发生的（Where）。

三者需要联动：通过 Metrics 发现异常，通过 Logs 查看详情，通过 Tracing 定位位置。例如：响应时间变慢（Metrics），查看错误日志（Logs），追踪慢查询服务（Tracing）。

可观测性的实现

数据采集

Agent 模式：在每个节点部署 Agent，采集数据并发送到后端。优势：解耦应用、统一管理。问题：资源开销、版本管理。

SDK 模式：应用集成 SDK，在代码中埋点采集数据。优势：灵活、精确。问题：侵入代码、维护成本。

Sidecar 模式：每个 Pod 部署 Sidecar 容器，采集数据并发送到后端。优势：解耦应用、云原生。问题：资源开销、网络延迟。

数据存储

Metrics 存储：时序数据库（Prometheus、InfluxDB），支持高效写入和聚合查询。

Logs 存储：日志系统（ElasticSearch、Loki），支持全文检索和分布式存储。

Tracing 存储：分布式追踪存储（Jaeger、Zipkin），支持按 Trace ID 查询和调用链可视化。

数据展示

Dashboard：实时展示指标，如 Grafana、Kibana。

Alerting：异常告警，如 Alertmanager、PagerDuty。

Analysis：问题分析，如 Jaeger UI、Zipkin UI。

可观测性的最佳实践

统一标准：使用 OpenTelemetry 统一 Metrics、Logs、Tracing 的采集和格式，避免碎片化。

采样策略：设置合理的采样率，核心服务 100%，非核心服务 10%。根据流量动态调整采样率。

关联分析：通过 Trace ID 关联 Metrics、Logs、Tracing，统一视图。

上下文传递：确保 Trace ID 跨服务传递，包括异步调用（线程池、消息队列）。

性能监控：监控可观测性组件的性能开销，避免影响业务。

可观测性是微服务治理的眼睛，理解可观测性的原理和权衡，有助于构建可维护的微服务系统。