exporter是prometheus生态中将各类系统指标采集并转换为标准时间序列格式的适配组件，分为官方与第三方、直接采集型与间接采集型，其核心作用是数据转换与/metrics端点暴露。
选对 Exporter，监控就完成了一半。Prometheus 本身不直接采集各类服务的指标，它依赖 Exporter 做“适配翻译”——把不同系统、协议、格式的数据，统一转成 Prometheus 能理解的时间序列。选型不是堆功能，而是看场景匹配度、维护活跃度、指标覆盖深度和部署轻量性。
基础设施层：从物理机到云主机
这是监控的底座，必须稳定、低开销、覆盖全。
-
Linux 主机：首选
node_exporter。官方维护、资源占用极低（通常＜5MB内存），支持 CPU、内存、磁盘 I/O、网络、文件系统、硬件传感器等超 200 项指标。无需额外依赖，下载二进制即启，/metrics 端点开箱即用。 -
Windows 主机：用
windows_exporter（不是 node_exporter 的 Windows 版）。它专为 Windows 设计，能采集服务状态、性能计数器（如 .NET CLR、SQL Server）、事件日志、WMI 指标等，端口默认 9182。 -
硬件健康（如 Dell/HP 服务器）：搭配
snmp_exporter+ iDRAC/iLO 的 SNMP 配置。它不依赖 Agent，纯协议通信，可获取风扇转速、温度、电源状态、RAID 健康等底层信息，适合与容器监控统一告警。
中间件与数据库层：按协议和生态选
这类 Exporter 的核心是“贴合原生指标体系”，避免漏关键瓶颈点。
-
MySQL：用
mysqld_exporter。支持连接池、慢查询、复制延迟、InnoDB 缓冲池、锁等待等 DBA 关心的指标。需创建专用监控账号并授权PROCESS, REPLICATION CLIENT, SELECT权限。 -
Redis：推荐
redis_exporter。能自动发现集群模式节点，暴露内存碎片率、键过期率、命令延迟分布（histogram）、客户端连接数等，比单纯看内存更准。 -
MongoDB：官方
mongodb_exporter或社区成熟版本。支持分片集群、副本集自动发现，关键指标包括 opcounters、queue 长度、repl lag、connpool 状态。云数据库（如腾讯云 MongoDB）建议优先走平台集成通道，省去自建运维。 -
Kafka：
kafka_exporter是主流选择。重点采集 consumer group lag、topic 分区偏移、broker 请求队列、网络延迟，这对保障消息实时性至关重要。
应用与运行时层：语言和框架决定路径
这里不能只看“有没有”，要看“能不能反映真实业务水位”。
-
Java 应用：优先
jmx_exporter。它直连 JMX，把 JVM 内存堆/非堆、GC 次数与耗时、线程状态、以及业务自定义 MBean 全部暴露为 Prometheus 指标。比 Spring Boot Actuator 的 /actuator/prometheus 更底层、更全面。 -
Go 应用：天然支持 Prometheus。只要引入
prometheus/client_golang包，几行代码就能注册 HTTP /metrics 端点，无需额外 Exporter。 -
容器环境：
cadvisor是事实标准。它嵌入在 kubelet 中或独立部署，采集容器级 CPU/内存/网络/存储使用，还能识别镜像、重启次数、OOM 事件，是 Kubernetes 监控基石。
网络与可用性层：模拟真实用户视角
这类 Exporter 不看内部状态，只问“能不能访问”“快不快”。
-
黑盒探测：
blackbox_exporter必选。支持 HTTP(S)、DNS、ICMP、TCP、SSL 证书过期检测。可配置多探针、自定义 HTTP 头、响应体关键字校验，适合监控官网、API 网关、第三方依赖服务。 - API 健康检查：对关键业务接口，可在应用内实现 /health 端点，并用 blackbox_exporter 的 http_probe 模块抓取 status_code 和响应时间，比 ping 更贴近业务逻辑。
