Promethes集成springboot篇（三）

yitian_hm

已于 2022-08-22 11:50:00 修改

阅读量679

点赞数

分类专栏： prometheus 文章标签： spring boot java 运维

于 2022-06-18 22:16:22 首次发布

本文链接：https://blog.csdn.net/yitian_881112/article/details/125351828

版权

prometheus 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Promethes集成springboot篇（三）

3.1 Prometheus的主要特点

Prometheus官网上的自述是：“From metrics to insight.Power your metricsand alerting with a leading open-source monitoring solution.”翻译过来就是：从指标到洞察力，Prometheus通过领先的开源监控解决方案为用户的指标和告警提供强大的支持。
Prometheus最主要的特色有4个：
·通过PromQL实现多维度数据模型的灵活查询。
·定义了开放指标数据的标准，自定义探针（如Exporter等），编写简单方便。
·PushGateway组件让这款监控系统可以接收监控数据。
·提供了VM和容器化的版本。尤其是第一点，这是很多监控系统望尘莫及的。多维度的数据模型和灵活的查询方式，使监控指标可以关联到多个标签，并对时间序列进行切片和切块，以支持各种图形、表格和告警场景。
Prometheus认为最有用的数据是最近的数据，监控数据默认保留15天。本地存储有限，存储大量的历史数据需要对接第三方远程存储。
Prometheus对数据的统计无法做到100%准确，如订单、支付、计量计费等精确数据监控场景。Prometheus默认是拉模型，建议合理规划网络，尽量不要转发

3.2 Prometheus架构剖析

在这里插入图片描述
如图所示，Prometheus主要由Prometheus Server、Pushgateway、Job/Exporter、Service Discovery、Alertmanager、Dashboard这6个核心模块构成。Prometheus通过服务发现机制发现target，这些目标可以是长时间执行的Job，也可以是短时间执行的Job，还可以是通过Exporter监控的第三方应用程序。被抓取的数据会存储起来，通过PromQL语句在仪表盘等可视化系统中供查询，或者向Alertmanager发送告警信息，告警会通过页面、电子邮件、钉钉信息或者其他形式呈现。从上述架构图中可以看到，Prometheus不仅是一款时间序列数据库，在整个生态上还是一套完整的监控系统。对于时间序列数据库，在进行技术选型的时候，往往需要从宽列模型存储、类SQL查询支持、水平扩容、读写分离、高性能等角度进行分析。而监控系统的架构，往往还需要考虑通过减少组件、服务来降低成本和复杂性以及水平扩容等因素。

3.2.1.Job/Exporter

Job/Exporter属于Prometheus target，是Prometheus监控的对象。Job分为长时间执行和短时间执行两种。对于长时间执行的Job，可以使用Prometheus Client集成进行监控；对于短时间执行的Job，可以将监控数据推送到Pushgateway中缓存。
Prometheus收录的Exporter有上千种，它可以用于第三方系统的监控。Exporter的机制是将第三方系统的监控数据按照Prometheus的格式暴露出来，没有Exporter的第三方系统可以自己定制Exporter，

3.2.2.Pushgateway

Prometheus是拉模式为主的监控系统，它的推模式就是通过Pushgateway组件实现的。Pushgateway是支持临时性Job主动推送指标的中间网关，它本质上是一种用于监控Prometheus服务器无法抓取的资源的解决方案。它也是用Go语言编写的，在Apache 2.0许可证下开源。
Pushgateway作为一个独立的服务，位于被采集监控指标的应用程序和Prometheus服务器之间。应用程序主动推送指标到Pushgateway，Pushgateway接收指标，然后Pushgateway也作为target被Prometheus服务器抓取。它的使用场景主要有如下几种。·临时/短作业。·批处理作业。·应用程序与Prometheus服务器之间有网络隔离，如安全性（防火墙）、连接性（不在一个网段，服务器或应用程序仅允许特定端口或路径访问）。
使用Pushgateway时需要记住的另一个问题是，Pushgateway不会自动删除推送给它的任何指标数据。因此，必须使用Pushgateway的API从推送网关中删除过期的指标。Pushgateway还有防火墙和NAT问题。推荐做法是将Prometheus移到防火墙后面，让Prometheus更加接近采集的目标。
注意，Pushgateway会丧失Prometheus通过UP监控指标检查实例健康状况的功能，此时Prometheus对应的拉状态的UP指标只是针对单Pushgateway服务的。

3.2.3 服务发现（Service Discovery）

Prometheus通过服务发现机制对云以及容器环境下的监控场景提供了完善的支持。除了支持文件的服务发现（Prometheus会周期性地从文件中读取最新的target信息）外，Prometheus还支持多种常见的服务发现组件，如Kubernetes、DNS、Zookeeper、Azure、EC2和GCE等。例如，Prometheus可以使用Kubernetes的API获取容器信息的变化（如容器的创建和删除）来动态更新监控对象。对于支持文件的服务发现，实践场景下可以衍生为与自动化配置管理工具（Ansible、Cron Job、Puppet、SaltStack等）结合使用。通过服务发现的方式，管理员可以在不重启Prometheus服务的情况下动态发现需要监控的target实例信息。服务发现中有一个高级操作，就是Relabeling机制。Relabeling机制会从Prometheus包含的target实例中获取默认的元标签信息，从而对不同开发环境（测试、预发布、线上）、不同业务团队、不同组织等按照某些规则（比如标签）从服务发现注册中心返回的target实例中有选择性地采集某些Exporter实例的监控数据。相对于直接使用文件配置，在云环境以及容器环境下我们更多的监控对象都是动态的。实际场景下，Prometheus作为下一代监控解决方案，更适合云及容器环境下的监控需求，在服务发现过程中也有很多工作（如Relabeling机制）可以加持

3.2.4 Prometheus服务器（Prometheus Server）

Prometheus服务器是Prometheus最核心的模块。它主要包含抓取、存储和查询这3个功能，如图2所示。

在这里插入图片描述
1）抓取：Prometheus Server通过服务发现组件，周期性地从上面介绍的Job、Exporter、Pushgateway这3个组件中通过HTTP轮询的形式拉取监控指标数据。2）存储：抓取到的监控数据通过一定的规则清理和数据整理（抓取前使用服务发现提供的relabel_configs方法，抓取后使用作业内的metrics_relabel_configs方法），会把得到的结果存储到新的时间序列中进行持久化。多年来，存储模块经历了多次重新设计，Prometheus 2.0版的存储系统是第三次迭代。该存储系统每秒可以处理数百万个样品的摄入，使得使用一台Prometheus服务器监控数千台机器成为可能。使用的压缩算法可以在真实数据上实现每个样本1.3B。建议使用SSD，但不是严格要求。

3.2.5 Dashboard

在Prometheus架构图中提到，Web UI、Grafana、API client可以统一理解为Prometheus的Dashboard。Prometheus服务器除了内置查询语言PromQL以外，还支持表达式浏览器及表达式浏览器上的数据图形界面。实际工作中使用Grafana等作为前端展示界面，用户也可以直接使用Client向Prometheus Server发送请求以获取数据。

3.2.6 Alertmanager

Alertmanager是独立于Prometheus的一个告警组件，需要单独安装部署。Prometheus可以将多个Alertmanager配置为一个集群，通过服务发现动态发现告警集群中节点的上下线从而避免单点问题，Alertmanager也支持集群内多个实例之间的通信，如图所示。
在这里插入图片描述

3.3 Prometheus 安装

在Prometheus的官方下载页面https://prometheus.io/download/中可以看到，Prometheus提供了独立的二进制文件的tar包，其中主要包括prometheus、alertmanager、blackbox_exporter、consul_exporter、graphite_exporter、haproxy_exporter、memcached_exporter、mysqld_exporter、node_exporter、Pushgateway、statsd_exporter等组件。Prometheus组件主要支持Darwin、Linux、Windows等操作系统。本节介绍通过linux版本在阿里云上迅速安装并启动Prometheus的方法。
在这里插入图片描述
执行命令如下

[root@iZuf6bm702o3rrjlhq9xt5Z ~]# tar -xf prometheus-2.36.1.linux-amd64.tar.gz
[root@iZuf6bm702o3rrjlhq9xt5Z prometheus-2.36.1.linux-amd64]# ./prometheus

通过访问9090端口可以发现prmethus正常启动了
在这里插入图片描述

如果开启了这个命令行参数，每当prometheus.yml文件发生改变时，就不需要对Prometheus进行关闭再重新启动的操作了，而是可以通过如下命令让配置进行重新加载。

当终端关闭或按下Ctrl+C组合键时，Prometheus服务会自动关闭。在Linux中，可以直接执行命令nohup./prometheus&使其后台运行。但是如果对进程进行关闭、重启、查看进程状态等操作，还需要配合各种Linux命令才能完成。为方便起见，可以将Prometheus添加为系统服务且开机自启动

需要注意的是，告警及其阈值是在Prometheus中配置的，而不是在Alertmanager中配置的。以下是prometheus.yml文件配置各个部分的含义和功能的注释。

# my global config
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'.

    static_configs:
      - targets: ["localhost:9090"]
  - job_name: 'springboot-demo'
    metrics_path: 'actuator/prometheus'
    static_configs: 
      - targets: ['localhost:8070']

通过上述注释可知，scrape_configs主要用于配置采集数据节点的操作，它和global重合的配置部分会覆盖global部分，每一个采集配置的具体参数及说明如表所示。在这里插入图片描述
Prometheus的基本概念、历史、特点，以及Prometheus架构中各个关键组件的功能，并对监控数据的抓取组件、存储组件、查询功能以及告警组件进行了简要说明。本章的最后还介绍了Prometheus的安装方法，并解释了prometheus.yml配置文件中的核心配置项。