##一、什么是zabbix及优缺点
Zabbix能监视各种网络参数,保证服务器系统的安全运营,并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。是一个基于WEB界面的提供企业级的开源分布式系统监视以及网络监视功能的企业级的开源解决方案。 Agent端:主机通过安装agent方式采集数据 Server端:通过收集agent发送的数据,写入数据库(MySQL,ORACLE),在通过php+apache/nginx在web前端展示 cacti:在监控方面有良好的绘图,cacti在流量和图型塑造上要强于nagios,但是在故障分析上延迟性大,而且报警机制薄弱,不适合大规范监控场景。 nagios :适合监视大量服务器上面的大批服务是否正常, 重点并不在图形化的监控, 其集成的很多功能例如报警,都是 cacti 没有或者很弱的。但在绘图以及图型塑造方面精细度比cacti要弱,不适合大规模监控场景。 Zabbix=cacti+Nagios 优点:基于两款工具(cacti+Nagios)优点于一身并更强大,集数据采集、数据存储、数据展示及报警功能为一体实现企业级分布式监控 缺点:需在被监控主机上安装agent,所有数据都存在数据库里,产生的数据量很大,瓶颈主要在数据库
##二、监控功能
主机的性能监控、网络设备性能监控、数据库性能监控、多种警告方式、详细的报表图表绘制
监控主机zabbix有专用的agent,可以监控Linux、Windows、FreeBSD等
监控网络设备zabbix通过SNMP、ssh
可监控对象:
设备:服务器、路由器、交换机
软件:OS、网络、应用程序
主机性能指标监控
故障监控:down机、服务不可达、主机不可达
##三、zabbix支持的通讯方式
硬件监控:Zabbix IPMI Interface 系统监控:Zabbix Agent Interface java监控:ZabbixJMXInterface 网络设备监控:Zabbix SNMP Interface 应用服务监控:Zabbix Agent UserParameter MySQL数据库监控:percona-monitoring-pldlgins URL监控:Zabbix Web监控
##四、工作原理
一个监控系统运行的大概流程是这样的: Zabbix agent需要安装到被监控的主机上,它负责定期收集各项数据,并发送到zabbix server端,zabbix server将数据存储到数据库中,zabbix web根据数据在前端进行展现和绘图。 这里agent收集数据分为主动和被动两种模式: 主动:agent请求server获取主动的监控项列表,并主动将监控项内需要检测的数据提交给server/proxy 被动:server向agent请求获取监控项的数据,agent返回数据
##五、zabbix的组件及进程
重要组件: Zabbix由以下几个组件部分构成: zabbix server:负责接收agent发送的报告信息的核心组件,所有配置,统计数据及操作数据均由其组织进行
database storage:专用于存储所有配置信息,以及由zabbix收集的数据
web interface:zabbix的GUI接口,通常与server运行在同一台主机上
proxy:可选组件,常用于分布式监控环境中,代理server收集部分被监控端的监控数据并同意发往server端
agent:部署在被监控主机上,负责收集本地数据并发往server端或proxy端 常见进程 默认情况下zabbix包含5个进程:zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server,另外一个zabbix_java_gataway是可选的,这个需要另外安装。 Zabbix_agentd:客户端守护进程,此进程收集客户端数据,例如cpu负载、内存、磁盘使用情况等。
Zabbix_get:zabbix工具,单独使用的命令,通常在server或者proxy端执行获取远程客户端信息的命令。通常用来排错。例如在server端获取不到客户端的内存数据,可以使用zabbix_get获取客户端内存的方式来做故障排查。
Zabbix_sender:zabbix工具,用于发送数据给server或者proxy,通常用于耗时比较长的检查。很多检查非常耗时,导致zabbix超时。于是我们在脚本执行完毕之后,使用sender主动提交数据。
Zabbix_server:zabbix服务端守护进程。Zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gataway的数据最终都是提交到server,并不是数据都是主动提交给zabbix_server,也有的是sever主动去取数据
Zabbix_proxy:zabbix代理守护进程,功能类似server,唯一不同的是它只是一个中转站,它需要把收集到的数据提交/被提交到sever
Zabbix_java_gataway:zabbix2.0之后引入的一个功能,顾名思义:java网关,类似agentd,但是只用于java方面。需要特别注意的是,它只能主动取获取数据,而不能被动获取数据。它的数据最终会给到server或者proxy
##六、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根据网络环境、监控规模等分了三种架构:server-client、master-node-client、server-proxy-client三种。 server-client架构 也是zabbix最简单的架构,监控机和被监控机直接不经过任何代理,直接由zabbix server和zabbix agentd之间进行数据交互。适用于网络比较简单,设备比较少的监控环境。
server-proxy-client架构 其中proxy是server、client之间沟通的一个桥梁,proxy本身没有前端,而且其本身并不存放数据,只是将agentd发来的数据暂时存放,而后再提交给server。该架构经常是和master-node-client架构做比较的架构,一般适用于跨机房、跨网络的中型网络架构的监控
master-node-clinet架构 该架构是zabbix最复杂的监控架构,适用于跨网络、跨机房、设备较多的大型环境。每个node同时也是一个server端,node下面可以接proxy,也可以直接接client。Node有自己的配置文件和数据库,其要做的是将配置信息和监控数据向master同步
##八、zabbix 使用详细介绍
zabbix基本应用流程: Host group -->Host ---> Application --->item ---> Trigger(状态ok --> PROBLEM,trigger event) --->Action(Condition + Operation(Send Message,Remote)) Send Message: Media: Email 、SMS、Jabber、EZ Texting 、Script User Groups -->User(Media) 示例:node.mage.com --->Traffic --->Inbiund traffic,Outbound traffic --> trigger(inbound) Zabbix 常用术语 Item key: 监控项,监控项当中最关键的是Item key,用于定义每个item事件用key来进行标识 Escalation:报经升级 template:模板 web Scenario:web应用场景,对web进行监控,例如:打开web页面需要的时间等 Zabbix服务器进程 Poller:主要功能是:主动去被监控的服务器中拉去数据的进程 Pinger:探测主机是否在线 db_config_syncer:服务器同步 timer:计时器 escaltor:报警升级器 housekeeper: discoverer:用来发现主机 httppoller:对web监控时用来获取web监控数据 alter:用来发送警告 Item key: 命名要求:只能使用字母、数字、下划线、点号、连接符 接收参数:system.cpu.load[<cpu>,<moduel>],new.if.inbound[if,<model>] 注意:每个key背后都应该有一个命令或脚本来负责实现数据采集,此命令或脚本可调用传递给key的参数,调用方式$1,$2,..... 在zabbix中定义item时调用某key,还需要额外定义数据采集频率,历史数据保存时长等 Trigger: 触发器表达式:{<Server>:<key>.<function>(<parameter>)}<operator><constant> 示例:{node2.mageedu.com:net.if.in[eth0,bytes].last(#1)} > 1200 <funciton>:评估采集到的数据是否在合理范围内时所使用的函数,其评估过程可以根据采集到的数据、当时时间或其他因素 avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、now、nodata、sum、prev、strlen regexp:检查最后一次采样的数据是否能够被指定的模式所匹配:1表示匹配,0表示不匹配 now:返回自Unix元年至此刻经历的秒数 prev:从最后一次的采样中查找此处指定的子串 str:从最后一次的采样中查找此处指定的字串 strlen: operator:操作符 > < = #不等于 / * - + & | 触发器间存在依赖关系 应用场景:核心交换机出现故障,会导致警告,下面连接多个交换机也会随之告警,通过依赖关系,如果核心交换机出现故障,下面的交换机很定连接不上,下面的交换就不需要告警了,可以减少警告次数,加快故障定位与排查效果 Action: message: codition(条件): event: trigger discovery: Server up,Server down,Host up,Host Down,Service Discovred,Service Lost,Host Discovred,Host Lost auto_registration: operation(操作): send message: Media Email , SMS,Jabber,Script,EZ Texting User remote commond (1)zabbix用户不一定有权限执行所要执行的命令 给zabbix用户定义sudo规则:赋权限 zabbix ALL=(ALL) ALL (2)不支持active模式的agent (3)不支持代理模式 (4)命令长度不得超过255哥字符 (5)可以使用宏 (6)zabbix-server仅执行命令,而不关心命令是否执行成功 Script: Alter Script 放置于特定目录中:AlterScriptsPath = /usr/lib/zabbix/alterscripts zabbix_server.conf配置文件中的参数 脚本中可使用$1,$2,$3来调用aciton页面中邮件的收件人,Default Subject,Default Message 注意:新房如此目录中的脚本只有重启zabbix-server方能被使用 可视化: graph,screen,slide,shows,map 宏:macros 是一种抽象,他根据一系列预定的规则替换一定的文本模式,而解释器或编译器在遇到宏时自动进行这一模式替换 两类: 内建:{MACRO_NAME} 自定义:{$MACRO_NAME} 可以三个级别使用: GLOBAL全局,Template模板,Host主机级别 优先级:host ---> template ---> global 在某级别找到后将直接使用 模板:一系列配置的集合,辞谢配置可通过连接的方式应用于指定的主机 appplication,item,trigger,graph,screen,discovery,web 维护时间: configuration -->Maintenance user Parameters: zabbix内置了许多item key zabbix提供网络发现功能:network discovery HTTP ICMP SSH LDAP TCP SNMP TELNET ZABBIX_AGENT扫描指定网络中的主机 一旦主机被发现,如果对其进行操作,将由action来决定 LLD:low level discovery 低级网络发现功能 此二者的功能: 自动添加主机,链接至模板,添加监控项、分组、定义触发器 网络发现有两个步骤: discovery --> action 发现中的事件: Server up,Server down,Host up,Host Down,Service Discovred,Service Lost,Host Discovred,Host Lost actions: sending notifications Adding/removing hosts enabling/disabling hostadding hosts to a group removing hosts from a group auto_registration: 主动注册功能 网络发现功能自去扫描,极其占用资源 可以使用主动注册功能 LLD:low level discovery 低级网络发现功能 自动发现特定变量的名称 添加针对变量的Items 返回魏JSON zabbix 的监控方式: zabbix-web 所能够显示的且可指定为监控接口类型的监控方式: Agent: passive active SNMP:simple Network Management Protocol MIB,smi snmp(V1,v2c,v3) IPMI:智慧平台管理接口 JMX:用于通过java自己的接口对java程序进行监控 zabbix-java-gateway 用于获取监控接口数据 zabbix database需要用到的空间 默认保存90天 历史数据 = 天数 X 每秒钟处理的数据量 X 24 X 3600 X50 Bytes 趋势数据: 默认一年 每一个趋势默认128Bytes 大小 = 天数*监控项数量*24 * 128Bytes 事件数据: 保存一年 每个占据130Bytes 大小 = 天数 * 86400 * 130 zabbix: database ---> zabbix-server(zabbix_server.conf) ---> zabbix-web(LNMP) ---> http://zabbix-web-server/zabbix zabbix-agent 历史数据: 采样生成的数据 历史趋势数据: 每小时的最大值、最小值、平均值、统计 as is :不做任何处理
##参考博客
https://www.cnblogs.com/clsn/p/7885990.html#auto_id_24 https://www.cnblogs.com/cheyunhua/p/9961608.html