成熟企业级开源监控解决方案Zabbix6.2关键功能实战-上

@

概述

定义

Zabbix 官网地址 //www.zabbix.com/

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、订单量等

架构组成

image-20221104173832253

  • 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

image-20221104142015998

Zabbix LTS 特点:

  • 支持期限更长,例如:为潜在的安全问题及bug迭代更新
  • 令人期待的高质量更新以及全新的功能点
  • 快速更新,可适用于多变的复杂环境
  • 在版本升级方面,更容易规划管理

image-20221104142146108

俗语

  • 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

image-20221105124444026

访问Zabbix的Web页面 //192.168.50.95:180/,输入用户名 Admin 以及密码 zabbix ,进入全局视图页面。

image-20221105124753817

配置为中文,通过用户设置,选择语言为中文,点击更新后就为中文版。

image-20221105125242150

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]"

image-20221105145439628

在Zabbix的Web页面中的配置-主机中,可以看到默认监控zabbix-server的主机信息,修改zabbix-agent1的容器名称

image-20221105145829798

等待一小段时间后可用性列就变为绿色也即是可用状态

image-20221105150052504

在Zabbix的Web页面中监测-主机,然后再列表中Zabbix server点击最新数据,可以查到当前主机的监控项最新数据了,当然也可以直接点击最新数据页面输入搜索条件查询,至此完成了一个简单入门示例。

image-20221105150438987

**本人博客网站 **IT小神 www.itxiaoshen.com

Tags: