当前位置： 首页 > news >正文

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

news 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. 对比两者差异，定位数据丢失环节

七、总结

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

  1. 非侵入式：无需修改应用代码，Envoy Sidecar负责所有数据采集
  2. 粒度有限：只有网络层数据（请求/响应/延迟），不像Agent能深入方法级别
  3. ALS优于Mixer：性能好、配置简单、Istio原生支持
  4. 混合部署：Agent+Mesh混合是很常见的架构，需要关注拓扑图中信息层次的统一

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

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

http://www.jsqmd.com/news/1241181/

相关文章：

  • 深入解析TMS320C54x DSP架构：从改进哈佛结构到高效信号处理实战
  • 从零开始学习betaflight《1-代码架构》
  • 基于 CentOS7 搭建 5 节点三层高可用 Web 集群（Nginx+Keepalived+Tomcat+MySQL 主从）
  • 标识工程出片品质哪家高？2026年十大出片品牌深度测评，所见即所得不踩雷 - 工业品牌热点
  • 2026惠阳黄金回收哪家靠谱？7月最新行情+避坑攻略+正规门店**（附上门电话） - 生活测评小能手
  • 从Selenium到Playwright：现代Web自动化测试的核心优势与实战指南
  • 2026 年如何使用 Python 抓取 Reddit 数据
  • 【小程序计算机毕业设计案例】基于SpringBoot的家庭健康数据记录与就医指导系统 便民居家医疗监护服务助手小程序(程序+文档+讲解+定制)
  • TI微控制器时钟域与系统控制：从架构原理到工程实践
  • 大模型多智能体系统架构与实战指南
  • TI PRU-ICSS IEP定时器：工业实时系统的硬件心跳与寄存器级配置实战
  • 二手MacBook价格波动解析与选购指南
  • 用了就上头的硬核APP
  • LaTeX与Word对比：专业排版与文档处理的核心差异
  • 嵌入式网络开发实战：EMAC/MDIO寄存器编程与中断管理详解
  • 重庆唐邦知识产权费用高吗避坑指南，实力测评与客户信赖之选 - 工业推荐榜
  • 智慧交通道路路障倒树检测数据集 树倒检测识别 树木倒伏检测数据集的训练及应用 森林灾害监测、道路安全巡检、河道清障、无人机林业巡查、项目 / 毕设课题
  • 基于Jenkins与Kubernetes的CI/CD自动化部署实践
  • Docker部署etcd集群权限问题解决方案
  • 深入解析Tiva C系列ADC核心寄存器：多通道采样与数据流管理实战
  • 从“跑断腿”到“掌上控”：楼宇暖通远程运维的价值重估
  • 学生综合素质评价系统开发公司
  • 工业现场疑难软故障实录：08 参数漂移，最隐蔽的系统老化
  • 深入解析eQEP模块：正交编码器解码、位置计数与速度测量实战
  • Java参数校验实战：从基础注解到自定义校验器
  • 频谱分析仪维修中最容易被误判的故障：本底噪声升高就是硬件坏了吗?
  • 从命令行管理文件
  • 小安派工：体育馆弱电施工从细节规避音视频网络安防系统故障风险
  • 声发射在线监测系统如何实现设备状态实时感知？从数据采集到智能预警全过程解析
  • 我给 Windows 版 Codex 做了一个主题注入器