【Monitoring】Prometheus工作原理以及Prometheus架构介绍

【参考】

【本文主要内容】

  • Prometheus是什么?使用案例?
  • Prometheus监控的目标是谁?Prometheus监控的内容是什么?
  • Prometheus收集Metrics的方式?Exporters的作用?
  • prometheus.yml
  • Alert Manager
  • PromQL

1. Prometheus介绍

Prometheus是一款用来做监控和预警的开源的项目,最早是SoundCloud公司的项目,始于2012年。Prometheus不仅可以工作在传统的模式上(即部署在服务器),也可以工作在容器应用中,如Kubernetes。

过去几年,在容器端,Prometheus作为Monitoring工具尤其重要。原因是容器化的服务使得DevOps工作变得复杂,假设我们有很多很多个pod运行在多个Prod clusters上,那么这些pod的健康情况的监控就显得很重要,如:有没有出现响应延迟,负载过重,资源不足,出现了Error等等。

具体举例,如Prod上的某个pod的out of memory错误,间接的导致了数据库的两个pod出问题了,然后这两个db pod为用户登陆验证提供服务,那么从而使得用户在UI上无法登陆,在这种情况下,我们需要快速定位哪里出了问题?但问题的关键是如果我们有监控系统,那么就可以快速知道哪些pod是不健康的,甚至如果有某种预警系统,当某个pod快出现资源枯竭的问题时,就可以先发出警报(预警功能)。

2. Prometheus工作原理

Prometheus Server主要由三个部分组成:

  • 存储(Storage):主要用来存储metrics(指标相关)数据,是基于时间序列的数据库。
  • 数据的拉取(Retrieval):从应用中(或是其它目标服务器)拉取metrics数据,然后存入到它自己的数据库中。
  • Http Server:使用PromQL,从它自己的数据库中检索数据,入口可以是Promethous Web UI或是其它的UI展示平台如Grafana。
2.1 Prometheus的监控目标

Prometheus的监控目标可以是我们的应用服务,也可以是其它对象如Linus或Windows服务器或Apache服务器,DB数据库等等。

2.2 Prometheus的监控内容

Prometheus的监控内容(即Metrics),针对不同的目标也不尽相同,针对服务器可以是CPU的状态,内存或磁盘的使用情况。或对于应用程序来说,监控的内容可以是服务请求的数据,请求的时间,异常的数量等。

以下是Prometheus的Metrics数据格式例子

通常由两部分组成:

  • HELP:用来描述这个Metrics的内容
  • TYPE:用来记录Metrics的内容,主要分三类:
    • 计数类的指标(Counter):主要记录了某个事件发生的次数,如应用的异常发生次数。
    • 仪表盘(Gauge):主要记录了某个目标目前的值是多少?如目前的CPU使用情况。
    • 直方图(Histogram):在一段时间范围内对数据进行采样,并将其计入可配置的存储中。
2.3 Prometheus收集数据的方式

Prometheus通过HTTP的请求来收集数据,默认的地址为{目标应用地址}/metrics,换句话说我们的应用服务需要暴露出/metrics端点以供Prometheus来拉取数据。

并且这个端点的数据必须是Prometheus认可的数据格式(具体在#2.2中有介绍)。

3. Exporters

有些应用服务默认情况下就会暴露/metrics端点,而另外一些应用没有这样的功能,所以需要Exporter,来从目标应用服务中拉取数据,然后转化为Prometheus能接受的数据格式,然后暴露出/metrics端点。

地址:prometheus.io/docs/instru...,上面列了很多第三方的Exporters,也有一些是官方提供的,如:

  • DB相关:如MongoDB exporter, PostgreSQL exporter,MySQL server exporter等
  • 硬件相关:Disk usage exporter等
  • 消息中间件相关:IBM MQ exporter, RabbitMQ exporter等
  • JAVA相关:Java GC exporter, JMS expoter等

这里只列了非常少的一部分,总之exporter种类繁多,有需要的去官网上查询。

3.1 监控Linux服务器

比如我们想要监控一台Linux服务器,那么可以:

  • 下载Node exporter
  • 解压并执行
  • exporter会转化服务器上的数据为metrics
  • 暴露/metrics端点
  • 在Prometheus上配置该端点,用来拉取数据。
3.2 以Pod的形式运行Exporters

Exporters也可以在Docker容器中,比如我们想要监控一台运行在Kubernetes上的mysql,那么我们可以另外运行exporter(也是一个pod),用来转化Mysql的监控数据并暴露端点。

4. 为什么Prometheus是以"拉取"的形式来收集数据?

有些监控系统是以应用主动推送的方式来收集Metrics数据,如Amazon Cloud Watch,New Relic。而这样的形式有时候会造成网络拥堵或是使得监控服务负载比较大。别外推送的方式需要在应用端额外安装工具以达到推送数据的功能。

Prometheus采取拉取的形式来收集数据,可以使用多个Prometheus实例来拉取数据,另外一个优势是Prometheus服务端可以很快速的感知应用端是否是运行状态。

但有些应用比如短时间短的job,可能Prometheus没办法定期的拉取数据(因为它跑的时间太短了),这时候Prometheus有个组件叫Pushgateway,以供应用可以主动推送数据到这个组件上,但这种方式不应该作为常规的数据收集方式。

5. Prometheus配置

Prometheus怎么知道什么时候需要拉取数据?以及拉取什么样的数据?需要在prometheus.yml中进行配置。

首先是global相关的配置,定义了一些全局的信息,如多久拉取一次Metrics数据(比如每隔15秒)?拉取数据时的超时时间为多少(如10秒)等等。这些值可以在具体配置的单个targets里进行覆盖重写:

yaml 复制代码
global:
  scrape_interval:     15s # How frequently to scrape targets by default.
  evaluation_interval: 15s # How frequently to evaluate rules.
  scrape_timeout:      10s

rule_files,定义了一些规则的文件。如收集Metrics的规则,或者定义一些预警规则(如CPU到达70%后发出Alerts),这些规则多久执行依赖于上述global的定义:

shell 复制代码
rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:定义了Prometheus需要监控的数据源。如以下job_name=prometheus的,则是拉取prometheus服务本身的Metrics数据,这里配置的localhost:9090就是prometheus服务本身的地址,prometheus服务默认已经实现了/metrics端点。 也可以定义别的数据源,如job_name=node_exporter,每隔1分钟从localhost:9100/methics端点拉取一次数据。

yaml 复制代码
scrape_configs:
  - job_name: prometheus
    static_configs:
    - targets: ['localhost:9090']
  - job_name: node_exporter
    scrape_interval: 1m
    scrape_timeout: 1m
    static_configs:
    - targets: ['localhost:9100']

本文介绍的比较简单,关于Prometheus到时候具体的配置,参考

6. Alert Manager

Prometheus另外一个重要的组件是Alert Manager,可以用来收集Prometheus上的alerts。

具体来说,Prometheus服务端从prometheus.yml中读取alert规则的定义,然后如果发现满足了某个alert规则被触发,则会将alerts推送给Alert Manager,以便后续进行更具体的通知,如发邮件等。

7. Prometheus数据存储/查询

Prometheus的籹据存储,可以放本地磁盘,也可以放远程的存储中。数据存储的方式是时间序列型的。

数据的查询可以通过Prometheus的Web UI页面,通过PromQL(即Prometheus Query Langurage)进行查询。 也可以通过另外的可视化工具进行展示,如Grafana(其底层依旧使用了PromQL进行查询)。

PromQL示例:http_requests_total{status!~"4.."} --> 返回所有HTTP状态不等于4xx的http_requests_total metrics数据。

更多关于PromQL的示例,参考官网:prometheus.io/docs/promet...

将Prometheus metrics数据展示在Grafana上:

8. Prometheus布署特点

作为监控系统,首先必要的是自已的服务必须是比较可靠的,基于此,Prometheus可以单机使用(stand-alone)或者叫独立的(self-containing),即就算是别的基础设施(如DB等)宕机了,作为监控系统的Prometheus依旧可以独立工作,并且不需要大量的设置。

正因为以上的特点,Prometheus很难作为集群进行部署。

建议:所以我们可以增加Prometheus的服务数据(单机部署),并且控制metrics的数量。

9. Prometheus可以很好的运行在Docker和Kubernetes上

关于Prometheus运行在Kubernetes上,可以做到不需要额外的配置,即可收集必要的metrics,是比较成熟的Prod监控解决方案。

相关推荐
小蒜学长19 小时前
springboot多功能智能手机阅读APP设计与实现(代码+数据库+LW)
java·spring boot·后端·智能手机
追逐时光者20 小时前
精选 4 款开源免费、美观实用的 MAUI UI 组件库,助力轻松构建美观且功能丰富的应用程序!
后端·.net
你的人类朋友20 小时前
【Docker】说说卷挂载与绑定挂载
后端·docker·容器
间彧21 小时前
在高并发场景下,如何平衡QPS和TPS的监控资源消耗?
后端
间彧21 小时前
QPS和TPS的区别,在实际项目中,如何准确测量和监控QPS和TPS?
后端
间彧21 小时前
消息队列(RocketMQ、RabbitMQ、Kafka、ActiveMQ)对比与选型指南
后端·消息队列
brzhang1 天前
AI Agent 干不好活,不是它笨,告诉你一个残忍的现实,是你给他的工具太难用了
前端·后端·架构
brzhang1 天前
一文说明白为什么现在 AI Agent 都把重点放在上下文工程(context engineering)上?
前端·后端·架构
Roye_ack1 天前
【项目实战 Day9】springboot + vue 苍穹外卖系统(用户端订单模块 + 商家端订单管理模块 完结)
java·vue.js·spring boot·后端·mybatis
AAA修煤气灶刘哥1 天前
面试必问的CAS和ConcurrentHashMap,你搞懂了吗?
后端·面试