指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载导读本文围绕 Zabbix 官方模板Kubernetes Scheduler by HTTP展开介绍如何在不依赖任何外部脚本的前提下通过 HTTP agent 从 Kubernetes Scheduler 的/metricsPrometheus 端点批量采集调度器运行指标并完成内存、CPU、REST Client 请求、调度成功率与调度延迟分位数的全方位监控与告警。读完本文你将掌握该模板的部署前置条件、宏参数配置、监控项与预处理链路的内部原理以及调度延迟直方图的自动发现与分位数计算机制。模板概览为什么用 HTTP 采集 Scheduler 指标Kubernetes Scheduler by HTTP是 Zabbix 为 Kubernetes 控制面组件提供的官方模板之一位于仓库 templates/app/kubernetes_http/kubernetes_scheduler_http/ 目录下。它的核心设计思路是零外部脚本所有指标都由 Zabbix Server/Proxy 内置的 HTTP agent 直接抓取无需在集群内部署 exporter 或自定义采集脚本批量采集模板通过单个 HTTP 请求抓取 Scheduler 的/metrics端点原始文本再借助Prometheus pattern / Prometheus to JSON预处理能力将原始指标拆解为数十个独立监控项实现一次抓取、多处复用即 README 中所说的Zabbix bulk data collection。该模板的 YAML 定义文件为 template_kubernetes_scheduler.yaml由官方模板工具 Templator 生成wizard_ready标记为YES即模板可直接在 Zabbix 8.0 的模板向导中使用。模板自带Scheduler overview仪表盘包含 General内存、REST Client 查询速率、调度尝试速率与 LatenciesBinding、E2e、Scheduling algorithm 三类延迟两个页面。适用版本与已验证环境Zabbix 版本要求8.0 及以上README 明确标注 Zabbix version: 8.0 and higher模板导出 YAML 头部的zabbix_export: version: 8.0也印证了这一点已验证的 Kubernetes 版本Kubernetes Scheduler 1.19.10注意事项部分指标可能因 Scheduler 实例的版本与配置差异而无法采集模板对此已在 README 中明确提示。部署前置与 Setup1. 配置 Scheduler 的绑定地址关键前提Scheduler 的指标端点默认绑定在回环地址Zabbix 需要通过 HTTP 访问该端点因此可能需要为 kube-scheduler 设置--binding-address选项使其监听 Zabbix Server/Proxy 可达的地址。对使用kubeadm创建的集群只需修改静态 Pod 清单文件修改会立即生效/etc/kubernetes/manifests/kube-scheduler.yaml2. 准备 API 鉴权 Token模板通过Authorization: Bearer {$KUBE.API.TOKEN}请求头访问/metrics端点见 YAML 中Get Scheduler metrics监控项的headers定义。在 kubernetes_http 目录总览 中官方给出了通过 Helm Chart 部署后获取 Token 的方式kubectl get secret zabbix-zabbix-helm-chart -n monitoring -o jsonpath{.data.token} | base64 -d3. 导入模板并创建主机将 template_kubernetes_scheduler.yaml 导入 Zabbix为 Scheduler 创建主机并关联Kubernetes Scheduler by HTTP模板为主机配置 Zabbix 可访问的接口HTTP 监控项需要主机接口在模板或主机级覆盖以下宏{$KUBE.SCHEDULER.SERVER.URL}、{$KUBE.API.TOKEN}并按需调整触发器阈值宏详见下一节。宏参数详解模板共定义了 4 个用于采集与告警的宏README 中均列出加上 YAML 中macros段补充的配置元数据含 secret 类型、输入校验正则与优先级汇总如下宏描述默认值YAML 中的配置细节{$KUBE.API.TOKEN}API 授权 TokenBearer Token空类型为SECRET_TEXT在 Zabbix 界面中作为加密文本存储required: YES优先级 1{$KUBE.SCHEDULER.SERVER.URL}Scheduler metrics 端点 URLhttps://localhost:10259/metrics普通 TEXT 宏优先级 2对应 HTTP 监控项的url字段{$KUBE.SCHEDULER.HTTP.CLIENT.ERROR}REST Client 请求失败5xx告警阈值2TEXT 宏优先级 3校验正则^-?([0-9]|(([0-9])\.([0-9])))$即允许整数或小数不小于 0{$KUBE.SCHEDULER.UNSCHEDULABLE}unschedulable 调度失败告警阈值2TEXT 宏优先级 4位于 Thresholds 配置分组同样带数值校验正则{$KUBE.SCHEDULER.ERROR}error 调度失败告警阈值2TEXT 宏优先级 5位于 Thresholds 配置分组带数值校验正则实操提示{$KUBE.SCHEDULER.SERVER.URL}默认指向https://localhost:10259/metrics这是 kube-scheduler 默认的安全端口10258 为旧版非安全端口1.19 及以后默认使用 10259。若你的集群通过--secure-port或端口转发暴露端点务必在宏中覆盖为实际可达地址Token 宏建议在 Zabbix 前端中以 Secret 类型填写避免明文出现在配置导出文件中。监控项体系从原始抓取到派生指标模板的监控项以1 个 HTTP 主监控项 16 个依赖型监控项的结构组织所有依赖项都以kubernetes.scheduler.get_metrics为master_item即 YAML 中的master_item: key: kubernetes.scheduler.get_metrics从同一份抓取结果中取值。主监控项名称类型Key关键配置Get Scheduler metricsHTTP agentkubernetes.scheduler.get_metrics请求{$KUBE.SCHEDULER.SERVER.URL}timeout: 15svalue_type: TEXThistory: 0原始文本不保留历史仅作为派生源请求头Authorization: Bearer {$KUBE.API.TOKEN}预处理为CHECK_NOT_SUPPORTED参数-1即任意错误都标记为不支持并丢弃该值进程级指标依赖项名称Key单位预处理链路Virtual memory, byteskubernetes.scheduler.process_virtual_memory_bytesBPrometheus patternVALUE(process_virtual_memory_bytes)失败时 Discard valueResident memory, byteskubernetes.scheduler.process_resident_memory_bytesBPrometheus patternVALUE(process_resident_memory_bytes)失败时 Discard valueCPUkubernetes.scheduler.cpu.util%VALUE(process_cpu_seconds_total)→Change per second→Custom multiplier 100把累加的 CPU 秒数换算为每秒使用比例再乘以 100 得到百分比Goroutineskubernetes.scheduler.go_goroutines无Prometheus patternSUM(go_goroutines)失败时 Discard valueGo threadskubernetes.scheduler.go_threads无VALUE(go_threads)失败时 Discard valueFds openkubernetes.scheduler.open_fds无VALUE(process_open_fds)失败时 Discard valueFds maxkubernetes.scheduler.max_fds无VALUE(process_max_fds)失败时 Discard valueREST Client 请求指标依赖项模板按 HTTP 状态码维度对rest_client_requests_total{code ~ 2..}等 Prometheus 计数器做按秒求速率Change per second处理共 4 个监控项名称KeyPrometheus 模式REST Client requests: 2xx, ratekubernetes.scheduler.client_http_requests_200.rateSUM(rest_client_requests_total{code ~ 2..})REST Client requests: 3xx, ratekubernetes.scheduler.client_http_requests_300.rateSUM(rest_client_requests_total{code ~ 3..})REST Client requests: 4xx, ratekubernetes.scheduler.client_http_requests_400.rateSUM(rest_client_requests_total{code ~ 4..})REST Client requests: 5xx, ratekubernetes.scheduler.client_http_requests_500.rateSUM(rest_client_requests_total{code ~ 5..})以上每个监控项都带component: rest与http-code: xxx标签可用于图形筛选与仪表盘聚合。调度尝试指标依赖项对scheduler_schedule_attempts_total按result标签拆分并计算每秒速率名称KeyPrometheus 模式语义Schedule attempts: scheduledkubernetes.scheduler.scheduler_schedule_attempts.scheduled.rateSUM(scheduler_schedule_attempts_total{result scheduled})每秒成功调度 Pod 的次数Schedule attempts: unschedulablekubernetes.scheduler.scheduler_schedule_attempts.unschedulable.rateSUM(scheduler_schedule_attempts_total{result unschedulable})每秒因资源不足等原因无法调度的次数Schedule attempts: errorkubernetes.scheduler.scheduler_schedule_attempts.error.rateSUM(scheduler_schedule_attempts_total{result error})每秒因内部错误调度失败次数告警触发器模板内置 3 个 Warning 级别触发器全部基于5 分钟窗口的min()聚合与阈值宏比较可有效过滤瞬时抖动触发器名称表达式说明故障标签Kubernetes Scheduler: Too many REST Client errorsmin(/Kubernetes Scheduler by HTTP/kubernetes.scheduler.client_http_requests_500.rate,5m){$KUBE.SCHEDULER.HTTP.CLIENT.ERROR}Scheduler 的 REST Client 请求 5xx 错误率过高表明其与 API Server 通信异常scope: availabilityKubernetes Scheduler: Too many unschedulable podsmin(/Kubernetes Scheduler by HTTP/kubernetes.scheduler.scheduler_schedule_attempts.unschedulable.rate,5m){$KUBE.SCHEDULER.UNSCHEDULABLE}unschedulable 即 Pod 无法被调度如节点资源不足、污点/容忍不匹配scope: performanceKubernetes Scheduler: Too many schedule attempts with errorsmin(/Kubernetes Scheduler by HTTP/kubernetes.scheduler.scheduler_schedule_attempts.error.rate,5m){$KUBE.SCHEDULER.ERROR}error 表示调度器内部问题属于更严重的故障信号scope: performance三个触发器的event_name均会动态展开为 over {$...} for 5m 形式便于在告警消息中直接看到触发阈值。三者的默认阈值宏均为2即 5 分钟内对应速率均值超过 2 次/秒才告警YAML 中通过regex约束其值必须为数值且不小于 0。调度延迟监控三个直方图的自动发现与分位数计算模板最具技术深度的部分是用三条 LLD 规则依赖型对 Scheduler 暴露的 Prometheus histogram 类型指标做发现与分位数计算覆盖调度器的完整延迟链路LLD 规则Key描述Prometheus to JSON 查询Scheduling algorithm histogramkubernetes.scheduler.scheduling_algorithm.discovery调度算法耗时分布选点过程{__name__~ scheduler_scheduling_algorithm_duration_seconds_*}Binding histogramkubernetes.scheduler.binding.discoveryBinding绑定耗时分布{__name__~ scheduler_binding_duration_seconds_*}e2e scheduling histogramkubernetes.controller.e2e_scheduling.discovery端到端调度耗时分布算法 Binding{__name__~ scheduler_e2e_scheduling_duration_*, result ~ .*}发现链路的三个预处理步骤以 Binding histogram 为例其 LLD 规则预处理依次为Prometheus to JSON将scheduler_binding_duration_seconds_*系列指标转为 JSON 数组JavaScript遍历 JSON对*_count系列生成{#TYPE}: totals宏对*_bucket系列提取{#LE}桶上界产出 LLD 宏数据JSON.parse(value).forEach(function (item) { if (item.name scheduler_binding_duration_seconds_count){ result.push({{#TYPE}: totals, {#SINGLETON}: }); } else if (item.name scheduler_binding_duration_seconds_bucket){ result.push({{#TYPE}: buckets, {#LE}: item.labels.le}); } }); return JSON.stringify(result);Discard unchanged with heartbeat: 3h当发现结果 3 小时内无变化时丢弃避免重复入库。随后通过两条LLD overrides过滤{#TYPE}为buckets的启用 bucket 原型{#TYPE}为totals的启用非 bucket 原型见 YAML 中overrides段的LIKE/NOT_LIKE规则。桶原型与分位数计算原型每条直方图 LLD 规则下都有两类监控项原型Bucket 原型依赖项如kubernetes.scheduler.binding_duration[{#LE}]用 Prometheus pattern 抓取对应le桶的累计计数history: 1h、trends: 0仅服务于分位数计算分位数原型计算项 Calculatedp50 / p90 / p95 / p99 四个分位统一使用 Zabbix 计算监控项函数bucket_percentile例如bucket_percentile(//kubernetes.scheduler.binding_duration[*],5m,50) bucket_percentile(//kubernetes.scheduler.binding_duration[*],5m,90) bucket_percentile(//kubernetes.scheduler.binding_duration[*],5m,95) bucket_percentile(//kubernetes.scheduler.binding_duration[*],5m,99)该函数在 Zabbix 表达式引擎中实现见 expr_eval.c其中MATCH_STRING(bucket_percentile, ...)及对应求值分支其原理是从 Prometheus histogram 的累计桶计数中在 5 分钟窗口内按桶间差分估算出指定分位的延迟秒数输出单位为s。同理Scheduling algorithm 与 e2e 两条规则分别通过kubernetes.scheduler.scheduling_algorithm_duration[*]与kubernetes.scheduler.e2e_scheduling_bucket[*,{#RESULT}]计算对应分位。e2e 规则额外按{#RESULT}宏区分scheduled/unschedulable/error等调度结果因此其分位原型 Key 形如kubernetes.scheduler.e2e_scheduling_p90[{#RESULT}]。注意分位原型默认discover: NO_DISCOVER需由 LLD overrides 按{#TYPE}匹配后显式启用因此 LLD 规则的实际产出数量是动态的、与端点暴露的桶数量一致。延迟图形原型三条规则各带一个图形原型将 p50/p90/p95/p99 四条曲线叠加分别命名为Kubernetes Scheduler: [{#SINGLETON}]Binding latency、Kubernetes Scheduler: [{#SINGLETON}]Scheduling algorithm duration、Kubernetes Scheduler: [{#RESULT}] E2e latency。结合内置Scheduler overview仪表盘的 Latencies 页按 1 列布局依次展示这三个图形原型即可在一个页面内观察调度延迟全链路的分位趋势。底层原理Prometheus 预处理如何落地模板中大量使用的Prometheus pattern与Prometheus to JSON是 Zabbix 8.0 预处理框架的原生能力其执行入口在 pp_execute.c内部以ZBX_PREPROC_PROMETHEUS_PATTERN、ZBX_PREPROC_PROMETHEUS_TO_JSON两个预处理类型分发处理另有pp_cache.c负责结果缓存。这意味着所有派生监控项都不产生额外网络请求完全复用主监控项kubernetes.scheduler.get_metrics的抓取文本这正是 Most of the metrics are collected in one go 的实现基础当某条 Prometheus pattern 在原始文本中匹配不到时多数监控项配置了⛔️Custom on fail: Discard value即error_handler: DISCARD_VALUE避免因单指标缺失导致监控项进入不支持状态或产生错误数据——这也解释了 README 中部分指标可能因版本/配置差异而采集不到的容错设计。使用注意事项与排障清单网络可达性若 Zabbix Proxy 无法直连 Scheduler 的 10259 端口务必先修改/etc/kubernetes/manifests/kube-scheduler.yaml中的--binding-address或使用 kube-proxy / 端口转发方案否则主监控项将因连接失败被CHECK_NOT_SUPPORTED丢弃Token 有效性{$KUBE.API.TOKEN}使用 Bearer 方案YAML 中请求头为Authorization: Bearer ...Token 过期或错误会导致 401表现为 REST Client 4xx 指标持续增长并触发相关告警阈值语义{$KUBE.SCHEDULER.UNSCHEDULABLE}与{$KUBE.SCHEDULER.ERROR}均为 5 分钟窗口内的速率均值上限在业务高峰期若出现大量 Pending Pod可按实际调度频率调大阈值避免误报指标缺失不同 Kubernetes 版本暴露的 histogram 桶与标签可能不同如 e2e 的result标签若 LLD 未发现任何原型请先用curl -k -H Authorization: Bearer token https://scheduler:10259/metrics核对端点输出是否符合模板的 Prometheus 查询模式。小结Kubernetes Scheduler by HTTP模板完整覆盖了 Scheduler 进程资源内存/CPU/文件描述符/Go 运行时、REST Client 通信质量2xx~5xx 请求速率、调度结果scheduled/unschedulable/error 速率以及调度延迟分位算法耗时、Binding 耗时、端到端耗时四个维度并自带告警与仪表盘。其单次 HTTP 抓取 Prometheus 预处理 bucket_percentile 分位计算 LLD 动态发现的组合为同类 Kubernetes 控制面组件API Server、Controller Manager、Kubelet 等见 kubernetes_http 目录总览的监控模板提供了可复用的标准范式。导入模板后只需按上文配置好端点 URL 与 API Token即可获得对调度器运行状态的实时可观测能力。赞分享指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载相关推荐Zabbix 监控 Kubernetes API Server 实战基于 HTTP 的官方模板深入解析Zabbix 监控 Kubernetes API Server 实战基于 HTTP 的官方模板深入解析 本文基于仓库 templates/app/kubern指标监控可观测性告警运维DeepSeek Harness Desktop 布局所有权架构Advanced / Extended 模式下的 layout 服务独占与冲突拒绝DeepSeek Harness Desktop 布局所有权架构Advanced / Extended 模式下的 layout 服务独占与冲突拒绝 本篇技术指指标监控可观测性告警运维toon-format/cli 完全指南JSON 与 TOON 双向转换、Token 统计与流式处理实战toon format/cli 完全指南JSON 与 TOON 双向转换、Token 统计与流式处理实战 导读 toon format/cli 是 TOO指标监控可观测性告警运维上一篇猫抓 Cat-Catch 浏览器扩展完整指南嗅探网页视频、合并 M3U8 流与批量保存下一篇OpenAPI查询参数终极指南掌握高效数据过滤API的完整技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考