【参考】
- How Prometheus Monitoring works | Prometheus Architecture explained:www.youtube.com/watch?v=h4S... --> 本文主要是对这个视频的内容的总结与学习
- Prometheus官网:prometheus.io/
- Prometheus配置学习,官网:prometheus.io/docs/promet...
- PromQL学习,官网:prometheus.io/docs/promet...
【本文主要内容】
- 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到时候具体的配置,参考:
- 官方文档:prometheus.io/docs/promet...
- 其它写的比较好的博文:blog.csdn.net/w2009211777...
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监控解决方案。