【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监控解决方案。

相关推荐
齐 飞1 小时前
MongoDB笔记01-概念与安装
前端·数据库·笔记·后端·mongodb
LunarCod1 小时前
WorkFlow源码剖析——Communicator之TCPServer(中)
后端·workflow·c/c++·网络框架·源码剖析·高性能高并发
码农派大星。2 小时前
Spring Boot 配置文件
java·spring boot·后端
杜杜的man3 小时前
【go从零单排】go中的结构体struct和method
开发语言·后端·golang
幼儿园老大*3 小时前
走进 Go 语言基础语法
开发语言·后端·学习·golang·go
llllinuuu3 小时前
Go语言结构体、方法与接口
开发语言·后端·golang
cookies_s_s3 小时前
Golang--协程和管道
开发语言·后端·golang
为什么这亚子3 小时前
九、Go语言快速入门之map
运维·开发语言·后端·算法·云原生·golang·云计算
想进大厂的小王3 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
customer084 小时前
【开源免费】基于SpringBoot+Vue.JS医院管理系统(JAVA毕业设计)
java·vue.js·spring boot·后端·spring cloud·开源·intellij-idea