一. 监控系统的功能概述
监控、从中文的字义来看,有两个内容,一是检测,二是控制。重点在第一个字眼,即检测、预防的意思。
监控,对应的英文单词是 Monitoring。在计算机领域,可以将其分为5种监控类型。
- 应用性能监控
- 业务交易监控
- 网络性能监控
- 操作系统监控
- 网络站点监控
上面5种类型将监控这个概念划分成了多个领域。我们通常所说的监控,都会模糊的包含以上5个细分的领域。在任何一个 IT业务环境中,都会存在各种各样的硬件设备、软件应用等。
按照逻辑层次划分,我们可以将我们可以将监控行为划分为5个层次:基础设施监控、系统层监控应用层监控、业务监控、端用户体验监控。
最底层基础设施监控:这层一般由运维人员负责,涉及到的方面比较接近硬件体系,例如网络,交换机,路由器等低层设备,这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性,所以需要对网络的流量,丢包情况、错包情况,连接数等等这些基础设施的核心指标进行监控。
系统层监控:这层涵盖了物理机、虚拟机、操作系统等,这些都是属于系统级别监控的方面,主要对几个核心指标进行监控,如cpu 使用率、内存占用率,磁盘 I0 和网络带宽情况。
应用层监控:这层涉及到方面和服务紧密相关,例如对 url访问的性能,访问的调用数,访问的延迟,还有对服务提供性能进行监控,服务的错误率等,同时对sql 也需要进行监控,查看是否有慢 sql。对于cache 来说,需要监控缓存的命中率和性能,每个服务的响应时间等等。
二. 监控系统的实现原理
1. 模块组成
一个监控系统的组成大体可以分为两部分:数据采集部分和数据存储、分析告警、展示部分,这两部分构成了监控系统的基本模型。
2. 采集协议
按照支持的协议方式,监控 IT数据采集可以分为两种:专用客户端采集和公用协议采集。
3. 监控模式
监控系统数据采集的工作模式可以分为被动模式和主动模式。被动模式指的是服务器端到客户端采集数据;主动模式是客户端主动上报数据到服务器。
一般来说被动模式对监控端服务器的开销较大,适合小规模的监控环境:被动模式对监控端服务器的开销较小,适合大规模的监控环境。
4. 理架构
对于大规模的监控环境,被监控节点比较多,并且监控类型也很多,监控产生的数据和网络连接开销非常大,数据采集方式除了使用主动模式之外,还需要使用代理的架构,通过代理架构分摊服务器端的性能开销。另外,代理架构还支持跨地域、跨网络的分布式监控。常见的代理架构为 C/S/P 架构,即 client/Proxy/Server。
三:监控系统的开源产品
1:zabbix
Zabbix是一款出色的企业级运维监控平台,可用于监控从服务器、网络设备到 web 应用程序和数据库的性能和可用性的一切;它可以安装在 Linux、AIX、Windows、Solaris、Macos x、FreeBsD、openBSD 等系统上使用,具有非常良好的适配能力
2:Prometheus+Grafana
Prometheus是一个开源系统监控和警报工具包,主要用于对基础设施的监控,包括服务器(CPU、MEM等)、数据库(MYSQL、PostgresQL 等)、web 服务等,几乎所有东西都可以通过Prometheus 进行监控。
3:Cacti
Cacti 是一款网络流量监测图形分析工具,它连接到 RRDTo01,生成与网络数据相关的图表,具有非常强大的数据和用户管理功能,可以指定每一个用户能査看树状结构、host 以及任何一张图,还可以与LDAP 结合进行用户验证,同时也能自己增加模板。
4:Nagios
Nagios 是一个监控系统运行状态和网络信息的监控系统,它可以监控所指定的本地或远程主机以及服务,同时提供异常通知功能等;能够监控几乎所有类型的组件,如网络协议、操作系统、系统指标、用程序、服务、web 服务器、网站、中间件等。
5:Checkmk
Checkmk 是一个高度可扩展的监控工具,可监控服务器、网络、云资产、数据库、容器、物联网等。
它有两种模式可用,基础版完全开源并提供免费和无限制的监控,企业版附带附加功能。
Checkmk 具有部署快、高度自动化、配置灵活的特点。
6:openNMS
OpenNMS 是一个企业级基于 Java/XML 的分布式网络和系统监控管理平台。它能够显示网络中各中终端和服务器的状态和配置,为管理网络提供有效的信息。它专为 Linux 设计,但也支持 windows、Solaris 和 OSX。
OpenNMS 可以使用 JMX、WMI、SNMP、NRPE、XML HTTP、JDBC、XML、JSON 等收集系统指标。
7:Netdata
Netdata 是一款 Linux 性能实时监测工具,它可以为 Linux 系统、应用程序、SNMP 服务等提供实时的性能监测,目前在物理系统、虚拟机、容器和物联网/边缘设备上运行。Netdata具有监控指标多而广,数据收集速度快等特点,可以同时并发监控数万个指标,交互式可视化和富有洞察力的健康警报可以即时诊断基础架构中的异常情况。
8:LibreNMS
LibreNMS 是一个开源、功能丰富且强大的网络监控系统,易于安装和配置,可以在多种平台上使用,它提供了广泛的功能,包括对各种协议的支持、性能监控、警报等;支持广泛的供应商、设备和协议,包括 Cisco、Linux、Windows、HP、Juniper、Dell、FreeBsD、Brocade、citrix、f5 Networks 等还可以根据接口进行接口分组,使用 SNMP、CDP、ARP、FDP、OSPF、LLDP、BGP 自动发现整个网络。
四. Zabbix 系统概述
Zabbix 是一款开源的企业级 IT 基础设施监控解决方案,由 Alexei Vladishev 于 2001 年开发,现由 Zabbix SIA 公司维护。它专为实时监控网络服务、服务器健康状况、应用程序及云资源而设计,通过分布式架构支持大规模监控场景,适用于从小型企业到大型数据中心的多种环境。
核心功能
- 多维度监控能力
- 基础设施监控:支持 Linux/Windows 服务器、网络设备(路由器/交换机)的 CPU、内存、磁盘、网络带宽等指标监控。
- 应用性能管理(APM):跟踪数据库(MySQL、PostgreSQL)、Web 服务(Nginx、Tomcat)、中间件的性能,如查询延迟、连接数、事务处理速度等。
- 云服务监控:兼容 AWS、Azure、OpenStack 等云平台,监控虚拟资源(如 EC2 实例、负载均衡器)的使用情况。
- 自定义监控:通过插件或脚本扩展监控范围,适配企业特定业务需求(如自定义日志分析、业务指标跟踪)。
- 灵活的数据采集方式
- Agent 模式:在被监控设备上安装 Zabbix Agent,主动上报数据(如 CPU 使用率)。
- 无 Agent 模式:通过 SNMP、JMX、SSH 等协议直接获取数据,适用于无法安装代理的设备(如网络设备)。
- Trapper 模式:由被监控端主动推送数据到 Zabbix 服务器,适用于防火墙环境或反向代理场景。
- 智能告警与通知
- 触发器(Trigger):基于预设规则(如“CPU 使用率 >90% 持续 5 分钟”)自动触发告警。
- 通知渠道:支持邮件、短信、Slack、钉钉、微信等多种方式,确保运维团队及时响应。
- 事件收敛:合并重复告警,避免“告警风暴”,提高故障处理效率。
- 数据可视化与分析
- 仪表盘与图形界面:实时展示监控指标趋势(如 CPU 利用率曲线、网络流量图)。
- 历史报表:生成 CSV、PDF 等格式的报表,支持数据导出,用于容量规划、性能分析和合规审计。
- 自定义图表:适配企业运维中心的可视化需求,支持多监控项组合展示。
- 自动化与扩展性
- 自动发现:自动识别网络中的新设备(如通过 IP 范围扫描)并添加到监控列表。
- Proxy 架构:通过代理服务器分担主服务器负载,支持跨机房、跨地域的分布式监控。
- API 集成:提供 REST API,可与 ITSM、CMDB 等系统集成,实现自动化运维流程。
- 系统架构
- Zabbix 采用 C/S(客户端-服务器)架构,核心组件包括:
- Zabbix Server:中央组件,负责数据收集、存储、分析和告警触发。
- Zabbix Agent:部署在被监控设备上,主动或被动上报数据。
- Database:存储配置信息、监控数据和历史记录,支持 MySQL、PostgreSQL、Oracle 等。
- Web Interface:基于 PHP 的 Web 前端,提供配置、展示和告警管理界面。
- Zabbix Proxy:可选组件,代替 Server 收集性能数据,减轻主服务器负载。
- 技术优势
- 开源免费:社区版完全开源,企业可根据需求自由定制,降低成本。
- 高扩展性:支持插件、API 接口和自定义脚本,轻松适配复杂 IT 环境。
- 成熟生态:社区活跃,文档和教程丰富,易于学习和部署。
- 企业级能力:支持数万节点监控,具备高可用性(HA)和分布式架构,满足大型企业需求。
- 跨平台兼容:支持 Windows、Linux、Unix 等主流操作系统,以及 VMware、Docker 等虚拟化平台。
五. Zabbix的功能特性
Zabbix 作为一款功能全面的开源监控系统,其核心特性覆盖了从数据采集到智能告警、从可视化展示到自动化运维的全流程。
多维度数据采集与监控
- 支持多种监控类型
- 主机监控:跟踪服务器、工作站、虚拟机的可用性(如 Ping 检测)和资源使用率(CPU、内存、磁盘 I/O)。
- 网络设备监控:通过 SNMP 协议监控路由器、交换机、防火墙的接口流量、错误包、带宽利用率等。
- 应用服务监控:支持 HTTP/HTTPS、FTP、SMTP 等服务的可用性检测,以及自定义端口和服务状态的监控。
- 数据库监控:集成 JMX、ODBC 等接口,监控 MySQL、PostgreSQL、Oracle 等数据库的连接数、查询性能、锁等待等指标。
- 云资源监控:兼容 AWS EC2、Azure VM、OpenStack 实例等云服务的状态和资源使用情况。
灵活的数据采集方式
- Zabbix Agent:轻量级代理程序,主动上报数据(如 /proc 文件系统信息)或响应 Server 请求。
- 无 Agent 模式:通过 SNMP、IPMI、SSH、Telnet 等协议直接获取数据,适用于无法安装代理的设备。
- 外部检查:调用自定义脚本或第三方工具(如 Nmap、Prometheus Exporter)采集数据,扩展监控范围。
- 依赖监控:定义监控项之间的依赖关系(如“Web 服务依赖数据库服务”),避免误报。
- 智能告警与事件管理
- 触发器(Trigger)与条件判断
- 基于监控项的阈值或表达式(如 {server:cpu.user.last(0)}>90)定义触发条件。
- 支持逻辑运算符(AND/OR)和复杂表达式,实现多条件组合告警(如“CPU >90% 且内存 <10% 剩余”)。
- 依赖触发器:避免上层服务故障触发下层组件的冗余告警(如“数据库故障时,不触发应用服务的高负载告警”)。
多渠道通知与升级策略
- 通知方式:支持邮件、短信、Slack、钉钉、Webhook、企业微信等,可自定义通知模板(如包含故障时间、影响范围)。
- 告警升级:定义未确认告警的升级路径(如“首次通知运维人员,30 分钟后未处理则通知主管”)。
- 维护模式:临时屏蔽特定主机或服务的告警,避免维护期间产生噪音。
- 事件关联与根因分析
- 事件标签:为告警添加标签(如“网络故障”“数据库锁等待”),便于分类和过滤。
- 问题时间线:展示告警从触发到恢复的全过程,结合相关监控数据辅助定位根因。
- 拓扑可视化:通过自动发现或手动配置网络拓扑,直观展示故障传播路径。
数据存储与历史分析
- 高性能数据存储
- 时序数据库优化:Zabbix 原生支持高效存储数值型监控数据,支持按时间范围压缩历史数据(如保留 7 天原始数据,30 天聚合数据)。
- 分区表设计:数据库表按时间分区,提升历史数据查询速度。
- 外部存储集成:支持将历史数据导出到外部数据库(如 TimescaleDB)或对象存储(如 S3),降低主库压力。
- 历史数据分析与报表
- 趋势预测:基于历史数据生成趋势图,预测资源使用峰值(如“下周 CPU 负载可能达到 95%”)。
- SLA 报告:统计服务可用性(如“Web 服务 99.9% 可用”),生成合规性报告。
- 自定义报表:通过 SQL 查询或内置报表工具生成业务相关报表(如“按部门统计资源消耗”)。
可视化与用户界面
- 动态仪表盘
- 拖拽式布局:支持自定义仪表盘,组合图表、地图、文本框等组件。
- 实时刷新:图表数据可配置自动刷新间隔(如每 5 秒更新一次)。
- 多屏适配:仪表盘支持响应式设计,适配不同设备屏幕(如 PC、大屏、移动端)。
- 高级图表类型
- 拓扑图:展示主机、服务之间的依赖关系,支持动态状态标记(如绿色表示正常,红色表示故障)。
- 热力图:可视化资源使用率分布(如“按小时统计 CPU 负载热力图”)。
- 3D 图表:展示多维数据(如“按地区、时间统计网络流量”)。
- 用户权限管理
- 基于角色的访问控制(RBAC):定义用户组(如“运维组”“管理员”),分配不同权限(如“只读”“配置修改”)。
- 审计日志:记录所有用户操作(如“用户 A 修改了触发器 B 的阈值”),满足合规性要求。
自动化与扩展性
- 自动发现与配置
- 网络自动发现:通过 ICMP Ping、SNMP 扫描自动识别网络中的主机和服务。
- LLD(Low-Level Discovery):动态生成监控项、触发器(如“自动发现磁盘分区并监控使用率”)。
- API 集成:通过 REST API 与 CMDB、ITSM 系统同步资产信息,实现监控配置自动化。
- 插件与第三方集成
- 社区插件:Zabbix 官方和社区提供大量插件(如监控 Docker、Kafka、Elasticsearch)。
- Webhook 支持:通过 Webhook 将告警信息推送至 Jira、PagerDuty 等外部系统。
- Prometheus 集成:通过 Zabbix-Prometheus 适配器采集 Prometheus 指标,实现混合监控。
- 高可用与分布式架构
- Zabbix Proxy:在分支机构部署代理服务器,集中上报数据至主 Server,减少带宽占用。
- 集群模式:支持多台 Zabbix Server 组成集群,实现负载均衡和故障转移。
- 数据库高可用:集成 MySQL Galera、PostgreSQL 流复制等方案,保障数据可靠性。
安全与合规性
- 数据加密
- 传输加密:支持 HTTPS、SSH 协议加密数据传输。
- 存储加密:可选数据库加密插件(如 MySQL Transparent Data Encryption)保护历史数据。
- 认证与授权
- 多因素认证(MFA):集成 Google Authenticator、DUO 等实现双因素认证。
- 单点登录(SSO):支持 LDAP、SAML 协议与企业身份系统集成。
- 合规性支持
- 审计日志:记录所有配置变更和用户操作,满足 GDPR、ISO 27001 等合规要求。
- 数据保留策略:自定义历史数据保留周期,避免数据泄露风险。
六. Zabbix角色及架构
Zabbix 的角色与架构设计围绕分布式监控需求展开,通过模块化组件和灵活的权限管理实现高效、可扩展的监控解决方案
Zabbix 核心角色
- Zabbix Server
- 功能:作为监控系统的中枢,负责接收、处理和存储所有监控数据,触发告警规则,生成报表,并管理分布式组件(如 Proxy)。
- 关键进程:
- Poller:主动采集 Agent 数据。
- Trapper:接收 Agent 主动推送的数据。
- Alert:处理告警规则并触发通知。
- Notifier:通过邮件、短信等方式发送告警。
- 部署建议:单节点建议监控不超过 5000 台主机,超大规模环境需结合 Proxy 分布式部署。
- Zabbix Proxy
- 功能:可选组件,用于分布式监控场景,替代 Server 收集本地数据并批量转发,减轻 Server 负载。
- 核心特性:
- 本地缓存:断网时暂存数据,网络恢复后自动续传。
- 独立数据库:存储短期数据(如未发送的历史数据),与 Server 数据库分离。
- 部署建议:每个 Proxy 建议监控不超过 5000 个监控项,与 Server 保持稳定网络连接。
- Zabbix Agent
- 功能:轻量级数据采集器,部署在被监控设备上,支持两种模式:
- 被动模式:响应 Server/Proxy 的轮询请求(默认端口 10050/TCP)。
- 主动模式:主动推送数据到 Server/Proxy,适合大规模环境。
- 扩展性:支持自定义监控项(UserParameters)和 SNMP、JMX 等协议。
- 功能:轻量级数据采集器,部署在被监控设备上,支持两种模式:
- Database
- 支持类型:MySQL/MariaDB(最常用)、PostgreSQL、Oracle、IBM DB2。
- 设计特点:
- 分区存储:历史数据按周分区,趋势数据按月分区。
- 定期归档:建议配置脚本自动归档旧数据,避免表膨胀。
- 性能优化:
- 调整 innodb_buffer_pool_size(建议 8GB 以上)。
- 启用 innodb_log_file_size(如 512MB)提升写入性能。
- Web Interface
- 技术栈:基于 PHP+JavaScript 的前端,提供仪表盘、配置管理、报表生成等功能。
- 安全建议:启用 HTTPS 加密访问,配置 API 白名单。
- REST API:支持与第三方系统(如 Jira、钉钉)集成。
Zabbix 架构类型
- 单 Server 架构
- 适用场景:小型环境(<100 台设备)。
- 特点:Server 与数据库同机部署,简单易维护,但性能瓶颈明显。
- 主备 Server 架构
- 适用场景:中型企业(100-1000 台设备)。
- 特点:
- 双 Server 部署(主备),数据库独立并采用主从复制。
- 通过 Keepalived 实现 VIP 漂移,保障高可用。
- 示例配置:
- 上海数据中心:主 Server + Proxy1(IDC1)、Proxy2(IDC2)。
- 北京数据中心:备 Server + Proxy3(IDC3)。
- 多级 Proxy 架构
- 适用场景:超大规模环境(>1000 台设备)。
- 特点:
- 区域 Proxy:按地理分布部署(如北京 Proxy、上海 Proxy)。
- 业务 Proxy:按业务系统划分(如 ERP Proxy、CRM Proxy),实现故障隔离。
- 网络隔离 Proxy:跨越防火墙部署(DMZ Proxy、内网 Proxy),通过 Proxy 中转数据。
权限管理:用户、组与角色
- 用户(User)
- 属性:别名、密码、语言、时区等。
- 权限继承:通过用户组分配权限,无法直接修改自身角色。
- 用户组(User Group)
- 功能:组织用户并分配主机组权限。
- 权限级别:
- Read-write:读写访问。
- Read-only:只读访问。
- Deny:拒绝访问。
- 标签过滤器:基于标签(如业务部门、环境)过滤问题集。
- 角色(Role)
- 定义:权限集合,简化权限管理。
- 预定义角色:
- Admin:管理用户和配置,但无超级权限。
- Super Admin:完全控制权。
- Guest:只读访问部分数据。
- 自定义角色:通过“管理”→“用户角色”创建,支持细粒度权限控制(如限制 API 访问)。
七. 部署zabbix
资源清单
操作系统 | 主机名 | IP | 角色 |
OpenEuler | zabbix | 192.168.10.107 | zbbix服务端 |
OpenEuler | proxy | 192.168.10.106 | zabbix proxy |
OpenEuler | server01 | 192.168.10.101 | 被监控节点 |
OpenEuler | server01 | 192.168.10.102 | 被监控节点 |
基础环境
关闭防火墙和SELinux
修改主机名
1. 部署zabbix源
添加zabbix源
安装软件包
备注:
- zabbix6.4.8 需要的各个平台软件的版本:
- mysql的版本要求8.0.30-8.1.X
- mariadb 的版本要求10.5.60-11.1.X
- nginx 的版本要求1.20 or later
- php 的版本要求7.4.0-8.2.X
配置数据库
导入数据
没有报错误信息就是导入成功
配置zabbix server
修改/etc/zabbix/zabbix_server.conf文件129行去掉注释
配置zabbix页面
修改/etc/nginx/conf.d/zabbix.conf文件 去掉注释
启动服务
2. zabbix页面配置
登录zabbix
http://192.168.10.107:8080
3. 解决图像字体显示问题
4. 配置被监控端Agent
添加zabbix源和安装软件包
配置agent
修改/etc/zabbix/zabbix_agentd.conf文件 分别是117行、171行、182行
启动服务
添加主机
数据采集--》主机--》创建主机
直接添加主机
- 主机名称:和 Agent 服务配置文件中的 Hostname 保持一致
- 模板:有很多自带的模板,也可以自己创建
- 主机群组:可以选择已有的,也可以自己创建一个群组
- 接口:添加 Agent 节点,IP 地址填写被监控节点的IP
第二个别监控主机一样的操作
注意配置文件里面的名称
5. 部署proxy
添加zabbix源
安装软件包
导入数据(在zabbix server节点执行)
(proxy节点执行)
IP地址修改为zabbix server的ip
zabbix server节点执行
配置zabbix proxy
修改/etc/zabbix/zabbix_proxy.conf文件
- 大约 32 行左右,修改为 zabbix server 节点的 IP
- Server=192.168.10.107
- 大约 42 行左右,可以修改,这里不做修改,后续 web 页面添加时名字要和这里保持一致
- Hostname=Zabbix proxy
- 大约 157 行左右,取消注释修改为 zabbix server 节点的 IP
- DBHost=192.168.10.107
- 大约 194 行左右,取消注释为数据库的密码
- DBPassword=zabbix
启动服务
web页面添加proxy
管理--》proxy--》创建agent代理
勾选点应用
修改server01或server02的地址指向proxy重启
可以看到proxy有东西了而且可用性是绿色就成功了