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

2026/7/22 12:37:30

下一篇【第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-nistio-system istio-oyaml|grepaccessLog# 预期输出应包含:# accessLogFile: /dev/stdout# 或# accessLogService:# address: skywalking-oap.istio-system:11800# 2. 检查Envoy Sidecar是否正常运行kubectlexec-it<pod>-cistio-proxy -- pilot-agent request GET stats# 3. 查看Envoy的ALS连接状态kubectlexec-it<pod>-cistio-proxy --\curl-shttp://localhost:15000/clusters|grepals# 4. 检查OAP的ALS接收端口netstat-tlnp|grep11800# 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配置kubectlexec-it<pod>-cistio-proxy --\curl-shttp://localhost:15000/config_dump|\grep-A10access_log# 步骤2：检查Envoy到OAP的网络连通性kubectlexec-it<pod>-cistio-proxy --\curl-stelnet://oap-service.istio-system:11800# 步骤3：查看Envoy日志kubectl logs<pod>-cistio-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的实际请求数kubectlexec-it<pod>-cistio-proxy --\curl-shttp://localhost:15000/stats|grep"http.ingress"# 2. 统计OAP接收到的AccessLog数量# 查看OAP的metrics端点curlhttp://oap:1234/metrics|grep"envoy_als"# 3. 对比两者差异，定位数据丢失环节