前言：最近有同事反应有的接口响应时间时快时慢，经过排查有的数据层响应时间过长，为了加快定位定位慢sql的准确性，决定简单地搭建一个慢sql报警系统
具体流程如下架构图
第一步：记录日志
每个业务系统都会在都会有自己的查询语句，所有的sql语句最红都会 我们先开启每个mysql的慢sql采集配置
1.将 slow_query_log 全局变量设置为“ON”状态
mysql> set global slow_query_log=‘ON‘;
2.设置慢查询日志存放的位置
3.mysql> set global slow_query_log_file=‘/usr/local/mysql/data/slow.log‘;
设置慢sql的时间
mysql> set global long_query_time=1;
测试一下
select sleep(3);去第二步设置的路径找到日志文件，打开日志发现会有一条记录
第二步:采集日志
当记录下所有的日志文件的之后，我们就需要采集，和传统的ELK那套模式一致，用filebeat去搜集（filebeat采集的原理就不多说介绍了），采集完成后就统一传输到logstash
第三步:格式化数据
当logstash得到这些数据之后，需要格式化Elasticsearch需要的格式
注意：我们采集到日志格式中无法区分sql类型，比如select * from user where userId=2 和 select * from user where userId=5 是同一种类型，但是原始日志采集过来的数据无法判断，我们需要特殊处理一下：
1：用正则表达式把所有 数字和引号“”里面的内容都替换成？，
2：然后把返回的值用加密算法加密一下，得到一个新的字段
改字段就可以表明是某种类型的sql
第四步:分析和展示数据
Elasticsearch得到logstash传来的数据之后，就可以来检索了（sql_for_hash字段就行用来判别sql类型的字段）
第五步：报警功能
以上四步基本完成了mysql慢sql的采集分析过程，接下里就是报警功能，采用每小时（可以更短）去扫描es的中数据，根据日志中出现的查询时间以及每小时出现的次数决定报警级别，调用消息中心的报警接口进行报警，这样开发员人能够实时地接收到慢sql的出现的情况以便及时排除解决问题(后台也写了一个简单的统计页面方便查看)
