分布式监控

ZYC·2024-01-14 01:12·48 次阅读

分布式监控

一个完整的项目:

业务架构:客户端 --> 防火墙 --> 负载均衡 (四层,七层) --> Web缓存/应用 --> 业务逻辑(动态应用) --> 数据缓存 --> 数据持久

运维架构:运维客户端 --> 堡垒机/跳板机 (jump server /VNC) --> 监控相同 、日志系统 、存储系统、自动化运维平台 、持续集成持续部署平台(CI/CD)

 

Zabbinx#

介绍#

●zabbix 是一个基于 Web 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。
●zabbix 能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
●zabbix 由 2 部分构成,zabbix server 与可选组件 zabbix agent。通过 C/S 模式采集数据,通过 B/S 模式在 Web 端展示和配置。
●zabbix server 可以通过 zabbix agent,SNMP协议,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在 Linux 等平台上。
●zabbix agent 需要安装在被监视的目标服务器上,它主要完成对硬件信息或与操作系统有关的内存,CPU 等信息的收集。

 

zabbix 监控原理#

zabbix agent 安装在被监控的主机上,zabbix agent 负责定期收集客户端本地各项数据,并发送至 zabbix server 端,zabbix server 收到数据后, 将数据存储到数据库中,用户基于 Zabbix Web 可以看到数据在前端展现图像。当 zabbix 监控某个具体的项目, 该项目会设置一个触发器阈值, 当被监控的指标超过该触发器设定的阈值,会进行一些必要的动作,动作包括:发送信息(邮件、微信、短信)、发送命令(shell 命令、reboot、restart、 install 等)。

 

 

zabbix 官网

https://www.zabbix.com/cn

Zabbix 6.0 新特性#

复制代码
1、Zabbix server高可用防止硬件故障或计划维护期的停机:
•原生选择加入HA群集配置
•定义一个或多个备用节点
•实时监控Zabbix server群集节点的状态
•不需要外部工具即可将Zabbix server配置为HA群集模式

2、Zabbix 6.0 LTS新增Kubernetes监控功能,可以在Kubernetes系统从多个维度采集指标:
•Kubernetes节点和pods的自动发现和监控
•无代理方式采集Kubernetes pods和节点的信息
•获取Kubernetes节点主机高水平信息
复制代码

 

Zabbix 6.0 功能组件#

复制代码
# Zabbix Server
zabbix 服务端守护进程,是 Zabbix 软件的核心组件,Zabbix Agent 向其报告可用性、系统完整性信息和统计信息。
Zabbix Server 也是存储所有配置信息、统计信息和操作信息的核心存储库。
Zabbix Server 也是 Zabbix 监控系统的告警中心。在监控的系统中出现任何异常,将发出通知给管理员。

基本的 Zabbix Server 的功能分解成为三个不同的组件。他们是:Zabbix server、Web 前端、数据库。

Zabbix 的所有配置信息都存储在 Server 和 Web 前端进行交互的数据库中。例如,当你通过 Web 前端(或者API)新增一个监控项时, 它会被添加到数据库的监控项表里。然后,Zabbix server 以每分钟一次的频率查询监控项表中的有效项,接着将它存储在 Zabbix server 中的缓存里。 这就是为什么 Zabbix 前端所做的任何更改需要花费两分钟左右才能显示在最新的数据段的原因。

# 数据库
所有配置信息以及 Zabbix 采集到的数据都被持久存储在数据库中。
可以支持 MySQL、PostgreSQL、Oracle、DB2、TimescaleDB 等多种数据库。

# Web 界面
Web 界面是 Zabbix Server 的一部分,用于实现展示和配置的界面。通常(但不一定)和 Zabbix server 运行在同一台物理机器上。
基于 Apache/Nginx + PHP 实现,早期只支持 LAMP 架构,从 Zabbix5.0 开始支持 LNMP 。

# Zabbix Agent
客户端守护进程,部署在被监控目标上,用于主动监控本地资源和应用程序,并将收集的数据发送给 Zabbix Server。从 Zabbix5.0 开始支技 Zabbix Agent2 。

# Zabbix Proxy
zabbix 分布式代理守护进程,可以代替 Zabbix Server 采集性能和可用性数据。Zabbix Proxy 在 Zabbix 的部署是可选部分。
Zabbix Proxy 的部署可以很好的分担单个 Zabbix Server 的负载。
通常监控大于 500 台主机时使用,需要进行分布式监控架构部署。

# Java Gateway
Zabbix 要监控 Tomcat 服务或其它 JAVA 程序(比例 Elasticsearch、ZooKeeper),需要使用 Java Gateway 做为代理,才能从 JAVA 程序中获取数据。
复制代码

 

 

 

 

 #搭建nginx  yum

 

 #yum安装nginx

 #安装epe源

 #安装php

 #修改nginx配置

复制代码
server {
  listen 80;
  server_name zbx.kgc.com;
  root /var/www/zbx;
  
  location / {
    index index.php;
  }
  
  location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /var/www/zbx$fastcgi_script_name;
    include fastcgi_params;
  }
}
复制代码

 

 

 #修改php配置

 #改为nginx

 

 #设置最大执行时间为300秒

 #设置最大输出时间600秒

 #设置Post Max尺寸 80M

 #设置默认时区,为亚洲上海

 #在var/www下创建zbx文件夹

 #创建测试环境

 #开启nginx和php服务

 

 

 # C盘中 :\Windows\System32\drivers\etc\hosts添加测试访问

 

 #浏览器访问

 

 

 #配置数据库

 #安装数据库

 #启动数据库

 

 

 #新密码

 

 

 #登录数据库

 #创建数据库并指定字符集

 #创建 zabbix 数据库用户并授权

 

 #去官网下载zabbix 6.0.25

 #将下载下来的安装包解压

 

 #用for循环按顺序将这五个导入到数据库中

 #登录数据库查看下有无导入成功

 #编译安装 zabbix Server 服务端

安装依赖包,创建 zabbix 用户

 #创建zabbix用户

 

 #在etc下创建个zabbix

 

 

复制代码
./configure \
--sysconfdir=/etc/zabbix/ \
--enable-server \
--with-mysql \
--with-net-snmp \
--with-libxml2 \
--with-ssh2 \
--with-openipmi \
--with-zlib \
--with-libpthread \
--with-libevent \
--with-openssl \
--with-ldap \
--with-libcurl \
--with-libpcre
复制代码

 #安装

 

#修改配置文件

 

 

 #准备sytemctl服务管理文件

 #将zabbix日志文件的属主,改为zabbix。不然日志文件的权限会被拒绝

 #重新加载systemctl服务,启动zabbix服务

 #zabbix_server 默认监听 10051 端口

 

 #部署web前端进行访问

 #浏览器访问

 

 

 

 

 

 #输入账户密码 admin要开头a要大写!密码zabbix

 

 #去官网下载  客户端主机

 

 

 

 #开启zabbix-agent2 

 #agent2默认端口是10050

 #问题的严重性消失

 

 #点击打开,图形界面

 

 

 

 #乱码以解决

 #添加zabbix客户端

 #主服务端和客户端都做时间同步

 #服务端和客户端都设置hosts解析

客户端也去官网安装agent2

 

 

 #指定zabbix服务端的IP地址

 #指定zabbix服务端的IP地址

 #指定当前zabbix客户端的主机名

 #开启zabbix-agent2

 

 #去服务端安装zabbix 主动获取数据的命令

 

 

 #当前系统能够支持的键

 #服务端与客户端是否连通,返回1表示可达,返回非表示不可达

 #客户端主机名

#常用的键值
agent.ping                                              #服务端与客户端是否连通,返回1表示可达,返回非表示不可达
system.hostname                                         #系统主机名
agent.hostname                                          #客户端主机名
net.if.in[if,<mode>]                                    #网络接口进入的流量统计,if表示网卡名称,带<>的参数表示可以省略
net.if.out[if,<mode>]                                   #网络接口流出的流量统计
proc.num[<name>,<user>,<state>,<cmdline>,<zone>]        #进程数
net.tcp.port[<ip>,port]                                 #检查是否能建立tcp连接到指定端口,返回0表示不能连接,返回1表示可以连接

 

 

#创建主机完成

 

 

模板

#监控模板下载地址
https://share.zabbix.com/
https://monitoringartist.github.io/zabbix-searcher/
https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates

 

自定义监控内容#

案列:自定义监控客户端服务器登录的人数
需求:限制登录人数不超过 3 个,超过 3 个就发出报警信息

 #客户端,查看有多少登录

 #可以将自定义的监控项配置文件创建在 zabbix_agent2.d 目录中

 #自定义监控格式

 #编写键的配置

 #重起

 #去服务端验证新建的监控项

 #杀掉其中一个登录项

 #服务端验证下

 

 

 #搜索

 

 #测试下

 

 #根据严重程度可自定义设置

 

#last最新值  进行比较

 

 

 

 

 

 #主机与模板关联起来(一个主机可以关联多个模板

 

 

 

 

 

 

 #监测指标上升了

 #再开个

 #超值了

 

 #关掉两个

 #仪表盘恢复正常

设置邮件报警#

 

密码】可登录QQ邮箱页面,点击【设置】-->【账户】中的【生成授权码】,通过短信获取授权码

 #已经有qq_email

 #测试下

 

 #邮箱收到测试信息

 

 

 

 

 

 

 

 

 

 

 

 

 

 #添加

 

 

开始测试#

 #来到监测页面,开始测试

 #开个服务

 #监测到达3

 #再开个服务

 #监控到达4

 #报警邮箱以发送

 #收到报警邮箱

 

总结#

复制代码
Zabbix 组件
zabbinx server (端口 10051) #zabbix服务端进程,用于配置和管理zabbix用于程序,也是监控系统的告警中心(需要配置监控项告警触发阈值和发送告警)
zabbix database #持久化存储信息和监控指标信息(支持MySQL oracle postgresql tsdb等)
zabbix web #用于做zabbix服务端配置界面和监控数据的UI界面展示(支持apache/nginx+php)LAMP/LNMP

zabbix agent (端口 10050)#部署在被监控的主机上,采集监控指标数据,并发送给zabbix server (数据采集支持主动模式和被动模式) 主动模式(zabbix 会主动向 zabbix server请求监控列表,并主动将监控的数据发送给zabbix server) ,被动模式(zabbix agent 主动被动接受 zabbix server 请求的监控项列表,zabbix agent 发送监控项需要的数据发送给 zabbix server)
zabbix proxy #zabbix 代理端进程,部署在zabbix server 与zabbix agent 之间,代替zabbix server 接受zabbix agent发送的监控数据并存储在本地,汇总后再转发给zabbix server,从而可以分担zabbix server 的集中式负载压力
zabbix java gateway #用于获取通过JMX从java应用暴露的端口采集的监控数据

#zabbix 工作原理
zabbix agent 会定期采集被监控主机的指标数据并发送给zabbix server,zabbix server接受数据后会存储到zabbix database中,管理员可基于zabbbix web 即可在浏览器查到监控数据的图像





#如何自定义监控模板
1) 先明确获取监控监控指标数据的命令或脚本
2) 在被监控主机配置文件目录中(/etc/zabbix/zabbix_agent2
.d/)创建以.conf为后缀的监控项配置文件,在文件里自定义监控指标数据的键值 。 键值格式 :Userparameter <键值名>,<获取值的命令>/<脚本路径>
3)在zabbix服务端web管理页面中依次添加 模板那 - 监控项 - 触发器 - 图形
4)将监控模板与被监控的主机进行关联

#配置邮件报警
1)在zabbix服务端web管理页面[管理] -[报警媒介类型] 中设置媒介类型和内容模板
2)在 [User settings] - [profile] - [报警媒介] 中设置类型  收件人  当启用时间  和严重级别
3)在[配置] - [动作] -[trigger actions]中创建动作,设置动作条件和操作内容
4)测试
复制代码

 

 

Zabbix 和 Prometheus#

Zabbix 和 Prometheus 的优缺点#

 

Zabbix 优点#

复制代码
1、监控模版可以包含多个指标,在不涉及自定义采集脚本等其他方式的情况下,使用SNMP、Zabbix Agent 的情况下可以做到开箱即用;

2、指标和触发器(Zabbix的告警规则叫触发器)的关联交互挺好用;

3、宏和宏变量的使用可以大大的提高告警的便捷性,基本可以做到每个label 不同的阈值;

4、Zabbix 的指标采集挺丰富的,包括采集间隔,是否要一直采集还是每天固定时间段来采集;

5、Zabbix 的管理页面,这个不愧是企业级软件,Zabbix 很大一部分的优势是靠它来体现的。
复制代码

 

zabbix缺点#

复制代码
1、Zabbix 架构原生是单点,没有集群方案,官方推荐的是使用keepalived 来进行3个点的负载均衡,这个方案在现在来说还是有很大的优化空间的。

2、Zabbix 的数据存储使用关系型数据库,在 Zabbix 刚发布的时候,这个没的选择,但放在现在这是个很大的问题,当指标数量增加以后,数据的存储空间、查询时间都变成了一个恐怖的事情。当前使用了6TiB的空间来存储了每帧80万条数据,采集间隔一分钟,详细数据1个月,历史数据大概1年半的数据,Prometheus 存储比这个节省多了。当然zabbix 也可以支持更大的数据收集规模,只是不知道资源会按什么比例增长。

3、升级复杂,体验了4.4.0升级到4.4.10以后,升级太麻烦,使用Zabbix 你的团队最好配置一个DBA 来处理各种问题。

4、Zabbix 和 Grafana 的结合不太好,语句写起来挺生硬的,也能用,但是不如Prometheus 灵活。

对于prometheus 这个月我也做了例行升级,大概花了一个小时左右,我升级完了十多个实例,配套的Thanos 和存储数据的Minio。和Zabbix 相比,这太让人舒服了。
复制代码

 

Prometheus 的优点#

1、结构简单,但是可以水平扩展,通过和thanos 结合可以做到无缝的水平扩展。不喜欢thanos 也可以使用自带的联邦功能进行扩展,Prometheus 的思想就是:我尽量简单但是好用,剩下的功能尽管放给其他人做

2、采用时序数据库,大大的节省了存储空间,并且提升了查询效率。我使用3TiB 的空间存储了每帧300万条数据,30秒采集一次,大约有120万条数据是15秒采集一次,详细数据存2个月,5分钟降准数据存半年,一小时降准数据存一年,而且我还不需要DBA 参与。

3、采集配置简单,简单配置以后就可以收取丰富的指标,不用自己一个指标一个指标的添加。

4、原生支持收集很多服务暴露的监控数据,Zabbix 很难收集应用自身提供的监控数据

 

Prometheus 的缺点#

当前告警规则无法快捷的支持每个label 一个阈值,要么统一阈值,要么一个label 一条规则,量大了以后真的不好管理。大家如果这方面有什么好的办法还请指导我一下。

其他感觉和zabbix 比起来没啥缺点了。

另外有一个不同点就是,当采集内容较多的时候会出现一个机器上有多个 Agent 的问题。对于这个方面来说,Zabbix 只有一个 Agent ,但是很多内容需要自己编写采集脚本,Agent 还是比自己编写脚本的可靠性更高一些。另外对于单节点多 Agent 来说,Prometheus 也有对应的解决方案。

 

Zabbix 和 Prometheus 的适用场景#

复制代码
在使用Zabbix 和 Prometheus 的过程中,曾经将 Zabbix 和 Prometheus 放在各种场景下进行过使用,比如单个集群、多个集群、超级集群、企业业务环境等等场景。

我们先来看看集群环境。

对于单个中小规模的集群(500或者 1000 节点以下)来说,使用Zabbix 和 Prometheus 没有什么差别,无论使用哪种工具,做好规划和设计,使用起来基本没有问题,单机的资源使用、数据库的压力、场景的复杂度,都不是太大的问题。随便使用就好。

对于多集群来说,我们需要考虑 Master 节点的资源使用情况、数据库的压力承载情况、集群扩展的方便性。对于 Zabbix 来说,当节点数量直线上升的时候,Master 的压力会一直增大,对于单点 Master 的配置要求越来越大,当数量达到一定规模以后,单点就无法支撑这个规模的系统,然而官方也没有提出很好的集群方案。另外当节点规模增大以后,数据库的压力会变大,监控数据的查询会变的很慢,数据库会变成一个集群来解决遇到的问题,硬件资源的成本会直线上升。对于集群扩展来说,Zabbix 可以基于自动注册和 Proxy 来实现,但是数据是采取 Agent 到 Server Push 回来的,当你想要摘除一个被监控集群的时候操作很繁琐。

对于Prometheus 来说,在多集群的时候,可以每个集群使用一个 Prometheus ,通过 Thanos 来进行汇总,水平扩展特别方便,也不会有单点压力很大的情况,而且可以通过 Label 来区分不同的集群,单点Server 承载节点的能力比Zabbix 强很多。而且 Prometheus 使用时序数据库来存储监控数据,可以用很少的硬件资源提供更强的查询能力。Prometheus 使用 从 Server 到 Agent 拉取的方式获取数据,可以在 Server 端很轻易的操作采集那些节点,放弃某些节点的采集。

对于单集群超过 5000 节点的超级集群,建议直接使用 Prometheus ,可以不用 Zabbix 了,性能差太多。在不考虑冗余的情况下,Prometheus 单点就可以支持 5000 节点存储 1 个月的监控数据,Zabbix 使用同配置的机器至少要 3~4 台机器才能实现相同的效果。而且 Prometheus 相较 Zabbix 维护简单,使用方便。

对于企业的业务环境来说,超过 2000 台节点、业务服务数量大于 1000 个的时候建议直接上 Prometheus 。这个时候是需要一个完整的监控观测系统,需要和 Grafana、Kafka、Redis、MySQL等等中间件和各种系统进行结合、直接获取服务自身暴露的监控指标,在这种场景下,Prometheus 是最适合的。Zabbix 和其他中间件的结合较差,完全依赖自定义脚本来实现,没有依托社区的力量。
复制代码

 

 

 

 

 

posted @   citywalk  阅读(48)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示
目录