prometheus服务监控

注：文档仅记录在linux下进行的一系列操做；
安装前准备：前端

安装wget，用于下载文件，命令： yum install wget -y
安装lrzsz，用于上传文件资料，命令： yum install lrzsz -y
若是要跨机器访问须要开启端口号，在root用户下使用命令（0000表示要开启的端口号）： firewall-cmd --zone=public --add-port=0000/tcp --permanent 重启防火墙： firewall-cmd --reload

Prometheus介绍：

Prometheus受启发于Google的Brogmon监控系统（类似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，而且于2015年早期对外发布早期版本。2016年5月继Kubernetes以后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年末发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 node

Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。惟一须要的就是本地磁盘，所以不会有潜在级联故障的风险。mysql

Prometheus基于Pull模型的架构方式，能够在任何地方（本地电脑，开发环境，测试环境）搭建咱们的监控系统。对于一些复杂的状况，还可使用Prometheus服务发现(Service Discovery)的能力动态管理监控目标。
全部采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。全部的样本除了基本的指标名称之外，还包含一组用于描述该样本特征的标签。linux

每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)惟一标识。每条时间序列按照时间的前后顺序存储一系列的样本值。表示维度的标签可能来源于你的监控对象的状态，好比code=404或者content_path=/api/path。也可能来源于的你的环境定义，好比environment=produment。基于这些Labels咱们能够方便地对监控数据进行聚合，过滤，裁剪。git

Prometheus内置了一个强大的数据查询语言PromQL。经过PromQL能够实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中。github

经过PromQL能够轻松回答相似于如下问题：golang

在过去一段时间中95%应用延迟时间的分布范围
预测在4小时后，磁盘空间占用大体会是什么状况
CPU占用率前5位的服务有哪些(过滤)

对于监控系统而言，大量的监控任务必然致使有大量的数据产生。而Prometheus能够高效地处理这些数据，对于单一Prometheus Server实例而言它能够处理：web

数以百万的监控指标
每秒处理数十万的数据点

Prometheus生态结构：

Prometheus 生态结构图以下所示： spring

prometheus 获取服务数据的方式有两种：pull和push两种模式，默认支持pull模式，配置简单，操做容易，配合一系列的Exporter能够很容易获取metircs接口数据，push模式须要pushgateway的支持，且须要本身实现一些操做，包括数据添加、更新、删除操做的数据到prometheus的pushgateway中，官方对push模式这样说的： sql

使用Pushgateway有几个陷阱：

经过单个Pushgateway监控多个实例时，Pushgateway成为单点故障和潜在瓶颈。
您经过up 指标（每次刮除时生成）丢失了Prometheus的自动实例运行情况监控。
Pushgateway永远不会忘记推送到它的系列，并将永远暴露给Prometheus，除非这些系列是经过Pushgateway的API手动删除的。

Prometheus对比Zabbix：

Zabbix	Prometheus
后端用C开发，界面用PHP开发，定制化难度很高。	后端用golang开发，前端是Grafana，JSON编辑便可解决定制化难度较低
集群规模上限为 10000 个节点	支持更大的集群规模，速度也更快
更适合监控物理机环境	更适合云环境的监控，对OpenStack，Kubernetes有更好的集成
监控数据存储在关系型数据库内，如 MySQL，很难从现有数据中扩展维度	监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合
安装简单，zabbix-server 一个软件包中包括了全部的服务端功能	安装相对复杂，监控、告警和界面都分属于不一样的组件
图形化界面比较成熟，界面上基本上能完成所有的配置操做	界面相对较弱，不少配置须要修改配置文件
发展时间更长，对于不少监控场景，都有现成的解决方案	2015 年后开始快速发展，但发展时间较短，成熟度不及Zabbix

Prometheus工做流程：

一、Prometheus Server 按期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Push Gateway 发过来的 metrics，或者从其余的 Prometheus Server 中拉 metrics。二、Prometheus Server 在本地存储收集到的 metrics，并运行已定义好的预警规则，记录新的时间序列或者向 Alertmanager 推送警报。三、Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。四、在图形界面（Grafana）中，采集数据，将其可视化。

Prometheus客户端库主要提供四种主要的 metric 类型：

Counter(计数器)： - 说明：Counter是一个累积度量，它表示一个单调递增的 Metrics，其值只能在重启时递增或重置为零； - 场景：可使用Counter来表示http的请求数、已完成的任务数或错误数、下单数。
Gauge(测量仪)： - 说明：当前值的一次快照(snapshot)测量，可增可减。 - 场景：磁盘使用率，当前同时在线用户数。
Histogram(直方图)： - 说明：经过区间统计样本分布。 - 场景：请求延迟时间的统计。例如统计 0200ms、200ms400ms、400ms~800ms 区间的请求数有多。
Summary(汇总)： - 说明：根据样本统计出百分位。 - 场景：请求延迟时间的统计。例如统计 95%的请求延迟 < xxx ms ，99%的请求延迟 < xxx ms。

Prometheus安装：

下载prometheus文件，在Linux系统中，使用cd命令进入目标目录下，例如：/usr/local/src/prometheus；下载连接为：https://prometheus.io/download/ 如图所示，下载红色框中的文件：

解压下载文件，使用tar -zxvf prometheus-*.tar.gz命令进行解压缩。解压后以下图所示，红色框中的为执行文件：

![](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jZG4ubmxhcmsuY29tL3l1cXVlLzAvMjAxOS9wbmcvMTgyNTQwLzE1NjMyNDgwNjUwNDktMWU0MWFmMzYtNWQ0MS00MzYyLWFhNzAtZjc4MDVmODgyNTYzLnBuZw#align=left&display=inline&height=188&originHeight=146&originWidth=567&status=done&width=732)

进入到premotheus根目录下，执行命令：sudo ./Prometheus 启动服务（启动prometheus须要/prometheus/data权限），能够看到下图所示信息即表示启动成功；

![](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jZG4ubmxhcmsuY29tL3l1cXVlLzAvMjAxOS9wbmcvMTgyNTQwLzE1NjMyNDgwNjUxNDAtYjUxYzJhNzctZTdmMi00ODcxLThiNzAtMjdlMTE5MTgyOGNhLnBuZw#align=left&display=inline&height=248&originHeight=465&originWidth=1396&status=done&width=744)

另外后台启动服务使用命令：nohup ./prometheus > prometheus.log 2>&1 & 启动以后，浏览器输入http://192.168.xx.xx:9090 ，以下如所示：

在阿里云的ESC部署的时候发现的问题及解决办法：

按照上面的操做进行启动的时候报错，报错信息以下： level=error ts=2019-07-23T02:03:30.555Z caller=main.go:731 err=“opening storage failed: lock DB directory: resource temporarily unavailable” 解决办法：删除解压目录下的 lock 文件
执行：rm -f [软件的本地解压目录]/prometheus/data/lock
解决上面的问题后，启动服务发现还有报错，报错信息以下：

level=error ts=2019-07-23T02:30:49.107Z caller=main.go:731 err=“error starting web server: listen tcp 0.0.0.0:9090: bind: address already in use”

解决办法：查找占用9090端口的应用的PID，而后强制关闭执行：sudo netstat -antup 查找到占用9090端口的应用的PID 执行：kill -9 \[具体的pid\]

Prometheus配置介绍：

Prometheus配置只有一个prometheus.yml文件，其内容以下图所示：

读配置文件即其中的注释能够知道默认的配置有四个，global全局配置，alerting预警，rule_files规则文件，scrape_configs下载配置；

在scrage_configs下看到默认配置了prometheus本身的监控配置，job_name是一个配置标识， static_config下有一个targets，这个配置监控服务的地址+端口号，promehteus会经过这个配置的url和默认的路径”/metrics”，去对应的服务上pull监控的各类数据到prometheus中进行存储。

Prometheus数据存储配置：

数据存储：prometheus采用自定义的存储格式将样本数据保存在本地磁盘当中，默认数据存储在prometheus根目录下的/data文件夹中，如图所示：

存储说明：Prometheus 按照两个小时为一个时间窗口，将两小时内产生的数据存储在一个块（Block）中。每一个块都是一个单独的目录，里面含该时间窗口内的全部样本数据（chunks），元数据文件（meta.json）以及索引文件（index）。其中索引文件会将指标名称和标签索引到样板数据的时间序列中。此期间若是经过 API 删除时间序列，删除记录会保存在单独的逻辑文件 tombstone 当中。

当前样本数据所在的块会被直接保存在内存中，不会持久化到磁盘中。为了确保 Prometheus 发生崩溃或重启时可以恢复数据，Prometheus 启动时会经过预写日志（write-ahead-log(WAL)）从新记录，从而恢复数据。预写日志文件保存在 wal 目录中，每一个文件大小为 128MB。

wal 文件包括尚未被压缩的原始数据，因此比常规的块文件大得多。通常状况下，Prometheus 会保留三个 wal 文件，但若是有些高负载服务器须要保存两个小时以上的原始数据，wal 文件的数量就会大于 3 个。

Prometheus保存块数据的目录结构以下所示：

Prometheus 的本地存储没法持久化数据，没法灵活扩展。为了保持简单性，定义两个标准接口（远程写remote_write，远程读remote_read），让用户能够基于这两个接口对接将数据保存到任意第三方的存储服务中，这种方式在 Promthues 中称为 Remote Storage。

Prometheus远程存储配置：

Prometheus远程存储的方式有不少种，可是部分只支持写，并不支持读，Elasticsearch就是其中一个，可是咱们能够经过中间工具能够实现将数据存储到Elasticsearch和从Elasticsearch中读取数据。在prometheus官网是这样介绍远程读写的：

prometheus远程读写数据到Elasticsearch，须要一个对应的adapter来实现，Prometheus-es-adapter 就是实现这个功能的。

Prometheus远程读写到Elasticsearch：

Prometheus-es-adapter在github上能够拉取源码：https://github.com/pwillie/prometheus-es-adapter.git，这个adapter是Go语言开发的，全部编译运行须要Go语言环境。Go语言环境搭建这里再也不描述，只说明编译和运行的步骤。这里特殊说明一点，go的仓库在国外，可能有些依赖下载不下来，须要配置GOPRAXY环境变量，说明以下：

修改配置文件，添加go module和goproxy的配置：在Go语言环境配置好以后，由于验证时没有在root用户下操做，因此配置的GOPATH为/home/xxx/go，若是是在root用户下操做，安装Go环境以后，默认的GOPATH是/root/go，cd到GOPATH目录下，若是没有src目录则在这个目录下建立一个src文件夹，而后将prometheus-es-adapter 克隆/下载到/src下，也就是/home/xxx/go/src/，或者/root/go/src下，cd到prometheus-es-adapter下，修改/cmd/adapter/main.go文件，默认配置的es信息以下图所示：

而后执行make build命令进行编译，编译完成以后，在当前目录下会生成一个prometheus-es-adapter的可执行文件，这个文件在当前目录下的/release/linux/amd64/文件夹，启动这个可执行文件。

若是是docker启动服务则须要修改docker-compose.yml文件，配置elasticsearch路径、版本等信息，示例以下所示，其中蓝色框中的是本身注释掉的，这个暂且不须要，红色框的是要修改的：

远程读/写的配置很简单，在prometheus.yml中添加remote_write的配置项便可，这里演示配置远程写到Elasticsearch，示例以下：

#远程写
remote_write:
  - url: http://192.168.xx.xx:8000/write
#远程读
remote_read:
  - url: http://192.168.xx.xx:8000/read

Prometheus监控配置：

Node_exporter服务器监控：

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储而且对外提供数据查询支持。所以为了可以可以监控到某些东西，如主机的CPU使用率，咱们须要使用到Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（一般是/metrics）拉取监控样本数据。

为了可以采集到主机的运行指标如CPU, 内存，磁盘等信息。咱们可使用Node Exporter。Node Exporter一样采用Golang编写，而且不存在任何的第三方依赖，只须要下载，解压便可运行。

下载node_exporter能够从https://prometheus.io/download/ 获取最新的node exporter版本的二进制包。在prometheus官网提供不少exporter，下载下图红框中的文件，放到要安装的目录下，例如：/usr/local/src目录下；
解压缩文件，使用tar -zxvf node_exporter-0.18.1.linux-amd64.tar.gz命令，解压文件，包含一个可执行文件，下图红色框中的文件：
进入到node_exporter根目录，输入命令：./node_exporter，启动服务，能够看到下图所示信息即表示启动成功。

另外能够后台启动服务使用命令：nohup ./node_exporter > node_exporter.log 2>&1 &，启动成功后，访问http://192.168.xx.xx:9100能够看到：
点击mertrics能够看到服务监控信息：

Node_exporter配置到Prometheus:

node_exporter的端口是9100，打开prometheus的配置文件prometheus.yml，在scrape_configs下面添加以下内容，注意这个要跟默认的job_name: 'prometheus’同级配置；

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
	#node_exporter
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

配置好以后，须要重启prometheus服务，重启完成，再次访问http://192.168.xx.xx:9090点击菜单栏status下的targets能够看到，node_exporter已经出现，并显示状态为UP；由于只部署了一个node_exporter因此看到的是node_exporter（1/1 up）;

点击Endpoint下的url（由于全部的服务都在同一机器上，因此这里配置的是localhost）能够看到服务器的监控信息，也就是点击http://192.168.xx.xx:9100 下的metrics一样的页面和内容。

Mysqld_exporter数据库监控：

Mysqld_exporter和Node_exporter相似，也是官网提供的监控插件，在官网能够下载到。

经过浏览器访问prometheus官网https://prometheus.io/download/ 获取最新的mysqld_exporter版本的二进制包。下载下图红框中的文件，放到要安装的目录下，例如：/usr/local/src目录下；
解压缩文件，使用tar -zxvf mysqld_exporter-0.12.0.linux-amd64.tar.gz命令，解压文件，包含一个可执行文件，下图红色框中的文件（其中mysqld_exporter.log是后台启动指定建立的日志文件，自己不包含此文件）：
启动可执行文件，使用命令：./mysqld_exporter 看到下图所示信息：

注意红色框中的信息提示当前用户目录root下没有.my.cnf文件，mysqld_exporter监控数据库信息，须要数据库相关的配置，包括url、端口号、用户名和密码，若是这个配置须要配置在当前用户目录下的.my.cnf文件中；

命令cd到用户目录下，当前用户是root 就cd /home/root，而后使用命令：vi .my.cnf这个若是有会打开，若是没有这个文件，保存时会建立。使用ls -la 命令可查看.my.cnf文件是否存在，打开此文件，配置数据库相关信息：

[client]host=192.168.xx.xx
port=3306
user=root
password=root

编辑好以后进行保存，而后从新启动mysqld_exporter服务：

此时能够看到错误信息中出现了数据库相关信息，可是拒绝链接，这个是由于数据库没有启动，去后台启动数据库服务后便可，正常链接后以下图所示：

访问http://192.168.xx.xx:9104 查看相关信息：

Mysqld_exporter配置到Prometheus：

配置好mysqld_exporter以后，在prometheus的配置文件prometheus.yml中加入mysqld_exporter的配置，配置信息以下所示：

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
  #mysqld_exporter
  - job_name: 'mysqld_exporter'
    static_configs:
      - targets: ['localhost:9104']

而后重启prometheus服务，访问http://192.168.xx.xx:9090点击菜单栏status下的targets能够看到有关mysqld_exporter的信息，而且状态是UP。

点击链接，能够看到数据库监控信息，如图所示：

Java服务监控：

在服务中加入maven依赖：

<!-- actuator -->
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- prometheus-->
<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

在配置文件中配置相关信息：

##=====actuator=====##
management:
  endpoints:
    web:
      exposure:
        include: health,info,env,metrics,Prometheus

这里include也能够配置成*，表示全部，配置好以后，启动服务，访问http://192.168.xx.xx:8762/actuator可看到相关监控信息：

Java服务配置到Prometheus：

服务启动后打开prometheus配置文件prometheus.yml，在配置文件中加入服务监控的相关配置，这里须要注意，和前面的配置相比，多了一个metrics_path的配置项，这里配置的是/actuator/promehteus, 配置信息以下所示：

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
  #spring-boot 这里命名为spring-boot
  - job_name: 'spring-boot'
    metrics_path: '/actuator/prometheus'
    static_configs:
		- targets: ['192.168.xx.xx:8762']

metrics_path说明：

prometheus处理监控信息的格式是固定的以下图所示：

prometheus默认的监控接口是/metrics，访问http://192.168.xx.xx:8762/actuator/metrics 看到以下信息：

上图中的数据格式prometheus是没法处理的，因此不能在prometheus配置中使用默认的接口，访问http://192.168.xx.xx:8762/actuator/prometheus能够看到：

这个是prometheus能够处理的，因此要配置metrics_path为/actuator/prometheus的接口。配置完成后，访问http://192.168.xx.xx:9090 点击菜单栏status下的targets能够看到有关spring_boot的信息，而且状态是UP，若是没有配置metrics_path，服务状态则是DOWN。

Prometheus告警配置:

Prometheus 告警配置参考prometheus.yml配置文档中的描述能够知道，告警规则能够是外部的YAML文件。在Prometheus中一条告警规则主要由如下几部分组成：

告警名称：用户须要为告警规则命名，固然对于命名而言，须要可以直接表达出该告警的主要内容；
告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警；

在Prometheus中，还能够经过Group（告警组）对一组相关的告警进行统必定义。固然这些定义都是经过YAML文件来统一管理的。

Prometheus告警规则：

Prometheus告警规则是基于PromQL表达式定义的，示例以下：

groups:
- name: node_alert
  rules:

  # Alert for any instance that is unreachable for > 10 seconds.
  - alert: Instance Down
    expr: up == 0
    for: 10s
    annotations:
      summary: "Instance {
   { $labels.instance }} down"
      description: "{
   { $labels.instance }} of job {
   { $labels.job }} has been down."

在告警规则文件中，咱们能够将一组相关的规则设置定义在一个group下。在每个group中咱们能够定义多个告警规则(rule)。经过 labels.name 变量能够访问当前告警实例中指定标签的值。$value则能够获取当前PromQL表达式计算的样本值。一条告警规则主要由如下几部分组成：

alert：告警规则的名称。
expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列知足该条件。
for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
labels：自定义标签，容许用户指定要附加到告警上的一组附加标签。
annotations：用于指定一组附加信息，好比用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同做为参数发送到Alertmanager。

按照PromQl语法配置一个告警规则，定义alert_rules.yml文件，将示例中的语句复制到alert_rules.yml文件中，保存，而后在prometheus的配置文件中，规则配置项添加alert_rules.yml的文件路径配置,完成以后使用命令：./promtool check rules ./ alert_rules.yml 检查规则是否正确，简称正确，一切完成后重启prometheus，访问http://192.168.xx.xx:9090/rules 能够看到配置的告警信息：

当告警规则触发时，alerts的state会变成PENDING，若是后告警条件持续知足配置的时间，告警状态为FIRING

Alertmanager配置到Prometheus:

Prometheus能够配置告警规则，并触发告警配置，可是只能在页面看到状态的变化，没法发送告警通知，alertmanager结合prometheus能够作到更多。

经过浏览器访问prometheus官网https://prometheus.io/download/ 获取最新的alertmanager。下载下图红框中的文件，放到要安装的目录下，例如：/usr/local/src目录下；
执行解压缩命令，解压下载的alertmanager-0.18.0.linux-amd64.tar.gz文件，里面包含alertmanager的可执行文件alertmanager，和配置文件alertmanager.yml
启动alertmanager服务，默认端口为9093，访问http://192.168.xx.xx:9093 能够看到相关的信息，点击status查看配置信息：

打开alertmanager.yml文件，下载邮件通知模板，添加邮件配置信息，内容示例以下所示（模板下载：wget https://raw.githubusercontent.com/prometheus/alertmanager/master/template/default.tmpl）：

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.qq.com:587'
  smtp_from: '29029xxx2@qq.com'
  smtp_auth_username: '29029xxx2@qq.com'
  smtp_auth_password: 'sxxasd' #这里须要得是客户端受权登陆密码，非帐号登陆密码
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: team-X-mails
receivers:
  - name: 'team-X-mails'
    email_configs:
    - to: 'liwenqiang@tseveryday.com'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']
templates:
  - 'default.tmpl'

配置完成后重启服务，刷新http://192.168.xx.xx:9093/status 能够看到配置信息已经更新：

当告警规则触发后，alertmanager会收到来自prometheus的告警信息，而且会发送告警通知（这里配置的是邮件通知，因此会）：

Grafana安装：

虽然prometheus能够进行一些数据的查看，可是没有只能看到一堆的数据，分析起来复杂，且不直观，grafana是一个可视化工具，能够根据须要安装各类功能分析和展现插件来直观的展现数据信息；

安装grafana的方式不少，参考：https://grafana.com/docs/installation/rpm/，为了方便直接使用 yum 安装:

sudo yum install https://dl.grafana.com/oss/release/grafana-5.4.2-1.x86_64.rpm

安装完成后执行：sudo service grafana-server start启动grafana服务，也能够经过systemctl start grafana-server启动（在使用此命令以前先执行一次systemctl daemon-reload），启动以后查看状态：systemctl status grafana-server；
Grafana默认端口号为3000，启动后访问http://192.168.xx.xx:3000 ，可看到下图画面，默认的帐号密码是admin/admin；

Grafana 配置数据源：

进入首页，点击add data source选项，进入数据源配置页面：
选择prometheus做为数据源配置，点击prometheus后进入数据源配置页面，以下图所示：
在红色框中配置相关的信息，这里grafana和prometheus在同一台机器上，因此这里配置http://localhost:9090 ，填写完成后，点击save and test，而后点击绿色框中的dashbords选项，选择prometheus 2.0 stats点击后面的import。
Import以后，在首页中，选择配置的prometheus 2.0 stats，就能够看到数据展现。

Grafana dashboards添加：

点击左侧栏中的+图标下的import，在页面中输入grafana labs的dashboards下的插件id（node_exporter：1860， mysqld_exporter: 6239， jvm: 4701/9568），会自动跳转至配置页，选择数据源为prometheus，而后点击import。操做完成，服务运行一段时间以后能够看到相关的数据统计：

注意红色框中，容器名称时没有的，这里须要说明得是，使用4701这个dashboards时，须要在spring boot配置文件中增长一些配置，两种配置二选一便可：

prometheus和grafana 服务监控搭建