-
线上部分实时job是用storm开发的,为了监控数据的延迟,在storm处理日志的时候会把日志的时间插入到redis中,然后通过zabbix做延迟的监控。由于经常有新的job上线,手动配置监控项就变得比较麻烦,为了解放生产力,还是需要搞成自动化。之前添加网卡和分区监控的时候用了LLD的功能,并用了其内置的宏变量,新版本的zabbix是支持custom LLD的,实现步骤如下:1.在模
-
线上使用zabbix的host update来监测监控值是否完整(关于host update的实现请参考:http://caiguangguang.blog.51cto.com/1652935/1345789)一直发现有机器过一段时间update值就会莫名其妙变低,之前一直没有找到rc,只是简单通过重启agent来进行修复,最近同事细心地发现可能是和sudo的bug有关系。回过头再来
-
最近有个朋友问我zabbix报警怎么做比较简单,灵活,方便。其实目前zabbix的报警无怪乎下面几种方法:1.通过action直接调用sendmail一类的脚本,传入zabbix的宏变量,优点:配置比较简单,缺点:缺乏灵活性。2.通过action调用脚本,传入宏变量,并通过脚本来做后续的处理,这个方法比较简单也比较灵活,大部分情况下都适用。3.抓取zabbix 数据库里面的报警信息并做报警处理,比
-
最近在搞kafka的监控,主要是通过jmx端口来获取item和对应的值。由于监控项比较多,直接通过api来添加item就方便很多。。简单写了一个脚本,调用api来批量添加item,写得比较简单(哈哈,异常都懒得去处理了。),有兴趣的同学可以扩展下。首先手动获取template的hostid和item的app id。select hostid,name from hos
-
最近在帮同事搞spark streaming的监控,主要是通过解析servlet的url来获取对应的监控值。其中有部分值是和时间戳有关系的,java的时间戳是精确到ms的,是13位。在添加监控后,发现不能正常获取到值。在agent端,直接通过zabbix_get测试,是可以拿到值的,证明和item值的获取没有关系,从日志也可以看出,item的value是正常发送出去的。agent的日志:87104
-
因为最近线上的hadoop集群从mrv1升级到mrv2了,监控模板也跟着变动了。。线上是200台左右的集群,模块采用了link的方式来添加,即一个模板下link大量的模块,然后主机添加到这个模板里。这样算下来一台机器差不多有 215个item.为了增加NM的监控,也采用了link的方式来连接模板,在页面上link时发现一直返回一个空白页。为了快速上线,改变了下方法,使用了host.u
-
最近在做spark的监控,spark原生支持jmx的方式来获取运行的metric,因此采用了zabbix的java gateway做监控。因为之前也涉及过java应用的监控,这里做小小结:对于java应用一般会关注3大块的信息:heap,gc,thread.旧版本的zabbix没有java gateway这个概念,只能通过自己写脚本来获取监控信息:1)通过jstat这种工具来获取监控
-
最近在review一些基础监控项,发现有部分基础的监控缺失,比如disk usage,network card相关的监控。因为机器的配置不同,不太好配置一个统一的模板,不过在新版本的zabbix中有个功能Low-level discovery,可以根据主机的配置自动生成需要的监控,只需要传入宏变量即可。比如监控每个网卡的出流量net.if.out[{#IFNAME}],监控网卡的speed os.
-
最近老毕在加hbase的监控,发现生成的graph有断图的情况。。因为之前有次zabbix断图定位到了是proxy的性能问题,通过调整相应的参数解决掉了。。再看这次的情况,发现有些item的graph是ok的,也就排除了proxy性能问题。。看来还是和item相关。整个数据链路是agent---proxy(db)----server(db),从上游数据库开始入手:1.找出正常的和断图
-
今天一台线上的datanode挂了,但是没有zabbix agent unreachable的报警,不过幸好有host update percent的报警。看了下item和trigger的设置,item是zabbix内置的agent.ping,trigger设置是nodata(5m)=1,即5分钟获取不到agent.ping的值就会报警。。 由于zabbix server
-
zabbix做为越来越受大家欢迎的监控工具,其相对于nagios,cacti之流,最大的一个特点就是数据是存放在关系型数据库中的,这样就可以极大的方便后续的数据查询,处理等,比如我们想知道一台机器全天ioutil 超过80的时间比例,在zabbix的数据库中,一个sql就可以搞定了,而在cacti中就不这么方便了,而且也不用担心数据随着时间的边长而被稀释掉。 在做za
-
这几天遇到的一个case,简单记录下。最近应用团队的zabbix系统(由于总总原因我们大数据部门使用自己的监控系统)出现了比较严重的性能问题,zabbix db服务器一直高负载,IO接近饱和(16 SAS raid5),从监控的数据来看,每秒的读次数高达2k/s,io util一直都是100%的。实际是只监控了1012台服务器,103113个item,1k多的nvps,由于应用运维团队对zabbi
-
在做zabbix的性能优化时,有时候在db的数据量比较大的时候,需要对表进行partition操作,这样可以在数据查询减少用时。并且由于使用了partition,我们可以自己实现历史数据的删除操作,这样就可以禁用zabbix的housekeeping功能。简单的说下再2.0.x版本的zabbix中进行partition的操作:1.备份数据,如果使用proxy的结构的话,调整Proxy
-
最近在做数据平台这边的监控,因为之前一直在用zabbix,而且个人比较倾向于把数据放在数据库中(这一点nagios和cacti是没法和zabbix比的),方便后面做进一步的分析和处理(容量规划等)。在架构上考虑到扩展性和性能问题,采用了master---proxy的结构,其中proxy使用active的模式,这样可以减轻master端的压力。谈几个遇到的问题:1.首先,为了了解zab
-
之前有一篇文章讲到使用update percent监控agent的数据提交状况,可以有效地发现agent的故障问题,而使用unreachable的时候,会因为unreachable process busy的情况造成误报(可以通过增大StartPollersUnreachable和UnreachablePeriod解决),附一个python小程序,用来计算host的update p
-
在监控zabbix内部的性能时,我们通常使用如下的几个metric来衡量服务的性能:nvps, queue,update percent,process busy和pending sync data,cache。通过增加相应的监控,可以有效的发现zabbix的性能问题,进而进行有的放矢的优化。下面简要说明下:1.nvps,每秒钟处理的数据量,是一个理论值。取值的sql:整集群:SELECTSUM(
-
用来衡量zabbix server和proxy的update 性能,在数据delay比较严重的时候,update percent会比较低。可以做成item用来监控性能。import MySQLdb
import sys
import time
class dbUtil:
def __init__(self,host,user,passwd,db):
菜菜光
分享到朋友圈
- 关注技术:Mysql 大数据 系统集成
- 入住博客:2010-05-28 10.8年