文章目录

Prometheus简介

一. 概述

Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包 。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。现在，它是一个独立的开源项目，并且独立于任何公司进行维护。为了强调这一点并阐明项目的治理结构，Prometheus 于2016年加入了 Cloud Native Computing Foundation，这是继Kubernetes之后的第二个托管项目。

Prometheus 基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供 HTTP 接口就可以接入监控系统，不需要任何 SDK 或者其他的集成过程。这样做非常适合虚拟化环境比如 VM 或者 Docker 。

二、优势

  1. 易于管理

    • Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖（数据库，缓存等等）；
    • 唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。

  2. 强大的查询语言PromQL

    • Prometheus 内置一个强大的数据查询语言 PromQL，通过 PromQL 可以实现对监控数据的查询、聚合。
    • 同时 PromQL 也被应用于数据可视化（如 Grafana）以及告警中。

  3. 高效

  4. 可扩展

    • Prometheus 支持联邦集群，可以让多个 Prometheus 实例产生一个逻辑集群；
    • 当单实例 Prometheus 处理的任务量过大时，通过使用功能分区（sharding）+ 联邦集群（federation）可以对其进行扩展。

  5. 易于集成

    • 目前官网提供了多种语言的客户端 SDK，基于这些 SDK 可以快速让应用程序纳入到监控系统中，同时还支持与其它的监控系统集成。

  6. 可视化

    • Prometheus Server 自带一个 UI，通过这个 UI 可以方便对数据进行查询和图形化展示；
    • 同时还可以对接 Grafana 可视化工具展示精美监控指标。

三、特点（官方文档）

  • 具有由指标名称和键/值对标识的时间序列数据的多维数据模型
  • PromQL，一种灵活的查询语言
  • 不依赖分布式存储（指的是普罗米修斯监控应用本身，不是说它不支持对分布式场景进行监控）
    时间序列收集通过HTTP上的拉取模型（就是前面的 pull）进行
  • 通过中间网关（就是前面的gateway）支持推送时间序列（就是前面的push）
  • 通过服务发现或静态配置发现目标
  • 多种图形和仪表板支持模式
    也就是实际上Prometheus本身并不做直接监控，只是做了一个监控整合，把监控信息获取，数据分析，告警，前端界面等整合到一起了。

三、基本框架

在这里插入图片描述
如上图，Prometheus 主要由以下部分组成：

  • Prometheus：主要是负责存储、抓取、聚合、查询方面。
  • Prometheus server：用于采集和存取时间序列数据。
  • Alertemanager：主要是负责实现报警功能。
  • Push gateway：主要是实现接收有 Client-push 过来的指标数据，在指定的时间间隔，有主程序来抓取（主要用于支持短期（Short-lived jobs）的作业）。
  • *_exporter：主要是负责采集物理机、中间件的信息，收集目标对象（host, container…）的性能数据，并通过HTTP接口提供给Prometheus Server。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。
  • PromQL：是Prometheus内置了一个强大的数据查询语言
  • Grafana：可视化的工具
  • Clienl Library：客户端库, 目的在于为那些期望原生提供InstrumenLalion功能的应用程序提供便捷的开发途径
  • Service discovery： 动态发现待监控的Targct,从而完成监控配置的重要组件,在容器化环境中尤为有用;该组件目前由Promctheus Server内建支持。
  • Short-lived jobs：瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用

PushGateway：应对部分push场景的组件可选组件，这部分监控数据先推送到Push Gateway上，然后再由Prometheus Server端拉取 。用于存在时间较短，可能在Prometheus来拉取之前就消失了的 jobs

Prometheus Server

Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。

Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。

其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。

最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。

Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。

Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。

Exporters

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

  • 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
  • 间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

Push Gateway

由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。

当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。

Prometheus抓取数据的两种模式 :

  • push 模式 ：这种模式我们可以灵活的在被监控端使用各种语言编写数据采集脚本，通过PushGateway传输给Prometheus，传输方式为http

  • pull 模式 ：我们直接使用采集数据客户端xxx_exporters将数据传输给Prometheus，已经有很多xxx_exporters详见官档。

Alert Manager(告警)

抓取异常值, pro通过告警机制发现和发送警示

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

五、工作原理

在这里插入图片描述

  1. Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
  2. Prometheus server 把采集到的监控指标数据通过 TSDB存储到本地HDD/ssD中。
  3. Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发 送到Alertmanager。
  4. Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
  5. Prometheus 自带的Web UI 界面提供 PromQL 查询语言，可查询监控数据。
  6. Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。

六、Prometheus的数据类型

Prometheus将所有采集到的样本数据以时间序列（time-series）的方式保存在内存数据库中，并定时保存在硬盘上。时间序列中的每一个样本由以下三部分组成:

  • 指标(metric)：metric name和描述当前样本特征的labelsets组成，参考格式如 {=, …}；，其中metric name的命名规则为：应用名称开头_监测对像_数值类型_单位。
    举例，大括号中为标签，这个例子就可以理解为3条时间序列（虽然指标名称相同，但标签不同）
    node_disk_io_now{device="dm-0",instance="localhost:9100",job="node"}
node_disk_io_now{device="sda",instance="localhost:9100",job="node"}
node_disk_io_now{device="sr0",instance="localhost:9100",job="node"}
  • 时间截(timestamp)：一个精确到毫秒的时间截；
  • 样本值(value)：一个float64的浮点类型数据表示当前的样本值。

采用普罗米修斯的四种类型指标

  • Counter：递增的计数器
    适合：API 接口请求次数，重试次数。
  • **Gauge：**可以任意变化的数值
    适合：cpu变化，类似波浪线不均匀。
  • **Histogram：**对一段时间范围内数据进行采样，并对所有数值求和与统计数量、柱状图
    　　适合：将web 一段时间进行分组，根据标签度量名称，统计这段时间这个度量名称有多少条。
    　　适合：某个时间对某个度量值，分组，一段时间http相应大小，请求耗时的时间。
  • Summary：与Histogram类似,Summary和Histogram十分相似
    常用于跟踪事件发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。它提供一个 quantiles的功能，可以按%比划分跟踪的结果。可以通过PromQL语句对这些指标进行分析，如：
    查询当前系统中，访问量前10的HTTP地址：
topk(10, http_requests_total)
Counter类型

其工作方式和计数器一样，只增不减（除非系统发生重置）。常见的监控指标，如机器的启动时间（node_cpu），HTTP访问量（http_requests_total）等。

Gauge

**仪表类型的指标，侧重于反应系统的当前状态，样本数据可增可减。**如CPU使用率（node_memory_MemFree，主机当前空闲的内容大小），内存使用率（node_memory_MemAvailable，可用内存大小），集群节点个数，大部分监控数据都是这种类型的。

Histogram

**也就是直方图类型的metric, 能够分组分区间显示指标的信息。**例如，统计延迟在0 ~ 10ms之间的请求数有多少而10~20ms之间的请求数就可采用这种方式。注意他与summary的区别。

summary

好像不是很好翻译，个人认为是表示分位数（quantile）的信息。分位数0.5表示前50%的数据是什么水平，现实生活中的例子比如班上所有学生身高的中位数，同样的分位数0.9表示前90%身高的划分位置。

七、参考资料

  1. Prometheus（普罗米修斯）监控架构简介
  2. prometheus的数据类型介绍
  3. Prometheus 基础入门 （一）
  4. 采用普罗米修斯（Prometheus ）监控各个指标的含义，类型，以及格式
  5. Prometheus监控系列–“普罗米修斯“ 入门 | 初识 | 简述 | 超详细
# prometheus # 运维 # 运维开发 # 信息可视化
Logo
GitCode 开源社区

旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。

更多推荐

cover

GitTalk | 使用面向业务的狮偶编程语言提升开发效率

avatar GitCode 开源社区
cover

GitTalk | DevUI Suits 场景解决方案

avatar GitCode 开源社区
cover

GitTalk | DevUI Admin 前端项目构建

avatar GitCode 开源社区