0 Prometheus概述

0.1 简介

0.2 特点

每一个时间序列数据都由metric度量指标名称和它的标签labels键值对集合唯一确定：这个metric度量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收http请求的总计数）。labels开启了Prometheus的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks的http请求，打上method=POST的标签，则形成了具体的http请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列图。

0.3 样本

样本由以下3部分组成：

  • 指标（metric）：指标名称和描述当前样本特征的 labelsets；
  • 时间戳（timestamp）：一个精确到毫秒的时间戳；
  • 样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。
  • 表示方式：通过如下表达方式表示指定指标名称和指定标签集合的时间序列：{

例如，指标名称为 api_http_requests_total，标签为 method="POST" 和 handler="/messages" 的时间序列可以表示为：api_http_requests_total

0.4 架构与组件

从上图可发现，Prometheus整个生态圈组成主要包括prometheus server，Exporter，pushgateway，alertmanager，grafana，Web ui界面，Prometheus server由三个部分组成，Retrieval，Storage，PromQL

  • Retrieval负责在活跃的target主机上抓取监控指标数据
  • Storage存储主要是把采集到的数据存储到磁盘中
  • PromQL是Prometheus提供的查询语言模块。

0.5 工作流程

0.6 竞品分析：Prometheus vs zabbix

0.7 Prometheus的部署模式

0.7.1 基本高可用模式

基本的HA模式只能确保Promthues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此，这种部署方式适合监控规模不大，Promthues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

0.7.2 基本高可用+远程存储

在解决了Promthues服务可用性的基础上，同时确保了数据的持久化，当Promthues Server发生宕机或者数据丢失的情况下，可以快速的恢复。同时Promthues Server可能很好的进行迁移。因此，该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景。

0.7.3 基本HA + 远程存储 + 联邦集群方案

Promthues的性能瓶颈主要在于大量的采集任务，因此用户需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promthues子服务中，从而实现功能分区。例如一个Promthues Server负责采集基础设施相关的监控指标，另外一个Prometheus Server负责采集应用监控指标。再有上层Prometheus Server实现对数据的汇聚。

0.8 Prometheus的数据类型（x4）

0.8.1 Counter(计数器类型)

# Counter类型示例http_response_total{method="GET",endpoint="/api/tracks"}  100http_response_total{method="GET",endpoint="/api/tracks"}  160

Counter 类型数据可以让用户方便的了解事件产生的速率的变化，在PromQL内置的相关操作函数可以提供相应的分析，比如以HTTP应用请求量来进行说明

0.8.2 Gauge(测量器类型)

# Gauge类型示例memory_usage_bytes{host="master-01"}   100memory_usage_bytes{host="master-01"}   30memory_usage_bytes{host="master-01"}   50memory_usage_bytes{host="master-01"}   80

对于 Gauge 类型的监控指标，通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况，例如，计算 CPU 温度在两小时内的差异：dalta(cpu_temp_celsius{host="zeus"}[2h])

你还可以通过PromQL 内置函数 predict_linear() 基于简单线性回归的方式，对样本数据的变化趋势做出预测。例如，基于 2 小时的样本数据，来预测主机可用磁盘空间在 4 个小时之后的剩余情况：predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

0.8.3 Histogram(柱状图)

histogram是柱状图，在Prometheus系统的查询语言中，有三种作用：

度量指标名称: [basename]上面三类的作用度量指标名称

1）[basename]bucket{le="上边界"}, 这个值为小于等于上边界的所有采样点数量2）[basename]_sum_3）[basename]_count

小结：如果定义一个度量类型为Histogram，则Prometheus会自动生成三个对应的指标

为什需要用histogram柱状图?在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。​ 为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在 0~10ms 之间的请求数有多少，而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。

Histogram 类型的样本会提供三种指标（假设指标名称为 ）：

1）样本的值分布在 bucket 中的数量，命名为 _bucket{le="<上边界>"}。解释的更通俗易懂一点，这个值表示指标值小于等于上边界的所有样本数量。

# 1、在总共2次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0 # 2、在总共2次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0 # 3、在总共2次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0 # 4、在总共2次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0

2）所有样本值的大小总和，命名为 _sum

# 实际含义： 发生的2次 http 请求总的响应时间为 13.107670803000001 秒io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001

3）样本总数，命名为 _count，值和 _bucket{le="+Inf"} 相同

# 实际含义： 当前一共发生了 2 次 http 请求io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0

注意：1）bucket 可以理解为是对数据指标值域的一个划分，划分的依据应该基于数据值的分布。注意后面的采样点是包含前面的采样点的，假设 xxx_bucket{...,le="0.01"} 的值为 10，而 xxx_bucket{...,le="0.05"} 的值为 30，那么意味着这 30 个采样点中，有 10 个是小于 0.01s的，其余 20 个采样点的响应时间是介于0.01s 和 0.05s之间的。

2）可以通过 histogram_quantile() 函数来计算 Histogram 类型样本的分位数。分位数可能不太好理解，你可以理解为分割数据的点。我举个例子，假设样本的 9 分位数（quantile=0.9）的值为 x，即表示小于 x 的采样值的数量占总体采样值的 90%。Histogram 还可以用来计算应用性能指标值（Apdex score）。

0.8.4 Summary(汇总)

与 Histogram 类型类似，用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。它也有三种作用：

1）对于每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于60分不及格的同学比例，统计低于80分的同学比例，统计低于95分的同学比例）

2）统计班上所有同学的总成绩(sum)

3）统计班上同学的考试总人数(count)

带有度量指标的[basename]的summary 在抓取时间序列数据有如命名。

1、观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}

2、[basename]sum， 是指所有观察值的总和

3、[basename]_count, 是指已观察到的事件计数值

样本值的分位数分布情况，命名为 {quantile="<φ>"}。

# 1、含义：这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983sio_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983 # 2、含义：这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666sio_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666

所有样本值的大小总和，命名为 _sum。

# 1、含义：这12次 http 请求的总响应时间为 51.029495508sio_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508

样本总数，命名为 _count。

# 1、含义：当前一共发生了 12 次 http 请求io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0

Histogram 与 Summary 的异同：它们都包含了 _sum 和 _count 指标，Histogram 需要通过 _bucket 来计算分位数，而 Summary 则直接存储了分位数的值。

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002prometheus_tsdb_wal_fsync_duration_seconds_count 216 # 从上面的样本中可以得知当前Promtheus Server进行wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。

0.9 监控内容：Prometheus能监控什么?

# Databases---数据库    Aerospike exporter    ClickHouse exporter    Consul exporter (official)    Couchbase exporter    CouchDB exporter    ElasticSearch exporter    EventStore exporter    Memcached exporter (official)    MongoDB exporter    MSSQL server exporter    MySQL server exporter (official)    OpenTSDB Exporter    Oracle DB Exporter    PgBouncer exporter    PostgreSQL exporter    ProxySQL exporter    RavenDB exporter    Redis exporter    RethinkDB exporter    SQL exporter    Tarantool metric library    Twemproxy# Hardware related---硬件相关    apcupsd exporter    Collins exporter    IBM Z HMC exporter    IoT Edison exporter    IPMI exporter    knxd exporter    Netgear Cable Modem Exporter    Node/system metrics exporter (official)    NVIDIA GPU exporter    ProSAFE exporter    Ubiquiti UniFi exporter# Messaging systems---消息服务    Beanstalkd exporter    Gearman exporter    Kafka exporter    NATS exporter    NSQ exporter    Mirth Connect exporter    MQTT blackbox exporter    RabbitMQ exporter    RabbitMQ Management Plugin exporter# Storage---存储    Ceph exporter    Ceph RADOSGW exporter    Gluster exporter    Hadoop HDFS FSImage exporter    Lustre exporter    ScaleIO exporter# HTTP---网站服务    Apache exporter    HAProxy exporter (official)    Nginx metric library    Nginx VTS exporter    Passenger exporter    Squid exporter    Tinyproxy exporter    Varnish exporter    WebDriver exporter# APIs    AWS ECS exporter    AWS Health exporter    AWS SQS exporter    Cloudflare exporter    DigitalOcean exporter    Docker Cloud exporter    Docker Hub exporter    GitHub exporter    InstaClustr exporter    Mozilla Observatory exporter    OpenWeatherMap exporter    Pagespeed exporter    Rancher exporter    Speedtest exporter# Logging---日志    Fluentd exporter    Google"s mtail log data extractor    Grok exporter# Other monitoring systems    Akamai Cloudmonitor exporter    Alibaba Cloudmonitor exporter    AWS CloudWatch exporter (official)    Cloud Foundry Firehose exporter    Collectd exporter (official)    Google Stackdriver exporter    Graphite exporter (official)    Heka dashboard exporter    Heka exporter    InfluxDB exporter (official)    JavaMelody exporter    JMX exporter (official)    Munin exporter    Nagios / Naemon exporter    New Relic exporter    NRPE exporter    Osquery exporter    OTC CloudEye exporter    Pingdom exporter    scollector exporter    Sensu exporter    SNMP exporter (official)    StatsD exporter (official)# Miscellaneous---其他    ACT Fibernet Exporter    Bamboo exporter    BIG-IP exporter    BIND exporter    Bitbucket exporter    Blackbox exporter (official)    BOSH exporter    cAdvisor    Cachet exporter    ccache exporter    Confluence exporter    Dovecot exporter    eBPF exporter    Ethereum Client exporter    Jenkins exporter    JIRA exporter    Kannel exporter    Kemp LoadBalancer exporter    Kibana Exporter    Meteor JS web framework exporter    Minecraft exporter module    PHP-FPM exporter    PowerDNS exporter    Presto exporter    Process exporter    rTorrent exporter    SABnzbd exporter    Script exporter    Shield exporter    SMTP/Maildir MDA blackbox prober    SoftEther exporter    Transmission exporter    Unbound exporter    Xen exporter# Software exposing Prometheus metrics---Prometheus度量指标    App Connect Enterprise    Ballerina    Ceph    Collectd    Concourse    CRG Roller Derby Scoreboard (direct)    Docker Daemon    Doorman (direct)    Etcd (direct)    Flink    FreeBSD Kernel    Grafana    JavaMelody    Kubernetes (direct)    Linkerd

0.9 Prometheus对kubernetes的监控

对于Kubernetes而言，我们可以把当中所有的资源分为几类：

因此，如果要构建一个完整的监控体系，我们应该考虑，以下5个方面：

1 Prometheus 监控 Spring Cloud Gateway

1.1 简述

对API网关的监控也是相当必要的。

1.2 配置步骤

1.2.1 Maven 依赖

      org.springframework.boot      spring-boot-starter-actuator      ${springboot.version}          io.micrometer      micrometer-registry-prometheus      runtime
  • 需要注意的是micrometer-registry-prometheus的版本号需要跟spring-boot-dependencies中定义的保持一致。
  • Springboot较高版本的定义统一在micrometer-bom中，低版本的直接在spring-boot-dependencies中定义。

1.2.2 配置文件 application.yaml [local or nacos]

--- # 暴露监控端点 配置management:  endpoints:    # web端点配置属性    web:      # 默认端点前缀为/actuator，可修改      base-path: /actuator      exposure:        # 包含端点，全用直接使用"*"即可，多个场景["prometheus","health"]        include: [ "prometheus","health" ]        # 排除端点        exclude: [ "shutdown" ]    # JMX 端点配置属性    jmx:      exposure:        include: [ "prometheus" ]        exclude: [ "shutdown" ]  metrics:    tags:      application: ${spring.application.name}    export:      prometheus:        descriptions: true        enabled: true

按照实际使用情况，开放对应监控端点即可，为了保护应用安全，不使用的不开启

spring-cloud-gateway (embed : netty server)

spring-boot (embed : tomcat server)

1.2.3 Prometheus 相关配置

prometheus.yml配置

# consul服务发现配置  - job_name: "api_gatway"    consul_sd_configs:      - server: "10.0.107.55:8500" #consul的服务地址        services: ["api_gateway"]    relabel_configs:      - source_labels: ["__meta_consul_tags"]        regex: .*api_gateway.*        action: keep      - regex: __meta_consul_service_metadata_(.+)        action: labelmap    # 指标标签兼容，spring cloud  gateway 3.x版本前缀加了spring_cloud_    metric_relabel_configs:      - source_labels: [__name__]        regex: "gateway(.*)"        target_label: "__name__"        replacement: "spring_cloud_gateway$1"# file_sd服务发现配置  - job_name: "api_gateway"    file_sd_configs:      - files:        - "./api_gateway_config/*.json"        refresh_interval: 15s    # 指标标签兼容，spring cloud  gateway 3.x版本前缀加了spring_cloud_    metric_relabel_configs:      - source_labels: [__name__]        regex: "gateway(.*)"        target_label: "__name__"        replacement: "spring_cloud_gateway$1"

所以，在prometheus配置文件中使用metric_relabel_configs对指标进行统一处理

1.2.4 调用 Actuator API

1.2.5 Grafana面板

官方面板：

  • https://github.com/spring-cloud/spring-cloud-gateway/blob/main/docs/src/main/asciidoc/gateway-grafana-dashboard.json

Grafana中的面板：

  • https://grafana.com/grafana/dashboards/11506-spring-cloud-gateway/ 编号11506

grafana官方提供的仅支持2.x的gateway，对于3.x的gateway存在问题。

因此，我们在使用面板的时候同时兼容了2.x和3.x版本，需要根据gateway官方的面板进行自定义。自定义面板：

1.2.6 指标选取

指标PromQL
运行状态up
近5分钟QPSsum by(instance) (rate(spring_cloud_gateway_requests_seconds_count{uri!~“.actuator.”}[5m]))
近5分钟请求失败次数sum by(instance) (increase(spring_cloud_gateway_requests_seconds_count{outcome!=“SUCCESSFUL”}[5m]))

X 参考文献

推荐内容