下一篇【第65篇】Service Mesh数据的采集监控——Mixer与ALS模式的监控差异与排查指南上一篇【第67篇】SkyWalking观测Istio Mixer模式——Adapter配置、Telemetry接收与废弃原因一、Service Mesh观测的三个天然挑战在Service Mesh架构中做可观测性有三座大山横在面前挑战1数据是扁平的传统Agent嵌在应用代码里能看到方法栈、能看到SQL、能看到缓存操作。但Envoy Sidecar只能看到网络流量——它不知道你的业务方法是createOrder还是cancelOrder它只知道POST /api/order。挑战2拓扑推断需要猜测Agent模式下Dubbo Consumer创建ExitSpanProvider创建EntrySpan中间的父子关系明明白白。而Mesh模式下Envoy只记录了谁发起了请求和谁收到了请求中间的关联需要靠请求头来推断。挑战3多集群场景的数据一致性跨Kubernetes集群的Service Mesh部署数据分散在不同集群中如何统一收集和展示是个难题。二、SkyWalking的应对策略2.1 通过AccessLog还原请求拓扑------------------------------------------------------------------ | 从AccessLog到拓扑图的转换过程 | ------------------------------------------------------------------ | | | Envoy AccessLog条目: | | ┌────────────────────────────────────────────────────────────┐ │ | │ { │ │ | │ source: frontend-7d8f-abc12, │ │ | │ destination: order-service-7d8f-def34, │ │ | │ method: POST, │ │ | │ path: /api/order, │ │ | │ upstream_cluster: outbound|8080||order-service.ns, │ │ | │ response_code: 200, │ │ | │ duration: 45, │ │ | │ request_id: xxx-yyy-zzz │ │ | │ } │ │ | └────────────────────────────────────────────────────────────┘ │ | │ │ | ↓ OAP ALS Analyzer │ | │ | 解析结果: │ | ┌────────────────────────────────────────────────────────────┐ │ | │ │ │ | │ 拓扑关系: │ │ | │ frontend ──→ order-service │ │ | │ │ │ | │ Metrics: │ │ | │ service_cpm: frontend → order-service 1 │ │ | │ service_avg: 45ms │ │ | │ service_resp_time: 45ms │ │ | │ │ │ | │ Trace (近似): │ │ | │ Span1: frontend (exit) --45ms--→ Span2: order-service │ │ | │ (entry) │ │ | └────────────────────────────────────────────────────────────┘ │ | | ------------------------------------------------------------------2.2 请求头中的加密电报——sw8传播SkyWalking利用Envoy的request_id和自定义Header如sw8在Mesh层面传播链路上下文# Istio EnvoyFilter 添加sw8 header传播apiVersion:networking.istio.io/v1alpha3kind:EnvoyFiltermetadata:name:skywalking-sw8-propagationnamespace:istio-systemspec:configPatches:-applyTo:NETWORK_FILTERmatch:context:SIDECAR_OUTBOUNDlistener:filterChain:filter:name:envoy.filters.network.http_connection_managerpatch:operation:MERGEvalue:typed_config:type:type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManageraccess_log:-name:envoy.access_loggers.http_grpctyped_config:type:type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfigcommon_config:log_name:skywalkingtransport_api_version:V3grpc_service:envoy_grpc:cluster_name:outbound|11800||skywalking-oap.istio-system.svc.cluster.localadditional_request_headers_to_log:-sw8# 传播SkyWalking的trace header-x-request-id# 传播请求ID三、语言探针与Service Mesh的混合拓扑3.1 混合场景的拓扑融合------------------------------------------------------------------ | 混合部署的拓扑融合挑战 | ------------------------------------------------------------------ | | | 场景AAgent服务调用Mesh服务 | | ┌─────────────────┐ ┌─────────────────┐ │ | │ Java Service │ │ Go Service │ │ | │ (Agent) │ │ (Mesh only) │ │ | │ │ POST │ │ │ | │ createOrder() │ ──────→ │ CreateOrder() │ │ | │ ↓ │ sw8 │ (不可见) │ │ | │ MySQL查询可见 │ header │ │ │ | │ │ │ │ │ | └─────────────────┘ └─────────────────┘ │ | | | 拓扑图中 | | Java Service ────→ Go Service | | ┌──────┐ ┌──────┐ │ | │丰富 │ │只有 │ │ | │指标 │ │网络 │ │ | │(DB可见)│ │指标 │ │ | └──────┘ └──────┘ │ | | | 场景B跨Mesh的Agent服务 | | ┌─────────────────┐ ┌─────────────────┐ │ | │ Java Service │ │ Java Service │ │ | │ (Agent Mesh) │ │ (Agent Mesh) │ │ | │ │ │ │ │ | │ Agent上报: │ sw8 │ Agent上报: │ │ | │ ExitSpan │ ──────→ │ EntrySpan │ │ | │ │ │ │ │ | │ Mesh上报: │ 日志 │ Mesh上报: │ │ | │ AccessLog │ ──────→ │ AccessLog │ │ | └─────────────────┘ └─────────────────┘ │ | | | 拓扑图挑战如何合并Agent和Mesh对同一请求的两份数据 | | OAP需要识别Agent的ExitSpan Mesh的AccessLog同一请求 │ | 解决通过TraceId关联 | | | ------------------------------------------------------------------3.2 统一拓扑图的实现原理OAP在构建拓扑图时遵循以下原则同TraceId的Span优先合并Agent数据优先级高于Mesh数据粒度更细缺失数据由另一方补充// OAP中拓扑构建的简化逻辑publicclassTopologyBuilder{publicTopologybuild(ListSegmentsegments,ListAccessLogaccessLogs){TopologytopologynewTopology();// 1. 从Agent的Span中提取节点和边for(Segmentsegment:segments){NodefromNodecreateNode(segment.getServiceName());fromNode.addLabels(segment.getLabels());// Agent标签更丰富for(Spanspan:segment.getSpans()){if(spaninstanceofExitSpan){NodetoNodecreateNode(span.getPeerName());topology.addEdge(fromNode,toNode,span);}}}// 2. 从Mesh的AccessLog中补充for(AccessLoglog:accessLogs){NodefromNodetopology.findNode(log.getSourceServiceName());NodetoNodetopology.findNode(log.getDestinationServiceName());// 如果Agent已经捕获了这个关系补充Mesh指标if(topology.hasEdge(fromNode,toNode)){topology.enrichEdge(fromNode,toNode,log);}else{// Agent没有捕获到纯Mesh服务创建新边topology.addEdge(fromNode,toNode,log);}}returntopology;}}四、Service Mesh可观测性的最佳实践4.1 实践黄金规则------------------------------------------------------------------ Service Mesh可观测性实践金字塔 ------------------------------------------------------------------ | | | ┌────────────┐ | | │ 业务级监控 │ ← 自定义Metrics/Alerts | | │ (L5) │ | | ├────────────┤ | | │ 应用级追踪 │ ← 语言Agent Logging │ | │ (L4) │ | | ┌┴────────────┴┐ | | │ 网络层可观测 │ ← AccessLog Mesh │ | │ (L3) │ | | ├──────────────┤ | | │ 基础设施监控 │ ← K8s Prometheus │ | │ (L2) │ | | ├──────────────┤ | | │ 平台级健康 │ ← SkyWalking自身健康 │ | │ (L1) │ | | └──────────────┘ | | | | 数据覆盖层级: | | L1-L2: 基础设施 平台健康 → 通用监控工具 | | L3: Mesh可观测 → SkyWalking ALS模式 | | L4: 应用追踪 → SkyWalking Agent | | L5: 业务监控 → SkyWalking 自定义Metrics | | | ------------------------------------------------------------------4.2 部署建议# 推荐为不同角色配置不同的OAP实例# 配置ATrace处理OAP处理Agent数据application-trace.yml:core:selector:standalonegRPCHost:0.0.0.0gRPCPort:11800# Agent连接此端口receiver-trace:selector:default# 配置BMesh处理OAP处理ALS数据application-mesh.yml:core:selector:standalonegRPCHost:0.0.0.0gRPCPort:11801# Envoy连接此端口envoy-mesh:als:enabled:true# 分开部署的好处# - Trace数据和Mesh数据可以独立扩容# - 避免一组OAP故障影响另一组数据# - 可分别监控和告警五、性能优化建议------------------------------------------------------------------ Service Mesh观测性能优化要点 ------------------------------------------------------------------ | | | 优化项 效果 复杂度 | | ─────────────────────────────────────────────────────────────── │ | 启用Envoy的AccessLog缓冲 减少gRPC流开销 低 | | 使用专用OAP处理Mesh数据 避免相互影响 中 | | 限制AccessLog字段数量 减少数据量 低 | | 增加OAP实例数 提高处理能力 中 | | 使用Kafka缓冲Mesh数据 削峰持久化 高 | | | ------------------------------------------------------------------# Envoy AccessLog缓冲配置typed_config:type:type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfigcommon_config:log_name:skywalkingbuffer_flush_interval:10s# 每10秒刷新一次buffer_size_bytes:10485760# 10MB缓冲区transport_api_version:V3六、总结Service Mesh的可观测性是一个由外向内的过程挑战数据扁平化、拓扑推断困难、多集群复杂性应对通过AccessLog解析还原拓扑sw8 Header传播上下文混合架构Agent优先级 Mesh数据取长补短最佳实践分角色部署OAP合理配置缓冲建立多层观测体系我们进入对Istio两种模式Mixer和ALS的深度解析。下一篇【第65篇】Service Mesh数据的采集监控——Mixer与ALS模式的监控差异与排查指南上一篇【第67篇】SkyWalking观测Istio Mixer模式——Adapter配置、Telemetry接收与废弃原因
)
