
- 外文名
- monitor and control
- 第一代
- 传统模拟闭路视监控系统(CCTV)
- 发 展
- 三代
- 中文名
- 监控
- 质量问题
- 解码器、云台、传输部件等设备
- 组 成
- 前端部分、传输部分、控制部分
-
2022-04-15 14:31:13
目录
概述
监控系统一般特指对数据中心的监控,主要针对数据中心内的硬件和软件进行监控和告警。企业的IT架构逐步从传统的物理服务器,迁移到以虚拟机为主导的 IaaS 云,抑或当前流行的容器云PaaS 平台。无论基础架构如何调整,都离不开监控系统的支撑。
不仅如此,越来越复制的数据中心环境,对监控系统提出了越来越高的要求:需要监控不同的对象,例如容器、分布式存储、SDN网络、分布式系统、各种应用程序等,种类繁多;还需要采集和存储大量的监控数据,例如每天数TB数据的采集汇总,以及基于这些监控数据的智能分析、告警及预警等。
监控系统处理能提供实时监控和告警,还能辅助决策,所有决策都以数据为支撑,而非主观臆断。在大数据时代,数据变得越来越重要,监控数据不仅能提供实时状态展现,更能帮助故障回溯和预测风险等。当我们充分了解当前数据中心的真实资源使用情况时,才能绝对是否需要迁移服务、重新调度资源、清理垃圾数据及采购新的服务器。在故障发生后,通过分析历史监控数据,可以准确定位故障源,确定故障的发生时间及持续时间等,从而避免后续相关故障的发生。
从监控对象的角度来看,可以将监控分为网络监控、存储监控、服务器监控和应用监控等。因为需要监控数据中心的各个方面,所以监控系统需要做到面面俱到,在数据中心充当 “天眼” 角色。
从程序设计的角度来看,可以将监控分为基础资源监控、中间件监控、应用程序监控和日志监控。
基础资源监控
从监控对象的角度来看,可以将基础监控分为网络监控、存储监控和服务器监控。
网络监控
网络监控主要分为以下几个方向。
(1)网络性能监控(Network Performance Monitor,NPM)
主要涉及网络监测、网络实时流量监控(网络延迟、访问量、成功率等)和历史数据统计、汇总和历史数据分析等功能。
目前,有很多公司提供了 NPM 解决方案,比如天旦、nCompass、SolarWinds、Nagios(已开源)等。
(2)网络攻击检查
主要针对内网或外网的网络攻击如 DDoS 攻击等,通过分析异常流量来确定网络攻击行为。
(3)设备监控
主要针对数据中心的多种网络设备进行监控,包括路由器、防火墙和交换机等硬件设备,可以通过 SNMP 等协议收集数据。
存储监控
存储主要分为云存储和分布式存储两部分。
-
云存储主要通过存储设备构建存储资源池,并对操作系统提供统一的存储接口,例如块存储的 SCSI 和文件存储 NFS 等。它们的特点是存储接口统一,并不识别存储数据的格式和内容,例如块存储只负责保存二进制数据块,这些二进制数据可能来自图片或视频,对于块存储来说都是一样的。
-
分布式存储主要构建在操作系统之上,提供分布式集群存储服务,主要是针对特定数据结构的数据存储。例如 HDFS 的大文件存储、Dynamo 的键值数据存储、Elasticsearch 的日志文档存储等。
我们通常说到的存储监控主要是指云存储监控,主要监控数据中心内部的存储使用量和读写速度。
我们可以将云存储监控分为存储性能监控、存储系统监控及存储设备监控。
-
存储性能监控方面,块存储通常监控块的读写速率、IOPS、读写延迟、磁盘使用量等;文件存储通常监控文件系统 Inode、读写速度、目录权限等。
-
存储系统监控方面,不同的存储系统有不同的指标。例如,对于 Ceph 存储,需要监控 OSD、MON的运行状态,各种状态的数量,以及集群 IOPS 等信息。
-
存储设备监控方面,对于构建在 x86 服务器上的存储设备,设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息;存储厂商以黑盒方式提供的商业存储设备通常自带监控功能,可监控设备的运行状态、性能和容量等。
服务器监控
每个程序最终都会在对应的服务器上运行,对服务器的监控一方面是提供服务进程的运行环境信息,另一方面是通过汇总服务器上的监控数据来了解整个数据中心内部的服务器资源使用情况。
服务器监控包括物理服务器主机监控、虚拟机监控和容器监控,需要做到对多种环境的兼容,如下所述。
-
对服务器硬件的兼容。数据中心内的服务器通常来自多个厂商如Dell、华为或者联想等,服务器监控需要获取不同厂商的服务器硬件信息。
-
对操作系统的兼容。为了适应不同软件的需求,在服务器上会安装不同的操作系统如 Windows、Linux,采集软件需要做到跨平台运行以获取对应的指标。
-
对虚拟化环境的兼容。当前,虚拟化已经成为数据中心的标配,可以更加高效便捷地获取计算和存储服务。服务器监控需要兼容各种虚拟化环境如虚拟机(KVM、VMware、Xen)及容器(Docker、rkt)。
采集监控数据的方式通常分为两种:一种是内置客户端,即在每台机器上都安装采集客户端;另一种是在外部采集,例如在虚拟化环境中可以通过Xen API、VMware Vcenter API 或者 Libvirt 的接口分别获取监控数据。
从操作系统层次来看,采集指标通常有如下几种。
-
CPU:涉及整体的 CPU 使用量、用户态百分比、内核态百分比、每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。
-
内存:涉及内存使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常数等。
-
网络I/O:涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等。
-
磁盘I/O:涉及磁盘的读写速率、IOPS(每秒读写次数)、磁盘用量、读写延迟等。
伴随着云计算的兴起,容器和虚拟机监控成为最近几年所有监控系统的必备功能,我们通常可以通过虚拟化软件提供的监控接口获取其监控数据。由 Google 开源的 cAdvisor 可以获取主机上所有容器的性能指标。
开源的服务器监控项目主要有 Prometheus、Zabbix 及 Open-Falcon 等。
中间件监控
中间件是指系统软件和应用软件之间的连接软件,无论是在分布式系统中还是在单体系统中,中间件都发挥着重要的作用。
常用的中间件主要有以下几类。
-
消息中间件,例如 RabbitMQ、Kafka。
-
Web 服务中间件,例如 Tomcat、Jetty、Nginx。
-
缓存中间件,例如 Redis、Memcached。
-
数据库中间件,例如 MySQL、PostgreSQL。
中间件的运行状态会直接影响服务程序的运行状态,很多系统的性能都受中间件的限制。Web 服务的并发上限很大程度上取决于数据库的并发能力,所以中间件监控既可以用于应用调优,也可以在高并发或者大流量的情况下及时反馈。
中间件监控需要针对不同中间件的特点和属性分别监控,目前并没有统一的标准和规范。例如,针对 Kafka 的性能监控通常需要采集 Kafka 集群的 Topic 个数、Broker 数据分区数量、日志 Offset 值、和生产消费流量等指标;针对 Redis 的性能监控通常需要采集 Redis 的内存使用量、连接数、和缓存命中率等指标。解决方案通常是分别开发一个数据收集 Agent,该 Agent 将采集中间件的性能指标并将其统一转换成 JSON、文本或者其他监控系统能识别的数据格式,然后汇总到监控中心。Prometheus 针对不同的中间件开发了对应的监控代理,例如 Kafka exporter、MySQL server exporter、Apache exporter、Redis exporter 等 exporter,它们负责采集这些中间件的特定指标,并提供 HTTP 查询接口。
应用程序监控(APM)
APM 主要是针对应用程序的监控,包括应用程序的运行状态监控、性能监控、日志监控及调用链跟踪等。调用链跟踪是指追踪整个请求过程,从用户发送请求(通常指浏览器或者应用客户端)到后端 API 服务,以及 API 服务和关联的中间件或者其他组件之间的调用,构建出一个完整的调用拓扑结构。不仅如此,APM 还可以监控组件内部方法的调用层次(Controller-->Service-->DAO),获取每个函数的执行耗时,从而为性能调优提供数据支撑。
日志监控
区别于指标监控,日志监控采集日志数据(文本类型),并将这些数据汇总到日志存储和搜索引擎中,提供日志检索的 Web 接入。指标监控的对象通常都是数字,而日志监控的对象是文本数据,这就要求存储系统具备文本检索功能。
日志监控不仅可以用于性能问题定位,还可以用于数据统计和故障告警。例如,在某个时间段内的程序输出日志中,若异常数超过阈值,则发出告警。
如下图所示,展现了目前业内比较流行的日志监控黄金组合,当然,每个组件都有一些替代方案。
接下来对上图的组件进行简单介绍。
-
Fluentd 主要负责日志采集,其他开源组件还有 Filebeat、Flume、Fluent Bit 等,也有一些应用集成 Log4g 等日志组件直接输出日志。
-
Kafka 主要负责数据整流合并,避免突发日志流量直接冲击 Logstash,业内也有用 Redis 替换 Kafka 的方案。
-
Logstash 负责日志整理,可以完成日志过滤、日志修改等功能。
-
Elasticsearch 负责日志存储和日志检索,自带分布式存储,可以将采集的日志进行分片存储。为保证数据高可用,Elasticsearch 引入多副本概念,并通过 Lucene 实现日志的索引和查询。
-
Kibana 是一个日志查询组件,负责日志展现,主要通过 Elasticsearch 的 HTTP 接口展现日志。
监控系统的实现
总体架构
监控系统的实现各有不同。
-
在数据采集方面,有的监控系统采用主动采集方式,有的监控系统采用被动上报方式, 有的监控系统采用上述两者兼备的方式。
-
在数据传输方面,有的监控系统采用 Socket 传输,有的监控系统采用 HTTP 传输。
-
在数据存储方面,有的监控系统将监控数据保存在 MySQL 中,有的监控系统将监控数据保存在 MongoDB、OpenTSDB、InfluxDB 等时序数据库中。
但是,所有监控系统的核心都是采集和处理数据。
监控系统通常由指标采集子系统和数据处理子系统这两大子系统组成,对这两大子系统说明如下。
-
指标采集子系统主要负责信息采集、过滤、汇总和存储。
-
数据处理子系统主要负责数据分析、展现、预警、告警动作触发和告警等。
指标采集
指标采集包括数据采集、数据传输和过滤,以及数据存储。
数据采集
数据采集有两种方式:通过客户端进行数据采集;通过标准协议(如 SNMP、JMX、IPMI 等)进行数据采集。
数据传输和过滤
我们还需要将采集的数据传输到数据存储节点,这时可以通过 HTTP、Socket 连接进行点对点传输,还可以通过 RabbitMQ、Kafka 等消息中间件进行传输。
HTTP 是目前互联网最流行的协议,通过 HTTP 方式传输需要一个 HTTP 客户端和一个 HTTP 服务端。如果 Agent(采集器)是一个 HTTP 服务端,那么采集中心节点会周期性调用 Agent 的接口获取数据,这种方式被称为 Pull(拉取);相反,如果 Agent 是一个 HTTP 客户端,它就会调用中心节点的 HTTP 服务,将数据发送到中心节点,这种方式被称为 Push(推送)。Socket 方式是指直接建立 TCP/IP 的传输通道,在传输上会更加高效,但对 Socket 连接的维护额外增加开发维护成本,对于开发人员的要求也更高。
使用消息中间件传输的方式在结构上充分解耦,数据采集组件只需将采集的数据放到消息中间件中,数据收集组件只需要从消息中间件中获取数据。消息中间件不仅可以将监控数据进行一定程度的持久化, 而且可以对监控数据进行整流,避免突发流量冲击数据收集组件。数据收集组件可以部署多个接收消息,均衡流量。采用消息中间件传输的方式也有一定的弊端,即会造成整个系统对中间件的强依赖,如果中间件发生故障,则可能导致整个系统发生故障,并且消息中间件在安装部署及后期的运维中都比较复杂。采用 HTTP 传输的方式虽然有一定的耦合度,但系统可以足够简单,易于扩展和维护,大部分开源监控系统都采用这种方式。
数据存储
对监控数据的存储通常借助于时序数据库(TSDB)。监控数据的最大特点是有时间属性,每个监控数据都有一个时间维度(属性),被称为时序数据,展现了一个物体的某些特征在一段时间内的变化情况。例如,股市数据就是典型的时序数据,在开盘的时候,每个时间点对应一个股价,并且股价随着时间的推移不断改变。
时序数据的特点有:
-
一次性写入多次读取,时序数据通常不会修改更新,一旦存入,则后期只会对数据进行查询操作。
-
数据流持续平稳,时序数据量往往和采集点的数据量成正比,不会出现业务系统流量突增的情况,并且数据流是持续稳定的,通常间隔一个稳定的采集周期来获取数据;相应的,随着时间的推移,存储的数据量会变得非常大。
-
查询方式以时间为维度,数据查询通常会指定一段时间,并且热数据通常都是最新采集的数据。在实际场景中,通常查询最近几个小时的监控数据,很少会查询一周之前的监控数据。
数据处理
数据处理分为数据查询、数据分析和基于规则告警等。
数据查询
数据查询指通过展现层(浏览器或者客户端)多维度展现实时数据和历史数据。实时数据查询严格要求数据的准确性和实时性,查询接口需要迅速响应。历史数据的查询则要求数据的时间跨度长,并且可以生成对应的监控报表。
另外,可以通过一些 Web 工具,把后端分析的数据以可视化的方式展现。折线图能够很好地展现数据变化的趋势;饼状图能够更好地展现系统中各个子模块的占比;柱状图的优势在于对数据的对比。这些图像化的展现能够让数据 “动起来”,使其更加直观。
目前开源的工具有 Grafana、Kibana等,它们都允许用户自定义监控视图。
数据分析
数据分析是指为用户或者其他系统提供对监控数据的性能分析、关联分析和趋势分析。
基于规则告警
基于规则告警是指利用已经采集的监控数据,匹配用户自定义的多维度告警规则,如果满足,则触发相应规则的告警。
例如,性能告警规则一般是设定某个阈值、触发次数和告警行为,对于 CPU 利用率、内存使用量、 QPS 等性能指标,如果在某个时间段内多次触发该阈值,则将其视为满足告警条件;如果是站点告警,则一般设置请求的返回码或者正则匹配消息体的内容、触发次数和告警动作;还有一些告警属于异常告警,例如服务器宕机、网络不通等情况,通常不需要设置告警规则。
如果某个告警规则被触发,则在接下来的一段时间内,为避免相同的告警被多次触发,需要进行告警抑制;如果是一个由 “根问题” 触发的一系列子问题告警,则都需要收敛到这次 “根问题” 上面。
监控系统的发展趋势
监控系统提供的对单个指标的监控并不能很好地反映运行系统和程序的当前状态。告警都发送在故障发生之后,并不能对故障提前预警,并且告警处理基本通过简单的通知机制实现,运维人员还需要通过综合分析来确定问题,使问题处理时间延长。在分布式系统普及后,定位问题变得更加复杂。单纯的指标监控系统已经不能满足业务的需求。
如今,监控系统朝着自动化和智能化的方向发展,我们把性能监控、健康状态监控、应用监控等提供基础能力的监控称为传统监控;把具备机器学习和自动化运维能力,能够进行智能分析和故障处理的监控系统称为智能监控。
智能监控需要具备以下能力:
-
通过多种维度的指标分析定位问题的故障点。数据中心内的指标种类繁多,需要根据从硬件(机房温度、风扇转速)到软件(TCP 延迟、网络丢包率)等多个维度的监控指标,准确定位故障点。
-
故障和风险预测。指通过对以往故障的学习,预测未来的故障时间。AWS (Amazon Web Services)通过对大量服务器发生故障的时间、故障前某些指标的异常等数据进行机器学习,可以准确预测服务器发生故障的时间,从而提前更换服务器。在 AWS 数据中心内有百万量级的服务器,故障发生的频率非常高,如果能够提前更换服务器,则会极大降低故障率。另外在互联网场景中,风险预测也非常重要,为了应对突发流量,通过对历史服务请求的 QPS 学习,可以预测未来某个时间段将会出现的流量高峰,从而提前将服务扩容。
-
智能处理。单纯的通知告警并不能解决问题,现在的告警处理逐步从完全的人工处理,发展为目前的专家系统(机器提供一些处理意见),下一阶段将会是机器的自动化运维,在不需要人为干涉的情况下,能够通过机器处理故障,而智能监控系统正是运维自动化的首要环节。
智能监控将会是监控的发展趋势,但它并不是空中楼阁,而是建立在传统运维基础之上的,如果没有传统监控的支持,就没有实时数据的支持;如果没有对大量基础指标监控数据的学习,就没有智能决策。
本文讲述监控系统相关知识的内容主要来自书籍《深入浅出 Prometheus》,感兴趣的读者可以购买相关书籍进行深入学习。
更多相关内容 -
-
道路监控视频资源
2018-05-08 17:07:20十个 视频资源 搞视频分割,背景建模的同学可下载 道路监控视频 -
车辆识别-道路监控视频源(高清 AVI格式)
2017-11-23 20:28:01车辆识别-道路监控视频源(高清 AVI格式),可用于基于视频的车辆识别,内含3个视频文件 -
视频监控系统整套源码
2015-10-27 15:16:28网络视频监控系统整套。含多云台操作,含数据库和源代码,开发视频监控系统时修改修改就OK。 -
Prometheus 监控详解
2021-12-07 18:42:20文章目录一、常用监控系统介绍1. Cacti2. Nagios3. Zabbix4. Prometheus5. Open-falcon二、运维监控平台设计思路三、Prometheus 的监控体系四、Prometheus 简介五、Prometheus 时序数据六、Prometheus 生态组件七、...文章目录
一、常用监控系统介绍
1. Cacti
cacti(英文含义为仙人掌)是一套基于 PHP、MySQL、SNMP 和 RRDtool 开发的网络流量监测图形分析工具。它通过 snmpget 来获取数据,使用 RRDTool 绘图,但使用者无须了解 RRDTool 复杂的参数。它提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与 LDAP 结合进行用户认证,同时也能自定义模板,在历史数据的展示监控方面,其功能相当不错。
cacti 通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力(数据的叠加功能)。2. Nagios
Nagios 是一款开源的免费网络监视工具,能有效监控 windows、Linux 和 Unix 的主机状态,交换机路由器等网络设置打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员,在状态恢复后发出正常的邮件或短信通知。
Nagios 主要的特征是监控告警,最强大的就是告警功能,可支持多种告警方式,但缺点是没有强大的数据收集机制,并且数据出图也很简陋,当监控的主机越来越多时,添加主机也非常麻烦,配置文件都是基于文本配置的,不支持 web 方式管理和配置,这样很容易出错,不宜维护。3. Zabbix
zabbix 是一个基于 web 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix 能监视各种网络参数,保证服务器系统的安全运营;并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。
zabbix 由 2 部分构成,zabbix server 与可选组件 zabbix agent。zabbix server 可以通过 SNMP,zabbix agent,ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在 Linux,Solaris,HP-UX,ALX,Free BSD,open BSD,os x 等平台上。
zabbix 解决了 cacti 没有告警的不足,也解决了 nagios 不能通过 web 配置的缺点,同时还支持分布式部署,这使得它迅速流行起来,zabbix 也成为目前中小企业监控最流行的运维监控平台。当然,zabbix 也有不足之处,它消耗的资源比较多,如果监控的主机非常多时(服务器数量超过 500 台),可能会出现监控超时、告警超时、告警系统单点故障等现象,不过也有很多解决办法,比如提高硬件性能、改变 zabbix 监控模式、多套 zabbix 等。监控方式:
-
agent 代理:专门的代理服务方式进行监控,专属的协议,装有 zabbix-agent 的主机就可以被 zabbix-server 监控,主动或被动的方式,把数据给到 server 进行处理。
-
ssh/telnet:linux 主机支持 ssh/telnet 协议
-
snmp:网络设备路由器、交换机不能安装第三方程序(agent),使用简单网络协议。大多数的路由器设备支持 SNMP 协议。
-
ipmi:通过 ipmi 接口进行监控,我们可以通过标准的 ipmi 硬件接口,监控被监控对象的物理特征,比如电压,温度,风扇状态电源情况,被广泛使用服务监控中,包括采集 cpu 温度,风扇转速,主板温度,及远程开关机等等,而且 ipmi 独立于硬件和操作系统,无论是 cpu,bios 还是 os 出现故障,都不会影响 ipmi 的工作,因为 ipmi 的硬件设备 BMC(bashboard management controller)是独立的板卡,独立供电。
zabbix 核心组件介绍:
- zabbix server:zabbix 软件实现监控的核心程序,主要功能是与 zabbixproxies 和 agents 进行交互、触发器计算、发送告警通知;并将数据集中保存。与 prometheus 类似可以保存收集到的数据,但是 prometheus 告警需要使用 alter manager 组件。
- database storage:存储配置信息以及收集到的数据。
- web Interface:zabbix 的 GUI 接口,通常与 server 运行在同一台机器上。
- proxy:可选组件,常用于分布式监控环境中,一个帮助 zabbix server 收集数据,分担 zabbix server 的负载的程序。
- agent:部署在被监控主机上,负责收集数据发送给 server。
4. Prometheus
borg.kubernetes
borgmon(监控系统)对应克隆的版本:prometheus(go 语言开发)所以 prometheus 特别适合 K8S 的架构上。而作为一个数据监控解决方案,它由一个大型社区支持,有来自 700 多家公司的 6300 个贡献者,13500 个代码提交和 7200 个拉取请求。prometheus 具有以下特性:
- 多维的数据模型(基于时间序列的 Key-value 键值对)
- 灵活的查询和聚合语言 PromQL
- 提供本地存储和分布式存储
- 通过基于 HTTP 和 HTTPS 的 Pull 模型采集时间序列数据(pull 数据的推送,时间序列:每段时间点的数据值指标,持续性的产生。横轴标识时间,纵轴为数据值,一段时间内数值的动态变化,所有的点连线形成大盘式的折线图)
- 可利用 Pushgateway(Prometheus 的可选中间件)实现 Push 模式
- 可通过动态服务发现或静态配置发现目标机器(通过 consul 自动发现和收缩)
- 支持多种图表和数据大盘
5. Open-falcon
open-falcon 是小米开源的企业级监控工具,用 go 语言开发,包括小米、滴滴、美团等在内的互联网公司都在使用它,是一款灵活、可拓展并且高性能的监控方案。
https://www.cnblogs.com/yinzhengjie/p/9946624.htmlPS:
Nightingale 是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。
Nightingale 在产品完成度、系统高可用、以及用户体验方面,达到了企业级的要求,可满足不同规模用户的场景,小到几台机器,大到数十万都可以完美支撑。兼顾云原生和裸金属,支持应用监控和系统监控,插件机制灵活,插件丰富完善,具有高度的灵活性和可扩展性。
Nightingale 是一款分布式高性能的运维监控系统,在 Open-Falcon 的基础上,各核心模块做了大幅优化,引入了滴滴的生产实践经验结合滴滴内部的最佳实践,在性能、可维护性、易用性方面做了大量的改进, 作为集团统一的监控解决方案,支撑了滴滴内部数十亿监控指标,覆盖了从系统、容器、到应用等各层面的监控需求,周活跃用户数千。五年磨一剑,取之开源,回馈开源。夜莺 Fork 自 Open-Falcon,可以把夜莺看做是 Open-Falcon 的下一代。
https://cloud.tencent.com/developer/article/1638839?from=15425二、运维监控平台设计思路
- 数据收集模块
- 数据提取模块
- 监控告警模块
可以细化为 6 层
第六层:用户展示管理层 同一用户管理、集中监控、集中维护 第五层:告警事件生成层 实时记录告警事件、形成分析图表(趋势分析、可视化) 第四层:告警规则配置层 告警规则设置、告警伐值设置 第三层:数据提取层 定时采集数据到监控模块 第二层:数据展示层 数据生成曲线图展示(对时序数据的动态展示) 第一层:数据收集层 多渠道监控数据
三、Prometheus 的监控体系
系统层监控(需要监控的数据)
- CPU、Load、Memory、swap、disk i/o、process 等
- 网络监控:网络设备、工作负载、网络延迟、丢包率等
中间件及基础设施类监控
- 消息中间件:kafka、redis、RocketMQ 等消息代理/中间件
- WEB 服务器容器:tomcat、weblogic、apache、php、spring 系列
- 数据库/缓存数据库:MySQL、PostgreSQL、MogoDB、es、redis
redis 监控内容:
- redis 所在服务器的系统层监控
- redis 服务状态
- RDB AOF 日志监控
(日志 -》如果是哨兵模式 -》哨兵共享集群信息,产生的日志 -》直接包含的其他节点哨兵信息及 mysql 信息) - key 的数量
- key 被命中的数据/次数
- 最大连接数 -》redis 和系统
(系统:ulimit -a。redis:redis-cli 登陆 -》config get maxclients 查看最大连接。)
应用层监控
用于衡量应用程序代码状态和性能
- 白盒监控:自省指标,等待被下载
- 黑盒监控:基于探针的监控方式,不会主动干预、影响数据
业务层监控
用于衡量应用程序的价值
- 如电商业务的销售量,QPS、dau 日活、转化率等。
- 业务接口:登入数量,注册数、订单量、搜索量和支付量。
四、Prometheus 简介
Prometheus 受启发于 Google 的 Brogmon 监控系统(相似的 Kubernetes 是从 Google 的 Brog 系统演变而来),从 2012 年开始由前 Google 工程师在 Soundcloud 以开源软件的形式进行研发,并且于 2015 年早期对外发布早期版本。 2016 年 5 月继 Kubernetes 之后成为第二个正式加入 CNCF 基金会的项目,同年 6 月正式发布 1.0 版本。2017 年底发布了基于全新存储层的 2.0 版本,能更好地与容器平台、云平台配合。 Prometheus 作为新一代的云原生监控系统,目前已经有超过 650+ 位贡献者参与到 Prometheus 的研发工作上,并且超过 120+ 项的第三方集成。
五、Prometheus 时序数据
时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的集合将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴,服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。
- 数据来源:
prometheus 基于 HTTP call (http/https 请求),从配置文件中指定的网络端点
endpoint/IP:端口
上周期性获取指标数据。很多环境、被监控对象,本身是没有直接响应/处理 http 请求的功能,prometheus-exporter 则可以在被监控端收集所需的数据,收集过来之后,还会做标准化,把这些数据转化为 prometheus 可识别,可使用的数据。- 收集数据:
监控概念:白盒监控、黑盒监控
白盒监控:自省方式,被监控端内部,可以自己生成指标,只要等待监控系统来采集时提供出去即可。
黑盒监控:对于被监控系统没有侵入性,对其没有直接 “影响”,这种类似于基于探针机制进行监控(snmp 协议)。
Prometheus 支持通过三种类型的途径从目标上 "抓取(Scrape)" 指标数据(基于白盒监控)
Exporters -> 工作在被监控端,周期性的抓取数据并转换为 pro 兼容格式等待 prometheus 来收集,自己并不推送。 Instrumentation -> 指被监控对象内部自身有数据收集、监控的功能,只需要 prometheus 直接去获取。 Pushgateway -> 短周期 5s-10s 的数据收集。
- 获取方式:
Prometheus 同其它 TSDB 相比有一个非常典型的特性,它主动从各 Target 上拉取数据,而非等待被监控端的推迭。(pull/push)
两个获取方式各有优劣,其中,Pull 模型的优势在于:
集中控制:有利于将配置集在 Prometheus server 上完成,包括指标及采取速率等。Prometheus 的根本目标在于收集在 target 上预先完成聚合的聚合型数据,而非一款由事件驱动的存储系统通过 targets(标识的是具体的被监控端)。比如配置文件中的 targets:['localhost:9090']
六、Prometheus 生态组件
prometheus 生态圈中包含了多个组件,其中部分组件可选。
- Prometheus server:收集和储存时间序列数据。通过 scraping 以刮擦的方式去获取数据放入 storge(TSDB 时序数据库),制定 Rules/Alerts 告警规则,service discovery 自动发现需要监控的节点。
- Client Library:客户端库,目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径。
- Push Gateway:接收那些通常由短期作业生成的指标数据的网关,并支持由 Prometheus Server 进行指标拉取操作。
- Exporters:用于暴露现有应用程序或服务(不支持 Instrumentation)的指标给 Prometheus server。
而 pro 内建了数据样本采集器,可以通过配置文件定义,告诉 prometheus 到那个监控对象中采集指标数据,prometheus 采集过后,会存储在自己内建的 TSDB 数据库中,提供了 PromQL 支持查询和过滤操作,同时支持自定义规则来作为告警规则,持续分析一场指标,一旦发生,通知给 alerter 来发送告警信息,还支持对接外置的 UI 工具( grafana)来展示数据。采集、抓取数据是其自身的功能,但一般被抓取的数据一般来自于:export/instrumentation (指标数据暴露器)来完成的,或者是应用程序自身内建的测量系统(汽车仪表盘之类的,测量、展示)。
-
Alertmanager:prometheus 可以生成告警信息,但是不能直接提供告警,需要使用一个外置的组件 altermanager 来进行告警。由告警规则对接,从 Prometheus Server 接收到 “告警通知” 后,通过去重、分组、路由等预处理功能后高效向用户完成告警信息发送。emailetcd 优势在于
收敛、支持静默、去重、可以防止告警信息的轰炸
。 -
Data Visualization(Dashboards):与 TSDB 对接并且展示数据库中的数据,Prometheus web UI(Prometheus Server 内建),及 Grafana 等。
-
Service Discovery:动态发现待监控的 Target,从而完成监控配置的重要组件,在容器化环境中尤为有用。该组件目前由 PrometheusServer 内建支持。
-
PromQL(告警规则编写):通常告警规则的文件指定输出到展示界面(grafana)
-
UI 表达式浏览器(调试)
七、Prometheus 数据模型
1. 概述
-
Prometheus 仅用键值方式存储时序式的聚合数据,不支持文本信息
-
其中的 “键” 称为指标(metric),通常意味着 CPU 速率、内存使用率或分区空闲比例等
-
同一指标可能适配到多个目标或设备、因而它使用 “标签” 作为元数据,从而为 metric 添加更多的信息描述维度
-
Prometheus 每一份样本数据都包含了:
① 时序列标识:key+lables ② 当前时间序列的样本值value ③ 这些标签可以作为过滤器进行指标过滤及聚合运算,如何从上万的数据过滤出关键有限的时间序列,同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们想要的样本数据
2. 指标类型
默认都是双精度浮点型数据(服务器端无数据量类型数据)
- counter:计数器单调递增
- gauge:仪表盘:有起伏特征的
- histogram:直方图
在一段时间范围内对数据采样的相关结果,并记入配置的 bucket 中,它可以存储更多的数据,包括样本值分布在每个 bucket 的数量,从而 prometheus 就可以使用内置函数进行计算。
计算样本平均值:以值得综合除以值的数量
计算样本分位值:分位数有助于了解符合特定标准的数据个数,例如评估响应时间超过1秒的请求比例,若超过20侧则进行告警等- summary:摘要,histogram 的扩展类型,它是直接由监控端自行聚合计算出分位数,同时将计算结果响应给 prometheus server 的样本采集请求,因而,其分位数计算是由监控端完成
3. 作业 job 和实列 targets/instance
- job:能够接收 prometheus server 数据 scrape ,如
"mysql nodes" "mysql master slave"
- targets:每一个可以被监控的系统,成为 targets 多个相同的 targets 的集合(类)称为 job
- instance:实例与 targets 类似。与 target 相比,instance 更趋近于一个具体可以提供监控数据的实例,而 targets 则更像一个对象、目标性质。
4. PrometheusQL(数据查询语言也是时序数据库使用语言)
支持两种向量,同时内置提供了一组用于数据处理的函数
- 即时向量:最近以此时间戳上跟踪的数据指标,表示的是一个时间刻度
- 即时向量选择器:返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本,该样本成为即时样本
- 时间范围向量:指定时间范围内所有时间戳上的数据指标,表示的是一组时间区间
- 范围向量选择器:返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)
八、Prometheus 安装
[root@c7-1 ~]#hostnamectl set-hostname prometheus [root@c7-1 ~]#su [root@prometheus ~]#systemctl stop firewalld && systemctl disable firewalld &> /dev/null [root@prometheus ~]#setenforce 0 [root@prometheus ~]#ntpdate ntp1.aliyun.com &> /dev/null [root@prometheus ~]#wget http://101.34.22.188/prometheus/prometheus-2.27.1.linux-amd64.tar.gz -P /opt &> /dev/null [root@prometheus ~]#tar xf /opt/prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local/ [root@prometheus ~]#cd /usr/local/prometheus-2.27.1.linux-amd64/ [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#ls console_libraries consoles LICENSE NOTICE prometheus prometheus.yml promtool
主配置文件
[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#egrep -v "^(.)*#(.)*$" prometheus.yml | grep -v "^$" global: alerting: alertmanagers: - static_configs: - targets: rule_files: scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#cat prometheus.yml # my global config global: #全局组件 scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s). # Alertmanager configuration #对接的 altermanager (第三方告警模块) alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: #告警规则;告警规则可以使用 yml 规则去书写 # - "first_rules.yml" # - "second_rules.yml" # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: #数据采集模块 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. #对于所抓取的指标数据采集的来源在job_name中定义 - job_name: 'prometheus' #对于指标需要打上的标签,对于PrometheusSQL(查询语句)的标签:比如prometheus{target='values'} # metrics_path defaults to '/metrics' #收集数据的路径,展示使用 metrics 模式 # scheme defaults to 'http'. #默认抓取的方式是 http static_configs: #对于 Prometheus 的静态配置监听端口具体数据收集的位置 默认的端口 9090 - targets: ['localhost:9090']
开启 prometheus
[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#nohup ./prometheus & [1] 65782 [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#nohup: 忽略输入并把输出追加到"nohup.out" #启动慢,等一会 [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#netstat -antp | grep 9090 tcp6 0 0 :::9090 :::* LISTEN 65782/./prometheus tcp6 0 0 ::1:9090 ::1:58132 ESTABLISHED 65782/./prometheus tcp6 0 0 ::1:58132 ::1:9090 ESTABLISHED 65782/./prometheus
访问 web 页面(prometheus 是表达式浏览器)
Prometheus 会周期性的采集数据,多次周期性采集的数据集合形成时间序列
访问 192.168.10.20:9090/metrics ,查看 prometheus 自带的内键指标
九、Prometheus 监控其他节点
在 Prometheus 的架构设计中,Prometheus Server 并不直接服务监控特定的目标,其主要任务负责数据的收集,存储并且对外提供数据查询支持。因此为了能够监控到更多信息,如主机的 CPU 使用率等,我们需要使用到 node_exporter。Prometheus 周期性的从 Exporter 暴露的 HTTP 服务地址(通常是 /metrics)拉取监控样本数据。
下载地址:
http://prometheus.io/download/或者
wget http://101.34.22.188/prometheus/node_exporter-1.1.2.linux-amd64.tar.gz
解压安装包,优化命令路径,设置服务控制,开启服务(被监控端)
tar zxvf node_exporter-1.1.2.linux-amd64.tar.gz cd node_exporter-1.1.2.linux-amd64 cp node_exporter /usr/local/bin ./node_exporter --help #查看命令可选项
服务开启方式一:直接运行
./node_exporter
服务开启方式二:使用 systemctl 控制
cat /usr/lib/systemd/system/node_exporter.service [Unit] Description=node_exporter Documentation=https://prometheus.io/ After=network.targets [service] Type=simple User=prometheus ExecStart=/usr/local/bin/node_exporter \ --collector.ntp \ --collector.mountstats \ --collector.systemd l --collertor.tcpstat ExecReload=/bin/kill -HUP $MAINPID TimeoutStopSec=20s Restart=always [Install] WantedBy=multi-user.target ------------------------- systemctl daemon-reload systemctl start node_exporter
启动成功后,可以看到以下输出:
...... level=info ts=2021-12-09T14:48:10.414Z caller=tls_config.go:191 msg="TLS is disabled." http2=false
访问
192.168.10.30:9100/metrics
(node 节点)查看抓取内容
访问
http://192.168.10.20:9090/
(服务端)点击 -》status -》targets,发现并没有 node 指标,那是因为我们还没配 prometheus.yml 文件[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#vim prometheus.yml ...... ...... #添加如下配置,有几个节点就加几个节点(我们并没有在 20 上安装 node_exporter,因此实验应该收集不到 20 的指标) - job_name: 'nodes' static_configs: - targets: - 192.168.10.20:9100 - 192.168.10.30:9100 - 192.168.10.40:9100
重启服务端 prometheus 查看监控情况
可以看到安装了 node_exporter 的 30/40 可以监控,20 无法连接。当然也可以查看被监控端展示的数据。
输入 up 函数查看当前在线的主机,0 值表示异常
筛选:
up{job=“prometheus”}
up{instance=“192.168.10.20:9100”}
十、表达式浏览器常规使用
CPU 使用总量
PromQL: node_cpu_seconds_total
计算过去 5 分钟内 CPU 使用速率
irate(node_cpu_seconds_total{mode="idle"}[5m]) ----------------------------------------------- irate : 速率计算函数(灵敏度非常高的) node_cpu_seconds_total : node节点CPU使用总量 mode="idle" : 空闲指标 5m : 过去的5分钟内,所有CPU空闲数的样本值,每个数值做速率运算
每台主机 CPU 在 5 分钟内的平均使用率
(1-avg(irate(node_cpu_seconds_total{mode='idle'}[5m]))by (instance))*100 --------------------------------------------------------- avg : 平均值 avg(irate(node_cpu_seconds_total{mode='idle'}[5m]) : 可以理解为 CPU 空闲量的百分比 by(instance) : 表示的是所有节点
查询 1 分钟平均负载超过主机 CPU 数量两倍的时间序列
node_load1 > on (instance) 2 * count (node_cpu_seconds_total{mode='idle'}) by(instance)
内存使用率
node_memory_MemTotal_bytes node_memory_MemFree_bytes node_memory_Buffers_bytes node_memory_Cached_bytes #计算使用率: 可用空间:以上后三个指标之和 己用空间:总空间减去可用空间 使用率:己用空间除以总空间
阶段总结
指标(配置文件/PromQL):target/instance target 偏向于表示一个集合 instance 偏向于表示具体的一个可提供监控数据的对象 PromQL:指标 {标签1=标签值1,......,标签N=标签N} 样本(值) prometheus 的配置文件: - global - alertmanager - rules - scrape prometheus 架构模型(工作流程) scrape 收集数据方式: - exporter - 自建/内建指标 - pushgateway sd 服务发现: - 基于 fd 文件 - 基于 DNS -》SRV 记录 - 基于 consul -》自动发现,同时利用 prometheus 的自身周期扫描配置文件更新并且加载的特性,实现动态更新 - 基于 K8S 服务发现
十一、部署 Service Discovery 服务发现
1. 相关概念
1.1 Prometheus 指标抓取的生命周期
发现 -> 配置 -> relabel -> 指标数据抓取 -> metrics relabel
Prometheus 的服务发现类型:
-
基于文件的服务发现
-
基于 DNS 的服务发现
-
基于 API 的服务发现:Kubernetes、Consul、Azure、重新标记;target 重新打标;metric 重新打标
-
基于 K8S 的服务发现
1.2 Prometheus 的服务发现机制
详细的 Prometheus 工作生命周期
- Prometheus Server 的数据抓取工作于 Pull 模型,因而它必需要事先知道各 Target 的位置,然后才能从相应的 Exporter 或 Instrumentation 中抓取数据。
- 对于小型的系统环境来说,通过 static_configs 指定各 Target 便能解决问题,这也是最简单的配置方法。每个 Targets 用一个网络端点
ip:port
进行标识。 - 对于中大型的系统环境或具有较强动态性的云计算环境来说,静态配置显然难以适用。
因此,Prometheus 为此专门设计了一组服务发现机制,以便于能够基于服务注册中心(服务总线)自动发现、检测、分类可被监控的各 Target,以及更新发生了变动的 Target 指标抓取的生命周期。 - 在每个 scrape_interval 期间,Prometheus 都会检查执行的作业 Job,这些作业首先会根据 Job 上指定的发现配置生成 Target 列表,此即服务发现过程。服务发现会返回一个 Target 列表,其中包含一组称为元数据的标签,这些标签都以
meta_
为前缀。 - 服务发现还会根据目标配置来设置其它标签,这些标签带有 “” 前缀和后缀,包括 “scheme”、“address” 和 “metrics path_”,分别保存有 target 支持使用协议(http或https,默认为http) 、target 的地址及指标的 URI 路径(默认为 /metrics)。
- 若 URI 路径中存在任何参数,则它们的前缀会设置为 “param” 这些目标列表和标签会返回给 Prometheus,其中的一些标签也可以配置中被覆盖。
- 配置标签会在抓取的生命周期中被重复利用以生成其他标签,例如指标上的 instance 标签的默认值就来自于 address 标签的值。
- 对于发现的各目标,Prometheus 提供了可以重新标记(relabel)目标的机会,它定义在 job 配置段的 relabel_config 配置中。
2. 静态配置发现
修改 prometheus 服务器上的配置文件,指定 targets 的端口
- job_name: 'nodes' static_config: - targets: - 192.168.10.20:9100 - 192.168.10.30:9100 - 192.168.10.40:9100
3. 动态发现
3.1 基于文件形式的服务发现
-
基于文件的服务发现仅仅略优于静态配置的服务发现方式,它不依赖于任何平台或第三方服务,因而也是最为简单和通用的实现方式。
-
prometheus server 定期从文件中加载 target 信息(pro-server pull 指标发现机制 -job_name 获取我要 pull 的对象target)文件可以只用 json 和 yaml 格式,它含有定义的 target 列表,以及可选的标签信息
-
以下第一配置,能够将 prometheus 默认的静态配置转换为基于文件的服务发现时所需的配置
prometheus 会周期性的读取、重载此文件中的配置,从而达到动态发现、更新的操作
环境准备
cd /usr/local/prometheus-2.27.1.linux-amd64/ mkdir file_sd cd file_sd mkdir targets #把修改后的 Prometheus.yml 上传到 file_sd 目录下 cd targets #把 nodes_centos.yaml、prometheus_server.yaml、prometheus.yml 上传到指定目录下 wget http://101.34.22.188/prometheus/file_sd/nodes_centos.yaml -P /usr/local/prometheus-2.27.1.linux-amd64/file_sd/targets wget http://101.34.22.188/prometheus/file_sd/prometheus_server.yaml -P /usr/local/prometheus-2.27.1.linux-amd64/file_sd/targets wget http://101.34.22.188/prometheus/file_sd/prometheus.yml -P /usr/local/prometheus-2.27.1.linux-amd64/file_sd ----------------------------- [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64/file_sd]#tree . ├── prometheus.yml └── targets ├── nodes_centos.yaml └── prometheus_server.yaml 1 directory, 3 files
修改 nodes_centos.yaml、prometheus_server.yaml 两个文件 IP 为自己的 IP
指定配置文件启动
[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#ps aux|grep prometheus root 3999 0.1 2.8 1242744 109004 ? Sl 07:03 0:30 ./prometheus root 63514 0.0 0.0 112728 980 pts/1 S+ 11:33 0:00 grep --color=auto prometheus [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#kill -9 3999 [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#ps aux|grep prometheus root 63525 0.0 0.0 112728 976 pts/1 S+ 11:33 0:00 grep --color=auto prometheus [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#./prometheus --config.file=./file_sd/prometheus.yml ...... ......
开启 node 节点
./node_exporter
浏览器登录查看 http://192.168.10.20:9090/targets
新加一个节点安装 node_exporter ,在服务端 nodes_centos.yaml 添加一个节点信息,并查看这个节点信息是否加入
3.2 文件发现的作用
增加 node,prometheus 服务端节点只需更改 nodes_centos.yaml,prometheus_server.yaml 两个文件添加地址就行,不需要停止服务。
4. 基于 DNS 自动发现
- 基于 DNS 的服务发现,针对一组 DNS 域名进行定期查询,以发现待监控的目标查询时使用的 DNS 服务器由 /etc/resolv.conf 文件指定。
- 该发现机制依赖于 A、AAAA 和 SRV 资源记录,且仅支持该类方法,尚不支持 RFC6763 中的高级 DNS 发现方式。
#SRV:SRV 记录的作用是指明某域名下提供的服务。 例: http._tcp.example.com.SRV 10 5 80. www.example.com SRV 后面项目的含义: 10-优先级,类似MX记录 5-权重 80-端口 www.example.com - 实际提供服务的主机名。同时 SRV 可以指定在端口上对应哪个 service #prometheus 基于 DNS 的服务中的 SRV 记录,让 prometheus 发现指定 target 上对应的端口对应的是 exporter 或 instrumentation
5. 基于 Consul 发现
5.1 概述
一款基于 golang 开发的开源工具,主要面向分布式,服务化的系统。提供服务注册、服务发现和配置管理的功能。提供服务注册/发现、健康检查、Key/value 存储、多数据中心和分布式一致性保证等功能。
原理:
通过定义 json 文件将可以进行数据采集的服务注册到 consul 中,用于自动发现同时使用 prometheus 做为 client 端获取 consul 上注册的服务,从而进行获取数据
5.2 部署安装
prometheus 通过 consul 自动发现主机清单配置
- 普罗米修斯的 prometheus-servers.json 文件中写的是它的主机信息,主机信息中写有相对应的标签 tags: “prometheus”,这个配置文件被 consul 所加载,加载后会显示在 8500 的端口上,prometheus 在 yml 文件中也定义了二个 job:“prometheus” “nodes”,关联了 consul 的位置 192.168.10.20:8500,Prometheus 会定期到 consul 8500 上去找标签是 prometheus 的节点,在 8500 上就可以获取主机信息,找到以后可以直接到 http://192.168.10.20:9090/metrics 上收集信息,最后通过 ui 表达式浏览器显示出来。
安装 consul_1.9.0 版本
[root@prometheus ~]#wget http://101.34.22.188/consul/consul_1.9.0_linux_amd64.zip &> /dev/null [root@prometheus ~]#ls consul_1.9.0_linux_amd64.zip [root@prometheus ~]#unzip consul_1.9.0_linux_amd64.zip -d /usr/local/bin/ Archive: consul_1.9.0_linux_amd64.zip inflating: /usr/local/bin/consul
启动开发者模式
consul 开发者模式,可以快速开启单节点的 consul 服务,具有完整功能,方便开发测试
[root@prometheus ~]#mkdir -pv /consul/data mkdir: 已创建目录 "/consul" mkdir: 已创建目录 "/consul/data" [root@prometheus ~]#mkdir /etc/consul [root@prometheus ~]#cd /etc/consul/ [root@prometheus /etc/consul]#consul agent -dev -ui -data-dir=/consul/data/ -config-dir=/etc/consul/ -client=0.0.0.0 ...... #参数解析 consul agent #使用agent代理的方式来开启 -dev #开发者模式 -ui #启用ui界面 -data-dir #数据文件的位置 -config-dir #consul的配置文件位置 -client #监听的客户端为所有
编辑 /etc/consul 目录下的 prometheus-servers.json 配置文件
[root@prometheus ~]#vim /etc/consul/prometheus-servers.json { "services": [ { "id": "prometheus-server-node01", "name": "prom-server-node01", "address": "192.168.10.20", "port": 9090, "tags": ["prometheus"], "checks": [{ "http": "http://192.168.10.20:9090/metrics", "interval": "5s" }] } ] } [root@prometheus ~]#consul reload Configuration reload triggered [root@prometheus ~]#netstat -antp |grep consul tcp 0 0 127.0.0.1:8300 0.0.0.0:* LISTEN 64781/consul tcp 0 0 127.0.0.1:8301 0.0.0.0:* LISTEN 64781/consul tcp 0 0 127.0.0.1:8302 0.0.0.0:* LISTEN 64781/consul tcp 0 0 127.0.0.1:45987 127.0.0.1:8300 ESTABLISHED 64781/consul tcp 0 0 127.0.0.1:8300 127.0.0.1:45987 ESTABLISHED 64781/consul tcp6 0 0 :::8600 :::* LISTEN 64781/consul tcp6 0 0 :::8500 :::* LISTEN 64781/consul tcp6 0 0 :::8502 :::* LISTEN 64781/consul
先终止 Prometheus 服务,修改配置文件
[root@prometheus ~]#ps aux|grep prometheus root 63526 0.3 2.4 1114924 94196 pts/1 Sl+ 12:10 0:22 ./prometheus --config.file=./file_sd/prometheus.yml root 64823 0.0 0.0 112728 976 pts/2 S+ 14:04 0:00 grep --color=auto prometheus [root@prometheus ~]#kill -9 63526 [root@prometheus ~]#ps aux|grep prometheus root 64826 0.0 0.0 112728 976 pts/2 S+ 14:04 0:00 grep --color=auto prometheus [root@prometheus ~]#cd /usr/local/prometheus-2.27.1.linux-amd64/ [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#mkdir consul_sd [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#ls console_libraries consoles consul_sd data file_sd LICENSE nohup.out NOTICE prometheus prometheus.yml promtool [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#cd consul_sd/ [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64/consul_sd]#wget http://101.34.22.188/consul/prometheus/prometheus.yml [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64/consul_sd]#cat prometheus.yml # my global config # Author: MageEdu <mage@magedu.com> # Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/ global: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s). # Alertmanager configuration alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. consul_sd_configs: - server: "192.168.10.20:8500" tags: - "prometheus" refresh_interval: 2m # All nodes - job_name: 'nodes' consul_sd_configs: - server: "192.168.10.20:8500" tags: - "nodes" refresh_interval: 2m #注意修改 IP #指定配置文件位置运行 Prometheus,可以 nohup ... & 后台运行 [root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#./prometheus --config.file=./consul_sd/prometheus.yml ......
使用浏览器访问 http://192.168.10.20:8500 查看 node01 节点是否加入进去
添加 node 节点再查看
[root@prometheus /etc/consul]#wget http://101.34.22.188/consul/prometheus/nodes.json ...... [root@prometheus /etc/consul]#cat nodes.json { "services": [ { "id": "node_exporter-node01", "name": "node01", "address": "192.168.10.30", "port": 9100, "tags": ["nodes"], "checks": [{ "http": "http://192.168.10.30:9100/metrics", "interval": "5s" }] }, { "id": "node_exporter-node02", "name": "node02", "address": "192.168.10.40", "port": 9100, "tags": ["nodes"], "checks": [{ "http": "http://192.168.10.40:9100/metrics", "interval": "5s" }] } ] } [root@prometheus /etc/consul]#consul reload Configuration reload triggered
十二、Grafana 部署及模板展示
1. Grafana 概述
-
grafana 是一款基于 go 语言开发的通用可视化工具,支持从不同的数据源加载并展示数据,可作为其数据源的部分储存系统如下所示:
① TSDB:Prometheus、InfluxDB、OpenTSDB 和 Graphit
② 日志和文档存储:Loki 和 Elasticsearch
③ 分布式请求跟踪:Zipkin、Jaeger 和 Tenpo
④ SQLDB:MySQL、PostgreSQL 和 Microsoft SQL Server
-
grafana 基础默认监听于 TCP 协议的 3000 端口,支持集成其他认证服务,且能够通过 /metrics 输出内建指标
-
支持的展示方式:
① 数据源(Data Source):提供用于展示数据的储存系统
② 仪表盘(Dashboard):组织和管理数据的可视化面板
③ 团队和用户:提供了面向企业组织层级的管理能力
2. 安装
wget http://101.34.22.188/grafana/grafana-7.3.6-1.x86_64.rpm yum install -y grafana-7.3.6-1.x86_64.rpm systemctl enable grafana-server && systemctl start grafana-server netstat -nuptl|grep 3000
浏览器访问 http://IP:3000,默认账号密码:admin admin
-
-
Zabbix深度监控:多款开源工具构建企业监控新架构
2022-04-21 14:20:39由于公司业务平台的网络环境苛刻,以Zabbix server为核心开发设计一套适应性强的监控运维境更强的方案,不仅能满足当下的需求还能方便后续扩展。
感谢作者方傅皓敏、傅皓樑供稿!欢迎投稿分享你的使用经验。-
Zabbix5.0、6.0中文手册译者
-
就职于某知名金融公司,从事于运维架构领域相关工作,负责公司AIOPS架构方面工作。
-
对于开源监控、数据库、分部署存储等方面有丰富的实践经验。
【背景】由于公司业务平台的网络环境苛刻,以Zabbix server为核心开发设计一套适应性强的监控运维境更强的方案,不仅能满足当下的需求还能方便后续扩展。写这篇文档的初衷希望遇到类似环境的同学有一个参考,在碰到严格、复杂的网络环境,数量庞大机器管理,如何能够利用 Zabbix 的特性做到深度监控。
需要面对的挑战
-
端口受限,我们的网络环境非常苛刻,节点系统对外只开放访问 22、80(部分),服务端有 80、443 端口。
-
带宽受限,服务端、节点系统分布在不同区域,连接靠一根多个系统公用千 M 光纤,在保证监控完整的同时不能影响业务。
-
数量庞大,目前近万台节点,还在不断在增加,监控项 30W+。
-
如何统一管理,如何批量部署客户端、更新监控项配置。
-
监控数据如何写入 Zabbix,zabbix server 是否扛得住。
-
什么数据库才能抗住这么大数据量,后面如何扩展。
终版配置环境
-
Zabbix5.4 server*1。
-
TiDB 分布式数据库,TiDB 采用 TiDB3、tikv3、pd*3。
-
RabbitMQ*1。
-
Jenkins server1, Jenkins node3。
脚本和客户端采用 python 和 go 编写。
终版监控架构图
架构说明
- 监控模块,数据从右往左,agent->server->rabbitmq->脚本处理->ZabbixServer(ZabbixApi)->Zabbix 数据库(Tidb)。
- Agent 部署模块,从 server 提取当前 agent 注册清单->并入 agent 总清单->对比 agent 和总清单的差异,对于那些没有安装 agent 主机通过 ssh 协议远程连接上进行执行署脚本。
解决问题
第一阻力:端口受限,只能用 22、80,那么如何部署 zabbix agent 和 zabbix server,为什么不用的 zabbix 分布式让 zabbix agent 主动上报,而采用当前的架构?
解决方案:
目前用的最多 zabbix 分布式如下图,那为什么我们不用呢?zabbix agent 上报数据需要访问 zabbix proxy 10051 端口,通常整个环境也是在一个局域网内亦或者整个网络环境可以调控。
而我们的网络环境如下,环境限制问题有:-
客户端只能和网关进行相连,中心开放的端口只有 80,客户端只开放 80,443,22。
-
因为中心机房网关是单线光前通往 agent 所在地,同时网关也用于其他业务,对于带宽的要求也要进一步压缩。
-
Zabbix agent 包都比较大,远程下发包的流量也会影响带宽的使用。
从这几方面考虑无法通过 zabbix agent 进行上报数据方式。
通过 go 编写 ws agent 主动上报,这样只要 ws server 端开 80 端口就能解决此问题,go 的 agent 压缩后只有 3M,可以解决包过大传输的问题和 3、4 问题,演变的数据上报架构如下。
- Server 是使用 go 写的 websocket 服务端简称 ws,agent 上部署了 2 个服务(webscoket 客户端和监控服务都是用 go 自己写的)。
- 客户端上的监控服务通过本地的配置文件会不断异步执行监控项存储至内存中,客户端上的 ws agent 也可以执行 ws server 下发的命令。
- 通过 jenkins 定时任务发送给 ws server 让其转发送给所有 ws agent,上报自身监控数据给 ws server,后者将数据存放至 rabbitmq 的监控项数据队列中,这里要说明一下,rabbitmq 队列要设置 TTL,不然一旦消费者挂了数据囤积后会把 mq 内存给打满了,这里我们对 ws server、消费者都通过脚本进行监测使其能够自愈。
第二阻力:数据在 mq 中如何消费到 zabbix 中的近万台主机的监控项中呢,采用什么方式?
解决方案:
-
RabbitMQ 和 zabbix server 都在都在同一网络中,这样网络限制就会小很多,这当中第一个要解决的是如何创建监控项,因为监控项都是不定式的,例如多个磁盘,多个服务等,这样只能采用自动发现,常用的自动发现 2 种:一种通过自制脚本创建自动发现监控项,这种一般都是定式的,已经知道有哪些监控项,如知道目前主机上有 3 个磁盘,通过自动发现就可以节省每个主机上手动创建 3 个监控项,还有一种通过在 zabbix agent 主机执行脚本获取待创建监控项队列,
-
我们使用的是第三种通过 zabbix sender 发送给 zabbix server 数据的方式创建监控项例如:
zbx_sender -z zabbix_server的ip -s hostip -key 自动发现的key -o {“data”:[“#{ITEM_NAME}”:“监控项名字”,”#{ITEM_KEY}”:“监控项key”]}
这个是 zabbix 自带的命令,可以使用 python、go、java 等语言自己写一个,我们是用 python 写的。第一个问题解决了,下面就是第二个自动发现的监控项都有存活周期,这个周期如何更新,例如:自动发现设置 7 天后删除,那 7 天后失效了怎么办,经过测试上面创建监控项命令对存在的监控项再次创建就会更新监控项存活时间,例如昨天创建的监控项到今天还有 6 天就要被删除了,那今天再次创建监控项就会从今天开始计时往后延长 7 天。最后一个问题就是插入数据了,这个比较容易解决,命令提供在下面,在这里我们发现一个坑不知道大家有没有注意,使用 zbx_sender 时发送的数据时间是执行命令时的,而监控项数据在客户端采集到执行命令会有时间差,这个问题在自制 zab_sender 中已经解决,里面有个参数是 value_clock,脚本网上可以找到,看似问题都解决了其实不然。插入监控项数据命令。
zbx_sender -z zabbix_server的ip -s hostip -key 监控项key -o 监控项值
我们的监控项数量有30W+,相信大家的数量也不会少,我们 agent 完成后大约有 100W+的监控项,那如果监控项间隔为 5 分钟,相当于每次创建监控项任务要 5 分钟发送 100W 次,zabbix server 的 lld 进程最多只能开启 100 个,发送命令可以分布式多线程、多进程来发送,但是接收只有 1 个 zabbix server,我们运行到后面 zabbix server 就出现不会执行队列(创建监控项、更新监控项、插入数据)了,队列全部溢出。
对于这个问题我们尝试了 以下2 种方式,虽然全部失败但是也积累了经验。- 双 zabbix server 模式
这个模式查了相关文档没人用过,使用后会产生 2 个告警,查了源码和相关文档后找出原因,监控项数据发送给 zabbix server 后,zabbix server 会匹配对应监控项的触发器规则,如果匹配后发送给数据库,这样就不难理解会出现 2 个告警了,几个 zabbix server 就会有几个 zabbix server,这样问题还难不倒我们,一个 zabbix server 接收监控项数据,一个 zabbix server 接收创建监控项及更新监控项,但是就是这样对于大量更新监控项也扛不住,通过分析 lld 大部分工作在于更新监控项存活时间,从日志跟踪中找到下面的 sql,而创建监控项通常就创建一次,所以只要解决了这个问题就完美了。
update item_discovery set lastcheck=1624511695 where itemid=1674491
通过分析 zabbix server log 每一个触发更新监控项会输出 133 行日志,至少有 50 个以上的动作,那 100W 监控项的工作量可想而知了,如果采用批量 update 直接对数据库进行操作就可以解决这个问题了。解决方法如下,在消费监控项数据时把对应节点监控项输出一份到监控项需更新队列中,通过脚本汇聚这些监控项与 zabbix 数据库 items 表进行关联取差集得到需要更新的监控项 id,然后使用 update 批量更新,sql 如下,item_free 表为关联后取得 itemid 写入表中,不然不好操作:
Update item_discovery set lastcheck=UNIX_TIMESTAMP(NOW()),ts_delete=UNIX_TIMESTAMP(NOW())+(7*24*3600) where itemid in (select itemid from item_free)
2.zabbix proxy 模式zabbix proxy 不支持 lld,所以发送创建监控项数据后,不会创建监控项,查看配置文件就没有 lld 的进程,查了下原理也释然,zabbix proxy 是定时读取 zabbix server 的配置数据保存在 zabbix proxy 数据库中,如果能够创建监控项信息,那多个 zabbix proxy 数据上传时会产生数据冲突。
第三阻力:什么数据库才能抗住这么大数据量,后面如何扩展?
我们数据库从 mysql->postgresql->tidb 不断进行迭代,从 mysql 说起吧,现在还在 mysql 的通常都是分表分库的方式,单标 1000W 已经影响性能了,当初 mysql 优化到极限单标 9000W 数据,查询 3 秒,面对现在动不动几亿的数据量实在扛不住,postgresql 是我们上一代的 zabbix server 数据库,单表性能没得说,目前各个 zabbix 场景下用的最多的就属他了,但是 pg 是单点的不能用于扩展,看着每天增加的指标量,数据阶梯式增长,在这种情况下分布式数据库是必选的方案,tidb 是开源的分布式数据库,想要扩展性能可以通过横向扩节点的方式,简单容易上手、社区活跃、官方解答问题非常积极,对于我们运维人员是一个福音,再更新数据库后虽然问题很多,但是大势所趋目的办法。
碰到的问题
问题 1:zabbix server 日志排查问题?
我们的架构核心是通过 zabbix_sender 发送 zabbix_server 创建监控项、更新监控项、更新监控项值,在更新自动发现监控项存活和创建监控项时遇到 zabbix_server 处理不过来,具体的排查通过查看 zabbix server 的 lld 日志来判断,这里如果直接打开 debug 日志满屏刷无法定位问题,通过设置日志文档来打开 lld 日志输出,具体参考:https://www.zabbix.com/documentation/5.0/manpages/zabbix_server
问题 2:如何快速更新自动发现监控项存活?
监控项数据增加监控项更新操作就会非常多,统计了下有 133 行日志,创建 lld 监控项多好几倍,自动发现(lld)都压在 zabbix_server 上,通过日志发现一个监控项的更新执行逻辑步骤非常多,那在多并发的情况下 zabbix_server lld 进程数量就 100,大量的 update 可能还会触发相互锁的问题,而 zabbix proxy 还不支持 lld 进程,通过日志发现更新最终就是执行一个 updatesql,如下:
update item_discovery set lastcheck=1624511695 where itemid=1674491
思索后通过把需要更新监控项聚合后通过 sql 批量更新,直接对数据库操作不仅速度更快,还大大减少了 zabbix server 的压力,sql 操作如下,对统计后的 itemid 批量更新。
Update item_discovery set lastcheck=UNIX_TIMESTAMP(NOW()),ts_delete=UNIX_TIMESTAMP(NOW())+(7*24*3600) where itemid in (select itemid from item_free)
参考资料
zabbix 5.4 编译安装
# 前置库安装 yum install unixODBC-devel mysql-devel net-snmp-devel libxml2-devel libcurl-devel libevent-devel gcc -y useradd zabbix #安装zabbix5.4 cd /opt/zabbix-5.4/zabbix-5.4.0/ ./configure --prefix=/usr/local/zabbix --sysconfdir=/etc/zabbix/ --enable-server --enable-agent --enable-ipv6 --with-net-snmp --with-libcurl --with-mysql --with-libxml2 make && make install
Zabbix官方工具书发布,总结众多实践案例的经验和技巧,适用于进阶用户!欢迎阅读。
往期推荐
-
-
全能的监控视频播放软件
2014-11-14 11:17:52一个全格式,比较万能的视频监控播放器,这个软件主要针对公安、警察等行业在案件侦查观看视频过程中用,更可以同时将一段视频分成多段来同时观看。大大节省了时间,提高了侦查效率。 -
zabbix 监控过程详解
2021-03-13 15:51:51监控过程详解 1、修改密码及中文版 按如上操作即可,选择中文以后,点击下面的update即可更新成功 为了安全起见修改密码 修改完成后同样点击更新即可。 2、创建主机及主机群组 1、定义一个主机群组 2、添加...监控过程详解
1、修改密码及中文版
按如上操作即可,选择中文以后,点击下面的update即可更新成功
- 为了安全起见修改密码
修改完成后同样点击更新即可。
2、创建主机及主机群组
1、定义一个主机群组
2、添加主机
- 当然,上面有很多选择卡,有一个加密:
- 设置完成后,点击添加。添加的主机已经出现在列表中
- 同样的把node2节点添加进来:
3、监控项 (items)
1、 介绍
-
点击 node1 的监控项,即可创建监控项,首先,创建三个应用集:
-
应用集一般配合监控项使用,是多个同类型的监控项的分类目录
-
定义监控项
任何一个被监控项,如果想要能够被监控,一定要在 zabbix-server 端定义了能够连接至 zabbix-agent 端,并且能够通过命令获取信息。或者在 agent 端定义了能够让server 端获取命令。一般都是内建的命令,都对应的有其名字,被我们称之为 key。
- 关于key值,可以直接在网页上设置(服务器自动执行),也可以使用命令行命令(手动执行)来获取:
[root@qfedu.com ~]# zabbix_get -s 192.168.37.122 -p 10050 -k "system.cpu.intr"
- 在 agent 端,也可以使用命令来查看 intr 的速率变化:
继续配置监控项:
2、定义一个不带参数的监控项
设置完以后,点击更新,即可加入,并会自动跳转至如下页面
定义完成,回到所有主机,等待5秒,可以看到,node1节点后面的选项已经变成绿色:
回到仪表盘,可以看到,监控项有一个处于启用状态:
点击最新数据,选择要查看主机,应用一下,就可以看到数据状态:
可以看到,还有一个图形页面,点进去则可以看图形的分布:
-
事实上,需要关注的指标有很多种,一一添加进来即可。
-
以上定义的监控项是很简单的,指定一个
key
即可,但是有些监控项是带有参数的,这样一来,监控项就有更多的灵活性。接下来,简单说明需要带参数的监控项:
3、定义一个带参数的监控项
-
[] 就是需要参数的意思,里面的值即为参数
-
<> 为不可省略的。
我们就以这个例子来说明:
-
if 表示是接口名;
-
表示是那种模式,包括但不限于:packets(包)、bytes(字节)、errors(错误)、dropped(丢包)、overuns等等(上述内容通过 ifconfig 查看)
设置一个监控值:
- 通过命令行来查看:
[root@qfedu.com~]# zabbix_get -s 192.168.37.122 -p 10050 -k "net.if.in[ens33,packets]"
- 查看网页的显示情况:检测中 —> 最新数据 —> Network Interface Stats(图形)
中文乱码解决方法
- Zabbix监控页面中文显示异常,具体为显示为方块,如图所示。
1、查找zabbix安装目找到字体具体位置。#查找zabbix安装位置 [root@qfedu.com~]# whereis zabbix zabbix: /usr/lib/zabbix /etc/zabbix /usr/share/zabbix [root@qfedu.com~]# ls /usr/share/zabbix/ actionconf.php app charts.php hostinventories.php items.php report2.php styles adm.gui.php applications.php conf host_prototypes.php js report4.php sysmap.php adm.housekeeper.php audio conf.import.php host_screen.php jsLoader.php robots.txt sysmaps.php adm.iconmapping.php auditacts.php correlation.php hosts.php jsrpc.php screenconf.php templates.php adm.images.php auditlogs.php discoveryconf.php httpconf.php latest.php screenedit.php toptriggers.php adm.macros.php browserwarning.php disc_prototypes.php httpdetails.php local screen.import.php tr_events.php adm.other.php chart2.php favicon.ico image.php locale screens.php trigger_prototypes.php adm.regexps.php chart3.php fonts images maintenance.php search.php triggers.php adm.triggerdisplayoptions.php chart4.php graphs.php img map.import.php services.php usergrps.php adm.triggerseverities.php chart5.php history.php imgstore.php map.php setup.php users.php adm.valuemapping.php chart6.php host_discovery.php include overview.php slideconf.php zabbix.php adm.workingtime.php chart7.php hostgroups.php index_http.php profile.php slides.php api_jsonrpc.php chart.php hostinventoriesoverview.php index.php queue.php srv_status.php #字体文件位置 [root@qfedu.com~]# ls /usr/share/zabbix/fonts/ graphfont.ttf [root@qfedu.com~]# cd /usr/share/zabbix/fonts/ [root@server fonts]# pwd /usr/share/zabbix/fonts [root@server fonts]# ls -l 总用量 0 lrwxrwxrwx. 1 root root 33 3月 25 15:24 graphfont.ttf -> /etc/alternatives/zabbix-web-font
采用 winscp/xftp等工具将 Windows 中文字体上传到 /usr/share/zabbix/fonts/ 文件夹。本文中文字体为宋体。字体权限修改后截图如下所示:
切换至/etc/alternatives 目录查看软链接。
- 删除旧软链接并新建。也可以修改为其他中文字体,例如仿宋或者微软雅黑。
# 删除旧软链接 [root@quedu.com fonts]# rm -f /etc/alternatives/zabbix-web-font # 新建软链接 [root@quedu.com fonts]# ln -s /usr/share/zabbix/fonts/simsun.ttc /etc/alternatives/zabbix-web-font
- 刷新浏览器页面即可,如果显示异常,请重新启动 zabbix-server 服务。
[root@quedu.com fonts]# systemctl restart zabbix-server
正常显示字体如图所示。
4、快速定义类似指标
-
要定义一个类似的指标,直接选择克隆,然后简单的修改参数即可。
-
就以定义的 net.if.in[ens33,packets] 为例,如果我们想要在定义一个
out
的进行如下操作即可:
如果要以字节为单位需要定义的话,进行同样的操作:
-
如果有需要的话也可以把 byte 再克隆成out。
-
可以看一下,已经定义的指标:
-
进入检测中 —> 最新数据,可以看到,我们定义的监控项都已经有值了:
5、删除监控项
- 如果有一个监控项,用不上了,就可以删除掉。但是如果你直接删除的话,默认数据是会留下的,所以要先清除数据,然后再删除,具体操作步骤如下:
6、监控项存储的值
对于监控项存储的值,老一点的版本只有以下三种方式:
-
As is: 不对数据做任何处理(存储的为原始值)
-
Delta:(simple change)(变化),本次采样减去前一次采样的值的结果
-
Delta:(speed per second)(速率),本次采样减去前一次采样的值,再除以经过的时长;
在3.4版本以后有了更多的表现形式:
4、触发器(trigger)
1、简介
当采集的值定义完了以后,就可以来定义触发器了。触发器的定义是:**界定某特定的item采集到的数据的非合理区间或非合理状态。通常为逻辑表达式。**逻辑表达式(阈值):通常用于定义数据的不合理区间,其结果如下:
-
OK (不符合条件):正常状态 --> 较老的zabbix版本,其为FALSE;
-
PROBLEM(符合条件):非正常状态 --> 较老的zabbix版本,其为TRUE;
评定采样数值是否为合理区间的比较稳妥的方法是——根据最后N次的平均值来判定结果;这个最后N次通常有两种定义方式:
-
最近N分钟所得结果的平均值
-
最近N次所得结果的平均值
触发器存在可调用的函数:
-
nodata() #是否采集到数据,采集不到则为异常
-
last() #最近几次
-
date() #时间,返回当前的时间,格式YYYYMMDD
-
time() #返回当前的时间,HHMMSS格式的当前时间。
-
now() #返回距离Epoch(1970年1月1日00:00:00UTC)时间的秒数
-
dayofmonth() #返回当前是本月的第几天
注:能用数值保存的就不要使用字符串
2、触发器表达式
基本的触发器表达式格式如下所示
{<server>:<key>.<function>(<parameter>)}<operator><constant>
- server:主机名称;
- key:主机上关系的相应监控项的key;
- function:评估采集到的数据是否在合理范围内时所使用的函数,其评估过程可以根据采取的数据、当前时间及其它因素进行;
- 目前触发器所支持的函数有avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、nodata、now、sum等
- parameter:函数参数;大多数数值函数可以接受秒数为其参数,而如果在数值参数之前使用“#”做为前缀,则表示为最近几次的取值,如sum(300)表示300秒内所有取值之和,而sum(#10)则表示最近10次取值之和;
- 此外,avg、count、last、min和max还支持使用第二个参数,用于完 成时间限定;例如,max(1h,7d)将返回一周之前的最大值;
- 表达式所支持的运算符及其功能如下图所示:
3、定义一个触发器
查看一下 rate of packets(in) 的值,并以其为标准确定我们的非正常的值:
-
图中最大值为74,最小值为4,平均值为24。这样的话,可以定义50以上的都是非正常的值。
-
定义一个触发器:进入:配置 —> 主机 —> node1 —> 触发器 —> 创建触发器
表达式可以直接点击右侧的添加,然后定义自己所需的内容,即可自动生成:
生成完毕后,我们就点击页面下方的添加,即成功定义了一个触发器,同时页面自动跳转:
查看定义了触发器的监控项:
- 看到里面就有了一根线,就是定义的值,超过线的即为异常状态,看起来非常直观。现在即使超过了这根线,也仅仅会产生一个触发器事件而不会做其他任何事。因此,需要去定义一个动作(action)。
4、触发器的依赖关系
-
触发器彼此之间可能会存在依赖关系的,一旦某一个触发器被触发了,那么依赖这个触发器的其余触发器都不需要再报警。
-
多台主机是通过交换机的网络连接线来实现被监控的。如果交换机出了故障,我们的主机自然也无法继续被监控,如果此时,所有主机统统报警……想想也是一件很可怕的事情。要解决这样的问题,就是定义触发器之间的依赖关系,当交换机挂掉,只有自己报警就可以了,其余的主机就不需要在报警了。这样,也更易于我们判断真正故障所在。
-
注意:目前zabbix不能够直接定义主机间的依赖关系,其依赖关系仅能通过触发器来定义。
-
定义一个依赖关系:打开任意一个触发器,上面就有依赖关系,我们进行定义即可:
由于当前只定义了一个触发器,就不演示了,过程就是这样~添加以后点击更新即可。触发器可以有多级依赖关系,比如我们看下面的例子:
5、定义动作(action)
1、 简介
-
需要去基于一个对应的事件为条件来指明该做什么事,一般就是执行远程命令或者发警报。
-
有一个告警升级的机制,所以,当发现问题的时候,一般是先执行一个远程操作命令,如果能够解决问题,就会发一个恢复操作的讯息给接收人,如果问题依然存在,则会执行发警报的操作,一般默认的警报接收人是当前系统中有的 zabbix 用户,所以当有人需要收到警报操作的话,我们则需要把它加入我们的定义之中。
-
每一个用户也应该有一个接收告警信息的方式,即媒介,就像我们接收短信是需要有手机号的一样。
-
每一个监控主机,能够传播告警信息的媒介有很多种,就算我们的每一种大的媒介,能够定义出来的实施媒介也有很多种。而对于一个媒介来说,每一个用户都有一个统一的或者不同的接收告警信息的端点,我们称之为目标地或者目的地。
综上为了能够发告警信息,
-
第一,我们要事先定义一个媒介,
-
第二,还要定义这个媒介上用户接收消息的端点(当然,在用户上,我们也称之为用户的媒介)。
系统内建的媒介类型:
这只是基本的媒介类型,里面还有更多的细分,以 Email为例:
注意:同一个类型也可以定义多个,以 Email 为例,可以定义一个腾讯的服务器,一个网易的服务器,一个阿里的服务器等等。
2、定义一个媒介(media)
以 Email 为例定义一个媒介:
定义后更新就可以
媒介定义好了,怎么才能够让用户接收到邮件呢?比如让Admin用户接收邮件,应该怎么操作呢?具体步骤如下-
进入 管理 —> 用户 —> Admin —> 报警媒介
-
添加一条进来:
添加过后是这样的
- 更新就可以
注意: 一个用户可以添加多个接收的媒介类型。 请使用163/qq邮箱测试
3、定义一个动作(action)
动作是在某些特定条件下触发的,比如,某个触发器被触发了,就会触发动作。现在基于redis来定义一个动作。
- 在 agent 端使用 yum 安装一下 redis:
[root@node1 ~]# yum install redis -y
- 修改配置文件:
[root@node1 ~]# vim /etc/redis.conf bind 0.0.0.0 #不做任何认证操作
- 启动服务检查端口:
[root@node1 ~]# systemctl start redis [root@node1 ~]# ss -nutlp | grep redis tcp LISTEN 0 128 *:6379 *:* users:(("redis-server",pid=5250,fd=4))
1、定义监控项
- 进入 配置 —> 主机 —> node1 —> 监控项(items)—> 创建监控项
填写完毕以后点击下方的添加
- 该监控项已成功添加。
- 查看值:检测中 —> 最新数据
2、定义触发器
-
定义好了监控项以后,定义一个触发器,当服务有问题的时候,才能及时知道:
-
进入 配置 —> 主机 —> node1 —> 触发器(trigger)—> 创建触发器
填写完毕以后点击下方的添加。
-
该触发器已成功添加
-
查看:监测中 —> 最新数据
- 手动关闭 redis 服务来检测一下:
[root@node1 ~]# systemctl stop redis.service
- 进入 监测中 —> 问题
- 看到已经显示的是问题了。并且有持续的时间,当服务被打开,会转为已解决状态:
[root@node1 ~]# systemctl start redis.service
3、定义动作(action)
- 进入 配置 —> 动作 —> 创建动作(注意选择事件源为触发器)
操作添加:
需要在虚拟机上进行两项操作,
-
修改 sudo 配置文件使 zabbix 用户能够临时拥有管理员权限;
-
修改 zabbix 配置文件使其允许接收远程命令。
进行如下操作:
[root@node1 ~]# visudo # 相当于“vim /etc/sudoers” ## Allow root to run any commands anywhere root ALL=(ALL) ALL zabbix ALL=(ALL) NOPASSWD: ALL # 添加的一行,表示不需要输入密码 [root@node1 ~]# vim /etc/zabbix/zabbix_agentd.conf EnableRemoteCommands=1 # 允许接收远程命令 LogRemoteCommands=1 # 把接收的远程命令记入日志 [root@node1 ~]# systemctl restart zabbix-agent.service
- 添加了第一步需要做的事情,重启服务,如果重启不成功怎么办呢?就需要来添加第二步
添加完成以后
操作添加完了,如果服务自动恢复了,可以发送消息来提示:
动作设置完毕,可以点击添加了,添加完成会自动跳转至如下页面:
- 可以手动停止服务来进行测试:
[root@node1 ~]# systemctl stop redis.service
- 到问题页面来查看,发现确实有问题,并且已经解决:
server 端查看是否收到邮件
agent 端查看端口是否开启- 端口正常开启,动作触发已经完成。
补充:可以使用脚本来发送警报,脚本存放路径在配置文件中可以找到,定义为:AlterScriptsPath=/usr/lib/zabbix/alertscripts
- 手动修改一下redis服务的监听端口,这样就不能通过重启服务恢复了:
[root@node1 ~]# vim /etc/redis.conf #port 6379 port 6380 #注释掉原来的端口,更换为新的端口 [root@node1 ~]# systemctl restart redis
- 网页查看状态:进入 监测中 —> 问题,可以看到是报错的:
经过了重启服务以后还是没能把解决问题,就会发邮件告警
把服务端口改回来,然后重启服务。这样,等到问题自动解决了以后,会再次收到邮件:
- 动作设定已经全部测试完成。
6、zabbix可视化
1、 简介
数据日积月累,想要更直观的了解到各项数据的情况,图形无疑是最佳选择。zabbix 提供了众多的可视化工具直观展示,如 graph、screen 及 map 等。前面也看到过一些简单的图形展示。如果想要把多个相关的数据定义在同一张图上去查看,就需要去自定义图形
2、自定义图形(Graphs)
自定义图形中可以集中展示多个时间序列的数据流。支持四种不同形式的图形
-
线状图(normal)
-
堆叠面积图(stacked)、
-
饼图(pie)”
-
分离型饼图(exploded)
设置过程如下:进入 配置 —> 主机 —> node1 —> 图形,选择右上角创建图形:
- 看一看四种状态:
-
主机都可以自定义,一般线型是看的最清晰的,通常会使用这个。克隆一个 packets 来更改为 bytes 用同样的,如果想添加别的内容,也都可以添加的。
-
这里添加了三个图形,我们可以在 监测中 —> 图形 来查看
3、聚合图形(Screens)
- 创建的自定义图形也可以放在一个聚合图里显示,具体的设置方法: 进入 监测中 —> 聚合图形 —> 选择右上角创建聚合图形
可以选择分享:
-
定义好了添加即可
-
定义完成以后,需要编辑一下,来指定保存哪些图:
依次添加即可,添加完成之后:- 因为只有三张图,所以添加的有重复的。
4、幻灯片演示(Slide shows)
-
如果有多个聚合图形想要按顺序展示的话,我们就可以定义一个幻灯片。
-
具体步骤:进入 监测中 —> 聚合图形 —> 右上角选择幻灯片演示 —> 创建幻灯片
- 打开以后显示的是图片1,5s以后会自动切换为图片2。这样就可以实现幻灯片演示,就不需要去手动切换了。
5、 定义拓扑图(Maps)
-
在拓扑图中,可以定义成一个复杂的网络连接图,可以使用一台主机来连接另一台主机,这样的话,就可以查看出到底是哪个链接出了问题。
-
进入 监测中 —> 拓扑图 —> 所有地图 —> Local network(默认就有的)
-
通过 Ping 和 Traceroute 就可以实验我们上述的功能。
7、模板
1、创建模板
-
每一个主机的监控项都很多,一个一个的添加实在是太头疼了,更何况,可能不止一个主机。可以把一个 redis 的监控项添加进一个模板里,这样更方便于我们以后的添加。
-
具体操作:进入 配置 —> 模板 —> 选择右上角创建模板
-
填写完以后,点击下方的添加即可。
-
基于组过滤,就能看到定义的模板:
-
可以向里面添加应用集、监控项、触发器、图形等等,添加完成以后,后期再有主机需要添加就直接套用模板即可。
-
需要注意的一点是,现在添加的是模板,所以不会立即采用数据,只有链接到主机上以后,才会真正生效。
2、模板的导入与导出
-
可以直接导入一个模板,在互联网上可以找到很多,导入的步骤如下:
-
创建好的模板也可以导出为文件:
-
任意选中一个准备好的模板,然后页面的最下方就有导出按钮:
-
就可以非常方便的进行应用了
3、模板的应用
-
进入 配置 —> 主机 —> node1 —> 模板,选择要添加的模板了:
点击更新了。成功链接至模板,主机数据就会更新了:
注意: -
一个主机可以链接多个模板,但尽量不要让一个指标被采样两次。
-
如果有多个主机,同时这些主机也在一个主机组里,这样的话,只需要在这个主机组里添加模板,就能够让在主机组里的所有主机进行监控
4、移除模板链接
-
当一个主机的模板不想要用了,可以移除模板链接,
-
具体操作步骤:进入 配置 —> 主机 —> node1 —> 模板,可以把不需要的模板移除:
删除试试看,移除并清理以后,点击更新。就会自动跳转至如下界面: -
模板已经被移除
8、宏(macro)
1、简介
-
宏是一种抽象(Abstraction),它根据一系列预定义的规则替换一定的文本模式,而解释器或编译器在遇到宏时会自动进行这一模式替换。类似地,zabbix基于宏保存预设文本模式,并且在调用时将其替换为其中的文本。
-
zabbix有许多内置的宏,如{HOST.NAME}、{HOST.IP}、{TRIGGER.DESCRIPTION}、{TRIGGER.NAME}、{TRIGGER.EVENTS.ACK}等。
-
详细信息请参考官方文档
2、级别
宏一共有三种级别,分别是全局宏、模板宏、主机宏。不同级别的宏的适用范围也不一样。
-
全局宏也可以作用于所有的模板宏和主机宏,优先级最低。
-
模板宏则可以作用于所有使用该模板的主机,优先级排在中间。
-
主机宏则只对单个主机有效,优先级最高。
3、类型
-
宏的类型分为系统内建的宏和用户自定义的宏。
-
为了更强的灵活性,zabbix还支持在全局、模板或主机级别使用用户自定义宏(user macro)。
-
系统内建的宏在使用的时候需要
{MACRO}
的语法格式,用户自定义宏要使用{$MACRO}
这种特殊的语法格式。 -
宏可以应用在item keys和descriptions、trigger名称和表达式、主机接口IP/DNS及端口、discovery机制的SNMP协议的相关信息中……
-
宏的名称只能使用大写字母、数字及下划线。
-
进一步信息请参考官方文档。
4、定义一个宏
如果想要在监控项(items)上使用宏,就要先去定义一个宏,然后去创建监控项,直接引用定义好的宏即可。具体操作步骤:
1、定义全局宏
- 进入 管理 —> 一般 —> 右上角选择宏
- 全局宏就添加好了
2、定义监控项,调用宏
- 进入 配置 —> 主机 —> 所有主机 —> 监控项 —> 右上角创建监控项
填写完成以后,点击添加。看到这个调用宏的监控项已经添加成功:
查看监控项现在的状态:进入 监测中 —> 最新数据 - 把服务停掉。就会变成 down 的状态
[root@node1 ~]# systemctl stop redis
- 发现监控项是可以正常使用的。
3、修改宏
如果把 node1 节点上的 redis 服务监听端口手动改掉,定义的监控项就不能正常使用了,这样的话,就需要去修改宏。因为只是个例,所以我们不需要去修改全局宏,只用修改模板宏或者主机宏就可以了。
模板宏和主机宏的不同修改操作:
-
模板宏:模板宏的修改,配置 —> 模板 —> redis stats(相应的模板) —> 宏
-
点击添加就可以了。
-
主机宏:主机宏的修改,配置 —> 主机 —> 所有主机 —> node1 —> 宏
点击添加就可以了。
-
Grafana监控系统之Prometheus+Grafana监控系统搭建
2020-08-21 11:06:05Grafana监控系统之Prometheus+Grafana监控系统搭建 本文章内容较长,可通过右上角点击目录快速定位想看的内容 => => 一. 概述 1.1 Grafana介绍 Grafana是一个跨平台的开源的度量分析和可视化工具,可以通过... -
安防天下:智能网络视频监控技术详解与实践.pdf
2014-02-17 11:46:11第1章 视频监控技术概述 1 第2章 模拟视频监控系统 13 第3章 视频编码压缩技术 43 第4章 硬盘录像机(dvr)技术 87 第5章 视频编码器技术 131 第6章 网络录像机(nvr)技术 163 第7章 网络摄像机(ipc)技术 197 第... -
服务器运维监控知识体系
2020-05-15 14:24:57从来没讲过运维,因为我觉得运维这种东西不需要太多的知识面,然后我一个做了运维朋友告诉我大错特错,...当然,对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。 一、监控目标 每个人 -
zabbix 监控介绍
2021-03-13 14:52:05一、监控介绍 你用过哪些监控软件? zabbix 和 nagios、cacti、ganglia 有什么区别? zabbix 有那些好处? zabbix 的监控流程是什么? zabbix 常见监控项有那些? 1、Cacti Cacti 是一套基于 PHP、MySQL... -
Zabbix监控实战-Tomcat监控
2021-03-13 17:40:15八、Zabbix监控实战-Tomcat监控 1、方法一:开发java监控页面 [root@qfedu.com tomcat8_1]# cat /application/tomcat/webapps/memtest/meminfo.jsp <% Runtime rtm = Runtime.getRuntime(); long mm = rtm.... -
zabbix 监控 mysql
2021-03-13 17:49:38在创建监控项之前要尽量考虑清楚要监控什么,怎么监控,监控数据如何存储,监控数据如何展现,如何处理报警等。要进行监控的系统规划需要对Zabbix很了解,这里只是提出监控的需求。 需求一:监控MySQL的状态,当状态... -
监控工具——Prometheus
2021-11-14 08:41:24监控工具——Prometheus普罗米修斯介绍易于管理监控服务的内部运行状态强大的数据模型强大的查询语言PromQL高效可扩展易于集成可视化开放性架构服务端下载安装安装包测试9090端口配置节点信息添加视图客户端安装安装... -
应用监控工具
2022-04-04 19:03:03系统监控工具、应用监控工具、数据库监控工具。 -
使用 Docker 安装 Zabbix,并配置自定义监控项
2022-04-07 14:57:24Zabbix 可以用来监控各种网络配置,来保证服务器和系统的安全运行。并且 Zabbix 还提供了灵活的通知机制,以此来让系统管理员快速定位/解决存在的各种问题。是一个基于 Web 界面提供的分布式系统监控以及网络监控... -
QT编写的简易安防视频监控系统
2014-07-19 17:46:25说明: 1:此示例只是用来显示视频流 并没有处理存储视频及回放视频功能 2:在打开项目后务必将构建里面的影子构建 Shadow build 取消 3:实时显示视频 视频响应速度比VLC QTAV等播放器快很多倍 ... -
监控zabbix面试题
2021-10-04 16:26:41zabbix的主动监控与被动监控 配置zabbix自定义监控流程 安全组是什么,限制了3306的入规则,客户端还能访问吗 Nagio监控? 服务器一般需要监控哪些项目? 凭借这些项目如何判断服务器的瓶颈? zabbix监控mysql的... -
全球与中国网络性能监控工具市场现状及未来发展趋势
2022-03-10 10:17:43本文研究全球及中国市场网络性能监控工具现状及未来发展趋势,侧重分析全球及中国市场的主要企业,同时对比北美、欧洲、中国、日本、东南亚和印度等地区的现状及未来发展趋势。 根据QYR(恒州博智)的统计及预测,... -
Zabbix企业级分布式监控系统.吴兆松(详细书签)
2016-06-19 07:31:06【大家如果觉得书籍不错,请购买纸质书籍支持作者】《Zabbix企业级分布式监控系统》从运维(OPS)角度对Zabbix的各项功能进行了详细介绍,以自动化运维视角为出发点,对Zabbix的安装配置、自动化功能、监控告警、... -
基础设施与应用监控之指标、监控和报警简介
2018-09-20 12:35:08获得这种洞察力的最佳方法之一是使用强大的监控系统,该系统收集指标,可视化数据,并在事情出现故障时向操作员发出警报。 在本文中,我们将讨论什么是指标,监控和警报。我们将讨论它们为何重要,一般情况下你需要... -
智能安防及视频监控系统
2021-02-23 22:19:50目录 一、智能安防系统 1、智能安防系统介绍 2、安防系统相关工程 ...安防系统主要包括:视频监控系统、入侵报警系统、出入口控制系统、电子巡查系统以及智能停车场管理系统等5个子系统。 AI人工智 -
【Prometheus】Prometheus&Grafana 监控
2021-12-03 17:39:33Grafana 监控 整理自B站多个视频, 如尚硅谷https://www.bilibili.com/video/BV1HT4y1Z7vR 马哥https://www.bilibili.com/video/BV1AK4y1T7QQ 本文尚在整理中,先抛出来给大家参考 第1章 Prometheus 入门 版本:V... -
C#远程监控
2016-02-17 13:33:39C#利用.net remoting技术开发的远程监控程序,可以实现类似远程桌面的功能。 -
prometheus监控JAVA应用(JVM等)并自定义监控指标
2022-05-02 10:30:22prometheus监控JAVA应用(JVM等)并自定义监控指标主体思路将Nacos伪装成Consul快速开始在Spring Cloud Gateway引入jar包Prometheus配置在每个Spring Cloud实例中的配置引入Prometheus监控包暴露每个应用的指标接口... -
《Kubernetes监控篇:Kubernetes集群之微服务JVM内存监控》
2021-07-23 11:42:39三、部署架构 1、监控系统架构图 2、监控系统说明 由于kubernetes集群中有多个业务系统,分别部署在不同的namespace空间,针对不同的监控类型数据,如主机资源监控数据、容器监控数据、应用程序监控数据,分别采用... -
HDFS 监控背后那些事儿,构建 Hadoop 监控共同体
2021-02-24 14:42:05运维开源最佳实践 Hadoop 分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。... HDFS 是 Hadoop 生态的一部分,监控方案不仅需适用 HDFS,其他组件如 Yarn、H... -
如何监控Nginx(看完这篇就会了)
2021-08-16 15:17:59注意: 这两个是必须要加在zabbix监控,加触发器有问题及时告警。 二、监控的主要指标 即主要监控对象: 1、基本活跃指标 名称 描述 指标类型 Accepts (接受) NGINX 所接受的客户端连接数 资源: 功能 -
基于Android平台的监控端和被监控端系统
2022-04-20 14:06:56CameraViewer 视频监控系统-监控端 简介 该系统分为3个部分,监控端、被监控端、中转服务器。...当被监控端无法暴露端口,则监控端和被监控端都连接到一个中转服务器上,监控端发出的指令先发给服务器,