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