07 可观测性体系

渐儿
0 阅读9分钟

面试官关注点：你能不能把日志、指标、链路追踪融合起来做根因分析？知道 SLS/ARMS 并用过吗？能写 PromQL 查询吗？

一、可观测性三支柱

维度回答什么问题代表产品
Metrics（指标）系统运行在什么状态？Prometheus、ARMS Prometheus、CloudMonitor
Logs（日志）发生了什么？SLS、ELK、Loki
Traces（链路）请求为什么慢 / 错？ARMS、Jaeger、SkyWalking、Zipkin

新增第四支柱：Events（事件） — K8s 事件、变更事件、告警事件；Profiles（剖析） — CPU/内存火焰图。

二、监控指标体系（Metrics）

2.1 指标分层

业务层：订单量、GMV、转化率、DAU
应用层：QPS、延迟、错误率、JVM 指标
中间件：MQ 积压、DB 连接、缓存命中率
系统层：CPU、内存、磁盘、网络
基础设施：云产品指标（SLB QPS、RDS CPU）

2.2 四大黄金指标（Google SRE）

  1. Latency 延迟
  2. Traffic 流量
  3. Errors 错误
  4. Saturation 饱和度

2.3 Prometheus 核心概念

概念说明
Target被抓取对象（/metrics 接口）
Metric指标，有 name + labels
Sample时序数据点（timestamp, value）
Series一组（metric + labels）组合的时序
ScrapePrometheus 主动抓取
Exporter将非原生应用指标转成 Prom 格式（node_exporter、mysql_exporter）

2.4 指标类型

  • Counter：累计计数（只增不减），如请求总数
  • Gauge：瞬时值，可增可减，如内存使用
  • Histogram：分桶统计，可算分位数（客户端预定义桶）
  • Summary：客户端算分位数（不推荐，聚合不友好）

2.5 PromQL 实战

# QPS（5 分钟速率）
rate(http_requests_total[5m])

# 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) 
  / sum(rate(http_requests_total[5m]))

# P99 延迟
histogram_quantile(0.99, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# 按服务分组的 P99
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# CPU 使用率
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 内存使用率
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Top 5 耗内存 Pod
topk(5, sum(container_memory_working_set_bytes{namespace="prod"}) by (pod))

# 同比（昨天同时段对比）
rate(http_requests_total[5m]) 
  / rate(http_requests_total[5m] offset 1d)

2.6 Prometheus 生产架构

  • 单机：< 100 万 series 可扛
  • 分片：按服务/业务拆多实例（hashmod）
  • 联邦：上层 Prom 聚合下层
  • 远程存储：Thanos / VictoriaMetrics / ARMS Prometheus / Mimir（长期存储 + 跨集群查询）

阿里云 ARMS Prometheus：

  • 全托管，自动采集 ACK 集群指标
  • 兼容开源 PromQL 和 Grafana
  • 数据保留 15 月起
  • 大规模场景性能优于自建

三、日志体系（Logs）

3.1 SLS（日志服务）

阿里云日志平台标杆产品，整个阿里内部也用它（原名 Loghub）。

核心能力：

  • LogHub：采集（Logtail/API/SDK），秒级入库
  • LogSearch：查询分析（自研 SQL，索引秒级）
  • LogShipper：投递到 OSS/MaxCompute
  • Data Transform：实时 ETL、富化、脱敏
  • 告警 + AI 异常检测

3.2 Logtail 采集模式

  • 极简模式：单行文本
  • 正则模式：按正则分字段
  • 分隔符模式：CSV/TSV
  • JSON 模式：JSON 自动解析字段
  • 容器模式：按容器 Label/环境变量 过滤

Logtail 资源消耗低（单机 CPU < 5%），比 Filebeat/Fluentd 更省。

3.3 日志规范（生产必做）

必含字段：
- timestamp（纳秒精度）
- level（INFO/WARN/ERROR）
- service_name
- traceId / spanId（关联链路）
- userId / orderId（业务维度，按需）
- message
- 堆栈（ERROR 级别必带）

格式：JSON（便于结构化查询）

等级规范：
- DEBUG：生产关闭
- INFO：关键业务动作
- WARN：可恢复异常
- ERROR：需告警的错误

3.4 SLS 查询示例

-- 最近 1 小时错误日志 top 10 按服务
* AND level:ERROR 
| SELECT service_name, COUNT(*) as cnt 
  GROUP BY service_name 
  ORDER BY cnt DESC 
  LIMIT 10

-- 延迟分位数
* | SELECT 
    approx_percentile(latency_ms, 0.50) as p50,
    approx_percentile(latency_ms, 0.99) as p99,
    approx_percentile(latency_ms, 0.999) as p999

-- 按 traceId 串联全链路
traceId:"abc123"

-- 同比环比
* | SELECT 
    count_if(event_time > now() - interval '5' minute) as now_cnt,
    count_if(event_time between now() - interval '10' minute 
             and now() - interval '5' minute) as prev_cnt

3.5 成本治理

日志最容易爆预算的地方。

  • 采样：DEBUG/INFO 按 1%-10% 采样，ERROR 100% 留
  • 冷热分离：3 天热数据索引，30 天冷数据只存（投递 OSS）
  • 字段索引：只给高频查询字段建索引（索引流量也收费）
  • 压缩存储：SLS 默认已压缩
  • 日志分级 Project：核心业务独立 project，降级可单独处理

四、链路追踪（Tracing）

4.1 核心概念

  • Trace：一次完整请求
  • Span：Trace 中的一个调用片段（有 parent/child 关系）
  • TraceId / SpanId：标识，全链路透传
  • Baggage：跨 Span 传递的业务字段

4.2 追踪协议

  • OpenTelemetry（OTel）：CNCF 毕业，新事实标准
  • OpenTracing（已合并入 OTel）
  • Jaeger / Zipkin 格式：存储格式
  • W3C Trace Context：HTTP Header 标准（traceparent/tracestate）

4.3 ARMS 应用监控

阿里云托管 APM，核心能力：

  • 自动埋点：Java Agent 无侵入接入，Node.js/Python/Go 也支持
  • 全链路视图：微服务调用拓扑
  • 慢 SQL / 慢接口自动采集
  • 异常诊断：自动关联 JVM 指标、线程池、GC
  • 业务监控：注解式埋点

ARMS 和开源对比：

  • 优势：托管、与 SLS/Prometheus 深度集成、AI 诊断
  • 劣势：成本比开源 SkyWalking 高

4.4 采样策略

全量采样成本爆炸，需要采样：

  • 头部采样：入口随机 1% 保留 trace
  • 尾部采样：先全收，根据 trace 最终状态（错/慢）决定保留
  • 分层采样：错误 100%、慢请求 100%、正常 1%
  • 业务关键路径：核心交易 100%，非核心 1%

4.5 追踪与日志联动（黄金场景）

告警触发 → 打开 ARMS 慢调用列表 → 点到一个 trace → 看到某个 Span 慢
→ 右键跳到 SLS 过滤该 traceId 看日志细节 → 定位业务代码
→ 看 Prometheus 该时间段该节点 CPU → 确认是否资源压力

能讲出这套组合拳，面试加分很多。

五、告警体系

5.1 告警分级

级别响应通道
P0立刻响应（5 分钟）电话 + 短信 + 群
P130 分钟响应短信 + 群
P2工时内响应群 + 邮件
P3日报汇总邮件

5.2 告警设计原则

  1. 可操作：每条告警必须有对应 Runbook
  2. 不重复：合并关联告警，抑制下游告警
  3. 不漏报：关键指标双通道告警
  4. 不误报：定期 review，误报率 > 20% 必须优化

5.3 常见告警模式

  • 阈值告警：简单，适合稳定基线
  • 同比/环比：消除周期性
  • 趋势预测：线性回归预测到达阈值
  • 异常检测（AI）：ARMS/SLS 内置智能异常检测（3σ/移动平均/Prophet）
  • 日志告警：ERROR 日志激增
  • 多指标联合：A 且 B 才告警

5.4 告警风暴抑制

  • 分组：同服务/同集群告警合并
  • 静默：变更窗口、已知故障抑制
  • 依赖抑制：根因告警抑制派生告警
  • 冷却：同告警 N 分钟内不重复发
  • 智能降噪：AIOps 合并关联告警

六、eBPF 可观测（前沿）

6.1 为什么 eBPF

  • 零侵入：不改应用代码
  • 全栈覆盖：从内核到应用
  • 低性能损耗：内核态执行

6.2 产品

  • Cilium Hubble：网络流量可视化
  • Pixie：K8s 全栈可观测
  • Parca：持续 profiling
  • 阿里云 SysOM：基于 eBPF 的系统诊断

七、成本与落地策略

7.1 成本优先级

通常监控成本占整体云成本 5-10%，过高需要治理。

  • 指标：控制 series 数量（label 基数爆炸是头号杀手）
  • 日志：采样、冷热分层
  • 链路：尾部采样
  • 存储：长期低频数据下沉 OSS

7.2 Label 基数爆炸反面教材

❌ 把 userId 作为 label：百万级 series 炸库
❌ 把完整 URL 作为 label：URL 无穷多
✅ URL path 模板（/api/users/:id）
✅ 业务维度放到日志，不放指标

7.3 落地路线图（新团队）

  1. M1（1 月）：节点 + K8s 基础指标（ARMS Prometheus）+ 日志接入 SLS
  2. M2：应用 APM 接入 ARMS，关键服务 SLO 看板
  3. M3：告警体系分级、Runbook 初版
  4. M4：链路追踪 + 日志联动，根因分析流程化
  5. M5：成本治理 + AIOps 降噪
  6. M6：混沌工程 + 故障演练，验证可观测覆盖度

八、面试高频问答

Q1：Prometheus 怎么做高可用？ A：

  • 本地：两台 Prom 同时抓取同一套 target，前面挂 Alertmanager 集群做去重告警
  • 长期存储：Thanos Sidecar 上传块到 OSS，Thanos Query 聚合查询
  • 跨集群：ARMS Prometheus 或 Thanos Query 联邦

Q2：为什么 Histogram 比 Summary 好？ A：

  • Summary 在客户端算分位数，多副本无法合并（分位数不可加）
  • Histogram 服务端算（histogram_quantile），可跨实例聚合
  • 缺点：Histogram 精度取决于桶划分，要合理设置

Q3：SLS 和 ELK 怎么选？ A：

  • SLS 优势：全托管、成本低（小规模）、秒级写入、查询快、与阿里云深度集成、大规模免运维
  • ELK 优势：开源可控、本地部署、生态丰富
  • 建议：阿里云环境 SLS 为主，跨云/本地 IDC 混合用 ELK

Q4：链路追踪怎么在老 Java 系统接入？ A：

  • 无侵入方案：ARMS Java Agent（-javaagent）或 SkyWalking Agent
  • 自动埋点常见框架（Spring/Dubbo/HTTP Client/JDBC/Redis）
  • 自定义埋点：OpenTelemetry SDK 注解
  • 坑：Agent 版本兼容、异步线程 TraceId 透传（需用 MDC + 包装 Runnable）

Q5：告警总是太多怎么办？ A：结构化治理：

  1. Review 历史告警：Top N 噪声源
  2. 调阈值：基于历史数据 P99 值 +buffer
  3. 合并告警：按服务/集群聚合
  4. 分级：真正要叫人的才 P0/P1
  5. 自愈：能自动处理的闭环（磁盘清理、重启）
  6. 看板替代：趋势类关注放大盘，不必告警

Q6：怎么监控微服务之间的依赖健康？ A：

  • 链路追踪：ARMS 自动画服务拓扑
  • 服务网格层：Istio/ASM 提供 request_duration、error_rate 分服务
  • SLO 看板：每个服务独立 SLO 页面
  • 变更关联：监控面板叠加发布事件

Q7：指标数据保留多久合适？ A：

  • 实时指标（秒级）：7-14 天
  • 5 分钟降采样：3-6 月
  • 1 小时降采样：1-3 年
  • 成本和价值权衡，历史趋势分析用低精度足够

Q8：应用 OOM 了怎么定位？ A：

  • 日志：SLS 找 OOM 关键字（OutOfMemoryError、dmesg OOM killer）
  • 指标：Prometheus 看 JVM old 区增长趋势
  • Heap dump：应用配 -XX:+HeapDumpOnOutOfMemoryError 自动落盘
  • 链路：看 OOM 前相关请求（是否有超大返回/批量查询）
  • 持续 profiling：Parca/pyroscope 捕捉内存分配热点

Q9：怎么设计一个高价值 SLO 看板？ A：

  • 最上层：业务成功率、延迟、量（老板看）
  • 中层：依赖服务调用健康（按下游分）
  • 底层：基础设施（CPU/内存/网络/依赖中间件）
  • 右侧：变更事件时间线（发布、配置变更）
  • 交互：下钻能力，从业务指标点到服务点到实例

Q10：ARMS 和 Prometheus 的关系？ A：

  • ARMS Prometheus：托管 Prom 服务，协议兼容开源
  • ARMS 应用监控：独立 APM 产品（链路追踪 + 应用指标 + 诊断）
  • ARMS 前端监控 / 小程序：端侧
  • 生产推荐组合：ARMS Prometheus（指标） + SLS（日志） + ARMS APM（链路）

九、必读资源

  • 《Observability Engineering》Charity Majors
  • OpenTelemetry 官方文档
  • Google SRE Book Ch6 监控
  • 阿里云 SLS / ARMS / Prometheus 产品文档
avatar
文章
阅读
粉丝