成熟企业级开源监控解决方案Zabbix6.2关键功能实战-上
@
概述
定义
Zabbix 官网文档 //www.zabbix.com/documentation
Zabbix GitHub源码地址 //github.com/zabbix
Zabbix 是一个企业级的开源分布式监控、高度集成的网络监控解决方案。最新版本为6.2.4,官方文档支持很多种语言,最新中文文档支持到6.0版本。
Zabbix 诞生于1998年,核心组件采用C语言开发,Web端采用PHP开发。属于老牌监控系统中的优秀代表,监控功能很全面,使用也很广泛。是一款具备监控网络的众多参数,可以监控网络、物理服务器、虚拟机、应用程序、服务、数据库、网站、云等。
监控作用
- 实时采集监控数据:包括硬件、操作系统、中间件、应用程序等各个维度的数据。
- 实时反馈监控状态:通过对采集的数据进行多维度统计和可视化展示,能实时体现监控对象的状态是正常还是异常。
- 预知故障和告警:能够提前预知故障风险,并及时发出告警信息。
- 辅助定位故障:提供故障发生时的各项指标数据,辅助故障分析和定位。
- 辅助性能调优:为性能调优提供数据支持,比如慢SQL,接口响应时间等。
- 辅助容量规划:为服务器、中间件以及应用集群的容量规划提供数据支撑。
- 辅助自动化运维:为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。
使用理解
- 了解监控对象的工作原理:要做到对监控对象有基本的了解,清楚它的工作原理。比如想对JVM进行监控,你必须清楚JVM的堆内存结构和垃圾回收机制。
- 确定监控对象的指标:清楚使用哪些指标来刻画监控对象的状态?比如想对某个接口进行监控,可以采用请求量、耗时、超时量、异常量等指标来衡量。
- 定义合理的报警阈值和等级:达到什么阈值需要告警?对应的故障等级是多少?不需要处理的告警不是好告警,可见定义合理的阈值有多重要,否则只会降低运维效率或者让监控系统失去它的作用。
- 建立完善的故障处理流程:收到故障告警后,一定要有相应的处理流程和oncall机制,让故障及时被跟进处理。
监控对象和指标
运维关注硬件和基础监控,研发关注各类中间件和应用层的监控,产品关注核心业务指标的监控。
-
硬件监控:电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态。
-
服务器基础监控
- CPU:单个CPU以及整体的使用情况
- 内存:已用内存、可用内存
- 磁盘:磁盘使用率、磁盘读写的吞吐量
- 网络:出口流量、入口流量、TCP连接状态
-
数据库监控:数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询。
-
中间件监控
- Nginx:活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
- Tomcat:最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
- 缓存(Redis) :成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
- 消息队列(Kafka):连接数、队列数、生产速率、消费速率、消息堆积量
-
应用监控
- HTTP接口:URL存活、请求量、耗时、异常量
- RPC接口:请求量、耗时、超时量、拒绝量
- JVM :GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
- 线程池:活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
- 连接池:总连接数、活跃连接数
- 日志监控:访问日志、错误日志
- 业务指标:视业务来定,比如PV、订单量等
架构组成
- Zabbix server:核心组件, Zabbix 软件的中央进程,执行监控、与 Zabbix proxy 和 agent 交互,负责接收Agent、Proxy的监控数据,也支持JMX、SNMP等多种协议直接采集数据;负责数据的汇总存储以及告警触发等。
- 数据库:Zabbix 收集的所有配置信息以及数据都存储在数据库中,支持MySQL、Oracle等关系型数据库,逐步支持时序数据库。
- 前端:Zabbix的Web的 界面,提供基于 Web 可视化监控配置、展现、告警。
- Zabbix proxy:可以代替 Zabbix server 收集性能监控项数据,可选,对于被监控机器较多的情况下,可使用Proxy进行分布式监控以减轻Server的压力。
- Zabbix agent :部署在被监控目标上,以主动监控本地资源和应用程序的进程(硬盘、内存、处理器统计信息等),采集本机的数据并发送给Proxy或者Server,数据收集方式同时支持主动Push和被动Pull 两种模式。从 Zabbix 4.4 开始,有两种类型的 agent 可用:Zabbix agent(轻量级,在许多平台上支持,用 C 编写)和 Zabbix agent 2(非常灵活,易于使用插件扩展,用 Go 编写)。
- 被动模式:agent 应答数据请求。Zabbix server(或 proxy)询求数据,例如 CPU load,然后 Zabbix agent 返还结果。
- 主动模式:处理过程将相对复杂,Agent 必须首先从 Zabbix sever 索取监控项列表以进行独立处理,然后会定期发送采集到的新值给 Zabbix server。
- Zabbix API:使用 JSON RPC 协议来创建、更新和获取 Zabbix 对象(如主机、监控项、图表等)或执行任何其他自定义任务。
- Zabbix Java gateway :获取主机的JMX 计数器的值,Zabbix server向Zabbix Java gateway发送请求,使用 JMX 管理 API 来远程查询相关的应用。
- Zabbix sender:用来推送性能数据给 Zabbix Server 处理的命令行应用程序;通常用在定期推送可用性和性能数据等在长耗时的用户脚本上。
- Zabbix get :命令行应用,它可以用于与 Zabbix agent 进行通信,并从 Zabbix agent 那里获取所需的信息;通常被用于 Zabbix agent 故障排错。
常用监控软件分析
前面我们学习过Prometheus,这里结合Zabbix、Open-falcon做下简单的优劣势分析
-
Zabbix
- 优势
- 产品成熟:拥有丰富的文档资料(包括中文文档)以及各种开源的数据采集插件,能覆盖绝大部分监控场景。
- 采集方式丰富:支持Agent、SNMP、JMX、SSH等多种采集方式,支持主动和被动的数据传输方式。
- 较强的扩展性:支持Proxy分布式监控,有agent自动发现功能,插件式架构支持用户自定义数据采集脚本。
- 配置管理方便:能通过Web界面进行监控和告警配置,操作方便,上手简单。
- 劣势
- 性能瓶颈:机器量或者业务量大了后,关系型数据库的写入一定是瓶颈。
- 应用层监控支持有限:如果想对应用程序做侵入式的埋点和采集(比如监控线程池或者接口性能),zabbix没有提供对应的sdk,需要通过插件式的脚本编写实现较为麻烦。
- 数据模型不强大:不支持tag,没法按多维度进行聚合统计和告警配置,不灵活。
- 方便二次开发难度大:Zabbix采用的是C语言,二次开发成本较高。
- 优势
-
Open-falcon:是小米2015年开源的企业级监控工具,采用Go和Python语言开发,这是一款灵活、高性能且易扩展的新一代监控方案,目前小米、美团、滴滴等超过200家公司在使用。核心优势在于数据分片功能,能支撑更多的机器和监控项。
- 优势
- 自动采集能力:无需做任何配置Falcon-agent 就能自动采集服务器的200多个基础指标(比如CPU、内存等)。
- 强大的存储能力:底层采用RRDTool,并且通过一致性hash进行数据分片,构建了一个分布式的时序数据存储系统,可扩展性强。
- 灵活的数据模型:借鉴OpenTSDB,数据模型中引入了tag,这样能支持多维度的聚合统计以及告警规则设置,大大提高了使用效率。
- 插件统一管理:Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理,可通过HeartBeat Server分发给agent,减轻了使用者自主维护脚本的成本。
- 个性化监控支持:基于Proxy-gateway,很容易通过自主埋点实现应用层的监控(比如监控接口的访问量和耗时)和其他个性化监控需求,集成方便。
- 劣势
- 整体发展一般:社区活跃度不算高,版本更新慢,支持粒度较弱。
- 安装比较复杂:组件较多,如果对整个架构不熟悉,安装很难一蹴而就。
- 优势
-
Prometheus:有Google和k8s加持,是容器监控方面的标配和主流方案。
- 优势
- 轻量管理:架构简单,不依赖外部存储,单个服务器节点可直接工作,二进制文件启动即可,属于轻量级的Server,便于迁移和维护。
- 较强的处理能力:监控数据直接存储在Prometheus Server本地的时序数据库中,单个实例可以处理数百万的metrics。
- 灵活的数据模型:同Open-Falcon,引入了tag,属于多维数据模型,聚合统计更方便。
- 强大的查询语句:PromQL允许在同一个查询语句中,对多个metrics进行加法、连接和取分位值等操作。
- 很好地支持云环境:能自动发现容器,同时k8s和etcd等项目都提供了对Prometheus的原生支持,是目前容器监控最流行的方案。
- 劣势
- 功能不够完善:Prometheus从一开始的架构设计就是要做到简单,不提供集群化方案,长期的持久化存储和用户管理,而这些是企业变大后所必须的特性,目前要做到这些只能在Prometheus之上进行扩展。
- 网络规划变复杂:由于Prometheus采用的是Pull模型拉取数据,意味着所有被监控的endpoint必须是可达的,需要合理规划网络的安全配置。
- 优势
版本选型
LTS稳定版本每一年半发布一次,对于所有稳定版本,五年的服务与支持。目前Zabbix版本支持期限列表如下,建议企业选型使用时选择LTS版本如6.0
Zabbix LTS 特点:
- 支持期限更长,例如:为潜在的安全问题及bug迭代更新
- 令人期待的高质量更新以及全新的功能点
- 快速更新,可适用于多变的复杂环境
- 在版本升级方面,更容易规划管理
俗语
- host(主机):要通过 IP/DNS 监控的联网设备。
- host group(主机组):主机的逻辑分组;可能包含主机和模板。主机组中的主机和模板没有以任何方式相互链接。在为不同用户组分配主机访问权限时使用主机组。
- item(监控项):你想要接收的主机的特定数据,一个度量/指标数据。
- value preprocessing(值预处理):在数据存入数据库之前 转化/预处理接收到的指标数据。
- trigger(触发器):一个被用于定义问题阈值和 “评估” 控项接收到的数据的逻辑表达式。 当接收到的数据高于阈值时,触发器从 ‘Ok’ 变成 ‘Problem’ 状态。当接收到的数据低于阈值时,触发器保留/返回 ‘Ok’ 的状态。
- event(事件):一次发生的需要注意的事情,例如 触发器状态改变、自动发现/agent 自动注册。
- event tag(事件标签):预设的事件标记 可以被用于事件关联,权限细化设置等。
- event correlation(事件关联):一种灵活而精确地将问题与其解决方法联系起来的方法 比如说,你可以定义触发器A告警的异常可以由触发器B解决,触发器B可能采用完全不同的数据采集方式。
- problem(问题): 一个处在 “问题” 状态的触发器。
- problem update(问题更新):Zabbix 提供的问题管理选项,例如添加评论、确认、更改严重性或手动关闭。
- action(动作):对事件作出反应的预先定义的方法。 一个动作由多个操作(例如发送通知))和条件(什么情况下 执行操作)组成。
- escalation(升级): 用于在动作中执行操作的自定义场景;发送通知/执行远程命令的序列。
- media(媒体): 发送告警通知的渠道;传输媒介。
- notification(通知):通过选定的媒体通道发送给用户的关于某个事件的消息。
- remote command(远程命令) :在某些条件下在受监控主机上自动执行的预定义命令。
- template(模板):可以应用于一个或多个主机的一组实体集 (包含监控项、触发器、图表、低级别自动发现规则、web场景等)。 模版的应用使得主机上的监控任务部署快捷方便;也可以使监控任务的批量修改更加简单。模版是直接关联到每台单独的主机上。
- web scenario(web 场景): 检查一个网站的可用性的一个或多个HTTP请求。
安装
部署方式
Zabbix支持多种安装方式,可单项安装也可以混合安装,包括如下:
- 二进制安装;
- 源代码安装;
- 容器安装;
- Web界面安装。
部署
# 下载docker项目
wget //github.com/zabbix/zabbix-docker/archive/refs/tags/6.2.4.tar.gz
# 解压
tar -xvf 6.2.4.tar.gz
# 进入目录
cd zabbix-docker-6.2.4
# 通过docker-compose一键安装启动,由于本机端口冲突,修改zabbix-web-nginx-mysql的端口为180和1443
docker-compose -f docker-compose_v3_centos_mysql_latest.yaml up -d
# 查看容器
docker-compose -f docker-compose_v3_centos_mysql_latest.yaml ps
访问Zabbix的Web页面 //192.168.50.95:180/,输入用户名 Admin 以及密码 zabbix ,进入全局视图页面。
配置为中文,通过用户设置,选择语言为中文,点击更新后就为中文版。
zabbix-agent
# 模拟启动zabbix-agent1为Zabbix server的
docker run --name zabbix-agent1 -e ZBX_HOSTNAME="Zabbix server" --network zabbix-docker-624_zbx_net_backend -e ZBX_SERVER_HOST="zabbix-docker-624_zabbix-server_1" -d zabbix/zabbix-agent:latest
# 进入zabbix-docker-624_zabbix-server_1的容器
docker exec -it zabbix-docker-624_zabbix-server_1 /bin/bash
# 执行测试命令,可以获取到监控项的值
zabbix_get -s zabbix-agent1 -p 10050 -k "system.cpu.load[all,avg1]"
在Zabbix的Web页面中的配置-主机中,可以看到默认监控zabbix-server的主机信息,修改zabbix-agent1的容器名称
等待一小段时间后可用性列就变为绿色也即是可用状态
在Zabbix的Web页面中监测-主机,然后再列表中Zabbix server点击最新数据,可以查到当前主机的监控项最新数据了,当然也可以直接点击最新数据页面输入搜索条件查询,至此完成了一个简单入门示例。
**本人博客网站 **IT小神 www.itxiaoshen.com