SkyWalking Kubernetes 监控全指南KSM/cAdvisor、Rover 与 Cilium Fetcher 三条观测路径详解【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalkingKubernetes 已成为云原生应用的基础设施SkyWalking 作为 APM 系统提供了三条互补的 Kubernetes 监控路径基于 kube-state-metricsKSM与 cAdvisor 的资源指标监控、基于 SkyWalking Rover eBPF Agent 的网络访问日志观测以及基于 Cilium Hubble API 的流量拓扑分析。本文以 SkyWalking 仓库中的 backend-k8s-monitoring.md 为主干逐条梳理三条路径的数据流、部署接入步骤、完整指标清单与自定义扩展方式并结合 OAP 服务端真实的 MAL/OAL 规则文件讲解底层实现帮助读者在自建 Kubernetes 集群上快速落地一套覆盖资源、网络、协议三个维度的可观测方案。为什么 SkyWalking 需要三种 K8s 监控路径Kubernetes 是一个开源容器编排系统用于自动化应用部署、扩缩容与管理由 Google 最初设计现由云原生计算基金会CNCF维护目标是跨主机集群自动化部署、扩缩容和运维应用容器可配合 Docker 等容器工具使用。如今 Kubernetes 是云原生应用的基础设施SkyWalking 提供了以下三种方式监控 Kubernetes 上的部署方式数据来源覆盖维度详细指南kube-state-metrics cAdvisorKSM 与 kubelet 内置 cAdvisor集群/节点/服务的资源指标CPU、内存、存储、状态backend-k8s-monitoring-metrics-cadvisor.mdRoverSkyWalking 原生 eBPF Agent网络访问日志、拓扑感知、指标分析并可对 C/Rust/Golang 等语言运行的服务做 profilingbackend-k8s-monitoring-rover.mdCilium FetcherCilium Hubble Observe API服务间网络流量数据、拓扑图、L4/L7 层指标backend-k8s-monitoring-cilium.mdSkyWalking 与 Kubernetes 深度集成帮助用户理解应用在 Kubernetes 上的运行状态。需要说明的是文档中提到Cilium with Hubble 在 v10 计划中从当前仓库结构看cilium-fetcher-plugin 已作为独立的 fetcher 插件存在可结合 cilium-fetcher-plugin 源码目录 与 fetcher-proto 中的 proto 定义进一步了解实现。路径一基于 kube-state-metrics 与 cAdvisor 的资源指标监控SkyWalking 借助 K8s 的 kube-state-metricsKSM与 cAdvisor 采集 Kubernetes 的指标数据再通过 OpenTelemetry Collector 将指标转发给 OpenTelemetry receiver最终汇入 Meter SystemMAL。该功能要求授权 OAP Server 访问 K8s 的 API Server以便 OAP 获取元数据信息。数据流K8s kube-state-metrics 与 cAdvisor 从 K8s 采集指标数据OpenTelemetry Collector 通过 Prometheus Receiver 从 kube-state-metrics 与 cAdvisor 拉取指标再通过 OpenTelemetry gRPC exporter 推送给 SkyWalking OAP ServerSkyWalking OAP Server 访问 K8s API Server 获取元数据信息并使用 MAL 表达式对指标进行过滤、计算、聚合后入库。这一数据流与仓库中的配置一一对应在 otel-rules/k8s/k8s-cluster.yaml 中可以看到入口过滤条件filter: { tags - tags.job_name in [ kubernetes-cadvisor, kube-state-metrics ] }即只接收 job_name 为kubernetes-cadvisor与kube-state-metrics的指标这正是 OpenTelemetry Collector 中 Prometheus Receiver 两个抓取任务的 job 名称约定。部署与接入步骤部署 kube-state-metrics参考其官方 Kubernetes Deployment 方式cAdvisor 默认已集成在 kubelet 中无需单独部署在 Kubernetes 中部署 OpenTelemetry Collector并配置 Prometheus Receiver 抓取上述两类指标抓取目标参考 Prometheus 官方提供的 prometheus-kubernetes 抓取配置示例仓库所在的 SkyWalking 生态提供了完整的快速开始示例与推荐版本可在 skywalking-showcase 项目的deploy/platform/kubernetes/templates/feature-kubernetes-monitor中找到本仓库不包含该工程配置 SkyWalking 的 OpenTelemetry receiver 以接收上报的指标。集群监控Kubernetes Cluster MonitoringK8s 集群监控提供整个集群及各节点的状态与资源监控。映射关系为K8s 集群作为 OAP 中的 ServiceK8s 节点作为 OAP 中的 Instance归属Layer: K8S。在 k8s-cluster.yaml 中expSuffix: tag({tags - tags.cluster k8s-cluster:: tags.cluster}).service([cluster], Layer.K8S)正体现了这一映射。集群级支持的指标数据源均为 K8s kube-state-metrics监控面板单位指标名说明Node Totalk8s_cluster_node_total节点数量Namespace Totalk8s_cluster_namespace_total命名空间数量Deployment Totalk8s_cluster_deployment_totalDeployment 数量StatefulSet Totalk8s_cluster_statefulset_totalStatefulSet 数量DaemonSet Totalk8s_cluster_daemonset_totalDaemonSet 数量Service Totalk8s_cluster_service_totalService 数量Pod Totalk8s_cluster_pod_totalPod 数量Container Totalk8s_cluster_container_total容器数量CPU Resourcesmk8s_cluster_cpu_cores / k8s_cluster_cpu_cores_requests / k8s_cluster_cpu_cores_limits / k8s_cluster_cpu_cores_allocatableCPU 容量与 Requests / Limits / AllocatableMemory ResourcesGik8s_cluster_memory_total / k8s_cluster_memory_requests / k8s_cluster_memory_limits / k8s_cluster_memory_allocatable内存容量与 Requests / Limits / AllocatableStorage ResourcesGik8s_cluster_storage_total / k8s_cluster_storage_allocatable存储容量与 AllocatableNode Statusk8s_cluster_node_status节点当前状态Deployment Statusk8s_cluster_deployment_statusDeployment 当前状态Deployment Spec Replicask8s_cluster_deployment_spec_replicasDeployment 期望副本数Service Statusk8s_cluster_service_pod_statusService 当前状态取决于关联 Pod 的状态Pod Status Not Runningk8s_cluster_pod_status_not_running当前不在 Running 阶段的 PodPod Status Waitingk8s_cluster_pod_status_waiting处于 Waiting 状态的 Pod 与容器展示原因Pod Status Terminatedk8s_cluster_container_status_terminated处于 Terminated 状态的 Pod 与容器展示原因这些指标在 k8s-cluster.yaml 中均有对应的 MAL 表达式定义。例如metricsRules: - name: cpu_cores exp: (kube_node_status_capacity * 1000).tagEqual(resource , cpu).sum([cluster]) - name: node_status exp: kube_node_status_condition.valueEqual(1).tagMatch(status , true|unknown).sum([cluster , node ,condition]) - name: service_pod_status exp: kube_pod_status_phase.retagByK8sMeta(service , K8sRetagType.Pod2Service , pod , namespace).tagNotEqual(service , ).valueEqual(1).sum([cluster , service , phase])可以看到 CPU 核心数被乘以 1000 转换为毫核m单位retagByK8sMeta是 MAL 中面向 K8s 的特殊函数它借助 OAP 从 API Server 获取的元数据将 Pod 维度标签重写为 Service 维度标签K8sRetagType.Pod2Service这正是 OAP 需要访问 K8s API Server 的原因。节点级支持的指标CPU/内存/存储资源类来自 KSM用量类来自 cAdvisor监控面板单位指标名说明数据源Pod Totalk8s_node_pod_total该节点上的 Pod 数量K8s kube-state-metricsNode Statusk8s_node_node_status该节点当前状态K8s kube-state-metricsCPU Resourcesmk8s_node_cpu_cores / k8s_node_cpu_cores_allocatable / k8s_node_cpu_cores_requests / k8s_node_cpu_cores_limitsCPU 容量与 Requests / Limits / AllocatableK8s kube-state-metricsMemory ResourcesGik8s_node_memory_total / k8s_node_memory_allocatable / k8s_node_memory_requests / k8s_node_memory_limits内存容量与 Requests / Limits / AllocatableK8s kube-state-metricsStorage ResourcesGik8s_node_storage_total / k8s_node_storage_allocatable存储容量与 AllocatableK8s kube-state-metricsCPU Usagemk8s_node_cpu_usageCPU 核心总用量若有 2 核则最大用量为 2000mcAdvisorMemory UsageGik8s_node_memory_usage内存总用量cAdvisorNetwork I/OKB/sk8s_node_network_receive / k8s_node_network_transmit网络接收与发送cAdvisor对应实现在 k8s-node.yaml 中其expSuffix为instance([cluster] , [node], Layer.K8S)即节点映射为 OAP Instance。其中 CPU 用量表达式(container_cpu_usage_seconds_total * 1000).tagEqual(id , /).sum([cluster , node]).irate()通过id /精确锁定根容器cgroup 根代表整机视角来聚合节点整体用量网络收发则对container_network_receive_bytes_total/container_network_transmit_bytes_total做irate()求瞬时速率。服务监控Kubernetes Service MonitoringK8s Service 监控提供对 Service 状态与资源的可观测性。映射关系为K8s Service 作为 OAP 中的 Service归属Layer: K8S_SERVICE对应 k8s-service.yaml 中的expSuffix: service([cluster , service], ::, Layer.K8S_SERVICE)。Service 级支持的指标监控面板单位指标名说明数据源Service Pod Totalk8s_service_pod_totalPod 数量K8s kube-state-metricsService Pod Statusk8s_service_pod_statusPod 当前状态K8s kube-state-metricsService CPU Resourcesmk8s_service_cpu_cores_requests / k8s_service_cpu_cores_limits该 Service 的 CPU Requests / LimitsK8s kube-state-metricsService Memory ResourcesMBk8s_service_memory_requests / k8s_service_memory_limits该 Service 的内存 Requests / LimitsK8s kube-state-metricsPod CPU Usagemk8s_service_pod_cpu_usagePod CPU 总用量cAdvisorPod Memory UsageMBk8s_service_pod_memory_usagePod 内存总用量cAdvisorPod Waitingk8s_service_pod_status_waiting处于 Waiting 状态的 Pod 与容器展示原因K8s kube-state-metricsPod Terminatedk8s_service_pod_status_terminated处于 Terminated 状态的 Pod 与容器展示原因K8s kube-state-metricsPod Restartsk8s_service_pod_status_restarts_total与 Pod 相关的每个容器的重启次数K8s kube-state-metricsService 级指标同样大量依赖retagByK8sMeta(service , K8sRetagType.Pod2Service , pod , namespace)完成 Pod → Service 的维度转换例如 CPU 用量表达式- name: pod_cpu_usage exp: (container_cpu_usage_seconds_total * 1000).tagNotEqual(container , ).tagNotEqual(pod , ).retagByK8sMeta(service , K8sRetagType.Pod2Service , pod , namespace).tagNotEqual(service , ).sum([cluster , service , pod]).irate()另外仓库中还存在一份 k8s-instance.yaml可一并阅读以了解实例维度的规则结构。自定义监控Customizations该路径支持自定义指标、表达式与仪表盘面板指标定义与表达式规则位于/config/otel-rules/k8s/k8s-cluster.yaml、/config/otel-rules/k8s/k8s-node.yaml、/config/otel-rules/k8s/k8s-service.yaml即仓库中的 otel-rules/k8s/ 目录可直接修改或新增规则后重启 OAP 生效K8s Cluster 与 K8s Service 的仪表盘面板配置随 SkyWalking Horizon UI 包apache/skywalking-horizon-ui一同发布OAP 后端不再托管 UI 仪表盘 JSON。路径二基于 SkyWalking RovereBPF的网络访问日志观测SkyWalking Rover 是 SkyWalking 原生的 eBPF Agent用于从 Kubernetes 集群采集访问日志并交给 OAL 系统 进行指标与实体分析。得益于 eBPF 的能力Rover 还能对 C、Rust、Golang 等语言编写的运行中服务进行 profiling。数据流SkyWalking Rover 监控 K8s 集群中的访问日志数据并发送给 OAPSkyWalking OAP Server 通过 gRPC 接收来自 Rover 的访问日志分析生成实体并使用 OAL 生成指标。部署与配置在 Kubernetes 中部署 Rover并启用其 access log service流量采集配置通过以下配置启用 OAP 的 eBPF receiver 模块receiver-ebpf: selector: ${SW_RECEIVER_EBPF:default} default:其中selector默认值由环境变量SW_RECEIVER_EBPF控制默认default保持默认即可启用。生成的实体Generated EntitiesSkyWalking 接收来自 Rover 的访问日志后分析 Kubernetes 连接信息解析出以下对应实体Service服务Service Instance服务实例Service Endpoint服务端点Service Relation服务间关系Service Instance Relation服务实例间关系Service Endpoint Relation服务端点间关系生成的指标Generate Metrics对上述每个实体均可分析出连接connection、传输transfer、协议protocol三类指标。连接指标Connection Metrics记录每个服务与其他服务建立/关闭连接的指标。名称单位说明Connect CPMCount每分钟连接其他服务的总次数Connect DurationNanoseconds连接其他服务使用的总时长Connect Success CPMCount每分钟成功连接其他服务的次数Accept CPMCount每分钟接受来自其他服务新连接的次数Accept DurationNanoseconds接受来自其他服务的新连接使用的总时长Close CPMCount每分钟关闭连接的次数Close DurationNanoseconds关闭连接使用的总时长传输指标Transfer Metrics记录每个服务向其他服务发起网络请求时每次 syscall 的基本信息与 L2-L4 层细节。读连接数据Read Data from Connection名称单位说明Read CPMCount每分钟从连接读取的次数Read DurationNanoseconds读取数据使用的总时长Read Package CPMCount每分钟读取 TCP 包的次数Read Package SizeBytes每分钟读取的 TCP 包总大小Read Layer 4 DurationNanoseconds第 4 层读取数据使用的总时长Read Layer 3 DurationNanoseconds第 3 层读取数据使用的总时长Read Layer 3 Recv DurationNanoseconds第 3 层接收数据使用的总时长Read Layer 3 Local DurationNanoseconds第 3 层本地读取数据使用的总时长Read Package To Queue DurationNanosecondsTCP 包接收到送入队列之间的总时长Read Package From Queue DurationNanoseconds送入队列到从队列取出的总时长Read Net Filter CPMCount读取数据时 Net Filter 处理的总次数Read Net Filter DurationNanosecondsNet Filter 处理使用的总时长写连接数据Write Data to Connection名称单位说明Write CPMCount每分钟写入连接的次数Write DurationNanoseconds向连接写入数据使用的总时长Write Package CPMCount每分钟写入 TCP 包的次数Write Package SizeBytes每分钟写入的 TCP 包总大小Write L4 DurationNanoseconds第 4 层写入连接数据使用的总时长Write L3 DurationNanoseconds第 3 层写入数据使用的总时长Write L3 Local DurationNanoseconds第 3 层本地写入数据使用的总时长Write L3 Output DurationNanoseconds第 3 层输出数据使用的总时长Write L2 DurationNanoseconds第 2 层写入连接数据使用的总时长Write L2 Ready Send DurationNanoseconds第 2 层数据进入待发送队列使用的总时长Write L2 Send NetDevice DurationNanoseconds第 2 层数据发送到网卡设备使用的总时长协议指标Protocol基于每次传输数据分析提取 7 层网络协议信息。HTTP/1.x 或 HTTP/2.x名称单位说明Call CPMCount每分钟 HTTP 请求调用次数DurationMillisecondsHTTP 响应总时长Success CPMCount每分钟 HTTP 成功响应status 500次数Request Header SizeBytes请求 Header 总大小Request Body SizeBytes请求 Body 总大小Response Header SizeBytes响应 Header 总大小Response Body SizeBytes响应 Body 总大小上述指标与 oal/ebpf.oal 中的 OAL 定义一一对应例如连接类指标kubernetes_service_connect_cpm from(K8SService.*).filter(type connect).cpm(); kubernetes_service_connect_time from(K8SService.connect.duration).filter(type connect).longAvg(); kubernetes_service_connect_success_cpm from(K8SService.*).filter(type connect).filter(connect.success true).cpm(); kubernetes_service_read_cpm from(K8SService.*).filter(type read).cpm(); kubernetes_service_write_l2_net_device_avg_send_duration from(K8SService.write.l2.networkDeviceSendDuration).filter(type write).longAvg(); kubernetes_service_http_call_cpm from(K8SService.*).filter(detectPoint DetectPoint.SERVER).filter(type protocol).filter(protocol.type http).cpm().decorator(K8SServiceDecorator);从 OAL 结构可以看到Rover 上报的数据以typeconnect/accept/close/read/write/protocol区分事件类别connect.duration、read.l2.packageCount、write.l3.netFilterCount等字段则体现了 eBPF 在连接建立、协议栈各层处理环节的精细化埋点能力。自定义监控Customizations该路径同样支持自定义指标与仪表盘面板指标定义与表达式规则位于/config/oal/ebpf.oal即 oal/ebpf.oal其中使用的K8SService等 Scope 的字段定义可参考 Scope 声明文档Scopes with K8s prefixK8s 仪表盘面板配置随 SkyWalking Horizon UI 包apache/skywalking-horizon-ui一同发布OAP 后端不再托管 UI 仪表盘 JSON。路径三基于 Cilium FetcherHubble的流量观测如果集群中安装了 CiliumSkyWalking 通过 Cilium Fetcher 借助 Cilium Hubble 的 Observe API 采集服务间流量数据。这些数据可用于创建拓扑图并提供 L4 与 L7 层指标随后交由 OAL 系统 进行指标与实体分析。数据流SkyWalking 通过 gRPC API 获取 Cilium Node 与观测数据分析生成实体并使用 OAL 生成指标。API 依赖Cilium Fetcher 依赖 Cilium Hubble 提供以下两个 APIPeers API监听集群中的 hubble 节点OAP 会与 Hubble 节点通信以获取 Observe 数据Observe API从 Hubble 节点获取 Flow 数据。部署与配置参照 Hubble 官方部署文档完成 Hubble 的安装使其提供上述 API激活 Cilium receiver 模块在 YAML 中设置selectordefault或通过系统环境变量设置SW_CILIUM_FETCHERdefaultcilium-fetcher: selector: ${SW_CILIUM_FETCHER:default} default: # Host name and port of Hubble peer component peerHost: ${SW_CILIUM_FETCHER_PEER_HOST:hubble-peer.kube-system.svc.cluster.local} peerPort: ${SW_CILIUM_FETCHER_PEER_PORT:80} fetchFailureRetrySecond: ${SW_CILIUM_FETCHER_FETCH_FAILURE_RETRY_SECOND:10} sslConnection: ${SW_CILIUM_FETCHER_SSL_CONNECTION:false} sslPrivateKeyFile: ${SW_CILIUM_FETCHER_PRIVATE_KEY_FILE_PATH:} sslCertChainFile: ${SW_CILIUM_FETCHER_CERT_CHAIN_FILE_PATH:} sslCaFile: ${SW_CILIUM_FETCHER_CA_FILE_PATH:} convertClientAsServerTraffic: ${SW_CILIUM_FETCHER_CONVERT_CLIENT_AS_SERVER_TRAFFIC:true}各配置项说明如下配置项环境变量默认值说明peerHostSW_CILIUM_FETCHER_PEER_HOSThubble-peer.kube-system.svc.cluster.localHubble peer 组件的主机名peerPortSW_CILIUM_FETCHER_PEER_PORT80Hubble peer 组件端口fetchFailureRetrySecondSW_CILIUM_FETCHER_FETCH_FAILURE_RETRY_SECOND10拉取失败后的重试间隔秒sslConnectionSW_CILIUM_FETCHER_SSL_CONNECTIONfalse是否启用 SSL 连接sslPrivateKeyFileSW_CILIUM_FETCHER_PRIVATE_KEY_FILE_PATH空私钥文件路径sslCertChainFileSW_CILIUM_FETCHER_CERT_CHAIN_FILE_PATH空证书链文件路径sslCaFileSW_CILIUM_FETCHER_CA_FILE_PATH空CA 文件路径convertClientAsServerTrafficSW_CILIUM_FETCHER_CONVERT_CLIENT_AS_SERVER_TRAFFICtrue是否将客户端流量转换为服务端视角若启用了 Hubble 的 TLS 证书需更新以下配置peerPort通常应更新为443sslConnection设置为truesslPrivateKeyFile私钥文件路径sslCertChainFile证书链文件路径sslCaFileCA 文件路径。配置 cilium 规则cilium-rules/exclude.yaml配置应从监控中排除的 endpoint详见下文排除规则cilium-rules/metadata-service-mapping.yaml配置服务名称与 endpoint 的映射。排除规则Exclude RulesCilium 规则中的 exclude 配置用于指定哪些 Cilium Endpoint 不会被加入拓扑图也不会生成指标与其他数据。namespaces: # 定义来自哪些命名空间的流量应被排除 - kube-system labels: # 定义匹配哪些 endpoint 标签的流量应被排除只要匹配任一标签即被排除 - k8s:io.cilium.k8s.namespace.labels.istio-injection: enabled # 每个标签是一个键值对key 为标签键value 为标签值 k8s:security.istio.io/tlsMode: istio默认情况下来自kube-system命名空间以及由 istio mesh 管控的流量都会被排除。仓库中的 cilium-rules/exclude.yaml 即为上述默认配置的实际落地文件。注意只有源端和目的端同时匹配排除规则的 endpoint 才会被排除否则流量仍会计入。另外cilium-rules/metadata-service-mapping.yaml 定义了服务名与实例名的生成规则serviceName: ${LABELS.service.istio.io/canonical-name,LABELS.app.kubernetes.io/name,LABELS.component,LABELS.app,LABELS.k8s-app,SERVICE}.${NAMESPACE} serviceInstanceName: ${NAME}即服务名按service.istio.io/canonical-name→app.kubernetes.io/name→component→app→k8s-app→ 原生 SERVICE 名的优先级依次取第一个存在的标签值并拼上命名空间后缀实例名取NAME。生成的实体Generated EntitiesSkyWalking 从 Cilium 获取 Flow 数据分析源端与目的端 endpoint解析出以下实体Service服务Service Instance服务实例Service Endpoint服务端点Service Relation服务间关系Service Instance Relation服务实例间关系Service Endpoint Relation服务端点间关系生成的指标Generate Metrics对上述每个实体可分析出 L4 与 L7 协议指标。L4 指标记录每个服务与其他服务读写数据包的指标。名称单位说明Read Package CPMCount每分钟从其他服务读取包的总次数Write Package CPMCount每分钟向其他服务写入包的总次数Drop Package CPMCount每分钟丢弃来自其他服务包的总次数Drop Package Reason CountLabeled Count每分钟丢弃包的原因带标签计数对应实现可在 oal/cilium.oal 中看到例如cilium_service_l4_read_pkg_cpm from(CiliumService.*).filter(verdict forwarded).filter(type tcp).filter(direction ingress).cpm(); cilium_service_l4_write_pkg_drop_cpm from(CiliumService.*).filter(verdict dropped).filter(type tcp).filter(direction egress).cpm(); cilium_service_l4_drop_reason_count from(CiliumService.*).filter(verdict dropped).filter(type tcp).labelCount(dropReason);可见 L4 指标通过verdictforwarded/dropped、typetcp与directioningress/egress过滤 Flow 数据得出丢包原因通过labelCount(dropReason)按标签统计。协议指标Protocol基于每次传输数据分析提取 7 层网络协议信息。注意默认情况下 Cilium 只上报 L4 指标。如果需要 L7 指标必须在每个服务的 CiliumNetworkPolicy 中显式声明详见 Cilium 官方安全策略文档。HTTP名称单位说明CPMCount每分钟 HTTP 请求调用次数DurationNanosecondsHTTP 响应总时长Success CPMCount每分钟 HTTP 成功响应status 500次数Status 1/2/3/4/5xxCountHTTP 响应状态码按 1xx/2xx/3xx/4xx/5xx 分组统计DNS名称单位说明CPMCount每分钟 DNS 请求调用次数DurationNanosecondsDNS 响应总时长Success CPMCount每分钟 DNS 成功响应code 0次数Error CountLabel Count带错误描述标签的 DNS 错误响应计数Kafka名称单位说明CPMCount每分钟 Kafka 请求调用次数DurationNanosecondsKafka 响应总时长Success CPMCount每分钟 Kafka 成功响应errorCode 0次数Error CountLabel Count带错误描述标签的 Kafka 错误响应计数在 oal/cilium.oal 中协议指标覆盖了 Service、ServiceInstance、Endpoint、ServiceRelation、ServiceInstanceRelation 五类实体的 HTTP / DNS / Kafka 定义例如cilium_service_protocol_http_call_cpm from(CiliumService.*).filter(verdict forwarded).filter(type http).filter(detectPoint DetectPoint.SERVER).cpm(); cilium_service_protocol_http_status_5xx_cpm from(CiliumService.*).filter(verdict forwarded).filter(type http).filter(detectPoint DetectPoint.SERVER).filter(http.code 500).filter(http.code 600).cpm(); cilium_service_protocol_dns_error_count from(CiliumService.*).filter(verdict forwarded).filter(type dns).filter(detectPoint DetectPoint.SERVER).filter(success false).labelCount(dns.rcodeString); cilium_service_protocol_kafka_call_success_count from(CiliumService.*).filter(verdict forwarded).filter(type kafka).filter(detectPoint DetectPoint.SERVER).filter(success true).cpm();Cilium Fetcher 与 OAP 集群的负载均衡Cilium Fetcher 模块依赖 Cluster 模块当 Cilium Fetcher 模块启动时会通过每个 OAP 节点上的 Peers API 获取 OAP 集群中所有 Cilium 节点与节点信息。在此基础上它会把采集到的 Cilium 节点平均分配到每个 OAP 节点上并保证单个 Cilium 节点不会被多个 OAP 节点重复监控从而在 OAP 集群部署时实现采集任务的负载均衡与去重。自定义监控Customizations该路径同样支持自定义指标与仪表盘面板指标定义与表达式规则位于/config/oal/cilium.oal即 oal/cilium.oal其中使用的CiliumService等 Scope 的字段定义可参考 Scope 声明文档Scopes with Cilium prefixCilium 仪表盘面板配置随 SkyWalking Horizon UI 包apache/skywalking-horizon-ui一同发布OAP 后端不再托管 UI 仪表盘 JSON。三条路径的选型建议三条监控路径从仓库的 backend-k8s-monitoring.md 出发、互不冲突且维度互补需要集群资源大盘与容量规划选择KSM cAdvisor路径。它数据链路轻依赖 OpenTelemetry Collector 转发、指标覆盖面广集群/节点/服务三级的 CPU、内存、存储、状态适合作为 K8s 集群的体检报告也是接入成本最低的一条路径需要拓扑感知、网络性能分析与无侵入 profiling选择RovereBPF路径。它对应用语言无侵入可观测到 syscall 级、协议栈各层的读写细节并能对 C/Rust/Golang 等服务做 profiling集群已采用 Cilium 作为 CNI优先选择Cilium Fetcher路径。直接复用 Cilium Hubble 的观测能力获取 Flow 数据天然支持 L4/L7HTTP/DNS/Kafka指标与拓扑图且在 OAP 集群模式下自带负载均衡能力。三条路径生成的实体均落在 SkyWalking 标准的 Service / Instance / Endpoint / Relation 模型上因此可以统一在 SkyWalking UIHorizon UI中查看拓扑与指标并与 SkyWalking 其他观测数据Trace、Log、Meter形成完整的可观测闭环。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
