云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载本指南聚焦 kube-prometheus 官方文档 docs/customizations/prometheus-agent.md 所描述的Prometheus Agent 模式集成方案。该方案通过 Jsonnet 补丁strategic merge patch让 kube-prometheus 部署的 Prometheus 以轻量 Agent 形态运行——只抓取指标并通过 remoteWrite 转发不存储、不查询、不告警。读完本文你将掌握完整的 Jsonnet 配置写法、每个关键字段的含义、构建产出物的正确顺序以及官方对“自行承担风险”这一边界条件的解读。重要声明官方原文虽然 Prometheus-Operator 支持以 Agent 模式运行 Prometheus但必须依赖 strategic merge patch 实现。此做法并非官方推荐若 Prometheus 未按预期工作kube-prometheus 不提供支持。请自行承担风险Try it at your own risk!。一、背景Prometheus Agent 模式与 kube-prometheus 的结合方式Prometheus Agent 模式是 Prometheus 提供的一种精简运行形态它保留抓取scrape与 remote write 的能力但不包含本地存储、查询query、告警alerting与规则评估等重负载功能内存占用显著低于常规 Prometheus。其典型应用场景是作为“指标采集器”将分散集群的指标统一转发到中心化的长期存储如 Thanos、Mimir、VictoriaMetrics 等 remote write 接收端。kube-prometheus 默认并不提供“一键开启 Agent 模式”的开关——官方文档明确指出与 Prometheus-Operator 的 Agent 支持对接需要strategic merge patches。这意味着我们需要在 Jsonnet 层面对PrometheusCR 的 spec 及容器参数进行覆盖式修补而不是通过新增的配置项去声明式地开启。在 kube-prometheus 的组件实现中Agent 相关字段实际上已有默认通道jsonnet/kube-prometheus/components/prometheus.libsonnet的defaults中定义了enableFeatures: []第 16 行并在构建PrometheusCR 时通过enableFeatures: p._config.enableFeatures第 348 行注入spec.enableFeatures。官方给的 Agent 方案正是在此基础上将agent特性加入该列表并额外修补容器启动参数与 remoteWrite 配置。二、完整配置示例逐段拆解官方文档给出的示例与仓库中的 examples/prometheus-agent.jsonnet 完全一致下面按逻辑分段解读。2.1 引入主库与 values 覆盖local kp (import kube-prometheus/main.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus: { resources: { requests: { memory: 100Mi }, }, enableFeatures: [agent], }, }, ... };import kube-prometheus/main.libsonnet导入 kube-prometheus 主入口它与 jsonnetfile.json 中声明的依赖一起通过jbjsonnet-bundler安装到vendor目录后即可被解析。values::是 kube-prometheus 暴露的统一配置入口类似 Helm 的values见 main.libsonnet 第 18-19 行注释 usingvaluesas this is similar to helm。::表示字段覆盖并保持惰性求值。common.namespace覆盖为monitoring这是 kube-prometheus 各组件默认命名空间。prometheus.resources.requests.memory覆盖为100Mi。作为对比组件默认值为requests: { memory: 400Mi }见 prometheus.libsonnet 第 9-11 行Agent 模式没有本地存储与查询内存需求更低官方示例借此体现“轻量”优势。prometheus.enableFeatures设置为[agent]最终会被写入PrometheusCR 的spec.enableFeatures由 Prometheus-Operator 渲染为--enable-featureagent启动参数。2.2 strategic merge patch修补 Prometheus CR specprometheus: { prometheus: { spec: { replicas: 1, alerting:: {}, ruleSelector:: {}, remoteWrite: [{ url: http://remote-write-url.com, }], containers: [ { name: prometheus, args: [ --config.file/etc/prometheus/config_out/prometheus.env.yaml, --storage.agent.path/prometheus, --enable-featureagent, --web.enable-lifecycle, ], }, ], }, }, },这一层是整个方案的核心也是文档所称“strategic merge patch”的落点replicas: 1覆盖默认的 2 副本prometheus.libsonnet 第 14 行replicas: 2。注意在 prometheus.libsonnet 第 321 行只有replicas 1时才生成podDisruptionBudget因此 Agent 模式下 PDB 会被自动移除。alerting:: {}清空默认的 Alertmanager 关联。kube-prometheus 默认将alerting.alertmanagers指向同命名空间的alertmanager-k8s见 main.libsonnet 第 104-111 行。::惰性覆盖为空对象确保 Agent 不再尝试连接 Alertmanager。ruleSelector:: {}清空默认的规则选择器。默认值同样是{}prometheus.libsonnet 第 17 行这里显式声明以强调 Agent 模式不加载任何PrometheusRule从而跳过规则评估。remoteWriteAgent 的数据出口。示例使用占位地址http://remote-write-url.com实际部署时必须替换为你的 remote write 接收端地址并按需补充authorization、basicAuth、writeRelabelConfigs等字段。containers修补名为prometheus的容器启动参数。:语义保证与 operator 渲染出的参数合并而非整体替换--config.file/etc/prometheus/config_out/prometheus.env.yaml保持与常规模式一致的配置文件路径由 Prometheus-Operator 的 config-reloader 生成。--storage.agent.path/prometheusAgent 模式的数据目录。--enable-featureagent与spec.enableFeatures双重保障spec 层由 operator 注入此处的显式参数使容器启动时即刻处于 Agent 模式。--web.enable-lifecycle允许通过 API 热加载配置。2.3 输出清单setup 资源与 CRD 就绪顺序{ setup/0namespace-namespace: kp.kubePrometheus.namespace } { [setup/prometheus-operator- name]: kp.prometheusOperator[name] for name in std.filter((function(name) name ! serviceMonitor name ! prometheusRule), std.objectFields(kp.prometheusOperator)) } // serviceMonitor and prometheusRule are separated so that they can be created after the CRDs are ready { prometheus-operator-serviceMonitor: kp.prometheusOperator.serviceMonitor } { prometheus-operator-prometheusRule: kp.prometheusOperator.prometheusRule } { kube-prometheus-prometheusRule: kp.kubePrometheus.prometheusRule } { [blackbox-exporter- name]: kp.blackboxExporter[name] for name in std.objectFields(kp.blackboxExporter) } { [grafana- name]: kp.grafana[name] for name in std.objectFields(kp.grafana) } { [kube-state-metrics- name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } { [kubernetes- name]: kp.kubernetesControlPlane[name] for name in std.objectFields(kp.kubernetesControlPlane) } { [node-exporter- name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } { [prometheus- name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } { [prometheus-adapter- name]: kp.prometheusAdapter[name] for name in std.objectFields(kp.prometheusAdapter) }setup/前缀资源Namespace 与全部 CustomResourceDefinition被单独分组确保 CRD 先于业务对象创建。serviceMonitor与prometheusRule从 operator 组件中剥离注释明确说明原因是“需要在 CRD 就绪之后再创建”避免应用时序问题。其余组件blackbox-exporter、grafana、kube-state-metrics、kubernetes 控制面、node-exporter、prometheus、prometheus-adapter按组件-资源命名铺平输出。2.4 编译为 YAML 清单仓库默认的manifests目标由 Makefile 第 77-78 行定义本质是执行build.shmake manifests # 等价于 # jsonnet -J vendor -m manifests examples/prometheus-agent.jsonnet | xargs ... gojsontoyamlbuild.sh 会先清空manifests/再用jsonnet -J vendor -m manifests输出多文件清单最终经gojsontoyaml转换为*.yaml。随后按kubectl create -f manifests/setup→kubectl apply -f manifests的顺序应用即可先创建 CRD 与 Namespace。三、为什么 Agent 模式需要修补而非开关源码依据对比 jsonnet/kube-prometheus/components/prometheus.libsonnet 中PrometheusCR 的构造逻辑第 333-371 行可以看到 kube-prometheus 始终会渲染出完整能力集spec.alerting无条件取自p._config.alerting第 362 行而默认值在 main.libsonnet 中已被指向 Alertmanagerspec.ruleSelector取自p._config.ruleSelector第 355 行spec.enableFeatures取自p._config.enableFeatures第 348 行。也就是说项目为“关闭告警/规则/存储”预留的只有enableFeatures这一个标准通道而告警与规则关联需要另行覆盖。这正是官方文档强调“requires strategic merge patches”的根源——它不是一个开箱即用的values.xxx开关而是需要你按上述方式在 spec 与容器参数两个层面手动合入补丁。从源码结构还可以推断enableFeatures支持列表不仅限于agentPrometheus 3.x 还提供exemplar-storage、auto-gomaxprocs、memory-snapshot-on-shutdown等实验特性传入[agent]只是利用了该字段的标准传递链路而 Agent 模式无法从该字段单独触发还依赖remoteWrite与容器参数补丁两者缺一不可。四、适用前提、限制与风险边界版本前提Agent 模式是 Prometheus 2.32 起引入的实验性功能到 2.39 前后趋于稳定。当前仓库 versions.json 锁定的 Prometheus 版本为3.14.0Prometheus-Operator 为0.94.1均可渲染--enable-featureagent与--storage.agent.path。能力裁剪Agent 模式下 kube-prometheus 的 Grafana 面板、PrometheusRule告警、Alertmanager告警链路均不再生效文档通过清空alerting与ruleSelector显式确认这一点prometheus-adapter若依赖本地 Prometheus 查询接口见 main.libsonnet 第 123 行以prometheus-k8s...svc:9090为prometheusURL的配置也将失去数据源需另行规划资源指标方案。支持边界官方文档以加粗形式给出风险声明——该做法不受支持未按预期工作时 kube-prometheus 不提供排障支持。建议仅在确有 remote write 集中存储、且可接受实验性部署的集群中使用并在测试环境先行验证。Remote write 端点示例中的http://remote-write-url.com必须替换为真实接收端并正确配置认证TLS、basicAuth 或 bearer token与写路径重打标writeRelabelConfigs。五、相关资源官方文档原文docs/customizations/prometheus-agent.md可直接编译的完整示例examples/prometheus-agent.jsonnetPrometheus 组件实现jsonnet/kube-prometheus/components/prometheus.libsonnet主入口与 values 结构jsonnet/kube-prometheus/main.libsonnet组件版本锁定jsonnet/kube-prometheus/versions.json清单生成流程Makefile 与 build.sh赞分享云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载上一篇Metabase 嵌入式分析 SDK 的 useAvailableFonts获取可用字体列表的 Hook 全解析下一篇YuE2许可证详解cc-by-nc-4.0非商业协议下AI音乐创作能做什么、不能做什么创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考