监控系统的入门搭建 Prometheus（普罗米修斯）基础理论篇

时间 2019-11-30

标签监控系统入门搭建 prometheus 普罗基础理论繁體版

原文原文链接

监控系统的入门搭建 Prometheus（普罗米修斯）

基础理论篇

对于普罗米修斯的介绍能够参考这篇文章，写的很是好，很是权威，不逊色于官方文档，能够说是中文环境下最好的参考资料html

Prometheus 入门与实践

吴莉, 殷一鸣, 和蔡林
2018 年 5 月 30 日发布node

我想写出一篇超过这篇文章显然以如今的实力是不太现实web

毕竟是很权威的文章，这种文章的通病就是太过学术，没有了解过的人很难读过就能明确的理解。docker

那么就有我本身的理解来说讲Prometheus的各个方面的问题数据库

可能有的观点是错误的，因此仍是把他当成茶余饭后的休闲文章看看吧 json

Prometheus到底在个人服务器，kvm，或者docker上作了什么？

首先要解答这个问题，咱们必须了解一个重要的概念 api

Metric 服务器

这个官方文档出现频率的最高的单词架构

谷歌机翻翻译为度量，我以为翻做指标可能更加贴切运维

其实它的本质就是存在某一款数据库的一条记录

什么是metric

这篇文章介绍的也很详细

总之就是监控系统经过服务将某个监控数据存入某个数据库的某条记录

这条记录能够动态的增长字段，最终获得了通用的metric结构，name，label(与tag{}同义仅名字不一样，在Prometheus中为label)，value，timestamp

咱们将额外须要扩展增长的数据生成json存入label{} ，这样能够方便的扩展字段，而不用每次都修改数据库的表结构

(PS:在Prometheus中提供四种 Metric 类型 Counter, Gauge, Histogram,Summary)

具体的内容我就再也不赘述，能够经过上文来了解Metric

那么了解Metric，咱们还须要了解alert

Alert其实就是警报，咱们的监控系统就是为了在集群出现问题的时候

及时向运维人员报告

那么Prometheus究竟对咱们的机器作了什么？

它的组成

Prometheus Server:

用于收集和存储时间序列数据。

Client Library:

客户端库，为须要监控的服务生成相应的 metrics 并暴露给 Prometheus server。

当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。Push Gateway: 主要用于短时间的 jobs。

因为这类 jobs 存在时间较短，可能在 Prometheus 来 pull 以前就消失了。

为此，此次 jobs 能够直接向 Prometheus server 端推送它们的 metrics。

这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，须要使用 node exporter。

Exporters:

用于暴露已有的第三方服务的 metrics 给 Prometheus。

Alertmanager:

从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。

常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。

一些其余的工具：

。。。。。。。。

Prometheus架构图

其中jobs/Eeporters就是生成metric的，而后咱们的Prometheus server从它们那按期获取metrics，或者一些短暂的jobs生成的metric推送给Pushgateway

再由Pushgateway推送给Prometheus server，或者其余机器的Prometheus server发给本机的Prometheus server，

总之咱们想获取的的数据源在Prometheus server中汇总后按照咱们规定的报警机制（alert.rules）推送警报到Alertmanager或者刷新时间序列（就是不报警，相安无事）

最后Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。在图形界面中，可视化采集数据（这一步咱们放在grafana上去作）

(PS:

instance 和 jobs.的区别

instance:

一个单独 scrape 的目标，通常对应于一个进程。

jobs:

一组同种类型的 instances（主要用于保证可扩展性和可靠性）)

例如：清单 1. job 和 instance 的关系

job: api-server
 
    instance 1: 1.2.3.4:5670
    instance 2: 1.2.3.4:5671  
    instance 3: 5.6.7.8:5670
    instance 4: 5.6.7.8:5671

当 scrape 目标时，Prometheus 会自动给这个 scrape 的时间序列附加一些标签以便更好的分别，例如： instance，job。

下面以实际的 metric 为例，对上述概念进行说明。

如上图所示，这三个 metric 的名字都同样，他们仅凭 handler 不一样而被标识为不一样的 metrics。这类 metrics 只会向上累加，是属于 Counter 类型的 metric，且 metrics 中都含有 instance 和 job 这两个标签

到此咱们已经了解了Prometheus 最基础的个概念，下一篇咱们就要小试牛刀，试试实际运行