介绍
本文是一个使用ELK来监控mysql的介绍,基本监控了一些关键指标,当然根据业务的不同,可能有不同的指标需求,但使用该方法监控,原理不会变化,非常适合入门。
ELK是一个非常强大的软件组合,在github上有开源,star数大的惊人,感兴趣的朋友可以了解下,这套工具学习曲线比较陡峭,推荐使用本文提到的mysqlbeat这类简单的工具作为采集工具开始,一开始先不使用官方提供的beat,一方面是因为默认的配置什么数据都上报,浪费存储空间,另一方面复杂的嵌套表结构(document)更增加了学习难度,更具体的原因后面还会提及。而本文涉及到的表结构(document)只有一层,说不定你输入一个key:value,例如INNODB_PAGE_SIZE:16384,就把pagesize为16KB的记录全部列出来了。但这并不意味着你不会掉到坑里去,学好这套工具还是需要大量的学习和摸索,其实ELK的难点在于ES,建议可以读一下它的原版教程ElasticSearch权威指南。
监控工具
mysqlbeat
mysqlbeat是一个高度可定制的mysql监控agent,通过查询information_schema.global_status中部分字段,并上报到ElasticSearch进行存储,并通过Kibana进行可视化展示。代码量少,建议阅读,github地址。
数据上报
安装后主要对/etc/mysqlbeat/mysqlbeat.yml文件进行配置(不同平台上路径可能有差异),有以下设置项:
mysqlbeat:配置mysql账号,上报间隔,查询语句等 output:ElasticSearch集群的地址(也可以输出到logstash),可以同时设多个,例如:hosts: ["192.168.1.1:9200", "192.168.1.2:9200"] template:ElasticSearch mapping模板路径,默认为/etc/mysqlbeat/mysqlbeat.template.json,定义了文档字段(初学者可以理解为关系数据库的表结构),如果你偶尔要添加或修改字段,请设置overwrite: true字段,同时需要在Kibana界面reload一下该模板 配置中最重要的是queries字段,定义了一系列SQL语句,mysqlbeat通过执行这些语句,会生成一张表,这张表就是你要监控的数据,它只有两个字段VARIABLE_NAME和VARIABLE_VALUE,分别代表你要监控的监测名和监测值,其中value有两种类型
第一种是差值类型,因为global status中的一些数据是不断累加的,所以要得到1s内的数据,需要用当前时间取到的值减去前一个间隔取到的值,然后除以间隔的秒数,当然这些都不需要你来完成,你只需要在监测名后面加一个后缀__DELTA即可:CONCAT(VARIABLE_NAME, '__DELTA') 第二种是像内存值这样的不需要进行差值操作的类型。 总之使用很简单,看一下配置,然后马上就try吧
数据展示
使用这个工具导出的数据很容易配置可视化,我目前使用的是标配Kibana作为UI,下图是mysqlbeat可视化配置和官方beat可视化配置的一个对比
用ElasticSearch监控MySQL 对比左图X轴是时间轴,Y轴是QPS的平均值,非常清晰明了。再看右图,我只展示了X轴,X轴是一个外部是时间轴,内部还嵌套了一个过滤器,这个效果却是对垂直空间做了划分,对于初学者来说非常不直观,可以想象当初我为了实现这个展示是花了很多时间去摸索的,即便如此,也不能否认ElasticSearch本身非常强大的事实。
监控指标
QPS和TPS
用ElasticSearch监控MySQL QPS and TPSqps是每秒的查询数,即information_schema.global_status中的QUESTIONS字段 tps是每秒的事务数,是information_schema.global_status中COM_ROLLBACK和COM_COMMIT之和连接
用ElasticSearch监控MySQL 连接使用数据库的时候会出现"mysql connection error"的错误,一般有两个原因
连接数到达配置的最大值 内存或线程不足(每个连接对应一个线程) 所以需要设置如下几个监控
THREADS_CONNECTED:当前连接数,对照MAX_CONNECTIONS,如超过总连接的80%,或陡然突增的情况,需要设置报警 ABORTED_CONNECTS:表示存在服务器拒绝client连接的情况,此时下面两个指标中的一种或两种会增长 CONNECTION_ERRORS_MAX_CONNECTIONS:连接失败是因为当前连接超过最大连接数 CONNECTION_ERRORS_INTERNAL:主要用于排查连接失败是因为内存或线程不足造成的参数 缓存
用ElasticSearch监控MySQL 缓存缓存在互联网时代的重要性不可估量,主流的两个数据库引擎InnoDB和MyISAM的缓存作用有所区别,前者的缓存包括了索引和实际数据,而MyISAM仅缓存了索引,它把数据缓存交给了操作系统,在这里我们的监控原理一样,只是字段有差别:
监控缓存使用率 监控缓存命中情况 缓存使用情况需要两个参数,缓存使用大小和缓存总大小
MyISAM:KEY_BLOCKED_USED / (KEY_BLOCKED_UNUSED + KEY_BLOCKED_USED) InnoDB:INNODB_BUFFER_POOL_PAGES_DATA / (INNODB_BUFFER_POOL_PAGES_FREE + INNODB_BUFFER_POOL_PAGES_DATA) 同样,缓存命中情况也只需要缓存访问量和磁盘访问量两个参数,这一组字段不好记,记住读缓存次数的变量名比读磁盘次数的变量名多个requests后缀就好了。
MyISAM:读命中 KEY_READ_REQUESTS / (KEY_READS + KEY_READ_REQUESTS);写命中 KEY_WRITE_REQUESTS / (KEY_WRITE_REQUESTS + KEY_WRITES) InnoDB:缓存命中 INNODB_BUFFER_POOL_READ_REQUESTS / (INNODB_BUFFER_POOL_READ_REQUESTS + INNODB_BUFFER_POOL_READS) 需要注意的是,缓存的读/写命中率应该以最近一段时间(比如10s)为基准(作者取的是累积值),这样数据更真实,而基数太大会把数据压得更平滑,不利于监测突发情况。
TODO
主从同步延迟,其实mysqlbeat已经实现了,只是老是出现类型冲突,所以就无法可视化,需要查代码定位 mysql错误,这种以表格的形式展示更好,对错误语句、原因根据错误次数倒序展示 最慢的mysql语句,同样是以表格形式展示 报警,使用ElastAlert的spike rule监控陡然增减的情况、frequency rule设置阈值,出现这些情况进行报警 latency,这种优先级比较低,一般上层接口的监控latency即可,因为一般情况下,mysql都是瓶颈。