Prometheus 监控系统的健康检查与自监控实现-linux运维-PHP中文网

prometheus自身具备自监控能力，通过/metrics接口暴露全部内部指标，只需在prometheus.yml中配置job_name: "prometheus"抓取localhost:9090即可实现；关键指标如prometheus_target_sync_length_seconds、prometheus_tsdb_head_series等用于健康判断，kubernetes中可结合/-/readyz做就绪探针。

prometheus 监控系统的健康检查与自监控实现

Prometheus 本身具备完善的自监控能力，其所有内部指标都通过 /metrics 接口暴露，只需将其自身纳入采集目标，就能实现对监控系统自身的健康检查与运行状态追踪。

启用 Prometheus 自身的指标采集

Prometheus 默认就将自己作为第一个 scrape target（即 localhost:9090/metrics），只要配置中没有显式禁用或覆盖 scrape_configs 中的 job_name: "prometheus"，该采集就会生效。确认方法是访问 http://<prometheus-host>:9090/targets</prometheus-host>，查看 prometheus job 下的目标是否为 UP 状态。

若未启用，可在 prometheus.yml 的 scrape_configs 中添加标准配置：

scrape_configs:<br>  - job_name: "prometheus"<br>    static_configs:<br>      - targets: ["localhost:9090"]

有道智云AI开放平台

下载

注意：如果 Prometheus 运行在容器或远程节点上，“localhost”需替换为实际可访问的地址（如宿主机 IP 或服务名）
重启 Prometheus 后，可通过查询 up{job="prometheus"} 验证目标是否在线

关键自监控指标与健康判断逻辑

以下指标直接反映 Prometheus 核心组件的运行状况，建议配置告警和看板：

prometheus_target_sync_length_seconds：抓取同步耗时，持续高于 1s 可能预示性能瓶颈或网络延迟
prometheus_tsdb_head_series：当前内存中时间序列数，突增可能意味标签爆炸或采集配置异常
prometheus_tsdb_storage_blocks_bytes：持久化 block 占用磁盘空间，配合 rate(prometheus_tsdb_head_truncate_failures_total[1h]) 可识别存储写入问题
prometheus_notifications_alertmanagers_discovered：发现的 Alertmanager 数量，为 0 表示通知链中断
process_resident_memory_bytes 和 go_memstats_heap_inuse_bytes：内存使用趋势，结合 GC 频率（go_gc_duration_seconds_count）判断是否内存泄漏

构建轻量级健康检查端点（/health）

Prometheus 原生不提供 HTTP 健康检查接口（如 /health），但可通过简单方式补充：

使用 node_exporter 的 textfile 收集器 + 定时脚本，定期写入 prometheus_health_status 1（成功）或 0（失败）
更推荐方式：部署一个反向代理（如 nginx），对 /health 路径做健康探测——例如转发请求到 /api/v1/status/config 并检查 HTTP 200 + JSON 解析成功
Kubernetes 环境下，可直接使用 readiness probe 调用 /-/readyz（Prometheus v2.35+ 支持）或 /api/v1/status/runtimeinfo

避免自监控盲区的实践要点

自监控容易忽略的几个关键点：

Alertmanager 未被 Prometheus 监控：必须单独配置 job_name: "alertmanager" 抓取其 /metrics，否则告警发送失败无法感知
服务发现组件（如 Consul、Kubernetes SD）本身故障会导致 target 失联，但 Prometheus 进程仍 UP —— 需监控 prometheus_sd_discovered_targets 变化趋势
远程写（remote_write）失败不会影响本地采集，但数据已丢失，应关注 prometheus_remote_storage_queue_length 和 prometheus_remote_storage_failed_samples_total
rule evaluation 耗时过长会阻塞后续 rule 执行，用 prometheus_rule_evaluation_duration_seconds 的 99 分位判断是否异常