admin管理员组

文章数量:1529455

Prometheus

  • zibbix
    • Zabbix 组件
  • prometheus 数据模型
  • promethues 安装
    • 配置yum源
    • 环境部署与服务启动
    • 安装prometheus管理
    • 监控node节点安装
    • 查询状态数据
  • 服务发现service discovery
    • 服务发现三种方式：
      • 基于文件服务发现
      • 基于DNS的服务发现
      • 基于 consul/api 的服务发现
  • grafana部署
    • Grafana基础
    • Grafana部署
  • prometheus 告警功能
    • alertmanager 邮箱报警

zibbix

zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。

1、zabbix由zabbix-server服务端和zabbix-agent监控端组成。

2、Zabbix支持的通信方式

*agent (代理) :专用的代理服务方式进行监控,专属的协议,装有zabbix-agent的主机就可以被zabbix-server监控。主动或被动的方式,把数据给到server进行处理。

*ssh/telent: Linux主机支持ssh/telent协议

*SNMP:网络设备路由器、交换机不能安装第三方程序(agent) ,使用简单网络管理协议。大多数的路由交换设备支持SNMP协议。

*IPMI:通过IPMI接口进行监控,我们可以通过标准的IPMI硬件接口,监控被监控对象的物理特征,比如电压,温度,凤扇状态,电源状态等。

IPMI (Intelligent Platform ManagementInterface)
协议被广泛用于服务器监控中,包括采集CPU温度、风扇转速、主板温度,以及远程开关机等等。而且IPMI独立于硬件和操作系统,无论是CPU, BIOS,还是OS出现故障,都不会影响IPMI的工作。因为IPMI的硬件设备BMC (Baseboard ManagementController)是一个独立的板卡,独立供电。

*JMX:通过JMx进行监控, JMX (Java ManagementExtensions,即Java管理扩展) ,监控JVM虚拟机时,使用这种方法也是非常不错的选择。

Zabbix 组件

  1. Zabbix Server: Zabbix软件实现监控的核心程序,主要功能是与zabbixproxies和Agents进行交互、触发器计算、发送告警通知;并将数据集中保存
  1. Database storage:存储配置信息以及收集到的数据
  1. web Interface: Zabbix的GUI接口,通常与server运行在同一台机器上
  1. Proxy:可选组件,常用于分布式监控环境中,一个帮助zabbix server收集数据,分担zabbix server的负载的程序
  1. Agent部署在被监控主机上,负责收集数据发送给Server

prometheus和zabbix 区别

区别prometheuszabbix
发行时间20162012
开发语言goc+php
性能支持万为单位上限10000节点
社区支持与日俱增，不如zabbix应用广、支持成熟、解决方案多
容器支持不仅支持swarm原生集群，还支持K8S，目前为止最好的容器监控解决方案对容器支持比pro较弱
企业支持基本上使用k8S与容器的企业pro是最好的选择传统监控系统中，尤其是在服务器相关监控上，占据绝对
部署难度只有一个核心server组件，一条命令便可启动多种系统，多种监控信息采集方式
		发行时间	开发语言	性能			社区支持

prometheus 2016 go 支持万为单位 与日俱增，不如zabbix
zabbix 2012 c+php 上限10000节点 应用广、支持成熟、解决方案多

				容器支持

promethues 不仅支持swarm原生集群，还支持K8S，目前为止最好的容器监控解决方案
zabbix 对容器支持比pro较弱

				企业支持

promethues 基本上使用k8S与容器的企业pro是最好的选择
zabbix 传统监控系统中，尤其是在服务器相关监控上，占据绝对优势

				部署难度

promethues 只有一个核心server组件，一条命令便可启动
zabbix 多种系统，多种监控信息采集方式

prometheus 数据模型

prometheus仅用键值方式存储时序式的聚合数据,他不支持文本信息

1.其中的"键"成为指标(metric) ,通常意味着cpu速率、内存使用率或分区空闲比例等。

2.同一指标可能适配到多个目标或设备 、因而它使用“标签"作为元数据,从而为metric添加更多的信息描述维度

metric（cpu指标） JOB——NAME

CPU_usage{core='1' , ip='ip地址'} 14.04    key   labels(matedata)  value (样本)

prometheus 每一份样本数据都包含
(1) 时间序列标识：key+labels
(2) 当前时间序列的样本值 value


3.标签还可以作为过滤器进行指标过滤及聚合运算

job 和 target/instance

job ：能够接收 prometheus server 数据scrape targets 每一个可以被监控的系统，成为targets 多个相同的targets的几个成为 job

 instance:实例-targets (类似) ,与target相比, instance更趋近于一个具体可以提供监控数据的实例, 而targets则更像一个对象、目标性质

PromQL, (数据查询语言)—时序数据库中使用的语言:

支持两种向量,同时内置提供了一组用于数据处理的函数

1.即时向量:最近以此时间戳上跟踪的数据指标
即时向量选择器:返回0个1个或多个时间序列上在给定时间截上的各白的一个样本,该样本成为即时样本,时间范围向量:指

2.时间范围内所有时间戳上的数据指标范围向量选择器:返回0个、1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)

promethues 安装

配置yum源

cat > /etc/yum. repos. d/prometheus.repo << EOF

[prometheus] name-prometheus 
baseurl-https://packagecloud.io/prometheus-rpm/release/el/$releasever/$basearch
repo_gpgcheck=1 
enabled=1
gpgkey-https: //packagecloud.io/prometheus-rpm/release/apgkey
https://raw.aithubusercontent.com/lest/prometheus-rpm/master/RPM-GPG-KEY-prometheus-rpm
gpqcheck=1 metadata expire-300
EOF

环境部署与服务启动

安装prometheus管理

//安装prometheus 192.168.78.11
wget  https://github.com/prometheus/prometheus/releases/download/v2.9.2/prometheus-2.9.2.linux-amd64.tar.gz

//我是本地软件包
cd /opt
tar xzvf prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local
cd /usr/local
mv prometheus-2.27.1.linux-amd64/  prometheus


// 启动prometheus

./usr/local/promethues/promethues

ss -natp | grep 9090


浏览器访问：IP：9090   或者  IP ：9090/metrics

监控node节点安装


//安装node_exporter 192.168.78.22 192.168.78.33

wget https://github.com/prometheus/node_exporter/releases/download/v0.18.0/node_exporter-0.18.0.linux-amd64.tar.gz
//我是本地软件包
tar zxvf node_exporter-1.1.2.linux-amd64.tar.gz

mv node_exporter-1.1.2.linux-amd64 /usr/local/node_exporter

cp node_exporter /usr/local/bin/


./node_exporter 

修改 promethues 管理节点 prometheus.yml  配置文件
 - job_name: 'nodes'
    static_configs:
    - targets: 
      - 192.168.78.22:9100
      - 192.168.78.33:9100


//kill -9 刚才启动的promethues的PID，重启promethues

查询状态数据

#可重复查询，观测到有增长
prometheus_http_requests_total


#附加条件（指标过滤器：PromQL）：
prometheus_http_requests_total{code="200"}


#CPU使用总量（所有节点）
node_cpu_seconds_total
#CPU空闲值（所有节点）
node_cpu_seconds_total{mode='idle'}
#指定查看节点
node_cpu_seconds_total{mode='idle',instance="192.168.78.22:9100"}
node_cpu_seconds_total{mode='idle',instance="192.168.78.33:9100"}

#计算过去5分钟内的CPU使用速率
PromQL: irate(node_cpu_seconds_total{mode="idle"}[5m])
解析：
irate：速率计算函数（灵敏度非常高的）
node_cpu_seconds_total:node节点CPU使用总量
mode="idle" 空闲指标
5m:过去的5分钟内，所有CPU空闲数的样本值，每个数值做速率运算


#每台主机CPU 在5分组内的平均使用率
PromQL：(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- avg (irate(node_cpu_seconds_total{mode='idle'}[5m]))by (instance))* 100：CPU 5分钟内的平均使用率

#查询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


服务发现service discovery

服务发现三种方式：


静态配置发现，需要手工更改
 -job_name: 'nodes'
  static_configs:
  - targets:
    - 192.168.78.22:9100 
	- 192.168.78.33:9100

基于文件服务发现

基于文件的服务发现是仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式；
Prometheus Server定期从文件中加载Target信息（pro-server pull 指标 发现机制-job_name 获取我要pull的对象target）
 文件可使用JSON和YAML格式，它含有定义的Target列表，以及可选的标签信息；
 以下第一个配置，能够将prometheus默认的静态配置转换为基于文件的服务发现时所需的配置：
 （prom会周期性的读取、重载此文件中的配置，从而达到动态发现、更新的操作）


配置方式：

#在prometheus工作目录下：
mkdir files_sd  && cd files_sd
mkdir targets 

#在 file_sd 目录下创建

vim 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'.

    file_sd_configs:
    - files:                                               
      - targets/prometheus-*.yaml  
      refresh_interval: 2m 

  # All nodes
  - job_name: 'nodes'
    file_sd_configs:
    - files:                                               
      - targets/nodes-*.yaml  
      refresh_interval: 2m



#在targets目录下 创建 prometheus_server.yaml和nodes_centos.yaml


vim prometheus_server.yaml

- targets:
  - 192.168.78.11:9090
  labels:
    app: prometheus
    job: prometheus

vim nodes_centos.yaml

- targets:
  - 192.168.78.22:9100
  - 192.168.78.33:9100
  - 192.168.78.44:9100
  labels:
    app: node-exporter
    job: node
//  这个添加发现节点IP，就会自动发现节点

#指定配置文件启动
./prometheus --config.file=./files_sd/prometheus.yml

基于DNS的服务发现

基于DNS的服务发现针对一组DNS域名进行定期查询，以发现待监控的目标
查询时使用的DNS服务器由/etc/resolv.conf文件指定；
该发现机制依赖于A、AAAA和SRV资源记录，且仅支持该类方法，尚不支持RFC6763中的高级DNS发现方式

基于 consul/api 的服务发现

consul
一款基于golang开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务  发现和配置管理的功能
提供服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能

#原理：通过定义json文件将可以进行数据采集的服务注册到consul中，用于自动发现
同时使用prometheus做为client端 获取consul上注册的服务，从而进行获取数据

#安装(上传consul_1.9.0版本）
unzip consul_1.9.0_linux_amd64.zip -d /usr/local/bin/


#启动开发者模式
#consul 开发者模式，可以快速开启单节点的 consul服务，具有完整功能，方便开发测试
mkdir -pv /consul/data/
mkdir /etc/consul
consul agent -dev -ui -data-dir=/consul/data/ \
-config-dir=/etc/consul/ -client=0.0.0.0

agent -dev ：运行开发模式（）
agent -server：运行server模式 
-ui ：ui界面
-data-dir ：数据位置
-config-dir ：配置文件位置
/etc/consul : 可以以文件形式定义好的各个services的配置，也可以基于api接口直接配置
-client：监听地址
运用的端口：8500

#另起一个终端，进入/etc/consul目录下，定义prometheus-servers.json
[root@prometheus consul]# cat prometheus-servers.json 
{
  "services": [
    {
      "id": "prometheus-server-node01",
      "name": "prom-server-node01",
      "address": "192.168.78.11",
      "port": 9090,
      "tags": ["prometheus"],
      "checks": [{
        "http": "http://192.168.78.11:9090/metrics",
        "interval": "5s"
      }]
    }
  ]
}

#重载consul 配置文件
consul services register /etc/consul/prometheus-servers.json
consul reload 进行重载

#启动prometheus 

cd /usr/local/prometheus

mkdir consul-sd && cd consul-sd

cat prometheus.yml
.......
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.78.11:8500"
      tags:
      - "prometheus"				#只会抓取tags为prometheus的数据做为指标
      refresh_interval: 2m 
	
  # All nodes
  - job_name: 'nodes'
    consul_sd_configs:
    - server: "192.168.78.11:8500"
      tags:
      - "nodes"						#只会抓取tags为prometheus的数据做为指标
      refresh_interval: 2m 

#指定配置文件启动
cd ../  && ./prometheus --config.file=./consul-sd/prometheus.yml

##此时查看prometheus targets指标，只能看到一个prometheus，因为配置文件中配置了"prometheus"的tag，所以只会抓取pro的
配置

#在/etc/cosul目录下定义nodes.json

[root@prometheus consul]# cat nodes.json 
{
  "services": [
    {
      "id": "node_exporter-node01",
      "name": "node01",
      "address": "192.168.78.22",
      "port": 9100,
      "tags": ["nodes"],
      "checks": [{									#健康检查
        "http": "http://192.168.78.33:9100/metrics",	#定期进行检测，返回200则为健康
        "interval": "5s"
      }]
    },
    {
      "id": "node_exporter-node02",
      "name": "node02",
      "address": "192.168.78.33",
      "port": 9100,
      "tags": ["nodes"],
      "checks": [{
        "http": "http://192.168.78.33:9100/metrics",
        "interval": "5s"
      }]
    }
  ]
}

#consul reload重载，返回prom ui界面查看


##这里使用文件进行注册的，实际环境中应使用的是脚本、工具或者一些服务注册到consul中的，同时是基于consul的api进行注册的。

#同时可以通过consul 注销指定的服务 (1.92版本可使用)
示例:
consul services deregister -id="node_exporter-node02"

consul services register /etc/consul/ndoes.json

###指标抓取的生命周期



grafana部署

Grafana是一款基于go语言开发的通用可视化工具，支持从多种不同的数据源加载并展示数据，可作为其数据源的部分存储系统如下所示

TSDB：Prometheus、IfluxDB、OpenTSDB和Graphit

日志和文档存储：Loki和ElasitchSearch

分布式请求跟踪：Zipkin、Jaeger和Tempo

SQL DB: MySQL、PostgreSQL和Microsoft SQL Server

Grafana基础

默认监听于TCP协议的3000端口，支持集成其他认证服务，且能够通过/metrics输出内建指标；
基本概念
数据源（Data Source）：提供用于展示的数据的存储系统；
仪表盘（Dashboard）：组织和管理数据的可视化面板（Panel）；
团队和用户：提供了面向企业组织层级的管理能力；

Grafana部署

#部署步骤

wget https://mirrors.huaweicloud.com/grafana/7.3.6/grafana-7.3.6-1.x86_64.rpm

yum install grafana-7.3.6-1.x86_64.rpm

#Docker容器运行方式
VERSION=7.3.6
docker run -d --name=grafana -p 3000:3000 grafana/grafana

#账号密码默认为admin,admin 
#grafana默认配置文件目录 /etc/grafana/grafana.ini

#启动
systemctl start grafana-server

#直接访问ip:3000 进入grafana控制台

#grafana模板
https://grafana.com/grafana/dashboards
8919






prometheus 告警功能

Prometheus对指标的收集、存储同告警能力分属于Prometheus Server和AlertManager（通用的组件） 两个独立的组件，前者仅负责基于“告警规则”生成告警通知，具体的告警操作则由后者完成；

Alertmanager负责处理由客户端发来的告警通知

客户端通常是Prometheus Server，但它也支持接收来自其它工具的告警；

Alertmanager对告警通知进行分组、去重后，根据路由规则将其路由到不同的receiver，如Email、短信或PagerDuty等；

目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化

PS:Webhook是一个API概念,webhook是一种web回调或者http的push API.Webhook作为一个轻量的事件处理应用

告警功能概述：
prometheus 对指标的收集、存储与告警能力分属于Prometheus serve和alertmanager两个
独立的组件，pro-server只负责通过“告警规则”生成告警通知，具体告警操作是由alertmmanager完成

告警规则：
是由PromQL编写的布尔值表达式
使用 > < = 与一个常量值，比如80% 进行比较，其返回值为true 或false
prometheus-server 对抓取到的指标序列与告警规则中做为比较的PromQL匹配，则会把此样本值抓取过来作比较
若返回值为true 则认为指标异常，不能满足false，则为正常值
以上表达式为告警规则表达式，示例：
PromQL对应的值为CPU5分钟平均使用率，告警规则表达式则为:
(1- avg (irate(node_cpu_seconds_total{mode=‘idle’}[5m]))by (instance))* 100 > 50%
值为：
40% > 50 % false,系统正常
60% > 50% true,系统异常

通知告警信息
一旦条件表达式为true了就会触发通知信息，送给alertmanager，由aler借助特定服务的API或者访问入口，将此信息发出去
一般称为告警媒介，也可以借助邮件进行告警SMTP

告警功能：
除了基本的告警通知能力外，Altermanager还支持对告警进行去重、分组、抑制、
静默和路由等功能；
分组（Grouping）：将相似告警合并为单个告警通知的机制，在系统因大面积故障而触 发告警潮时，分组机制能避免用户被大量的告警噪声淹没，进而导致关键信息的隐没；
抑制（Inhibition）：系统中某个组件或服务故障而触发告警通知后，那些依赖于该组件或服务的其它组件或服务可能也会因此而触发告警，抑制便是避免类似的级联告警的一种特性，从而让用户能将精力集中于真正的故障所在；
静默（Silent）：是指在一个特定的时间窗口内，即便接收到告警通知，Alertmanager也不会真正向用户发送告警信息的行为；通常，在系统例行维护期间，需要激活告警系统的静默特性；
路由（route）：用于配置Alertmanager如何处理传入的特定类型的告警通知，其基本逻辑是根据路由匹配规则的匹配结果来确定处理当前告警通知的路径和行为；

alertmanager 邮箱报警

#在prometheus-server端 定义告警规则，指定alertmanager 的位置，将告警信息发送给alert处理

tar zxvf alertmanager-0.22.2.linux-amd64.tar.gz -C /usr/local/

ln -s /usr/local/alertmanager-0.22.2.linux-amd64/ /usr/local/alertmanager

#查看默认配置文件
cat /usr/local/alertmanager/alertmanager.yml

route:								#路由信息
  group_by: ['alertname']			#分组 ,
  group_wait: 30s					#分组缓冲/等待时间
  group_interval: 5m				#重新分组时间
  repeat_interval: 1h				#重新告警间隔
  receiver: 'web.hook'				#指定接收人/媒介
receivers:							#receivers 接收人/媒介具体信息
- name: 'web.hook'					
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'
inhibit_rules:						#抑制规则的策略
  - source_match:					#匹配项
      severity: 'critical'			#严重的级别
    target_match:
      severity: 'warning'			#target 匹配warning级别
    equal: ['alertname', 'dev', 'instance']	#符合alertname 、dev、instance

#如果另一个警报正在触发，则禁止规则允许将一组警报静音，如果同一警报已经严重，我们将使用此选项禁用任何警告级别的通知 


#修改配置文件
vim alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_from: *******@qq.com
  smtp_auth_username: ********@qq.com
  smtp_auth_password: ****************
  smtp_require_tls: false
  smtp_smarthost: 'smtp.qq:465'
 
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'email-koubei'
receivers:
- name: 'email-koubei'
  email_configs:
  - to: ********@qq.com
    send_resolved: true


## 启动alertmanager
./alertmanager


##创建prometheus 对接alertmanager配置文件

mkdir alert-config && cd alert-config
mkdir alert_rules
mkdir targets


1.定义targets
2.定义rule告警规则
3. 在prom主配置文件中添加alertmanager字段，定义alertmanager对接位置，定义告警规则文件位置

./prometheus --config.file=./alert-config/prometheus.yml

#修改邮件配置

QQ邮件告警：
prometheus-server ——》定义告警规则（布尔值表达式，以及描述信息），一旦表达式为true，那么会将此告警信息
发送给alertmanager 
alertmanager此时会根据主配置文件中定义的route（告警路由），recver（接收方/告警媒介）进行发送











关闭 节点验证


本文标签： 进阶邮箱阶段参数高级

版权声明：本文标题：Prometheus监控系列-- 进阶阶段 | 高级操作 | 配合Grafana | 邮箱报警 | 参数说明 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dongtai/1726722075a1081908.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。