我们监控的初衷就是当某些指标不符合我们的需求时，我们能够在第一时间发现异常， 所以，监控工具需要定期的对被监控主机进行检查、信息收集等操作，当被监控主机出现异常时，能够及时报警、通知管理员，并且需要记录这些异常，以便我们分析这些数据，查漏补缺，那么，一个监控工具就应该具备采集信息、存储信息、展示信息、报警通知等功能，而zabbix就可以做到这些，除了zabbix,你可能还听说过cacti、nagios、 ganglia等 类似的监控系统，但是此处,我们只聊zabbix
好了，我们大概了解了一下zabbix,那么我们通过zabbix能够监控哪些硬件资源呢?
理论上来说，只要是与我们的业务有关的硬件资源，都应该被监控，比如主机、交换机、路由器、UPS等等，但是，监控它们的前提是能与它们进行通讯，那么问题来了，由于硬件的不同，导致我们无法使用统一的方法去监控他们，这个时候，要监控程序有一定的通用性者说，监控程序需要能够与多种硬件设备通讯，才能满足我们的监控需求
举个例子:
如果被监控的对象是一台安装了linux操作系统的服务器，那么我们可以通过ssh或者telnet这种远程工具与被监控对象建立起通讯的通道，可是如果被监控的对象是一台安装了其他操作系统的服务器呢，更甚之，被监控的对象并不是服务器，而只是一台交换机或者路由器呢，所以, zabbix如果想要能够全面的监控这些对象，则需要能够通过各种方法与它们进行通讯
那么zabbix能够支持哪些通讯方式呢，总结如下:
agent:通过专用的代理程序进行监控，与常见的master/agent模型类似,如果被监控对象支持对应agent,推荐首选这种方式
ssh/telnet:通过远程控制协议进行通讯，比如ssh或者telnet。
SNMP:通过SNMP协议与被监控对象进行通讯,SNMP协议的全称为Simple Network Management
Protocol ,被译为"简单网络管理协议"，通常来说，我们无法在路由器、交换机这种硬件上安装agent,但是这些硬件往往都支持SNMP协议，SNMP是一种比较久远的、通行的协议，大部分网络设备都支持这种协议，其实SNMP协议的工作方式也可以理解为master/agent的工作方式，只不过是在这些设备中内置了 SNMP的agent而已，所以，大部分网络设备都支持这种协议。
IPMI:通过IPMI接口进行监控，我们可以通过标准的IPMI硬件接口，监控被监控对象的物理特征，比如电压，温度,风扇状态，电源状态等。
jMX:通过JMX进行监控，jMX ( Java Management Extensions,即Java管理扩展)，监控JVM虚拟机时,使用这种方法也是非常不错的选择。
好了，我们刚才提到了zabbix agent, 一般情况下，我们将zabbix agent部署到被监控主机上，由agent采集数据，报告给负责监控的中心主机，中心主机也就是master/agent模型中的master,负责监控的中心主机被称为zabbix server, zabbix server将从agent端接收到的信息存储于zabbix的数据库中，我们把zabbix的数据库端称为zabbix database,如果管理员需要查看各种监控信息，则需要zabbix的GUI,zabbix的GUI是一种Web GUI,我们称之为zabbix web, zabbix web是使用php编写的，所以，如果想要使用zabbix web展示相关监控信息，需要依赖LAMP环境，不管是zabbixserver，或是zabbix web,他们都需要连接到zabbixdatabase获取相关数据
当监控规模变得庞大时，我们可能有成千上万台设备需要监控，这时我们是否需要部署多套zabbix系统进行监控呢?如果部署多套zabbix监控系统，那么监控压力将会被分摊，但是，这些监控的对象将会被尽平均的分配到不同的监控系统中，这个时候，我们就无法通过统一的监控入口 ,去监控这些对象了，虽然分摊了监控压力，但是也增加了监控工作的复杂度，那么，我们到底该不该建立多套zabbix监控系统从而分摊巨大的监控压力呢?其实，zabbix天生就有处理这种问题的能力，因为zabbix支持分布式监控，我们可以把成千上万台的被监控对象分成不同的区域，每个区域中设置一台代理主机， 区域内的每个被监控对象的信息被agent采集，提交给代理主机，在这个区域内，代理主机的作用就好比zabbix server,我们称这些代理主机为zabbix proxy, zabbix proxy再将收集到的信息统一提交给真正的zabbix server处理，这样,zabbix proxy分摊了zabbix server的压力，同时，我们还能够通过统一的监控入口，监控所有的对象，当监控规模庞大到需要使用zabbix proxy时，zabbix的架构如下图，我们可以对比下图，理解上述描述。
我们再把刚才说到的各种组件总结一遍:
zabbix agent:部暑在被监控主机上，负责被监控主机的数据，并将数据发送给zabbix server。
zabbix server:负责接收agent发送的报告信息，并且负责组织配信息、统计信息、操作数据等。
zabbix database:用于存储所有zabbix的配i信息,监控数据的数据库。
zabbix web : zabbix的web界面，管理员通过web界面管理zabbix配置以及查看zabbix相关监控信息，可以单独部署在独立的服务器上。
我们知道，agent端会将采集完的数据主动发送给server端，这种模式我们称之为主动模式，即对于agent端来说是主动的。其实，agent端也可以不主动发送数据，而是等待server过来拉取数据，这种模式我们称之为被动模式。不管是主动模式还是被动模式，都是对于agent端来说的，而且，主动模式与被动模式可以同时存在，并不冲突。管理员可以在agent端使用一-个名为zabbix_ sender的工具，测试是否能够向server端发送数据。管理员可以在server端使用一个名为zabbix_ get的工具，测试是否能够从agent端拉取数据
知识归纳
zabbix agent:zabbix客户端负责数据收集上传
zabbix server: zabbix的服务端负责数据汇总处理告警策略告警发送等等
zabbix web: zabbix前端页面提供了友好的展示和操作界面负责数据的展示监控系统的配管理用户权限管理等等
database:数据和配置存储数据库zabbix支持多种数据库包括mysql oracle db2等等
java Gateway: java网关负责通过JMX监控收集java应用性能数据
zabbix proxy: zabbix代理分布式部署架构会用到主要是收集设备的监控数据并将数据发送给对应的zabbix server
面试问题
什么是监控系统?
互联网监控软件:分为单一监控程序和分布式监控程序
单一监控程序: win中的任务管理器linux中的top vmstat iostat等
分布式监控程序: zabbix open-falcon
硬件监控:通过传感器
为什么需要监控系统?
为用户提供稳定高效安全的服务
监控系统功能:
数据收集，数据展示(分析原始数据)，警告策率，告警发送(短信邮件微信电话)，报表管理，认证权限(不同的部门所关心的数据是不一样的)
监控系统趋势
智能监控: KPI聚类，瓶颈分析，KPI异常检测，定位，故障预测，容量预估
如何选择监控系统
是否需要监控的设备，系统，应用的规模/类型/地理位置
是否需要监控的设备，系统，应用增长规模
是否需要哪些数据展示和报表
是否需要哪些告警策略
是否需要哪些告警发送方式
是否需要自定义监控
是否需要认证和权限控制
是否可以自动化部署配置
是否需要高可用或多机房部署
是否需要后期的支持服务?活跃度
是否需要与第三方系统对接
是否需要故障自愈
对比测试作出决定
