259 lines
10 KiB
Markdown
259 lines
10 KiB
Markdown
<h1><center>zabbix监控入门</center></h1>
|
||
|
||
|
||
|
||
------
|
||
|
||
## 一：监控介绍
|
||
|
||
你用过哪些监控软件
|
||
|
||
zabbix 和 nagios、cacti、ganglia 有什么区别
|
||
|
||
zabbix 有那些好处
|
||
|
||
zabbix 的监控流程是什么
|
||
|
||
zabbix 常见监控项有那些
|
||
|
||
#### 1.cacti
|
||
|
||
Cacti 是一套基于 PHP、MySQL、SNMP 及 RRD Tool 开发的监测图形分析工具,Cacti 是使用轮询的方式由主服务器向设备发送数据请求来获取设备上状态数据信息的,如果设备不断增多,这个轮询的过程就非常的耗时,轮询的结果就不能即时的反应设备的状态了。Cacti 监控关注的是对数据的展示,却不关注数据异常后的反馈。如果凌晨 3 点的时候设备的某个数据出现异常,除非监控人员在屏幕前发现这个异常变化,否则是没有任何报警机制能够让我们道出现了异常。
|
||
|
||
#### 2.Nagios
|
||
|
||
Nagios 是一款开源的免费网络监控报警服务,能有效监控Unix、Windows和Linux的主机状态,交换机、路由器和防火墙等网络设置,打印机、网络投影、网络摄像等设备。在系统或服务状态异常时发出邮件或短信报警第一时间通知运维人员,在状态恢复后发出正常的邮件或短信通知。Nagios 有完善的插件功能,可以方便的根据应用服务扩展功能。
|
||
|
||
Nagios 已经可以支持由数万台服务器或上千台网络设备组成的云技术平台的监控,它可以充分发挥自动化运维技术特点在设备和人力资源减少成本。只是 Nagios 无法将多个相同应用集群的数据集合起来,也不能监控到集群中特殊节点的迁移和恢复。
|
||
|
||
#### 3.Ganglia
|
||
|
||
Ganglia 是 UC Berkeley 发起的一个开源集群监视项目,设计用于测量数以千计的节点。Ganglia 的核心包含 gmond、gmetad 以及一个 Web 前端。主要是用来监控系统性能,如:CPU 、内存、硬盘利用率, I/O 负载、网络流量情况等,通过曲线很容易见到每个节点的工作状态,对合理调整、分配系统资源,提高系统整体性能起到重要作用,目前是监控HADOOP 的官方推荐服务。
|
||
|
||
#### 4.Zabbix
|
||
|
||
Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix 能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
|
||
|
||
Zabbix 是由 Alexei Vladishev 创建，目前由 Zabbix SIA 在持续开发和支持。
|
||
|
||
Zabbix 是一个企业级的分布式开源监控方案
|
||
|
||
Zabbix 是一款能够监控各种网络参数以及服务器健康性和完整性的软件
|
||
|
||
Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题
|
||
|
||
基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。这些功能使得Zabbix成为容量规划的理想方案
|
||
|
||
Zabbix支持主动轮询和被动捕获。Zabbix所有的报告、统计信息和配置参数都可以通过基于Web的前端页面进行访问
|
||
|
||
Zabbix是免费的。Zabbix是根据GPL通用公共许可证第2版编写和发行的。这意味着它的源代码都是免费发行的，可供公众任意使用
|
||
|
||
## 二：监控区别
|
||
|
||
nagios图形不是特别好，也可以安装图形插件，但是也不怎么好看
|
||
|
||
nagios一般情况下如果需要图形可以和cacti配合使用
|
||
|
||
cacti的监控是轮询监控,效率低，图形相对nagios比较好看
|
||
|
||
zabbix和nagios因为是并发监控，对cpu的要求更高
|
||
|
||
zabbix在性能和功能上都强大很多
|
||
|
||
zabbix的图形相当漂亮
|
||
|
||
支持多种监控方式 zabbix-agent snmp 等等
|
||
|
||
支持分布式监控,能监控的agent非常多
|
||
|
||
zabbix有图形的web配置界面，配置简洁
|
||
|
||
zabbix支持自动发现功能
|
||
|
||
## 三：监控架构
|
||
|
||
|
||
|
||
## 四：zabbix简介
|
||
|
||
#### 1.zabbix优点
|
||
|
||
开源,无软件成本投入
|
||
|
||
Server 对设备性能要求低
|
||
|
||
支持设备多,自带多种监控模板
|
||
|
||
支持分布式集中管理,有自动发现功能,可以实现自动化监控
|
||
|
||
开放式接口,扩展性强,插件编写容易
|
||
|
||
Api 的支持,方便与其他系统结合
|
||
|
||
#### 2.zabbix缺点
|
||
|
||
需在被监控主机上安装 agent,所有数据都存在数据库里, 产生的数据据很大,瓶颈主要在数据库
|
||
|
||
#### 3.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
|
||
|
||
#### 4.zabbix监控方式
|
||
|
||
被动模式：
|
||
|
||
相对于agent而言；agent, server向agent请求获取配置的各监控项相关的数据，agent接收请求、获取数据并响应给server
|
||
|
||
主动模式：
|
||
|
||
相对于agent而言；agent(active),agent向server请求与自己相关监控项配置，主动地将相关的数据发送给server
|
||
|
||
## 五：zabbix相关组件
|
||
|
||
#### 1.Zabbix Server
|
||
|
||
Zabbix server 是 agent 程序报告系统可用性、系统完整性和统计数据的核心组件，是所有配置信息、统计信息和操作数据的核心存储器
|
||
|
||
#### 2.Zabbix 数据库存储
|
||
|
||
所有配置信息和 Zabbix 收集到的数据都被存储在数据库中
|
||
|
||
#### 3.Zabbix Web 界面
|
||
|
||
为了从任何地方和任何平台都可以轻松的访问Zabbix, 我们提供基于Web的Zabbix界面。该界面是Zabbix Server的一部分，通常(但不一定)跟Zabbix Server运行在同一台物理机器上
|
||
|
||
#### 4.Zabbix Proxy 代理服务器
|
||
|
||
Zabbix proxy 可以替Zabbix Server收集性能和可用性数据。Proxy代理服务器是Zabbix软件可选择部署的一部分；当然，Proxy代理服务器可以帮助单台Zabbix Server分担负载压力
|
||
|
||
#### 5.Zabbix Agent 监控代理
|
||
|
||
Zabbix agents监控代理 部署在监控目标上，能够主动监控本地资源和应用程序，并将收集到的数据报告给Zabbix Server
|
||
|
||
## 六：Zabbix常用术语的含义
|
||
|
||
#### 1.主机 (host)
|
||
|
||
一台你想监控的网络设备，用IP或域名表示
|
||
|
||
#### 2.主机组 (host group)
|
||
|
||
主机的逻辑组；它包含主机和模板。一个主机组里的主机和模板之间并没有任何直接的关联
|
||
|
||
#### 3.监控项 (item)
|
||
|
||
你想要接收的主机的特定数据，一个度量数据。
|
||
|
||
#### 4.触发器 (trigger)
|
||
|
||
一个被用于定义问题阈值和“评估”监控项接收到的数据的逻辑表达式
|
||
|
||
#### 5.事件 (event)
|
||
|
||
单次发生的需要注意的事情，例如触发器状态改变或发现有监控代理自动注册
|
||
|
||
#### 6.异常 (problem)
|
||
|
||
一个处在“异常”状态的触发器
|
||
|
||
#### 7.动作 (action)
|
||
|
||
一个对事件做出反应的预定义的操作。
|
||
|
||
一个动作由操作(例如发出通知)和条件(当时操作正在发生)组成
|
||
|
||
#### 8.升级 (escalation)
|
||
|
||
一个在动作内执行操作的自定义场景; 发送通知/执行远程命令的序列
|
||
|
||
#### 9.媒介 (media)
|
||
|
||
发送告警通知的手段；告警通知的途径
|
||
|
||
#### 10.通知 (notification)
|
||
|
||
利用已选择的媒体途径把跟事件相关的信息发送给用户
|
||
|
||
#### 11.远程命令 (remote command)
|
||
|
||
一个预定义好的，满足一些条件的情况下，可以在被监控主机上自动执行的命令
|
||
|
||
#### 12.模版 (template)
|
||
|
||
一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用，LLD，Web场景）的集合
|
||
|
||
#### 13.应用 (application)
|
||
|
||
一组监控项组成的逻辑分组
|
||
|
||
#### 14.web 场景 (web scenario)
|
||
|
||
利用一个或多个HTTP请求来检查网站的可用性
|
||
|
||
#### 15.前端 (frontend)
|
||
|
||
Zabbix提供的web界面
|
||
|
||
#### 16.Zabbix server
|
||
|
||
Zabbix软件实现监控的核心程序，主要功能是与Zabbix proxies和Agents进行交互、触发器计算、发送告警通知；并将数据集中保存
|
||
|
||
#### 17.Zabbix agent
|
||
|
||
一个部署在监控对象上的，能够主动监控本地资源和应用的程序
|
||
|
||
Zabbix agent 部署在监控的目标上，主动监测本地的资源和应用(硬件驱动，内存，处理器统计等)
|
||
|
||
#### 18.被动（passive）和主动（active）检查
|
||
|
||
Zabbix agents 可以执行被动和主动两种检查方式
|
||
|
||
被动检查（passive check） 模式中 agent 应答数据请求，Zabbix server（或者proxy）询问agent数据,如CPU 的负载情况，然后 Zabbix agent 回送结果。
|
||
|
||
主动检查（Active checks） 处理过程将相对复杂。 Agent 必须首先从 Zabbix sever 索取监控项列表以进行独立处理，然后周期性地发送新的值给server。
|
||
|
||
执行被动或主动检查是通过选择相应的监测项目类型来配置的。item type. Zabbix agent 处理监控项类型有 Zabbix agent 和 Zabbix agent (active)。
|
||
|
||
#### 19.Zabbix proxy
|
||
|
||
一个帮助 Zabbix Server 收集数据，分担Zabbix Server的负载的程序
|
||
|
||
Zabbix Proxy 是一个可以从一个或多个受监控设备收集监控数据，并将信息发送到Zabbix sever的进程，基本上是代表 sever工作的。 所有收集的数据都在本地进行缓存，然后传送到 proxy 所属的 Zabbix sever
|
||
|
||
Zabbix proxy需要使用独立的数据库
|
||
|
||
## 七：zabbix监控部署
|
||
|
||
#### 1.环境准备
|
||
|
||
两台服务器，一台做zabbix-server，一台做zabbix-agent
|
||
|
||
| **zabbix-server** | **10.0.1.3** |
|
||
| :---------------: | :----------: |
|
||
| **zabbix-agent** | **10.0.1.4** |
|
||
|
||
关闭防火墙
|
||
|
||
关闭selinux
|
||
|
||
保证yum仓库可用
|
||
|
||
保证网络可用
|
||
|
||
#### 2.项目部署
|
||
|
||
```shell
|
||
https://www.zabbix.com/download
|
||
``` |