自动化-解放运维双手 - 提升运维小路 节省很多时间
架构部署 -- 稳定运行 -- 很快速定位&解决问题
Cacti-- 监控随着时间不断变化的数值（cpu、内存使用率、网卡流量） - 服务状态不能-不能实现自动报警-必须安装额外的插件 + 生产连用
Nagios -- 监控服务状态（分级） - 所有监控都算需要管理员安排（监控什么系统、什么服务、什么参数、什么时间、通知谁） --->通过web展示
国内硬件防火墙厂商（天融信、深信服、绿盟、山石、启明）国际品牌（juniper、飞塔等等）
负载均衡 -- 针对pv量大（客户端流量） -- 服务数据是一样
分布式 -- 针对服务器个数--数据占百分之多少
zabbix基础概念及工作原理整理
一、什么是zabbix
Zabbix能监控各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理元快速定位、解决存在的各种问题，是一个基于web界面的提供分布式系统监视以及网络监视功能的开源解决方案。
主要有以下几个功能组件组成：
参考官方文档：https://www.zabbix.com/documentation/4.0/zh/manual/introduction/overview
zabbix4.0与3.0对比可以实现实时抓取
Zabbix的核心组件
Server是Zabbix软件的核心组件，agent向其报告可用性、系统完整性信息和统计信息，server上的Database组件（Mysql Oracle SQLite4 PG DB2） 也是存储所有配置信息，统计信息和操作信息的核心存储库。
数据库
所有配置信息以及Zabbix采集到的数据都被存储在数据库中。
Web界面
该界面是Zabbix server的一部分通常（但不一定）和Zabbix server运行在同一台物理机上。
Proxy
Zabbix proxy可以代替Zabbix server采集性能和可用性数据。Zabbix proxy在Zabbix的部署是可选部分；但是proxy的部署可以很好的分担单个Zabbix server的负载。
1、下游设备500台（经验值） -- 一台server内存cpu、带宽承受不住
2、跨机房
Agent
Zabbix agent 部署在被监控目标上（服务器或者是、pc），用于主动监控本地资源和应用程序，并将手机的数据发送给Zabbix server
二、监控功能
主机的性能监控、网络性能监控、数据库性能监控、多种告警方式、详细的报表图标回值；
监控主机zabbix有准用的agent，可以监控Linux、Windows、等、
监控网络设备zabbix通过SNMP,SSH等(通过自定义方式）
监控中间件（java） -Zabbix-java-gateway（JMX）
监控硬件指标（温度、湿度、转速等） -IPMI
可监控对象：
设备：服务器、路由器、交换机等
软件：OS、网络、应用程序等
主机性能指标监控
故障监控：宕机、服务器不可用、主机不可达
三、Zabbix工作原理
一个监控系统运行的大概流程是这样的：
zabbix agent需要安装到监控的主机上，他需要定期收集各项数据，并发送到zabbix server端 zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展示和绘图。这里agent收据数据分为主动和被动（客户端主动发送数据给服务器-主动模式；客户端等待服务器发送请求，被动收集反馈-被动模式）两种模式；
主动:agent请求server获取主动的监控项列表，并主动将监控向内需要检测的数据交给server / proxy
被动：server向agent请求获取监控的数据，agent返回数据。
四、zabbix 工作进程
默认情况下zabbix包含6个进程：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server 另外一个zabbix_java_gateway是可选的，这个需要单独安装。
zabbix_agentd
客户端守护进程，此进程手机客户端数据，例如cpu负载、内存、硬盘使用情况等
zabbix_get
zabbix工具，单独使用的命令，通常在server或者proxy端执行获取远程客户端信息的命令。通常用于排错，例如在server端获取不到客户端内存数据，可以输用zabbix_get获取客户端的内容的方式来做故障排查。自定义key去采集需要数据
zabbix_sender
zabbix工具，用于发送数据给server或者proxy，通常用于耗时比较长的检查，很多检查非常耗时间，导致zabbix超时，于是在脚本执行完毕之后使用sender主动提取数据。
zabbix_server
zabbix服务端守护进程，zabbix_agent、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server（说明：当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据）
zabbix_proxy--万年老二 -- server宕机了-- 不可以-- 并不支持GUI图形（web组件）--但是具备独立的数据库（备份-X%）工具人
zabbix代理守护进程。功能类似server，唯一不同的是它只是一个中转站，他需要把收集到的数据提交/被提交到server里
zabbix_java_gateway
zabbix2.0之后引入的一个功能。顾名思义：java网络，类似agentd，但是只用于java方面。需要特别注意的是，它只能主动去获取数据，而不能被动获取数据。他的数据最终会给到server或者proxy。
五、zabbix常用术语解释 --
(1)、主机（host）：要监控的网络设备，可由IP或DNS名称指定；--->必须被加入到某个主机组的
(2)、主机组（host group）：主机的逻辑容器，可以包含主机和模板，但是同一个组织内的主机和模板不能相互链接；主机组通常再给用户或用户组指派监控权限时使用； -->Zabbix设计监控“模板” -->批量监控具备相同特征的服务器|数据-->不可能只有一台设备具备单独的功能，授权只能给“主机组“授权
(3)、监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是zabbix进行数据手机的核心，相对某个监控对象，每个item都由”key“标识；--->自定义监控项 -- http-80 -冲突 ”http-80“ -->让监控项 "唯一" -->监控项 “身份证号key值”
(4)、触发器（trigger）：一个表达式，用于评估某监控对象的特定item内接收到的数据是否在合理范围内，也就是阈值（临界值）；接受的数据量大于阈值时，触发器状态将从“OK”转变为“Problem”，当数据再次恢复到合理范围，又转变为“ok”（cpu使用率20~80%之间--低于20%资源浪费 高于80%机器故障）
(5)、事件（event）：触发一个值得关注的事情，比如触发器状态转变，新的agent或重新上线的agent的自动注册等；
(6)、动作（action）：指对于特定时间先定义的处理方法，如发送通知，何时执行操作；--不仅仅可以报警-同时"可以控制服务" --例如： nginx宕机 -->通知管理员（注意|看看什么问题） +调用某个脚本让nginx自动重启
(7)、报警升级（escalation）：发送警报或者执行远程命令的自定义方案，如每隔5分钟发送一次警报共发送5次等；
根据职位&技术能力 --warning-->黄色-->普通运维--5分钟 *3次 =15分钟
--warning-->橙色-->普通运维/运维组长-->5分钟*3次
(8)、媒介（media）：发送通知的手段或者通道，如Email、jabber或者SMS等；---->Email、短信、（短信猫-小设备（linux系统）-1毛一条 -->注册-验证码- "文字模板" -必须遵守30个字节） 飞信----> 邮箱|微信|钉钉最常用等等
(9)、通知（notification）：通过选定的媒介向用户发送的有关某事件的信息；
(10)、远程命令（remote command）：预定义的命令，可在被监控主机处于某特定条件下是自动执行；
(11)、模板（template）：用于快速定义被监控主机的预设条目集合，通常包含了item、trigger、graph、screen、applicatiom、以及low-level discovery rule；模板可以直接链接之某个主机 --模板可以链接模板；
(12)、应用（application）：一组item的集合；
(13)、web场景（web scennario）
(14)、前端（frontend）：Zabbix的web 接口；
六、zabbix 监控架构
在实际监控架构中，zabbix根据网络环境、监控规模等 分了三种架构：server-client master-node-client、server-proxy-client三种
1、server-client架构
zabbix的最简单的架构，监控器和被监控机之间不经过任何代理直接由zabbix server和zabbix agent之间进行数据交互。适用于网络比较简单，设备比较少的监控环境。
2、server-proxy-client架构
其中proxy是server、client之间沟通的一个桥梁，proxy本身没有前端，而且其本身并不存放数据，只是将agent发来的数据暂时存放，，而后在提交给server，该架构经常是和master-node-client架构作比较的架构，一般适用于跨机房，跨网络的中型网络架构的监控。
3、master-node-client架构
该架构是zabbix最复杂的监控架构，适用于跨网络、跨机房、设备较多的大环境。每个node同时也是一个server端，node下面可以接proxy，也可以直接接client。node由自己的配置文件和数据库，其要做的是将配置信息和监控数据向master同步，master的故障或损坏不影响node其下的架构的完整性。
