zabbix监控系统可用性干货系统学习

导读转自@TWT社区~文介绍了Zabbix基本概念及其特点，阐述zabbix系统环境搭建与基础安装，如何实现对各类操作系统、硬件设备、应用软件监控告警。1介绍1....

转自@TWT社区~

文介绍了Zabbix 基本概念及其特点，阐述 zabbix 系统环境搭建与基础安装，如何实现对各类操作系统、硬件设备、应用软件监控告警。

1 介绍1.1 摘要

本文深入浅出，切近实际运维应用，由 zabbix 3.4 版本入手，学习 zabbix 监控告警实现方式，由 zabbix 5.0 浅出实现快速部署、快速应用。本人从业多年，关注 zabbix 开源社区，以及 zabbix 官方组织的各种峰会，了解到的前沿技术，因随着运维监控软件的不断发展，未来软件将是开箱即用的模式，运维人员在使用监控软件，不必再去花精力编写运维监控程序，而是完善监控项，这样的方式对于初学者越来越不容易学习。因此，学习 zabbix 3.4 版本是非常必要的， zabbix 官方那时候还没有集成更多的模板以直接使用，那里有大量的监控项需要自己编写实现，不仅全面了解了 zabbix ，也是对 linux 命令、 shell 脚本、 Python 语言等的很好学习，也有助于二次开发，自定义监控项的配置。

1.2 背景

以下是部署实施基于 zabbix 监控系统的建设背景，以解决诸多运维实际问题：

目前公司系统运维主要采用人工检查的方式，问题发现的时效性较低，容易出现问题不被立刻发现，人工也容易疏忽漏查，导致问题处理不及时，影响信息化系统服务效果，就需要更好保障系统稳定运行。

公司信息化系统、操作系统、设备种类多，各类信息化系统如：OA 、 U9 ， PLM 、企业邮箱等，又有 Linux 、 Windows 、 Vmware 、 EMC 等系统，设备有服务器、交换机、存储等，机房环境有动环系统进行监测。如此众多的信息化系统平台，当然需要统一运维界面，实时监测各系统运行状况，为运维工作提供便利。

为适应时代的发展，未来是个智能化的时代，运维工作要实现自动化，运维工作者要向开发去转变，开发即运维，或许有一天人工智能将代替运维人员，而今的运维人员希望是人工智能创造者的一份子，了解自动化运维，与时俱进是非常必要的。

综上，为了提高运维效率，节约人力资源，对设备、机房环境实时监控，能有效、实时发出告警信息，从而及时发现问题快速响应。急需一套能满足以上需求的监控系统，经考量 zabbix 监控系统应用广泛，可实现上述功能。

1.3 系统简介

Zabbix 是一个企业级解决方案，支持实时监控数千台服务器，虚拟机和网络设备，采集百万级监控指标。Zabbix 完全开源免费。

Zabbix 的主要特点有：

1. 指标收集：从任何设备、系统、应用程序上进行指标采集
2. 问题监测：定义智能阈值
3. 可视化：单一界面管理平台
4. 告警和修复：确保及时、有效的告警
5. 安全和认证：保护您所有层级的数据
6. 轻松搭建部署：大批模板，开箱即用，节省您宝贵的时间
7. 自动发现：自动监控大型动态环境
8. 分布式监控：无限制扩展
9. ZABBIX API ：将 Zabbix 集成到您 IT 环境的其他任何部分

1.4 名词术语

Zabbix 系统有一些自己定义的专业术语，为更好的熟悉系统名词，下面主要介绍本文以及 zabbix 常用的术语。

主机（ host）

一台你想监控的服务器、工作站、交换机等网络设备，用 IP 或者域名表示。

主机组（ host group）

多台具有某种相同角色、属性的集合。例如，所有 windows 服务器放在一个叫 “windows server” 的主机组中。

监控项（ item）

你想要监控、获取主机或主机组的哪些数据。例如：我想监控所有机器的 cpu 使用情况，则需要建一个监控项，用于获取所有服务器的 CPU 使用率。

触发器（ trigger）

由逻辑表达式组成的按照预先设置好的阀值来评估由监控项采集到的数据。触发器有两种状态，分别为 “ 问题 ” 和 “ 已解决 ” 。例如：在上述通过监控项获取了 CPU 的使用率，假如我想超过 CPU 使用超过 80% 的就预警，则可以创建一个触发器，当监控项获取的值超过 80% 时就按照预设的情况报警，状态为 “ 问题 ” ；低于 80% 时认为报警解除，状态恢复为 “ 已解决 ” 。

事件（ event）

单次发生的需要注意的事情，例如上述触发器状态由问题变成了正常或者由正常变成了问题，均可以称为一个事件。事件包括触发器事件、自动发现事件、自动注册事件和内部事件 4 个部分。

动作（ action）

一个对事件做出反应的预定义的操作；例如 CPU 使用超过 80% 时，触发器状态变成了问题，即产生了一个事件，我们可以针对此事件预设一个动作（比如执行命令 reboot ），则系统会自动针对此事件的预设动作执行命令 reboot 。

媒介（ media）

发送告警通知的手段或途径。例如：当 CPU 超过 80% 报警后，通过媒介（邮件、短信、自定义脚本、微信等）形式告知。

模板（ template）

一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用， web 场景等）的集合。简单的说，即多个监控项的集合。

应用集（ application）

一组监控项组成的逻辑分组。例如， CPU 的监控项，归集至 cpu ，在想查看有关 cpu 方面的信息时，可以直接在界面上提供的搜索框内查询所有有关 cpu 的信息。

zabbix server

zabbix 系统实现监控的核心程序，主要功能是与被监控主机、代理机等进行交互、触发器计算、发送告警通知、收集数据并存储等。

zabbix agent

一个部署在监控对象上的，能够主动监控本地资源和应用的程序；一般来讲，我们需要在所有被监控服务器上安装此程序。

zabbix proxy

一个帮助 zabbix server 收集数据，分担 zabbix server 的负载压力的程序；另外，还可以用在 server 与 agent 机器网络不通，使用 proxy 作为网络代理，实现两者的通信功能。

1.5 系统架构

系统结构说明：由 web 、 linux 、 php 、 mysql 等组件部署安装，实现 zabbix server 服务端；由被监控对象例如：Windows 系统， linux 系统、 Vmware 虚拟化平台、交换机，存储等组成了 agent 端。Zabbix server 可采用主动模式，获取 agent 上数据，也可采用被动模式，接收 agent 定时发送的数据。

2 指标2.1 软件版本

版本选择说明：目前 zabbix 3 版本成熟稳定，各大企业公司运维监控系统运行于该平台上，提供的监控项比 zabbix 第 1 和 2 版本丰富，完全能满足监控对象的需要；至今 zabbix 第 3 版已持续发布 4 年多时间，开源系统积累了大量的资料与研究人员，可供交流学习，能很好服务于 zabbix 定制化；zabbix 4.0 版本 2018 年 10 月正式发布， 4.2 版本于 2019 年 4 月正式发布，目前最新的是 zabbix 5.2 版本，版本持续更新满足未来升级发展的需要，新版本增加了 ELK 、时序数据库，以及前端 web 优化，但监控本质并未发生大的变化。

2.1 硬件指标

Zabbix 可以运行于虚拟环境也可以部署在服务器上，因 zabbix 采集数据主要是文本，对网络带宽要求不高，千兆速率足矣，只要满足性能上的要求即可，主要为 CPU 、内存和硬盘三项。结合 zabbix 官网给出的指标、实际监控项数量、历史记录保存时间长度。根据上表的参考标准，测试环境建议小型化部署。