-
线上部分实时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年
