介绍
本文是一个使用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可视化配置的一个对比
对比
左图X轴是时间轴，Y轴是QPS的平均值，非常清晰明了。再看右图，我只展示了X轴，X轴是一个外部是时间轴，内部还嵌套了一个过滤器，这个效果却是对垂直空间做了划分，对于初学者来说非常不直观，可以想象当初我为了实现这个展示是花了很多时间去摸索的，即便如此，也不能否认ElasticSearch本身非常强大的事实。
监控指标
QPS和TPS
QPS and TPS
qps是每秒的查询数，即information_schema.global_status中的QUESTIONS字段
tps是每秒的事务数，是information_schema.global_status中COM_ROLLBACK和COM_COMMIT之和连接
连接
使用数据库的时候会出现"mysql connection error"的错误，一般有两个原因
连接数到达配置的最大值
内存或线程不足（每个连接对应一个线程）
所以需要设置如下几个监控
THREADS_CONNECTED：当前连接数，对照MAX_CONNECTIONS，如超过总连接的80%，或陡然突增的情况，需要设置报警
ABORTED_CONNECTS：表示存在服务器拒绝client连接的情况，此时下面两个指标中的一种或两种会增长
CONNECTION_ERRORS_MAX_CONNECTIONS：连接失败是因为当前连接超过最大连接数
CONNECTION_ERRORS_INTERNAL：主要用于排查连接失败是因为内存或线程不足造成的参数
缓存
缓存
缓存在互联网时代的重要性不可估量，主流的两个数据库引擎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都是瓶颈。
网友评论