zabbix监控日志文件 MySQL日志为例(95)

一般情况下,日志最先反映出应用当前的问题,在海量日志里面找到我们异常记录,然后记录下来,并且根据情况报警,大家可以监控系统日志、nginx、Apache、业务日志。这边我拿常见的MySQL日志做监控,大家看演示。

监控日志key

首先要了解key,

log[ file  ,<regexp>,<encoding>,<maxlines>,<mode>,<output>]

file:文件名,写绝对路径

regexp:要匹配内容的正则表达式,或者直接写你要检索的内容也可以,例如我想检索带ERROR关键词的记录

encoding:编码相关,留空即可

maxlines:一次性最多提交多少行,这个参数覆盖配置文件zabbxi_agentd.conf中的’MaxLinesPerSecond’,我们也可以留空

mode:默认是all,也可以是skip,skip会跳过老数据

output:输出给zabbix server的数据。可以是\1、\2一直\9,\1表示第一个正则表达式匹配出得内容,\2表示第二个正则表达式匹配错的内容。

备注:我极力推荐大家使用第二个参数,看到网上一些zabbix监控日志的教程,几乎只有第一个参数,这样将会导致日志文件里的内容统统丢给zabbix_server记录,我想,这一定不是大家想看到的。

日志文件权限配置

给日志文件加上读取权限,为了演示方便,我直接给777

如果权限给的不到位,zabbix agent日志有类似如下报错:

zabbix配置

Host>>目标主机>>item>>create item,如下:

logrt

zabbix日志监控

说明:

1. type必须选择zabbix agent(active),因为数据是zabbix被监控的主动提交给server

2. key:log[/data/mydata/mydata_3306/li220-237.err,ERROR,,,,],我不多说了,细心的人会说,还有一个叫logrt得key,有什么区别,等会儿讲.

3. log time format:yyMMddphh:mm:ss,对应日志的行头150311 11:47:09,y表示年、M表示月、d表示日、p和:一个占位符,h表示小时,m表示分钟,s表示秒。

zabbix监控MySQL日志查看

切换到最新日志里面,找到相应数据,如下是我的监控截图

logrt

zabbix监控MySQL日志

接下来便是触发器,大家可以根据自己的情况来创建触发器,例如日志中包含某个字符串等等,如上图,我们可以触发执行mysql表修复。

logrt介绍

如果仔细看可以发现,第一个参数不一样,logrt的第一个参数可以使用正则表达式。针对日志回滚用得,例如我们每天都切割nginx日志,日志名位www.ttlsa.com_2017-01-01.log、www.ttlsa.com_2017-01-02.log等等,使用log肯定不合适,如果文件名使用正则,那么新增的日志文件会立即加入监控。

备注:不管新日志、老日志,只要他们有变更,zabbix都会监控。

 

 

Received empty response from Zabbix Agent问题解决(94)

刚接触zabbix新手少部分会出现如下错误:

Received empty response from Zabbix Agent at [192.168.1.2]. Assuming that agent dropped connection because of access permission

大概意思是说没有权限访问agent端口10050,解决方法如下:

如果你的server有多个IP地址,使用逗号分隔多个IP地址。

 

 

java struts2 远程执行任意java代码漏洞

最近网络上爆发大规模的struts2远程代码执行漏洞。

漏洞说明

漏洞危害

漏洞可以远程执行任意Java代码

危险等级

高危

受影响版本

Struts 2.3.20 – Struts 2.3.28 (2.3.20.2 和 2.3.24.2 除外)

CVE

CVE-2016-3081

漏洞前提

开启动态方法调用, struts.xml配置

<constant name=”struts.enable.DynamicMethodInvocation” value=”true” />

沙盒绕过

通过ognl表达式静态调用获取ognl.OgnlContext的DEFAULT_MEMBER_ACCESS属性,并将获取的结果覆盖_memberAccess属性,这样就可以绕过SecurityMemberAccess的限制。

漏洞详情

https://struts.apache.org/docs/s2-032.html

http://www.freebuf.com/vuls/102836.html

临时解决方案

1. 检查是否使用struts2

2. 检查是否开启动态方法调用

3. 在struts前端nginx配置正则拦截攻击请求

正则:if($args ~ @ognl.OgnlContext@DEFAULT_MEMBER_ACCESS) { return 404;}

升级Struts 2至Struts 2.3.20.2, Struts 2.3.24.2 或者 Struts 2.3.28.1,以便彻底解决此问题。

Nagios太阳(pnp)安装配置

Nagios太阳(pnp)安装配置

一.安装rrdtool

RRDTOOL将nagios采集的数据绘制成图表。

 

二.安装pnp

 

三.配置nagios

 

四.验证

http://ip/nagios/pnp/

zabbix加载扩展模块 第三方库支持(92)

zabbix从2.2版本开始增加了使用动态库来扩展zabbix功能。loadable modules实际上和我们前面提到的用户自定义key是一样的功能,不同的是,他用加载lib库的方式,并且zabbix不需要fork一个新的进程,性能更好。目前类似的功能包含user parameters 、 external checks 、 system.run[] ,如果这些脚本逻辑过于复杂、耗时太长会出现比较严重的问题。

工作中,我们可以使用c开发一些适用于我们自己生产环境的模块。当然你也可以将它分享给出来,而不需要公布你的源代码,如果你对自己写的代码不自信的话。当agentd、server、proxy启动的时候同时将模块加载进来,退出的时候也会释放。

zabbix模块API

zabbix代码中有提供api所需的头文件.h,目前模块有两类接口需要实现,一类是必须实现的,一类是可选的。

必须实现的接口

两个接口: zbx_module_api_version()、zbx_module_init()

用于返回API版本,必须实现,默认返回常量ZBX_MODULE_API_VERSION_ONE(数值1)

模块必要的一些初始化,初始化成功返回ZBX_MODULE_OK,否则返回ZBX_MODULE_FAIL。

可选接口

可选接口有zbx_module_item_list()、 zbx_module_item_timeout()、 zbx_module_uninit()

返回模块内定义的item列表,包含key,如:agent.ping、agent.version,每个item都使用结构体ZBX_METRIC

超时时间设置,秒为单位

释放资源,如:文件描述等

定义item结构体

key:item key名称,例如agent.ping、mysql.version等

flags:CF_HAVEPARAMS 或者0

function:将要调用的函数

test_param:参数列表

示例

在定义function需要接收两个参数AGENT_REQUEST 、AGENT_RESULT ,如下

编译模块

编译准备

zabbix提供了一份用于测试的模块源码,在zabbix源码目录下

请一定记住所有的源代码最好放到modules目录下来编译,因为他需要一些接口都在源码中。例如include/module.h、include/sysinc.h、 include/config.h,前面两个.h文件解压就存在,而config.h需要在源码根目录下执行./configure(不能带参数,否则会报错)。

开始编译

加载模块

拷贝so文件到zabbix目录下

修改配置文件

测试模块

重启zabbix_agentd

# killall zabbix_agentd

# /usr/local/zabbix-2.4.3/sbin/zabbix_agentd

测试key

可以看到定义好的三个key都成功了。学好linux c开发自己的zabbix模块吧。

 

 

 

zabbix监控惠普打印机(91)

假设公司有多个楼层或者分布在不同楼,打印机自然分布很广泛,打印机缺少油墨或者卡纸了,都需要员工找IT部门。我们使用zabbix对打印机进行监控,一旦缺少油墨,zabbix发出报警,it人员能够及时更换,让打印机一直处在不间断的工作状态。如果卡纸也能第一时间赶赴现场,迅速解决问题。

我们今天监控的主要项目是油墨,卡纸这块请根据对应的snmp来做

开启打印机SNMP

登陆打印机web地址:http://192.168.1.20/(我当前的),网络>>SNMP>>勾选”启用 SNMP v1/v2 只读访问(将 ‘public’ 用于获取社区名称)”

hp

 

油墨剩余量OID

可以看出,我们当前油墨剩余量是30%,与web管理后台的剩余量一致

hp

创建主机

configuration>>HOST>>create host,type选择SNMPv2 agent,key其实意义不大,OID:.1.3.6.1.2.1.43.11.1.1.9.1.1,更新时间大家自己发挥,其他都用默认,想了解更多关于zabbix使用snmp监控,请回头看ttlsa相关文章。

hp

 

创建触发器

当油墨小于10%,trigger触发warnning。出现warnning之后,接下来的便是邮件报警了。

hp

当油墨不足时,trigger报警如下

hp

邮件报警

邮件报警请参考《zabbix邮件报警

 

更多相关文章

1. zabbix snmp类型 无需安装agent也能监控(51)

2. snmp安装配置 zabbix snmp监控准备(52)

3. snmp v3的安全配置 snmp认证与加密配置(53)

4. SNMP OID列表 监控需要用到的OID

5. zabbix单位符号Unit symbols(32)

打印机OID:http://www.oidview.com/mibs/0/Printer-MIB.html

OpenTSDB Nagios 实现监控报警

OpenTSDB 非常强大,但是没有一个完整的监控平台。现在,OpenTSDB上有一系列的metric,当这些值超过临界值时,发送报警。在OpenTSDB源码tools目录下有一个Python工具check_tsd。该脚本查询OpenTSDB并返回兼容Nagios的输出OK/WARNING/CRITICAL状态格式。

check_tsd 解释

参数说明

添加Nagios命令

将check_tsd脚本放在Nagios服务器/usr/local/nagios/libexec目录里。

编辑/usr/local/nagios/etc/objects/commands.cnf文件,添加下面的命令:

添加监控项

nagios

OpenTSDB 部署

有关 OpenTSDB 介绍可以参见之前的文章。

OpenTSDB架构

OpenTSDB三大块,收集,加载/存储和查询数据。这种架构的主要目的是写入和读取数据点到HBase的。 有很多种方法来收集数据。我们可以使用tcollector,也可以自定义客户端程序收集。架构图如下:

HBase

所需条件

  • A Linux system
  • Java Development Kit 1.6 or later
  • GnuPlot 4.2 or later
  • Autotools
  • Make
  • Python
  • Git
  • An Internet connection

安装jdk

为了处理大量的数据使用的HBase作为底层数据库。在安装OpenTSDB前,需要先安装并运行HBase。本文将部署简单单一的HBase环境,如果你需要可扩展高可用性,就需要部署完全的HBase集群。

Oracle下载jdk安装包。

设置环境变量

部署单一的HBase实例

配置HBase

启动HBase实例

安装Gnuplot

安装OpenTSDB

下载地址:https://github.com/OpenTSDB/opentsdb/releases

可以下载RPM包安装或通过源码安装。通过源码编译安装需要连接到Google code下载jar包。

创建表

COMPRESSION可以有NONE/LZO/GZIP/SNAPPY。 推荐使用LZO,压缩率高,会节省空间。 将创建4张表:tsdb、tsdb-uid、tsdb-tree、tsdb-meta。

配置OpenTSDB

要能正常启动tsdb服务,需要配置以下四个参数:

  • Port: 监听的端口,默认 4242
  • Staticroot: 指定web静态文件根目录
  • Cachedir: 创建一个临时目录来存储缓
  • Zkquorum: 指定Zookeeper服务器ip和端口

Cachedir目录会缓存大量的临时过期文件,需要定期清理。源码目录下有提供一个脚本来定期清理该目录。可以设置为cron任务。

启动tsdb服务:

采集数据

收集的数据格式如下:

put tsd.hbase.latency_90pct 1408958117 18 method=scan host=tsdb class=TsdbQuery
put tsd.hbase.latency_95pct 1408958117 18 method=scan host=tsdb class=TsdbQuery
put tsd.hbase.root_lookups 1408958117 0 host=tsdb
put tsd.hbase.meta_lookups 1408958117 2 type=uncontended host=tsdb
put tsd.hbase.meta_lookups 1408958117 0 type=contended host=tsdb
put tsd.hbase.rpcs 1408958117 0 type=increment host=tsdb
put tsd.hbase.rpcs 1408958117 312 type=delete host=tsdb
put tsd.hbase.rpcs 1408958117 601 type=get host=tsdb
put tsd.hbase.rpcs 1408958117 14543 type=put host=tsdb
put tsd.hbase.rpcs 1408958117 0 type=rowLock host=tsdb
put tsd.hbase.rpcs 1408958117 102 type=openScanner host=tsdb
put tsd.hbase.rpcs 1408958117 102 type=scan host=tsdb
put tsd.hbase.rpcs.batched 1408958117 739 host=tsdb
put tsd.hbase.flushes 1408958117 0 host=tsdb
put tsd.hbase.connections.created 1408958117 1 host=tsdb
put tsd.hbase.nsre 1408958117 0 host=tsdb
put tsd.hbase.nsre.rpcs_delayed 1408958117 0 host=tsdb
put tsd.compaction.count 1408958117 379 type=trivial host=tsdb
put tsd.compaction.count 1408958117 32 type=complex host=tsdb

这个这是简单的测试。收集OpenTSDB的信息的。 可以使用Tcollector来收集数据。有关Tcollector内容参见之前的文章。

OpenTSDB内置的可视化界面

通过http://IP:4242来访问

 

HBase

zabbix开启报警声音 网页也可以有声音(49)

用过nagios的兄弟应该用过 Nagios Checker,当nagios有异常监控,他可以发出报警声音,不过他是浏览器的一个扩展。而zabbix直接自带了这个功能。

zabbix右上角的profile(配置)–>messaging–>Frontend messaging勾上。可以选择你需要发出声音的故障的严重性类型。下回有报警便能发出声音了。上图吧,一看就知道~

Linux

zabbix报警声音

 

参考

Nagios Checker:https://addons.mozilla.org/zh-CN/firefox/addon/nagios-checker/

zabbix telnet监控类型(93)

概述

zabbix监控的方式很多,例如前面讲到的agent、snmp以及后续后续要讲到ssh和今天要讲到的telnet。流程很简单,创建item–>配置ip、用户、密码、端口、脚本->zabbix server telnet目标ip->执行制定脚本,脚本最后返回数据给server。

目标:获取linux系统15分钟负载

telnet key

语法:telnet.run[<unique short description>,<ip>,<port>,<encoding>]
<unique short description>:描述
<ip>:服务器ip
<port>:服务器端口
<encoding>:编码,可为空

telnet配置

请看《linux下telnet安装与使用》

创建脚本

获取系统负载脚本loadavg.sh

创建item

configuration>>host>>你的主机>>item>>create item,如下:

Linux

属性说明:

user name:telnet账号

Password:telnet密码

 

 

获取到的结果如下

Linux

优缺点都很明显,只需要通过telnet就可以监控服务器,但是账号密码是明文配置在item中的,而且一旦网络不好,item状态很容变为unspport。一直相类似的还有ssh监控类型,想了解的同学情关注下一篇文章。再会~

OpenTSDB TCollector 详解

tcollector是一个客户端程序,用来收集本机的数据,并将数据发送到OpenTSDB。

OpenTSDB被设计的收集和写入数据非常简单,有一个简单的协议,即使是一个shell脚本也可以用来发送数据。

但是,做到可靠和一致性就有些困难了。当TSD服务器down了该怎么做?如何确保采集者一直在运行?这就是要使用tcollector的原因了。

tcollector可以为你做一下几件事:

  • 运行所有的采集者并收集数据
  • 完成所有发送数据到TSD的连接管理任务
  • 不必在你写的每个采集者中嵌入这些代码
  • 是否删除重复数据
  • 处理所有有线协议,以后今后的改进

重复数据删除

通常情况下,你需要收集你系统的所有数据。这会产生大量的数据点,其中大多数的数据是不经常改变的。但是,当它们改变时,你想以细粒度来解决。Tcollector会记住发送所有时间序的最后的值和时间戳,如果该值在采样间隔内没有发生变化,将抑制发送该数据点。一旦该值发生变化(或10分钟后),则发送上次抑制的值和时间戳,以及当前的值和时间戳。这样一来,所有的图形将是正确的。

重复数据删除技术会减少TSD数据点的数量,同样也可以减少网络负载。

未来版本的OpenTSDB,会使用RLE来改善存储格式,使得很少存储重复值。

使用tcollector收集大量的metric

在tcollector下,可以使用任何语言编写采集者。只需要采集者有可执行权限,并把数据以标准输出输出。其他的交给tcollector处理。采集者位于采集器目录下,tcollector会遍历每个数字目录并执行这些目录下的采集者。数字目录代表采集间隔。如,如果目录名称为60,tcollector将尝试每60s运行该目录下的所有采集者。目录名为0,说明采集者持续长久运行。tcollector会读取它们的输出,如果它们挂掉了,会复活它们。

一般来说,长久运行的采集者需要考虑耗资料少。OpenTSDB被设计成每个metric具有大量数据点。对于大多数metric,通常以15s为一个数据点。

如果以任何非数字命令目录,将忽略该目录下的所有采集者。采集器目录下还包含lib和etc目录,为所有采集者使用的library和配置数据。

安装tcollector

git clone git://github.com/OpenTSDB/tcollector.git

编辑tcollector/startstop文件,设置该变量TSD_HOST=tsd.ttlsa.com。

为了避免为每个采集者创建各自的metric,启动tsd时,加上–auto-metric 参数。不过从长远看,不建议加上该参数,避免metric意外创建。

tcollector自带的采集者

0/dfstat.py

这些统计类似于/usr/bin/df工具提供的。

  • df.bytes.total  数据总大小
  • df.bytes.used  已用的字节数
  • df.bytes.free    剩余的字节数
  • df.inodes.total  总的inode数量
  • df.inodes.used  已用的inode数
  • df.inodes.free  剩余的inode数

这些metric包含时间序标记每个挂载点和文件系统类型。此采集器可通过cgroup, debugfs, devtmpfs, rpc_pipefs, rootfs filesystems和挂载点/dev/, /sys/, /proc/和/lib/进行过滤。

0/ifstat.py

这些统计来自/proc/net/dev。

  • proc.net.bytes    (rate) Bytes in/out
  • proc.net.packets  (rate) Packets in/out
  • proc.net.errs  (rate) Packet errors in/out
  • proc.net.dropped (rate) Dropped packets  in/out

接口标签iface=, 方向标签direction=in|out。 仅仅ethN接口采集,有意排除bondN接口,因为bonded接口也就是各个ethN接口的总计,没必要重复收集。

0/iostat.py

数据来源于/proc/diskstats.

  • iostat.disk.*  每个磁盘的统计
  • iostat.part.* 每个分区的统计

iostats内容参见:https://www.kernel.org/doc/Documentation/iostats.txt

0/netstat.py

socket分配和网龙统计信息。

从/proc/net/sockstat来的metric。

  • net.sockstat.num_sockets  sockets分配的数量,仅TCP
  • net.sockstat.num_timewait   TCP sockets当前处在TIME_WAIT状态数量
  • net.sockstat.sockets_inuse 套接字使用的数量
  • net.sockstat.num_orphans 孤儿套接字数量(不依附于任何文件描述符)
  • net.sockstat.memory 分配给该套接字类型的内存大小(字节)
  • net.sockstat.ipfragqueues 等待重新组装的IP流数量

从 /proc/net/netstat (netstat -s )来的metric。

  • net.stat.tcp.abort  内核中止连接数量
  • net.stat.tcp.abort.failed 内核中止失败数量,因为没有足够内存来复位。
  • net.stat.tcp.congestion.recovery 内存检测到假重传,能部分回收或全部CWND数量。
  • net.stat.tcp.delayedack 发送不同类型的延迟确认数量。
  • net.stat.tcp.failed_accept 在3WHS连接之后丢弃数。
  • net.stat.tcp.invalid_sack 无效的SACK数量。
  • net.stat.tcp.memory.pressure  进入”memory pressure”的次数。
  • net.stat.tcp.memory.prune  因内存不足放弃接收数据的次数。
  • net.stat.tcp.packetloss.recovery  丢失恢复的次数。
  • net.stat.tcp.receive.queue.full 因套接字接收队列慢导致被丢弃接收到的数据包数量。
  • net.stat.tcp.reording  检测到重新排序的次数。
  • net.stat.tcp.syncookies SYN cookies数。
 0/nfsstat.py

这些统计来自/proc/net/rpc/nfs.

  • nfs.client.rpc.stats  RPC状态统计
  • nfs.client.rpc  RPC调用统计
 0/procnettcp.py

这些统计来自 /proc/net/tcp{,6}。每60s收集一次。

  •  proc.net.tcp  TCP连接数
 0/procstats.py

来自/proc的统计。

  • proc.stat.cpu  CPU使用率统计。标签为CPU类型。type=user, nice, system, idle, iowait, irq, softirq。
  • proc.stat.intr  中断率
  • proc.stat.ctxt 上下文切换率

procstat内容参见:http://www.linuxhowtos.org/System/procstat.htm

  •  proc.vmstat.*  从/proc/vmstat信息,参见:http://www.linuxinsight.com/proc_vmstat.html
  • proc.meminfo.* 从/proc/meminfo统计的内存使用情况
  • proc.loadavg.*  从/proc/loadavg统计的1min, 5min, 15min, runnable, total_threads指标。
  • proc.uptime.total 启动率
  • proc.uptime.now
  • proc.kernel.entropy_avail
  • sys.numa.zoneallocs
  • sys.numa.foreign_allocs
  • sys.numa.allocation
  • sys.numa.interleave
 0/smart-stats.py

统计SMART磁盘信息。

  •  smart.raw_read_error_rate  当从盘面上读取数据时,有关硬件读取数据出错的几率。
  • smart.throughput_performance  硬盘驱动的总体吞吐量
  • smart.spin_up_time  主轴旋转起来的平均时间(从零转速到完全运行[毫秒])
  • smart.start_stop_count  主轴开始/停止周期的统计
  • smart.reallocated_sector_ct  重新分配扇区的统计
  • smart.seek_error_rate 磁头寻道错误几率
  • smart.seek_time_performance 磁头寻道平均时间
  • smart.power_on_hours
  • smart.spin_retry_count
  • smart.recalibration_retries
  • smart.power_cycle_count
  • smart.soft_read_error_rate
  • smart.program_fail_count_chip
  • smart.erase_fail_count_chip
  • smart.wear_leveling_count
  • smart.used_rsvd_blk_cnt_chip
  • smart.used_rsvd_blk_cnt_tot
  • smart.unused_rsvd_blk_cnt_tot
  • smart.program_fail_cnt_total
  • smart.erase_fail_count_total
  • smart.runtime_bad_block
  • smart.end_to_end_error
  • smart.reported_uncorrect
  • smart.command_timeout
  • smart.high_fly_writes
  • smart.airflow_temperature_celsius
  • smart.g_sense_error_rate
  • smart.power-off_retract_count
  • smart.load_cycle_count
  • smart.temperature_celsius
  • smart.hardware_ecc_recovered
  • smart.reallocated_event_count
  • smart.current_pending_sector
  • smart.offline_uncorrectable
  • smart.udma_crc_error_count
  • smart.write_error_rate
  • smart.media_wearout_indicator
  • smart.transfer_error_rate
  • smart.total_lba_writes
  • smart.total_lba_read

SMART说明参见:https://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes

理解这些metric最好是看厂家的说明。

其他采集器

0/couchbase.py

统计couchbase数据库的。

所有的metric都以bucket=为标签。桶是Couchbase服务器集群中的逻辑分组。参见:http://docs.couchbase.com/couchbase-manual-2.1/#cbstats-tool

0/elasticsearch.py

统计Elastic 搜索的。

metric说明参见http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster.html

0/hadoop_datanode_jmx.py

统计Hadoop  DataNode 状态。

默认情况下,采集器对这些metric是禁用的。revision, hdfsUser, hdfsDate, hdfsUrl, date, hdfsRevision, user, hdfsVersion, url, version, NamenodeAddress, Version, RpcPort, HttpPort, CurrentThreadCpuTime, CurrentThreadUserTime, StorageInfo, VolumeInfo.

metric说明参见:http://hbase.apache.org/book.html#hbase_metrics

0/haproxy.py

统计Haproxy 状态信息。

  • haproxy.current_sessions 当前的session数
  • haproxy.session_rate 每秒新增session量

所有metric的标签有server (server=) 和cluster (cluster=).

具体信息说明参见:http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

0/hbase_regionserver_jmx.py

统计Hadoop  RegionServer 信息

默认情况下,采集器对这些metric是禁用的。revision, hdfsUser, hdfsDate, hdfsUrl, date, hdfsRevision, user, hdfsVersion, url, version, Version, RpcPort, HttpPort,HeapMemoryUsage, NonHeapMemoryUsage.

具体说明参见:http://hbase.apache.org/book.html#hbase_metrics

0/mongo.py

统计Mongo 信息。

具体metric说明参见:http://docs.mongodb.org/manual/reference/server-status/

0/mysql.py

统计mysql信息。

统计的信息有:InnoDB Innodb monitors, Global Show status, Engine Show engine, Slave Show slave status, Process list Show process list.

0/postgresql.py

统计PostgreSQL 信息。

metric说明参见:http://www.postgresql.org/docs/9.2/static/monitoring-stats.html

0/redis-stats.py

统计redis信息。

metric说明参见:http://redis.io/commands/INFO

0/riak.py

统计riak信息。

metric说明参见:http://docs.basho.com/riak/latest/ops/running/stats-and-monitoring/#Statistics-from-Riak

0/varnishstat.py

统计varnish信息。

默认情况下,所有的metric都收集。若要改变编辑采集器的vstats数组。运行“varnishstat-l”列出所有可用的metric。

0/zookeeper.py

统计zookeeper信息。

metric说明参见:http://zookeeper.apache.org/doc/trunk/zookeeperAdmin.html#sc_zkCommands

对于本地的信息采集只好部署在本地了。可以通过自动化部署如puppetsaltstack来部署tcollector。

对于网络类型的服务,集中式采集会方便些。不需要在每台上去部署了。

snmp v3的安全配置 snmp认证与加密配置(53)

如果你觉得你得服务器信息暴露在外面没关系,或者说服务器安全限制的很严格,不需要对snmp做一道验证,那么你可以打住,否则继续往下看。snmp v2配置请参考上一节《snmp安装配置 zabbix snmp监控准备(52)

增加snmp v3用户

 

参数说明

ttlsa:用户名

ttlsapwd:密码,密码必须大于8个字符

DES:加密方式,这边支持AES、DES两种

ttlsades:DES口令,必须大于8位

备注:增加用户的时候,snmp必须关闭,否则有如下报错

启动snmpd v3

使用snmp v3获取信息

snmp v3安全级别有三种,分别为noAuthNoPriv(不认证也不加密)、authNoPriv(认证但是不加密)、authPriv(既认证又加密)

务器剩余内存

noAuthNoPriv安全级别

authNoPriv安全级别

authPriv安全级别

SNMP V3小结

既然打算用snmp v3了,那么v1、v2别忘记关闭了,下一节我们分别会演示v2与v3的监控项创建方法,关注下一节zabbix使用SNMP监控服务器.

 

zabbix snmp监控所有文章

1. zabbix snmp类型 无需安装agent也能监控(51)

2. snmp安装配置 zabbix snmp监控准备(52)

3. snmp v3的安全配置 snmp认证与加密配置(53)

4. SNMP OID列表 监控需要用到的OID

5. zabbix单位符号Unit symbols(32)

KairosDB REST API

KairosDB REST API提供了对一系列已存在的指标名、标记名和值、存储指标数据点和查询指标数据点的操作。

可以通过制定的指标名称和时间范围来查询数据点,并可以任选一个或多个标记。查询可以对数据进行处理操作,如聚合,平均值,最小值和最大值的计算。

所有的POST值和返回信息都以JSON格式表示。

添加数据点

方法:POST

地址:http://[host]:[port]/api/v1/datapoints

如果使用压缩,需要设置内容类型为application/gzip。

body格式:

描述:

  • name: 指标名必需唯一。
  • datapoints:数据点的数组。每个数据点包含一个时间戳和值。
  • tags:标记字段是一系列属性列表。至少需要一个标记。当查询指标时,使用标记缩小查询。
  • type: 类型识别自定义数据类型。

返回结果:

  • 成功:返回204,不包含内容。
  • 失败:如果请求无效返回400 Bad Request。
    如果发生错误返回500 Internal Server Error

删除数据点

对指定的查询的数据点执行删除操作。聚合和分组不受影响。

删除设计的目的是,执行查询验证返回的数据点是否正常,对有问题的数据点删除。

注意:删除操作只对Cassandra和H2存储有效。

方法:POST

地址:http://[host]:[port]/api/v1/datapoints/delete

body格式:一个查询操作

返回结果:

  • 成功:返回204,不包含内容。
  • 失败:如果请求无效返回400 Bad Request。
    如果发生错误返回500 Internal Server Error

删除指标

删除指定的指标以及与其相关的数据点。

只对Cassandra和H2数据库有效。

方法:DELETE

地址:http://[host]:[port]/api/v1/metric/{metric_name}

body格式:None

返回结果:

  • 成功:返回204,不包含内容。
  • 失败:如果请求无效返回400 Bad Request。
    如果发生错误返回500 Internal Server Error

列出所有指标名

方法:GET

地址:http://[host]:[port]/api/v1/metricnames

body格式:None

返回结果:

成功返回200和查询结果。

列出所有标记名

方法:GET

地址:http://[host]:[port]/api/v1/tagnames

body格式:None

返回结果:

成功返回200和查询结果。

列出所有标记值

方法:GET

地址:http://[host]:[port]/api/v1/tagvalues

body格式:None

返回结果:

成功返回200和查询结果。

查询指标

返回基于一系列标准指标值的列表,也返回一系列的所有标记和标记值的数据点。

时间范围内可以以绝对或相对时间值来指定。绝对时间值,以毫秒为单位。相对时间值被指定为整数持续时间和单位。单位有:“milliseconds”, “seconds”, “minutes”, “hours”, “days”, “weeks”, “months”, “years”。结束时间是可选的。如果不指定结束时间,结束时间被假定为现在。

grouping

查询的结果可以被组合在一起。有三种方式对数据进行分组:tags、time range、value。时间范围或值的分组可以减缓查询。

Aggregators
Filtering

通过制定的标记来进行数据过滤。返回的数据将只包含有指定标签的相关数据点。

方法:POST

地址:http://[host]:[port]/api/v1/datapoints/query

body格式:

查询属性:

必须指定start_absolute或start_relative,但不能同时使用。

cache_time:查询结果缓存周期。如果相同的查询在缓存周期内,将从缓存中返回数据。

指标属性:

name: 返回数据点的指标名称。必需的。

aggregators:这是聚合的有序数组。如果没有指定聚合器,则所有的数据点被返回。默认聚合器有:avg、dev、histogram、least_squares、max、min、rate、sum。

所有聚合允许缩减像素采样,除了rate和div。

缩减像素采样可以让你减少数据点的采样率和在一段较长的时间聚集这些值。 缩减像素采样值是一个整数值,单位有:”milliseconds”, “seconds”, “minutes”, “hours”, “days”, “weeks”, “months”, “years”。

tags: 标记缩小搜索范围。仅仅指标包含该标记并且匹配其中的值则被返回。可选的。

group_by:所得到的数据点可以由一个或多个标记,时间范围,值,或由这三种的组合进行分组。

在查询中的“GROUP_BY”属性的一个或多个分组的数组。每个分组有一个名称和附加属性。

exclude_tags:默认情况下,查询的结果包括与数据点相关联的标记和标记值。如果exclude_tags为true,标记将排除在外。

结果返回:

  • 成功:返回200代码
  • 失败:
    如果请求无效返回400 Bad Request
    如果检索数据发生错误返回500 Internal Server Error

 查询指标标记

仅仅返回标记信息。

目前,不能在HBase数据库上实现。

Filtering:通过指定的标记来过滤返回标记。

方法:POST

地址:http://[host]:[port]/api/v1/datapoints/query/tags

body格式:

查询属性:必须指定start_absolute或start_relative,但不能同时使用。同样,可以指定任一end_absolute或end_relative,但不能同时使用。如果未指定任一结束时间则当是当前时间。

指标属性:

name: 返回指定指标的数据点。必需的。

tags:缩小搜索范围,仅返回指标包含该标记并匹配该值。可选的。

返回结果:

  • 成功:
  • 失败:
    如果请求无效返回400 Bad Request.
    如果检索数据发生错误返回500 Internal Server Error

 版本信息

返回KairosDB版本信息。

方法:GET

地址:http://[host]:[port]/api/v1/version

body格式:None

返回结果:

  • 成功:

snmp安装配置 zabbix snmp监控准备(52)

snmp在监控这个行当里面有着举足轻重的地位,一直想写zabbix使用snmp监控,由于最近懒散了一直没写,也有人提到ttlsa能否写snmp的监控,那就写吧,前面有两篇文章已经做好了铺垫《SNMP OID列表 监控需要用到的OID》《zabbix snmp监控类型》,今天是最后一篇铺垫,然后下面一篇便是zabbix使用snmp监控的实例,好了,不说没用的,看看snmp的安装配置。

yum安装snmp

snmp配置

 

启动snmpd

通过snmp获取数据

需要通过snmp获取到数据,首先我们需要对应的OID,请参考《SNMP OID列表 监控需要用到的OID

获取主机名

 

通过如上两种方式均可获取到数据,如上获取到得数据都是li519-232

获取服务器剩余内存

通过两种方式获取到服务器剩余内存,因为服务器资源使用量都实时变动的,所以两次获取的数值不同.

最后

snmp的安装和使用就是这么的简单了,如果你希望你的snmp安全点,那请看接下来的《snmp v3的安全配置 snmp认证与加密配置

 

zabbix snmp监控所有文章

1. zabbix snmp类型 无需安装agent也能监控(51)

2. snmp安装配置 zabbix snmp监控准备(52)

3. snmp v3的安全配置 snmp认证与加密配置(53)

4. SNMP OID列表 监控需要用到的OID

5. zabbix单位符号Unit symbols(32)

OpenTSDB数据写入HTTP API接口

一.命名方案

OpenTSDB命名格式有点类似于RRD样式,只不过引入了标记(tags),使得指标(metric)更具有代表性和通用性,可以共享许多独特的时间序列。通过标记的键值对组合来确定指标的唯一性,可以非常灵活的进行聚合函数的查询。

RRD如果要记录web1服务器的第一个CPU的用户空间使用量,命名的格式为web1.sys.cpu.0.user,如果有上千台服务器,每台多核CPU,那么需要命名很多来区别,如webN.sys.cpu.M.user。 对于OpenTSDB,可以这么命名sys.cpu.user host=web1,cpu=0。如果要汇总所有内核的值,只需sum:sys.cpu.user{host=web1}。如果要汇总上千台服务器的CPU值,只需sum:sys.cpu.user。比RRD命名格式更加的灵活通用。

因此,对于要监控的对象命名,要定义一个相同的共性,便于汇总,同时,要能很好的表达监控的项目。

二.指标命名规范

指标名称区分大小写,统一以小写字母命名。

指标名称不能含有空格。

指标名称只能含有下列字符:a-z,A-Z,0-9,-,_,.,/或Unicode字母。

指标名称尽量精短。

三.指标值规范

指标值可以是整数也可以是浮点数。

四.时间戳

UNIX时间戳,可以是秒或毫秒,必需是整数,且不能超过13位数。毫秒级的时间戳格式必需是1234567890123,最后三位代表毫秒数。对于应用程式生成的时间戳超过13位的,必需四舍五入至最高13位,否则报错。

由于OpenTSDB底层存储系统HBase目前只支持秒级别的存储,因此对于毫秒级别的数据会转换成秒。

五. 标记命名规范

标记是用来补充说明指标的,是指标的属性,来对指标进行差异性的定义。

标记是一对键值对。

每个指标至少有一个标记。通常是host=ip或host=hostname。

OpenTSDB最多支持8个标记。

标记区分大小写,统一以小写字母命名。

标记不能含有空格。

标记只能含有下列字符:a-z,A-Z,0-9,-,_,.,/或Unicode字母。

六. HTTP API接口

为了节省带宽,该接口允许在一个单一的请求中提交多个数据点数据。每个数据点单独处理,如果其中某个数据点有问题不会影响其他数据点的存储。

  • 地址:
  1. /api/put
  2. /api/put?summary 调试,返回汇总信息
  3. /api/put?details 调试,返回详细信息
  • 方法:POST
  • 格式:
    {

metric:     ”lvs.connection.active”,              //必需,字符串,指标名称

timestamp:        1234567890,                            //必需,整型,时间戳

value:        11.11,                                             //必需,整型、浮点型、字符串,指标值

tags: {“host”:”web1”}                                     //必需,对象,标记对

}

  • 返回结果:

默认情况下,如果所有数据存储成功,响应一个204的状态码。如果有一个或多个数据点出错,返回400状态码和错误消息内容。

  1. 请求地址是/api/put?summary时,返回:
    {

“failed”: 1,                            //整型,存储失败的数据点数量

“success”: 0                         //整型,存储成功的数据点数量

}

  1. 请求地址是/api/put?details时,返回:
    {

“errors”: [  …],             //数组,失败的数据点列表以及失败原因

“failed”: 1,

“success”: 0

}

七. HTTP API接口实例

1. /api/put

2./api/put?summary

3. /api/put?details

zabbix proxy分布式监控配置(45)

概述

zabbix proxy可以代替zabbix server检索客户端的数据,然后把数据汇报给zabbix server,并且在一定程度上分担了zabbix server的压力.zabbix proxy可以非常简便的实现了集中式、分布式监控.

zabbix proxy使用场景:

  • 监控远程区域设备
  • 监控本地网络不稳定区域
  • 当zabbix监控上千设备时,使用它来减轻server的压力
  • 简化zabbix的维护

Linux

zabbix proxy仅仅需要一条tcp连接到zabbix server,所以防火墙上仅仅需要加上一条规则即可.zabbix proxy数据库必须和server分开,否则数据会被破坏,毕竟这两个数据库的表大部分都相同。总之记住,数据库分开即可。

proxy收集到数据之后,首先将数据缓存在本地,然后在一定得时间之后传递给zabbix server.这个时间由proxy配置文件中参数ProxyLocalBuffer and ProxyOfflineBuffer决定.

zabbix proxy是一个数据收集器,它不计算触发器、不处理事件、不发送报警,如下是proxy的功能.

Items Function Supported by proxy
 Zabbix agent checks  Yes
 Zabbix agent checks (active)  Yes
 Simple checks  Yes
 Trapper items  Yes
 SNMP checks  Yes
 SNMP traps  Yes
 IPMI checks  Yes
 JMX checks  Yes
 Log file monitoring  Yes
 Internal checks  Yes
 SSH checks  Yes
 Telnet checks  Yes
 External checks  Yes
 Built-in web monitoring  Yes
 Network discovery  Yes
 Low-level discovery  Yes
 Calculating triggers  No
 Processing events  No
 Sending alerts  No
 Remote commands  No

 

备注:使用agent active模式,一定要记住在agent的配置文件参数ServerActive加上proxy的IP地址.切记

配置

如果你安装好proxy(安装方法我们后续讲)之后,我们便可以在zabbix管理站点上配置proxy了.

添加proxy

ministration(管理) → DM(分布式监控)–>Create proxy(创建代理)

Linux

zabbix proxy

参数 描述
Proxy name proxy名称,必须和proxy配置文件中的hostname一致
Proxy mode 选择proxy模式
Active proxy主动连接到zabbix server并且请求配置文件数据
Passive Zabbix server连接到proxy
Hosts 哪些主机需要被proxy监控

 

Host配置

配置主机HOST的时候,如果需要被proxy代理,那么都选择对应的proxy名称

Linux

zabbix proxy

zabbix Event acknowledgment事件确认(47)

概述

以往服务器出现报警,运维人员处理完事之后,报警自动取消,但是下一次出现同样一个错误,但是换了一个运维人员,他可能需要重新排查问题,直到问题处理完毕。针对这种情况,zabbix提供了event acknowledgment(事件确认)功能,一旦处理好某个问题,运维认为可以再里面写上备注,说明造成此问题的原因以及处理方法,下一次运维人员遇到这个报警先看前一次的事件确认。
Acknowledgment也可以在action中使用,一旦运维人员没有及时填写事件确认,可以向他的主管或者经理发送一个通知:xxx人员没有写事件确认.

事件确认界面

在zabbix首页的last 20 issues,在每条报警列都有Ack,如果是NO,说明还没有对事件进行确认,如果是Yes,表明已经提交了事件描述.

event acknowledge

zabbix event Acknowledgment

event acknowledge

zabbix event Acknowledgment

这里写明造成问题的原因以及解决方法,然后点击下方的acknowledge and return,如果下次还出现类似故障,运维人员可以看到如下内容

event acknowledge

zabbix event Acknowledgment

zabbix Queue队列(46)

概述

queue(队列)显示监控项等待刷新的时间,可以看到每种agent类型刷新时间,通过queue可以更好的体现出监控的一个指标.正常情况下,是一片绿色。如果出现过多红色,那么需要留意一下。我们也可以在右上角的下拉条选detail,可以找出到底是哪个item的问题。

读取队列

点击Administration(管理) → Queue(队列). 下拉框三个选项,分别为overview、overview by proxy、detail,如下为overview

Linux

zabbix queue

上图大部分为绿色,表示服务器整体OK,上图可以看到10秒和5分钟处有两个item还未刷新.为了找出是哪个item,我们可以再下拉框选到detail。

 

Linux

zabbix queue

如上图,可以轻易的找出刷新存在延迟item的详细信息(因为延迟很快就恢复了,所以第一张图抓到7个延迟,detail只出现一个)。偶尔出现几个延迟,那是很正常的,一般都会快速恢复的。但是如果比较多的超过10分钟的延迟,那么你要好好的留意一下了。有可能出现比较严重的问题。

Linux

zabbix queue

远程节点延迟

来自子节点(child node)的信息部都不是最新的。master节点接受到的数据都存在一定得延迟(通常情况下,多则需要10秒)
决定子节点信息延迟因素

  • 子节点性能
  • 子节点与主节点之间的通行质量
  • 子节点与主节点之间的时间差

Queue item

既然queue也是一项性能指标,那么我们也有很必要把他加入监控项,zabbix提供了内建item zabbix[queue,,] ,from默认为6秒,表示超过多少秒便报警,to默认为infinity,也就是无限制.

zabbix Maintenance维护周期(48)

概述

我们可以给zabbix某些组或者某些Hosts设置维护时间,zabbix提供两种维护类型:依旧收集数据、暂停收集数据

在 服务器维护期间不会生成报警(前提:触发器设置了’Maintenance status = not in “maintenance”’),如果在维护期间出现故障,并且没有解决掉,那么在维护周期结束之后,服务器会生成报警.如果你想在维护期间也能收到报 警,那么触发器不需要设置’Maintenance status = not in “maintenance”’.

配置

配置维护周期,

点击Configuration(配置) → Maintenance(维护)—>点击Create maintenance period (创建维护周期)

配置如下

Linux

zabbix maintenance

 参数  描述
 Name  维护名称
 Maintenance type  两种维护类型可选:
With data collection – 依旧收集数据
No data collection – 暂停收集数据
 Active since  维护周期开始时间
 Active till  维护结束时间
 Description  描述

.Periods 选项卡是维护周期的,可以选择daily, weekly, monthly or one-time,我这边的例子是每周一凌晨6点开始维护,持续2个小时,也就是到八点结束.如果你想每天执行,也可以选择daily或者在weekly 里选择周一到周天.具体用法我不在详讲了,大家看了就明白.

Linux
zabbix maintenance

Hosts & Groups选项卡里面,选择需要维护的主机或者组.

Linux
zabbix maintenance

维护标识在inventory–>HOSTS->host inventory的overview里面可以看到维护的标示(扳手),如下图

Linux
zabbix maintenance

或者在HOSTS列表里面,status显示In maintenance.

Linux
zabbix maintenance

KairosDB Telnet API

KairosDB Telnet API 提供对指标的存储操作和查询KairosDB当前的版本。

数据点有一个指标、值、时间戳和一个或多个的标记列表。标记用来标示数据属性。

指标名、标记名和值区分大小写的,并且只能包含以下字符:字母数字字符,可以含有”.”、”/”、”-“、”_”。

如果一个数据点的指标不存在,将被创建。

put

可以通过telnet 4242端口进行数据的提交。

数据格式为:

Metric name: 指标名称只能是字母数字-_. 。

Time stamp:时间戳可以是毫秒或秒。秒是为了和OpenTSDB兼容。Cassandra支持毫秒数据存储。注意:REST API只支持毫秒时间戳。

value: 值可以是一个长或双精度值。

Tag:一系列的key=value键值对。

注意:发送的数据后面必须跟一个换行符。

例如:

version

该命令返回KairosDB版本信息。

输出:

使用netcat:

OpenTSDB 详解

1. OpenTSDB介绍

OpenTSDB用HBase存储所有的时序(无须采样)来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集所有metrics,支持永久存储,可以做容量规划,并很容易的接入到现有的报警系统里。OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的metrics并进行存储、索引以及服务,从而使得这些数据更容易让人理解,如web化、图形化等。

对于运维工程师而言,OpenTSDB可以获取基础设施和服务的实时状态信息,展示集群的各种软硬件错误,性能变化以及性能瓶颈。对于管理者而言,OpenTSDB可以衡量系统的SLA,理解复杂系统间的相互作用,展示资源消耗情况。集群的整体作业情况,可以用以辅助预算和集群资源协调。对于开发者而言,OpenTSDB可以展示集群的主要性能瓶颈,经常出现的错误,从而可以着力重点解决重要问题。

OpenTSDB使用LGPLv2.1+开源协议,目前版本为2.X。

2. 安装OpenTSDB

2.1 依赖

OpenTSDB依赖jdk和Gnuplot,Gnuplot需要提前安装,版本要求为最小4.2,最大4.4,执行以下命令安装即可:

OpenTSDB是用java编写的,但是项目构建不是用的java的方式而是使用的C、C++程序员构建项目的方式。运行时依赖:

可选的编译时依赖:

  • GWT 2.4 (ASLv2)

可选的单元测试依赖:

2.2 下载并编译源代码

首先安装必要依赖:

下载源代码,可以指定最新版本或者手动checkout

2.3 安装

  • 1. 首先安装一个单节点或者多节点集群的hbase环境,hbase版本要求为0.94
  • 2. 设置环境变量并创建opentsdb使用的表,需要设置的环境变量为COMPRESSIONHBASE_HOME,前者设置是否启用压缩,或者设置hbase home目录。如果使用压缩,则还需要安装lzo
  • 3. 执行建表语句src/create_table.sh
  • 4. 启动TSD

如果你使用的是hbase集群,则你还需要设置--zkquorum--cachedir对应的目录会产生一些临时文件,你可以设置cron定时任务进行删除。添加--auto-metric,则当新的数据被搜集时自动创建指标。

你可以将这些参数编写到配置文件中,然后通过--config指定该文件所在路径。

  • 5. 启动成功之后,你可以通过127.0.0.1:4242进行访问。

从源代码安装gnuplot、autoconf、opentsdb以及tcollector,可以参考:OpenTSDB & tcollector 安装部署(Installation and Deployment)

3. 使用向导

3.1 配置

OpenTSDB的配置参数可以在命令行指定,也可以在配置文件中指定。配置文件使用的是java的properties文件,文件中key为小写,支持逗号连接字符串但是不能有空格。所有的OpenTSDB属性都以tsdb开头,例如:

配置参数优先级:

命令行参数 > 配置文件 > 默认值

你可以在命令行中通过--config指定配置文件所在路径,如果没有指定,OpenTSDB会从以下路径寻找配置文件:

  • ./opentsdb.conf
  • /etc/opentsdb.conf
  • /etc/opentsdb/opentsdb.conf
  • /opt/opentsdb/opentsdb.conf

如果一个合法的配置文件没有找到并且一些必须参数没有设置,TSD进程将不会启动。

配置文件中可配置的属性请参考:Properties

3.2 基本概念

在深入理解OpenTSDB之前,需要了解一些基本概念。

  • Cardinality。基数,在数学中定义为一个集合中的一些元素,在数据库中定义为一个索引的一些唯一元素,在OpenTSDB定义为:
  • 一个给定指标的一些唯一时间序列
  • 和一个标签名称相关联的一些唯一标签值

在OpenTSDB中拥有高基数的指标在查询过程中返回的值要多于低基数的指标,这样花费的时间也就越多。

Compaction。在OpenTSDB中,会将多列合并到一列之中以减少磁盘占用空间,这和hbase中的Compaction不一样。这个过程会在TSD写数据或者查询过程中不定期的发生。

Data Point。每一个指标可以被记录为某一个时间点的一个数值。Data Point包括以下部分:

  • 一个指标:metric
  • 一个数值
  • 这个数值被记录的时间戳
  • 多个标签

Metric。一个可测量的单位的标称。metric不包括一个数值或一个时间,其仅仅是一个标签,包含数值和时间的叫datapoints,metric是用逗号连接的不允许有空格,例如:

  • hours.worked
  • webserver.downloads
  • accumulation.snow

Tags。一个metric应该描述什么东西被测量,在OpenTSDB中,其不应该定义的太简单。通常,更好的做法是用Tags来描述具有相同维度的metric。Tags由tagk和tagv组成,前者表示一个分组,后者表示一个特定的项。

Time Series。一个metric的带有多个tag的data point集合。

Timestamp。一个绝对时间,用来描述一个数值或者一个给定的metric是在什么时候定义的。

Value。一个Value表示一个metric的实际数值。

UID。在OpenTSDB中,每一个metric、tagk或者tagv在创建的时候被分配一个唯一标识叫做UID,他们组合在一起可以创建一个序列的UID或者TSUID。在OpenTSDB的存储中,对于每一个metric、tagk或者tagv都存在从0开始的计数器,每来一个新的metric、tagk或者tagv,对应的计数器就会加1。当data point写到TSD时,UID是自动分配的。你也可以手动分配UID,前提是auto metric被设置为true。默认地,UID被编码为3Bytes,每一种UID类型最多可以有16,777,215个UID。你也可以修改源代码改为4Bytes。UID的展示有几种方式,最常见的方式是通过http api访问时,3 bytes的UID被编码为16进制的字符串。例如,UID为1的写为二进制的形式为000000000000000000000001,最为一个无符号的byte数组,其可以表示为[0,0,1],编码为16进制字符串为000001,其中每一位左边都被补上0,如果其不足两位。故,UID为255的会显示为[0,0,255]0000FF

关于为什么使用UID而不使用hashes,可以参考:why-uids

TSUID。当一个data point被写到OpenTSDB时,其row key格式为:<metric_UID><timestamp><tagk1_UID><tagv1_UID>[...<tagkN_UID><tagvN_UID>],不考虑时间戳的话,将其余部分都转换为UID,然后拼在一起,就可以组成为TSUID。

Metadata。主要用于记录data point的一些附加的信息,方便搜索和跟踪,分为UIDMeta和TSMeta。

每一个UID都有一个metadata记录保存在tsdb-uid表中,每一个UID包括一些不可变的字段,如uidtypenamecreated字段表示什么时候被创建,还可以有一些额外字段,如descriptionnotesdisplayName和一些custom key/value对,详细信息,可以查看 /api/uid/uidmeta

同样,每一个TSUID可以对应一个TSMeta,记录在tsdb-uid中,其包括的字段有tsuidmetrictagslastReceivedcreated,可选的字段有descriptionnotes,详细信息,可以查看/api/uid/tsmeta

开启Metadata有以下几个参数:

  • tsd.core.meta.enable_realtime_uid
  • tsd.core.meta.enable_tsuid_tracking
  • tsd.core.meta.enable_tsuid_incrementing
  • tsd.core.meta.enable_realtime_ts

metadata的另外一个形式是Annotations,详细说明,请参考annotations

Tree

3.3 数据存储方式

OpenTSDB使用HBase作为后端存储,在安装OpenTSDB之前,需要先启动一个hbase节点或者集群,然后再执行建表语句src/create_table.sh创建hbase表。建表语句如下:

从上面可以看出一共创建了4张表,并且可以设置是否压缩、是否启用布隆过滤、保存版本号等等,如果追求hbase读写性能,还可以预建分区。

3.3.1 Data Table Schema

在OpenTSDB中,所有数据存储在一张叫做tsdb的表中,这是为了充分利用hbase有序和region分布式的特点。所有的值都保存在列族t中。

rowkey为<metric_uid><timestamp><tagk1><tagv1>[...<tagkN><tagvN>],UID默认编码为3 Bytes,而时间戳会编码为4 Bytes

OpenTSDB的tsdb启动之后,会监控指定的socket端口(默认为4242),接收到监控数据,包括指标、时间戳、数据、tag标签,tag标签包括tag名称ID和tag值ID。例如:

对于指标myservice.latency.avg的ID为:[0, 0, -69],reqtype标签名称的ID为:[0, 0, 1], foo标签值的ID为:[0, 1, 11], 标签名称的ID为:[0, 0, 2] web42标签值的ID为:[0, -7, 42],他们组成rowkey:

row表示格式为: 每个数字对应1 byte

  • [0, 0, -69] metric ID
  • [77, 4, -99, 32] base timestamp = 1292148000. timestamps in the row key are rounded down to a 60 minute boundary。也就是说对于同一个小时的metric + tags相同的数据都会存放在一个row下面
  • [0, 0, 1] “reqtype” index
  • [0, 1, 11] “foo” index
  • [0, 0, 2] “host” index
  • [0, -7, 42] “web42” index

NOTE:可以看到,对于metric + tags相同的数据都会连续存放,且metic相同的数据也会连续存放,这样对于scan以及做aggregation都非常有帮助

column qualifier 占用2 bytes或者4 bytes,占用2 bytes时表示以秒为单位的偏移,格式为:

  • 12 bits:相对row表示的小时的delta, 最多2^ 12 = 4096 > 3600因此没有问题
  • 4 bits:format flags
    • 1 bit: an integer or floating point
    • 3 bits: 标明数据的长度,其长度必须是1、2、4、8。000表示1个byte,010表示2byte,011表示4byte,100表示8byte

占用4 bytes时表示以毫秒为单位的偏移,格式为:

  • 4 bits:十六进制的1或者F
  • 22 bits:毫秒偏移
  • 2 bit:保留
  • 4 bits: format flags
    • 1 bit: an integer or floating point,0表示整数,1表示浮点数
    • 3 bits: 标明数据的长度,其长度必须是1、2、4、8。000表示1个byte,010表示2byte,011表示4byte,100表示8byte

举例:

对于时间戳为1292148123的数据点来说,其转换为以小时为单位的基准时间(去掉小时后的秒)为129214800,偏移为123,转换为二进制为1111011,因为该值为整数且长度为8位(对应为2byte,故最后3bit为100),故其对应的列族名为:0000011110110100,将其转换为十六进制为07B4

value 使用8bytes存储,既可以存储long,也可以存储double。

总结一下,tsdb表结构如下:

cassandra

3.3.2 UID Table Schema

一个单独的较小的表叫做tsdb-uid用来存储UID映射,包括正向的和反向的。存在两列族,一列族叫做name用来将一个UID映射到一个字符串,另一个列族叫做id,用来将字符串映射到UID。列族的每一行都至少有以下三列中的一个:

  • metrics 将metric的名称映射到UID
  • tagk 将tag名称映射到UID
  • tagv 将tag的值映射到UID

如果配置了metadata,则name列族还可以包括额外的metatata列。

  • id 列族

Row Key – 将会是一个分配到UID的字符串,例如,对于一个指标可能有一个值为sys.cpu.user或者对于一个标签其值可能为42

Column Qualifiers – 上面三种列类型中一种。

Column Value – 一个无符号的整数,默认被编码为3个byte,其值为UID。

例如以下几行数据是从tsdb-uid表中查询出来的数据,第一个列为row key,第二列为”列族:列名”,第三列为值,对应为UID

  • name 列族

Row Key – 为UID

Column Qualifiers – 上面三种列类型中一种或者为metrics_metatagk_metatagv_meta

Column Value – 与UID对应的字符串,对于一个*_meta列,其值将会是一个UTF-8编码的JSON格式字符串。不要在OpenTSDB外部去修改该值,其中的字段顺序会影响CAS调用。

例如,以下几行数据是从tsdb-uid表中查询出来的数据,第一个列为row key,第二列为”列族:列名”,第三列为值,对应为UID

总结一下,tsdb-uid表结构如下:

cassandra

上图对应的一个datapoint如下:

从上图可以看出tsdb-uid的表结构以及数据存储方式,对于一个data point来说,其被保存到opentsdb之前,会对metricstagktagvmetric_metatagk_metatagv_meta生成一个UID(如上图中的000001),然后将其插入hbase表中,rowkey为UID,同时会存储多行记录,分别保存metricstagktagvmetric_metatagk_metatagv_meta到UID的映射。

3.3.3 Meta Table Schema

这个表是OpenTSDB中不同时间序列的一个索引,可以用来存储一些额外的信息。这个表名称叫做tsdb-meta,该表只有一个列族name,两个列,分别为ts_metats_ctr,该表中数据如下:

Row Key 和tsdb表一样,其中不包含时间戳,<metric_uid><tagk1><tagv1>[...<tagkN><tagvN>]

TSMeta Column 和UIDMeta相似,其为UTF-8编码的JSON格式字符串

ts_ctr Column 计数器,用来记录一个时间序列中存储的数据个数,其列名为ts_ctr,为8位有符号的整数。

3.3.4 Tree Table Schema

索引表,用于展示树状结构的,类似于文件系统,以方便其他系统使用,例如:Graphite

3.4 如何写数据

3.5 如何查询数据

3.6 CLI Tools

tsdb支持以下参数:

通过以下命令创建指标:

执行上述命令的结果如下:

3.11 Utilities

3.12 Logging

4. HTTP API

5. 谁在用OpenTSDB

  • StumbleUpon StumbleUpon is the easiest way to find cool new websites, videos, photos and images from across the Web
  • box Box simplifies online file storage, replaces FTP and connects teams in online workspaces.
  • tumblr 一个轻量级博客,用户可以跟进其他的会员并在自己的页面上看到跟进会员发表的文章,还可以转发他人在Tumblr上的文章

6. KairosDB

KairosDB是一个快速可靠的分布式时间序列数据库,主要用于Cassandra当然也可以适用与HBase。KairosDB是在OpenTSDB基础上重写的,他不仅可以在HBase上存储数据还支持Cassandra。

KairosDB主页:https://code.google.com/p/kairosdb/

7. 参考资料

转自:http://blog.javachen.com/2014/01/22/all-things-opentsdb/#

zabbix Aggregate checks聚合检测(43)

概述

aggregate checks是一个聚合的检测,例如我想知道某个组的host负载平均值,硬盘剩余总量,或者某几台机器的这些数据,简单的说,这个方法就是用来了解一个整体水平,而不需要我们一台台看过去。这个方法的数据全部来之数据库,所以它不需要agent。文章的最后面我们会有一个简单的图例讲述aggregate checks.

aggregate item key语法如下:

多个组使用逗号分隔.

支持按组的function

GROUP FUNCTION 描述

grpavg 平均值
grpmax 最大值
grpmin 最小值
grpsum 总和

支持按tiem的function

ITEM FUNCTION 描述
avg 平均值
count value个数
last 最新值
max 最大值
min 最小值
sum 总值

参数timeperiod为指定的采集时间,可以使用时间单位,例如可以使用1d代替86400(单位默认为秒),5m代替300.

备注:

  • 如果第三个参数为last,那么timeperiod参数值将会被server忽略掉
  •  只有被监控的HOST上启用的item才会被计入aggregate check

使用范例

示例1

组MySQL Servers剩余硬盘空间大小

示例2

组MySQL Servers的平均CPU负载

示例3

组MySQL Servers 5分钟内的平均查询速度(次/秒)

示例4

多个组的cpu负载平均值

示例(带图)

获取linux servers组内所有HOST平均运行天数

首先在zabbix server上配置item,名字就叫做:zabbix aggregate(平均运行天数),key为:grpavg[“Linux servers”,”system.uptime”,last,0]

具体请看图:

Aggregate

zabbix Aggregate checks

获取到的结果如下:

Aggregate

zabbix Aggregate checks

最后

如果如要对某个监控项有一个整体的了解,zabbix aggregate是你的不二选择.

zabbix分布式监控proxy vs nodes(44)

概述

zabbix为IT基础设施提供有效和可用的分布式监控,zabbix提供了两种解决方案,分别为:proxy和nodes.proxy代替zabbix server在本地检索数据,然后提交给zabbix server. Nodes则就是一个完整的zabbix Server.

Proxy vs. node

服务器一多以及服务器分布在各个不同地区,便需要考虑使用分布式监控,那么我们到底选择proxy还是nodes呢,请看如下的对照表,看完之后,我想你能选到一个你满意的方式.

 Proxy  Node  描述
 Lightweight/轻量级  Yes  No 安装完毕即可,Proxy必须更轻量级
 GUI/图形界面  No  Yes proxy的配置都在servers上,而node是一个完整的server
 Works independently/独立工作  Yes  Yes
 Easy maintenance/易于维护  Yes  No
Automatic DB creation/自动生成数据库 Yes No
Local administration/本地管理 No Yes
Ready for embedded hardware Yes No
One way TCP connections Yes Yes
Centralised configuration/集中配置 Yes No  proxy配置全部集中在server上,node自己维护自己的配置
Generates notifications/通知 No Yes

备注:只有SQLite才支持自动创建数据库,其他数据都需要手动创建.

zabbix Trapper 监控项配置(42)

概述

zabbix获取数据有超时时间,如果一些数据需要执行比较长的时间才能获取的话,那么zabbix会出现异常,考虑到这种情况,zabbix增加了Trapper功能,客户端自己提交数据给zabbix,这个通道便是trapper.

使用trapper的步骤如下:

  • 在zabbix中配置trapper监控项
  • 传递数据到zabbix中

配置

配置监控项

Configuration(配置) → Hosts(主机)–> 选择需要配置的Host—> 点击右上角的”create item(创建监控项)”–>输入如下参数

Linux

参数说明

Type 这边选择Zabbix trapper.
key 自定义key名称,客户端通过key来传送数据
Type of information 数据类型,比如数字、文本、浮点等等
Allowed hosts 可选,如果指定了,那么当前监控项只接受指定IP地址发送来的数据,多个IP使用逗号分隔. 这个参数从zabbix

传送数据

我们通过一个最简单的例子来讲解,使用zabbix sender命令传送“ttlsa.com你好”给trapper.

参数详解:

-z – 指定zabbix server的IP

-p – 指定zabbix server的端口,默认为10051

-s – 指定目标主机,主机名必须是配置中的hostname而不是visible name,切记

-k – 指定key,我们定义的trapper的key,这边便是我们前面定义的trap

-o – 指定要传递的数据

备注:如上的test_01便是目标主机

展示数据

菜单中 Monitoring → Latest data可以查看数据

Linux

zabbix trapper

zabbix执行远程命令(41)

概述

监控,有的人只把他当做报警使用,出现问题之后打开跑回家打开电脑,巴拉巴拉的处理掉,大多数时候都是一些小问题,为何不让zabbix帮你把这些事情处理掉呢?和朋友具体,收到xx硬盘空间慢了、xx服务器高负载等问题,你要回家处理?多扫兴

瞧瞧zabbix远程执行命令可以做些什么吧:

  • 重启应用(Apache、nginx、MySQL等等)
  • 使用IPMI接口重启服务器
  • 自动释放磁盘空间(删除老文件,清除/tmp目录等等)
  • CPU过载时讲一个虚拟机迁移到另外一台物理服务器
  • 云环境下,一台服务器CPU\硬盘\内存\其他硬件资源不足的情况下,可以自动添加过去

创建一个报警,记得使用邮件报警吗?呵呵,实际上,我们把发送邮件的操作改成执行远程命令就行了

备注:zabbix代理不支持远程命令

远程命令最大长度为255字符,同时支持多个远程命令,如需要执行多条命令,只需要另起一行写命令即可,还有,远程命令可以使用宏变量。

接下来我将一步一步告诉大家如何设置远程命令

配置

首先我们需要在zabbix客户配置文件开启对远程命令的支持,编辑zabbix_agentd.conf,修改

重启客户端

备注:Aive zabbix不支持远程命令

然后配置action,Configuration->Actions,选择Operation选项卡,operation type改成Remote Command,选择远程命令类似 (IPMI, Custom script, SSH, Telnet, Global script),输入远命令

配置Action

  • 在Operations选显卡中选择Remote command
  • 选择远程命令类型(IPMI, Custom script, SSH, Telnet, Global script)
  • 写上远程命令

示例:

上面例子用来在出现状况的情况下重启Apache,务必全包zabbix agent能够执行这个命令.

备注:

1.sudo不用多说了,zabbix用户没有运行某些命令的权限,必须加上.

2.远程命令,自然是在远程的主机后台运行。
Conditions选项卡定义了什么条件下,这个远程命令会被执行,其实这个和前面说的action真没什么区别,大家都能看懂。下图的意思是,在非维护时间Apache应用出现状况,并且严重性级别为Disaster。满足条件之后,就开始执行命令了。

访问权限

确保你的zabbix用户有执行权限,如果某些命令需要root权限,那么请使用sudo

编辑sudoer文件,zabbix用户便可以执行Apache restart命令了

 

备注:在某些情况下,zabbix需要sudo才能执行命令,请先在/etc/sudoer开启requiretty.具体的方法,请百度或者google.

使用多种接口执行远程命令

如果目标系统支持多种接口:zabbix agent、IPMI、远程命令(默认),请看如下一些实例
示例1

通过zabbix检测到的一些问题,然后自动重启windows

参数 描述
Operation type Remote command
Type Custom script
Command c:\windows\system32\shutdown.exe -r –

示例2

使用IPMI重启服务器

参数 描述
Operation type Remote command
Type IPMI
Command reset on

示例三

使用IPMI关机

参数 描述
Operation type Remote command
Type IPMI
Command power off

 

喜欢zabbix的请继续关注运维生存时间zabbix教程…当然还有其他文章.

SNMP OID列表 监控需要用到的OID

zabbix的snmp监控还没开始讲,不过先给大家列一些snmp常用的一些OID,比如cpu、内存、硬盘什么的。先了解这些,在使用snmp监控服务器。

系统参数(1.3.6.1.2.1.1)

OID

描述

备注

请求方式

.1.3.6.1.2.1.1.1.0

获取系统基本信息

SysDesc

GET

.1.3.6.1.2.1.1.3.0

监控时间

sysUptime

GET

.1.3.6.1.2.1.1.4.0

系统联系人

sysContact

GET

.1.3.6.1.2.1.1.5.0

获取机器名

SysName

GET

.1.3.6.1.2.1.1.6.0

机器坐在位置

SysLocation

GET

.1.3.6.1.2.1.1.7.0

机器提供的服务

SysService

GET

.1.3.6.1.2.1.25.4.2.1.2

系统运行的进程列表

hrSWRunName

WALK

.1.3.6.1.2.1.25.6.3.1.2

系统安装的软件列表

hrSWInstalledName

WALK

网络接口(1.3.6.1.2.1.2)

OID

描述

备注

请求方式

.1.3.6.1.2.1.2.1.0

网络接口的数目

IfNumber

GET

.1.3.6.1.2.1.2.2.1.2

网络接口信息描述

IfDescr

WALK

.1.3.6.1.2.1.2.2.1.3

网络接口类型

IfType

WALK

.1.3.6.1.2.1.2.2.1.4

接口发送和接收的最大IP数据报[BYTE]

IfMTU

WALK

.1.3.6.1.2.1.2.2.1.5

接口当前带宽[bps]

IfSpeed

WALK

.1.3.6.1.2.1.2.2.1.6

接口的物理地址

IfPhysAddress

WALK

.1.3.6.1.2.1.2.2.1.8

接口当前操作状态[up|down]

IfOperStatus

WALK

.1.3.6.1.2.1.2.2.1.10

接口收到的字节数

IfInOctet

WALK

.1.3.6.1.2.1.2.2.1.16

接口发送的字节数

IfOutOctet

WALK

.1.3.6.1.2.1.2.2.1.11

接口收到的数据包个数

IfInUcastPkts

WALK

.1.3.6.1.2.1.2.2.1.17

接口发送的数据包个数

IfOutUcastPkts

WALK

CPU及负载

OID

描述

备注

请求方式

. 1.3.6.1.4.1.2021.11.9.0

用户CPU百分比

ssCpuUser

GET

. 1.3.6.1.4.1.2021.11.10.0

系统CPU百分比

ssCpuSystem

GET

. 1.3.6.1.4.1.2021.11.11.0

空闲CPU百分比

ssCpuIdle

GET

. 1.3.6.1.4.1.2021.11.50.0

原始用户CPU使用时间

ssCpuRawUser

GET

.1.3.6.1.4.1.2021.11.51.0

原始nice占用时间

ssCpuRawNice

GET

. 1.3.6.1.4.1.2021.11.52.0

原始系统CPU使用时间

ssCpuRawSystem.

GET

. 1.3.6.1.4.1.2021.11.53.0

原始CPU空闲时间

ssCpuRawIdle

GET

. 1.3.6.1.2.1.25.3.3.1.2

CPU的当前负载,N个核就有N个负载

hrProcessorLoad

WALK

. 1.3.6.1.4.1.2021.11.3.0

ssSwapIn

GET

. 1.3.6.1.4.1.2021.11.4.0

SsSwapOut

GET

. 1.3.6.1.4.1.2021.11.5.0

ssIOSent

GET

. 1.3.6.1.4.1.2021.11.6.0

ssIOReceive

GET

. 1.3.6.1.4.1.2021.11.7.0

ssSysInterrupts

GET

. 1.3.6.1.4.1.2021.11.8.0

ssSysContext

GET

. 1.3.6.1.4.1.2021.11.54.0

ssCpuRawWait

GET

. 1.3.6.1.4.1.2021.11.56.0

ssCpuRawInterrupt

GET

. 1.3.6.1.4.1.2021.11.57.0

ssIORawSent

GET

. 1.3.6.1.4.1.2021.11.58.0

ssIORawReceived

GET

. 1.3.6.1.4.1.2021.11.59.0

ssRawInterrupts

GET

. 1.3.6.1.4.1.2021.11.60.0

ssRawContexts

GET

. 1.3.6.1.4.1.2021.11.61.0

ssCpuRawSoftIRQ

GET

. 1.3.6.1.4.1.2021.11.62.0

ssRawSwapIn.

GET

. 1.3.6.1.4.1.2021.11.63.0

ssRawSwapOut

GET

.1.3.6.1.4.1.2021.10.1.3.1

Load5

GET

.1.3.6.1.4.1.2021.10.1.3.2

Load10

GET

.1.3.6.1.4.1.2021.10.1.3.3

Load15

GET

内存及磁盘(1.3.6.1.2.1.25)

OID

描述

备注

请求方式

.1.3.6.1.2.1.25.2.2.0

获取内存大小

hrMemorySize

GET

.1.3.6.1.2.1.25.2.3.1.1

存储设备编号

hrStorageIndex

WALK

.1.3.6.1.2.1.25.2.3.1.2

存储设备类型

hrStorageType[OID]

WALK

.1.3.6.1.2.1.25.2.3.1.3

存储设备描述

hrStorageDescr

WALK

.1.3.6.1.2.1.25.2.3.1.4

簇的大小

hrStorageAllocationUnits

WALK

.1.3.6.1.2.1.25.2.3.1.5

簇的的数目

hrStorageSize

WALK

.1.3.6.1.2.1.25.2.3.1.6

使用多少,跟总容量相除就是占用率

hrStorageUsed

WALK

.1.3.6.1.4.1.2021.4.3.0

Total Swap Size(虚拟内存)

memTotalSwap

GET

.1.3.6.1.4.1.2021.4.4.0

Available Swap Space

memAvailSwap

GET

.1.3.6.1.4.1.2021.4.5.0

Total RAM in machine

memTotalReal

GET

.1.3.6.1.4.1.2021.4.6.0

Total RAM used

memAvailReal

GET

.1.3.6.1.4.1.2021.4.11.0

Total RAM Free

memTotalFree

GET

.1.3.6.1.4.1.2021.4.13.0

Total RAM Shared

memShared

GET

.1.3.6.1.4.1.2021.4.14.0

Total RAM Buffered

memBuffer

GET

.1.3.6.1.4.1.2021.4.15.0

Total Cached Memory

memCached

GET

.1.3.6.1.4.1.2021.9.1.2

Path where the disk is mounted

dskPath

WALK

.1.3.6.1.4.1.2021.9.1.3

Path of the device for the partition

dskDevice

WALK

.1.3.6.1.4.1.2021.9.1.6

Total size of the disk/partion (kBytes)

dskTotal

WALK

.1.3.6.1.4.1.2021.9.1.7

Available space on the disk

dskAvail

WALK

.1.3.6.1.4.1.2021.9.1.8

Used space on the disk

dskUsed

WALK

.1.3.6.1.4.1.2021.9.1.9

Percentage of space used on disk

dskPercent

WALK

.1.3.6.1.4.1.2021.9.1.10

Percentage of inodes used on disk

dskPercentNode

WALK

System Group
sysDescr 1.3.6.1.2.1.1.1
sysObjectID 1.3.6.1.2.1.1.2
sysUpTime 1.3.6.1.2.1.1.3
sysContact 1.3.6.1.2.1.1.4
sysName 1.3.6.1.2.1.1.5
sysLocation 1.3.6.1.2.1.1.6
sysServices 1.3.6.1.2.1.1.7
Interfaces Group
ifNumber 1.3.6.1.2.1.2.1
ifTable 1.3.6.1.2.1.2.2
ifEntry 1.3.6.1.2.1.2.2.1
ifIndex 1.3.6.1.2.1.2.2.1.1
ifDescr 1.3.6.1.2.1.2.2.1.2
ifType 1.3.6.1.2.1.2.2.1.3
ifMtu 1.3.6.1.2.1.2.2.1.4
ifSpeed 1.3.6.1.2.1.2.2.1.5
ifPhysAddress 1.3.6.1.2.1.2.2.1.6
ifAdminStatus 1.3.6.1.2.1.2.2.1.7
ifOperStatus 1.3.6.1.2.1.2.2.1.8
ifLastChange 1.3.6.1.2.1.2.2.1.9
ifInOctets 1.3.6.1.2.1.2.2.1.10
ifInUcastPkts 1.3.6.1.2.1.2.2.1.11
ifInNUcastPkts 1.3.6.1.2.1.2.2.1.12
ifInDiscards 1.3.6.1.2.1.2.2.1.13
ifInErrors 1.3.6.1.2.1.2.2.1.14
ifInUnknownProtos 1.3.6.1.2.1.2.2.1.15
ifOutOctets 1.3.6.1.2.1.2.2.1.16
ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17
ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18
ifOutDiscards 1.3.6.1.2.1.2.2.1.19
ifOutErrors 1.3.6.1.2.1.2.2.1.20
ifOutQLen 1.3.6.1.2.1.2.2.1.21
ifSpecific 1.3.6.1.2.1.2.2.1.22
IP Group
ipForwarding 1.3.6.1.2.1.4.1
ipDefaultTTL 1.3.6.1.2.1.4.2
ipInReceives 1.3.6.1.2.1.4.3
ipInHdrErrors 1.3.6.1.2.1.4.4
ipInAddrErrors 1.3.6.1.2.1.4.5
ipForwDatagrams 1.3.6.1.2.1.4.6
ipInUnknownProtos 1.3.6.1.2.1.4.7
ipInDiscards 1.3.6.1.2.1.4.8
ipInDelivers 1.3.6.1.2.1.4.9
ipOutRequests 1.3.6.1.2.1.4.10
ipOutDiscards 1.3.6.1.2.1.4.11
ipOutNoRoutes 1.3.6.1.2.1.4.12
ipReasmTimeout 1.3.6.1.2.1.4.13
ipReasmReqds 1.3.6.1.2.1.4.14
ipReasmOKs 1.3.6.1.2.1.4.15
ipReasmFails 1.3.6.1.2.1.4.16
ipFragsOKs 1.3.6.1.2.1.4.17
ipFragsFails 1.3.6.1.2.1.4.18
ipFragCreates 1.3.6.1.2.1.4.19
ipAddrTable 1.3.6.1.2.1.4.20
ipAddrEntry 1.3.6.1.2.1.4.20.1
ipAdEntAddr 1.3.6.1.2.1.4.20.1.1
ipAdEntIfIndex 1.3.6.1.2.1.4.20.1.2
ipAdEntNetMask 1.3.6.1.2.1.4.20.1.3
ipAdEntBcastAddr 1.3.6.1.2.1.4.20.1.4
ipAdEntReasmMaxSize 1.3.6.1.2.1.4.20.1.5
ICMP Group
icmpInMsgs 1.3.6.1.2.1.5.1
icmpInErrors 1.3.6.1.2.1.5.2
icmpInDestUnreachs 1.3.6.1.2.1.5.3
icmpInTimeExcds 1.3.6.1.2.1.5.4
icmpInParmProbs 1.3.6.1.2.1.5.5
icmpInSrcQuenchs 1.3.6.1.2.1.5.6
icmpInRedirects 1.3.6.1.2.1.5.7
icmpInEchos 1.3.6.1.2.1.5.8
icmpInEchoReps 1.3.6.1.2.1.5.9
icmpInTimestamps 1.3.6.1.2.1.5.10
icmpInTimestampReps 1.3.6.1.2.1.5.11
icmpInAddrMasks 1.3.6.1.2.1.5.12
icmpInAddrMaskReps 1.3.6.1.2.1.5.13
icmpOutMsgs 1.3.6.1.2.1.5.14
icmpOutErrors 1.3.6.1.2.1.5.15
icmpOutDestUnreachs 1.3.6.1.2.1.5.16
icmpOutTimeExcds 1.3.6.1.2.1.5.17
icmpOutParmProbs 1.3.6.1.2.1.5.18
icmpOutSrcQuenchs 1.3.6.1.2.1.5.19
icmpOutRedirects 1.3.6.1.2.1.5.20
icmpOutEchos 1.3.6.1.2.1.5.21
icmpOutEchoReps 1.3.6.1.2.1.5.22
icmpOutTimestamps 1.3.6.1.2.1.5.23
icmpOutTimestampReps 1.3.6.1.2.1.5.24
icmpOutAddrMasks 1.3.6.1.2.1.5.25
icmpOutAddrMaskReps 1.3.6.1.2.1.5.26
TCP Group
tcpRtoAlgorithm 1.3.6.1.2.1.6.1
tcpRtoMin 1.3.6.1.2.1.6.2
tcpRtoMax 1.3.6.1.2.1.6.3
tcpMaxConn 1.3.6.1.2.1.6.4
tcpActiveOpens 1.3.6.1.2.1.6.5
tcpPassiveOpens 1.3.6.1.2.1.6.6
tcpAttemptFails 1.3.6.1.2.1.6.7
tcpEstabResets 1.3.6.1.2.1.6.8
tcpCurrEstab 1.3.6.1.2.1.6.9
tcpInSegs 1.3.6.1.2.1.6.10
tcpOutSegs 1.3.6.1.2.1.6.11
tcpRetransSegs 1.3.6.1.2.1.6.12
tcpConnTable 1.3.6.1.2.1.6.13
tcpConnEntry 1.3.6.1.2.1.6.13.1
tcpConnState 1.3.6.1.2.1.6.13.1.1
tcpConnLocalAddress 1.3.6.1.2.1.6.13.1.2
tcpConnLocalPort 1.3.6.1.2.1.6.13.1.3
tcpConnRemAddress 1.3.6.1.2.1.6.13.1.4
tcpConnRemPort 1.3.6.1.2.1.6.13.1.5
tcpInErrs 1.3.6.1.2.1.6.14
tcpOutRsts 1.3.6.1.2.1.6.15
UDP Group
udpInDatagrams 1.3.6.1.2.1.7.1
udpNoPorts 1.3.6.1.2.1.7.2
udpInErrors 1.3.6.1.2.1.7.3
udpOutDatagrams 1.3.6.1.2.1.7.4
udpTable 1.3.6.1.2.1.7.5
udpEntry 1.3.6.1.2.1.7.5.1
udpLocalAddress 1.3.6.1.2.1.7.5.1.1
udpLocalPort 1.3.6.1.2.1.7.5.1.2
SNMP Group
snmpInPkts 1.3.6.1.2.1.11.1
snmpOutPkts 1.3.6.1.2.1.11.2
snmpInBadVersions 1.3.6.1.2.1.11.3
snmpInBadCommunityNames 1.3.6.1.2.1.11.4
snmpInBadCommunityUses 1.3.6.1.2.1.11.5
snmpInASNParseErrs 1.3.6.1.2.1.11.6
NOT USED 1.3.6.1.2.1.11.7
snmpInTooBigs 1.3.6.1.2.1.11.8
snmpInNoSuchNames 1.3.6.1.2.1.11.9
snmpInBadValues 1.3.6.1.2.1.11.10
snmpInReadOnlys 1.3.6.1.2.1.11.11
snmpInGenErrs 1.3.6.1.2.1.11.12
snmpInTotalReqVars 1.3.6.1.2.1.11.13
snmpInTotalSetVars 1.3.6.1.2.1.11.14
snmpInGetRequests 1.3.6.1.2.1.11.15
snmpInGetNexts 1.3.6.1.2.1.11.16
snmpInSetRequests 1.3.6.1.2.1.11.17
snmpInGetResponses 1.3.6.1.2.1.11.18
snmpInTraps 1.3.6.1.2.1.11.19
snmpOutTooBigs 1.3.6.1.2.1.11.20
snmpOutNoSuchNames 1.3.6.1.2.1.11.21
snmpOutBadValues 1.3.6.1.2.1.11.22
NOT USED 1.3.6.1.2.1.11.23
snmpOutGenErrs 1.3.6.1.2.1.11.24
snmpOutGetRequests 1.3.6.1.2.1.11.25
snmpOutGetNexts 1.3.6.1.2.1.11.26
snmpOutSetRequests 1.3.6.1.2.1.11.27
snmpOutGetResponses 1.3.6.1.2.1.11.28
snmpOutTraps 1.3.6.1.2.1.11.29
snmpEnableAuthenTraps 1.3.6.1.2.1.11.30

KairosDB 数据查询

KairosDB数据查询接口: http://localhost:8080/api/v1/datapoints/query

根据绝对时间来获取数据:

根据相对时间来获取数据:

也可以指定一个end_absolute和end_relative。如果未指定结束时间视为现在。关于更多的REST API信息关注后面内容。

例如:

zabbix开启中文语言 zabbix没中文语言选项(50)

zabbix是一个多语言监控系统,默认使用英文并且也支持中文语言,详见《zabbix汉化方法》,但是近期有人反映说zabbix里面看不到中文语言.请往下看

zabbix不支持中文图

Linux

zabbix中文

开启zabbix对中文的支持

原来zabbix默认把对中文的支持给关闭了,我们需要修改zabbix的php源文件. 修改站点根目录下include/locales.inc.php文件.

请喜欢运维生存时间的sa们继续关注,有任何疑问可加群或者文章后边留言

zabbix 监控 gearman

KairosDB 配置选项

KairosDB配置主要更改conf目录下的kairosdb.properties 文件。

它们的属性和说明如下所示:

kairosdb.hostname

描述:当报告内部指标时所使用的主机名

需要:可选

默认值:不设置该值,会使用hostname命令。

kairosdb.telnetserver.port

描述:Telnet服务端口。

需要:必需

默认值:4242

kairosdb.telnetserver.commands

描述:列出KairosDB支持的telnet命令。

需要:必需

默认值:put、version

kairosdb.service.telnet

描述:全包和类名来处理在Telnet请求的类。

需要:必需

默认值:org.kairosdb.core.telnet.TelnetServerModule

kairosdb.service.http

描述:全包和类名来处理在HTTP请求的类。

需要:必需

默认值:org.kairosdb.core.http.WebServletModule

kairosdb.service.reporter

描述:全包和类名来处理内部指标报表类。 如果没有指定,报告将关闭。

需要:可选

默认值:org.kairosdb.core.reporting.MetricReportingModule

kairosdb.reporter.period

描述:内部指标报告周期。

需要:如果有指定kairosdb.service.reporter 则必需

默认值:1

kairosdb.reporter.period_unit

描述:与kairosdb.reporter.period结合使用。单位有:milliseconds, seconds, minutes, days

需要:如果有指定kairosdb.service.reporter 则必需

默认值:minutes

kairosdb.jetty.port

描述:KairosDB UI使用的端口。设置为0将禁用HTTP端口。

需要:可选。必需设置该属性或kairosdb.jetty.ssl.port属性

默认值:8080

kairosdb.jetty.static_web_root

描述:Jetty服务的web路径

需要:必需

默认值:webroot

kairosdb.jetty.basic_auth.user

描述:设置基本身份验证的用户名

需要:可选

默认值:None

kairosdb.jetty.basic_auth.password

描述:设置基本身份验证的密码

需要:可选

默认值:None

kairosdb.jetty.ssl.port

描述:SSL使用的端口

需要:可选

默认值:443

kairosdb.jetty.ssl.keystore.path

描述:SSL证书完整路径。

需要:可选

默认值:

kairosdb.jetty.ssl.keystore.password

描述:key秘钥

需要:如果有设置kairosdb.jetty.ssl.keystore.path则必需。

默认值:

kairosdb.service.datastore

描述:全包和类名来处理数据存储请求的类。

需要:org.kairosdb.datastore.h2.H2Module 或 org.kairosdb.datastore.cassandra.CassandraModuleor

默认值:org.kairosdb.datastore.h2.H2Module 或 net.opentsdb.kairosdb.HBaseModule

kairosdb.datastore.h2.database_path

描述:H2数据库目录

需要:如果选择H2作为数据库必需

默认值:build/h2db

kairosdb.datastore.cassandra.host_list

描述:逗号分隔的一些列Cassandra节点

需要:如果选择Cassandra作为数据库必需

默认值:localhost:9160

kairosdb.datastore.cassandra.replication_factor

描述:Cassandra复制因子

需要:如果选择Cassandra作为数据库必需

默认值:1

kairosdb.datastore.cassandra.write_delay

描述:指标缓存延迟写入Cassandra

需要:如果选择Cassandra作为数据库必需

默认值:1000

kairosdb.datastore.cassandra.write_buffer_max_size

描述:写缓存最大大小。当缓存满时数据写入

需要:如果选择Cassandra作为数据库必需

默认值:500000

kairosdb.datastore.cassandra.single_row_read_size

描述:当从Cassandra读取单一行的缓冲区大小

需要:如果选择Cassandra作为数据库必需

默认值:10240

kairosdb.datastore.cassandra.multi_row_read_size

描述:当从Cassandra读取多行时的缓冲区大小

需要:如果选择Cassandra作为数据库必需

默认值:1024

kairosdb.datastore.cassandra.auth.[prop name]

描述:Cassandra身份验证,如:kairosdb.datastore.cassandra.auth.user=admin

需要:可选

默认值:

kairosdb.datastore.cassandra.increase_buffer_size_schedule

描述:如果Cassandra负载高,KairosDB将降低写入缓冲区的大小。 此属性标识KairosDB试图增加缓冲区大小递增频率,直到它恢复到kairosdb.datastore.cassandra.write_buffer_max_size。

需要:如果选择Cassandra作为数据库必需

默认值:/5 ?

kairosdb.datastore.hbase.timeseries_table

描述:存储指标的HBase表名

需要:如果选择HBase作为数据库必需

默认值:tsdb

kairosdb.datastore.hbase.uinqueids_table

描述:唯一ID的HBase表名

需要:如果选择HBase作为数据库必需

默认值:tsdb-uid

kairosdb.datastore.hbase.zoo_keeper_quorum

描述:Zookeeper quorum主机

需要:如果选择HBase作为数据库必需

默认值:localhost

kairosdb.datastore.hbase.zoo_keeper_base_dir

描述:Zookeeper基本目录

需要:如果使用带Zookeeper的HBase则必需

默认值:

kairosdb.datastore.hbase.auto_create_metrics

描述:如果为true,如果不存在的指标将被创建。如果为FALSE,新的指标将被拒绝。

需要:如果选择HBase作为数据库必需

默认值:true

kairosdb.service.oauth

描述:全包和处理OAuth的通信类的类名。

需要:可选

默认值:org.kairosdb.core.oauth.OAuthModule

kairosdb.oauth.consumer.[consumer key]

描述:OAuth秘钥

需要:使用OAuth则必需

默认值:

kairosdb.job.cache_file_cleaner_schedule

描述:缓存文件清理进度

需要:

默认值:0 0 12 ? * SUN *

将数据推入KairosDB

可以通过telnet协议(4242端口)或REST协议(8080端口)将数据提交到KairosDB,端口可以在kairosdb.properties文件中修改。

通过telnet提交数据

数据格式为:

Metric name: 指标名称只能是字母数字-_. 。

Time stamp:时间戳可以是毫秒或秒。秒是为了和OpenTSDB兼容。Cassandra支持毫秒数据存储。注意:REST API只支持毫秒时间戳。

Tag:一系列的key=value键值对。

注意:发送的数据后面必须跟一个换行符。

例如:

通过REST提交数据

提交的URL地址为:http://localhost:8080/api/v1/datapoints

在REST API情况下,时间戳始终被视为自1970年1月1日的毫秒。如果写入HBase会被截断到秒。

后面再说REST API。

Graphite协议

KairosDB 支持Graphite 协议。具体参见:https://graphite.readthedocs.org/en/latest/feeding-carbon.html

这可以让你整合KairosDB到现有的应用程序中将数据推送到Graphite。

KairosDB的carbon协议插件:https://github.com/kairosdb/kairos-carbon

KairosDB 入门教程

安装

KairosDB 需要运行在java1.6及以上版本。以及设置java环境变量。

KairosDB 下载地址:https://github.com/kairosdb/kairosdb/releases

1. 将KairosDB解压到你想位于的目录下

2. 编辑conf/kairosdb.properties文件,更改 kairosdb.service.datastore属性,决定你要使用的数据库。默认是内存H2数据库,这个比较慢。

3. 执行./kairosdb run启动KairosDB。

更改系统文件句柄限制

更改数据存储

KairosDB 后端数据存储可以有多个选择。在默认情况下KairosDB使用内存H2数据库来存储数据点数据。要更改存储方式编辑kairosdb.properties 文件修改kairosdb.service.datastore属性。

使用H2

这是默认情况下,在开发环境下,可以这么来配置。生产环境下不建议。

配置选项
kairosdb.datastore.h2.database_path H2数据库目录

删除数据库目录和重新启动KairosDB会导致数据丢失。

使用Cassandra

对Cassandra的默认配置是使用宽行。每一行设置为包含3周的数据,原因是如果你每毫秒写一个指标,3周的数据量刚刚超过10亿列。而Cassandra有一个20亿列的限制。

行的大小有点小的疑惑。当查询数据时,越多的数据位于当行上执行的效率高。这并不意味着Cassandra只能保存3周的数据,而是意味着在写入到新行前将3周的数据写入到同一行。 这个可以看看Cassandra模式。

更改read_repair_chance,这个值告诉Cassandra多久需要进行读修复。读修复默认是1,也就100%改变。推荐值为0.1,10%的改变。登录cassandra-cli执行下面的命令更改:

配置选项
kairosdb.datastore.cassandra.host_name  Cassandra 的主机名或IP
kairosdb.datastore.cassandra.port Cassandra 服务端口号
kairosdb.datastore.cassandra.replication_factor 当数据写入Cassandra时复制因子
kairosdb.datastore.cassandra.row_width 在一行里的毫秒数。默认为7257600000,也就是12周。加载数据后更改此值会导致意想不到的结果。
kairosdb.datastore.cassandra.write_delay 将数据写入到Cassandra,后台线程等待的时间。允许批量插入数据到存储。
kairosdb.datastore.cassandra.single_row_read_size 当读单行时的列数。在性能与内存之间平衡。当查询行健索引和最初多获取后的持续查询时使用。
kairosdb.datastore.cassandra.multi_row_read_size 一个查询读取初始多个get的列数。如果数据有极少的标记,该值设置大些。如果你的指标有很多标记组合低于该值,可能会遇到内存不足的问题。

使用HBase

需要手动创建表。创建表的脚本位于源码目录下./src/scripts/create_hbase_table.sh

注意:HBase目前只支持秒级别数据。

配置选项
kairosdb.datastore.hbase.timeseries_table 时间序列表名
kairosdb.datastore.hbase.uinqueids_table 唯一ID表名
kairosdb.datastore.hbase.zoo_keeper_quorum zoo keeper quorum主机名
kairosdb.datastore.hbase.zoo_keeper_base_dir
kairosdb.datastore.hbase.auto_create_metrics 自动创建指标

使用远程数据存储

将远程的KairosDB服务器作为本地的KairosDB实例的存储并将数据发送到远程。数据以JSON格式存储在目录下。可配置的后台线程将压缩数据并将数据点上传到远程KairosDB实例上。

配置选项
kairosdb.datastore.remote.data_dir 数据点目录,默认当前目录。
kairosdb.datastore.remote.remote_url 将数据发送到KairosDB 实例的URL,如: http://10.10.10.10:8080
kairosdb.datastore.remote.schedule Quartz cron schedule 上传收集数据的频率

启动和关闭服务

通过kairosdb.sh脚本来完成。

在前台启动服务:

在后台启动服务:

停止服务:

# ./kairosdb.sh stop

采集数据

简单的收集些数据。

可视化界面

KairosDB自带了一个可视化界面,不过与OpenTSDB的可视化界面对比,感觉比较糟糕。

访问地址:http://10.0.101.145:8080/index.html

cassandra

cassandra

KairosDB 监控系统介绍

KairosDB是一个快速可靠的分布式时间序列数据库,主要用于Cassandra来做底层存储,当然也可以使用HBase。KairosDB是在OpenTSDB基础上重写的。 KairosDB主页: https://code.google.com/p/kairosdb/

对于运维工程师而言,OpenTSDB可以获取基础设施和服务的实时状态信息,展示集群的各种软硬件错误,性能变化以及性能瓶颈。对于管理者而言,OpenTSDB可以衡量系统的SLA,理解复杂系统间的相互作用,展示资源消耗情况。集群的整体作业情况,可以用以辅助预算和集群资源协调。对于开发者而言,OpenTSDB可以展示集群的主要性能瓶颈,经常出现的错误,从而可以着力重点解决重要问题。

与OpenTSDB相比KairosDB 改进的地方:

  • Uses Guice to load modules.
  • Incorporates Jetty for Rest API and serving up UI.
  • Pure Java build tool (Tablesaw)
  • UI uses Flot and is client side rendered.
  • Ability to customize UI.
  • Relative time now includes Month and supports leap years.
  • Modular data store interface supports:
    • HBase
    • Cassandra
    • H2 (For development)
  • Milliseconds data support when using Cassandra.
  • Rest API for querying and submitting data.
  • Build produces deployable tar, rpm and deb packages.
  • Linux start/stop service scripts.
  • Faster.
  • Made aggregations optional (easier to get raw data).
  • Bug fix with returning incorrect data.
  • Added abilities to import and export data.
  • Aggregators can aggregate data for a specified period.
  • Aggregators can be stacked or “piped” together.
  • Grouping by tags, time range, or value.

KairosDB 删除的地方:

  • Removed all telnet commands except for put
  • No longer supports URL query

KairosDb 特性:

Data Store Support

KairosDB 可以使用cassandra、HBase、H2(开发环境中)作为后端存储。默认情况下,KairosDB运行在H2数据库下,开发环境不需要cassandra或HBase。

Time Granularity

如果使用cassandra,KairosDB 支持毫秒的粒度。HBase 仅支持秒级别。

Tags

数据点可以跟上标记,一个标记是一个键值对。

Submit Metrics Via Telnet

使用telnet是一个非常简单的方式来添加指标的方法。语法简单、使用方便。

REST API

支持REST API来添加查询指标。

Aggregators

在查询时,使用聚合来处理数据点。KairosDB带有聚合的默认设置,聚合器可以很容易地进行编码,并加入到扩展默认功能。

Grouping

查询API可以通过标记、时间范围、值来对数据点进行分组。

Filtering

查询API通过标记来筛选过滤返回的一组数据。

Graphing

KairosDB 有一个内置的web服务来绘图。用户界面允许您在一个折线图建立查询并显示结果数据点。将JSON发送到REST API也可以显示出结果,因此如果你想直接调用KairosDB对结果进行解析。

CORS

KairosDB支持跨地资源共享。这个主要是js跨域。基本上,可以让你在其他网站上通过JavaScript来访问KairosDB数据。

Compressed Upload

KairosDB支持gzip压缩指标数据。如果你需要上传大量的数据让服务器批量处理,可以用gzip压缩JSON并上传,设置内容类型为application/gzip。

KairosDB 对时间粒度的处理

原来的OpenTSDB项目只处理秒级别的数据。KairosDB重写了该项目,并引进毫秒级别粒度的目标。

为了实现这两个目录,做了下面的处理:

1. Telnet协议接收秒和毫秒级别的时间值。如果时间值小于3,000,000,000,就乘以 1,000所得到毫秒值存入到数据库。

2. REST API只接受毫秒时间值。

3. Cassandra接收并存储毫秒级的时间值。

4. HBase对毫秒级时间值进行处理,除以1,000所得的秒值存入到数据库。

KairosDB 导入和导出数据

在命令行下,可以从KairosDB导入和导出数据。

导出数据

从KairosDB导出数据命令如下:

导出的数据格式是每行一个指标的JSON对象。

导出时,还可以进行压缩:

导出参数

-f <filename> : 导出到文件名。如果没有指定,以标准输出输出。

-n <metricName> : 导出指定的指标数据。如果没有指定,导出所有的指标。

导入数据

导入数据到KairosDB命令如下:

如果导入的数据有压缩:

导入参数

-f <filename>:指定要导入的文件,如果没有指定,则数据来自标准输入。

性能测试

环境如下: Intel i5 (4 cores) 12 Gigs ram。两块SSD硬盘,另一个是普通硬盘。Cassandra单实例和KairosDB在同一台服务器上运行。

数据量:31,341,782个指标,其中大部分具有相同的指标和标签,这意味着会被写入到单一行。

结果如下:

Cassandra Memory Location of Data Metrics per second
1 Gig data and commit log on SSD 74,623
1 Gig data on platter, commit log on SSD 93,837
2 Gig data on platter, commit log on SSD 132,804

 

KairosDB 状态统计

KairosDB 将自身的状态统计指标写入到数据库,因此可以监控服务器的性能。可以通过用户界面查看这些统计信息。

这些内部指标默认情况下每分钟写入一次。写入频率可以更改,修改 kairosdb.properties文件:

kairosdb.reporter.period_unit 值可以有:milliseconds, seconds, minutes, hours,  days。

更改这些属性需要重启KairosDB服务使其生效。

kairosdb.service.reporter 删除该属性,可以关闭统计。

指标报告:

kairosdb.datastore.key_write_size:最后一次写入时,已写入的行数。

kairosdb.datastore.write_size : 最后一次写入时,已写入的数据点数量。

kairosdb.datastore.write_buffer_size:最后一次写入时,写缓冲区大小。

kairosdb.protocol.http_request_count :对于每个HTTP请求方法的统计数量。如method=query。

kairosdb.protocol.telnet_request_count : 对于每个telnet请求方法的统计数量。如method=put。

kairosdb.jvm.free_memory:JVM中可用的空闲内存量。

kairosdb.jvm.total_memory:JVM总内存量。

kairosdb.jvm.max_memory:JVM将尝试使用的最大内存量。

kairosdb.jvm.thread_count: 运行在JVM中的线程总数。

文档上的与实际的有些不同。实际的指标如下:

cassandra

zabbix windows性能计数器使用详解(90)

概述

windows下的性能计数器让zabbix监控更加轻松,直接获取性能计数器的数值即可完成windows监控。性能计数器如下:

获取所有性能计数器命令:

数字对应

如上的perf_counter[“\Processor(0)\Interrupts/sec”],里面的\Processor(0)\Interrupts/sec很难记忆,而且不同的windows系统名称不可能不相同,这可能会导致获取到错误的值。基于此,windows有相应的数字与名称对应,比如:system对应2,Memory对应4,有几千个性能计数器名称与数字对。那怎么找到名称对应的数字呢?打开注册表Regedit,找到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009,打开key counter

Windows

在win2008下,有5000多行,大概2000多对。贴一部分文字出来吧

自定义性能计数器key

编辑agentd配置文件,添加PerfCounter自定义内容

或者

UserPerfCounter1与UserPerfCounter2其实是一样的,4取代了Memory,24取代了Page Reads/sec,虽然说可读性差一点,但是推荐大家使用数值。

关于更详细的windows计数器item key介绍,请继续关注ttlsa.com

zabbix报警媒介:Ez Texting(65)

Ez Texting是zabbix的技术合作伙伴,主要提供短信服务,用手机注册账号,便可以使用它来发送短信了,不过他只支持美国和加拿大的手机号码,并且应该是收费的。没有美国/加拿大手机号码的朋友请绕行,先了解的请继续往下看。

Administration(管理)→Media types(媒介类型)->点击创建

E-mail

ez-texting

参数说明:

 选项 描述
 Name  媒介名称,看着起名
 Type  选择Ez Texting,如果你没有账号,你可以到https://app.eztexting.com注册(没有手机号码绕行)
username 你的ez账号
Password Ez密码
 Message text limit
文本消息限制
USA (160 characters),美国一条短信支持160个字符
Canada (136 characters),加拿大一条短信支持136个字符

使用媒介

定义好了媒介之后,我们需要把这媒介指定给用户。

Administration->Users->打开用户配置->media type里面添加刚增加的媒介

E-mail

ez-texting-media

参数说明

选项 描述
Type 选择媒介名称,此处选Ez Texting
Send to 发短信给谁,填手机号码
When active 发送时间,只有在这个时间段内才会发短信
Use if severity 发送短信的触发器级别
Status 当前媒介状态
Enabled – 使用中.
Disabled – 禁用中.

zabbix实战监控WEB网站性能(58)

一直在纠结用什么实例来给大家演示呢?想来想去还是官方的好,那我们怎么用zabbix监控web性能和可用性呢?我们这边分为几个步骤:打开网站、登陆、登陆验证、退出,一共4个小step,看实例。

检测流程

1. 打开网站:如果http code为200,并且响应的html中包含Zabbix SIA表示打开成功(zabbix页面有这个标示)

2. 登陆后台:post用户名和密码到index.php,如果响应200,那表示post成功。并且通过正则表达式从响应的html中匹配sid,这个sid也就是一个宏变量,退出可以使用到

3. 验证登陆:打开首页,检索html中是否包含Profile(只有登陆成功,才会有Profile出现)

4.退出账号:传递参数sid给index.php即可退出,响应200即表示退出成功。

我们可以使用上节讲到的item key来获取每个step的速度以及响应时间或者说最新的一个错误消息,大家自己去研究吧,不难

创建WEB场景

configuration->Host->你的主机->web->右上角Create scenario

nagios

Create scenario – 01

Name:监控项的名称

Application:放到哪个应用中,《什么是Application

Authentication:是否有http的基本认证,大部分情况下是None,难不成用户进来还需要经过一次认证?

Update interval:更新周期,默认60秒,多久跑一次

Retries:重试次数

Agetn:模拟浏览器

HTTP proxy:代理,如果你的站点有多台服务器,那么请写上你目标服务器ip和端口,例如http://10.9.0.2:80,默认端口可不是80,别忘记80了

Variables:宏变量,后面会用到。想了解请点《zabbix用户宏macro

web监控阶段1:打开首页

nagios

Create scenario – 02

对step做一个说明:

name:当前step名称,item key中可以用到

url:需要检测的网址

POST:你需要post提交上去的内容,例如user=123&password=123456,,或者使用宏变量user={user}&password={password},如果支持GET,那么可以直接写到URL里面

variables:变量,这边定义宏变量后续的step可以使用

Timeout:超时时间,默认15秒

Required string:响应的内容中必须包含的字符串,否则失败

Required status codes:响应代码必须包含在里面,多个响应代码用逗号分隔,例如200,301,302

 

web监控阶段2:登陆

 

nagios

Create scenario – 03

post账号和密码上去,关于post在前面已经提过了。

WEB监控阶段3:验证登陆

nagios

Create scenario – 04

WEB监控阶段4:退出账号

nagios

Create scenario – 05

 

WEB网站检测配置完成

记得保存账号

nagios

Create scenario – 06

 

查看结果

monitorning->web->筛选出你的主机->查看“WEB性能监控_FOR_TTLSA”,结果如下图

各个阶段的响应时间、速度、返回状态码以及总的响应时间

nagios

Create scenario – 07

下图是下载速度的图表,包含各个阶段

nagios

Create scenario – 08

下图是响应时间的图表

nagios

Create scenario – 09

以上是没问题的信息,那么出现故障是什么样子呢?我把密码改掉,演示给大家看看下图,在LOGIN IN这个step就出错了,拿不到SID

nagios

Create scenario – 10

那么Required String不匹配又是什么样子呢?我们把阶段3Login CHECK的required string的Profile改成Profile1试试。看看结果

nagios

web scenario – 11

 

好了,web监控的实例就完成了。

 

WEB监控所有文章

1. zabbix监控web服务器访问性能(56)

2. zabbix web监控项item详解(57)

3. zabbix实战监控WEB网站性能(58)

3. zabbix监控api接口性能及可用性 天气预报api为例(59)

zabbix监控api接口性能及可用性 天气预报api为例(59)

现在各种应用都走api,例如淘宝,天气预报等手机、pad客户端都是走api的,那么平时也得对这些api做监控了。怎么做呢?zabbix的web监控是不二选择了。今天就以天气预报api作为一个例子。

天气预报API

天气预报api地址:http://www.weather.com.cn/data/sk/101010100.html

api正常情况下会返回如下数据:

ZABBIX WEB场景配置

configuration->host->您的主机->web->点击右上角create scenario

Linux

zabbix监控api – 创建

点击step,输入如下

Linux

zabbix监控api – step

查看监控结果

monitoring->web->选择相应的hosts,点击如下的“监控天气预报API_FOR_TTLSA”

Linux

zabbix监控api – 查看结果

Linux

zabbix监控api – 整体情况

Linux

zabbix监控api – 速度

Linux

zabbix监控api – 响应时间

创建触发器

至于怎么创建触发器,我这边就不多说了,请看关于触发器的文章《zabbix创建触发器》,当有故障发生,便可以发送故障报警。

 

zabbix监控api说明

以上只是一个简单的例子,具体应用看大家了,比如说可以监控注册、获取新闻列表、获取评论等等接口是否可以使用,以及这些接口的一些性能。

 

WEB监控所有文章

1. zabbix监控web服务器访问性能(56)

2. zabbix web监控项item详解(57)

3. zabbix实战监控WEB网站性能(58)

4. zabbix监控api接口性能及可用性 天气预报api为例(59)

zabbix使用IT services 了解服务器SLA整体情况(60)

什么是IT Services

服务器或者某项服务、业务的可用率,不懂技术的上级领导会过问最近服务器可用率如何、所有api的状况怎么样?通常一些技术人员会说负载怎么样,哪些cpu使用率怎么样,硬盘使用情况,api的响应速度都保持在多少、响应时间都在多少?还没等说完,领导就打断了。他不关心这些细节,更不懂这些技术。他想要的是一个结果。比如说服务器故障率在0.001,api的响应率在99.99%。这就是IT Services的功能。

IT service结构如下:

IT Sverices示例

举个例子,API的SLA,各个子Service都有他的可用率,然后XXX网站API可以统计到整个API的可用率,当领导过问起来,给他看这个就行了。

那这些可用率是怎么计算出来的呢?根据你的触发器,除了未分类和信息这两类,其他严重性级别,例如警告(warnning)等等都会记入故障率

 

配置IT Services

configuration->IT Services->单击root->Add services

IT Services

zabbix it service – 创建

创建服务器在线率

IT Services

zabbix it services 服务器在线率

service说明

name:名称

Parent service:上级节点,这边是root

Status calculation algorithm:计算付费,共有三个选项

  • Do not calculate – 不加入计算
  • Problem, if at least one child has a problem – 子项至少一个发生故障(一般用这个)
  • Problem, if all children have problems – 所有子项都发生故障,才加入计算

Acceptable SLA (in %):可接受的可用率百分比,如果在大于这个百分比那么现实绿色,如果小于那么就是红色显示

Trigger:触发器,可以选触发器也可以不选,不过大家要记住,可用率计算的就是这些触发器的可用率,如果没有触发器根本无法计算。最上级的可以不选触发器,子项一定记得选择触发器,否则就失去意义了。

添加子service

IT Services

zabbix-it-service-03

IT Services

zabbix-it-service-04

依赖标签

这边我们不增加依赖,在后面我们专门来谈谈这个依赖

IT Services

zabbix-it-service-05

Time这边如果默认,那么就是24×7

IT Services

zabbix-it-service-06

Time说明

Service times:定义好的工作时间

New service time:一共有三个选项

  • Downtime – 在这个时间段,不计入SLA
  • One-time downtime – 在这个时间段,不计入SLA,指定一个时间(只有一次)
  • Uptime :工作时间,在这个时间内出现故障都计入SLA

看看效果,monitoring–>IT services

IT Services

zabbix-it-service-07

IT Services依赖

分为hard和soft依赖,例如我们增加一个C服务器,他需要依赖其他IT树下的services,首先它不能链接触发器,在依赖那边选择其他树下依赖即可,可以添加多个,软依赖是灰色的标识,硬件依赖则是直接把整个service挪过来。如果C服务器使用软依赖,那么可以直接删除C服务器Service,如果是硬依赖,需要先移除依赖,才能删除。

IT Services

service-soft-hard-01

soft不勾选,表示为硬依赖

IT Services

service-soft-hard-02

如下,原本“测试”和“服务器在线率”在同一个层级,都归属于root,但是加了硬依赖之后,直接到了C服务器只下了

IT Services

service-soft-hard-03

接着来看看软依赖

勾选soft,就是软依赖了

IT Services

service-soft-hard-04

看下图,和硬依赖很不相同,C服务器下的测试是灰色的,并且“测试”依旧和“服务器在线率”在同一个层次。

IT Services

service-soft-hard-05

此时你可以直接删除C服务器,但是硬依赖的情况下不行哦。

好了,zabbix IT SERVICES就到这里了,可以给领导开个权限,这样他也可以了解到服务器整体状况了。运维们也需要经常看,毕竟这是调整的一个一句。

学习zabbix的继续关注运维生存时间zabbix教程,后续还有更多相关文章。

zabbix报警媒介:Jabber(64)

Jabber有第三方插件,能让Jabber用户和MSN、YahooMessager、ICQ等IM用户相互通讯。因为Google遵从Jabber协议,并且Google已经将Gtalk的服务器开放给了其它的Jabber服务器。所以PSI、Giam等Jabber客户端软件支持GTalk用户登陆。

jabberXMPP(可扩展消息处理现场协议)是基于可扩展标记语言(标准通用标记语言下的一个子集、外语缩写:XML)的协议,它用于即时消息(IM)以及在线现场探测。它在促进服务器之间的准即时操作。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息,即使其操作系统和浏览器不同。XMPP的技术来自于Jabber,其实它是 Jabber的核心协定,所以XMPP有时被误称为Jabber协议。Jabber是一个基于XMPP协议的IM应用,除Jabber之外,XMPP还支持很多应用。

IEEE XMPP工作组(一个工程师和程序员联盟)正在改编XMPP以用作互联网工程任务组(IETF)技术。XMPP最终有望使用鉴定、访问控制、高级隐私、逐跳加密、端端加密以及与其它协议的相容等应用来支持IM。

zabbix报警媒介:SMS(63)

介绍

服务器安装串口GSM短信猫之后,zabbix可以使用它来发送短信通知给管理员,如下注意事项:

  • 串行设备速度要与GSM猫相匹配(linux下默认为/dev/ttyS0),zabbix无法设置设置串行设备速率
  • zabbix有对串行设备的读写全乡,可以使用ls -l /dev/ttyS0查看设备权限
  • 请禁用你GSM手机卡的PIN码

zabbix测试过的GSM猫如下

  • Siemens MC35
  • Teltonika ModemCOM/G10

zabbix配置媒介SMS

Administration->Media types->媒介类型选择SMS,和email的配置方法是一样的,直接上参数吧。

 

选项 描述
Description 媒介名称
Type 类型
GSM modem SM modem串行设备,默认为:/dev/ttyS0

 

zabbix使用媒介SMS

Administration->Users->打开用户配置->media type里面添加刚增加的媒介

选项 描述
Type 选择媒介名称,此处选SMS
Send to 发短信给哪个手机号码
When active 发送时间,只有在这个时间段内才会发短信
Use if severity 发送短信的触发器级别
Status 当前媒介状态
Enabled – 使用中.
Disabled – 禁用中.

用短信猫发送短信的公司都很有钱,我从来只用邮件~

zabbix报警媒介:email(62)

报警信息将会使用系统自带的sendmail发送,配置比较简单

配置媒介Email

Administration→Media types->Click on Create media type

email

media_email

 选项 描述
 Name  媒介名称,看着起名
 Type  选择Email
 SMTP server SMTP服务器
 SMTP helo SMTP helo值, 通常情况下是顶级域名
 SMTP email 这个邮件地址会显示到收件人的From里
可用邮箱地址:
zabbix@company.com (只包含邮箱地址,不需要尖括号括起来)
Zabbix HQ <zabbix@company.com> (显示名和邮箱地址,邮箱地址使用尖括号)
∑Ω-monitoring <zabbix@company.com> (显示名称为UTF8格式)
不可用的邮箱地址
Zabbix HQ zabbix@company.com (需要尖括号)
“Zabbix\@\<H(comment)Q\>” <zabbix@company.com>不支持转义

使用媒介

定义好了媒介之后,我们需要把这媒介指定给用户。

Administration->Users->打开用户配置->media type里面添加刚增加的媒介

email

email

参数说明

选项 描述
Type 选择媒介名称,此处选Email
Send to 发邮件给谁,例如support@ttlsa.com,也可以使用显示名
When active 发送时间,只有在这个时间段内才会发邮件
Use if severity 发送邮件的触发器级别
Status 当前媒介状态
Enabled – 使用中.
Disabled – 禁用中.

zabbix报警媒介介绍(61)

zabbix触发器到了要发送通知的情况下,需要一个中间介质来接收并传递它的消息给运维们,以往用nagios,通常用脚本发送邮件或者发送飞信来达到报警。这个脚本实际上就是一个媒介了。

zabbix有如下介质:

E-mail

使用sendmail发送邮件,从这边出去的邮件基本是垃圾邮件,我一直不喜欢用

SMS

需要短信设备,没有,一直都没用过这东西

Jabber

Jabber有第三方插件,能让Jabber用户和MSN、YahooMessager、ICQ等IM用户相互通讯。因为Google遵从Jabber协议,并且Google已经将Gtalk的服务器开放给了其它的Jabber服务器。所以PSI、Giam等Jabber客户端软件支持GTalk用户登陆。国内没啥人用

Ez Texting

给用户手机发短信,貌似只支持美国和加拿大

Custom alertscripts

自定义脚本,把信息传递给脚本,我们在脚本里使用sendEmail(不要和sendmail搞混了)、飞信发短信、调用短信接口发送短信等等。

zabbix snmp自定义OID nginx监控实例(55)

为什么要自定义OID?

前面的文章我们已经讲过zabbix如何使用snmp监控服务器,但是他有一个很明显的局限性:只能监控定义好的OID项目,假如我们想知道nginx进程是否在运行?在没有zabbix agent的情况下,我们该怎么做呢?接下来就用这个实力来讲解自定义OID

 

确认SNMP OID是否存在

首先我们需要找一个oid是否被系统暂用,比如.1.3.6.1.4.1.2021.5000

如上说明不存在

增加自定SNMP OID

编写脚本

 

修改配置

获取snmp信息

以下获取自定义的oid的所有数据,第一行便是我们需要获取的数据,那么在zabbix中写oid .1.3.6.1.4.1.2021.5000.4.1.2.11.99.104.101.99.107.95.110.103.105.110.120.1

创建snmp item

nginx

snmp-oid

获取最新数据

nginx

snmp获取nginx数据

接下来创建触发器以及报警,我就不多说了,大家可以参考《zabbix触发器

 

zabbix snmp监控所有文章

1. zabbix snmp类型 无需安装agent也能监控(51)

2. snmp安装配置 zabbix snmp监控准备(52)

3. snmp v3的安全配置 snmp认证与加密配置(53)

4. SNMP OID列表 监控需要用到的OID

5. zabbix单位符号Unit symbols(32)

zabbix API二次开发使用与介绍(68)

喜欢需要理由吗?需要吗?当然需要,zabbix的那么多功能足以让你喜欢她,现在还有zabbix API,zabbix真让我疯了,太牛逼了,太让人喜欢了。有zabbix API我们可以做很多,自己开发web界面、开发手机端zabbix、获取zabbix指定数据、创建zabbix监控项等等。

zabbix API开发库

zabbix API请求和响应都是json,并且还提供了各种语法的lib库,http://zabbix.org/wiki/Docs/api/libraries,包含php、c#、PythonPerl、go等等语言,简单看了下phpzabbixapi,使用非常方便。

请求zabbix API

post json数据到api接口地址,例如你得zabbix地址是http://company.com/zabbix,那么你得接口地址是:http://company.com/zabbix/api_jsonrpc.php,必须包含content-type头,值为application/json-rpc, application/json or application/jsonrequest之一。

 

zabbix API登陆

获取auth token(登陆)

在操作zabbix之前,我们必须先登陆zabbix,得到token,以后的操作带着这个token即可,要不然肯定没权限。

请求的json如下:

 

属性说明
jsonrps – JSON-RPC版本,基本上用2.0就行了;
method – 调用的API方法,方法列表请上官网;
params – 需要传递的参数,这边是user和password;
id – 请求标志;
auth – 用户token,这边使用null,因为还没通过验证

验证成功,会返回如下json数据

result便是我们要德token数据,id对应请求的id。

zabbix api检索主机

通过验证之后,我们带着token使用host.get获取主机列表,请求的json如下:

获取到如下数据

请使用你的程序处理一下即可。

 

zabbix API就是这么简单,请求、响应然后处理,更多API方法请直接上官方文档,里面有几百个方法等着你。如果你使用zabbix二次开发,千万不要直接操作zabbix数据,太…..,为何不使用zabbix API。

windows安装zabbix监控(89)

windows下安装zabbix agent,方法非常简单。首先到zabbix官方下载windows版本agent,地址:http://www.zabbix.com/download.php,找到“Zabbix pre-compiled agents”选择相应的版本下载。安装方法很简单,下载–>解压到目录–>修改配置文件–>安装服务–>启动–>web中添加HOST即可。

文件解压到指定目录

如下图即可

windows zabbix agentd安装

bin:zabbix_get.exe、zabbix_sender.exe连个文件

sbin:zabbix_agentd.exe 客户端主进程

etc:配置文件

dev:不用理会

修改配置文件

修改etc/zabbix_agentd.conf,只要修改以下几个配置即可(与linux配置文件没什么差别),只需要修改以下三个,其他参数都默认。

安装服务

 

启动zabbix agentd

开始->>运行->> services.msc,双击zabbix agent,点击启动。

windows zabbix agentd安装

添加Host

这步略过,请参考前面的《zabbix主机与组配置(12)

效果图

windows zabbix agentd安装

 

zabbix如何使用SNMP获取数据 SNMP监控实例(54)

前面几篇文章已经对zabbix snmp监控类型以及如何安装配置snmp做了几篇讲解,那么接下来我们开始来一个使用zabbix监控服务器内存使用情况的实例,大家可以举一反三,可以使用zabbix+snmp一一监控cpu使用率、硬盘使用率、负载情况等等。

zabbix增加snmp接口

configuration(配置)->Hosts(主题)->您需要配置的主机,找到“SNMP interfaces”,配置类似如下:

Linux

zabbix-snmp

 

创建SNMP监控项

configuration(配置)->Hosts(主题)->您需要配置的主机->items,点击create items,配置如下:

Linux

zabbix监控snmp

图片里面的账号、口令、oid我就不多做说明了,特别说一下单位B和倍数1024,更多的单位符号请看文章最后的参考。流量的单位是字节,也就是大B,那么为什么下面还有一个1024呢?因为通过snmp获取的数据是kB,比如通过snmp得到1024kB,zabbix以为是1024,那么数据不准了,所以我们需要额外给它乘以1024,这样就准确了?不知道能否明白意思?然后到最新数据里面查看zabbix是否获取到了snmp数据。monitor->last data->找到你得主机以及相应的item,如下:

Linux

zabbix使用snmp获取内存

 

zabbix使用snmp说明

大多数设备都支持snmp,例如路由器、交换机、打印机等等,我想以后的智能家居也会有snmp支持,使用zabbix监控家里的电视机、冰箱、洗衣机、电饭煲,很有趣。如果不知道监控项目的oid,那么看文章末尾的参考地址。那么如何自定义SNMP OID来监控服务器呢?下一节最最后来谈谈zabbix的snmp监控:snmp+shell+zabbix。

 

zabbix snmp监控所有文章

1. zabbix snmp类型 无需安装agent也能监控(51)

2. snmp安装配置 zabbix snmp监控准备(52)

3. snmp v3的安全配置 snmp认证与加密配置(53)

4. SNMP OID列表 监控需要用到的OID

5. zabbix单位符号Unit symbols(32)

 

zabbix web监控项item详解(57)

一旦我们创建好web监控之后,我们便可以查看web站点的性能状况。zabbix一共给我们提供了6个item key,实际上就三个,分别针对单个阶段和整个阶段,三个item分别为web.test.in、web.test.fail、web.test.error,下面看看它的具体用法。

 

web方案监控项

当web监控项创建好之后,下面的key会被自动添加好

key 描述
 web.test.in[Scenario,,bps]  整个阶段中的下载速度,单位字节/秒
类型: Numeric(float)
 web.test.fail[Scenario]  整个检测阶段,失败的阶段个数,如果所有的阶段(step)都成功,那么返回0
类型: Numeric(unsigned)
 web.test.error[Scenario]  返回最后一个错误信息(文本)

web监控项实例

创建触发器“Web scenario failed”,表达式如下

{host:web.test.fail[Scenario].last(0)}#0

创建触发器“Web application is slow”,表达式如下

{host:web.test.in[Scenario,,bps].last(0)}<10000

备注:Scenario改成你web方案的名称即可

web方案阶段监控项

key 描述
 web.test.in[Scenario,Step,bps] 检索指定阶段的下载速度,字节每秒
类型: Numeric(float)
 web.test.time[Scenario,Step] 获取指定阶段响应时间,时间计算从开始请求道获取到所有响应信息之后
类型: Numeric(float)
 web.test.rspcode[Scenario,Step] 检索指定阶段的http响应代码
类型: Numeric(unsigned)

 

step item使用实例

创建触发器 “Zabbix GUI login is too slow” trigger, 触发器表达式如下

{zabbix:web.test.time[ZABBIX GUI,Login].last(0)}>3

说明:ZABBIX GUI是web方案的名称,Login为阶段(step)名称

web监控项数据保留时间

web监控历史数据数据保存30天,趋势数据保存90天,老数据将被清除

zabbix监控web服务器访问性能(56)

zabbix web监控介绍

在host列可以看到web(0),在以前的版本这项是独立出来的,这个主要实现zabbix对web性能的监控,通过它可以了解web站点的可用性以及性能。最终将各项指标绘制到图形中,这样我们可以了解到一个站点的下载速度、响应速度等。需要注意的是在安装zabbix server需要增加libcurl的支持。

我们只需要配置后web监控项,那么zabbix server会定时按照你的规则去执行性能监控。特性下,如果配置都差不多,大家可以先创建模板,然后套用下模板即可

web检测数据搜集说明

web整个检测中会收集如下数据
1. 整个web监控规则中的页面平均下载速度,秒为单位
2. 检测阶段发生的错误次数
3. 最后一个错误消息

web检测的任何一个阶段都会收集如下数据
1. 每秒的下载速度
2. 响应时间
3. 响应代码(http code,如200、301等)

zabbix web监控说明

zabbix可以检测http、https协议,而且zabbix也支持重定向,执行过程中的所有cookies也会被保留。如果需要的话,zabbix会检索某个页面是否包含特定的字符,如果有表示成功,没有表示失败,例如检测zabbix登陆是否正常,它会检索响应的html页面中是否包含Admin,如果有表示登陆成功。

zabbix web数据保存

每次执行完之后的数据都会保存到zabbix数据中,这些数据可以用户绘制成图表以及用户zabbix触发器和发送报警通知

WEB监控所有文章

1. zabbix监控web服务器访问性能(56)

2. zabbix web监控项item详解(57)

3. zabbix实战监控WEB网站性能(58)

3. zabbix监控api接口性能及可用性 天气预报api为例(59)

zabbix导入/导出配置文件(88)

通过导入/导出zabbix配置文件,我们可以将自己写好的模板等配置在网络上分享,我们也可以导入网络上分享的配置文件,配置文件有两种格式,分为为xml与json,通过zabbix管理界面可以导出xml,通过zabbix api可以导出json与xml格式配置。

 

可导出的项目

  • host groups (只能通过zabbix api导出)
  • templates (包含所有预其直接关联的items, triggers, graphs, screens, discovery rules和link的template)
  • hosts (包含所有与它直接相关的items, triggers, graphs, discovery rules 和link的template)
  • network maps (包含所有相关图片; map export/import 从Zabbix 1.8.2开始被支持)
  • images
  • screens

导出详细说明

  • 导出为单个文件
  • Host and template从模板中link过来的实体 (items, triggers, graphs, discovery rules)不会导出,通过low-level创建的实体不会导出。但是导如之后,会重新创建link的实体。
  • 与low-level实体相关联的实体不会被导出,例如触发器。
  • web items相关的Triggers and graphs不支持导出

导入详细说明

  • 导如过程中遇到任何错误,都会停止导入
  • 支持导如xml与json格式文件,并且文件名后缀必须为.xml或者.json

XML文件基本格式

xml默认头

zabbix xml root 元素

导出版本

导出日期

导出模板

configuration>>templates>>勾选需要导出的模板>>左下角下拉列表选择”Export selected”,点击Go,保存xml即可。

如下是我的一个测试模板内容

与模板相关的数据都在xml里,它link的模板”Template OS Linux”并未导出。而是通过如下元素将他关联起来,下回导入还会link一次。

通过此方式,大家可以互相共享配置文件,提高效率。

zabbix客户端自动注册(84)

1. 概述

上一篇内容《zabbix自动发现配置》,大概内容是zabbix server去扫描一个网段,把在线的主机添加到Host列表中。我们本篇内容与上篇相反,这次是Active agent主动联系zabbix server,最后由zabbix server将这些agent加到host里。对于需要部署特别多服务器的人来说,这功能相当给力。所有服务器批量装好zabbix agent,server配置好trigger,所有的服务器都配置好了,非常快速。

2. 配置

2.1配置文件修改

指定server ip

修改Hostname

关于主机名:如果zabbix_agentd.conf配置有定义Hostname,那么zabbix会使用这个Hostname命名,否则agent的主机名(hostname得来的)

修改metadataitem

 

2.2 配置action

步骤:configuration>>action>>Event source(选择Auto registration)>>Create Action,我们按如下步骤来定义个action

2.2.1 action选项卡

hostmetadata

定义Action名称,以及发送消息的主题和内容,使用默认的就行了

2.2.2 Conditions选项卡