第十四篇：监控
2026-06-06 15:16:01
- Cacti：基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。
- Zabbix：企业级高度集成开源监控软件，提供分布式监控解决方案，可监控设备、服务的可用性和性能。
- Open-falcon：由小米启动，用golang和python编写的监控系统。
- Prometheus：由SoundCloud开发，是开源监控报警系统和时序列数据库(TSDB)，使用Go语言开发，为Google BorgMon监控系统的开源版本。
- 简述：Prometheus是加入CNCF的开源监控报警系统和时序列数据库项目，通过不同组件完成数据采集、存储和告警。
- 主要特性：
多维数据模型：时间序列数据通过metric名和键值对区分，所有metrics可设置任意多维标签，数据模型随意，无需刻意设置为以点分隔的字符串，支持聚合、切割和切片操作，支持双精度浮点类型，标签可设为全unicode。
灵活的查询语句（PromQL）：可利用多维数据完成复杂查询。
集成度高：Prometheus server是单独二进制文件，不依赖分布式存储，支持local和remote不同模型。
数据拉取：采用http协议，使用pull模式拉取数据，或通过中间网关推送方式采集数据。
目标发现：监控目标可采用服务发现或静态配置方式。
高效：一个Prometheus server可处理数百万的metrics，适用于以机器为中心的监控以及高度动态面向服务架构的监控。
- Prometheus Server：
Retrieval：获取监控数据。
TSDB：时间序列数据库，具备顺序写入、按时间段删除、有序读取等特点。
HTTP Server：为告警和出图提供查询接口。
- Pull metrics指标采集：
Exporters：Prometheus数据采集组件总称，从目标处搜集数据并转化为Prometheus支持格式，等待中央服务器抓取，用于暴露第三方服务的metrics给Prometheus。
Pushgateway：用于网络不可直达或生命周期短的数据采集job，作为exporter与server端的中转站，汇总多个节点数据后统一推送到server。
- service discovery服务发现：
Kubernetes_sd：支持从Kubernetes中自动发现服务和采集信息。
file_sd：通过配置文件实现服务自动发现。
- Alertmanager单独抽离的告警组件：从Prometheus server端接收alerts后，去除重复数据、分组，并路由到对应接收方式发出报警，常见接收方式有电子邮件、pagerduty、OpsGenie、webhook等。
- 图形化展示：通过ProQL语句查询指标信息并在页面展示，虽自带UI界面，但大部分使用Grafana出图，第三方也可通过API接口获取监控指标。
- Prometheus server定期从配置好的jobs或exporters中拉metrics，或接收来自Pushgateway的metrics，或从其他Prometheus server中拉metrics。
- 默认使用pull方式拉取数据，也可使用pushgateway提供的push方式获取监控节点数据。
- 将获取的数据存入TSDB。
- 使用内置的PromQL查询获取到的监控数据。
- 报警功能由Alertmanager提供，它是Prometheus的告警管理和发送报警组件。
- Prometheus原生图标功能简单，可将数据接入grafana进行统一管理。
- 全局配置：global标签下的配置作用于所有抓取目标，有4种配置：
scrape_interval：拉取targets的默认时间间隔。
scrape_timeout：拉取一个target的超时时间。
evaluation_interval：评估rules的时间间隔。
external_labels：和外部系统交流时添加到数据中的标签。
global: scrape_interval: 15s scrape_timeout: 10s evaluation_interval: 15s - 规则文件配置：rule_files标签下指定一系列rules文件。rule_files: - "rules/simple.rules" - "rules/rules/*.rules"
- 数据源配置：scrape_configs节点下配置拉取的数据。scrape_configs:- job_name: node metrics_path: /metrics scheme: http static_configs: - targets: - 10.1.204.109:9100 labels: instance: service1 - targets: - 10.1.205.235:9100 labels: instance: private- job_name: consul-knowledge metrics_path: /actuator/prometheus scheme: http consul_sd_configs: - server: 10.1.204.79:8500 tag_separator: ',' scheme: http allow_stale: true refresh_interval: 30s services: - knowledge-service - gateway-service
- 告警配置：alerting节点下指定Alertmanager相关配置。alerting: alert_relabel_configs: [ - <relabel_config> ... ] alertmanagers: [ - <alertmanager_config> ... ]
- 服务发现配置：- job_name: kubernetes-nodes kubernetes_sd_configs: - role: node
- 热更新：curl -X POST “http://10.102.74.90:9000/-/reload”
- 优势：
自由开放源代码产品，可任意修改和二次开发，采用GPL协议。
安装和配置简单。
搭建环境简单，基于开源软件构建平台。
完全支持Linux、Unix、Windows、AIX、BSD等平台，采用C语言编码，系统占用小，数据采集性能和速度快。
数据采集持久存储到数据库，便于二次分析。
扩展能力强，轻松实现自定义监控项和数据采集。
- 结构：
Zabbix Server：接收agent发送报告信息的核心组件，组织所有配置、统计数据及操作数据。
database：专用于存储所有配置信息和zabbix收集的数据。
web interface：zabbix的GUI接口，通常与server运行在同一台机器上。
proxy：可选组件，常用于分布式监控环境，代理Server收集部分被监控数据并统一发往Server端。
agent：部署在被监控主机上，收集本地数据并发往Server端或者Proxy端。
- 支持的监控方式：
Zabbix agent checks：分为Zabbix agent（被动模式，客户端等服务器端要数据）和Zabbix agent (active)（主动模式，客户端主动发送数据到服务器端）。
SNMP agent checks：用于监控支持SNMP设备（如打印机、网络设备等）且不能安装agent的设备。
SNMP traps
IPMI checks：利用IPMI监视服务器的物理特性，如温度、电压、电扇工作状态、电源供应以及机箱入侵等。
- 分布式及其适应场景：
zabbix proxy可代替zabbix server收集性能和可用性数据，然后汇报给zabbix server，分担zabbix server压力。
使用proxy是实现集中式和分布式监控的最简单方法。
使用场景：
监控远程区域设备。
监控本地网络不稳定区域。
当zabbix监控上千设备时，减轻server压力。
简化分布式监控的维护。
热门标签
