Prometheus加grafana监控之初探

目录

目录

一、概述

prometheus 的特点

prometheus 相关组件

二、grafana简介

Prometheus安装-图形界面展示

Prometheus metrics概念

metrics的几种类型

Gauges

counters

Histograms

k/v的数据形式

配置Prometheus获取监控数据

三、部署grafana

为grafana配置Prometheus数据源

Grafana 展示 MySQL 的监控数据

告警配置

Grafana+onealert报警

在Grafana中配置Webhook URL

测试CPU负载告警

测试报警

一、概述

Prometheus是一个开源监控系统，它的前身是SoundCloud的告警工具包。从2012年开始，许多公司合组织开始使用Prometheus。该项目的开发人员和用户社区非常活跃，越来越多的开发人员和用户参与到该项目中。目前它是一个独立的开源项目，且不依赖与任何公司。为了强调这点和明确该项目治理结构，prometheus在2016年继kurberntes之后，加入了Cloud Native Computing Foundation

prometheus 的特点

和其他监控系统相比，Prometheus的特点包括：

• 多维数据模型（时序列数据由metric名和一组key/value组成）
• 在多维度上灵活的查询语言(PromQl)
• 不依赖分布式存储，单主节点工作.
• 通过基于HTTP的pull方式采集时序数据
• 可以通过中间网关进行时序列数据推送(pushing)
• 目标服务器可以通过发现服务或者静态配置实现
• 多种可视化和仪表盘支持

prometheus 相关组件

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

• Prometheus 主服务,用来抓取和存储时序数据
• client library 用来构造应用或 exporter 代码 (go,java,python,ruby)
• push 网关可用来支持短连接任务
• 可视化的dashboard (两种选择,promdash 和 grafana.目前主流选择是 grafana.)
• 一些特殊需求的数据出口(用于HAProxy, StatsD, Graphite等服务)
• 实验性的报警管理端(alartmanager,单独进行报警汇总,分发,屏蔽等 )
  promethues 的各个组件基本都是用golang编写,对编译和部署十分友好.并且没有特殊依赖.基本都是独立工作.

二、grafana简介

grafana是一个优秀的数据看板类工具，他提供了强大和优雅的方式去创建、共享、浏览数据。dashboard中显示了你不同metric数据源中的数据。

Grafana是在网络架构和应用分析中最流行的时序数据展示工具，并且也在工业控制、自动化监控和过程管理等领域有着广泛的应用

grafana有热插拔控制面板和可扩展的数据源，目前已经支持绝大部分常用的时序数据库。

Zabbix和Prometheus的区别

和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂。 zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的exporter来直接开箱使用，通过http通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集。 zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据。 界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路。

Prometheus安装-图形界面展示

Download | Prometheus

tar -xvf prometheus-2.38.0.linux-amd64.tar.gz -C /usr/local
mv prometheus-2.38.0.linux-amd64/ prometheus

 启动Prometheus

#两种启动方式，前台启动和后台启动
./prometheus
 
nohup /usr/local/prometheus/prometheus  --config.my-cnf=/usr/local/prometheus/prometheus &

 访问prometheus界面（默认端口9090）

打开的文件描述符数——process_open_fds

在status下的targets就能看到被监控的目标主机采集的数据

 Prometheus组件

这里就是Prometheus的服务端，也就是核心

Prometheus本身是一个以进程方式启动，之后以多进程和多线程实现监控数据收集，计算，查询，更新，存储的这样一个C/S模型运行模式，本身启动很简单

1. prometheus 采用的是 time-series (时间序列)的方式以一种自定义的格式存储在本地硬盘上 ​ prometheus的本地T-S(time-series)数据库以每两小时为间隔来分block(块)存储，每一个块中又分为多个chunk文件（我们以后会介绍chunk的概念)，chunk文件是用来存放采集过来的数据的T-S数据，metadata和索引文件(index)
2. index文件是对metrics(prometheus中一灰K/V采集数据叫做一个metric)和labels(标签)进行索引之后存储在chunk中 chunk 是作为存储的基本单位,index and metadata是作为子集 ​ prometheus平时是将采集过来的数据先都存放在内存之中(prometheus对内存的消耗还是不小的)以类似缓存的方式用于加快搜索和访问当出现当机时，prometheus有一种保拒机制叫做WAL可以讲数据定期存入硬盘中以chunk来表示，并在重新后动时用以恢复进入内存

这里面主要是Prometheus可以集成的服务发现功能

例如Consul

Prometheus采集客户端部分

Prometheus的客户端有两种方式

pull主动拉取的形式

1. pull：指的是客户端（被监控机器）先安装各类已有exporters（由社区组织或企业开发的监控客户端插件）在系统上，之后，exporters以守护进程的模式运行并开始采集数据
2. exports本身也是一个http_server可以对http请求作出响应，返回数据
3. Prometheus用pull这种主动拉的方式（HTTP get）取访问每个节点上exports并采样回需要的数据

push被动推送的形式

1. 指的是在客户端（或者服务器）安装这个官方提供的oushgetway插件
2. 然后，使用我们运维自行开发的各种脚本，把监控数据组织成K/V形式metrics形式发送给pushgetway之后pushgetway回在推送给Prometheus
3. 这种是一种被动的数据采集模式

报警绘图部分

alertmanager是监控和其他商业报警的桥梁，当有数据超过阈值，Prometheus会将报警信息通过alertmanager会将报警再推给其他报警平台，才会实现真正报警，这里不需要多说alertmanage（有很多功能缺陷），而且我们会使用更高级的绘图平台如grafana中，通过这些平台自带的报警系统去实现，而不再用自带的alertmanager。

Prometheus metrics概念

Prometheus监控中对于采集过来的数据同一称为metrics数据。当我们需要为某个系统某个服务做监控，做统计，就需要用到metrics

metrics是一种对采样数据的总称(metrics并不代表某一种具体的数据格式 是一种对于度量计算单的抽象)

metrics的几种类型

Gauges

存储的是当前状态的快照，其关心的是数值本身，因此此类型的数据类型的值可升可降。例如: 使用Gauge数据类型的例子包括队列中元素个数、缓存的内存使用率，活跃的线程数，最后一分钟时间里没秒的平均请求数。

最简单的度量指标，只有一个简单的返回值，或者叫瞬时状态，例如我们想衡量一个待处理队列中任务的个数（例如：我们要监控硬盘容量或者内存的使用量，那么就i一个使用gauges的metrics格式来度量，因为硬盘的容量或者内存的使用量是醉着时间的推移，不断地瞬间，没有规则变化地，这种变化没有规律当前是多少，采集回来就是多少，既不能肯定是一直持续增长的，也不能肯定是一直降低，是多少就是多少，这就是gauges使用的类型的代表）

counters

描述: 它是使用最频繁的数据类型，其记录的是事件的数量或者大小，通常用来跟踪某个特定代码路径被执行的频率，此类型其根本的的意义是计数器随着时间的推移而增加的速度。

counter就是计数器，从数据0开始累计计算，在理想状态下只能是永远的增长不会降低（一些特殊情况另说）

举个例子说明：比如对用户访问量的采样数据，我们的产品被用户访问一次就是1，过了10分钟后累积到100，国一天后累计到20000

一周后积累到100000-150000

1. process_cpu_seconds_total 用户和系统的总cpu使用时间

Histograms

histogram统计数据的分布情况，比如最小值，最大值，中间值，还有中位数，75百分位，90百分位，98百分位，99百分位和99.9百分位的值

这是一种特殊的metrics数据类型，代表的是一种近似的百分比估算数值

举个例子，我们日后在企业工作中经常接触这种数据

Http_response_time HTTP响应时间

代表一次用户HTTP请求在系统传输和执行过程中，总共花费的时间

日常中，假设我们一天下来，线上没有发生故障，大部分用户的响应时间都在0.05s（通过总时长/总次数）但是我们不要忘记了，任何系统中都一定存在慢请求，就是右一少部分的用户请求时间会比总的平均值大很多，甚至接近5s，10s的也有（这种情况很普遍，因为各种因素，可能是软件本身的bug，也可能是系统的原因，更有可能是少部分用户的使用途径中出现了问题）

那么我们的监控需要发现和报警这种少部分的特殊情况，用总平均能获得吗

如果采取总平均的方式，那么不管发生上面特殊情况，因为发部分的用户响应都是正常的，你永远也发现不了少部分的问题

所以histogram的metrics类型在这种时候就派上用场了

通过histogram的metrics类型（Prometheus提供了一个基于histogram算法的函数，可以直接使用）可以分别统计出全部用户的响应时间中~=0.05s的量有多少，0~0.05s的有多少，>2s的有多少

我们就可以清晰的看到当前我们的系统中处于基本正常状态的有多少百分比的用户（或是请求）

metrics的类型其实还有另外的类型，但是上述三种是用的比较多的，能满足大部分需求

k/v的数据形式

我们在前面了解了metrics的概念和类型

Prometheus的数据类型就是依赖于这种metrics的类型来计算的

而对于采集回来的数据类型，在往细了说必须要以一种具体的数据格式供我们查看和使用

那么我们来看以下一个exporter给我们采集来的服务器上的k/v形式metrics数据

当一个exporter被安装和运行在被监控的服务器上后，使用简单的curl命令就可以看到exports帮我们采集到metrics数据的样子

安装node_exporter之前需要安装go环境

$ yum install go
$ go version
go version go1.9.4 linux/amd64

192.168.100.3使我们数据库主机的ip，端口号则是对应的exporter的监听端口。

启动一下Prometheus

#两种启动方式，前台启动和后台启动
./prometheus
 
nohup /usr/local/prometheus/prometheus  --config.my-cnf=/usr/local/prometheus/prometheus &

此时访问192.168.100.3web页面，查看state为down

$ tar xvf node_exporter-0.14.0.linux-amd64.tar.gz -C /usr/local/
$ nohup /usr/local/node_exporter-0.14.0.linux-amd64/node_exporter &

安装运行mysqld_exporter

mysqld_exporter需要连接到Mysql，所以需要Mysql的权限，我们先为它创建用户并赋予所需的权限

create user 'exporter'@'localhost'  IDENTIFIED BY '199710';
GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT, RELOAD ON *.* TO 'exporter'@'localhost';

创建.my.cnf文件并运行mysqld_exporter：

$ cat /usr/local/mysqld_exporter-0.10.0.linux-amd64/.my.cnf
[client]
user=mysql_monitor
password=mysql_monitor

$ tar xvf mysqld_exporter-0.10.0.linux-amd64.tar.gz -C /usr/local/
$ nohup /usr/local/mysqld_exporter-0.10.0.linux-amd64/mysqld_exporter -config.my-cnf="/usr/local/mysqld_exporter-0.10.0.linux-amd64/.my.cnf" &

 启动组件

./mysqd_exporter或者

nohup /usr/local/mysqld_exporter/mysqld_exporter  --config.my-cnf=/usr/local/mysqld_exporter/mysqld_exporter.cnf &

浏览器访问默认端口192.168.100.20:9104 

 这样就启动成功了

配置Prometheus获取监控数据

在Prometheus的配置文件中添加node_exporter 和 mysqld_exporter 的配置

重启一下prometheus

看到各节点都UP起来，那就说明配置成功了（建议多刷新web页面几次，不然不容易出结果）

会主界面搜索 MySQL 相关参数，比如：mysql_global_variables_innodb_buffer_pool_size

三、部署grafana

Grafana 的 Github 地址：GitHub - grafana/grafana: The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.

Download Grafana | Grafana Labs

先wget https://dl.grafana.com/oss/release/grafana-7.4.5-1.x86_64.rpm
​
后yum install grafana-7.4.5-1.x86_64.rpm -y

我们找一台192.168.100.6主机来部署grafana

wget https://dl.grafana.com/oss/release/grafana-7.4.5-1.x86_64.rpm
​
yum install grafana-7.4.5-1.x86_64.rpm -y

 启动一下

systemctl start grafana-server

以下web页面建议全屏操作 

用户名密码都是 admin。登录后，会让我们修改密码，则按提示操作即可，当然也可以点击跳过

为grafana配置Prometheus数据源

如下图，增加 Prometheus 的 URL 即可：

Grafana 展示 Linux 的监控数据

 11074是英文的，8919是中文的,这都是官方的id

点击load就会出现以下画面

将 Name 改成你希望定义的名字，在 VictoriaMetrics 位置选择之前创建的 Prometheus 数据源，如下图：

“Import”，会自动跳转到如下界面：

到这里，完成了 Grafana 展示 Prometheus 中 Linux 操作系统的监控数据。

Grafana 展示 MySQL 的监控数据

 在 “Import via grafana.com” 下方输入 7362：

或者在 MySQL Overview | Grafana Labs 页面下载 JSON 模板，然后点击 “Upload JSON file” 导入，然后会显示如下信息（目前还有其他一些模板，比如 GitHub - percona/grafana-dashboards: PMM dashboards for database monitoring，有兴趣的可以尝试一下）：

因为mysql没有数据，所以会出现NO Data

到这里，完成了 Grafana 展示 Prometheus 中 MySQL 的监控数据。

告警配置

对 Prometheus 中获取的数据进行告警配置，目前有很多方式，比如：

• 通过 Grafana 配置邮件告警

• 通过开源的运维告警中心消息转发系统：PrometheusAlert，Github 地址：GitHub - BegoniaFlowerHome/PrometheusAlert: Prometheus Alert是开源的运维告警中心消息转发系统,支持主流的监控系统Prometheus,Zabbix,日志系统Graylog和数据可视化系统Grafana发出的预警消息,支持钉钉,微信,华为云短信,腾讯云短信,腾讯云电话,阿里云短信,阿里云电话等

本节内容就拿 Grafana 配置邮件告警来举例，PrometheusAlert 在后面的内容中再跟朋友们介绍。编辑 Grafana 配置文件 etc/grafana/grafana.ini，按下图修改 [smtp] 部分配置：

重启 Grafana

systemctl restart grafana-server.service

如果测试正常，则点击“Save”保存配置。

Grafana+onealert报警

Prometheus报警需要使用alertmanager这个组件，而且报警规则需要手动编写。所以最好使用grafana+onealert实现监控报警。做之前在检查一下时间同步。

登陆http://www.onealert.com/——》注册账户——》登入后台管理

 点击保存以后，获取appkey

在Grafana中配置Webhook URL

 1、在Grafana中创建Notification channel，选择类型为Webhook；
2、推荐选中Send on all alerts和Include image，Cloud Alert体验更佳；
3、将第一步中生成的Webhook URL填入Webhook settings Url；
URL格式：
http://api.aiops.com/alert/api/event/prometheus/bd8cc0af7b2644f1834a8d0b9d9e5ced
 
4、Http Method选择POST；
5、Send Test&Save；

测试CPU负载告警

现在可以去设置一个报警来测试（这里我们可以用我们前面加的CPU负载监控来做测试）

1.  #查看cpu占用率
2. (1- ((sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)) / (sum(increase(node_cpu_seconds_total[1m])) by(instance))))*100

测试报警

在被监控端下载一个stress测试工具

yum install -y epel*
yum install -y stress

开始测试

设置压6核cpu，此时cpu就会被冲高（根据自己内存来）

手动触发报警通知，发来的报警如下图

登录自己邮箱

 退出后，CPU压力就变小了

可以尝试在冲击一下，不尝试的话在睿象云发的告警通知里点击关闭，就会收到一封告警已经解决的邮件