引言

你是否遇到过这些场景：

• 线上出了问题，看日志发现关键信息没打，只能加日志重新发版
• 一个请求经过 5 个微服务，排查时要在 5 个系统的日志之间来回跳
• 监控大盘倒是有一堆，但没有人说得清哪个指标代表什么意思
• 团队用了 3 种 APM 工具，每年光 License 费就十几万

这些问题的根源都是同一个：没有统一的可观测性体系。

本系列将带你从 0 开始搭建一套完整的可观测性体系，这是第 1 期，先搞清楚架构和选型。

一、什么是可观测性

1.1 监控 ≠ 可观测性

监控（Monitoring）：告诉你系统出了什么问题
可观测性（Observability）：让你能搞清楚为什么出问题

监控是"已知未知"——你知道要监控什么（CPU、内存、QPS），设置阈值告警。可观测性是"未知未知"——你不知道问题会在哪里发生，但系统提供足够的信息让你能排查。

1.2 可观测性三支柱

┌─────────────────────────┐
                    │     可观测性 Observability    │
                    └────────────┬────────────┘
            ┌────────────────────┼────────────────────┐
            ▼                    ▼                    ▼
    ┌───────────────┐   ┌───────────────┐   ┌───────────────┐
    │  Metrics 指标  │   │  Logs 日志     │   │  Traces 链路   │
    │  "发生了什么"  │   │  "细节是什么"  │   │  "在哪里发生"  │
    └───────────────┘   └───────────────┘   └───────────────┘
    CPU/内存/QPS        错误日志/业务日志     请求经过哪些服务
    数值型，低成本       文本型，高信息量      耗时分布，调用关系

三者关系：告警看 Metrics → 排查看 Traces → 定位看 Logs。不是三选一，而是缺一不可。

1.3 第四支柱：Profiles（性能剖析）

近年来，持续性能剖析（Continuous Profiling）逐渐成为可观测性的"第四支柱"：

Metrics → 告诉你 CPU 使用率 80%
Traces  → 告诉你某个请求慢
Logs    → 告诉你报错信息
Profiles → 告诉你 CPU 80% 中有 60% 花在哪个方法的哪行代码

本系列也会覆盖这个维度。

二、全景架构图

2.1 目标架构

┌─────────────────────────────────────────────────────────────────────────┐
│                           应用层 (Application)                            │
│                                                                         │
│   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐           │
│   │ Service A│   │ Service B│   │ Service C│   │ Service D│           │
│   │ Java/Spring│  │ Java/Spring│  │   Go     │   │  Node.js │           │
│   └────┬─────┘   └────┬─────┘   └────┬─────┘   └────┬─────┘           │
│        │              │              │              │                   │
│   ┌────┴──────────────┴──────────────┴──────────────┴─────┐            │
│   │          OpenTelemetry SDK / Auto Instrumentation       │            │
│   │     (自动埋点 + 手动埋点，统一数据格式 OTLP 协议)          │            │
│   └────────────────────────┬────────────────────────────────┘            │
└────────────────────────────┼─────────────────────────────────────────────┘
                             │
                             │ OTLP (gRPC/HTTP)
                             ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                      采集层 (Collection)                                 │
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                   OpenTelemetry Collector                         │   │
│   │                                                                   │   │
│   │   ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐        │   │
│   │   │ Receiver│   │Processor│   │ Exporter│   │Extension│        │   │
│   │   │ (接收)  │→  │ (处理)  │→  │ (导出)  │   │ (扩展)  │        │   │
│   │   └─────────┘   └─────────┘   └─────────┘   └─────────┘        │   │
│   └───────────────────────────┬─────────────────────────────────────┘   │
└───────────────────────────────┼─────────────────────────────────────────┘
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
              ▼                 ▼                 ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│   Metrics 指标    │ │    Logs 日志     │ │   Traces 链路    │
│                  │ │                  │ │                  │
│  ┌────────────┐  │ │  ┌────────────┐  │ │  ┌────────────┐  │
│  │   Mimir    │  │ │  │    Loki    │  │ │  │   Tempo    │  │
│  │ (时序数据库)│  │ │  │ (日志数据库)│  │ │  │ (链路存储)  │  │
│  └─────┬──────┘  │ │  └─────┬──────┘  │ │  └─────┬──────┘  │
└────────┼─────────┘ └────────┼─────────┘ └────────┼─────────┘
         │                    │                    │
         │                    │                    │
         └────────────────────┼────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     展示与告警层 (Visualization & Alerting)               │
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                        Grafana                                    │   │
│   │                                                                   │   │
│   │   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐       │   │
│   │   │ Metrics  │  │  Logs    │  │  Traces  │  │ Profiles │       │   │
│   │   │ Dashboard│  │ Explorer │  │ Explorer │  │ Explorer │       │   │
│   │   └──────────┘  └──────────┘  └──────────┘  └──────────┘       │   │
│   │                                                                   │   │
│   │                      Alerting Rules                              │   │
│   └─────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────┘

2.2 架构设计原则

三、为什么不用 ELK 了

3.1 ELK 的困境

ELK（Elasticsearch + Logstash + Kibana）曾是日志系统的代名词，但在 2026 年的今天，它的问题越来越突出：

3.2 成本对比

以 500GB/天 日志量 为例：

Loki 的设计哲学：不对日志内容建索引，只对标签（labels）建索引。日志本身压缩存储在对象存储中。这就像图书馆只对书架编号建索引，书的内容不索引，需要时再去对应书架翻——对于 99% 只按时间和服务名查日志的场景，够用了。

3.3 什么时候还是该用 ELK

四、OpenTelemetry vs SkyWalking 怎么选

4.1 核心区别

4.2 选型建议

选 OpenTelemetry 如果：
  ✅ 多语言微服务架构
  ✅ 想要厂商中立，未来可切换后端
  ✅ 团队有运维能力，愿意搭建完整体系
  ✅ 关注行业标准，不想被绑定

选 SkyWalking 如果：
  ✅ 纯 Java 技术栈
  ✅ 团队规模小，想要开箱即用
  ✅ 主要需求是 APM（应用性能监控）
  ✅ 中文社区支持重要

4.3 本系列的选择：OpenTelemetry

原因很简单：

1. OTel 已是行业标准：CNCF 毕业项目，所有主流云厂商和 APM 厂商都支持
2. 厂商中立：今天用 Grafana 后端，明天可以切 Jaeger、Datadog、阿里云 ARMS，应用代码不用改
3. 多语言支持：本系列虽以 Java 为主，但架构设计支持多语言
4. 生态趋势：SkyWalking 8.x 也在适配 OTel 协议，说明方向已经明确

五、Grafana 全家桶各自解决什么问题

5.1 全景对比

┌─────────────────────────────────────────────────────────┐
│                    Grafana 统一展示                       │
│                                                         │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│
│   │  Mimir   │  │   Loki   │  │  Tempo   │  │Pyroscope ││
│   │ Metrics  │  │   Logs   │  │  Traces  │  │ Profiles ││
│   │ "多少"   │  │ "什么"   │  │ "哪里"   │  │ "哪行代码"││
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘│
│                                                         │
│   Mimir ← Prometheus 兼容，水平扩展的时序数据库           │
│   Loki  ← 日志聚合系统，轻量级，只索引标签                 │
│   Tempo ← 分布式链路追踪后端，支持 OTLP                   │
│   Pyroscope ← 持续性能剖析，定位代码级性能问题             │
└─────────────────────────────────────────────────────────┘

5.2 各组件详解

Mimir（Metrics）

# PromQL 查询示例
# 过去 5 分钟 HTTP 5xx 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/ 
sum(rate(http_requests_total[5m])) by (service)

Loki（Logs）

# LogQL 查询示例
# 查询 order-service 最近的 ERROR 日志
{service="order-service"} |= "ERROR"

# 统计过去 1 小时各服务的错误日志数
sum(count_over_time({level="error"}[1h])) by (service)

Tempo（Traces）

# Trace 结构示例
TraceID: 4a3b2c1d

  [Service A] HTTP GET /api/orders        120ms
    ├── [Service B] DB Query              45ms
    ├── [Service C] HTTP GET /api/users   50ms
    │    └── [Service D] Redis Get         5ms
    └── [Service B] DB Query              20ms

Pyroscope（Profiles）

# Profile 示例
com.example.order.OrderService.processOrder
  └── com.example.order.OrderRepository.findById
        └── org.hibernate.Session.doWork
              └── java.sql.PreparedStatement.executeQuery   ← 80% CPU 花在这

5.3 为什么选 Grafana 全家桶

5.4 数据关联示意

Grafana Dashboard 中的关联跳转：

┌──────────────────────────────────────────────────┐
│ Metrics 大盘                                      │
│   HTTP P99 延迟突然升高 ↑↑↑                       │
│   [点击异常点] ─────────────────────────┐         │
│                                        ▼         │
│   Exemplars: 该时间点的 TraceID          │
│   [点击 TraceID] ──────────────┐        │         │
│                                ▼        │         │
│   Tempo Trace 详情                        │         │
│   Service C 调用 DB 耗时 800ms           │         │
│   [点击 Span 日志] ───────────┐          │         │
│                               ▼          │         │
│   Loki 日志详情                           │         │
│   "DB connection pool exhausted"         │         │
│   ─────────────────────────────────────────┘        │
│                                                     │
│   结论：DB 连接池耗尽导致 P99 升高                   │
└─────────────────────────────────────────────────────┘

六、docker-compose.yml：一键启动全套环境

以下是本系列使用的完整 docker-compose.yml，一键启动 OpenTelemetry Collector + Grafana 全家桶 + 示例应用：

version: "3.8"

services:
  # ============================================
  # 采集层：OpenTelemetry Collector
  # ============================================
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.108.0
    container_name: otel-collector
    command: ["--config=/etc/otelcol/config.yml"]
    volumes:
      - ./otel-collector-config.yml:/etc/otelcol/config.yml
    ports:
      - "4317:4317"   # OTLP gRPC
      - "4318:4318"   # OTLP HTTP
      - "8888:8888"   # Prometheus metrics
    depends_on:
      - tempo
      - loki
      - mimir

  # ============================================
  # Metrics：Mimir
  # ============================================
  mimir:
    image: grafana/mimir:2.13.0
    container_name: mimir
    command: ["-config.file=/etc/mimir/mimir.yml"]
    volumes:
      - ./mimir-config.yml:/etc/mimir/mimir.yml
      - mimir-data:/data
    ports:
      - "9009:9009"   # Mimir HTTP

  # ============================================
  # Logs：Loki
  # ============================================
  loki:
    image: grafana/loki:3.1.0
    container_name: loki
    command: ["-config.file=/etc/loki/loki.yml"]
    volumes:
      - ./loki-config.yml:/etc/loki/loki.yml
      - loki-data:/loki
    ports:
      - "3100:3100"   # Loki HTTP

  # ============================================
  # Traces：Tempo
  # ============================================
  tempo:
    image: grafana/tempo:2.5.0
    container_name: tempo
    command: ["-config.file=/etc/tempo/tempo.yml"]
    volumes:
      - ./tempo-config.yml:/etc/tempo/tempo.yml
      - tempo-data:/var/tempo
    ports:
      - "3200:3200"   # Tempo HTTP
      - "4317"        # OTLP gRPC (internal)

  # ============================================
  # Profiles：Pyroscope
  # ============================================
  pyroscope:
    image: grafana/pyroscope:1.8.0
    container_name: pyroscope
    command: ["server"]
    volumes:
      - pyroscope-data:/var/lib/pyroscope
    ports:
      - "4040:4040"   # Pyroscope HTTP

  # ============================================
  # 展示层：Grafana
  # ============================================
  grafana:
    image: grafana/grafana:11.2.0
    container_name: grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    volumes:
      - ./grafana-datasources.yml:/etc/grafana/provisioning/datasources/datasources.yml
      - ./grafana-dashboards.yml:/etc/grafana/provisioning/dashboards/dashboards.yml
      - ./dashboards:/var/lib/grafana/dashboards
      - grafana-data:/var/lib/grafana
    ports:
      - "3000:3000"   # Grafana HTTP
    depends_on:
      - mimir
      - loki
      - tempo
      - pyroscope

  # ============================================
  # 示例应用：Java Spring Boot
  # ============================================
  demo-app:
    image: openjdk:21-slim
    container_name: demo-app
    working_dir: /app
    volumes:
      - ./demo-app.jar:/app/app.jar
    command: ["java", "-jar", "/app/app.jar"]
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
      - OTEL_SERVICE_NAME=demo-app
      - OTEL_RESOURCE_ATTRIBUTES=service.name=demo-app,service.version=1.0.0
    ports:
      - "8080:8080"
    depends_on:
      - otel-collector

volumes:
  mimir-data:
  loki-data:
  tempo-data:
  pyroscope-data:
  grafana-data:

6.1 OTel Collector 配置

# otel-collector-config.yml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  memory_limiter:
    check_interval: 2s
    limit_percentage: 80
    spike_limit_percentage: 25
  resource:
    attributes:
      - key: deployment.environment
        value: development
        action: upsert

exporters:
  # Metrics → Mimir
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push

  # Logs → Loki
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

  # Traces → Tempo
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [prometheusremotewrite]
    
    logs:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [loki]
    
    traces:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [otlp/tempo]

6.2 Grafana 数据源配置

# grafana-datasources.yml
apiVersion: 1

datasources:
  - name: Mimir
    type: prometheus
    access: proxy
    url: http://mimir:9009
    isDefault: true
    jsonData:
      httpMethod: POST

  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100
    jsonData:
      maxLines: 1000

  - name: Tempo
    type: tempo
    access: proxy
    url: http://tempo:3200
    jsonData:
      tracesToLogs:
        datasourceUid: loki
        tags: ['service.name', 'span.name']
      tracesToMetrics:
        datasourceUid: mimir

  - name: Pyroscope
    type: pyroscope
    access: proxy
    url: http://pyroscope:4040

6.3 各组件最小化配置

# mimir-config.yml
multitenancy_enabled: false

blocks_storage:
  backend: filesystem
  tsdb:
    dir: /data/tsdb
  bucket_store:
    sync_dir: /data/tsdb-sync

compactor:
  data_dir: /data/compactor
  sharding_ring:
    kvstore:
      store: inmemory

distributor:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory

ingester:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory
    replication_factor: 1

ruler:
  rule_path: /data/ruler

server:
  http_listen_port: 9009
  log_level: info

# loki-config.yml
auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

limits_config:
  retention_period: 168h
  max_query_length: 721h

# tempo-config.yml
server:
  http_listen_port: 3200

distributor:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317

storage:
  trace:
    backend: local
    local:
      path: /var/tempo/blocks
    wal:
      path: /var/tempo/wal

metrics_generator:
  registry:
    external_labels:
      source: tempo
  storage:
    path: /var/tempo/generator/wal
    remote_write:
      - url: http://mimir:9009/api/v1/push
        send_exemplars: true

6.4 启动方式

# 创建项目目录
mkdir observability-stack && cd observability-stack

# 将上述配置文件放入目录
# docker-compose.yml
# otel-collector-config.yml
# mimir-config.yml
# loki-config.yml
# tempo-config.yml
# grafana-datasources.yml
# grafana-dashboards.yml

# 一键启动
docker-compose up -d

# 查看状态
docker-compose ps

# 访问 Grafana
# http://localhost:3000
# 用户名: admin / 密码: admin

启动后各组件地址：

七、后续连载计划

本系列后续文章将在上述 docker-compose 环境基础上逐步叠加：

总结

选型决策一览

一句话总结

OpenTelemetry 统一采集 + Grafana 全家桶统一展示 = 厂商中立、开源、低成本、可扩展的可观测性体系。

成本对比

互动话题：你团队目前用的是什么可观测性方案？有没有遇到选型纠结？欢迎留言讨论！

附录

参考资料

• OpenTelemetry 官方文档
• Grafana Mimir 文档
• Grafana Loki 文档
• Grafana Tempo 文档
• Grafana Pyroscope 文档
• CNCF 可观测性白皮书

系列文章导航

• 第 1 期：架构总览与工具选型（本文）
• 第 2 期：Metrics 入门（敬请期待）
• 第 3 期：Logs 入门（敬请期待）
• 第 4 期：Traces 入门（敬请期待）
• 第 5 期：Profiles 入门（敬请期待）
• 第 6 期：告警体系（敬请期待）
• 第 7 期：生产部署（敬请期待）

订阅提醒：关注我，每周获取可观测性体系搭建的实战经验！