Prometheus 自定义导出器构建器

解决什么问题

prom/prometheus 和官方 exporter 覆盖的是进程、节点、中间件这类通用指标，它们回答的是「这台机器/这个容器还活着吗」。当你想知道自己应用的业务语义——订单创建耗时分布、某类任务的积压深度、按租户维度划分的队列长度——默认指标往往要么不存在，要么粒度太粗，只能去看日志和 APM。

更麻烦的是指标建模本身：把一个会增长的值塞进 gauge、把一个单调递增的累计值放进 counter、给请求延迟随手设几个固定桶，都会让后续的 rate()、histogram_quantile() 算出看似合理但实际误导的曲线。排查这类问题时，经常要翻回 SDK 文档去确认 CounterVec 的标签顺序和 observe() 的调用时机。

技能如何工作

该技能围绕两个官方客户端组织构建过程，输出可直接接入现有 Prometheus 抓取链路的导出器：

• Python 路线：基于 prometheus_client SDK，适合已经在 Python 服务里做埋点的场景，可直接复用进程内已有的运行时状态。
• Go 路线：基于 client_golang 库，适合高吞吐服务，通过 promhttp.Handler() 暴露 /metrics。

在指标定义层面，它按三类信号分别处理：

1. counter 与标签：为累计值设计标签集（如 handler、status、method），并通过 CounterVec 在请求路径上做 labels(...).inc()。
2. histogram 与分桶：为延迟、大小这类分布型指标设置合理的 bucket 边界，而不是用默认的一串数字凑数；分桶决定了 histogram_quantile() 能否算出可信的 p95/p99。
3. gauge 仪表化：把当前值、在途请求数、队列深度这类可上可下的状态暴露为 gauge，并明确谁在何时调用 set()。

适用边界与注意点

• 它负责的是导出器的构建与指标建模，不替代 Prometheus server 的部署、配置和长期存储方案。
• 分桶要结合实际观测范围设定。桶边界太稀疏会让直方图退化成「非空即满」，太密则会让基数失控，在抓取端和存储端都付出代价。
• 标签基数是最容易被低估的坑：不要把用户 ID、订单号、IP 这类高基数值放进 label，cardinality 膨胀会拖垮服务端。
• counter 的单调性假设意味着它不能用于会被重置的量（比如每秒请求数这种应换算成 rate 的原始累计值，而非直接暴露瞬时值）。
• 抓取路径与端口要纳入既有的服务发现与网络策略，导出器本身只负责「提供指标」，不负责「被发现」。