操作系统层面
cpu监控
[root@zst data]# sar -u 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:26:44 AM CPU %user %nice %system %iowait %steal %idle10:26:54 AM all 0.55 0.00 0.41 5.61 0.03 93.40
内存监控
[root@zst data]# sar -r 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:28:36 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit10:28:46 AM 223084 32658252 99.32 143468 16549080 18774068 37.81
I/O监控
[root@zst data]# sar -b 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_ (8 CPU)10:30:25 AM tps rtps wtps bread/s bwrtn/s10:30:35 AM 67.17 61.63 5.54 16169.99 86.20
系统SWAP监控
[root@zst data]# sar -w 10 3Linux 2.6.32-642.el6.x86_64 (zst) 09/22/2017 _x86_64_10:31:56 AM proc/s cswch/s10:32:06 AM 0.00 2234.44
当然，查看当前的磁盘和内存使用情况df -h，free -m，是否使用numa和swap，或是否频繁交互信息等。当然，还有其他的监控项目，这里就不一一赘述了。
除此之外，还需要关注日志类信息，例如：
1 /var/log/messages
2 /var/log/dmesg
MySQL本身
MySQL本身的监控应该包含重点参数的检查，MySQL状态的检查，除此以外还应该包含自增id的使用情况（小心因为自增id使用满了 不能insert写入从而引发报警哦），及主从健康状态的巡检。
重点参数
1 "innodb_buffer_pool_size""sync_binlog"'binlog_format''innodb_flush_log_at_trx_commit''read_only':
2 'log_slave_updates''innodb_io_capacity''query_cache_type''query_cache_size''max_connections''max_connect_errors''server_id'
MySQL的状态
例如：每秒的tps、qps，提交了多少事务、回滚了多少事务、打开文件数、打开表数、连接数、innodb buffer使用率，及锁等待等等。
首先，查看mysql状态
1 mysql> show full processlis;
2 mysql> show global status;3mysql> show engine innodb status\G
wait事件
Innodb_buffer_pool_wait_free
Innodb_log_waits
MySQL锁监控
#表锁
Table_locks_waited
Table_locks_immediate
#行锁
Innodb_row_lock_current_waits，当前等待锁的行锁数量
Innodb_row_lock_time，请求行锁总耗时
Innodb_row_lock_time_avg，请求行锁平均耗时
Innodb_row_lock_time_max，请求行锁最久耗时
Innodb_row_lock_waits，行锁发生次数
#还可以定时收集INFORMATION_SCHEMA里面的信息：
INFORMATION_SCHEMA.INNODB_LOCKS;
INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
#临时表/临时文件
Created_tmp_disk_tables/Created_tmp_files
#打开表/文件数
Open_files/Open_table_definitions/Open_tables
#并发连接数
Threads_running /Threads_created/Threads_cached
Aborted_clients
#客户端没有正确关闭连接导致客户端终止而中断的连接数
Aborted_connects
Binlog
1 Binlog_cache_disk_use
2 使用临时二进制日志缓冲但超过 binlog_cache_size 值并使用临时文件
3 Binlog_cache_use
4 使用临时二进制日志缓冲的事务数
5 Binlog_stmt_cache_disk_use
6 当非事务语句使用二进制日志缓存
7 Binlog_stmt_cache_use
8 使用二进制日志缓冲非事务语句数量
链接数
1 Connections
2 试图连接到（不管成不成功）mysql服务器的链接数
临时表
1 Created_tmp_disk_tables
2 服务器执行语句时,在硬盘上自动创建的临时表的数量,是指在排序时,内存不够用(tmp_table_size小于需要排序的结果集)，所以需要创建基于磁盘的临时表进行排序
3 Created_tmp_files
4 服务器执行语句时自动创建的内存中的临时表的数量
索引
1 Handler_commit 内部交语句
2 Handler_rollback 内部 rollback语句数量
3 Handler_read_first 索引第一条记录被读的次数,如果高,则它表明服务器正执行大量全索引扫描
4 Handler_read_key 根据索引读一行的请求数，如果较高，说明查询和表的索引正确
5 Handler_read_last 查询读索引最后一个索引键请求数
6 Handler_read_next 按照索引顺序读下一行的请求数
7 Handler_read_prev 按照索引顺序读前一行的请求数
8 Handler_read_rnd 根据固定位置读一行的请求数，如果值较高，说明可能使用了大量需要mysql扫整个表的查询或没有正确使用索引
9 Handler_read_rnd_next 在数据文件中读下一行的请求数，如果你正进行大量的表扫，该值会较高
10 Open_table_definitions
11 被缓存的.frm文件数量
12 Opened_tables
13 已经打开的表的数量,如果较大,table_open_cache值可能太小
14 Open_tables
15 当前打开的表的数量
16 Queries
17 已经发送给服务器的查询个数
18 Select_full_join
19 没有使用索引的联接的数量,如果该值不为0,你应该仔细检查表的所有
20 Select_scan
21 对第一个表进行完全扫的联接的数量
22 Slow_queries
23 查询时间超过long_query_time秒的查询个数
24 Sort_merge_passes
25 排序算法已经执行的合并的数量,如果值较大,增加sort_buffer_size大小
线程
1 Threads_cached 线程缓存内的线程数量
2 Threads_connected 当前打开的连接数量
3 Threads_created 创建用来处理连接的线程数
4 Threads_running 激活的（非睡眠状态）线程数
MySQL自增id的使用情况
1 mysql> SELECT table_schema,table_name,engine, Auto_increment
2 FROM information_schema.tables where
3 INFORMATION_SCHEMA.TABLE_SCHEMA
4 not in ("INFORMATION_SCHEMA" ,"PERFORMANCE_SCHEMA", "MYSQL", "SYS")
存储引擎是否为innodb
1 mysql> SELECT TABLE_SCHEMA,TABLE_NAME,ENGINE FROM
2 INFORMATION_SCHEMA.TABLES WHERE
3 ENGINE != 'innodb' AND
4 TABLE_SCHEMA NOT IN
5 ("INFORMATION_SCHEMA" ,"PERFORMANCE_SCHEMA", "MYSQL", "SYS");
MySQL主从检测
#主从状态
mysql> show slave status\G
#主从是否延迟
Master_Log_File == Relay_Master_Log_File
&& Read_Master_Log_Pos == Exec_Master_Log_Pos
高可用层面
MHA && keepalived
观察日志看是否有频繁主从切换，如果有的话就分析一下是什么原因导致频繁切换？
中间件的巡检
mycat && pproxysql
这些中间件的巡检，首先参考系统巡检，再看一下中间件本身的日志类和状态类信息，网络延迟或丢包的检查，也是必须要做工作。