使用jpgraph绘制数据库监控图形

对于数据库的监控,可以分成两种类型,一种是实时的错误告警,需要尽快将一些错误信息发送给相关责任人,这更多的属于救火的性质。另外一种就是关键指标历史趋势的展示和分析,可以帮助DBA更加直观的发现数据库的指标的异常波动,提前发现问题。

市面上有不少商品的数据库监控产品,数据库厂商们也在不遗余力的推广自己的解决方案,其中不乏优秀的东西,不过能做到多产品兼容、可扩展伸缩和高度可定制的产品就凤毛麟角了。所以很多公司会自己开发一些数据库监控产品,不求大而全,只要能满足自己的业务需求就足矣。

对于自己开发的轻量级监控产品,使用LAMP等开源产品是比较合适的。数据的抽取和告警的发送,可以使用shell或者perl,几个简单的脚本就可以实现,放在crontab里定期跑跑就行,监控数据库使用MySQL存放,如果需要实现高可用的监控,考虑一下冗余,MySQL可以使用Master-Master Replication。而展示可以使用php等搭建一个简单的web网站,成本不高,效率很高。

对于历史趋势的展示,图形绘制是必须的,一图胜千言。如果使用的是PHP,jpgraph或者是pChart都是不错的选择。相对而言,jpgraph的文档和开发都还在不断的丰富,最新版本3.0.6发布于2009-10-10,而pChart的最新版本则是2008-10-06发布的1.27d,因此建议使用jpgraph。如果使用java来架构监控网站,则anysqlDataReport是值得推荐的一款产品,简单易上手,功能很强大很邪恶。

扯的有点远了,回到这篇文章的标题。jpgraph只是一个图形绘制的库,如果需要比较方便的用于数据库监控中,最好在上面再封装一层,以实现根据SQL语句查询的结果集自动绘制图形,这样可以更方便的做到批量化的增加关键指标的图形展示。另外,jpgraph对于中文的支持,因为使用了truetype字体的关系,有一点点复杂,需要从windows复制c:\windows\fonts\simsun.ttc和c:\windows\fonts\simhei.ttc到linux的/usr/share/fonts/truetype目录。jpgraph默认会将所有的中文转化成UTF8字符,如果数据库和web使用的是gb2312,则这个转化会导致乱码,解决办法是修改jpgraph_ttf.inc.php,注释掉转化部分的代码:

     /*   elseif( $aFF === FF_SIMSUN ) {
            // Do Chinese conversion
            if( $this->g2312 == null ) {
                include_once 'jpgraph_gb2312.php' ;
                $this->g2312 = new GB2312toUTF8();
            }
            return $this->g2312->gb2utf8($aTxt);
        }*/

绘制图形时,在需要使用中文的地方,显式的调用字体设置函数,将字体设置为simsun,即可正确的显示中文:

$graph->title->SetFont(FF_SIMSUN,FS_BOLD);
$graph->title->Set("中文测试");

最后,贴两张用jpgraph绘制的Oracle数据库监控效果图:
sql_executions

sequential_reads



无觅相关文章插件,快速提升流量

6条评论

  • At 2009.12.18 16:59, coolzsb said:

    “监控数据库使用MySQL存放”???

    个人实在是不建议监控数据存储到数据库里面,建议有机会去了解一下rrdtool

    签名

    可以考虑换个角度来考虑数据库的监测甚至是监控问题

    签名

    google关键字: “oracle site:cacti.net”

    • At 2009.12.18 22:21, NinGoo said:

      rrdtool和cacti我们也是有用的,有它的特点,比如对于当前数据的展示非常的方便。但是历史数据会做压缩处理。监控数据放在数据库里,可以更加方便的进行一些智能化的分析处理,更加便于利用历史数据来自动分析一些深层次问题。监控并不仅仅只是图形化展示,更多的类似运维数据BI的概念。所以即使使用rrdtool,也可以存放一份历史的全数据在数据库里,两者并不冲突。

      • At 2009.12.21 11:08, coolzsb said:

        哦,原来如此,运维数据BI的概念:我只是比较疑惑,对于半年前的数据还需要精确到每个采集时间点的精度是否有现实的意义?

        签名

        能问一下你们的历史全数据多久归档一次吗?

        签名

        那么,我现在的建议是:请有机会深入的了解一下rrdtool

        • At 2009.12.21 12:54, NinGoo said:

          谢谢你的建议,rrdtool我们也有大规模的运用的,尤其在主机监控方面。前面也说了,详细数据的分析和rrdtool的展示,面对的是两种不太一样的需求。数据库的很多监控,大多是1分钟或者5分钟的采样,也有些是小时级别或者按天监控的,对于数据库来说,整体数据量其实不能算很大,即使是分布式数据库环境,可能到1000台的规模,目前国内就很难找了,即使两年的全部监控数据,也不过几GB到几十GB的数据量而已,对归档的需求不是非常强烈。这个和大规模应用服务器的监控可能有点不太一样,国内几个大型的站点,应用服务器都到了10000台以上这种规模了,监控的数据量会非常的大,归档和聚合就显得尤为重要。

          全数据的意义,在于统计分析,基线计算,以及一些异常发生时的回溯分析。就像一般的数据仓库和商业智能分析一样,全数据,聚合数据,都有其价值,问题在于这个价值如何发掘,如何利用罢了。当然,这也和我做为一个DBA,更加习惯利用数据库来解决问题的思路有关系,这篇博文,也只是为了记录一下我利用jpgraph来展示监控的一个方法,尤其是解决中文显示的方法,顺便就数据库监控的问题多说了几句,呵呵。

    • At 2010.01.11 23:52, Jimmy said:

      赞同楼主~~

      • […] 本文转载自网址:http://www.ningoo.net/html/2009/use_jpgraph_for_database_monitor.html […]


        (Required)
        (Required, will not be published)