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 先采集本地导出器，再向上级联邦拉取，适合多区域、弱网络链路
这些不是“备选方案”，而是根据部署形态自然选择的技术路径。
