可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载Apache SkyWalking 内置实现了 Envoy 的 Metrics Service gRPC 协议接收端允许将数据面Data Plane的 Envoy 代理指标实时上报到 OAP Server用于服务网格可观测性分析。本篇以仓库中docs/en/setup/envoy/examples/metrics/下的官方示例为核心完整讲解基于 Docker Compose 一键启动 Envoy SkyWalking OAP 的指标上报链路覆盖 Metrics Service v2/v3 两代 gRPC 接口的配置差异、DEBUG 日志验证方法并结合 OAP 端envoy-metric接收器配置与 MAL 指标规则说明底层工作方式。读完本文你将掌握如何在本地复现 Envoy 指标上报、如何自定义 Envoy 的stats_sinks与node.metadata以及如何在不借助 Istio 的情况下完成数据面监控接入。示例目标Envoy Stats 直达 SkyWalking OAP该示例的目标非常明确通过 Envoy 的Metric Service协议gRPC 流式上报把 Envoy 运行时产生的 Envoy Stats 持续推送给 SkyWalking OAP Server。示例同时覆盖了协议的两个版本v2envoy.service.metrics.v2.MetricsService对应 Envoy 1.16 等旧版本v3envoy.service.metrics.v3.MetricsService对应 Envoy 1.19 及更新版本。SkyWalking OAP 侧从 8.3.0 起同时支持这两个版本。在仓库的 OAP 接收器源码中可以看到这一设计MetricServiceGRPCHandler直接继承MetricsServiceGrpc.MetricsServiceImplBasegRPC 自动生成的服务基类而MetricServiceGRPCHandlerV3同样继承 v3 版本的MetricsServiceGrpc.MetricsServiceImplBase并将streamMetrics调用委托给前者处理从而以一份核心逻辑同时兼容两代协议。相关实现位于MetricServiceGRPCHandler.javaMetricServiceGRPCHandlerV3.java一键运行示例Docker Compose示例的运行环境要求本地安装docker与docker-compose镜像从 Docker Hub 拉取。仓库在示例目录下提供了 Makefile封装了启停命令up: docker-compose up -d down: docker-compose down .PHONY: up down在 docs/en/setup/envoy/examples/metrics 目录下按以下步骤操作$ make up $ docker-compose logs -f skywalking第一条命令以后台模式拉起全部服务第二条命令持续跟踪skywalking容器的日志。等待片刻待 SkyWalking 完成初始化、Envoy 开始上报统计指标后日志中会出现类似如下的 DEBUG 输出由MetricServiceGRPCHandler打印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 | fields { skywalking_1 | key: envoy skywalking_1 | value { skywalking_1 | string_value: isawesome skywalking_1 | } skywalking_1 | } skywalking_1 | fields { skywalking_1 | key: skywalking skywalking_1 | value { skywalking_1 | string_value: iscool skywalking_1 | } skywalking_1 | } skywalking_1 | } skywalking_1 | locality { skywalking_1 | region: ap-southeast-1 skywalking_1 | zone: zone1 skywalking_1 | sub_zone: subzone1 skywalking_1 | } skywalking_1 | user_agent_name: envoy skywalking_1 | user_agent_build_version { skywalking_1 | version { skywalking_1 | major_number: 1 skywalking_1 | minor_number: 19 skywalking_1 | } skywalking_1 | ... skywalking_1 | } skywalking_1 | extensions { ... } 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 | } skywalking_1 | ...日志结构清晰展示了StreamMetricsMessage的两大部分identifier.nodeEnvoy 节点的身份信息包括id、cluster、metadata含LABELS、NAME等自定义元数据、locality地域/可用区/子区以及版本与构建信息。SkyWalking 正是依据这些元数据来识别服务与服务实例进而构建服务拓扑envoy_metrics具体的指标项每条包含指标name如cluster.service_google.update_no_rebuild、指标type如COUNTER以及带时间戳的采样值。实验结束后在示例目录执行以下命令拆除环境$ make down两种协议版本的 Compose 与 Envoy 配置对照示例目录下有两套相互独立的 Compose 编排文件分别演示 v2 与 v3 协议方案一Envoy 1.16 Metrics Service v2docker-compose.yamlversion: 3 services: envoy16: image: envoyproxy/envoy-alpine:v1.16.2 command: /usr/local/bin/envoy -c /etc/envoy.yaml --service-cluster envoy-proxy ports: - 10000:10000 depends_on: - skywalking volumes: - ./envoy-v1.16.yaml:/etc/envoy.yaml skywalking: image: apache/skywalking-oap-server:latest volumes: - ./log4j2.xml:/skywalking/config/log4j2.xml expose: - 11800配套的 envoy-v1.16.yaml 中v2 协议的关键配置是stats_sinks使用name: envoy.metrics_service与config.grpc_servicestats_sinks: - name: envoy.metrics_service config: grpc_service: envoy_grpc: cluster_name: service_skywalking同时必须在clusters中声明名为service_skywalking的上游集群指向 OAP 的 11800 端口且启用 HTTP/2gRPC 必需clusters: - name: service_skywalking connect_timeout: 5s type: STRICT_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 port_value: 11800方案二Envoy 1.19 Metrics Service v3docker-compose-envoy-v3-api.yamlversion: 3 services: envoy19: image: envoyproxy/envoy-alpine:v1.19-latest command: /usr/local/bin/envoy -c /etc/envoy.yaml --service-cluster envoy-proxy ports: - 10001:10000 depends_on: - skywalking volumes: - ./envoy-v1.19.yaml:/etc/envoy.yaml skywalking: image: apache/skywalking-oap-server:latest volumes: - ./log4j2.xml:/skywalking/config/log4j2.xml expose: - 11800与 v2 方案的差异点使用了 Envoy 1.19 镜像宿主机端口映射为10001:10000避开与方案一冲突Envoy 配置文件改为 envoy-v1.19.yamlstats_sinks使用 v3 命名空间即envoy.stat_sinks.metrics_service并通过typed_config显式声明transport_api_version: V3stats_sinks: - name: envoy.stat_sinks.metrics_service typed_config: type: type.googleapis.com/envoy.config.metrics.v3.MetricsServiceConfig transport_api_version: V3 grpc_service: envoy_grpc: cluster_name: service_skywalkingv3 配置中的service_skywalking集群与 v2 基本一致但 HTTP/2 协议选项采用了 v3 的扩展写法clusters: - name: service_skywalking connect_timeout: 5s type: LOGICAL_DNS typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: type: type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config: 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 port_value: 11800提示示例集群配置中带有# Comment out the following line to test on v6 networks注释即在纯 IPv6 网络环境下可注释掉dns_lookup_family: V4_ONLY以允许 IPv6 解析。两套 Envoy 配置中的流量转发目标service_google均指向www.google.com:443v1.16 配置使用tls_context.sniv1.19 配置使用UpstreamTlsContext用于制造真实流量从而让 Envoy 产生可观测的集群统计指标。启用 OAP 侧 DEBUG 日志验证上报示例中特意覆盖了 OAP 的 log4j2 配置log4j2.xml 的核心内容如下Configuration statusINFO Appenders Console nameConsole targetSYSTEM_OUT PatternLayout charsetUTF-8 pattern%d - %c -%-4r [%t] %-5p %x - %m%n/ /Console /Appenders Loggers logger nameorg.apache.zookeeper levelINFO/ logger nameio.grpc.netty levelINFO/ logger nameorg.apache.skywalking.oap.server.receiver.istio.telemetry levelDEBUG/ !-- We make envoy metrics receiver to log at DEBUG level -- logger nameorg.apache.skywalking.oap.server.receiver.envoy levelDEBUG/ Root levelINFO AppenderRef refConsole/ /Root /Loggers /Configuration关键点在于将接收器包org.apache.skywalking.oap.server.receiver.envoy的日志级别调整为DEBUG。这样MetricServiceGRPCHandler中打印的Received msg ...原始消息即 Envoy 上报的StreamMetricsMessage就会输出到控制台便于直观确认 Envoy 已成功与 OAP 建立 gRPC 流并持续上报指标。该文件通过 Compose 的 volume 挂载覆盖到容器内/skywalking/config/log4j2.xml。在生产环境并不建议全局开启 DEBUG这只适合本地验证链路连通性。OAP 端接收器配置与指标处理原理envoy-metric 接收器配置段OAP 的默认配置 application.yml 中envoy-metric模块负责 Envoy 指标以及 ALS 访问日志分析的接收关键配置如下envoy-metric: selector: ${SW_ENVOY_METRIC:default} default: acceptMetricsService: ${SW_ENVOY_METRIC_SERVICE:true} alsHTTPAnalysis: ${SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS:} alsTCPAnalysis: ${SW_ENVOY_METRIC_ALS_TCP_ANALYSIS:} k8sServiceNameRule: ${K8S_SERVICE_NAME_RULE:${pod.metadata.labels.(service.istio.io/canonical-name)}.${pod.metadata.namespace}} istioServiceNameRule: ${ISTIO_SERVICE_NAME_RULE:${serviceEntry.metadata.name}.${serviceEntry.metadata.namespace}}其中acceptMetricsService: true默认开启即表示 OAP 在 11800 端口接受 Envoy 通过 Metrics Service 协议上报的指标流alsHTTPAnalysis与alsTCPAnalysis则用于配置 Envoy ALSAccess Log Service的 HTTP/TCP 分析规则属于访问日志维度与本文的指标上报相互独立。从 gRPC 流到指标入库从源码结构看指标处理链路分为三段接收MetricServiceGRPCHandler.streamMetrics通过 gRPC 双向流接收 Envoy 上报的StreamMetricsMessagev3 版本由MetricServiceGRPCHandlerV3委托给前者转换消息中的envoy_metrics通过ProtoMetricFamily2MetricsAdapter适配为 Prometheus 格式的Metric对象再交由PrometheusMetricConverter按 MAL 规则进行转换入库转换结果通过MeterSystem写入指标系统供后续查询与告警使用。处理器还会借助 telemetry 模块记录envoy_metric_in_count收到的 Envoy 指标条数与envoy_metric_in_latency处理延迟两项自监控指标。MAL 规则示例转换规则定义在 envoy-metrics-rules/envoy.yaml以 MALMeter Analysis Language编写例如expSuffix: instance([app], [instance], Layer.MESH_DP) metricPrefix: envoy metricsRules: - name: heap_memory_used exp: server_memory_heap_size - name: cluster_membership_healthy exp: envoy_cluster_metrics.tagMatch(metrics_name , .membership_healthy).tagMatch(metrics_name , cluster.outbound.|cluster.inbound.).tagNotMatch(cluster_name , .kube-system).sum([app, instance , cluster_name]) - name: cluster_up_cx_incr exp: envoy_cluster_metrics.tagMatch(metrics_name , .upstream_cx_total).tagMatch(metrics_name , cluster.outbound.|cluster.inbound.).sum([app, instance , cluster_name]).increase(PT1M)可以看出expSuffix将 Envoy 节点元数据中的app来自LABELS映射为服务、instance来自NAME映射为服务实例并归属到Layer.MESH_DP数据面层metricsRules则把原始 Envoy 指标名如server_memory_heap_size换算为带envoy前缀的 SkyWalking 指标如envoy_heap_memory_used并对集群类指标按cluster_name维度聚合。这也解释了为何示例中要在 Envoy 的node.metadata里填写LABELS.app与NAME它们决定了服务与服务实例在 SkyWalking 中的最终命名。不借助 Istio 的独立 Envoy 接入要点与示例同目录的配置指南 metrics_service_setting.md 对独立 Envoy无 Istio场景做了更完整的说明。核心思路与示例一致让 Envoy 的stats_sinks指向envoy.metrics_service并配置为config.grpc_servicegRPC 服务地址条目。该文档还特别说明grpc_service既可以使用envoy_grpc实现通过 Envoy 内置集群转发也可以使用google_grpc实现。其给出的精简配置骨架与示例中的service_skywalking集群定义一一对应端口11800即 SkyWalking 对外提供 Envoy Metrics Service gRPC 流的端口。为支撑服务拓扑分析需要让 Envoy 在node.metadata中携带服务元数据node: # ... other configs metadata: LABELS: app: test-app NAME: service-instance-name此外Envoy 的配置不仅可以通过静态文件下发也可以通过 xDS 协议动态下发。当 Envoy 运行在 Istio 网格中时Istio 会自动完成上述stats_sinks与元数据的注入仅需在安装或更新 Istio 时设置meshConfig.defaultConfig.envoyMetricsService.addressskywalking.address.port.11800即可将指标导向 SkyWalking同时可通过proxyStatsMatcherIstio 1.8 支持的inclusionRegexps白名单正则来精筛需要上报的指标例如.*membership_healthy.*、.*upstream_cx_total.*、.*lb_healthy_panic.*等 OAP 实际分析所用的指标从而降低 Envoy 内存占用与 CPU 开销。指标数据形态参考为帮助理解上报数据的结构仓库提供了两份样例数据identify.json包含节点标识identifier.node的完整样例展示了id: ingress、cluster: envoy-proxy、metadata以及locality的 JSON 形态metrics.json纯指标样例覆盖三种 Prometheus 指标类型COUNTER如cluster.service_stats.upstream_cx_total、cluster.service_google.update_attempt携带递增计数值GAUGE如cluster.service_stats.membership_healthy、server.memory_heap_size、server.uptime表示当前瞬时状态SUMMARY如cluster.service_stats.upstream_cx_connect_ms携带多个分位点quantile 0.25 至 0.999的分布信息。每条指标均带timestampMs时间戳。指标命名遵循 Envoy 的层级规范例如cluster.名称.upstream_cx_total表示某个上游集群的连接总数listener_manager.total_listeners_active表示活跃监听器数量server.memory_heap_size表示堆内存大小等等。常见问题与注意事项看不到日志输出先确认make up是否已成功且 OAP 已启动完成再确认 Envoy 容器是否生成了流量示例中需访问localhost:10000/localhost:10001触发转发到www.google.com。若 OAP 日志仍无 DEBUG 输出检查 log4j2.xml 是否被正确挂载到容器内/skywalking/config/log4j2.xml以及org.apache.skywalking.oap.server.receiver.envoy的级别是否为DEBUG。端口与协议匹配Envoy 的 Metrics Service 走 gRPC因此service_skywalking集群必须启用 HTTP/2v1.16 配置使用http2_protocol_options: {}v1.19 配置使用 v3 扩展的explicit_http_config.http2_protocol_options二者不可混用。同时确认 OAP 侧acceptMetricsService未关闭默认true。协议版本对应使用 Envoy 1.16 时对应 Metrics Service v2 配置envoy.metrics_serviceconfig使用 Envoy 1.19 时对应 v3 配置envoy.stat_sinks.metrics_servicetyped_configtransport_api_version: V3请按镜像版本选择对应的stats_sinks写法。服务命名SkyWalking 中服务名取自node.metadata.LABELS.app服务实例名取自node.metadata.NAME若未配置这些元数据将无法在拓扑与实例维度上正确归并指标。网络环境默认dns_lookup_family: V4_ONLY面向 IPv4 环境如需在 IPv6 网络测试可注释掉该行。小结本文围绕官方示例完整还原了Envoy 上报指标 → OAP 接收 → 指标转换入库的全链路通过 Makefile 一键启停、两套 Compose 与 Envoy 配置分别演示 Metrics Service v2/v3 协议、借助 log4j2.xml 的 DEBUG 级别验证 gRPC 消息内容并延伸讲解了 OAP 端 application.yml 的envoy-metric配置与 envoy.yaml MAL 规则如何将原始 Envoy 指标转换为 SkyWalking 指标。无论你的 Envoy 运行在独立模式还是 Istio 网格内都可以基于本示例快速打通数据面指标到 SkyWalking 的监控通道。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐使用 Docker Compose 示例将 Envoy 指标发送到 SkyWalking OAP 服务器使用 Docker Compose 示例将 Envoy 指标发送到 SkyWalking OAP 服务器 本篇技术指南讲解如何基于 Apache SkyWalk可观测性APM链路追踪指标监控日志分析微服务Apache SkyWalking OAP 外部通信通道配置指南receiver-sharing-server 独立 gRPC/HTTP 服务详解Apache SkyWalking OAP 外部通信通道配置指南receiver sharing server 独立 gRPC/HTTP 服务详解 导读 Sk可观测性后端微服务云原生Apache APISIX skywalking-logger 插件实战将网关访问日志无缝推送至 SkyWalking OAPApache APISIX skywalking logger 插件实战将网关访问日志无缝推送至 SkyWalking OAP skywalking logg后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
