简单分析percona-zabbix-templates

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。
    我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就排上了日程。
    首先是Percona monitoring Plugins for Zabbix这个插件,可以参考官网。https://www.percona.com/doc/percona-monitoring-plugins/1.1/zabbix/index.html里面已经列出了很详细的步骤,我就不再赘述了,我的目标是简单理解这些监控的出处和原理。

    因为这个插件是客户端的,所以选择了一台服务器在客户端查看。到达了相应的安装目录下,假设为:/home/app/zabbix/zabbix_agentd.conf.d/ 
可以看到配置文件userparameter_percona_mysql.conf的内容,类似下面的形式

如此来看监控项还是丰富啊,而且后面对应的参数很简介。这样的监控项总共有多少,大概是160多个。我想我算是找到了一个宝藏了,这么多的脚本可着实能好好潜心学习一番。
等等,我看了看脚本,发现有些不大对劲啊,怎么调用的都是同一个脚本。/home/app/zabbix/script/get_mysql_stats_wrapper.sh
好吧,一个就一个脚本,肯定脚本很大,也不影响代码阅读。
再次查看这个脚本,发现我又想错了。

这个脚本是大小是1333,大概就是1k的样子,这么大点能放多少代码,肯定远远不够啊。带着好奇心进入这个脚本。
原来这个脚本中不是实际的详细逻辑,这个脚本会生成一个所谓的cache文件,里面调用的脚本是一个php脚本ss_get_mysql_stats.php
大体的调用方式如下:
CMD="sudo /usr/local/php/bin/php -q $DIR/ss_get_mysql_stats.php --host $HOST --items gg"            
把生成的数据都放入/tmp/localhost-mysql_cacti_stats.txt  
          

这个cache文件是什么东东,就是调用后生成的数据信息。内容类似下面的样子:
 #cat /tmp/localhost-mysql_cacti_stats.txt
gg:19526110683 gh:2588 gi:330457818 gj:288709876 gk:-1 gl:-1 gm:-1 gn:-1 go:0 gp:0 gq:131064 gr:130907
就是把上面监控项的值按照参数来分组,比如参数gg,值为19526110683。
对应的就是监控项:
UserParameter=MySQL.Key-read-requests,/home/app/zabbix/script/get_mysql_stats_wrapper.sh gg         
而如果现学现用,就直接调用模板里引用的那个php脚本,也能得到参数gg对应的值。
# sudo /usr/local/php/bin/php -q /home/app/zabbix/script/ss_get_mysql_stats.php --host localhost --items gg
gg:19526142091   
这个参数值代表什么含义呢,继续在里面找找。查看代码,可以看到gg对应的是Key_read_requests,和监控项里的定义是一致的。

更为关键的是,我在脚本里找了半天相关的SQL语句,竟然一个都没有,这是什么情况。
继续往下看,发现原来是取的show status输出的结果,里面定义了不少的数组去存放和映射。

明白了套路,那里面引用了哪些命令呢,大概是这样的一些命令,而且难能可贵的是里面都给出了一些解释。

当然这个时候就会发现这个脚本的内容量很丰富了,里面定义了大量的函数。有些通过字面意思就能明白大体要做的操作了。

大师的脚本可以反复揣摩,其中值得学习的一个地方就是步骤很清晰,从注释就可以学习不少。
当然要抓住重点,那就是从main开始看起,有方向性。
把代码中的注释直接拿出来,对于理解也是大有裨益,这就是好脚本的一个特点。

可能因为里面有很多数组的处理,作者更钟爱于php,所以直接使用php来封装了,当然直接用shell封装也是可行的。这个应该就是基于个人喜好了。
通过这个简单的分析可以看到,这个脚本是基于一些看似简单的命令来得到一个MySQL的状态信息,而且从代码里也可以看到它也会对数据做一些二次处理,比如做一些数值统计。
看起来还是很繁琐的一个工作,在脚本里可以很清晰看出结构关系来。值得好好揣摩学习。
当然脚本运行的数据在Zabbix端也有一个映射。比如unflushed-log这个监控项,就需要这样配置一番。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------

Oracle之不可见索引 - 2016-08-27 17:08:09

Oracle 之不可见索引 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  Oracle 不可见索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新
【故障处理】序列 cache 值过小导致 CPU 利用率过高 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① enq: SQ - contention 等待事件的解决 ② 一般等待事件的解决办法 ③  DFS lock handle 等待事件 ④ 与序列有关的等待事件   Tips: ① 本文在 ITpub ( http://blog.itpub.
这两天做性能测试碰见一个问题,比较有意思。 一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2,  查看V$SQL,发现有两条记录,分别对应了0和1两个child cursor:  再查看这两个child cursor对应的执行计划:  child cursor:0 -----------------------------------------------------------------------------------------------------| I

OCP如何查看历史成绩(2) - 2016-08-25 14:08:08

OCP如何查看历史成绩( 2 ) 之前写过一篇文章 OCP如何查看历史成绩: http://blog.itpub.net/26736162/viewspace-1624996/  , 但是现在界面好像有所变动,而且有的连接也找不见了,今天有朋友问如何查询历史的成绩,晚上小麦苗就抽了点时间来找找,顺便记录下来。最近心情不好,不想写技术文章了。       首先登陆网址: https://education.oracle.com/ https://education.oracle.com/pls/eval-e
下午的时候收到这么一条报警。 ZABBIX- 监控系统 : ------------------------------------ 报警内容 : Too many parallel sessions on xxxxx_ xx机房 _xxxxx ------------------------------------ 报警级别 : PROBLEM ------------------------------------ 监控项目 : parallel_session_cnt : 66 -----------

【MySQL】Tokudb安装测试初探 - 2016-08-24 14:08:02

一 前言    TokuDB 是一个高性能、支持MVCC的MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是数据压缩功能出色,对高写压力的支持,由美国TokuTek公司(http://www.tokutek.com/) 研发,该公司于2015年4月份被Percona收购,理所当然地提供了TokuDB版本的Percona Server。本文使用Peronca server 5.6.30 版本进行测试安装。 二 安装前的准备     请参考官方文档 Percona Server YUM源

通过shell脚本添加备库日志 - 2016-08-21 17:08:14

今天下午的时候,准备顺手写一个简单的脚本,但是发现很多事情较真起来真是寸步难行。在写脚本的过程中碰到了太多的问题,很多时候感觉像要实现的功能更通用,就得做更多的检查,更多的校验也就意味着有更多的预先条件,这些条件里面有些是规范和建议,有些是按照已有的配置情况,尽管如此,自己感觉还是缺少了太多的检查。   先来说说今天尝试的简单脚本,就是给主库添加standby logfile,这个需求听起来非常简单,都甚至在我的半自动化脚本中隐去了,但是把这个需求要落到纸面上来,简直了。 首先这个需求会涉及到下面的几个数据