可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载导读本文基于 Apache SkyWalking 官方文档 Working with Istio 展开讲解如何将 Istio 服务网格的自监控指标控制面 istiod 指标通过 OpenTelemetry Collector 采集、转换并传输到 SkyWalking OAP 服务器最终在 SkyWalking UI 中以Dashboard - Istio控制面板呈现。读完本文你将掌握一条完整的可落地方案在 Kubernetes 中部署 OAP 并激活 OpenTelemetry receiver、配置 OpenTelemetry Collector 抓取 istiod 的 Prometheus 指标并通过 OTLP 协议上报、理解 OAP 侧otel-rules/istio-controlplane.yaml指标解析规则以及如何在 UI、CLI 与告警层面消费这些指标。方案总体架构与数据链路Istio 集成监控的核心思路不是让 SkyWalking 直接对接 Istio而是借助 OpenTelemetry Collector 作为中转与适配层。整体数据流如下Istio Control Plane (istiod, Prometheus 指标端点) │ prometheus receiver (kubernetes_sd_configs 发现并抓取) ▼ OpenTelemetry Collector │ otlp exporter (gRPC, 11800 端口) ▼ SkyWalking OAP Server (receiver-otel / otlp handler) │ otel-rules/istio-controlplane.yaml (MAL 规则) ▼ MeterSystem → 指标存储 → SkyWalking UI / swctl / 告警其中 Collector 承担「从 Istio 抓取指标」和「把指标推送给 OAP」两个职责OAP 侧由 OpenTelemetry receiverreceiver-otel模块接收 OTLP 数据再依据 MALMeter Analysis Language见 mal.md规则把 Prometheus 风格的原始指标换算为 SkyWalking 的度量模型。需要说明的是本方案观察的是Istio 控制面Control Plane自身的健康与行为如果需要观察 Istio 托管业务服务Service Mesh 数据面的服务拓扑与调用关系应使用 ALS 方案详见本文末尾。前置条件在开始之前需要确认以下环境就绪Kubernetes 集群Istio 应已安装到集群中。可参照 Istio 官方提供的 Getting Started 指引完成安装本文不展开 Istio 安装细节。SkyWalking OAP 后端部署于同一 Kubernetes 集群内且已激活 OpenTelemetry receiver下文详述。OpenTelemetry Collector作为指标采集与转发组件独立部署。部署 SkyWalking 后端并激活 OpenTelemetry ReceiverOAP 服务器可按 backend-k8s.md 中的步骤部署到 Kubernetes 集群。关键在于激活并正确配置 OpenTelemetry receiver使其能够接收 Collector 推送的指标。激活 receiver-otel 模块OpenTelemetry receiver 在 OAP 中以receiver-otel模块存在需要显式开启。可通过系统环境变量SW_OTEL_RECEIVERdefault激活或在 OAP 的application.yml中配置receiver-otel: selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:otlp-metrics} enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:istio-controlplane}参数说明配置项环境变量作用selectorSW_OTEL_RECEIVER选择 receiver 实现默认值为default对应源码中的OtelMetricReceiverProvider见 OtelMetricReceiverProvider.javaenabledHandlersSW_OTEL_RECEIVER_ENABLED_HANDLERS启用哪些 OTLP handler。otlp-metrics为指标 handler从源码可见还支持otlp-logs、otlp-traces等handler 按类型逐个注册enabledOtelMetricsRulesSW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES启用哪些 OTLP 指标解析规则多个规则以英文逗号分隔。istio-controlplane即对应otel-rules/istio-controlplane.yamlenabledHandlers与enabledOtelMetricsRules在源码中均按逗号拆分解析见 OtelMetricReceiverConfig.java 的getEnabledHandlers()与 OpenTelemetryMetricRequestProcessor.java 中Rules.loadRules(otel-rules, enabledRules)的加载逻辑因此可以一次启用多条规则。注意OAP 在启动时加载otel-rules目录下的规则文件位于$CLASSPATH/otel-rules。如果规则文件格式不合法OAP 可能启动失败修改规则后需谨慎验证。receiver-otel 支持的数据来源OpenTelemetry receiver 本身是通用的指标接收端其内置规则覆盖了多种数据源。与 Istio 相关的规则如下描述规则文件数据链路Istio 控制面指标otel-rules/istio-controlplane.yamlIstio Control Plane → OpenTelemetry Collector(OTLP exporter) → SkyWalking OAP Server其它预置规则OAP 自身、Linux/Windows OS、K8s、MySQL、PostgreSQL、Redis、Kafka、ClickHouse、RocketMQ 等可参见 opentelemetry-receiver.md说明该 receiver 是 Istio 之外多种监控场景的公共入口。部署并配置 OpenTelemetry CollectorOpenTelemetry Collector 是 Istio 遥测数据的目的地Istio 把指标暴露出来Collector 负责抓取、处理并转发给 SkyWalking 后端。可参照 OpenTelemetry Collector 官方 Getting Started 完成安装。Collector 内置了丰富的组件可按需组合。抓取 Istio 指标并转发到 OAP 的完整配置安装完成后把 Collector 配置为「从 Istio 抓取指标、发送给 SkyWalking 后端」一个可直接使用的 job 配置如下receivers: prometheus: config: scrape_configs: - job_name: istiod-monitor kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [ __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name ] action: keep regex: istiod;http-monitoring - action: labelmap regex: __meta_kubernetes_service_label_(.) - source_labels: [ ] target_label: cluster replacement: your-cluster # replace this with your cluster name exporters: otlp: endpoint: oap.skywalking:11800 # replace this with the OAP gRPC service address tls: insecure: true service: pipelines: metrics: receivers: [ prometheus ] exporters: [ otlp,logging ]配置要点逐项说明receivers.prometheus.config.scrape_configs定义抓取任务istiod-monitor。kubernetes_sd_configs使用endpoints角色自动发现集群内的端点。relabel_configs第一段仅保留service_nameistiod且端口名为http-monitoring的端点即精准定位 istiod 的控制面监控端点。relabel_configs第二段labelmap把 Kubernetes Service 标签__meta_kubernetes_service_label_*映射为指标标签便于后续按app、cluster等维度聚合。relabel_configs第三段为所有指标打上cluster标签值为your-cluster务必替换为实际集群名——OAP 侧规则正是按cluster维度进行服务聚合的见下文规则解析。exporters.otlp通过 OTLP gRPC 协议把指标推送到 OAPendpoint为 OAP 的 gRPC 服务地址示例为oap.skywalking:11800需替换为真实地址tls.insecure: true表示关闭 TLS。service.pipelines.metrics把prometheusreceiver 与otlp、logging两个 exporter 串联成一条指标流水线logging用于本地输出调试。Collector 到 OAP 的传输格式适配从源码看OAP 的OpenTelemetryMetricRequestProcessor负责把 OTLP 指标转换为 SkyWalking 的 Prometheus 中间模型其转换逻辑支持 OTLP 中的 Gauge、Sum区分 Delta/Cumulative、单调/非单调、Histogram、ExponentialHistogram 与 Summary 五种数据类型见 OpenTelemetryMetricRequestProcessor.java 的adaptMetrics方法。此外处理器对资源属性Resource Attributes做了标签映射LABEL_MAPPINGS这对理解最终指标维度很重要OTLP 资源属性映射后的 SkyWalking 标签net.host.name部分 OTLP 版本为host.namenode_identifier_host_namejob或service.namejob_name细节提醒在资源作用域resource scope中属性名里的点号.会被转换为下划线_而在指标作用域metrics scope中不做转换。采集时需要注意这一差异对标签名的影响。OAP 侧指标解析规则istio-controlplane.yaml 深度解析当 OAP 收到 OTLP 指标后会按照enabledOtelMetricsRules指定的规则文件进行二次加工。Istio 控制面指标规则位于 otel-rules/istio-controlplane.yaml其核心结构如下省略 License 头expSuffix: tag({tags - tags.cluster istio-ctrl:: tags.cluster}).service([cluster, app], Layer.MESH_CP) metricPrefix: meter_istio metricsRules: # 版本信息 - name: pilot_version exp: istio_build.tagEqual(component, pilot).sum([cluster, app, tag]) # 内存 - name: virtual_memory exp: process_virtual_memory_bytes.tagEqual(app, istiod).sum([cluster, app]) - name: resident_memory exp: process_resident_memory_bytes.tagEqual(app, istiod).sum([cluster, app]) - name: go_alloc exp: go_memstats_alloc_bytes.tagEqual(app, istiod).sum([cluster, app]) # CPU - name: cpu exp: (process_cpu_seconds_total * 100).tagEqual(app, istiod).sum([cluster, app]).rate(PT1M) # Goroutines - name: go_goroutines exp: go_goroutines.tagEqual(app, istiod).sum([cluster, app]) # Pilot 推送 - name: pilot_xds_pushes exp: pilot_xds_pushes.tagMatch(type, lds|cds|rds|eds).sum([cluster, app, type]).irate() # 配置冲突 - name: pilot_conflict_il exp: pilot_conflict_inbound_listener.tagEqual(app, istiod).sum([cluster, app]) # Webhook / 校验 - name: galley_validation_passed exp: galley_validation_passed.tagEqual(app, istiod).sum([cluster, app]).rate(PT1M) - name: sidecar_injection_success_total exp: sidecar_injection_success_total.tagEqual(app, istiod).sum([cluster, app]).rate(PT1M)规则语义expSuffix对全部规则统一施加「尾部表达式」。tag(...)先把cluster标签改写为istio-ctrl::cluster前缀形式使 Istio 控制面与数据面/业务服务在命名空间上区分随后.service([cluster, app], Layer.MESH_CP)以cluster与app作为服务标识维度将指标归属到MESH_CP服务网格控制面层。metricPrefix: meter_istio所有加工后指标名统一加meter_istio前缀例如pilot_xds_pushes最终成为meter_istio_pilot_xds_pushes。metricsRules逐条定义「原始指标名 → 目标指标」的换算表达式。完整规则还覆盖了 Pilot 各类 xDS 拒绝计数pilot_xds_cds_reject/eds/rds/lds、推送超时与内部错误、pilot_proxy_convergence_time的分位数P50/P90/P99、以及 galley 配置校验、sidecar 注入成功/失败等控制面关键行为指标。感兴趣的读者可直接阅读 istio-controlplane.yaml 全文。从表达式可以看出Istio 控制面监控的核心是istiodPilot进程它的内存虚拟内存、常驻内存、Go 堆、CPU 使用率、Goroutine 数量、xDS 推送行为、配置冲突、校验与注入成功率。这些指标经过换算后进入 MeterSystem成为 UI 面板的数据来源。在 SkyWalking UI 中观察 IstioDashboard - Istio 面板打开 SkyWalking UI依次点击Dashboard-Istio即可查看由 Istio 指标生成的图表。该菜单背后的模板与层级在仓库中均有对应物UI 菜单定义Service Mesh - Control Plane的 layer 为MESH_CP其 documentLink 即指向本文档见 menu.yaml 中Service Mesh菜单段控制面模板文件mesh-control-plane-root.json与mesh-control-plane-service.json位于 ui-initialized-templates/mesh_cp/ 目录OAP 启动时会将其初始化到 UI 模板库中。因此只要指标成功入库且服务被归属到MESH_CP层面板就会自动出现 istiod 相关图表。通过 swctl 与告警消费指标除 UI 外还可以使用 SkyWalking 命令行工具swctl查询这些指标便于脚本化巡检与二次开发基于这些指标配置告警规则例如 xDS 拒绝数突增、sidecar 注入失败率上升、Pilot 推送耗时 P99 超阈值等。SkyWalking 的告警规则定义与示例可参考 backend-alarm.md 及 alarm-settings.yml。扩展观察 Istio 托管服务的拓扑与调用关系本文方案聚焦控制面自身。若想观察 Istio 托管业务服务含服务拓扑官方推荐使用ALSEnvoy Access Log Service方案Istio 的 Envoy sidecar 将访问日志通过 gRPC 推送给 OAP 的 envoy-metric receiverOAP 侧通过k8s-mesh基于 Kubernetes 元数据或mx-mesh基于 Envoy metadata exchange等分析器还原服务调用关系详见 als_setting.md。两条链路互为补充控制面指标看 istiod 健康度ALS 看数据面服务拓扑。小结与常见问题排查本文完整走通了「Istio 控制面 → OpenTelemetry Collector → SkyWalking OAP」的指标传输链路。落地时重点检查以下三点receiver 是否激活确认 OAP 的receiver-otel/selector为default且enabledOtelMetricsRules包含istio-controlplane否则 Collector 推来的数据会被丢弃。Collector 端点与标签是否正确exporters.otlp.endpoint必须指向 OAP gRPC 地址默认 11800cluster标签务必替换为真实集群名它直接决定 OAP 侧的服务维度聚合。规则文件是否合法otel-rules下的 YAML 在 OAP 启动时加载格式错误可能导致 OAP 启动失败源码中Rules.loadRules抛出的IOException会包装为ModuleStartException。观测视角区分控制面指标走本文链路服务拓扑与业务调用观测请使用 ALS 方案。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐SkyWalking 监控 Apache APISIX基于 OpenTelemetry Collector 与 MAL 规则的指标采集指南SkyWalking 监控 Apache APISIX基于 OpenTelemetry Collector 与 MAL 规则的指标采集指南 导读 本指南讲解如可观测性APM链路追踪指标监控日志分析微服务SkyWalking 监控 Apache APISIX 网关基于 OpenTelemetry Collector 与 Prometheus 插件指标接入实战SkyWalking 监控 Apache APISIX 网关基于 OpenTelemetry Collector 与 Prometheus 插件指标接入实战可观测性后端微服务云原生Moby 项目中的 go-events 事件分发库实战指南用可组合 Sink 管道实现事件队列、重试与广播Moby 项目中的 go events 事件分发库实战指南用可组合 Sink 管道实现事件队列、重试与广播 go events 是 Docker 团队在 Mo可观测性APM链路追踪指标监控日志分析微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考