下一篇【第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 ServiceALSAccess 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开销 OAPMixer双进程 仅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-itpod-cistio-proxy -- pilot-agent request GET stats# 3. 查看Envoy的ALS连接状态kubectlexec-itpod-cistio-proxy --\curl-shttp://localhost:15000/clusters|grepals# 4. 检查OAP的ALS接收端口netstat-tlnp|grep11800# 5. 检查OAP日志# 搜索 ALS 或 AccessLog 相关日志grep-iaccess.log\|alsoap-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条/秒) │ │ | └───────────────────────────────────────────┘ │ | | | 示例: | | P100个Pod, R100 req/s, S400 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:MaxGCPauseMillis200# 大型 (200-500 Pods)JAVA_OPTS:-Xms8g-Xmx8g-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:G1HeapRegionSize8m-XX:ParallelGCThreads8# 超大型 (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 | | | ------------------------------------------------------------------六、排查实例实例1ALS数据不上报# 症状SkyWalking UI中看不到Service Mesh的服务节点# 步骤1确认Envoy配置kubectlexec-itpod-cistio-proxy --\curl-shttp://localhost:15000/config_dump|\grep-A10access_log# 步骤2检查Envoy到OAP的网络连通性kubectlexec-itpod-cistio-proxy --\curl-stelnet://oap-service.istio-system:11800# 步骤3查看Envoy日志kubectl logspod-cistio-proxy|grep-ials\|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-itpod-cistio-proxy --\curl-shttp://localhost:15000/stats|grephttp.ingress# 2. 统计OAP接收到的AccessLog数量# 查看OAP的metrics端点curlhttp://oap:1234/metrics|grepenvoy_als# 3. 对比两者差异定位数据丢失环节七、总结Service Mesh的监控有其独特之处非侵入式无需修改应用代码Envoy Sidecar负责所有数据采集粒度有限只有网络层数据请求/响应/延迟不像Agent能深入方法级别ALS优于Mixer性能好、配置简单、Istio原生支持混合部署AgentMesh混合是很常见的架构需要关注拓扑图中信息层次的统一–下一篇我们将深入讲解SkyWalking如何具体观测Service Mesh。下一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控上一篇【第66篇】SkyWalking观测Service Mesh——挑战、混合部署与统一拓扑图
