Zabbix功能概述及架构介绍(理论篇)

1、Zabbix的功能概述


1.1 zabbix是什么

Alexei Vladishev创建了Zabbix项目,当前处于活跃的开发状态,Zabbix SIA提供支持。

Zabbix是一个企业级的、开源的、分布式的监控套件。

Zabbix可以对网络和服务进行监控。 Zabbix利用灵活的告警机制,可实现微信、短信和邮件的自动报警。Zabbix利用存储的监控数据提供监控报告及实现图形化显示。

Zabbix支持polling和trapping两种方式。所有的Zabbix报告都可以通过配置参数在WEB界面进行访问。你可以通过Web界面实时查看网络和服务的监控状况。 不管你是小型组织还是大规模的公司,Zabbix都可以通过不通的配置来扮演监控你的IT基础框架的角色。

Zabbix是零成本的,因为Zabbix编写和发布基于GPL V2协议. 意味着源代码是免费发布的。

同时,Zabbix公司也提供商业化的技术支持。


1.2 zabbix特性

Zabbix是一个高度集成的网络监控套件,通过一个软件包即可提供如下特性

数据收集

  • 可用性及性能检测
  • 支持SNMP(trapping及polling)、IPMI、JMX监控
  • 自定义检测
  • 自定义间隔收集收据
  • server/proxy/agents实现分布监控环境

灵活的阀值定义

  • 允许灵活地自定义故障阀值,Zabbix中称为触发器(trigger), 存储在后端数据库中

高级告警配置

  • 可以自定义告警升级(escalation)、接收者及告警方式
  • 告警信息可以配置并允许使用宏(macro)变量
  • 通过远程命令实行自动化动作(action)

实时绘图

  • 通过内置的绘图引擎实现监控数据实时绘图

扩展的图形化显示

  • 允许自定义创建多监控项视图
  • 网络拓扑(network maps)
  • 自定义的面板(screen)和slide shows,并允许在dashboard页面显示
  • 报告
  • 高等级(商业)监控资源

历史数据存储

  • 数据存储在数据库中
  • 历史数据可配置
  • 内置数据清理机制

配置简单

  • 主机通过添加监控设备方式添加
  • 一次配置,终生监控(除非调整或删除)
  • 监控设备允许使用模板

模板使用

  • 模板中可以添加组监控
  • 模板允许继承

网络自动发现

  • 自动发现网络设备
  • agent自动注册
  • 自动发现文件系统、网卡设备、SNMP OID等

快速的web接口

  • web前端采用php编写
  • 访问无障碍
  • 你想怎么做就能做么做
  • 审计日志

Zabbix API

  • Zabbix API提供程序级别的访问接口,第三方程序可以很快接入

权限系统

  • 安全的权限认证
  • 用户可以限制允许维护的列表

全特性、agent易扩展

  • 在监控目标上部署
  • 支持Linux及Windows

二进制守护进程

  • C开发,高性能,低内存消耗
  • 易移植

具备应对复杂环境情况

  • 通过Zabbix proxy可以非常容易的创建远程监控

1.3 Zabbix功能

监控拓扑图说明:

(1)可以通过微信、短信、邮件实现自动报警机制

(2)可以通过Web页面进行配置,监控状态查看

(3)可以通过SNMP协议实现对打印机、路由器、交换机的设备的监控

通过在植入agent的方式对服务器主机进行监控

通过ping或者是port检查的方式实现IP和PORT的监控

可实现大多数系统的监控,包括windows、Linux、unix、Solaris、Mac等等,如图:

对主机可监控项包括:

CPU:CPU负载,CPU使用率

Memory:内存使用率,可交换内存/虚拟内存使用率

Network:网络传输、网络故障、丢包

Disk:磁盘使用率,磁盘I/O

Service:进程监控、界面服务、TCP端口连接,响应时间、DNS监控、NTP监控

Log:日志监控,文本日志,事件日志

File:文件监控

Other:性能计数器(仅限于Windows系统)

自定义报警机制:

如图所示,

如果故障在10分钟没有被解决,可以短信或邮件通知系统管理员

如果故障在15分钟没有被解决,可以短信或邮件通知运维人员

如果故障在30分钟没有被解决,可以短信或邮件通知经理

可以通过proxy代理服务器,代理Zabbix server搜集被监控的监控数据,并统一发送到Server端


2、zabbix程序架构

架构图如下:

Zabbix各组件的说明:

Zabbix Server

Zabbix Server为核心组件,用来获取agent存活状况及监控数据。所有的配置、统计、操作数据均通过Server进行存取到database

Zabbix database

所有的Zabbix数据均存储在数据库中

Web GUI

为了更简单的无障碍的访问Zabbix, 所以提供了web接口。该接口作为Zabbix Server的一部分,通常和server运行在同一台主机上

注意:如果采用SQLite作为数据库,web接口和Zabbix Server必须运行在同一台主机上

Proxy

Zabbix Proxy能够代替Zabbix Server进行性能及可用性数据采集。Proxy是Zabbix部署的可选组件。 如果想分担单一Zabbix Server负载,推荐使用proxy。

Agent

Zabbix agents 部署在目标监控机上并监控本地资源和应用,将收集数据汇报给Zabbix Server

监控流程:

通过zabbix监控数据流,并采取相应的措施。

首先要创建一个host,再创建一个item来搜集数据

通过item来创建触发器(trigger)

通过触发器(trigger)来创建一个动作(action)

例如:如果你想监控一个服务器的CPU负载状况,你首先为该服务器创建一个主机条目,其次是创建一个item来监控服务器的CPU状况,并创建相应的触发机制,当cpu负载达到某个阀值,触发操作,该操作包括执行设定的动作和发送邮件报警。

可以将这些操作设置成一个模板,要监控某台主机的时候,直接套用模板即可。

Zabbix各组件结构图:

Zabbix相关术语:

相关名词解释:

主机(host)

一个你想监控的网络设备(需要知道IP/DNS)

主机组(host group)

一个逻辑的主机组,它包含主机和模板。主机和模板在同一个主机内的话模板不能被link到其他上。主机组通常用于给不同的用户组创建访问权限

监控项(item)

你想从主机中收集到的数据

触发器(trigger)

一个逻辑表达式,用来表达从监控项获取的数据达到了预设的故障阀值

当接收到的监控值达到了预设的阀值,则触发器状态由’OK’变更为’Problem’,当收到的监控值低于阀值,则状态保持/变更为’OK’

事件(event)

一个事情发生如触发器状态变更或一个自动发现(discovery)/agent自动注册等

动作(action)

当一个事件发生时预设的处理过程

一个动作(action)包括操作(operations,如发送告警)和条件(当指定的操作完成)

告警升级(escalation)

在动作中一个自定的操作执行过程,一个发送告警/执行远程命令的队列

媒介(media)

发送告警的渠道

告警(notification)

通过媒介(media)渠道发送事件的消息

远程命令(remote command)

当监控主机达到某些条件(condition)后预设的自动执行的命令

模板(template)

一组包含监控项、触发器、绘图、面板(screen)、应用、低级别自动发现规则等并且能被其他主机应用的实体

模板能够提升主机部署监控任务的速度,同时也非常容易对监控任务做批量(mass)更新。模板被主机链接(link).

应用(application)

监控项逻辑组

web方案(scenario)

对一个web站点可用性进行检查的一个或多个http请求

前端(frontend)

Zabbix提供的web接口

Zabbix API

Zabbix API允许通过JSON RPC协议去创建、更新、获得Zabbix对象(如主机、监控项、绘图等等)以及完成自定义任务

Zabbix server

Zabbix软件中心进程,用于连通Zabbix proxy及agent完成监控、评估触发器、发送告警以及中心数据存储

Zabbix agent

部署在监控主机上的进程,用于监控本地资源和应用

Zabbix proxy

替代Zabbix server完成数据收集的进程,通常用于降低中心Zabbix Server的负载

节点(node)

一套完整的Zabbix server配置,通常位于分布式系统中,用于负责本区域的监控

Zabbix工作流程图:

Server

Zabbix server是Zabbix软件的核心进程。

Server通过polling和trapping采集数据来判断是否达到阀值,从而使用触发器发送报警给用户。Server也可以通过简单服务检查(simple service check)来完成远程网络服务检测。

Server既是保存所有配置、统计和操作数据的数据库,也是故障报警服务。

Zabbix server根据不同功能可划分为三个部分:Zabbix server、Web GUI及Database。

由于Zabbix的所有的配置信息保存在数据库中,server和web GUI可以直接进行操作。比如,通过Web界面(或者API)创建一个新的监控项时,它将创建的数据插入数据库。一分钟左右Zabbix server会查询监控项数据表,并将查询的监控项列表保存在自己的缓存(cache)中。这也是为什么通过Zabbix前端进行的变更将在两分钟左右生效的原因。

Zabbix server以守护(daemon)进程方式运行。

Zabbix server默认要求运行在非root账户下。

如果Zabbix server和agent运行在同一台主机上,建议分别运行在不同的用户下,因为一旦运行的同一个用户下,agent将可以访问server的配置文件,并且能够轻松取得Zabbix Admin级别用户,例如,数据库密码。

Zabbix server在以下平台进行过测试:

  • Linux
  • Solaris
  • AIX
  • HP-UX
  • Mac OS X
  • FreeBSD
  • OpenBSD
  • NetBSD
  • SCO Open Server
  • Tru64/OSF1

Agent:

Zabbix agent部署在被监控主机上用来监控本地资源和应用(如硬盘、内存、处理器等)。

Zabbix agent收集本地主机运行信息并将数据发送给Zabbix server进行处理. 一旦出现异常(如硬盘满或服务进程中断), Zabbix server会自动响应并进行报警操作。

Zabbix agent利用本地系统调用完成统计信息收集,因此它非常的高效。

被动(passive)和主动(active)检查

Zabbix agent提供被动和主动检查方式。

在 被动检查 模式中agent应答数据请求,Zabbix server或者proxy询问agent数据,如CPU load,然后Zabbix agent回送结果给server.

主动检查 处理过程将相对复杂,agent必须先进行一次请求Zabbix server索取监控项列表,然后发送对应的值给server.

选择是被动还是主动检查,需要在 监控项类型 中选择’Zabbix agent’或者’Zabbix agent (active)’。

Zabbix agent运行在被监控主机上,可以通过守护进行的方式运行。

Zabbix agent一般要求运行在非root账户下。

如果你在’root’账户下启动Zabbix agent,它将自动选择在操作系统中建立的’zabbix’用户,除非你修改agent配置文件中’AllowRoot’参数。

Zabbix agent支持以下平台:

  • Linux
  • IBM AIX
  • FreeBSD
  • NetBSD
  • OpenBSD
  • HP-UX
  • Mac OS X
  • Solaris
  • Windows: 2000, Server 2003, XP, Vista, Server 2008, 7

代理proxy

Zabbix代理(proxy)通常用于替代server收集监控信息并将数据发送给Zabbix server。所收集数据会先存储在代理主机的缓存中然后传送给Zabbix server。

代理是可选的,不过使用它可以有效的降低分布式环境中单一的Zabbix server负载。通过代理去收集监控数据,server可以有效降低CPU和磁盘I/O消耗。

Zabbix代理可以出色的完成远程区域、分支机构、无本地管理员的网络的集中监控。

Zabbix代理使用独立的数据库。

注意:Zabbix proxy数据库可以使用SQLite, MySQL, PostgreSQL. 如果Oracle或IBM DB2在低等级自动发现规则时存在限制和风险。

Zabbix proxy作为守护进程运行。

Zabbix proxy一般要求运行在非root账户下。

如果在’root’账户运行,它将自动选择之前已经在操作系统建立的’zabbix’用户,但是无法在编译时或在配置文件中进行配置。


Java gateway

zabbix2.0之后引入的一个功能。Java网关,类似agentd,但是只用于监控运行在Java虚拟机上的Java应用。它只能主动去获取数据,而不能被动获取数据。它的数据最终会给到server或者proxy。

Zabbix 2.0通过Zabbix Java gateway的守护进程对JMX应用进行监控。Zabbix Java gateway是采用Java编写的一个守护进程,Zabbix Java gateway利用 JMX API 去请求远程的有关应用。

Java gateway接受来自Zabbix server或者proxy的连接。在Zabbix server或proxy的配置文件中指定JAVA gateway的IP和端口,因此在每一个Zabbix server或proxy中只能配置一个Java gateway。

当在Java gateway上的一个监控项值更新了,Zabbix server或代理将连接Java gateway请求该值。同样的,Java gateway不会缓存任何值。

Zabbix server或代理可以通过 StartJavaPollers 控制连接Java gateway的进程。Java gateway在内部通过 START_POLLERS 控制选项使用多线程启动。 在Zabbix Server端,如果一个连接请求超过了 Timeout 设定的秒数,连接将会终止,但Java gateway也许此时依然忙于从JMX计数器中检索该值。

建议 StartJavaPollers 小于或等于 START_POLLERS ,否则可能导致当连接Java gateway时而Java gateway没有多余的线程进行处理。

当Java gateway已经运行,需要在 server配置文件 中指定JavaGateway的IP和端口,如果JMX应用采用Zabbix代理进行监控的话,你需要在 代理配置文件 中指定对应的连接参数。

Sender

Zabbix sender命令行工具常用于发送性能数据给Zabbix server。

该工具常用于在长时间运行的用户自定义脚本中以便不断发送可用性及性能数据。

Get

Zabbix get用于连接Zabbix agent并从agent上检索需要的信息。

时间: 2024-08-08 08:16:25

Zabbix功能概述及架构介绍(理论篇)的相关文章

linux功能概述及目录介绍

一:功能介绍: cd:切换目录  (cd. 切换到当前目录 :cd ..切换到上级目录) ls:查看当前目录      -l查看当前目录的详细信息(=ll)   -a查看隐藏文件 useradd :新建用户名 passwd:新建密码 up - :转移用户名 pwd:确定目录 cd~:切换到家目录下 cd -:返回上一次切换的目录 cp:拷贝文件    -r拷贝文件或目录 alias :查看命令别名 如cp=cp -i mv:剪切,有时可以改文件名(相同目录下移动,可以改名) mkdir:创建目录

MySQL性能管理及架构设计 --- 理论篇

              MySQL性能管理及架构设计  一丶IO,内存,吞吐量理解 IO     是指设备与设备之间操作次数,比如mysql与php互插内存   是程序运行都在里面执行吞吐量 是单位时间内处理的请求数量 二丶究竟是myisa还是innodb ? 业界争论不休的情况下,低版本默认引擎是myisam,高版本mysql默认引擎是innodb,也是innodb高版本一个梗吧,尽量使用innodb引擎,不要混合使用myisam这两种引擎,因为在事物中,如果回滚的话 ,表连接 myisa

【SSH2(理论篇)】--Struts2配置详解

上篇博客讨论了SSH2框架模型,在开发过程中发现SSH2的开发模型其实类似于经典的三层模式,在每一层中分别添加了不同的框架,显示层使用的是Struts2进行配置的,业务逻辑层使用的是Spring配置,数据持久层则采用的是Hibernate,开发模式简单易懂,接下来将会分别从三层着手讨论每一层的运行内容. 一.Struts体系简介 struts,是Apache软件基金会(ASF)赞助的一个开源项目,它通过采用Java Servlet/JSP技术,实现了基于Java EE Web应用的Model-V

三层架构理论篇

对于三层架构的理论阐述,我将从三个大的方面去讨论:what.why和how,说白了也就是以三层架构为中心,去了解什么是三层,为什么用三层以及怎么用三层这个三个问题.OK,废话不多说,进入正题. 什么是三层架构?(What) 通常多层结构的划分方式有两种:分别是物理和逻辑.物理上的三层结构是指将整个应用系统分为显示层.业务层和数据层,并且这三个层面上的实体都是硬件,比如显示层就是客户机器,业务层通常是应用程序服务器,而数据层就是数据库服务器了. 今天我们讨论的主要是逻辑上的三层架构,是在软件设计时

OpenStack入门——理论篇(二):OpenStack的节点类型和架构(含登录的仪表板界面示例)

OpenStack入门--理论篇(二):OpenStack的节点类型和架构(含仪表板界面示例) 前言 ? 看了网上的一些博客对OpenStack架构的描述,大部分都是将官网的架构图截取下来(还是纯英文文字描述的图片)或者直接将描述翻译为中文直接复制粘贴过来了.如果对于初学者而言,这或许是有字天书了.所以笔者先前的一篇文章是介绍了关于OpenStack的基础知识和核心的组件服务.而本文先从OpenStack部署的节点结构描述,再来对其整体架构进行阐述. 一.OpenStack节点类型 ? 在介绍O

三层架构-------理论篇

概念: 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦合"的思想. 各层概念 1.表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.查找等. 注:应用三层离不开另一个重要的类:实体类,

MySQL知识理论篇

此篇文件献给正在学习MySQL的同学们,如果希望探讨学习请加我QQ:402283866 [思维理论篇] MySQL的定义 MySQL就是一个存表格的仓库,用规范的语句可以操作这个表(我们称sql语句).这些表格的每一行为一个单位,被公司记录一些信息. MySQL的使用方法 MySQL中的表格,每一行在被调用的时候会使用一些标准的语句,语句可以完成增删改查等操作.这些语句有6类,常用的有3类,每一类只有3-5个总有固定的单词,反复练习很容易掌握. MySQL主从同步 因为两个原因要设置主从同步:1

大数据技术之_29_MySQL 高級面试重点串讲_02_Mysql 简介+Linux 版的安装+逻辑架构介绍+性能优化+性能分析+查询截取分析+分区分库分表简介+锁机制+主从复制

第1章 Mysql 简介1.1 概述1.2 高级 MySQL第2章 Mysql Linux 版的安装2.1 下载地址2.2 检查当前系统是否安装过 mysql2.3 修改 Mysql 配置文件位置2.4 修改字符集和数据存储路径2.5 MySQL 的安装位置说明2.6 Mysql 配置文件说明2.7 Mysql 的数据存放目录第3章 Mysql 逻辑架构介绍3.1 总体概览3.2 查询说明第4章 Mysql 性能优化4.1 影响 mysql 的性能因素4.2 查询与索引优化分析4.2.1 性能下

Centos 7防火墙基础——理论篇

Centos 7防火墙基础--理论篇 理论结构: Firewalld概述 Firewalld和iptables的关系 Firewalld网络区域 Firewalld防火墙的配置方法 Firewalld概述 支持网络区域所定义的网络连接以及接口安全等级的动态防火墙管理工具 支持IPV4.IPV6防火墙设置以及以太网桥 支持服务或应用程序直接添加防火墙规则接口 拥有两种不同的配置模式 运行时配置 永久配置 Firewalld和iptables的关系 netfilter ? 位于Linux内核的过滤的