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

@

目录

概述

定义

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

Zabbix 官网文档 https://www.zabbix.com/documentation

Zabbix GitHub源码地址 https://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 https://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页面 http://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

posted @ 2022-11-05 22:10  itxiaoshen  阅读(901)  评论(0)  编辑  收藏  举报