BEACO-216: fix initial monitoring integration (Longhorn scrape, CNPG identities) #280

Merged

multica-merger merged 2 commits from agent/gitops/beaco-216-longhorn-prometheus-allow into main 2026-10-18 14:51:30 +00:00

Conversation 1 Commits 2 Files changed 4 +59 -1

multica-gitops commented 2026-10-18 14:04:17 +00:00

Collaborator

Copy link

首次接入的两项最小修复（可审查准备，不是已授权部署）

本 PR 接续 #280，把 2026-10-17 首次接入后发现的两个确定缺陷合并为一份审阅变更；不扩展为新的监控栈或准备套娃。

• base / 当前 main：7775b05990c17c73ae49397a976c839114c1aebc
• head：f786e053792778a6aa5afad7387950a0193c41c7
• 两个提交：
  • 9f1408c2be5a9b70ba0997edc4acdbd7837f5732 fix(storage): allow Prometheus to scrape longhorn-manager
  • f786e053792778a6aa5afad7387950a0193c41c7 fix(monitoring): identify CNPG targets by owner kind
• 最终增量：4 files changed, 59 insertions(+), 1 deletion(-)
  • wanxiang/kubernetes/apps/storage/longhorn/app/networkpolicy-prometheus.yaml（新增）
  • wanxiang/kubernetes/apps/storage/longhorn/app/kustomization.yaml
  • wanxiang/kubernetes/apps/monitoring/prometheus-stack/app/prometheusrule.yaml
  • utils/test-observability-prep.py
• 签名：两提交均 Forgejo verified=true；parent 为当前 main，fast-forward 成立；PR open、mergeable、未合并
• 不修改 Longhorn HelmRelease、现有 NetworkPolicy、Prometheus/Alertmanager、PVC、Secret、RBAC、业务 Pod 或节点配置

修复一：Longhorn 采集被 NetworkPolicy 阻断

实际只读核查（2026-10-18）确认：storage/longhorn-manager NetworkPolicy 的 ingress 只允许 Longhorn 自身组件，未允许 monitoring 的 Prometheus；3 个 longhorn-backend target 均 health=down（context deadline exceeded），apiserver Service proxy 访问 longhorn-backend:9500/metrics 也超时。集群无 CiliumNetworkPolicy/CiliumClusterwideNetworkPolicy。

新增 storage/longhorn-manager-prometheus NetworkPolicy，只增加一条 additive allow：

• 目标：storage 中 app=longhorn-manager Pod
• 唯一 peer：namespaceSelector（kubernetes.io/metadata.name=monitoring）与 podSelector（app.kubernetes.io/name=prometheus 且 prometheus=kube-prometheus-stack-prometheus）在同一 peer 内形成 AND
• 唯一端口：TCP 9500

不开放其他 namespace、其他 Pod 或其他端口；源绑定当前已部署的 Prometheus 实例，不退化为整个 monitoring。旧 longhorn-manager 策略保持不动。

授权边界（必须让批准人知道）

该 NetworkPolicy 是 TCP 9500 端口级的允许，不能限制只访问 /metrics；源已绑定当前 Prometheus 实例，9500 也是 Longhorn 管理服务端口。这不等于本次会调用管理 API，但批准人应知道该来源对该端口的访问范围。保留原有策略并不等于没有增加访问权限，只是增量被限制在一个来源和一个端口。

修复二：CNPG WanxiangMonitoredTargetMissing 误报

2026-10-18 14:03 只读证据：规则对 ai/memoh-postgres-0、ai/memoh-pgvector-0 firing。两者是普通 apps/v1 StatefulSet 所有的 Postgres，分别为 postgres:18-alpine 与 pgvector:pg18，没有 CNPG 标签，只有 5432 业务端口，不属于 monitoring/cnpg-instances PodMonitor。旧规则仅凭 container="postgres" 判断期望 inventory，构成目标身份误判。

修复为基于现有 KSM 指标 kube_pod_owner 识别真实 CNPG 管理身份：

(
  (
    kube_pod_container_status_ready{container="postgres"} == 1
    and on(namespace, pod) kube_pod_owner{owner_kind="Cluster",owner_is_controller="true"}
  )
  unless on(namespace, pod) up{job="monitoring/cnpg-instances"}
)

• CNPG 实例 Pod 的 owner kind 为 Cluster，普通 Postgres StatefulSet 为 StatefulSet；不新增权限、不改业务 Pod、不引入大范围 KSM 标签或新服务。
• 仍以 up{job="monitoring/cnpg-instances"} 的逐 Pod 消失作为报警条件，不把 up 本身当期望清单；真实 CNPG 目标从发现消失、单目标丢失而其他 peer 健康时仍会报警。
• 若 KSM 整体缺失，由既有 WanxiangKubeStateMetricsMissing 覆盖。

现场只读验证（修复前）：旧表达式匹配 2 个 memoh Pod；kube_pod_owner{owner_kind="Cluster",owner_is_controller="true"} 为 24（当前 CNPG 实例数）；修复后表达式对当前实时数据返回 0 个误报，24 个 CNPG 实例仍被识别为期望目标。

测试

• bash utils/run-observability-test.sh 通过（规则、chart 渲染、循环送达、看板查询）。
• utils/test-observability-prep.py 的 promtool 场景新增/覆盖：
  • 普通 StatefulSet Postgres（memoh-postgres-0）不告警；
  • 真实 CNPG 健康 peer 不告警；
  • 真实 CNPG 已发现但 target 从发现消失时告警；
  • 其他健康 CNPG peer 不掩盖该缺失目标；
  • 目标恢复后告警清除。
• NetworkPolicy 离线验证：kubectl kustomize 渲染出 1 ingress / 1 peer / 1 port；实际 namespace/Pod 标签与 9500 端口匹配；错误 namespace、错误 Pod、错误端口负例均被拒绝；旧策略未改。
• 本 head 六项代码 CI 全部 success：push 4266 docs / 4267 Nix / 4268 secrets；PR 4269 docs / 4270 Nix / 4271 secrets，每个 run 一个 success job。policy/merge-gate 仍 pending。

合入后的只读验收

1. Flux 创建 storage/longhorn-manager-prometheus，Kustomization/longhorn Ready；既有 longhorn-manager 策略内容不变；job="longhorn-backend" 恢复 3/3 health=up，Longhorn 指标新鲜，WanxiangMonitoredTargetDown{job="longhorn-backend"} 不再 firing 并 resolved（null receiver 不外发）。
2. PrometheusRule 更新加载；WanxiangMonitoredTargetMissing 对 memoh-postgres-0/memoh-pgvector-0 不再 firing；真实 CNPG target 缺失仍能在健康 peer 存在时触发。
3. 节点采集保持通过：node-exporter 3/3 up、三节点 CPU/内存/磁盘（实际 /var xfs）、20Gi+2Gi PVC 与 Longhorn 三副本健康均不因本 PR 改变。
4. 不重跑全轮准备/压测；不把本 PR 解释为 Grafana/共享入口、真实通知或主动故障演练完成。

撤销

生产 undo 通过 branch/PR/门禁对相应 commit 做 revert（两处修复可整体或分别撤销），不能以本地 revert 代替；Flux prune 后 Longhorn 会回到原失败状态、CNPG 规则回到旧误报行为。保留原有 Prometheus/Alertmanager/Operator/KSM/exporter 与 20Gi+2Gi PVC，不改 Longhorn 自身策略、业务 Pod、节点网络/存储。

边界

当前节点 CPU/内存/磁盘/存活已实际运行；存储/Longhorn 采集尚未通过（3 个 target down）；CNPG 误报为本次修复对象。Grafana/共享入口、真实通知、主动故障演练仍未完成。本 PR 只是可审查准备，生产生效需另行授权；不授权 apply/reconcile、批准/合并、Secret/RBAC/业务 Pod 变更、真实通知或故障注入。

Refs: BEACO-216

## 首次接入的两项最小修复（可审查准备，不是已授权部署） 本 PR 接续 #280，把 2026-10-17 首次接入后发现的**两个确定缺陷**合并为一份审阅变更；不扩展为新的监控栈或准备套娃。 - base / 当前 main：`7775b05990c17c73ae49397a976c839114c1aebc` - head：`f786e053792778a6aa5afad7387950a0193c41c7` - 两个提交： - `9f1408c2be5a9b70ba0997edc4acdbd7837f5732` `fix(storage): allow Prometheus to scrape longhorn-manager` - `f786e053792778a6aa5afad7387950a0193c41c7` `fix(monitoring): identify CNPG targets by owner kind` - 最终增量：4 files changed, 59 insertions(+), 1 deletion(-) - `wanxiang/kubernetes/apps/storage/longhorn/app/networkpolicy-prometheus.yaml`（新增） - `wanxiang/kubernetes/apps/storage/longhorn/app/kustomization.yaml` - `wanxiang/kubernetes/apps/monitoring/prometheus-stack/app/prometheusrule.yaml` - `utils/test-observability-prep.py` - 签名：两提交均 Forgejo `verified=true`；parent 为当前 main，fast-forward 成立；PR open、mergeable、未合并 - 不修改 Longhorn HelmRelease、现有 NetworkPolicy、Prometheus/Alertmanager、PVC、Secret、RBAC、业务 Pod 或节点配置 ## 修复一：Longhorn 采集被 NetworkPolicy 阻断 实际只读核查（2026-10-18）确认：`storage/longhorn-manager` NetworkPolicy 的 ingress 只允许 Longhorn 自身组件，未允许 `monitoring` 的 Prometheus；3 个 `longhorn-backend` target 均 `health=down`（`context deadline exceeded`），apiserver Service proxy 访问 `longhorn-backend:9500/metrics` 也超时。集群无 CiliumNetworkPolicy/CiliumClusterwideNetworkPolicy。 新增 `storage/longhorn-manager-prometheus` NetworkPolicy，只增加一条 additive allow： - 目标：`storage` 中 `app=longhorn-manager` Pod - 唯一 peer：`namespaceSelector`（`kubernetes.io/metadata.name=monitoring`）与 `podSelector`（`app.kubernetes.io/name=prometheus` **且** `prometheus=kube-prometheus-stack-prometheus`）在**同一 peer** 内形成 AND - 唯一端口：TCP 9500 不开放其他 namespace、其他 Pod 或其他端口；源绑定当前已部署的 Prometheus 实例，不退化为整个 `monitoring`。旧 `longhorn-manager` 策略保持不动。 ### 授权边界（必须让批准人知道） 该 NetworkPolicy 是 **TCP 9500 端口级**的允许，不能限制只访问 `/metrics`；源已绑定当前 Prometheus 实例，9500 也是 Longhorn 管理服务端口。这不等于本次会调用管理 API，但批准人应知道该来源对该端口的访问范围。**保留原有策略并不等于没有增加访问权限**，只是增量被限制在一个来源和一个端口。 ## 修复二：CNPG `WanxiangMonitoredTargetMissing` 误报 2026-10-18 14:03 只读证据：规则对 `ai/memoh-postgres-0`、`ai/memoh-pgvector-0` firing。两者是普通 `apps/v1` StatefulSet 所有的 Postgres，分别为 `postgres:18-alpine` 与 `pgvector:pg18`，没有 CNPG 标签，只有 5432 业务端口，不属于 `monitoring/cnpg-instances` PodMonitor。旧规则仅凭 `container="postgres"` 判断期望 inventory，构成目标身份误判。 修复为基于现有 KSM 指标 `kube_pod_owner` 识别真实 CNPG 管理身份： ```promql ( ( kube_pod_container_status_ready{container="postgres"} == 1 and on(namespace, pod) kube_pod_owner{owner_kind="Cluster",owner_is_controller="true"} ) unless on(namespace, pod) up{job="monitoring/cnpg-instances"} ) ``` - CNPG 实例 Pod 的 owner kind 为 `Cluster`，普通 Postgres StatefulSet 为 `StatefulSet`；不新增权限、不改业务 Pod、不引入大范围 KSM 标签或新服务。 - 仍以 `up{job="monitoring/cnpg-instances"}` 的逐 Pod 消失作为报警条件，不把 `up` 本身当期望清单；真实 CNPG 目标从发现消失、单目标丢失而其他 peer 健康时仍会报警。 - 若 KSM 整体缺失，由既有 `WanxiangKubeStateMetricsMissing` 覆盖。 现场只读验证（修复前）：旧表达式匹配 2 个 memoh Pod；`kube_pod_owner{owner_kind="Cluster",owner_is_controller="true"}` 为 24（当前 CNPG 实例数）；修复后表达式对当前实时数据返回 0 个误报，24 个 CNPG 实例仍被识别为期望目标。 ## 测试 - `bash utils/run-observability-test.sh` 通过（规则、chart 渲染、循环送达、看板查询）。 - `utils/test-observability-prep.py` 的 promtool 场景新增/覆盖： - 普通 StatefulSet Postgres（`memoh-postgres-0`）不告警； - 真实 CNPG 健康 peer 不告警； - 真实 CNPG 已发现但 target 从发现消失时告警； - 其他健康 CNPG peer 不掩盖该缺失目标； - 目标恢复后告警清除。 - NetworkPolicy 离线验证：`kubectl kustomize` 渲染出 1 ingress / 1 peer / 1 port；实际 namespace/Pod 标签与 9500 端口匹配；错误 namespace、错误 Pod、错误端口负例均被拒绝；旧策略未改。 - 本 head 六项代码 CI 全部 success：push 4266 docs / 4267 Nix / 4268 secrets；PR 4269 docs / 4270 Nix / 4271 secrets，每个 run 一个 success job。`policy/merge-gate` 仍 pending。 ## 合入后的只读验收 1. Flux 创建 `storage/longhorn-manager-prometheus`，`Kustomization/longhorn` Ready；既有 `longhorn-manager` 策略内容不变；`job="longhorn-backend"` 恢复 **3/3 health=up**，Longhorn 指标新鲜，`WanxiangMonitoredTargetDown{job="longhorn-backend"}` 不再 firing 并 resolved（null receiver 不外发）。 2. PrometheusRule 更新加载；`WanxiangMonitoredTargetMissing` 对 `memoh-postgres-0`/`memoh-pgvector-0` 不再 firing；真实 CNPG target 缺失仍能在健康 peer 存在时触发。 3. 节点采集保持通过：node-exporter 3/3 up、三节点 CPU/内存/磁盘（实际 `/var` xfs）、20Gi+2Gi PVC 与 Longhorn 三副本健康均不因本 PR 改变。 4. 不重跑全轮准备/压测；不把本 PR 解释为 Grafana/共享入口、真实通知或主动故障演练完成。 ## 撤销 生产 undo 通过 branch/PR/门禁对相应 commit 做 revert（两处修复可整体或分别撤销），不能以本地 revert 代替；Flux prune 后 Longhorn 会回到原失败状态、CNPG 规则回到旧误报行为。**保留原有 Prometheus/Alertmanager/Operator/KSM/exporter 与 20Gi+2Gi PVC**，不改 Longhorn 自身策略、业务 Pod、节点网络/存储。 ## 边界 当前节点 CPU/内存/磁盘/存活已实际运行；存储/Longhorn 采集尚未通过（3 个 target down）；CNPG 误报为本次修复对象。Grafana/共享入口、真实通知、主动故障演练仍未完成。本 PR 只是可审查准备，生产生效需另行授权；不授权 apply/reconcile、批准/合并、Secret/RBAC/业务 Pod 变更、真实通知或故障注入。 Refs: BEACO-216

multica-gitops added 1 commit 2026-10-18 14:04:17 +00:00

fix(storage): allow Prometheus to scrape longhorn-manager ... 9f1408c2be

Add an additive Ingress NetworkPolicy so the reviewed kube-prometheus-stack Prometheus instance can reach the existing longhorn-manager metrics port 9500. The peer is restricted to the monitoring namespace and the current Prometheus pod labels; no other namespace, pod, or port is opened.

Co-authored-by: multica-agent <github@multica.ai>

multica-gitops added 1 commit 2026-10-18 14:07:21 +00:00

fix(monitoring): identify CNPG targets by owner kind ... f786e05379

The missing-target rule treated any ready postgres container as an expected CNPG target. Restrict the expected inventory to pods owned by a CNPG Cluster via kube_pod_owner, while keeping the per-pod up check so a discovered target that disappears still alerts. Add fixtures for a real CNPG peer, a missing CNPG target, recovery, and ordinary StatefulSet postgres pods.

Co-authored-by: multica-agent <github@multica.ai>

multica-gitops changed title from BEACO-216: allow Prometheus to scrape longhorn-manager to BEACO-216: fix initial monitoring integration (Longhorn scrape, CNPG identities) 2026-10-18 14:08:56 +00:00

beacon1096 commented 2026-10-18 14:51:25 +00:00

Owner

Copy link

/approve f786e05379

/approve f786e053792778a6aa5afad7387950a0193c41c7

multica-merger merged commit f786e05379 into main 2026-10-18 14:51:30 +00:00

multica-merger deleted branch agent/gitops/beaco-216-longhorn-prometheus-allow 2026-10-18 14:51:30 +00:00

multica-gitops referenced this pull request 2026-10-26 16:31:41 +00:00

docs(backup): 修正全量间隔说明并记录 coder-pg-4 手动恢复点 (BEACO-235) #279

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

infrastructure/infra!280

No description provided.