mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
Profile Image of the Author
Souloss
公告
欢迎来到我的博客！这是一条示例公告
标签
3732 字
11 分钟
系列导读
2025-12-17
可观测性
可观测性
/
监控
/
工程实践

系列简介#

当你的微服务架构从 5 个服务膨胀到 500 个，凌晨 3 点的告警电话从”CPU 高了”变成”P99 延迟飙升但 CPU 正常、某个下游服务偶发超时、日志里找不到错误、追踪链路断在网关层”——你需要的不再是监控，而是可观测性。

本系列从可观测性的三大信号（日志、指标、追踪）出发，逐步扩展到第四大支柱（持续性能分析），深入 OpenTelemetry 的架构与实现，探索 eBPF 零侵入可观测性，构建数据管道与存储后端，最终落地 SLO 驱动的告警体系与可观测性平台。16 章内容覆盖从理论到实战的完整链路，每章配有可在 Docker 环境中验证的实践操作。

核心观点#

  • 监控告诉你系统出了问题，可观测性让你理解为什么
  • 三大信号不是孤岛，关联才是可观测性的灵魂
  • SLO 是可观测性的北极星，告警是错误预算的哨兵
  • OpenTelemetry 是可观测性的 TCP/IP——统一标准比工具选择更重要
  • eBPF 让可观测性从”侵入式仪器化”走向”零侵入观测”

场景驱动阅读路线#

不想按部就班地从第 1 章读到第 16 章？没问题。以下 5 条路线从你日常遇到的真实问题出发，按”你需要什么→可观测性怎么解决”的顺序串联章节。每条路线可独立阅读，前置依赖已在路线内标注。

路线总览#

flowchart TB subgraph 路线A[" 路线A：凌晨 3 点告警排查"] A1[Ch1 可观测性全景] --> A2[Ch2 结构化日志] A2 --> A3[Ch3 指标体系] A3 --> A4[Ch4 分布式追踪] A4 --> A5[Ch10 信号关联] A5 --> A6[Ch14 生产调试] end subgraph 路线B[" 路线B：从零搭建可观测性平台"] B1[Ch1 可观测性全景] --> B2[Ch5 OpenTelemetry] B2 --> B3[Ch8 数据管道] B3 --> B4[Ch9 存储后端] B4 --> B5[Ch13 平台设计] B5 --> B6[Ch16 综合实战] end subgraph 路线C[" 路线C：SLO 驱动的告警治理"] C1[Ch3 指标体系] --> C2[Ch11 SLO与告警] C2 --> C3[Ch10 信号关联] C3 --> C4[Ch12 可观测性规模] C4 --> C5[Ch13 平台设计] end subgraph 路线D[" 路线D：性能深度分析"] D1[Ch3 指标体系] --> D2[Ch6 持续性能分析] D2 --> D3[Ch7 eBPF可观测性] D3 --> D4[Ch14 生产调试] D4 --> D5[Ch15 可观测性驱动开发] end subgraph 路线E[" 路线E：大规模可观测性降本"] E1[Ch5 OpenTelemetry] --> E2[Ch8 数据管道] E2 --> E3[Ch12 可观测性规模] E3 --> E4[Ch9 存储后端] E4 --> E5[Ch13 平台设计] end style 路线A fill:#e3f2fd,stroke:#1565c0 style 路线B fill:#e8f5e9,stroke:#2e7d32 style 路线C fill:#fff3e0,stroke:#e65100 style 路线D fill:#fce4ec,stroke:#c62828 style 路线E fill:#f3e5f5,stroke:#6a1b9a

路线A：凌晨 3 点告警排查#

场景：P99 延迟飙升、错误率上升、某个下游服务偶发超时——你需要在最短时间内定位根因。

顺序章节为什么读这章
1Ch1 可观测性全景建立”监控 vs 可观测性”的认知——为什么传统监控不够用
2Ch2 结构化日志日志是排障的第一手证据——结构化日志让搜索从分钟级降到毫秒级
3Ch3 指标体系指标告诉你”哪里出了问题”——Histogram 比 Summary 更适合延迟分析
4Ch4 分布式追踪追踪告诉你”请求在哪个服务卡住了”——Span 是分布式排障的核心单元
5Ch10 信号关联核心：日志/指标/追踪三大信号的关联——Exemplar 让指标直通追踪
6Ch14 生产调试端到端排障实战——延迟分析、内存泄漏、间歇性故障的诊断方法论

路线逻辑：从”告警触发”出发，先掌握三大信号的基本能力（Ch2-4），再学习如何关联信号（Ch10），最后通过实战场景综合运用（Ch14）。

路线B：从零搭建可观测性平台#

场景：团队决定建设统一的可观测性平台——选什么技术栈？数据怎么采集、传输、存储、展示？

顺序章节为什么读这章
1Ch1 可观测性全景理解可观测性的全貌——平台需要覆盖哪些信号
2Ch5 OpenTelemetry核心：OTel 是可观测性的统一标准——SDK + Collector 是平台的骨架
3Ch8 可观测性数据管道数据管道是平台的血管——采样、路由、转换、缓冲
4Ch9 存储后端存储是平台的基石——VictoriaMetrics、Mimir、Tempo、Loki 各有所长
5Ch13 可观测性平台设计平台级设计——多租户、权限、数据生命周期、成本模型
6Ch16 综合实战端到端搭建——从 Docker Compose 到生产级部署

路线逻辑：从标准（OTel）出发，构建数据管道（Ch8），选择存储（Ch9），设计平台（Ch13），最终落地（Ch16）。

路线C：SLO 驱动的告警治理#

场景：告警风暴、误报率 90%、真正重要的告警被淹没——你需要从”指标驱动告警”转向”SLO 驱动告警”。

顺序章节为什么读这章
1Ch3 指标体系SLI 是 SLO 的基础——理解指标类型才能定义正确的 SLI
2Ch11 SLO与告警核心：SLO/SLI/错误预算/燃烧率——告警应该基于错误预算的消耗速度
3Ch10 信号关联多信号关联提升 SLO 诊断效率——从 SLO 违规快速定位根因
4Ch12 可观测性规模大规模下的 SLO 挑战——高基数指标对 SLO 计算的影响
5Ch13 可观测性平台设计SLO 平台化——多团队 SLO 管理、错误预算策略

路线逻辑：先理解指标基础（Ch3），再掌握 SLO 方法论（Ch11），然后学习如何用信号关联加速诊断（Ch10），最后解决规模化挑战（Ch12→Ch13）。

路线D：性能深度分析#

场景：CPU 利用率正常但延迟高、内存缓慢增长疑似泄漏、GC 停顿影响尾部延迟——你需要比指标更深的观测能力。

顺序章节为什么读这章
1Ch3 指标体系指标告诉你”慢在哪里”——但无法告诉你”为什么慢”
2Ch6 持续性能分析核心：火焰图是性能分析的第一工具——持续性能分析让火焰图从”按需”变成”始终在线”
3Ch7 eBPF可观测性零侵入观测——无需修改代码即可获得内核态/用户态的性能数据
4Ch14 生产调试延迟分析、内存泄漏、GC 问题的实战诊断
5Ch15 可观测性驱动开发将性能分析前置到开发阶段——结构化错误、业务指标、测试中的可观测性

路线逻辑：从指标发现性能问题（Ch3），用持续性能分析深入（Ch6），用 eBPF 零侵入观测（Ch7），实战诊断（Ch14），最终将可观测性融入开发流程（Ch15）。

路线E：大规模可观测性降本#

场景：可观测性成本占基础设施成本 30%、指标基数爆炸、存储无限增长——你需要控制成本而不牺牲可见性。

顺序章节为什么读这章
1Ch5 OpenTelemetryOTel Collector 是成本控制的入口——采样和路由在这里完成
2Ch8 可观测性数据管道采样策略是降本的核心——尾部采样保留有价值的追踪
3Ch12 可观测性规模核心：5 亿指标/秒的架构——降采样、高基数处理、成本模型
4Ch9 存储后端存储成本占比最大——降采样、数据分层、压缩比优化
5Ch13 可观测性平台设计平台级成本治理——多租户配额、数据生命周期管理

路线逻辑：从数据入口（Ch5→Ch8）控制数据量，解决规模化挑战（Ch12），优化存储成本（Ch9），最终平台化治理（Ch13）。

路线交叉参考#

同一章节在不同路线中的关注点不同：

章节路线A 关注点路线B 关注点路线C 关注点路线D 关注点路线E 关注点
Ch1监控 vs 可观测性信号全覆盖———
Ch2结构化日志搜索————
Ch3Histogram 延迟分析—SLI 定义性能问题发现—
Ch4追踪定位瓶颈————
Ch5—OTel SDK+Collector——采样与路由
Ch6———火焰图核心—
Ch7———零侵入观测—
Ch8—数据管道——采样策略
Ch9—存储选型——存储成本
Ch10信号关联核心—SLO 诊断——
Ch11——SLO 核心——
Ch12——高基数 SLO—规模核心
Ch13—平台设计SLO 平台化—成本治理
Ch14排障实战——延迟/内存诊断—
Ch15———开发阶段可观测性—
Ch16—端到端搭建———

知识导图#

以下导图展示 16 章知识之间的网络关系。与线性目录不同，这里强调跨信号的连接——一个 P99 延迟飙升的问题同时需要指标（发现异常）、追踪（定位瓶颈）、日志（查看错误上下文）、性能分析（找到热点函数）四种信号的协同。

概念关系图#

graph TB subgraph 信号层[" 信号层 — 可观测性的四大支柱"] LOG["日志<br/>Ch2"] METRIC["指标<br/>Ch3"] TRACE["追踪<br/>Ch4"] PROFILE["性能分析<br/>Ch6"] end subgraph 采集层[" 采集层 — 如何产生和采集信号"] OTEL["OpenTelemetry<br/>Ch5"] EBPF["eBPF<br/>Ch7"] SDK["SDK 仪器化<br/>Ch15"] end subgraph 管道层[" 管道层 — 数据的传输与处理"] PIPE["数据管道<br/>Ch8"] SAMPLE["采样与路由"] CORRELATE["信号关联<br/>Ch10"] end subgraph 存储层[" 存储层 — 数据的持久化与查询"] STORE["存储后端<br/>Ch9"] SCALE["规模与成本<br/>Ch12"] end subgraph 应用层[" 应用层 — 可观测性的价值落地"] SLO["SLO 与告警<br/>Ch11"] DEBUG["生产调试<br/>Ch14"] PLATFORM["平台设计<br/>Ch13"] PRACTICE["综合实战<br/>Ch16"] end %% 信号层 → 采集层 LOG --> OTEL METRIC --> OTEL TRACE --> OTEL PROFILE --> EBPF LOG --> SDK METRIC --> SDK TRACE --> SDK %% 采集层 → 管道层 OTEL --> PIPE EBPF --> PIPE PIPE --> SAMPLE PIPE --> CORRELATE %% 管道层 → 存储层 PIPE --> STORE STORE --> SCALE %% 存储层 → 应用层 STORE --> SLO STORE --> DEBUG SCALE --> PLATFORM SLO --> PLATFORM DEBUG --> PRACTICE PLATFORM --> PRACTICE %% 跨层关键连接 CORRELATE -.->|"Exemplar"| METRIC CORRELATE -.->|"TraceID"| LOG CORRELATE -.->|"ProfileID"| TRACE SLO -.->|"SLI 指标"| METRIC EBPF -.->|"零侵入追踪"| TRACE style 信号层 fill:#e8eaf6,stroke:#283593 style 采集层 fill:#e0f2f1,stroke:#00695c style 管道层 fill:#fff3e0,stroke:#e65100 style 存储层 fill:#fce4ec,stroke:#880e4f style 应用层 fill:#e8f5e9,stroke:#2e7d32

章节网络关系图#

graph LR Ch0["Ch0 导读"] --> Ch1["Ch1 全景"] Ch1 --> Ch2["Ch2 日志"] Ch1 --> Ch3["Ch3 指标"] Ch1 --> Ch4["Ch4 追踪"] Ch2 --> Ch5["Ch5 OTel"] Ch3 --> Ch5 Ch4 --> Ch5 Ch3 --> Ch6["Ch6 性能分析"] Ch4 --> Ch7["Ch7 eBPF"] Ch6 --> Ch7 Ch5 --> Ch8["Ch8 数据管道"] Ch7 --> Ch8 Ch8 --> Ch9["Ch9 存储"] Ch9 --> Ch12["Ch12 规模"] Ch2 --> Ch10["Ch10 信号关联"] Ch3 --> Ch10 Ch4 --> Ch10 Ch6 --> Ch10 Ch3 --> Ch11["Ch11 SLO"] Ch10 --> Ch11 Ch11 --> Ch13["Ch13 平台"] Ch12 --> Ch13 Ch10 --> Ch14["Ch14 生产调试"] Ch6 --> Ch14 Ch5 --> Ch15["Ch15 驱动开发"] Ch14 --> Ch15 Ch13 --> Ch16["Ch16 综合实战"] Ch14 --> Ch16 style Ch0 fill:#bbdefb,stroke:#1565c0 style Ch5 fill:#c8e6c9,stroke:#2e7d32 style Ch10 fill:#fff9c4,stroke:#f9a825 style Ch11 fill:#ffe0b2,stroke:#e65100 style Ch13 fill:#e1bee7,stroke:#6a1b9a style Ch16 fill:#ffcdd2,stroke:#c62828

知识关联参考表#

按五层模型组织：信号层（你观测什么）→ 采集层（如何产生信号）→ 管道层（如何传输处理）→ 存储层（如何持久化）→ 应用层（如何产生价值）。同一行的条目之间存在直接的知识依赖或概念映射。

信号采集方式管道处理存储后端应用场景
结构化日志OTel SDK / 手动仪器化批量发送、关联ID注入Loki / Elasticsearch错误排查、审计
Counter/Gauge 指标OTel SDK / Prometheus SDK降采样、基数控制VictoriaMetrics / MimirSLO 计算、容量规划
Histogram 指标OTel SDK / Prometheus SDK分桶合并、Exemplar 附加VictoriaMetrics / Mimir延迟分析、P99 计算
分布式追踪OTel SDK / eBPF 自动仪器化尾部采样、路由Tempo / Jaeger瓶颈定位、依赖分析
持续性能分析Parca / Pyroscope Agent符号解析、降采样Parca / Pyroscope火焰图、CPU/内存热点
eBPF 事件Beyla / Pixie内核态过滤、聚合任意后端零侵入观测、网络追踪

系列大纲#

以下是按章节编号排列的完整目录。建议结合上方的场景驱动阅读路线和知识导图选择适合你的阅读顺序。

章节标题核心内容
0系列导读系列定位、场景路线、知识导图、Docker 环境、参考资料
1可观测性全景监控 vs 可观测性、三大信号、认知模型、可观测性成熟度
2结构化日志结构化日志、关联ID、日志级别、日志框架对比
3指标体系Prometheus、四大度量类型、Histogram、基数爆炸
4分布式追踪Span/SpanContext、W3C TraceContext、Jaeger、采样策略
5OpenTelemetry 架构OTel API/SDK/Collector、自动仪器化、语义约定
6持续性能分析火焰图、Parca、Pyroscope、第四大支柱
7eBPF 零仪器化可观测性eBPF 原理、Beyla、零侵入追踪与指标
8可观测性数据管道OTel Collector 管道、采样、路由、转换、缓冲
9可观测性存储后端VictoriaMetrics、Mimir、Tempo、Loki、选型指南
10信号关联Exemplar、TraceID 关联、日志-指标-追踪-性能四信号联动
11SLO 驱动的可观测性SLO/SLI、错误预算、燃烧率、多窗口告警
12可观测性规模5 亿指标/秒、高基数、降采样、成本模型
13可观测性平台设计Grafana、多租户、数据生命周期、平台工程
14生产调试实战延迟分析、内存泄漏、间歇性故障、诊断方法论
15可观测性驱动开发结构化错误、业务指标、测试中的可观测性、开发体验
16综合实战Docker Compose 搭建完整可观测性平台、端到端验证

Docker 实验环境#

本系列所有实践操作均基于以下 Docker Compose 环境。你只需要 docker compose up -d 即可启动完整的可观测性技术栈。

技术栈组件#

graph TB subgraph 应用层[" 应用服务"] APP1["demo-api<br/>:8080"] APP2["demo-worker<br/>:8081"] end subgraph 采集层[" OTel 采集"] OTEL["OTel Collector<br/>:4317/:4318"] end subgraph 存储层[" 存储后端"] PROM["Prometheus<br/>:9090"] TEMPO["Tempo<br/>:3200"] LOKI["Loki<br/>:3100"] end subgraph 展示层[" 可视化"] GRAFANA["Grafana<br/>:3000"] end APP1 -->|"OTLP"| OTEL APP2 -->|"OTLP"| OTEL OTEL -->|"metrics"| PROM OTEL -->|"traces"| TEMPO OTEL -->|"logs"| LOKI GRAFANA --> PROM GRAFANA --> TEMPO GRAFANA --> LOKI style 应用层 fill:#e8eaf6,stroke:#283593 style 采集层 fill:#e0f2f1,stroke:#00695c style 存储层 fill:#fff3e0,stroke:#e65100 style 展示层 fill:#e8f5e9,stroke:#2e7d32

docker-compose.yml#

version: "3.8"


services:
  # ============ 应用服务 ============
  demo-api:
    image: ghcr.io/open-telemetry/demo:latest
    command: ["adservice"]
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
      - OTEL_RESOURCE_ATTRIBUTES=service.name=demo-api,service.version=1.0.0
    ports:
      - "8080:8080"
    depends_on:
      - otel-collector


  # ============ OTel Collector ============
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.96.0
    command: ["--config=/etc/otelcol/config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otelcol/config.yaml:ro
    ports:
      - "4317:4317"   # OTLP gRPC
      - "4318:4318"   # OTLP HTTP
      - "8889:8889"   # Prometheus exporter
      - "13133:13133" # Health check
    depends_on:
      - prometheus
      - tempo
      - loki


  # ============ 存储后端 ============
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yaml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"


  tempo:
    image: grafana/tempo:2.3.1
    command: ["-config.file=/etc/tempo/tempo.yaml"]
    volumes:
      - ./tempo.yaml:/etc/tempo/tempo.yaml:ro
      - tempo-data:/var/tempo
    ports:
      - "3200:3200"   # Tempo HTTP API
      - "4319:4319"   # OTLP gRPC (Tempo 接收)


  loki:
    image: grafana/loki:2.9.4
    command: ["-config.file=/etc/loki/loki.yaml"]
    volumes:
      - ./loki.yaml:/etc/loki/loki.yaml:ro
      - loki-data:/loki
    ports:
      - "3100:3100"


  # ============ 可视化 ============
  grafana:
    image: grafana/grafana:10.3.3
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    volumes:
      - ./grafana-datasources.yaml:/etc/grafana/provisioning/datasources/datasources.yaml:ro
      - grafana-data:/var/lib/grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus
      - tempo
      - loki


volumes:
  prometheus-data:
  tempo-data:
  loki-data:
  grafana-data:

OTel Collector 配置#

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


processors:
  batch:
    send_batch_size: 1024
    send_batch_max_size: 2048
    timeout: 5s
  resource:
    attributes:
      - key: collector.name
        value: otel-collector
        action: upsert


exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  otlphttp:
    endpoint: http://tempo:4318
  loki:
    endpoint: http://loki:3100/loki/api/v1/push
    default_labels_enabled:
      exporter: false


service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [loki]

快速启动#

# 克隆配置文件（本系列提供完整配置）
git clone https://github.com/your-org/observability-lab.git
cd observability-lab


# 启动所有服务
docker compose up -d


# 验证服务状态
docker compose ps


# 访问 Grafana
open http://localhost:3000


# 发送测试追踪
curl -X POST http://localhost:4318/v1/traces \
  -H "Content-Type: application/json" \
  -d '{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"test-service"}}]},"scopeSpans":[{"scope":{"name":"test"},"spans":[{"traceId":"01234567890123456789012345678901","spanId":"0123456789012345","name":"test-span","kind":1,"startTimeUnixNano":"1700000000000000000","endTimeUnixNano":"1700000001000000000"}]}]}]}'


# 查询 Prometheus 指标
curl http://localhost:9090/api/v1/query?query=up


# 查询 Loki 日志
curl "http://localhost:3100/loki/api/v1/query_range?query={service_name='demo-api'}&limit=10"

环境验证清单#

组件端口验证方式预期结果
OTel Collector4317/4318curl http://localhost:13133/HTTP 200
Prometheus9090curl http://localhost:9090/api/v1/query?query=up返回 targets 列表
Tempo3200curl http://localhost:3200/readyHTTP 200
Loki3100curl http://localhost:3100/readyHTTP 200
Grafana3000浏览器访问显示登录页面

推荐参考资料#

经典教材#

书籍作者特点
《Observability Engineering》Charity Majors, Liz Fong-Jones, George Miranda可观测性工程的”圣经”，Honeycomb 团队实战经验
《Systems Performance》Brendan Gregg性能分析与可观测性的百科全书，火焰图发明者亲著
《Distributed Systems Observability》Cindy Sridharan分布式系统可观测性的实践指南
《Site Reliability Engineering》Google SRE TeamSLO/SLI 方法论的权威来源
《The Art of Monitoring》James Turnbull监控系统设计的实战参考

官方文档#

文档链接说明
OpenTelemetryopentelemetry.ioOTel API/SDK/Collector 官方文档
Prometheusprometheus.ioPrometheus 查询、配置、最佳实践
Grafanagrafana.com/docsGrafana 面板、告警、数据源配置
Tempografana.com/docs/tempoGrafana Tempo 追踪存储
Lokigrafana.com/docs/lokiGrafana Loki 日志聚合
eBPFebpf.ioeBPF 技术生态

开源项目#

项目用途星标
OpenTelemetry可观测性标准与实现4k+
Parca持续性能分析4k+
Pyroscope持续性能分析（Grafana 生态）9k+
BeylaeBPF 零侵入可观测性1k+
PixieeBPF 可观测性平台5k+
Mimir大规模指标存储4k+

技术博客#

本系列的实践方法论#

本系列遵循 观测 → 假设 → 关联 → 验证 的可观测性方法论：

  1. 观测：通过指标发现异常（P99 延迟飙升、错误率上升）
  2. 假设：根据指标特征，对可能的根因提出假设（下游超时？缓存未命中？GC 停顿？）
  3. 关联：通过追踪定位瓶颈服务，通过日志查看错误上下文，通过性能分析找到热点函数
  4. 验证：修复问题后，通过指标确认改善效果，更新 SLO 和告警规则

每章的「动手实践」部分都遵循这一方法论，让你不仅知道”怎么用工具”，更理解”为什么这样用”。

准备好开始了吗？从 可观测性全景 开始你的可观测性工程之旅吧！

参考#

支持与分享

如果这篇文章对你有帮助，欢迎支持作者或分享给更多人

赞助
系列导读
https://blog.souloss.com/posts/observability/observability-series-guide/
作者
Souloss
发布于
2025-12-17
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

语义分析：类型检查与作用域
让AI使用工具：Function Calling实战
相关文章 智能推荐
1
综合实战：搭建可观测性平台
可观测性 综合实战——使用 OTel + Prometheus + Tempo + Loki + Grafana 搭建全链路可观测性平台，配置 SLO、告警规则，实现日志-指标-追踪的信号关联。
2
可观测性平台设计
可观测性 可观测性平台的架构设计——Grafana 作为统一可视化层、多租户隔离与配额、数据生命周期管理、平台工程实践，以及从工具到平台的演进路径。
3
可观测性全景：从监控到可观测性
可观测性 从传统监控到现代可观测性的范式转变——三大信号（日志、指标、追踪）的认知模型、可观测性成熟度模型、以及为什么'监控告诉你系统出了问题，可观测性让你理解为什么'。
4
指标体系：Prometheus 与度量类型
可观测性 深入 Prometheus 的四大度量类型（Counter、Gauge、Histogram、Summary），Histogram 分桶原理与 P99 计算、基数爆炸的成因与治理、以及如何用指标驱动 SLO 和告警。
5
系列导读
eBPF 本系列从 eBPF 的底层原理出发，系统讲解 eBPF 虚拟机、验证器、Map 数据结构、Hook 机制、CO-RE 可移植性，再到 XDP/TC 网络处理、LSM 安全、Cilium 实践、Wasm 融合、Kubernetes 集成与生产部署，带你从「听说过 eBPF」进阶到「能用 eBPF 解决真实问题」。
随机文章 随机推荐
1
BGP与域间路由：互联网的外交系统
互联网运作 2022-04-19
2
以太网与交换：数据包离开网卡
互联网运作 2022-02-15
3
containerd-shim
容器运行时 2026-05-06
4
持续性能分析：第四大支柱
可观测性 2025-08-25
5
Agent 开发框架对比：LangChain、AutoGen、CrewAI 与 OpenAI SDK
AI 2025-01-15
© 2026 Souloss. All Rights Reserved. / RSS / Atom / Sitemap
Powered by Astro & souloss  Version 9.0