【SkyWalking从入门到精通】第65篇：Service Mesh数据的采集监控——Mixer与ALS模式的监控差异与排查指南

下一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控 上一篇【第66篇】SkyWalking观测Service Mesh——挑战、混合部署与统一拓扑图

一、Service Mesh监控的特殊性

Service Mesh监控和传统的语言探针监控，有着本质的不同：

+——————————————————————+
| 两种数据采集模式的本质差异 |
+——————————————————————+
| |
| 传统Agent模式（侵入式） |
| ┌──────────────────────────────────────┐ │
| │ Application │ │
| │ ┌────────────────────────────┐ │ │
| │ │ Business Code │ │ │
| │ │ ┌──────────────────────┐ │ │ │
| │ │ │SkyWalking Agent │ │ │ │
| │ │ │(字节码增强,同进程) │ │ │ │
| │ │ └──────────────────────┘ │ │ │
| │ └────────────────────────────┘ │ │
| │ │ 上报 │ │
| └──────────────┼────────────────────────┘ │
| ↓ │
| OAP Server │
| |
| Service Mesh模式（非侵入式） |
| ┌──────────────────────────────────────┐ │
| │ Pod │ │
| │ ┌──────────┐ ┌──────────┐ │ │
| │ │ App │ │ Envoy │ │ │
| │ │Container │ │Sidecar │ │ │
| │ │(无Agent!) │ │(代理所有 │ │ │
| │ │ │ │ 进出流量) │ │ │
| │ └─────┬─────┘ └────┬─────┘ │ │
| │ │ │ │ │
| │ 进出流量 ─────────→ Envoy截获 │ │
| │ │ 上报 │ │
| └────────────────────────┼──────────────┘ │
| ↓ │
| OAP Server │
| |
| 关键区别: |
| – Agent模式：深入到代码级别，能看到方法调用、数据库访问等 |
| – Mesh模式：只能在网络层面看到进出流量，粒度粗但无需代码改动 |
| |
+——————————————————————+

二、两种数据接收模式

2.1 Mixer模式（已废弃）

Istio的Mixer组件负责从Envoy收集遥测数据，然后转发给Adapter（如SkyWalking Mixer Adapter）。

+——————————————————————+
+ Mixer模式的数据流 |
+——————————————————————+
| |
| Envoy Sidecar Istio Mixer |
| ┌──────────────┐ ┌─────────────┐ |
| │ 每次请求 │ │ │ |
| │ ↓ │ ──report()──→ │ 接收请求 │ |
| │ 构造Attribute│ │ ↓ │ |
| │ (大量的 │ │ 检查规则 │ |
| │ key-value) │ │ ↓ │ |
| └──────────────┘ │ 调用Adapter │ |
| │ ↓ │ |
| │ SkyWalking │ |
| │ Mixer │ ──→ OAP |
| │ Adapter │ |
| └─────────────┘ |
| |
| 问题：每次请求都要同步调用Mixer → 性能开销大 |
| Istio 1.5+ 已废弃Mixer |
| |
+——————————————————————+

2.2 ALS模式（Envoy Access Log Service）

ALS（Access Log Service）是Envoy的原生功能。Envoy将每次请求的访问日志通过gRPC流直接发送给配置的ALS服务端。

+——————————————————————+
+ ALS模式的数据流 +
+——————————————————————+
| |
| Envoy Sidecar |
| ┌────────────────────────────────────────────┐ |
| │ │ |
| │ 请求处理 │ |
| │ ↓ │ |
| │ 构造Access Log │ |
| │ ┌──────────────────────────────────────┐ │ |
| │ │ { │ │ |
| │ │ "timestamp": "2026-07-02T10:…",│ │ |
| │ │ "method": "GET", │ │ |
| │ │ "path": "/api/user", │ │ |
| │ │ "response_code": 200, │ │ |
| │ │ "upstream_host": "order-svc:8080",│ │ |
| │ │ "duration": 45, // ms │ │ |
| │ │ "request_id": "xxx", │ │ |
| │ │ "x-request-id": "…", │ │ |
| │ │ … │ │ |
| │ │ } │ │ |
| │ └──────────────────┬───────────────────┘ │ |
| │ │ │ |
| │ ↓ │ |
| │ ┌──────────────────────────────────────┐ │ |
| │ │ ALS gRPC Client (内置) │ │ |
| │ │ 通过gRPC流发送到 OAP Server │ │ |
| │ └──────────────────────────────────────┘ │ |
| └──────────────────────┬─────────────────────┘ |
| │ |
| ┌──────────▼──────────┐ |
| │ OAP Server │ |
| │ ┌────────────────┐ │ |
| │ │ ALS Receiver │ │ ← 端口 11800 (复用gRPC) │
| │ └───────┬────────┘ │ |
| │ │ │ |
| │ ↓ │ |
| │ ┌────────────────┐ │ |
| │ │ ALS Analyzer │ │ ← 解析AccessLog │
| │ │ → 构造Metrics │ │ → 生成拓扑 │
| │ │ → 构造Trace │ │ |
| │ └────────────────┘ │ |
| └──────────────────────┘ |
| |
+——————————————————————+

三、Mixer vs ALS 的监控差异

3.1 差异对比表

+——————————————————————+
+ Mixer vs ALS 监控指标对比 +
+——————————————————————+
| |
| 指标维度 Mixer模式 ALS模式 |
| ─────────────────────────────────────────────────────────────── │
| 数据完整性 取决于Mixer规则配置 默认完整（所有请求） |
| 延迟影响 每次请求额外调用Mixer 异步发送，几乎无影响 |
| CPU开销 OAP+Mixer双进程 仅OAP |
| 内存开销 中等 中等 |
| |
| 可监控维度 较丰富(Attribute多) 受限(仅AccessLog字段) |
| 配置复杂度 高(需Adapter+规则) 低(仅Envoy配置) |
| 数据丢失风险 高(Mixer过载时丢失) 中(gRPC流溢出时) |
| |
| 排查难度 Mixer→Envoy间链路复杂 单一链路，简单 |
| 版本兼容性 Istio 1.4- Istio 1.5+ |
| |
+——————————————————————+

3.2 ALS数据丢失的常见原因

# === ALS数据丢失排查清单 ===

# 1. 检查Envoy配置是否正确
kubectl get configmap -n istio-system istio -o yaml | grep accessLog

# 预期输出应包含:
# accessLogFile: /dev/stdout
# 或
# accessLogService:
# address: skywalking-oap.istio-system:11800

# 2. 检查Envoy Sidecar是否正常运行
kubectl exec -it <pod> -c istio-proxy — pilot-agent request GET stats

# 3. 查看Envoy的ALS连接状态
kubectl exec -it <pod> -c istio-proxy — \\
curl -s http://localhost:15000/clusters | grep als

# 4. 检查OAP的ALS接收端口
netstat -tlnp | grep 11800

# 5. 检查OAP日志
# 搜索 "ALS" 或 "AccessLog" 相关日志
grep -i "access.log\\|als" oap-server/logs/skywalking-oap-server.log

四、大规模Service Mesh的OAP容量规划

4.1 数据量估算公式

+——————————————————————+
+ Service Mesh数据量估算 +
+——————————————————————+
| |
| 输入参数: |
| ┌───────────────────────────────────────────┐ │
| │ P = Pod数量 │ │
| │ R = 每个Pod的请求速率 (requests/sec) │ │
| │ S = 每个AccessLog的大小 (约300-500 bytes) │ │
| │ D = 数据保留天数 │ │
| │ C = 压缩比 (约0.3, Protobuf压缩) │ │
| └───────────────────────────────────────────┘ │
| |
| 计算: |
| ┌───────────────────────────────────────────┐ │
| │ 每秒数据量 = P × R × S × C │ │
| │ 每天数据量 = 每秒数据量 × 86400 │ │
| │ 总存储量 = 每天数据量 × D (假设无副本) │ │
| │ OAP实例数 = CEIL(每秒数据量 / 5000) │ │
| │ (假设单OAP处理5000条/秒) │ │
| └───────────────────────────────────────────┘ │
| |
| 示例: |
| P=100个Pod, R=100 req/s, S=400 bytes |
| 每秒数据量 = 100 × 100 × 400 × 0.3 = 1,200,000 bytes ≈ 1.2 MB/s|
| 每天数据量 ≈ 100 GB |
| 30天保留 ≈ 3 TB |
| 推荐OAP实例数 = CEIL(10000/5000) = 2 |
| 推荐ES节点数 = 3 (1主2数据) |
| |
+——————————————————————+

4.2 参数调优参考

# 不同规模下的OAP JVM参数建议

# 小型 (< 50 Pods)
JAVA_OPTS: "-Xms2g -Xmx2g -XX:+UseG1GC"

# 中型 (50-200 Pods)
JAVA_OPTS: "-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

# 大型 (200-500 Pods)
JAVA_OPTS: "–Xms8g –Xmx8g –XX:+UseG1GC –XX:MaxGCPauseMillis=200
–XX:G1HeapRegionSize=8m –XX:ParallelGCThreads=8"

# 超大型 (500+ Pods)
JAVA_OPTS: "-Xms16g -Xmx16g …"
# 建议：水平扩展OAP而非继续增加单机堆大小

五、Agent与Service Mesh混合部署的监控

在实际生产中，混合架构非常常见——有些服务用Java Agent，有些用Service Mesh。

+——————————————————————+
+ 混合部署的统一监控 +
+——————————————————————+
| |
| ┌──────────────────────────────┐ ┌──────────────────────────────┐
| │ Java Service (有Agent) │ │ Go Service (无Agent) │
| │ ┌────────────────────────┐ │ │ ┌────────────────────────┐ │
| │ │ App │ │ │ │ App │ │
| │ │ + SkyWalking Agent │ │ │ │ (无Agent) │ │
| │ └────────┬───────────────┘ │ │ └────────┬───────────────┘ │
| │ │ │ │ │ │
| │ 完整Trace: │ │ 仅有网络层: │
| │ 方法级+DB+缓存+… │ │ 请求/响应/延迟 │
| │ │ │ │ │ │
| └───────────┼──────────────────┘ └───────────┼──────────────────┘
| │ │ │
| └────────────┬───────────────────┘ │
| │ │
| ↓ │
| ┌──────────────┐ │
| │ OAP Server │ │
| │ │ │
| │ 统一拓扑图中: │ │
| │ Agent节点:深度追踪 │ │
| │ Mesh节点:网络层数据 │ │
| └──────────────┘ │
| |
| 混合监控的挑战: |
| 1. Agent提供的数据比Mesh更丰富 → 拓扑图中信息不对称 |
| 2. 一个请求穿越Agent和Mesh → 需要正确串联 |
| 3. 需要sw8头部在Mesh层被保留（Envoy默认保留所有Header） |
| |
+——————————————————————+

六、排查实例

实例1：ALS数据不上报

# 症状：SkyWalking UI中看不到Service Mesh的服务节点

# 步骤1：确认Envoy配置
kubectl exec -it <pod> -c istio-proxy — \\
curl -s http://localhost:15000/config_dump | \\
grep -A 10 access_log

# 步骤2：检查Envoy到OAP的网络连通性
kubectl exec -it <pod> -c istio-proxy — \\
curl -s telnet://oap-service.istio-system:11800

# 步骤3：查看Envoy日志
kubectl logs <pod> -c istio-proxy | grep -i "als\\|access"

# 步骤4：确认OAP中ALS Receiver已启用
# 检查 application.yml 中 envoy-mesh 相关配置

实例2：数据量与预期不符

# 症状：Service Mesh的QPS远低于实际QPS

# 可能原因：
# 1. Envoy只采样部分日志（检查sampling配置）
# 2. DNS解析导致的重复请求未被正确合并
# 3. 健康检查请求被错误计入
# 4. OAP处理能力不足，部分数据被丢弃

# 排查：
# 1. 统计Envoy的实际请求数
kubectl exec -it <pod> -c istio-proxy — \\
curl -s http://localhost:15000/stats | grep "http.ingress"

# 2. 统计OAP接收到的AccessLog数量
# 查看OAP的metrics端点
curl http://oap:1234/metrics | grep "envoy_als"

# 3. 对比两者差异，定位数据丢失环节

七、总结

Service Mesh的监控有其独特之处：

–下一篇我们将深入讲解SkyWalking如何具体观测Service Mesh。

下一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控 上一篇【第66篇】SkyWalking观测Service Mesh——挑战、混合部署与统一拓扑图