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 不支持配置的热加载,修改起来比较麻烦。

你可能感兴趣的:(MySQL,数据库)