正文

小公司用Prometheus Grafana实现MySQL性能监控大屏大厂的PMMA慢查询分析实战与工具选型避坑指南

/0 浏览量
0926

说实话，看到标题里这一长串词，我都能想象到你现在的头秃程度。小公司资源有限，想搞大厂那套专业的性能监控，但一看文档就头大，买商业软件又心疼预算。别急，咱们今天就把这套“Prometheus + Grafana + PMMA”的组合拳拆开来揉碎了讲。这不是什么高深的学术论文，而是一个刚帮一家50人左右的电商公司搭完监控系统的老兵，跟你唠唠怎么不花冤枉钱，把MySQL这头“吞金兽”喂明白。

一、 为什么是这套组合拳？先聊聊小公司的痛点

在大厂，你有专门的SRE团队，有内部的APM系统，数据链路清清楚楚。但在小公司，情况往往是这样的：

  1. 报警滞后：线上卡了，用户骂娘了，你才知道数据库出问题了。
  2. 排查靠猜：出了性能问题，第一反应是“重启试试”，而不是看数据。
  3. 慢查询没人管：开发人员写SQL随手就来，缺乏有效的分析和约束机制。
  4. 大屏是面子，也是里子：老板要看数据，客户要看稳定性，你得有个像样的展示界面。

Prometheus + Grafana 是目前云原生监控的事实标准，开源免费，社区活跃。而 PMMA（MySQL Monitoring and Analysis）则是国内很多大厂（比如美团、滴滴等）内部常用的慢查询分析和性能管理工具。将两者结合，既能实现实时的性能指标监控大屏，又能深入分析慢查询根因，是小公司实现“大厂级”监控的高性价比方案。

二、 核心组件选型与避坑指南

在动手之前，咱们得先选对工具。选型不对，后期两行泪。

1. Prometheus：指标采集的“瑞士军刀”

选型建议：直接使用官方稳定版本，比如当前最新的 2.4x 系列。不要为了追求新功能去尝鲜beta版，稳定性对小公司至关重要。

避坑指南：

  • 存储周期：Prometheus 默认是本地磁盘存储，磁盘满了就删旧数据。小公司别指望它长期存储历史数据做趋势分析。建议配合 VictoriaMetrics 或 Thanos 做长期存储和去重，或者简单点，只保留7-30天的高分辨率数据，更久的数据导出到 Prometheus 的下游（如 Loki + MySQL 或 ClickHouse）。
  • 服务发现：如果服务器是动态的（比如用K8s），务必开启自动服务发现（Service Discovery），别手动改配置文件，累死你。
  • 标签设计：标签是 Prometheus 的命门。标签值基数（Cardinality）要控制，别让一个指标有上万个标签组合，否则内存爆炸。

2. Grafana：数据展示的“魔术师”

选型建议：同样使用官方稳定版，推荐 Linux 二进制安装或 Docker 部署。

避坑指南：

  • 权限管理：早期版本权限比较弱，建议配合 Grafana Enterprise 或使用 Nginx 反向代理做简单的 IP 白名单。别让你的监控大屏随便被路人看到核心数据。
  • Dashboard 复用：别自己从零画 Panel。Grafana 社区（grafana.com/dashboards）有大量现成的 MySQL 模板，先拿来用，再根据业务调整。这是最快上手的方法。
  • 变量管理：学会用 Grafana 的 Variables（变量）。比如，当你的MySQL有多个实例时，用变量下拉选择实例，Dashboard 会自动刷新，这比你做10个重复的 Dashboard 强一万倍。

3. MySQL Exporter：连接 MySQL 和 Prometheus 的桥梁

选型建议：官方推荐的 mysqld_exporter。它是由 Prometheus 社区官方维护的，支持大部分 MySQL 5.7+ 和 8.0+ 的指标。

避坑指南：

  • 权限最小化：给 exporter 创建专用的 MySQL 用户，只授予 PROCESS, REPLICATION CLIENT, SELECT 权限。千万别用 root 账号，安全风险太大。
  • 收集范围：默认收集了几乎所有指标，可能有些不是你需要的。可以通过配置 --collect 参数来过滤，比如 --collect.info_schema.innodb_metrics，减少 Prometheus 的压力。
  • 慢日志收集：这是关键！mysqld_exporter 本身不直接收集慢查询日志。它收集的是“慢查询数量”这样的计数指标。要分析具体的慢查询语句，你需要配合其他工具（比如 Percona 的 pmm-server 或者自建的日志解析服务）。

4. PMMA（或类似慢查询分析工具）：深挖慢查询的“手术刀”

这里需要澄清一点：PMMA 并不是一款单一的、广泛开源的免费软件，它更多是指一类慢查询管理分析系统的统称，或者特指某些大厂内部或商业化的解决方案（如 Percona Monitoring and Management - PMM，或者一些基于 pt-query-digest 的封装）。

对于小公司，我们有几个更实际的选择：

  • 方案A：PMM (Percona Monitoring and Management)：开源，功能强大，专门针对 MySQL。它内置了慢查询分析，可以自动抓取并解析慢日志，生成报告。推荐度：⭐⭐⭐⭐⭐
  • 方案B：pt-query-digest + 自建存储：用 Percona Toolkit 的 pt-query-digest 定期分析慢日志，将结果写入 MySQL 或 ClickHouse，再用 Grafana 展示。推荐度：⭐⭐⭐⭐
  • 方案C：Elasticsearch + Logstash + Filebeat：将慢日志实时同步到 ES，用 Kibana 或 Grafana 进行查询分析。适合日志量不大的场景。推荐度：⭐⭐⭐

避坑指南（针对PMMA/PMM类工具）：

  • 性能开销：任何慢查询分析工具，本质都是“偷看”慢日志。如果慢日志量巨大（每秒上千条），工具本身可能会成为瓶颈。务必测试工具的资源占用。
  • 误报与漏报：自动分析工具可能会把一些正常的、偶尔的慢查询当作“问题”，或者忽略一些复杂的、拼接后的SQL。人的经验依然不可替代。
  • 与 Prometheus 的集成：有些 PMMA 工具可以提供 Prometheus 格式的指标，方便统一监控。选择时优先考虑这种集成度高的。

三、 实战部署：从零搭建监控大屏

假设你有一台 Linux 服务器，MySQL 在另一台服务器上。我们用最简化的 Docker Compose 方式来部署（生产环境建议分开部署，但学习和小规模使用，Docker 足够）。

第一步：准备 MySQL Exporter

在 MySQL 服务器上，创建一个专用用户：

CREATE USER 'exporter'@'%' IDENTIFIED BY 'YourStrongPassword';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'%';
FLUSH PRIVILEGES;

然后，启动 mysqld_exporter（在 MySQL 服务器本机或监控服务器上）：

docker run -d \
  --name mysqld-exporter \
  -p 9104:9104 \
  -e DATA_SOURCE_NAME="exporter:YourStrongPassword@tcp(mysql_host:3306)/" \
  prom/mysqld-exporter

验证：访问 http://your_monitor_server:9104/metrics，应该能看到一堆以 mysqld_ 开头的指标。

第二步：部署 Prometheus

创建 prometheus.yml 配置文件：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'mysqld'
    static_configs:
      - targets: ['mysql_exporter_host:9104']
        labels:
          instance: 'mysql-primary'

  - job_name: 'node' # 可选，监控服务器本身
    static_configs:
      - targets: ['node_exporter_host:9100']

启动 Prometheus：

docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

访问 http://your_server:9090，在 Status -> Targets 里确认 mysqld job 是 UP 状态。

第三步：部署 Grafana

启动 Grafana：

docker run -d \
  --name grafana \
  -p 3000:3000 \
  -v /path/to/grafana-storage:/var/lib/grafana \
  grafana/grafana

访问 http://your_server:3000，默认账号密码 admin/admin。

添加数据源：

  1. 进入 Configuration -> Data Sources。
  2. 添加 Prometheus 数据源，URL 填 http://prometheus:9090（如果在同一网络）或服务器IP。

导入 MySQL Dashboard：

  1. 进入 Dashboards -> Import。
  2. 搜索 “MySQL” 或 “Prometheus MySQL”。
  3. 推荐一个 ID： 7362 （这是一个非常经典的 MySQL Dashboard）。
  4. 选择你的 Prometheus 数据源，点击 Import。

此刻，你应该能看到一个包含 QPS、TPS、连接数、InnoDB 缓冲池命中率、慢查询数量等指标的炫酷大屏了！

第四步：慢查询分析（引入 PMMA/PMM）

这是最关键的一步。Prometheus 只能告诉你“慢查询数量增加了”，但无法告诉你“哪条SQL慢了”。

推荐方案：使用 PMM (Percona Monitoring and Management)

PMM 是一个独立的开源平台，它可以独立于 Prometheus 运行，也可以将数据导出到 Prometheus。

  1. 部署 PMM Server： 
    
docker run -d \
  --name pmm-server \
  -p 443:443 \
  -v /opt/prometheus:/prometheus \
  -v /opt/consul:/consul \
  -v /opt/grafana:/var/lib/grafana \
  -v /opt/qa:/opt/qa \
  -v /opt/alertmanager:/alertmanager \
  -v /opt/node-exporter:/node-exporter \
  -v /opt/mysqld-exporter:/mysqld-exporter \
  -v /opt/promgen:/promgen \
  percona/pmm-server:2
  2. 注册 MySQL 服务： 在 PMM Server 的 Web UI 中，添加你的 MySQL 实例。
  3. 部署 PMM Client： 在 MySQL 服务器上安装 PMM Client，并连接 PMM Server。 
    
docker run -d \
  --name pmm-client \
  -v /var/lib/collectors/percona:/var/lib/percona \
  -v /var/run/docker.sock:/var/run/docker.sock \
  percona/pmm-client:2 \
  add mysql --user exporter --password 'YourStrongPassword' --host mysql_host --port 3306
  4. 分析慢查询： PMM 会自动采集慢日志，并在 “Query Analytics” 页面提供详细的 SQL 分析，包括执行频率、平均耗时、Scan Rows 数、锁等待时间等。你可以看到具体的 SQL 文本，并对其进行分组和排序。

四、 大屏设计与业务价值

监控大屏不只是给老板看的，更是给你自己看的。一个优秀的大屏应该包含以下模块：

  1. 核心健康度概览：

    • MySQL 实例状态（UP/DOWN）
    • 关键指标红点报警（如：连接数 > 80%，慢查询 > 10/s）
    • 总体 QPS/TPS 趋势

  2. 性能指标详情：

    • QPS/TPS：每秒查询/事务数，反映负载。
    • 连接数：当前连接、最大连接、空闲连接。
    • InnoDB 缓冲池：命中率、脏页比例、等待释放的页。
    • 磁盘 I/O：Read/Write IOPS，延迟。
    • 复制延迟：如果是主从架构，Seconds_Behind_Master 是关键。

  3. 慢查询分析（来自 PMM）：

    • Top 10 慢查询 SQL（按执行时间或次数）
    • 慢查询趋势图
    • 具体 SQL 的执行计划分析

  4. 业务关联指标（可选，高级玩法）：

    • 将数据库的 QPS 与业务指标（如订单量、用户访问量）关联，分析是否存在异常。

五、 常见坑点与解决方案

  1. 坑：Prometheus 内存暴涨

    • 原因：标签基数太高，或者收集了不必要的指标。
    • 解决：使用 promtool 检查配置，限制 scrape_timeout，过滤掉无关指标，考虑使用 Thanos 做去重和压缩。

  2. 坑：Grafana 图表加载慢

    • 原因：时间范围太大，数据点过多。
    • 解决：默认时间范围设为最近1小时或24小时，不要一进来就查一个月。使用 Grafana 的“Short Cache”设置。

  3. 坑：慢查询分析不准确

    • 原因：PMM 或 pt-query-digest 解析慢日志时，可能对某些复杂 SQL（如存储过程、动态SQL）解析失败。
    • 解决：定期手动检查慢日志，与工具分析结果对比。对于复杂SQL，使用 EXPLAIN 手动分析。

  4. 坑：报警风暴

    • 原因：配置了太多敏感阈值，或者网络抖动导致短暂报警。
    • 解决：使用 Alertmanager 进行报警聚合、静默和去重。设置合理的“持续时间”（For），比如指标持续5分钟超标才报警。

六、 结语：监控是持续优化的过程

搭建监控系统只是第一步，更重要的是建立基于数据的运维文化。定期Review慢查询，优化SQL；根据业务高峰调整监控阈值；让开发人员也能看到自己的代码对数据库的影响。

小公司用这套方案，成本几乎为零（除了人力），就能获得接近大厂的性能可见性。记住，工具是死的，人是活的。理解每个指标背后的业务含义，才能真正做到“监控驱动优化”。

希望这篇指南能帮你少走弯路。如果在实践中遇到具体问题，欢迎随时交流，毕竟，踩过的坑越多，成长越快嘛！

-- 展开阅读全文 --