做监控这么多年，我见过太多“裸奔”的系统了。
很多兄弟以为装个 Node Exporter，再把 mysqld_exporter 跑起来，Grafana 随便拖几个酷炫的仪表盘，就算是“懂监控”了。结果呢？业务接口延迟飙升，你看 CPU 正常；订单量腰斩，你看内存正常。老板在群里咆哮“为什么用户投诉了我们才知道？！”，你盯着那几个毫无波澜的基础指标，手心全是冷汗。
这就是监控的“盲区”。
真正的监控高手，从来不满足于社区提供的标准品。业务逻辑只有你最懂，核心指标必须自己通过 Exporter 暴露出来！无论你是想监控一个老旧的 Java 遗留系统，还是一个自研的 Go 微服务，甚至是一个没有任何接口的物理设备，掌握 Prometheus Exporter 的开发能力，就是你从“运维民工”进阶到“SRE 专家”的分水岭。
今天这篇长文，我不讲虚头巴脑的理论，直接把自己压箱底的 10 年 Exporter 开发经验掏出来。从指标设计避坑，到 Go 语言实战，再到生产级的高性能优化，全部是真枪实弹的代码和血泪教训。
看完这篇，要是还不会写 Exporter，你来顺着网线打我！
第一部分：Prometheus生态快速入门 从Server到Exporter：理解监控的骨骼
很多新手一上来就扎进代码里，结果写出来的 Exporter 要么性能极差，要么根本连不上。我们得先搞清楚，Prometheus 到底是怎么“吸血”的。
1.1 Prometheus三大核心组件的协作关系
Prometheus 的架构其实非常简单粗暴，简单到只有三个核心角色，我把它们称为“监控铁三角”：
- Prometheus Server（大脑）：它是个不知疲倦的爬虫。它不被动接收数据，而是主动出击（Pull 模式），定期去各个目标地址“拉取”数据。
- Pushgateway（缓存站）：专门处理那些“短命”的任务。比如一个只运行 5 秒的批处理脚本，Server 还没来得及拉取它就挂了，这就需要它先把数据推给 Pushgateway。
- Exporter（翻译官）：这才是我们今天的主角！绝大多数现成的软件（如 MySQL、Redis、Linux 内核）并不会天生吐出 Prometheus 能看懂的格式。Exporter 的作用就是充当“中间人”，连接到目标应用，拿数据，转换成 Prometheus 的文本格式，然后暴露一个 HTTP 接口等着 Server 来拉。
你要记住：Exporter 本质上就是一个暴露 HTTP 接口的 Web 程序，仅此而已。
1.2 Exporter的两种运行模式：独立 vs 集成
在开发前，你必须做一个战略选择：
- 独立模式 (Independent / Sidecar)：也就是如果你要监控 MySQL，你不可能去改 MySQL 的源码。所以你得写一个独立的程序（mysqld_exporter），它去连 MySQL 的库，查数据，然后自己起一个 HTTP 端口。
- 适用场景：监控第三方中间件、黑盒系统、老旧遗留系统。
- 集成模式 (Inline / Instrumentation)：如果你在写一个 Go 语言开发的微服务，千万别傻乎乎地再写个独立 Exporter。直接在你的服务代码里引入 Prometheus SDK，开一个
/metrics接口。- 适用场景：自研应用、微服务、内部 API。
1.3 社区Exporter的现状与局限
社区里有几百个现成的 Exporter，好用吗？好用。够用吗？绝对不够！
社区的 Exporter 只能告诉你“数据库还活没活着”、“QPS 是多少”。但是，它告诉不了你：
- “今天那个大客户的订单处理失败率是不是超标了？”
- “库存同步的逻辑是不是卡在第 3 步了？”
这些业务维度的洞察，只有你自己写的 Custom Exporter 能给。
真实 Scrape Config 配置示例：
如果你写好了一个 Exporter，跑在192.168.1.100:8080，你只需要在 Prometheus 的prometheus.yml里加上这几行：
scrape_configs:-job_name:'my_custom_business_app'scrape_interval:15s# 哪怕是生产环境，15s也是个黄金标准static_configs:-targets:['192.168.1.100:8080']# 加上这个标签，以后排查问题能救命labels:env:'production'region:'shanghai'第二部分：指标设计论 三种指标类型的深度解析与应用
代码写得再溜，指标设计错了，整个监控系统就是垃圾。我见过太多人把 Gauge 当 Counter 用，最后画出来的图全是断崖式下跌，简直是灾难。
Prometheus 的指标类型，常用的就这四个，吃透它们，你就懂了一半。
2.1 Counter（计数器）：只增不减的“守财奴”
定义：Counter 是最简单的类型，它代表一种累积的指标。就像你的汽车里程表，除非你把车（程序）砸了（重启），否则它永远只会增加，不会减少。
适用场景：
- HTTP 请求总数 (
http_requests_total) - 任务完成总数 (
tasks_completed_total) - 错误发生总次数 (
errors_total)
核心逻辑：
我们在 PromQL 里查询时，从来不直接看 Counter 的绝对值（因为它一直在涨，没意义），我们只看增长率。
也就是最常用的rate()函数：rate(http_requests_total[5m])-> 这里的含义是过去 5 分钟的每秒平均请求数（QPS）。
避坑指南：永远不要用 Counter 来记录“当前在线人数”。因为人数会减少，而 Counter 只要一减少，Prometheus 就会认为发生了一次“重置”，算出来的 rate 会瞬间变成负数或巨大的异常值！
2.2 Gauge（仪表盘）：情绪波动的“心电图”
定义：Gauge 是最直观的，它可增可减，就像你的车速表，或者你银行卡里的余额。
适用场景：
- 当前内存使用率 (
memory_usage_bytes) - 当前 Goroutine 数量 (
go_goroutines) - 任务队列中积压的任务数 (
job_queue_length)
核心逻辑：
Gauge 反映的是瞬时状态。它不需要rate()，直接看值就行。
2.3 Histogram（直方图）：拒绝平均数的“照妖镜”
这是最难理解，但也最有价值的指标。
老板问你：“我们的 API 慢不慢？”
你答：“平均响应时间 200ms。”
老板满意地点头。
结果背后可能有 10% 的用户请求耗时超过 5 秒，甚至超时！平均数把这些长尾问题给“抹平”了。
Histogram 就是为了解决这个问题。它会把观测到的数据放入一个个“桶”（Bucket）里。比如：
- 小于 0.1s 的有 100 个
- 小于 0.5s 的有 500 个
- 小于 1s 的有 800 个
适用场景：
- 请求延迟（Latency）
- 响应大小（Response Size）
通过 Histogram，我们可以计算出P99（99分位值）。histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
这句话的意思是：99% 的请求都在这个时间内完成了。这才是真实的性能指标！
2.4 Summary（摘要）：客户端的“独角戏”
Summary 和 Histogram 很像，都是算分位数的。但区别在于：
- Histogram：客户端只负责分桶，P99 是服务端（Prometheus）算出来的。消耗服务端 CPU，但支持聚合（比如算 10 台机器整体的 P99）。
- Summary：客户端直接算好 P99 发给服务端。不消耗服务端 CPU，但不支持聚合（你不能把 10 台机器的 P99 加起来求平均）。
结论：除非你明确知道自己在做什么，否则90% 的场景请使用 Histogram。
高危预警：高基数标签（High Cardinality）
这是新手把生产环境搞崩的第一原因！
比如你定义了一个指标http_requests_total，然后你加了一个标签叫user_id。
假如你有 1000 万个用户。Prometheus 就要存储 1000 万条不同的时间序列。内存和磁盘会瞬间爆炸！
绝对禁止在 Label 中放入：用户 ID、订单 ID、随机 Token、邮件地址等无界数据！
2.5 指标命名规范
好的命名是成功的一半。Google SRE 推荐的命名法：
{namespace}_{subsystem}_{name}_{unit}
- Metric Name:
app_db_query_duration_seconds(清晰、带单位) - Bad Name:
db_query_time(到底是毫秒还是纳秒？是哪个 App 的？)
第三部分：Go语言实现 从理论到代码的蜕变
光说不练假把式。Go 语言是 Prometheus 的亲儿子（Prometheus 本身就是 Go 写的），所以client_golang库非常强大。
我们将通过 4 个步骤，手撸一个生产级的监控代码。
3.1 环境搭建
首先，初始化项目结构。别把所有代码都塞在main.go里，那太业余了。
mkdirmy-exportercdmy-exporter go mod init my-exporter go get github.com/prometheus/client_go)
