>  기사  >  데이터 베이스  >  Mysql 시리즈(12) Mysql 모니터링 동작

Mysql 시리즈(12) Mysql 모니터링 동작

黄舟
黄舟원래의
2017-01-22 17:02:591275검색

MySQL监控属于DB监控的模块之一,包括采集、展示、监控告警。本文主要介绍Mysql监控的主要指标和采集方法。

  Mysql监控和Redis监控的逻辑类似,可参考文章《Redis监控》。

  DBA前台添加Mysql监控时系统会调用自动调度平台接口将Mysql监控的加密账户密码和ip端口等信息发送至目标,同时发送采集Agent。

  一、采集指标和命令

  1、Mysql服务运行状态

约定所有Mysql服务都必须以ip1(内网ip)来绑定,每个机器只有一个ip1,可以有多个端口,即多个Mysql Server。采集程序读取ip端口信息文件来判断server是否存在。

sockParam=`ps aux | grep -P "mysqld.*--port=${port}" | grep -oP " --socket.*\.sock"` 
 # 空则获取不到该服务器端口mysql socket配置,请检查mysql配置是否正确
MYSQL="/usr/local/mysql/bin/mysql -hlocalhost --port=${port} ${sockParam} -u${user} -p${password} "
MYSQL_ADMIN="/usr/local/mysql/bin/mysqladmin -hlocalhost --port=${port} ${sockParam} -u${user} -p${password} "
curStatus=`${MYSQL} -e"show global status"`  
 # 空则是获取不到该服务器mysql状态,请检查mysql是否正常运行
 if [ -z "${curStatus}" ]
 then
    portExists=0else
    echo "${curStatus}" >> ${curFile}
    portExists=1

  2、连接数

${MYSQL_ADMIN} processlist -v | wc -l

  3、线程数

grep 'Threads_connected' ${curFile} | awk '{print $2}'

  4、慢查询数

grep 'Slow_queries' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的慢查询次数。上次数据保存在last.cache。

  5、打开表数

grep 'Open_tables' ${curFile} | awk -F ' ' '{print $2}'

  6、每秒执行select数

grep 'Com_select' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。  

  7、每秒执行delete数

grep 'Com_delete' ${curFile} | grep -v 'multi' | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。

  8、每秒执行insert数

grep 'Com_insert' ${curFile} | grep -v 'select' | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。

  9、每秒执行update数

grep 'Com_update' ${curFile} | grep -v 'multi' | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。

  10、每秒钟执行replace数

grep 'Com_replace' ${curFile} | grep -v 'select' | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。 

  11、每秒钟执行的 Innodb_rows_deleted

grep 'Innodb_rows_deleted' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。  

  12、每秒钟执行的 Innodb_rows_inserted

grep 'Innodb_rows_inserted' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。  

  13、每秒钟执行的 Innodb_rows_read

grep 'Innodb_rows_read' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。

  14、每秒钟执行的 Innodb_rows_updated

grep 'Innodb_rows_updated' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量。上次数据保存在last.cache。

  15、每秒钟执行的 innodb rows total

expr ${innodbRowsDeletedPS} + ${innodbRowsInsertedPS} + ${innodbRowsReadPS} + ${innodbRowsUpdatedPS}

等于前面四个Innodb_rows_*执行次数的总和

  16、每秒处理命令数 qps

expr ${mysqlSelectNumPS} + ${mysqlInsertNumPS} + ${mysqlUpdateNumPS} + ${mysqlDeleteNumPS} + ${mysqlReplaceNumPS}

等于前面五个mysql命令Com_*的数量总和

  17、每秒接收字节数 KByte/s

grep 'Bytes_received' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量,除以1024得到单位KByte/s。上次数据保存在last.cache。

  18、每秒发送字节数

grep 'Bytes_sent' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值除以时间差,等于最近1分钟的执行数量,除以1024得到单位KByte/s。上次数据保存在last.cache。

  19、可立即获得锁的次数

grep 'Table_locks_immediate' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的可立即获得锁数量。上次数据保存在last.cache。

  20、不可立即获得锁的次数

grep 'Table_locks_waited' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的不可立即获得锁数量。上次数据保存在last.cache。

  21、一行锁定需等待时间

grep 'Innodb_row_lock_waits' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的一行锁定需等待时间。上次数据保存在last.cache。

  22、 当前脏页数

grep 'Innodb_buffer_pool_pages_dirty' ${curFile} | awk -F ' ' '{print $2}'

  23、要求清空的缓冲池页数

grep 'Innodb_buffer_pool_pages_flushed' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的要求清空的缓冲池页数。上次数据保存在last.cache。

  24、Innodb 写入日志字节数 KByte

grep 'Innodb_os_log_written' ${curFile} | awk -F ' ' '{print $2}'

需要计算两次的慢查询次数得到差值,等于最近1分钟的写入日志字节数,除以1024得到KByte。上次数据保存在last.cache。

  25、占用内存大小 MByte

pid=`ps aux | grep 'mysqld' | grep -Ev 'safe|grep' | awk '{print $2}' `
mem=`cat /proc/${pid}/status | grep 'VmRSS' | awk '{print $2}'`
mysqlMem=`echo "scale=2;${mem} / 1024" | bc`

除以1024得到MByte

  26、handler socket每秒处理数

curHsTableLock=`grep 'Hs_table_lock' ${curFile} | awk '{print $2}'`
preHsTableLock=`grep 'Hs_table_lock' ${preFile} | awk '{print $2}'`if [ -n "${curHsTableLock}" ]then
    hsQPS=`echo "scale=0;(${curHsTableLock} - ${preHsTableLock}) / ${intervalTime}" | bc`else
    hsQPS=0fi


  27、主从同步和状态

#主从信息
#是否为从服务器
slave_running=`grep 'Slave_running' ${curFile} | awk '{print $2}'`if [ "${slave_running}A" = "ONA" ]then
    slaveRunning=1
    slaveStatus=`${MYSQL} -e'show slave status\G'`    echo "${slaveStatus}" > ${slaveFile}
    
    slaveIoRunning=`grep 'Slave_IO_Running' ${slaveFile} | awk -F ':' '{print $2}'`
    slaveSqlRunning=`grep 'Slave_SQL_Running' ${slaveFile} | awk -F ':' '{print $2}'`    
    if [ "${slaveIoRunning}A" == "NoA" -o "${slaveSqlRunning}A" == "NoA" ]    then
        slaveRunning=3
    fi
    
    secondsBehindMaster=`grep 'Seconds_Behind_Master' ${slaveFile} | awk -F ':' '{print $2}'`    
    if [ "${secondsBehindMaster}A" = "NULLA" ]    then
        secondsBehindMaster=8888   # 表示主从不同步
    fi
    #是从库时 获取主库ip
    master=`grep 'Master_Host' ${slaveFile} | awk -F ':' '{print $2}'`
    masterPort=`grep 'Master_Port' ${slaveFile} | awk -F ':' '{print $2}'`else
    master=""
    masterPort=""
    slaveRunning=0
    secondsBehindMaster=10000   # 不用检测fi


참고: Seconds_Behind_Master, 이 값은 마스터-슬레이브 지연을 판단하는 지표로 사용됩니다. 그러면 동시에 이 값을 얻는 방법은 무엇입니까? (이 문단은 http://blog.chinaunix.NET/uid-27038861-id-3686311.html에서 인용했습니다.)

Seconds_Behind_Master는 sql_thread가 실행한 이벤트의 타임스탬프와 해당 이벤트의 타임스탬프를 비교합니다. io_thread(약칭 ts)로 복사한 것을 비교하면 이런 차이가 나옵니다. Relay-log에 있는 내용이 메인 라이브러리의 bin-log와 정확히 일치한다는 것은 우리 모두 알고 있는 사실인데, SQL문을 기록할 때 그때의 ts도 기록되기 때문에 비교를 위한 참조값은 binlog에서 나온다. 실제로 마스터-슬레이브가 NTP와 통신할 필요가 없습니다. 즉, 마스터와 슬레이브 클럭이 일치하는지 확인할 필요가 없습니다. 또한 실제로 io_thread와 sql_thread 사이에서 비교가 발생하고 io_thread가 실제로 메인 라이브러리와 관련되어 있음을 알 수 있습니다. 그러면 메인 라이브러리 I/O 로드가 많거나 네트워크가 차단되면 문제가 발생합니다. binlog를 복사하면(중단 없음, 계속 복사 중) sql_thread는 항상 io_thread 스크립트를 따라갈 수 있습니다. 이때 Seconds_Behind_Master의 값은 0이며 이는 지연이 없다고 생각하지만 실제로는 그렇지 않습니다. , 알잖아. 이것이 데이터베이스 지연이 부정확한지 모니터링하기 위해 이 매개변수를 사용하는 것을 모두가 비판하는 이유입니다. 그러나 이 값이 항상 부정확한 것은 아닙니다. io_thread 및 마스터 네트워크가 매우 좋다면 이 값도 매우 정확합니다.

28. Agent 하트비트 감지 및 수집

위는 Mysql 시리즈의 내용입니다. (12) Mysql 모니터링 작업에 대한 자세한 내용은 PHP 중국어 홈페이지(www.kr)를 참고하시기 바랍니다. .php.cn)!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.