Zabbix监控介绍
1、Zabbix监控架构
在上面的架构图中，为了防止zabbix server单点故障，对其进行了一个backup操作，实际生产环境中如果规模比较小的话其实用不到backup，然后zabbix的数据是要存储在zabbix的数据库当中，每一个agentdX都是一个信息采集端，当其数量达到一定规模时，可以给其加上proxy节点，目的是缓解zabbix server的压力。
2、Zabbix优点
✦ 开源，无软件成本投入
✦ zabbix-server端对设备性能要求低
✦ 支持多种设备，自带多种监控模板
✦ 支持分布式集中管理，有自动发现功能，可以实现自动化监控
✦ 开放式接口，扩展性强，插件编写容易
✦ 当监控的item比较多，服务器队列比较大时，可以采用主动状态，被监控客户端主动从server端去下载需要监控的item，然后取数据上传到server端。这种方式对服务器的负载比较小。
主动和被动是相对于agent端来说的，主动就是server端主动去找客户端；被动就是server端等待客户端来取监控项，然后再将数据上传到server端
✦ API的支持，方便与其他系统结合
3、Zabbix缺点
✦ 需要被监控主机上安装agent，所有数据都存在数据库里，产生的数据很大，瓶颈主要在数据库
✦ 项目批量修改不方便
✦ 社区虽然成熟，但是中文资料相对较少，服务支持有限
✦ 入门容易，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发难度较大
✦ 系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多，并且自定义的项目报警需要自己设置，过程比较繁琐
✦ 缺少数据汇总功能，如无法查看一组服务器平均值，需进行二次开发
4、Zabbix监控系统可监控对象
✦ 数据库：Mysql、Mariadb、Oracle、SQL Server agent
✦ 应用软件：Nginx、Apache、PHP、Tomcat agent
✦ 集群：LVS、Keepalived、HAproxy、RHCS、F5 agent
✦ 虚拟化：Vmware、KVM、XEN、docker、k8s agent
✦ 操作系统：Linux、Unix、Windows性能参数 agent
✦ 硬件：服务器、存储、网络设备 IPMI
✦ 网络：网络环境（内网环境、外网环境） SNMP协议
5、Zabbix的监控方式
① 被动模式
被动检测：相对于agent（客户端）而言；agent, server向agent请求获取配置的各监控项相关的数据，agent接收请求、获取数据并响应给server；
被动模式下，相当于server告知agent（客户端），我要监控你的什么什么数据，给你一张表格，你把表格填好之后再还给我。
② 主动模式
主动检测：相对于agent而言；agent(active),agent向server请求与自己相关监控项配置，主动地将server配置的监控项相关的数据发送给server；
主动模式下，agent端主动询问server端，你（server）要监控我（agent）的哪些项，来，给我张表，我填好之后就发给你
主动模式下能极大节约监控server的资源
6、Zabbix架构
此部分关于zabbix由什么组成，内部是如何协同工作的
① Zabbix Server
◆ Zabbix server 是 agent 程序报告系统可用性、系统完整性和统计数据的核心组件，是所有配置信息、统计信息和操作数据的核心存储器。
③ Zabbix 数据库存储
◆ 所有配置信息和 Zabbix 收集到的数据都被存储在数据库中。
③ Zabbix Web 界面
◆ 为了从任何地方和任何平台都可以轻松的访问Zabbix, Zabbix提供了基于Web的界面。该界面是Zabbix Server的一部分，通常(但不一定)跟Zabbix Server运行在同一台物理机器上。
◆ 如果使用 SQLite数据库,Zabbix Web 界面必须要跟Zabbix Server运行在同一台物理机器上。
④ Zabbix Proxy 代理服务器
◆ Zabbix proxy 可以替Zabbix Server收集性能和可用性数据。Proxy代理服务器是Zabbix软件可选择部署的一部分；当然，Proxy代理服务器可以帮助单台Zabbix Server分担负载压力。
⑤ Zabbix Agent 监控代理
◆ Zabbix agents监控代理 部署在监控目标上，能够主动监控本地资源和应用程序，并将收集到的数据报告给Zabbix Server。
⑥ Zabbix 数据流
◆ 监控方面，为了创建一个监控项(item)用于采集数据，必须先创建一个主机（host）。
◆ 告警方面，在监控项里创建触发器（trigger），通过触发器（trigger）来触发告警动作（action）。 因此，如果你想收到Server XCPU负载过高的告警，必须满足
a、为Server X创建一个host并关联一个用于对CPU进行监控的监控项（Item）。
b、创建一个Trigger，设置成当CPU负载过高时会触发
c、Trigger被触发，发送告警邮件
虽然看起来有很多步骤，但是使用模板的话操作起来其实很简单，Zabbix 这样的设计使得配置机制非常灵活易用。
7、Zabbix常用术语的含义
① 主机 (host)
◆ 一台你想监控的网络设备，用IP或域名表示
② 主机组 (host group)
◆ 主机的逻辑组；它包含主机和模板。一个主机组里的主机和模板之间并没有任何直接的关联。通常在给不同用户组的主机分配权限时候使用主机组。
③ 监控项 (item)
◆ 你想要接收的主机的特定数据，一个度量数据。
④ 触发器 (trigger)
◆ 一个被用于定义问题阈值和“评估”监控项接收到的数据的逻辑表达式
当接收到的数据高于阈值时，触发器从“OK”变成“Problem”状态。当接收到的数据低于阈值时，触发器保留/返回一个“OK”的状态。⑤ 事件 (event)
◆ 单次发生的需要注意的事情，例如触发器状态改变或发现有监控代理自动注册
⑥ 异常 (problem)
◆ 一个处在“异常”状态的触发器
⑦ 动作 (action)
◆ 一个对事件做出反应的预定义的操作。
◆ 一个动作由操作(例如发出通知)和条件(当时操作正在发生)组成
⑧ 升级 (escalation)
◆ 一个在动作内执行操作的自定义场景; 发送通知/执行远程命令的序列
⑨ 媒介 (media)
◆ 发送告警通知的手段；告警通知的途径
⑩ 通知 (notification)
◆ 利用已选择的媒体途径把跟事件相关的信息发送给用户
⑪ 远程命令 (remote command)
◆ 一个预定义好的，满足一些条件的情况下，可以在被监控主机上自动执行的命令
⑫ 模版 (template)
◆ 一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用，LLD，Web场景）的集合
◆ 模版的任务就是加快对主机监控任务的实施；也可以使监控任务的批量修改更简单。模版是直接关联到每台单独的主机上。
◆ 模板就是相当于一个标准文档
⑬ 应用 (application)
◆ 一组监控项组成的逻辑分组
⑭ web 场景 (web scenario)
◆ 利用一个或多个HTTP请求来检查网站的可用性
⑮ 前端 (frontend)
◆ Zabbix提供的web界面
⑯ Zabbix API
◆ Zabbix API允许你使用JSON RPC协议 (是一个无状态且轻量级的远程过程调用（RPC）传送协议，其传递内容透过 JSON 为主) 来创建、更新和获取Zabbix对象（如主机、监控项、图形和其他）信息或者执行任何其他的自定义的任务
◆ 其实就是Zabbix的API接口，允许用户进行二次开发
⑰ Zabbix server
◆ Zabbix软件实现监控的核心程序，主要功能是与Zabbix proxies和Agents进行交互、触发器计算、发送告警通知；并将数据集中保存等
⑱ Zabbix agent
◆ 一个部署在监控对象上的，能够主动监控本地资源和应用的程序
◆ Zabbix agent 部署在监控的目标上，主动监测本地的资源和应用(硬件驱动，内存，处理器统计等)。
◆ Zabbix agent收集本地的操作信息并将数据报告给Zabbix server用于进一步处理。一旦出现异常 (比如硬盘空间已满或者有崩溃的服务进程), Zabbix server会主动警告管理员指定机器上的异常。. Zabbix agents 的极端高效缘于它可以利用本地系统调用来完成统计数据的收集。
⑲ 被动（passive）和主动（active）检查
Zabbix agents 可以执行被动和主动两种检查方式
a、被动检查（passive check） 模式中 agent 应答数据请求，Zabbix server（或者proxy）询问agent数据,如CPU 的负载情况，然后 Zabbix agent 回送结果。
b、主动检查（Active checks） 处理过程将相对复杂。 Agent 必须首先从 Zabbix sever 索取监控项列表以进行独立处理，然后周期性地发送新的值给server。
执行被动或主动检查是通过选择相应的监测项目类型来配置的。item type. Zabbix agent 处理监控项类型有 Zabbix agent 和 Zabbix agent (active)。
⑳ Zabbix proxy
◆
◆
◆ 一个帮助 Zabbix Server 收集数据，分担Zabbix Server的负载的程序◆ Zabbix Proxy 是一个可以从一个或多个受监控设备收集监控数据，并将信息发送到Zabbix sever的进程，基本上是代表 sever工作的。 所有收集的数据都在本地进行缓存，然后传送到 proxy 所属的 Zabbix sever。
◆ 部署 Proxy 是可选的，但是可能非常有益于分散单个 Zabbix sever 的负载。 如果置有 proxy 收集数据，sever上的进程就会减少 CPU 消耗和磁盘 I / O 负载。
◆ Zabbix proxy 是完成远程区域、分支机构、没有本地管理员的网络的集中监控的理想解决方案。
◆ Zabbix proxy需要使用独立的数据库。
