可觀測性后端微服務(wù)云原生【免費下載鏈接】skywalkingAPM, Application Performance Monitoring System項目地址https://gitcode.com/gh_mirrors/sky/skywalking點擊查看免費下載本指南基于 Apache SkyWalking 官方文檔系統(tǒng)講解如何讓數(shù)據(jù)面代理 Envoy 通過內(nèi)置的 gRPC Metrics Service 協(xié)議把運行時指標上報給 SkyWalking OAP并利用這些指標還原服務(wù)與實例拓撲。讀完本文你將掌握兩種主流接入方式獨立 Envoy 靜態(tài)配置接入含stats_sinks、gRPC cluster、節(jié)點元數(shù)據(jù)三段核心配置與Istio 一鍵注入接入含istioctl install/manifest install命令與proxyStatsMatcher精確控流并理解 OAP 側(cè)接收器與示例工程可直接照抄落地。原理Envoy Metrics Service 協(xié)議與 SkyWalking 內(nèi)置接收器Envoy 對外定義了一套基于 gRPC 的 metrics service 協(xié)議用于持續(xù)推送統(tǒng)計指標stats。只要實現(xiàn)了這套協(xié)議就能接收 Envoy 的指標流。SkyWalking 在 OAP 中內(nèi)置了該協(xié)議的接收器因此你無需任何額外 Agent只需在 Envoy 側(cè)開啟上報即可把 Envoy 的指標接入 SkyWalking。作為 APM 系統(tǒng)SkyWalking 并不只是存指標——它還會基于 Envoy 指標中攜帶的服務(wù)元數(shù)據(jù)自動分析服務(wù)與服務(wù)實例之間的拓撲關(guān)系從而把數(shù)據(jù)面data plane的運行狀態(tài)納入統(tǒng)一的可觀測視圖。v2 / v3 兩套協(xié)議版本需要特別注意的是Envoy Metrics Service 協(xié)議目前存在兩個版本v2 協(xié)議對應(yīng)envoy.service.metrics.v2.MetricsService主要面向 Envoy 1.18.x 及更早版本v3 協(xié)議對應(yīng)envoy.service.metrics.v3.MetricsService是當前主流版本。SkyWalking8.3.0對這兩個版本同時支持。從源碼結(jié)構(gòu)看OAP 的 envoy 接收器模塊為兩個版本分別實現(xiàn)了獨立的 gRPC Handler——v2 的 MetricServiceGRPCHandler.java 與 v3 的 MetricServiceGRPCHandlerV3.java兩者均繼承自對應(yīng)版本的MetricsServiceGrpc.MetricsServiceImplBase說明 OAP 是在同一個 gRPC 端口上按不同 proto 包名分別注冊的接收端點。場景一無 Istio——獨立 Envoy 手動配置接入Envoy 可以獨立于 Istio 使用。要讓獨立的 Envoy 把指標發(fā)送給 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 內(nèi)置的 metrics service sink 名稱grpc_service下有兩種實現(xiàn)可選envoy_grpc走 Envoy 自身 cluster 轉(zhuǎn)發(fā)本示例采用與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關(guān)鍵字段解析connect_timeout: 5s與 OAP 建立連接的超時時間type: LOGICAL_DNS按域名解析出的每個 IP 建立連接示例中skywalking是 OAP 服務(wù)的 DNS 名若希望跟隨 DNS 變更重建連接池可改用STRICT_DNS示例工程 envoy-v1.16.yaml 中使用的即是STRICT_DNShttp2_protocol_options: {}gRPC 基于 HTTP/2該字段必須保留否則無法與 OAP 建立 gRPC 流dns_lookup_family: V4_ONLY僅解析 IPv4IPv6 網(wǎng)絡(luò)可注釋掉該行port_value: 11800這是 SkyWalking OAP 對外提供 Envoy Metrics Service gRPC 流的端口與 OAP 接收 gRPC 遙測數(shù)據(jù)的默認端口一致請勿隨意修改lb_policy: ROUND_ROBIN多端點時輪詢負載均衡。倉庫中 config.yaml 提供了一份完整可用的靜態(tài)配置其中除了上述兩段還包含 admin 管理端點127.0.0.1:9901、HTTP 監(jiān)聽器0.0.0.0:10000經(jīng)envoy.http_connection_manager將請求轉(zhuǎn)發(fā)至service_google集群以及訪問www.google.com:443的 TLS 上游集群可以直接對照學(xué)習(xí)或作為模板修改。另外Envoy 的配置不限于靜態(tài)文件也可以通過 xDS 協(xié)議進行動態(tài)下發(fā)Istio 場景即基于此機制詳見下文。核心配置段三node 元數(shù)據(jù)——拓撲分析的關(guān)鍵如前所述SkyWalking 會從指標中還原服務(wù)拓撲前提是 Envoy 在指標中攜帶服務(wù)元數(shù)據(jù)。這部分元數(shù)據(jù)需要在 Envoy 的node節(jié)點配置中聲明node: # ... other configs metadata: LABELS: app: test-app NAME: service-instance-nameLABELS.app用于標識服務(wù)serviceSkyWalking 將據(jù)此建立服務(wù)維度的拓撲節(jié)點NAME用于標識服務(wù)實例service instance幫助 SkyWalking 區(qū)分同一服務(wù)的多個實例。完整的 node 配置見 config.yaml還包含id、cluster、localityregion/zone/sub_zone以及自定義的skywalking/envoy鍵值這些信息都會隨StreamMetricsMessage.identifier.node一并上報。你可以從樣例報文 identify.json 中看到 Envoy 實際發(fā)送的完整 node 結(jié)構(gòu)含id: ingress、cluster: envoy-proxy、locality 與 buildVersion 等。場景二有 Istio——一鍵注入免手寫配置當 Envoy 運行在 Istio 服務(wù)網(wǎng)格中時配置工作會大大簡化Istio 會通過 xDS 協(xié)議替你組裝配置并下發(fā)給 Envoy同時自動把服務(wù)名、實例名等元數(shù)據(jù)注入到 bootstrap 配置中。你只需要在安裝 Istio 時通過一個參數(shù)把 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免重裝應(yīng)用配置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].*參數(shù)說明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只保留需要分析的指標以降低內(nèi)存占用、避免不必要的 CPU 開銷——因為 Envoy 原生的統(tǒng)計項非常多全量上報會對 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 拓撲與健康分析所需的核心統(tǒng)計membership_healthy上游集群健康成員、upstream_cx_*上游連接數(shù)/總數(shù)、upstream_rq_*上游請求數(shù)/排隊數(shù)、lb_healthy_panic負載均衡健康恐慌等可以在 metrics.json 樣例數(shù)據(jù)中看到這些指標的對應(yīng)報文如cluster.service_stats.upstream_cx_total、cluster.service_stats.upstream_rq_pending_total等。指標數(shù)據(jù)報文體長什么樣Envoy 上報的每條消息包含兩部分identifier標識符與envoyMetrics指標數(shù)組。標識符部分即上文 node 元數(shù)據(jù) locality buildVersion倉庫中的 identify.json 給出了完整示例報文其中node.metadata攜帶LABELS.app與NAME正是拓撲分析的數(shù)據(jù)來源指標部分每條指標含name如cluster.service_stats.update_attempt、listener_manager.listener_added、typeCOUNTER/GAUGE以及帶時間戳timestampMs的采樣值見 metrics.json。關(guān)于 Envoy 各類統(tǒng)計項的完整清單可查閱 Envoy 官方文檔中 cluster manager cluster stats 一節(jié)這里不展開。值得強調(diào)的是COUNTER 類指標如update_attempt、upstream_cx_total反映累計值GAUGE 類指標如membership_healthy、server.live、server.memory_allocated反映瞬時值OAP 側(cè)會通過 Prometheus 格式的指標轉(zhuǎn)換鏈路見 MetricServiceGRPCHandler.java 中對PrometheusMetricConverter的引用把它們歸一化到統(tǒng)一的指標模型中。端到端實戰(zhàn)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該示例的工程結(jié)構(gòu)說明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接收器包的日志級別調(diào)為DEBUG從而能在 OAP 日志里直觀看到 Envoy 發(fā)來的每條消息——上述日志中的MetricServiceGRPCHandler ... DEBUG - Received msg即由此產(chǎn)生排查問題時也可照此開啟。延伸Service Mesh 數(shù)據(jù)面網(wǎng)絡(luò)監(jiān)控本指南聚焦指標上報但值得順帶一提的是SkyWalking 還支持對 Service Mesh 數(shù)據(jù)面進行網(wǎng)絡(luò)監(jiān)控Network Monitoring相關(guān)能力與原理詳見 數(shù)據(jù)面網(wǎng)絡(luò)監(jiān)控文檔。它與本文的 Envoy Metrics 接入互為補充前者側(cè)重網(wǎng)絡(luò)流量觀測后者側(cè)重服務(wù)指標與拓撲分析。小結(jié)與排查建議接入鏈路可歸納為三步Envoy 配置stats_sinks→ 定義指向 OAP 11800 端口的 gRPC cluster → 在 node 元數(shù)據(jù)中聲明服務(wù)/實例標識Istio 場景則由meshConfig.defaultConfig.envoyMetricsService.address一行完成全部配置配合proxyStatsMatcher精確控流。實際排障時可按以下順序核對連通性Envoy 所在節(jié)點能否訪問 OAP 的 11800 端口可用curl -v telnet://oap-ip:11800之類方式驗證 TCP 可達協(xié)議匹配確認 Envoy 使用的 Metrics Service 版本v2/v3與 OAP 版本8.3.0 雙版本均支持上報是否觸發(fā)按示例工程的方式把接收器日志調(diào)到 DEBUG觀察MetricServiceGRPCHandler是否打印Received msg元數(shù)據(jù)是否齊全檢查 node 元數(shù)據(jù)中LABELS.app與NAME是否配置否則拓撲分析會缺失服務(wù)/實例維度。贊分享可觀測性后端微服務(wù)云原生【免費下載鏈接】skywalkingAPM, Application Performance Monitoring System項目地址https://gitcode.com/gh_mirrors/sky/skywalking點擊查看免費下載相關(guān)推薦SkyWalking 接入 Envoy Metrics Service 指標獨立部署與 Istio 服務(wù)網(wǎng)格兩種配置方案詳解SkyWalking 接入 Envoy Metrics Service 指標獨立部署與 Istio 服務(wù)網(wǎng)格兩種配置方案詳解 本篇技術(shù)指南以 Apache S可觀測性APM鏈路追蹤指標監(jiān)控日志分析微服務(wù)終極指南Sentinel如何與Service Mesh完美集成Istio、Envoy實戰(zhàn)終極指南Sentinel如何與Service Mesh完美集成Istio、Envoy實戰(zhàn) Sentinel作為阿里巴巴開源的流量控制組件在微服務(wù)架構(gòu)中發(fā)后端微服務(wù)如何通過Service Mesh Interface實現(xiàn)Istio標準化部署與管理如何通過Service Mesh Interface實現(xiàn)Istio標準化部署與管理 Istio作為開源服務(wù)網(wǎng)格的領(lǐng)軍項目通過Service Mesh Inte服務(wù)網(wǎng)格云原生微服務(wù)網(wǎng)絡(luò)負載均衡可觀測性創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考