文章目录

  • zabbix是什么
  • zabbix的架构
  • zabbix的优缺点
  • zabbix的监控流程
  • zabbix常见进程
  • zabbix监控环境中基本概念
  • 几个开源运维监控框架对比


zabbix是什么

zabbix([`zæbiks])是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。

zabbix至少由2部分构成,zabbix server与可选组件zabbix agent。

它具备主机的性能监控,网络设备性能监控,数据库性能监控,多种告警方式,详细报表、图表的绘制等功能。监测对象可以是Linux或Windows服务器,也可以是路由器、交换机等网络设备

zabbix server可以通过SNMP,zabbix agent,ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD,OS X等平台上。

zabbix安卓客户端 zabbix的客户端是什么_数据

zabbix安卓客户端 zabbix的客户端是什么_自定义_02

zabbix安卓客户端 zabbix的客户端是什么_java_03


zabbix安卓客户端 zabbix的客户端是什么_自定义_04

zabbix安卓客户端 zabbix的客户端是什么_数据_05


zabbix安卓客户端 zabbix的客户端是什么_zabbix安卓客户端_06

zabbix的架构

zabbix安卓客户端 zabbix的客户端是什么_数据_07

zabbix安卓客户端 zabbix的客户端是什么_zabbix安卓客户端_08

zabbix安卓客户端 zabbix的客户端是什么_java_09

zabbix安卓客户端 zabbix的客户端是什么_自定义_10

zabbix安卓客户端 zabbix的客户端是什么_java_11

zabbix安卓客户端 zabbix的客户端是什么_java_12

zabbix安卓客户端 zabbix的客户端是什么_java_13

在生产环境中,zabbix根据网络环境、监控规模等外界因素分为三种架构:server-client(直接连接)、master-node-client(Node架构)、server-proxy-client(proxy架构),如下图所示:

1、server-client架构:

server-client架构是zabbix最简单的架构,监控机和被监控机之间不经过任何代理,直接在zabbix server(监控服务器) 和zabbix agent(agent:部署在被监控端,用于采集数据)之间进行数据交互,适用于网络比较简单,设备较少的监控环境。

2、master-node-client架构:

master-node-client架构是zabbix最复杂的监控架构,适用于跨网络、跨机房、设备较多的大型环境。每个node同时也是一个server端,node下面可以接proxy,也可以直接接client。node有自己的配置文件和数据库,其要做的就是将配置信息和监控数据向master同步。当master宕机后,node可以保证架构的完整性。

3、server-proxy-client架构:

proxy是server、client之间沟通的一个桥梁,proxy本身没有前端,而且其本身不存放数据,只是将agentd发来的数据暂时存放,而后再提交给server。该架构经常是和master-node-client架构做比较的架构,一般适用于跨机房、跨网络的中型网络架构的监控。

zabbix安卓客户端 zabbix的客户端是什么_数据_14

zabbix的优缺点

zabbix的优点:

1、数据采集:可用性和性能检测,自动发现,支持agent、snmp、JMX、telnet等多种采集方式,支持主动和被动模式数据传输、支持用户自定义插件,自定义间隔收集数据

2、高可用:server对设备性能要求低,支持proxy分布式监控,分布式集中管理,有自动发现功能,可以实现自动化监控;开放式接口,扩展性强,插件编写容易

3、告警管理:支持多条件告警,支持多种告警方式,支持多组模板,模板继承。

4、告警设置:告警周期,告警级别,告警恢复通知、告警暂停,时段阈值、支持维护周期、支持单机停用

5、图形化展示:允许自定义创建多监控项视图,网络拓扑,自定义面板展示,自定义IT服务可用性

6、历史数据:历史数据查询可配置,内置housekeeping数据清理机制

7、安全审计:具备安全的用户审计日志,权限认证,用户可以限制允许维护的列表。

8.自定义方面做的也比较好,想关注系统什么指标就可以自定义键值取值。

zabbix缺点:

1、性能瓶颈,监控系统没有低估高峰期,具有持续性和周期性,机器量越大,数据的增大会使数据库的写入成为一定的瓶颈,官网给出的单机上限5000台,届时就需要增加proxy,增加成本。

2、Zabbix采集数据有pull方式,也就是server主动模式,当目标机器量大之后,pull任务会出现积压。采集数据会延迟

3、项目二次开发,需要分析MySQL表结构,表结构比较复杂,通过API开发对开发能力有要求。

4、内置housekeeping在执行过程中会对数据库增加压力,需要对数据库进行优化

zabbix的监控流程

Zabbix的监控流程可以简单描述为:

数据采集-->数据存储-->数据分析-->数据展示-->监控报警

其中:

数据采集:Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等进行数据采集
数据存储:Zabbix存储在MySQL上,也可以存储在其他数据库
数据展示:web界面展示、(移动APP、java_php开发一个web界面也可以)
数据报警:邮件报警、微信报警、短信报警、报警升级机制

Zabbix的监控配置流程可以简单描述为:
告警是由一系列的流程组成,首先是触发器达到阀值,产生一个事件,接下来由Action对事件信息进行处理,其中包括两部分:
第一部分是发送消息,即将告警信息发送给用户。
第二部分是执行命令,即将事件用命令进行处理,达到对事件故障自动尝试恢复的效果。

Host groups(主机组)-->Hosts(主机)-->template(模板)
-->Applications(监控项组)-->Items(监控项)
-->graph(图形) -->screen (图形分组)-->Triggers(触发器)
-->Event(事件)-->Actions(处理动作)-->
Media types(告警升级|1.执行远程命令2.发送告警邮件)-->
User groups(用户组)-->Users(用户)-->Medias(告警邮件)

在实际生产使用的时候,Items、Trigger、Graph采用模板来进行监控,模板特点就是可以重复的事情一次完成,修改了模板等于修改了所有调用此模板的主机,这样可解放运维的双手.
Graph不是必需的,因为没有配置图形,数据获取并不影响,获取数据是Items的功能。但是对于使用ZabbixWeb界面用户来说,没有图形等于没有数据,因此重要的Items必须添加必要的图形以做可视化展示。如果想集中查看图形,可以通过screen功能

zabbix常见进程

默认情况下zabbix包含5个进程:zabbix_agentd、zabbix_get、
zabbix_proxy、zabbix_sender、zabbix_server,
另外一个zabbix_java_gataway是可选的,这个需要另外安装。

Zabbix_server:zabbix服务端守护进程。Zabbix_agentd、zabbix_get、
zabbix_sender、zabbix_proxy、zabbix_java_gataway的数据最终都是提交到server,并不是数据都是主动提交给zabbix_server,
也有的是sever主动去取数据

Zabbix_agentd:客户端守护进程,此进程收集客户端数据,
例如cpu负载、内存、磁盘使用情况等。

Zabbix_proxy:zabbix代理守护进程,功能类似server,唯一不同的是它只是一个中转站,它需要把收集到的数据提交/被提交到sever

Zabbix_get:zabbix工具,单独使用的命令,通常在server
或者proxy端执行获取远程客户端信息的命令。通常用来排错。
例如在server端获取不到客户端的内存数据,可以使用zabbix_get获取
客户端内存的方式来做故障排查。

Zabbix_sender:zabbix工具,用于发送数据给server或者proxy,
通常用于耗时比较长的检查。很多检查非常耗时,导致zabbix超时。
于是我们在脚本执行完毕之后,使用sender主动提交数据。

Zabbix_java_gataway:zabbix2.0之后引入的一个功能,
顾名思义:java网关,类似agentd,但是只用于java方面。
需要特别注意的,  它只能主动取获取数据,而不能被动获取数据。
它的数据最终会给到server或者proxy

Zabbix_database:MySQL或PostgreSQL

Zabbix_web:Web GUI

zabbix监控环境中基本概念

主机(host):主要监控的网络设备,可由IP或DNS名称指定;

主机组(host group):主机的逻辑容器,可以包含主机和模板,
但同一个组织内的主机和模板不能互相链接;主机组通常在给用户或用户组
指派监控权限时使用

监控项(item):一个特定监控指标的相关的数据;
这些数据来自于被监控对象;item是zabbix进程数据收集的核心,
相对某个监控对象,每个item都由“key”标识

触发器(trigger):一个表达式,用于评估某监控对象的特定item
内接收的数据是否在合理范围内,也就是阈值;
接收的数据量大于阈值时,触发器状态将从“OK”转变为“Problem”,
当数据再次恢复到合理范围,又转变为“OK”

事件(event):触发一个值得关注的事情,比如触发器状态转变,
新的agent或重新上线的agent的自动注册等

动作(action):指对于特定事件事先定义的处理方法,
如发送通知,何时执行操作

报警升级(escalation):发送报警或者执行远程命令的自定义方案,
如每隔5分钟发送一次报警,共发送5次等。

媒介(media):发送通知的手段或者通道,如Email,Jabber或者SMS等

通知(notification):通过选定的媒介向用户发送有关某事件的信息

远程命令(remote command):预定义的命令,可在被监控主机处于某特定条件下时自动执行

模板(template):用于快速定义被监控主机的预设条目集合,
通常包含了item、trigger、graph、screen、application以及low-level discovery rule;模板可以直接链接到某个主机

应用(application):一组item的集合

Web场景(web scennario)用于检测web站点可用性的一个或多个HTTP请求

前端(frontend):zabbix的web接口

几个开源运维监控框架对比

zabbix安卓客户端 zabbix的客户端是什么_zabbix安卓客户端_15


zabbix安卓客户端 zabbix的客户端是什么_数据_16


zabbix安卓客户端 zabbix的客户端是什么_zabbix安卓客户端_17