可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载本指南基于 Apache SkyWalking 官方文档系统讲解如何让数据面代理 Envoy 通过内置的 gRPC Metrics Service 协议把运行时指标上报给 SkyWalking OAP并利用这些指标还原服务与实例拓扑。读完本文你将掌握两种主流接入方式独立 Envoy 静态配置接入含stats_sinks、gRPC cluster、节点元数据三段核心配置与Istio 一键注入接入含istioctl install/manifest install命令与proxyStatsMatcher精确控流并理解 OAP 侧接收器与示例工程可直接照抄落地。原理Envoy Metrics Service 协议与 SkyWalking 内置接收器Envoy 对外定义了一套基于 gRPC 的 metrics service 协议用于持续推送统计指标stats。只要实现了这套协议就能接收 Envoy 的指标流。SkyWalking 在 OAP 中内置了该协议的接收器因此你无需任何额外 Agent只需在 Envoy 侧开启上报即可把 Envoy 的指标接入 SkyWalking。作为 APM 系统SkyWalking 并不只是存指标——它还会基于 Envoy 指标中携带的服务元数据自动分析服务与服务实例之间的拓扑关系从而把数据面data plane的运行状态纳入统一的可观测视图。v2 / v3 两套协议版本需要特别注意的是Envoy Metrics Service 协议目前存在两个版本v2 协议对应envoy.service.metrics.v2.MetricsService主要面向 Envoy 1.18.x 及更早版本v3 协议对应envoy.service.metrics.v3.MetricsService是当前主流版本。SkyWalking8.3.0对这两个版本同时支持。从源码结构看OAP 的 envoy 接收器模块为两个版本分别实现了独立的 gRPC Handler——v2 的 MetricServiceGRPCHandler.java 与 v3 的 MetricServiceGRPCHandlerV3.java两者均继承自对应版本的MetricsServiceGrpc.MetricsServiceImplBase说明 OAP 是在同一个 gRPC 端口上按不同 proto 包名分别注册的接收端点。场景一无 Istio——独立 Envoy 手动配置接入Envoy 可以独立于 Istio 使用。要让独立的 Envoy 把指标发送给 SkyWalking核心是给 Envoy 喂一份包含stats_sinks的配置其中声明envoy.metrics_service并把该 sink 配置成一个config.grpc_service条目。核心配置段一stats_sinks 声明上报通道stats_sinks: - name: envoy.metrics_service config: grpc_service: # Note: we can use google_grpc implementation as well. envoy_grpc: cluster_name: service_skywalking要点说明envoy.metrics_service是 Envoy 内置的 metrics service sink 名称grpc_service下有两种实现可选envoy_grpc走 Envoy 自身 cluster 转发本示例采用与google_grpc走 gRPC 原生通道二选一即可envoy_grpc.cluster_name必须与下方static_resources.clusters中定义的 cluster 名称一致这里指向service_skywalking。核心配置段二定义指向 SkyWalking OAP 的 clusterstatic_resources: ... clusters: - name: service_skywalking connect_timeout: 5s type: LOGICAL_DNS http2_protocol_options: {} dns_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN load_assignment: cluster_name: service_skywalking endpoints: - lb_endpoints: - endpoint: address: socket_address: address: skywalking # This is the port where SkyWalking serving the Envoy Metrics Service gRPC stream. port_value: 11800关键字段解析connect_timeout: 5s与 OAP 建立连接的超时时间type: LOGICAL_DNS按域名解析出的每个 IP 建立连接示例中skywalking是 OAP 服务的 DNS 名若希望跟随 DNS 变更重建连接池可改用STRICT_DNS示例工程 envoy-v1.16.yaml 中使用的即是STRICT_DNShttp2_protocol_options: {}gRPC 基于 HTTP/2该字段必须保留否则无法与 OAP 建立 gRPC 流dns_lookup_family: V4_ONLY仅解析 IPv4IPv6 网络可注释掉该行port_value: 11800这是 SkyWalking OAP 对外提供 Envoy Metrics Service gRPC 流的端口与 OAP 接收 gRPC 遥测数据的默认端口一致请勿随意修改lb_policy: ROUND_ROBIN多端点时轮询负载均衡。仓库中 config.yaml 提供了一份完整可用的静态配置其中除了上述两段还包含 admin 管理端点127.0.0.1:9901、HTTP 监听器0.0.0.0:10000经envoy.http_connection_manager将请求转发至service_google集群以及访问www.google.com:443的 TLS 上游集群可以直接对照学习或作为模板修改。另外Envoy 的配置不限于静态文件也可以通过 xDS 协议进行动态下发Istio 场景即基于此机制详见下文。核心配置段三node 元数据——拓扑分析的关键如前所述SkyWalking 会从指标中还原服务拓扑前提是 Envoy 在指标中携带服务元数据。这部分元数据需要在 Envoy 的node节点配置中声明node: # ... other configs metadata: LABELS: app: test-app NAME: service-instance-nameLABELS.app用于标识服务serviceSkyWalking 将据此建立服务维度的拓扑节点NAME用于标识服务实例service instance帮助 SkyWalking 区分同一服务的多个实例。完整的 node 配置见 config.yaml还包含id、cluster、localityregion/zone/sub_zone以及自定义的skywalking/envoy键值这些信息都会随StreamMetricsMessage.identifier.node一并上报。你可以从样例报文 identify.json 中看到 Envoy 实际发送的完整 node 结构含id: ingress、cluster: envoy-proxy、locality 与 buildVersion 等。场景二有 Istio——一键注入免手写配置当 Envoy 运行在 Istio 服务网格中时配置工作会大大简化Istio 会通过 xDS 协议替你组装配置并下发给 Envoy同时自动把服务名、实例名等元数据注入到 bootstrap 配置中。你只需要在安装 Istio 时通过一个参数把 SkyWalking 地址告诉它。新装 Istioinstall 命令istioctl install -y \ --set profiledemo # replace the profile as per your need \ --set meshConfig.defaultConfig.envoyMetricsService.addressskywalking.address.port.11800 \ # replace skywalking.address.port.11800 with your actual SkyWalking OAP address --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[0].*已装 Istio免重装应用配置istioctl manifest install -y \ --set profiledemo # replace the profile as per your need \ --set meshConfig.defaultConfig.envoyMetricsService.addressskywalking.address.port.11800 \ # replace skywalking.address.port.11800 with your actual SkyWalking OAP address --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[0].*参数说明profiledemo按需替换为你使用的 Istio profile如default、demo等meshConfig.defaultConfig.envoyMetricsService.address必须替换为实际的 SkyWalking OAP 地址与 11800 端口例如skywalking-oap.observability.svc.cluster.local:11800proxyStatsMatcher.inclusionRegexps见下方指标裁剪说明。指标裁剪用 inclusionRegexps 控制上报范围有两点需要注意proxyStatsMatcher仅 Istio 1.8 支持强烈建议使用inclusionRegexps只保留需要分析的指标以降低内存占用、避免不必要的 CPU 开销——因为 Envoy 原生的统计项非常多全量上报会对 OAP 造成较大压力。OAP 实际会用到以下指标官方推荐的上报白名单正则istioctl manifest install -y \ --set profiledemo # replace the profile as per your need \ --set meshConfig.defaultConfig.envoyMetricsService.addressskywalking.address.port.11800 \ # replace skywalking.address.port.11800 with your actual SkyWalking OAP address --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[0].*membership_healthy.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[1].*upstream_cx_active.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[2].*upstream_cx_total.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[3].*upstream_rq_active.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[4].*upstream_rq_total.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[5].*upstream_rq_pending_active.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[6].*lb_healthy_panic.* \ --set meshConfig.defaultConfig.proxyStatsMatcher.inclusionRegexps[7].*upstream_cx_none_healthy.*这组正则覆盖了 OAP 拓扑与健康分析所需的核心统计membership_healthy上游集群健康成员、upstream_cx_*上游连接数/总数、upstream_rq_*上游请求数/排队数、lb_healthy_panic负载均衡健康恐慌等可以在 metrics.json 样例数据中看到这些指标的对应报文如cluster.service_stats.upstream_cx_total、cluster.service_stats.upstream_rq_pending_total等。指标数据报文体长什么样Envoy 上报的每条消息包含两部分identifier标识符与envoyMetrics指标数组。标识符部分即上文 node 元数据 locality buildVersion仓库中的 identify.json 给出了完整示例报文其中node.metadata携带LABELS.app与NAME正是拓扑分析的数据来源指标部分每条指标含name如cluster.service_stats.update_attempt、listener_manager.listener_added、typeCOUNTER/GAUGE以及带时间戳timestampMs的采样值见 metrics.json。关于 Envoy 各类统计项的完整清单可查阅 Envoy 官方文档中 cluster manager cluster stats 一节这里不展开。值得强调的是COUNTER 类指标如update_attempt、upstream_cx_total反映累计值GAUGE 类指标如membership_healthy、server.live、server.memory_allocated反映瞬时值OAP 侧会通过 Prometheus 格式的指标转换链路见 MetricServiceGRPCHandler.java 中对PrometheusMetricConverter的引用把它们归一化到统一的指标模型中。端到端实战docker-compose 一键演示仓库在 docs/en/setup/envoy/examples/metrics 目录下提供了完整的可运行示例包含 Envoy v1.16/v1.19 两个版本的配置、OAP 镜像与启动脚本$ make up $ docker-compose logs -f skywalking $ # 等待片刻待 SkyWalking 就绪且 Envoy 开始上报 stats 后会看到类似如下日志 skywalking_1 | 2021-07-23 13:25:30,683 - org.apache.skywalking.oap.server.receiver.envoy.MetricServiceGRPCHandler -19437 [grpcServerPool-1-thread-2] DEBUG [] - Received msg identifier { skywalking_1 | node { skywalking_1 | id: ingress skywalking_1 | cluster: envoy-proxy skywalking_1 | metadata { skywalking_1 | fields { skywalking_1 | key: LABELS skywalking_1 | value { skywalking_1 | struct_value { skywalking_1 | fields { skywalking_1 | key: app skywalking_1 | value { skywalking_1 | string_value: test-app skywalking_1 | } skywalking_1 | } skywalking_1 | } skywalking_1 | } skywalking_1 | } skywalking_1 | fields { skywalking_1 | key: NAME skywalking_1 | value { skywalking_1 | string_value: service-instance-name skywalking_1 | } skywalking_1 | } skywalking_1 | ... skywalking_1 | } skywalking_1 | } skywalking_1 | } skywalking_1 | envoy_metrics { skywalking_1 | name: cluster.service_google.update_no_rebuild skywalking_1 | type: COUNTER skywalking_1 | metric { skywalking_1 | counter { skywalking_1 | value: 1.0 skywalking_1 | } skywalking_1 | timestamp_ms: 1627046729718 skywalking_1 | } skywalking_1 | ... skywalking_1 | } $ # 停止并清理 $ make down该示例的工程结构说明docker-compose.yaml拉起envoyproxy/envoy-alpine:v1.16.2与apache/skywalking-oap-server:latest两个容器Envoy 通过挂载 envoy-v1.16.yaml 作为启动配置--service-cluster envoy-proxyOAP 暴露 11800 端口docker-compose-envoy-v3-api.yamlEnvoy Metrics ServiceV3 API版本的演示Makefile封装了docker-compose up -d/docker-compose down两个命令即make up与make downlog4j2.xml示例工程通过覆盖该文件将org.apache.skywalking.oap.server.receiver.envoy接收器包的日志级别调为DEBUG从而能在 OAP 日志里直观看到 Envoy 发来的每条消息——上述日志中的MetricServiceGRPCHandler ... DEBUG - Received msg即由此产生排查问题时也可照此开启。延伸Service Mesh 数据面网络监控本指南聚焦指标上报但值得顺带一提的是SkyWalking 还支持对 Service Mesh 数据面进行网络监控Network Monitoring相关能力与原理详见 数据面网络监控文档。它与本文的 Envoy Metrics 接入互为补充前者侧重网络流量观测后者侧重服务指标与拓扑分析。小结与排查建议接入链路可归纳为三步Envoy 配置stats_sinks→ 定义指向 OAP 11800 端口的 gRPC cluster → 在 node 元数据中声明服务/实例标识Istio 场景则由meshConfig.defaultConfig.envoyMetricsService.address一行完成全部配置配合proxyStatsMatcher精确控流。实际排障时可按以下顺序核对连通性Envoy 所在节点能否访问 OAP 的 11800 端口可用curl -v telnet://oap-ip:11800之类方式验证 TCP 可达协议匹配确认 Envoy 使用的 Metrics Service 版本v2/v3与 OAP 版本8.3.0 双版本均支持上报是否触发按示例工程的方式把接收器日志调到 DEBUG观察MetricServiceGRPCHandler是否打印Received msg元数据是否齐全检查 node 元数据中LABELS.app与NAME是否配置否则拓扑分析会缺失服务/实例维度。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐SkyWalking 接入 Envoy Metrics Service 指标独立部署与 Istio 服务网格两种配置方案详解SkyWalking 接入 Envoy Metrics Service 指标独立部署与 Istio 服务网格两种配置方案详解 本篇技术指南以 Apache S可观测性APM链路追踪指标监控日志分析微服务终极指南Sentinel如何与Service Mesh完美集成Istio、Envoy实战终极指南Sentinel如何与Service Mesh完美集成Istio、Envoy实战 Sentinel作为阿里巴巴开源的流量控制组件在微服务架构中发后端微服务如何通过Service Mesh Interface实现Istio标准化部署与管理如何通过Service Mesh Interface实现Istio标准化部署与管理 Istio作为开源服务网格的领军项目通过Service Mesh Inte服务网格云原生微服务网络负载均衡可观测性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考