一、常用监控系统介绍

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.html

PS：
  Nightingale 是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。
  Nightingale 在产品完成度、系统高可用、以及用户体验方面，达到了企业级的要求，可满足不同规模用户的场景，小到几台机器，大到数十万都可以完美支撑。兼顾云原生和裸金属，支持应用监控和系统监控，插件机制灵活，插件丰富完善，具有高度的灵活性和可扩展性。
  Nightingale 是一款分布式高性能的运维监控系统，在 Open-Falcon 的基础上，各核心模块做了大幅优化，引入了滴滴的生产实践经验结合滴滴内部的最佳实践，在性能、可维护性、易用性方面做了大量的改进， 作为集团统一的监控解决方案，支撑了滴滴内部数十亿监控指标，覆盖了从系统、容器、到应用等各层面的监控需求，周活跃用户数千。五年磨一剑，取之开源，回馈开源。夜莺 Fork 自 Open-Falcon，可以把夜莺看做是 Open-Falcon 的下一代。
https://cloud.tencent.com/developer/article/1638839?from=15425

二、运维监控平台设计思路

1. 数据收集模块
2. 数据提取模块
3. 监控告警模块

可以细化为 6 层

第六层:用户展示管理层    同一用户管理、集中监控、集中维护
第五层:告警事件生成层    实时记录告警事件、形成分析图表（趋势分析、可视化）
第四层:告警规则配置层    告警规则设置、告警伐值设置
第三层:数据提取层    定时采集数据到监控模块
第二层:数据展示层    数据生成曲线图展示（对时序数据的动态展示）
第一层:数据收集层    多渠道监控数据

三、Prometheus 的监控体系

系统层监控（需要监控的数据）

1. CPU、Load、Memory、swap、disk i/o、process 等
2. 网络监控：网络设备、工作负载、网络延迟、丢包率等

中间件及基础设施类监控

1. 消息中间件：kafka、redis、RocketMQ 等消息代理/中间件
2. WEB 服务器容器：tomcat、weblogic、apache、php、spring 系列
3. 数据库/缓存数据库：MySQL、PostgreSQL、MogoDB、es、redis

redis 监控内容：

• redis 所在服务器的系统层监控
• redis 服务状态
• RDB AOF 日志监控
  (日志 -》如果是哨兵模式 -》哨兵共享集群信息，产生的日志 -》直接包含的其他节点哨兵信息及 mysql 信息)
• key 的数量
• key 被命中的数据/次数
• 最大连接数 -》redis 和系统
  (系统：ulimit -a。redis：redis-cli 登陆 -》config get maxclients 查看最大连接。)

应用层监控

用于衡量应用程序代码状态和性能

1. 白盒监控：自省指标，等待被下载
2. 黑盒监控：基于探针的监控方式，不会主动干预、影响数据

业务层监控

用于衡量应用程序的价值

1. 如电商业务的销售量，QPS、dau 日活、转化率等。
2. 业务接口：登入数量，注册数、订单量、搜索量和支付量。

四、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

感谢作者方傅皓敏、傅皓樑供稿！欢迎投稿分享你的使用经验。

• Zabbix5.0、6.0中文手册译者

• 就职于某知名金融公司，从事于运维架构领域相关工作，负责公司AIOPS架构方面工作。

• 对于开源监控、数据库、分部署存储等方面有丰富的实践经验。

【背景】由于公司业务平台的网络环境苛刻，以Zabbix server为核心开发设计一套适应性强的监控运维境更强的方案，不仅能满足当下的需求还能方便后续扩展。写这篇文档的初衷希望遇到类似环境的同学有一个参考，在碰到严格、复杂的网络环境，数量庞大机器管理，如何能够利用 Zabbix 的特性做到深度监控。

需要面对的挑战

1. 端口受限，我们的网络环境非常苛刻，节点系统对外只开放访问 22、80（部分），服务端有 80、443 端口。

2. 带宽受限，服务端、节点系统分布在不同区域，连接靠一根多个系统公用千 M 光纤，在保证监控完整的同时不能影响业务。

3. 数量庞大，目前近万台节点，还在不断在增加，监控项 30W+。

4. 如何统一管理，如何批量部署客户端、更新监控项配置。

5. 监控数据如何写入 Zabbix，zabbix server 是否扛得住。

6. 什么数据库才能抗住这么大数据量，后面如何扩展。

终版配置环境

1. Zabbix5.4 server*1。

2. TiDB 分布式数据库，TiDB 采用 TiDB3、tikv3、pd*3。

3. RabbitMQ*1。

4. Jenkins server1, Jenkins node3。

   脚本和客户端采用 python 和 go 编写。

终版监控架构图

架构说明

1. 监控模块，数据从右往左，agent->server->rabbitmq->脚本处理->ZabbixServer（ZabbixApi）->Zabbix 数据库(Tidb)。
2. Agent 部署模块，从 server 提取当前 agent 注册清单->并入 agent 总清单->对比 agent 和总清单的差异，对于那些没有安装 agent 主机通过 ssh 协议远程连接上进行执行署脚本。

解决问题

第一阻力：端口受限，只能用 22、80，那么如何部署 zabbix agent 和 zabbix server，为什么不用的 zabbix 分布式让 zabbix agent 主动上报，而采用当前的架构？

解决方案：

目前用的最多 zabbix 分布式如下图，那为什么我们不用呢？zabbix agent 上报数据需要访问 zabbix proxy 10051 端口，通常整个环境也是在一个局域网内亦或者整个网络环境可以调控。

而我们的网络环境如下，环境限制问题有：

1. 客户端只能和网关进行相连，中心开放的端口只有 80，客户端只开放 80,443,22。

2. 因为中心机房网关是单线光前通往 agent 所在地，同时网关也用于其他业务，对于带宽的要求也要进一步压缩。

3. Zabbix agent 包都比较大，远程下发包的流量也会影响带宽的使用。

从这几方面考虑无法通过 zabbix agent 进行上报数据方式。

通过 go 编写 ws agent 主动上报，这样只要 ws server 端开 80 端口就能解决此问题，go 的 agent 压缩后只有 3M，可以解决包过大传输的问题和 3、4 问题，演变的数据上报架构如下。

1. Server 是使用 go 写的 websocket 服务端简称 ws，agent 上部署了 2 个服务（webscoket 客户端和监控服务都是用 go 自己写的）。
2. 客户端上的监控服务通过本地的配置文件会不断异步执行监控项存储至内存中，客户端上的 ws agent 也可以执行 ws server 下发的命令。
3. 通过 jenkins 定时任务发送给 ws server 让其转发送给所有 ws agent，上报自身监控数据给 ws server，后者将数据存放至 rabbitmq 的监控项数据队列中，这里要说明一下，rabbitmq 队列要设置 TTL，不然一旦消费者挂了数据囤积后会把 mq 内存给打满了，这里我们对 ws server、消费者都通过脚本进行监测使其能够自愈。
   

第二阻力：数据在 mq 中如何消费到 zabbix 中的近万台主机的监控项中呢，采用什么方式？

解决方案：

1. RabbitMQ 和 zabbix server 都在都在同一网络中，这样网络限制就会小很多，这当中第一个要解决的是如何创建监控项，因为监控项都是不定式的，例如多个磁盘，多个服务等，这样只能采用自动发现，常用的自动发现 2 种:一种通过自制脚本创建自动发现监控项，这种一般都是定式的，已经知道有哪些监控项，如知道目前主机上有 3 个磁盘，通过自动发现就可以节省每个主机上手动创建 3 个监控项，还有一种通过在 zabbix agent 主机执行脚本获取待创建监控项队列，

2. 我们使用的是第三种通过 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 种方式，虽然全部失败但是也积累了经验。

1. 双 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官方工具书发布，总结众多实践案例的经验和技巧，适用于进阶用户！欢迎阅读。

往期推荐

某股份制银行如何基于Zabbix实现自主运维和自主可控？

给你加个buff: Zabbix 6.0 Agent 2 !

Zabbix全年在线课录屏

Zabbix学习资料、客户案例申请

监控过程详解

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 —> 宏
  点击添加就可以了。