从零到一：sql_exporter实战指南

1. 为什么需要sql_exporter？

第一次接触数据库监控时，我盯着MySQL里每天增长的订单数据发愁。领导要实时看到注册用户数、异常订单率，难道要我每天手动跑SQL导出Excel？直到发现sql_exporter这个神器，才明白原来数据库监控可以这么简单。

sql_exporter本质上是个"翻译官"，它把数据库里的业务数据转换成Prometheus能理解的指标格式。比如你把用户表里count(*)的结果变成user_count指标，把订单金额sum()变成order_amount_total。这样就能用Grafana做酷炫的实时看板，或者设置"当日注册用户<1000"这样的告警规则。

适合三类人使用：

• 运维同学：不想为每个业务需求写定制化监控脚本
• 开发同学：需要暴露服务内部的关键业务指标
• 数据分析师：希望自动化获取日报数据源

我见过最聪明的用法，是用它监控电商大促期间的库存变化。通过实时追踪inventory_remaining指标，运营能第一时间发现爆款商品库存见底。

2. 环境准备与安装

2.1 硬件与软件要求

虽然sql_exporter用Go编写相当轻量，但根据我的踩坑经验，建议准备：

• 测试环境：1核CPU/1GB内存足够（实测每秒20次查询无压力）
• 生产环境：2核CPU/2GB内存（建议限制最大连接数避免拖垮数据库）
• 兼容性方面，我实测过这些组合：
  • MySQL 5.7/8.0 + Prometheus 2.30
  • PostgreSQL 12 + VictoriaMetrics
  • SQLite3 + Grafana Cloud

注意：Oracle数据库需要单独安装OCI驱动，Windows系统建议用Docker运行

2.2 三种安装方式对比

方法一：直接下载二进制文件（推荐新手）

# Linux系统 wget https://github.com/free/sql_exporter/releases/download/0.5/sql_exporter-0.5.linux-amd64.tar.gz tar -zxvf sql_exporter-*.tar.gz && cd sql_exporter-* # Mac系统用这个 wget https://github.com/free/sql_exporter/releases/download/0.5/sql_exporter-0.5.darwin-amd64.tar.gz

方法二：Docker运行（适合生产环境）

docker run -d \ -p 9089:9089 \ -v /path/to/config:/config \ ghcr.io/free/sql_exporter:latest

方法三：源码编译（需要Go环境）

git clone https://github.com/free/sql_exporter.git cd sql_exporter make build

个人建议从二进制包开始，我在早期用Docker时遇到过权限问题，二进制文件直接./sql_exporter就能跑起来。

3. 配置文件深度解析

3.1 主配置文件拆解

先看一个我优化过的sql_exporter.yml示例：

global: scrape_timeout: 8s # 必须比Prometheus的scrape_timeout短 scrape_timeout_offset: 1s # 安全缓冲时间 min_interval: 30s # 避免高频查询打满数据库CPU max_connections: 5 # 根据数据库连接池调整 max_idle_connections: 2 target: data_source_name: "mysql://monitor:Passw0rd@tcp(db-prod:3306)/order_db?charset=utf8mb4" collectors: [user_metrics, order_stats] collector_files: - "/etc/sql_exporter/collectors/*.yml"

关键参数经验：

• scrape_timeout：如果Prometheus设了10s超时，这里建议8s
• min_interval：业务指标通常30s-1分钟足够，财务类关键数据可以设15s
• 连接数配置要根据数据库负载调整，曾经因为max_connections=10把测试库拖垮

3.2 指标收集器实战

在collectors目录下，我们创建两个业务指标文件：

用户指标(user_metrics.yml)

collector_name: user_metrics metrics: - metric_name: active_users_today type: gauge help: "当日活跃用户数" values: [cnt] query: > SELECT COUNT(DISTINCT user_id) AS cnt FROM user_activity WHERE last_active_time > CURRENT_DATE()

订单指标(order_stats.yml)

collector_name: order_stats metrics: - metric_name: order_amount_by_status type: counter help: "各状态订单总金额" key_labels: [status] values: [amount] query: > SELECT status, SUM(amount) AS amount FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY status

几个实用技巧：

1. 用>代替|可以避免SQL中的换行问题
2. 关键业务指标建议添加WHERE时间限制
3. 金额类指标用counter类型可以自动处理重置问题

4. 部署与验证

4.1 启动服务的正确姿势

生产环境推荐用systemd管理：

# /etc/systemd/system/sql_exporter.service [Unit] Description=SQL Exporter After=network.target [Service] User=monitor ExecStart=/opt/sql_exporter/sql_exporter \ --config.file=/etc/sql_exporter/sql_exporter.yml \ --web.listen-address="0.0.0.0:9089" \ --log.level=info [Install] WantedBy=multi-user.target

启动后检查日志的小技巧：

journalctl -u sql_exporter -f # 实时查看日志 curl -s localhost:9089/metrics | grep -v '#' # 快速检查指标

4.2 Prometheus集成示例

在prometheus.yml中添加：

scrape_configs: - job_name: 'sql_exporter' scrape_interval: 30s static_configs: - targets: ['sql-exporter:9089'] relabel_configs: - source_labels: [__address__] target_label: instance replacement: "订单数据库监控"

常见问题排查：

1. 如果看到context deadline exceeded错误，检查scrape_timeout设置
2. no metrics collected可能是SQL语法错误，先用客户端工具测试SQL
3. 指标消失可能是数据库连接断开，检查max_idle_connections

5. 高级技巧与优化

5.1 性能优化方案

在大数据量场景下，我总结出这些优化手段：

查询优化

-- 原始慢查询 SELECT * FROM orders WHERE create_time > DATE_SUB(NOW(), INTERVAL 7 DAY) -- 优化后（使用索引字段） SELECT COUNT(*) FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-01-02'

配置优化

# 分批查询大数据表 metrics: - metric_name: large_table_stats query: > SELECT column, COUNT(*) FROM huge_table WHERE id BETWEEN ? AND ? params: [["1","100000"], ["100001","200000"]] # 自动分片查询

5.2 监控指标设计规范

根据Google SRE经验，建议遵循这些原则：

1. 黄金指标：

   • 请求量（如user_login_attempts）
   • 错误率（如order_failed_ratio）
   • 持续时间（如payment_processing_time）

2. 业务指标：

   - metric_name: shopping_cart_conversion type: gauge help: "购物车转化率" query: > SELECT COUNT(CASE WHEN status='paid' THEN 1 END)/COUNT(*) AS rate FROM shopping_carts

3. 避免的陷阱：

   • 不要监控会频繁清零的计数器
   • 避免过于细粒度的标签（如user_id）
   • 警惕指标基数爆炸（用rate()处理高频变更）

6. 真实业务场景案例

6.1 电商大屏监控

这是我们在双11使用的配置片段：

- metric_name: realtime_gmv type: counter help: "实时成交金额" values: [amount] query: > SELECT SUM(actual_payment) AS amount FROM orders WHERE pay_time >= UNIX_TIMESTAMP(CURRENT_DATE()) - metric_name: hot_items_top10 type: gauge help: "热销商品TOP10" key_labels: [item_name] values: [sales] query: > SELECT name AS item_name, COUNT(*) AS sales FROM order_items GROUP BY name ORDER BY sales DESC LIMIT 10

配合Grafana的Stat面板和BarGauge，可以做出实时更新的战报大屏。

6.2 异常检测配置

通过Prometheus的告警规则：

groups: - name: business.rules rules: - alert: HighFailureRate expr: | rate(order_status_failed[5m]) > 0.05 for: 10m labels: severity: critical annotations: summary: "订单失败率超过5% (当前值: {{ $value }})"

这套配置帮助我们提前发现了支付通道异常，避免了大规模客诉。关键是要用rate()函数处理计数器，而不是直接使用原始值。