前言

本篇文章介绍 k8s集群中部署 prometheus、grafana、alertmanager，并且配置 prometheus 的动态、静态服务发现，实现对容器、物理节点、service、pod 等资源指标监控，并在Grafana 的 web界面展示 prometheus 的监控指标，然后通过配置自定义告警规则，通过 alertmanager 实现 qq、钉钉、微信报警。

 

Prometheus 监控工具介绍

Prometheus是一个最初在SoundCloud上构建的开源系统监视和警报工具包。
自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有一个非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，可以独立于任何公司进行维护。为了强调这一点，并澄清项目的治理结构，Prometheus 于2016年加入 云计算本地计算基金会，作为继Kubernetes之后的第二个托管项目。

https://prometheus.io

https://github.com/prometheusicon-default.png?t=N7T8https://github.com/prometheus

Download | Prometheus

 

特征

Prometheus的主要特点是：

  • 多维数据模型：由度量名称和键值对标识的时间序列数据
  • 支持多种exporter采集数据
  •  PromQL：一种灵活的查询语言，可以利用多维数据完成复杂的查询
  •  不依赖分布式存储，单个服务器节点可直接工作（不需要安装数据库，直接使用即可，内置集成了数据库不需要重新的部署）
  •  基于HTTP的pull方式采集时间序列数据
  •  推送时间序列数据通过PushGateway组件支持，目标主机上报数据到PushGateway，普罗米修斯从PushGateway拉取数据，这个是可以跨网段的。
  •  通过服务发现或静态配置发现目标
  •  多种图形模式及仪表盘支持（grafana）
  • 高效的存储，每个采集数据占用3.5bytes左右，300万的时间序列，30s的时间间隔，保留60天，消耗磁盘大约200G
  • 做高可用，对数据进行异地备份。联邦集群，部署多套普罗米修斯，每套普罗米修斯可以在不同的机房，然后将这些普罗米修斯汇总到一个普罗米修斯，那么就可以将各个地方的数据，整体收集上来了。

 

 Prometheus组件与架构

                                                                                                                                                                                            Prometheus 监控工具架构图 

Prometheus生态系统由多个组件组成，其中许多组件是可选的：

  1. 主要的Prometheus server，用于存储时间序列数据。
  2. 用于检测应用程序代码的客户端库。
  3. 用于支持short-lived工作的推送网关(push gateway)。
  4. 针对HAProxy，StatsD，Graphite等服务的exporters。
  5. 一个alertmanager处理警报管理器。
  6. 各种支持工具

 大多数Prometheus组件都是用Go编写的，因此很容易构建和部署为静态二进制文件。

具体组件的作用：

• Prometheus Server：收集指标和存储时间序列数据，并提供查询接口（采集，存储，查询）

• ClientLibrary：客户端库

• Push Gateway：短期存储指标数据。主要用于临时性的任务，各个目标主机可以上报数据到pushgateway,，然后prometheus server统一从pushgateway拉取数据

• Exporters：采集已有的第三方服务监控指标并暴露metrics（类似于zabbix agent，但是exporter有很多种，针对不同的监控指标）

• Alertmanager：从prometheus server端收到alters之后，会进行去重，分组，并且路由到接收方，发出报警，常见的接收方式有：电子邮件，微信，钉钉

• Web UI：简单的Web控制台

普罗米修斯服务端是内置了TSDB的数据库，是存储在本地的文件系统当中。存储了采集被监控端数据指标。

获取指标有两种方式：

  • 一种直接是从pushgateway这里获取被监控指标，这是一个独立的组件，主要完成短周期任务暴露的指标，比如定时任务。（短周期任务不是每分钟都有的指标，可能在运行任务的时候才会产生指标。所以可以将临时的指标汇总到pushgateway，然后有pushgateway统一的暴露给服务端去采集）
  • 另外一种就是主要使用的，持久性的应用，比如nginx，mysql还要微服务jar包，这些都属于持久性运行任务的。

使用这种任务的监控就是采用exporter方式了。会配置exporter这样一个组件，主要是用来采集指标暴露给服务端。

Prometheus 根据配置的作业，直接从数据源pull拉取或者通过中间推送网关(push gateway),获取度量值Metrics。它在本地存储所有获取的样本，并在此数据上运行规则，以从现有数据聚合和记录新的时间序列，或者生成警报。Grafana或其他API使用者可用于可视化收集的数据。

服务端采集好之后就会存储在tsdb数据库当中，可以通过其ui去查看，因为其通过了http服务就可以访问其ui了。在ui上可以通过promql完成数据的查询。（export--->prometheus(TSDB)---->promsql）

告警是由altermanager提供的，在普罗米修斯这里定义告警规则，普罗米修斯这里会周期的评估当前采集的指标是否触发了告警规则，如果触发了会将事件推送给altermanger。altermanger会根据自己相关的逻辑处理后发给接收人，提供email webhook，所以告警是由单独的组件完成的。(告警规则在普罗米修斯里面定义，触发了告警推送给altermanager)

普罗米修斯实现了服务的发现，也就是可以自动的找到被监控端，这个需要在普罗米修斯的配置文件里面去配置。有了服务发现就不要一个一个的去配置了，让被监控端自动纳入监控。

普罗米修斯从目标主机拉取数据的时候有两种方式，一种是静态的，也就是我们部署exporter，静态的采集指标，也可以配置服务发现，自动的发现指标数据。通过服务发现和exporter采集到的数据的方式都是采用了默认的pull方式拉取指标的，也可以使用pushgateway上报到prometheus当中,通过在目标主机上面写脚本的方式。

 

监控指标数据模型

数据模型：

• Prometheus将所有数据存储为时间序列（存储的时候都会记录时间，并且存储到时序的数据库里面，也就是内置的TSDB）

• 具有相同度量名称以及标签属于同一个指标（指标名称是一样，但是标签是不一样的）

• 每个时间序列都由度量标准名称和一组键值对（称为标签）唯一标识，

通过标签查询指定指标。

指标格式  指标名称加上多个标签

<metric name>{<label name>=<label value>,...}

再配置被监控端这里要配置监控谁，在配置被监控端，必须要暴露指标出来，这种指标以https的方式给暴露出来，暴露出来之后在配置文件当中配置被监控端，最后就会被普罗米修斯给采集到，如果以上正确配置

在普罗米修斯的图形界面targets可以看到被监控端，也可以通过指标名称查看采集的数据了。

这个就相当于数据库，可以提供promql来查询数据，并且通过图表绘制出来

Prometheus 部署

• 二进制部署

https://prometheus.io/docs/prometheus/latest/getting_started/     下载地址

• Docker部署

https://prometheus.io/docs/prometheus/latest/installation/

访问地址：http://IP:9090

[root@localhost ~]# ls
anaconda-ks.cfg  prometheus-2.23.0.linux-amd64.tar.gz
[root@localhost ~]# mv prometheus-2.23.0.linux-amd64 /usr/local/prometheus
[root@localhost ~]# cd /usr/local/prometheus/
[root@localhost prometheus]# ls
console_libraries  consoles  LICENSE  NOTICE  prometheus  prometheus.yml  promtool

prometheus 主程序，promtool 检查普罗米修斯的工具，主要是用于检查普罗米修斯配置文件的语法

/usr/local//prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml


[apps@prometheus-uat prometheus]$ cat promtool.sh 
./promtool check config prometheus.yml
[apps@prometheus-uat prometheus]$ ./promtool.sh 
Checking prometheus.yml
 SUCCESS: prometheus.yml is valid prometheus config file syntax

 

 

Prometheus启动

./premetheus -h 命令行常用参数：

• --config.file="prometheus.yml" # 指定配置文件

• --web.listen-address= "0.0.0.0:9090" # 监听地址和端口

• --log.level=info # 日志级别

• --alertmanager.timeout=10s # 与报警组件的超时时间

• --storage.tsdb.path="data/ " # 数据目录

• --storage.tsdb.retention.time=15d # 数据保存时间，默认15天（到时候会在普罗米修斯目录下生成data目录用来保存数据，数据存储时间是15天，会定期的删除，也可以自己设置保存一个月）

 直接启动，查看监听端口

[apps@prometheus-uat prometheus]$ cat  /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus server
Documentation=https://prometheus.io/

[Service]
User=apps
Restart=always
ExecStart=/apps/svr/prometheus/prometheus \
 --config.file=/apps/svr/prometheus/prometheus.yml \
 --storage.tsdb.path=/apps/svr/prometheus/data \
 --storage.tsdb.retention.time=60d \
 --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=20
TimeoutStopSec=20
SendSIGKILL=no
LimitNOFILE=8192

[Install]
WantedBy=multi-user.target

# 指定 Prometheus 的配置⽂件路径。
--config.file=/usr/local/prometheus/prometheus.yml 

 # 设置 Prometheus 存储时间序列数据库（TSDB）的路径。 ⽤于存放Prometheus抓取到的指标数据。
--storage.tsdb.path=/usr/local/prometheus/data

# 配置 Prometheus 的数据保留期限。超过这个时间范围的旧数据将被删除。这个可以根据存储资源和监控需求进⾏调整。
--storage.tsdb.retention.time=60d 

# 允许通过 HTTP 请求的⽅式来更新Prometheus的配置。
--web.enable-lifecycle 


[root@localhost prometheus]# systemctl daemon-reload
[root@localhost prometheus]# systemctl start prometheus
[root@localhost prometheus]# systemctl enable prometheus

可以看到监听的端口是9090 ，[root@localhost ~]# netstat -tpln | grep pr

tcp6       0      0 :::9090                 :::*                    LISTEN      26554/./prometheus

浏览器上访问你的主机IP加端口即可

Alters 如果你在这配置了告警，那么这里会显示告警信息

Graph 根据普罗米修斯的查询语言会给你绘制一个图，这里主要是用于编写promq表达式相关的调试

Status 查看运行状态。在status里面的tragets里面是普罗米修斯监控的目标，默认把自己也监控了，service discovery服务发现可以加入被监控端。这里也可以看到告警规则，Configuration 查看普罗米修斯的配置文件内容

可以看到产生了数据目录，以后就可以对该目录做定期的备份

[root@localhost ~]# cd /usr/local/prometheus/
[root@localhost prometheus]# ls
console_libraries  consoles  data  LICENSE  NOTICE  prometheus  prometheus.yml  promtool
[root@localhost prometheus]# cd data/
[root@localhost data]# ls
01ETPMX68HCBK9BN6DA4KPNPNK  chunks_head  lock  queries.active  wal

promeheus存储数据的方式

历史数据会存放在长串字母以及数字组合的目录中
而近期数据会存放在内存里，让调用更加快捷。同时为了防止断电以及认为不可抗因素导致内存数据清空无法调用近期数据的情况下，会冷备份一份在wal目录下，当断电情况发生，内存被清空以后，会调取wal目录下的内容回复近期数据

 

 

生产环境中的prometheus启动姿势
/root/prometheus-2.11.1.linux-amd64/prometheus --web.listen-address=“0.0.0.0:9090” --web.read-timeout=5m --web.max-connections=512 --storage.tsdb.retention=15d --storage.tsdb.path=“data/” --query.max-concurrency=20 --query.timeout=2m

/root/prometheus-2.11.1.linux-amd64/prometheus 执行文件的绝对路径

--web.read-timeout=5m 请求连接的最大等待时间防止太多的空闲连接占用资源

--web.max-connections=512 最大连接数

–storage.tsdb.retention=15d 开始财局监控数据后会存在内存中和硬盘中对于保留期限的设置，太长的话硬盘和存储会有较大压力，15天比较合适

 --storage.tsdb.path="data/" 存储路径这个比较重要不压迫随便乱放，不要把/目录塞满了

--query.max-concurrency=20 --query.timeout=2m 这两项是针对用户执行prometheus查询的时候做的优化，防止太多的用户同时查询，也防止单个用户执行过大的查询而一直不退出都配置ok以后就相对稳妥。

Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods