Prometheus 自定义导出器：怎样扩展监控应用逻辑

Prometheus自定义导出器是业务监控逻辑的具象化表达，需明确指标类型（Gauge/Counter/Histogram）、解耦数据源、配套告警与可视化，并按部署场景选择Pushgateway/federation等适配方案。

Prometheus 自定义导出器（Exporter）不是“加功能”的插件，而是你业务监控逻辑的具象化表达。它不依赖目标系统是否原生支持指标暴露，关键在于：你能否把想看的数据，以 Prometheus 能理解的方式，通过 HTTP /metrics 端点稳定地提供出来。

明确监控目标，决定指标类型

业务场景不同，指标语义就不同，选错类型会导致查询和告警失效：

• Gauge：适合可增可减、有瞬时意义的值，比如“当前待处理订单数”“内存使用百分比”“API 当前并发连接数”
• Counter：适合只增不减的累计值，比如“今日支付成功次数”“服务启动以来错误总数”“定时任务执行完成次数”
• Histogram：适合分布类数据，比如“HTTP 请求响应时间分桶统计”“文件处理耗时分布”，能支撑 P90/P95 告警

例如监控一个批处理队列积压量，用 Gauge；统计每分钟失败重试次数，用 Counter；记录每次数据库查询耗时，用 Histogram。

让数据源与导出器解耦

导出器本身应轻量、专注暴露，不承担复杂采集逻辑：

• 若数据来自本地日志，可用脚本定时解析并写入 node_exporter 的 textfile 目录，由 textfile collector 统一拉取
• 若数据来自数据库或 API，导出器内只需做一次 HTTP 请求或 SQL 查询，避免长连接、重试、缓存等复杂封装
• 若数据来自多个目录或服务，用标签（label）区分维度，如 file_pending{dir="/data/in", type="xml"}，而非硬编码多个指标名

这样既便于调试（单独 curl 查看 /metrics），也利于横向扩展——同一份导出器代码，换配置就能监控不同环境。

集成告警与可观测性闭环

导出器上线只是第一步，必须配套规则才能产生价值：

• 在 Prometheus 中定义 alerting rule，例如：

  ALERT PendingTasksHigh<br>  IF app_pending_tasks > 100<br>  FOR 2m<br>  LABELS { severity = "warning" }<br>  ANNOTATIONS { summary = "待处理任务超阈值" }

• 在 Grafana 中新建面板，用 PromQL 直接查 app_pending_tasks 或聚合计算变化率：rate(app_pending_tasks[1h])
• 为关键指标添加 服务发现标签，如 job="order-exporter"、env="prod"，方便按环境、角色聚合筛选

指标有了、告警写了、图表画了，才算真正把业务逻辑纳入监控体系。

应对非持久化与网络受限场景

有些业务运行在临时容器、离线设备或内网环境中，无法被 Prometheus 主动拉取：

• 改用 Pushgateway：短生命周期任务（如 Cron Job）主动推送指标，注意设置 TTL 或定期清理，避免陈旧数据干扰
• 启用 cpolar/ngrok 类穿透服务：让内网导出器暴露公网端点，供远端 Prometheus 抓取，需配置白名单和基础认证
• 考虑 federation 模式：边缘 Prometheus 先采集本地导出器，再向上级联邦拉取，适合多区域、弱网络链路

这些不是“备选方案”，而是根据部署形态自然选择的技术路径。