MySQL 慢日志解析推送

背景

之前有用 pt-query-digest 做的慢日志分析的方案，定期将所有机器的慢日志的收集起来，传到中心机上用 pt-query-digest 分析一遍，最后展示出来。

• 基于 pt 分析展示的结果比较详细，有 SQL 排行，占比等，但是用户体验不是特别好，不能一目了然。

• 该功能本来是可以给开发看的，但是很少有开发会去看，每次有慢查询需要和开发配合进行修改或者调整的时候，开发都会问我们要具体的 SQL，比较麻烦。

• 因为每个人维护的端口实例数比较多，并且每次监控报出来的跟慢日志有关的往往是比较严重的问题，像隐式转化这种，如果对实例影响不是很严重，平时也发现不了。

基于以上原因，借助 ELK ，搞了个慢日志实时分析的方案，并且在 kibana 上配好一些图表后即可交给开发看，每次有新 SQL 上线后可以根据慢日志信息的实时展示及时发现问题。

方案确定

首先在网上搜了下关于慢日志分析展示的方案，除了用 pt 工具外，还有用 logstash 进行正则匹配的，正好那会日志分析处理比较热门，ELK 就是其中之一，并且部门其他同事已经搭建好了 ELK 服务，也正好可以用起来。

搭建

• 下载 logstash-all-plugins-2.1.0。好处是不用自己装插件了，直接能用。

• 写好配置文件。 logstash 启动的时候会按照配置文件中的设置和规则进行解析和过滤。

• nohup bin/logstash -f xxx.cnf > /dev/null 2>&1 & 即可在后台运行。

• 可以写个简单的监控来查看 logstash 进程是否存活，以及重启。

配置文件

主要是 MySQL 慢日志的解析正则，参考了网上的，但没有一个是能正确匹配的，只好自己再加工了。 里面有些字段可以不要，有些匹配失败的还可以过滤掉，并不是很完善，但是能用。

input {
  file { 
    path => "/data1/mysql*/slow.log"
    type => "slow-log"
    codec => multiline {
      pattern => "^# User@Host:"
      negate => true
      what => previous
    }
  }
}

filter {

  grok {
    match => { "message" => "# User@Host: (?[a-zA-Z0-9._-]*)\[(?:.*)\]\s+@\s+(?\S*)\s+\[%{IP:client-ip}*\]\s.*# Query_time: %{NUMBER:query_time:float}\s+Lock_time: %{NUMBER:lock_time:float}\s+Rows_sent: %{NUMBER:rows_sent:int}\s+Rows_examined: %{NUMBER:rows_examined:int}\s.*(?use \S*)?.*SET timestamp=%{NUMBER:ts};\s+(?(?\w+)\s+.*)\s+#?\s*.*" }
  }
  grok {
    match => { "path" => "/data1/mysql%{NUMBER:port:int}/slow.log" }
  }
}

output {

  elasticsearch {
    hosts => ["x.x.x.x"]
    index => "%{type}-%{+YYYY.MM.dd}"
    document_type => "%{type}"
  }

}

部署

目前线上部署了 860 台左右机器的 logstash，每台机器跑 3-4 个 MySQL 实例，总共 2500-3400 个 MySQL 实例。 大部分实例没有慢查（小于 1s 的），小部分有的也很明显，能直观的从 kibana 界面中看出来。 如图，还解决了好几个隐式转换的问题。

问题

缺点也很明显，logstash 占用资源比较多，并且 2.1 版本的 logstash 不支持配置的热加载，修改起来比较麻烦。