除了通常的系统统计信息(i/o、ram 使用情况、cpu、负载等),我目前正在收集问题、qps、运行查询和缓冲池命中。
我觉得qps很没用,因为我们的生产服务器正常运行时间非常长,而且是平均值。
我想知道mysql 生产服务器的统计信息收集的最佳实践。我还应该收集/监控哪些其他统计数据以了解服务器上的负载并迅速采取行动而不对其施加更多压力?
编辑 :
我不是在寻找第 3 方解决方案,我已经在使用 zabbix(以及创建手写脚本的能力)来收集统计信息/监控我们的 mysql 集群。在此链接中有可能收集的统计数据列表。当然还有一些统计信息没有在这里列出,可以通过 shell 脚本收集。真正的问题是必须收集哪些统计信息才能有效地监控我们的集群,而不会产生充满统计信息的不必要的垃圾。
示例:我们Qcache_hit / Qcache_hit + queries是否应该获取ratio 以查看我们的表是否足够热?
尽可能频繁地监控一切。我强烈推荐Graphite w/ statsd作为收集所有指标的中心位置。它提供了一个非常简单的纯文本协议,可以轻松记录几乎所有指标数据,并且提供了一个 UI,可以非常轻松地将一个指标与另一个指标进行比较。在我的系统上,我收集了大量信息,其中大部分信息在某些时候被证明是无价的。这里有几个:
我编写了一个名为mysampler 的守护进程,它定期将输出发送SHOW GLOBAL STATUS到Graphite (或 csv,如果需要的话)。我们以 5 秒的间隔记录此信息,但有时我希望将其设置为 1 秒的间隔。您开始在该粒度级别上看到一些非常有趣的模式。它知道哪些统计数据是计数器,哪些是绝对值(Questions 是计数器,Threads_running 是绝对值),并将输出计数器的增量。
ab-tblstats2g每晚从 cron 运行并将表大小统计数据发送到 Graphite,以便我们可以跟踪表的增长。我计划在不久的将来将其扩展为包括最大主键值和行数(来自表统计信息)。它还可以与 MSSQL Server 配合使用。
mysql_logger每 X 时间间隔将 SHOW FULL PROCESSLIST 的输出记录到 syslog。当出现奇怪的情况(表锁、长时间运行的查询等)时,准确找出并发运行的内容变得很简单。我们将这些数据转储到Splunk中以便于搜索,但有时我仍然只是在 syslog 日志中使用 grep。
Percona 工具包中的pt-stalk非常适合“刚刚发生了什么?” 场景。它监视服务器状态变量超过某个值(Threads_connected默认情况下> 25,但Threads_running根据我的经验,通常是一个更有价值的指标),并在触发时收集大量有关 MySQL 和系统的数据,可以使用pt-sift进行查看或者仅查看生成的文件。它甚至会生成 tcpdump、gdb、oprofile 和 strace 跟踪。
这基本上就是我们监控的内容,它与警报不同。对于警报,我建议您对极少数指标发出警报。只需选择具有工作负载代表性的查询并设置返回所需时间的阈值,即可覆盖 90% 的情况。如果超过该阈值,则发出警报...存在问题。否则,你就没事了。无需检查“进程是否正在运行”或类似的内容。其他需要查找的内容包括 MySQL 错误日志中的条目、接近过多的连接以及复制的运行情况(从属滞后、从属运行、表同步)。命中率对于警报目的完全没有用处 - 重要的是查询在一段时间内返回。
如需进一步阅读,Percona 人员撰写的《预防 MySQL 紧急情况》白皮书是一本不错的读物,其中详细介绍了监视和警报的内容。Percona 还发布了一组您可以使用的Nagios 插件(我相信它应该与 Zabbix 一起使用)。
| 归档时间: |
|
| 查看次数: |
5608 次 |
| 最近记录: |