金仓 KMonitor 自带 Prometheus 接入 VictoriaMetrics 记录

记录时间：2026-09-01
环境：szzx 生产金仓主机 szzxdmdb03（17 网段信创）/ 金仓 KMonitor 自带 kingbase_prometheus（独立二进制，file_sd 服务发现）/ VictoriaMetrics helm 集群（vmauth 入口 prod.vm.example.com）

一、事情的由头

szzx 的金仓数据库用厂家配套的 KMonitor 做监控，主机 szzxdmdb03 上跑着一套独立的 Prometheus（二进制叫 kingbase_prometheus），抓金仓 exporter 和节点 exporter，本地评估告警发给它自己的 Alertmanager，数据以前只有厂家界面能看到。

szzx 的节点监控本来就在我的 dyck 采集线上（ServiceMonitor 抓 node-exporter，带业务标签），但金仓数据库自身的专有指标（缓存命中、会话、表空间这类）只有 KMonitor 这套有。既然 VM 是信创环境的统一监控（k3s 与 VM 的分工口径：k3s 管 x86 非国产，VM 管 k8s 加信创），那就把这套独立 Prometheus 的数据 remote_write 进 VM，本地告警行为先不动。

二、盘家底

先看这套东西长什么样。配置就一个 prometheus.yaml，两个抓取 job：

scrape_configs:
  - job_name: "kingbase_kes_exporter"     # 金仓库指标，/kingbase 路径
  - job_name: "kingbase_node_exporter"    # 节点指标，/metrics 路径

两个 job 都走 file_sd（读 monitor_data/prom_server/ 下的 JSON 清单），basic auth kingbase，60s 采集。规则文件 rules/kingbase_alerts.rules.yaml，告警发给 KMonitor 自己的 AM。目录里还有一个 kprometheus_ctl.sh 控制脚本（start/stop/restart/status），当时我只当它是普通启停脚本没细看，后来它给了我一次教训（见第四节）。

dyck 侧的家底：szzx 的 node-exporter 已经在采（other/node-exporter/szzx/ 下一批 ServiceMonitor 加 Endpoints，db-kes 那组是 10.202.17.42/.43:9200，带 systemName/app/nodeType/dbType 全套业务标签）。

三、方案：写什么、丢什么

3.1 remote_write 的口径

写入入口跟 dyck/kjds 两套集群 Prometheus 完全同款：vmauth 的 Ingress 域名加写入账号。queue 给小规格就够，目标只有个位数节点。

参数	值	说明
url	`http://prod.vm.example.com/insert/0/prometheus/`	vmauth 统一写入入口，与两集群一致
basic_auth	<账号> / <密码>	VM 写入账号（记录在 kj-info.md）
max_samples_per_send	2000	个位数目标用不了大批量
capacity	5000	短暂断链时的本地缓冲
max_shards	3	压住并发分片上限

3.2 node job 直接 drop

kingbase_node_exporter 不进 VM。理由：szzx 节点数据唯一源是 dyck 采集线，那边带全套业务标签，VM 的 node-exporter 告警规则全部按 component/systemName/nodeType 过滤；KMonitor 这份 node 数据是无标签重复源，写进 VM 只会让同类序列双份，聚合口径乱。drop 用 write_relabel_configs 做，只作用于发往 VM 的数据流，KMonitor 本地抓取和告警照旧，厂家完全无感。

金仓 kes job 继续全量写入。这里我专门过了一遍防双发：kes_exporter 裸推的序列没有 component/systemName/nodeType 这些标签，VM 侧现有 VMRule 一条都匹配不上，不会产生告警，跟 dyck 线的 KES 采集（带标签）不构成双发。所以这次接入的收益是数据进统一存储可查可上屏，告警覆盖仍走 dyck 线。

3.3 cluster 来源标签

多了一个数据来源就得能区分。本来打算用 global.external_labels 打 cluster 标签，后来被脚本逼着改了方案（见第四节），最终用 write_relabel_configs 的 replace 注入 cluster="kmonitor-prod"，效果一样：这台 Prometheus 写进 VM 的所有序列自带这个标签，AM 分组首键就是 cluster，来源天然隔离。

四、启动失败：line 28 报错，根因是启动脚本自己改配置

第一版配置我把 external_labels 加在 global 段、remote_write 插在 alerting 前面。现场改完执行 restart，起不来：

err="parsing YAML file ...: yaml: line 28: did not find expected key"

more 一看 prometheus.yaml：alerting 段里混进一行 file_sd 的 JSON 路径，remote_write 块里凭空多出一行 scheme，配置已经不是我改完的样子。文件是 kprometheus_ctl.sh 自己改的，翻出脚本，init() 里写着真凶：

sed -i "20s|.*|    scheme: \"http\"|" prometheus.yaml
sed -i "28s|.*|        - ${KMONITOR_DATA_PATH}/prom_server/kingbase_exporter_*.json|" prometheus.yaml
sed -i "33s|.*|    scheme: \"http\"|" prometheus.yaml
sed -i "41s|.*|        - ${KMONITOR_DATA_PATH}/prom_server/node_exporter_*.json|" prometheus.yaml

每次启动都按固定行号把 scheme 和 file_sd 路径重写一遍，厂家假设自家模板是定长的（file_sd 模式正好 42 行）。我插了 21 行进去，行号整体下移，sed 把第 28 行（alerting 段的 - static_configs:）覆盖成了 JSON 路径，33、41 行同样遭殃。受损行跟 sed 行号一对，四处损伤一一对应，连 remote_write 块里那行突兀的 scheme 都对上了（它站在我第一版的第 20 行，原本是行注释，被 sed 原地改写）。

还有一个行为要记死：这个脚本是先 stop 再 start，配置解析失败进程起不来，KMonitor 本地监控在修复期间是断的，金仓本地告警这段时间没人发。

4.1 sed 行号清单（全模式）

配置模式	被 sed 重写的行号	写入内容
file_sd + http（本例）	20、28、33、41	两个 job 的 scheme、两个 file_sd 路径
file_sd + TLS	同上，scheme 改 https	另改 tls.yaml 前三行
consul 模式	20、27、28、30、49、56、57、59	consul server 地址、ACL token、各 scheme

以后切 consul 或开 TLS，动文件前必须先重看这份行号表。

五、终版结构：模板区一字不动，扩展全追加尾部

想明白 sed 的行为，结构就是唯一解：厂家模板区（原版 1 到 42 行，到 node job 的 refresh_interval 为止）一个字不动、一个空行和注释都不增删，remote_write 整块追加到文件末尾。sed 重跑也是幂等的，它写回的路径值跟模板原文一致，随便重启。

external_labels 用不成了（global 在模板区里），cluster 标签改由 write_relabel_configs 注入。终版追加块：

remote_write:
  - url: "http://prod.vm.example.com/insert/0/prometheus/"
    basic_auth:
      username: "11111"
      password: "******"
    queue_config:
      max_samples_per_send: 2000
      capacity: 5000
      max_shards: 3
    write_relabel_configs:
      - target_label: cluster
        replacement: "kmonitor-prod"      # 来源标识，全序列注入
      - source_labels: [job]
        regex: "kingbase_node_exporter"
        action: drop                       # 节点数据不进 VM，唯一源在 dyck 线

文件头部加了一段注释把这个雷写明：改此文件只允许在 42 行之后追加。仓库落盘 prometheus/17.23-kmonitor/prometheus.yaml，作为这台机器的权威版本。

六、验证

服务器 scp 覆盖加 chown，restart，log 见 Server is ready，VM 侧查询：

curl -u '<写入账号>:******' \
  'http://prod.vm.example.com/select/0/prometheus/api/v1/query?query=up{cluster="kmonitor-prod"}'

VM UI 里 up{cluster="kmonitor-prod"} 返回 kingbase_kes_exporter 的目标 10.202.17.116:1234、10.202.17.117:1234 等，全部 up=1，cluster 标签注入生效；表里没有 kingbase_node_exporter 的行，drop 生效。三项预期全部落地。

七、注意事项

改 prometheus.yaml 的铁律：厂家模板前 42 行不动，扩展只追加尾部。这个文件不是普通 Prometheus 配置，每次启动都有脚本按行号重写它。

restart 是先杀后起，配置坏了本地监控就断档。改前备份，失败先回滚再排查。
修好的文件 scp 覆盖后记得 chown kmonitor:kmonitor，属主不对服务可能起不来。
遗留一个覆盖缺口待核对：KMonitor file_sd 里的金仓主机是 10.202.17.116/.117:1234 这批，dyck 线 db-kes Endpoints 是 10.202.17.42/.43:9200，两批 IP 对不上。drop node job 之后，如果 .116/.117 这批主机 dyck 线也没采（要翻其他 szzx Endpoints 确认），它们的节点指标在 VM 里就是空白。核对动作：服务器上 cat node_exporter_*.json 看目标清单，缺的往 dyck 线补 Endpoints。
金仓自身的告警目前仍走 KMonitor 本地规则加本地 AM，两套告警出口并存。哪天要收编到 vmalert，守老铁律：先下线本地规则再上 VMRule，防双发。
下次这台机器重装或厂家重配，直接取仓库的 prometheus/17.23-kmonitor/prometheus.yaml，别手工改现场文件。

八、参考资料

仓库 victoriametrics/README.md（VM 统一监控架构）
笔记《Prometheus 切换到 VictoriaMetrics 统一告警的部署记录》（同一套 vmauth 入口的由来）：https://mp.weixin.qq.com/s/8wqgJfIpgoZtL3D9LXtm3g
Prometheus 官方文档 remote_write 与 write_relabel_configs：https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write