带你读《Prometheus监控实战》之二:Prometheus简介

点击查看第一章
点击查看第三章
第2章

Prometheus简介

在本章中,我们将介绍Prometheus及其起源,并概述以下内容:

  • Prometheus的发展
  • Prometheus架构和设计
  • Prometheus数据模型
  • Prometheus生态系统

这会让你了解Prometheus是什么,并理解它在监控领域的适用场景。
本书重点介绍Prometheus 2.0及更高版本。本书的大部分内容并不适用于早期版本。

2.1 Prometheus起源

很久以前,加利福尼亚州山景城有一家名为Google的公司。该公司推出了大量产品,其中最著名的是广告系统和搜索引擎平台。为了运行这些不同的产品,该公司建立了一个名为Borg的平台。Borg系统是:“一个集群管理器,可以运行来自成千上万个不同应用程序的成千上万个作业,它跨越多个集群,每个集群都有数万台服务器。”开源容器管理平台Kubernetes的很多部分都是对Borg平台的传承。在Borg部署到Google后不久,该公司意识到这种复杂性需要一个同等水平的监控系统。Google建立了这个系统并命名为Borgmon。Borgmon是一个实时的时间序列监控系统,它使用时间序列数据来识别问题并发出警报。
Borg和Borgmon都没有开源,直到最近才有机会了解它们的工作原理。你可以在Google SRE手册的实用警报章节中阅读更多相关内容。
Prometheus的灵感来自谷歌的Borgmon。它最初由前谷歌SRE Matt T. Proud开发,并转为一个研究项目。在Proud加入SoundCloud之后,他与另一位工程师Julius Volz合作开发了Prometheus。后来其他开发人员陆续加入了这个项目,并在SoundCloud内部继续开发,最终于2015年1月将其发布。
与Borgmon一样,Prometheus主要用于提供近实时的、基于动态云环境和容器的微服务、服务和应用程序的内省监控。SoundCloud是这些架构模式的早期采用者,而Prometheus的建立也是为了满足这些需求。如今,Prometheus被更多的公司广泛使用,通常用来满足类似的监控需求,但也用来监控传统架构的资源。
Prometheus专注于现在正在发生的事情,而不是追踪数周或数月前的数据。它基于这样一个前提,即大多数监控查询和警报都是从最近的(通常是一天内的)数据中生成的。Facebook在其内部时间序列数据库Gorilla的论文中验证了这一观点。Facebook发现85%的查询是针对26小时内的数据。Prometheus假定你尝试修复的问题可能是最近出现的,因此最有价值的是最近时间的数据,这反映在强大的查询语言和通常有限的监控数据保留期上。
Prometheus由开源编程语言Go编写,并且是在Apache 2.0许可证下授权的。它孵化于云原生计算基金会(Cloud Native Computing Foundation)。

2.2 Prometheus架构

Prometheus通过抓取或拉取应用程序中暴露的时间序列数据来工作。时间序列数据通常由应用程序本身通过客户端库或称为exporter(导出器)的代理来作为HTTP端点暴露。目前已经存在很多exporter和客户端库,支持多种编程语言、框架和开源应用程序,如Apache Web服务器和MySQL数据库等。
Prometheus还有一个推送网关(push gateway),可用于接收少量数据—例如,来自无法拉取的目标数据(如临时作业或者防火墙后面的目标)。
关于Prometheus的具体架构如图2-1所示。
带你读《Prometheus监控实战》之二:Prometheus简介

图2-1 Prometheus架构

2.2.1 指标收集

Prometheus称其可以抓取的指标来源为端点(endpoint)。端点通常对应单个进程、主机、服务或应用程序。为了抓取端点数据,Prometheus定义了名为目标(target)的配置。这是执行抓取所需的信息—例如,如何进行连接,要应用哪些元数据,连接需要哪些身份验证,或者定义抓取将如何执行的其他信息。一组目标被称为作业(job)。作业通常是具有相同角色的目标组—例如,负载均衡器后面的Apache服务器集群,它们实际上是一组相似的进程。
生成的时间序列数据将被收集并存储在Prometheus服务器本地,也可以设置从服务器发送数据到外部存储器或其他时间序列数据库。

2.2.2 服务发现

可以通过多种方式来处理要监控的资源的发现,包括:

  • 用户提供的静态资源列表。
  • 基于文件的发现。例如,使用配置管理工具生成在Prometheus中可以自动更新的资源列表。
  • 自动发现。例如,查询Consul等数据存储,在Amazon或Google中运行实例,或使用DNS SRV记录来生成资源列表。

我们将在第5章介绍如何使用各种服务发现方法。

2.2.3 聚合和警报

服务器还可以查询和聚合时间序列数据,并创建规则来记录常用的查询和聚合。这允许你从现有时间序列中创建新的时间序列,例如,计算变化率和比率,或者产生类似求和等聚合。这样就不必重新创建常用的聚合,例如用于调试,并且预计算可能比每次需要时运行查询性能更好。
Prometheus还可以定义警报规则。这些是为系统配置的在满足条件时触发警报的标准,例如,资源时间序列开始显示异常的CPU使用率。Prometheus服务器没有内置警报工具,而是将警报从Prometheus服务器推送到名为Alertmanager(警报管理器)的单独服务器。Alertmanager可以管理、整合和分发各种警报到不同目的地—例如,它可以在发出警报时发送电子邮件,并能够防止重复发送。
我们将在第6章看到有关Alertmanager的更多信息。

2.2.4 查询数据

Prometheus服务器还提供了一套内置查询语言PromQL、一个表达式浏览器(如图2-2所示)以及一个用于浏览服务器上数据的图形界面。
带你读《Prometheus监控实战》之二:Prometheus简介

图2-2 Prometheus表达式浏览器

2.2.5 自治

每个Prometheus服务器都设计为尽可能自治,旨在支持扩展到数千台主机的数百万个时间序列的规模。数据存储格式被设计为尽可能降低磁盘的使用率,并在查询和聚合期间快速检索时间序列。
为了速度和可靠性,建议Prometheus服务器充分使用内存(Prometheus在内存中做很多事)和SSD磁盘。关于SSD的使用可以参考相关视频。

2.2.6 冗余和高可用性

冗余和高可用性侧重弹性而非数据持久性。Prometheus团队建议将Prometheus服务器部署到特定环境和团队,而不是仅部署一个单体Prometheus服务器。如果你确实要部署高可用HA模式,则可以使用两个或多个配置相同的Prometheus服务器来收集时间序列数据,并且所有生成的警报都由可消除重复警报的高可用Alertmanager集群来处理。Prometheus冗余架构如图2-3所示。
带你读《Prometheus监控实战》之二:Prometheus简介

图2-3 Prometheus冗余架构

我们将在第7章介绍如何实现此配置。

2.2.7 可视化

可视化通过内置表达式浏览器提供,并与开源仪表板Grafana集成。此外,Prometheus也支持其他仪表板。
我们将在第4章了解这种集成。

2.3 Prometheus数据模型

正如之前所述,Prometheus收集时间序列数据。为了处理这些数据,它使用一个多维时间序列数据模型。这个时间序列数据模型结合了时间序列名称和称为标签(label)的键/值对,这些标签提供了维度。每个时间序列由时间序列名称和标签的组合唯一标识。

2.3.1 指标名称

时间序列名称通常描述收集的时间序列数据的一般性质—例如,website_visits_total为网站访问的总数。
名称可以包含ASCII字符、数字、下划线和冒号。

2.3.2 标签

标签为Prometheus数据模型提供了维度。它们为特定时间序列添加上下文。例如,total_website_visits时间序列可以使用能够识别网站名称、请求IP或其他特殊标识的标签。Prometheus可以在一个时间序列、一组时间序列或者所有相关的时间序列上进行查询。
标签共有两大类:插桩标签(instrumentation label)和目标标签(target label)。插桩标签来自被监控的资源—例如,对于与HTTP相关的时间序列,标签可能会显示所使用的特定HTTP动词。这些标签在由诸如客户端或exporter抓取之前会被添加到时间序列中。目标标签更多地与架构相关—它们可能会识别时间序列所在的数据中心。目标标签由Prometheus在抓取期间和之后添加。
时间序列由名称和标签标识(尽管从技术上讲,名称本身也是名为__name__的标签)。如果你在时间序列中添加或更改标签,那么Prometheus会将其视为新的时间序列。
你可以理解label就是键/值形式的标签,并且新的标签会创建新的时间序列。
标签名称可以包含ASCII字符、数字和下划线。
带有__前缀的标签名称保留给Prometheus内部使用。

2.3.3 采样数据

时间序列的真实值是采样(sample)的结果,它包括两部分:

  • 一个float64类型的数值
  • 一个毫秒精度的时间戳

2.3.4 符号表示

结合这些元素,我们可以看到Prometheus如何将时间序列表示为符号(notation),如下所示。

代码清单2-1 时间序列符号

带你读《Prometheus监控实战》之二:Prometheus简介
例如,带有标签的total_website_visits时间序列可能如下所示。

代码清单2-2 时间序列示例

带你读《Prometheus监控实战》之二:Prometheus简介
首先是时间序列名称,后面跟着一组键/值对标签。通常所有时间序列都有一个instance标签(标识源主机或应用程序)以及一个job标签(包含抓取特定时间序列的作业名称)。
这与OpenTSDB使用的符号大致相同,受到了Borgmon的影响。

2.3.5 保留时间

Prometheus专为短期监控和警报需求而设计。默认情况下,它在其数据库中保留15天的时间序列数据。如果要保留更长时间的数据,则建议将所需数据发送到远程的第三方平台。Prometheus能够写入外部数据存储,我们将在第7章看到更多相关内容。
2.4 安全模型
Prometheus可以通过多种方式进行配置和部署,关于安全有以下两个假设:

  • 不受信任的用户将能够访问Prometheus服务器的HTTP API,从而访问数据库中的所有数据。
  • 只有受信任的用户才能访问Prometheus命令行、配置文件、规则文件和运行时配置。

从Prometheus 2.0开始,默认情况下某些HTTP API的管理功能被禁用。
因此,Prometheus及其组件不提供任何服务器端的身份验证、授权或加密。如果你在一个更加安全的环境中工作,则需要自己实施安全控制—例如,通过反向代理访问Prometheus服务器或者正向代理exporter。由于不同版本的配置会潜在地发生较大变化,因此本书没有记录如何执行这些操作。

2.5 Prometheus生态系统

Prometheus生态系统由Prometheus项目本身提供的组件以及丰富的开源工具和套件组成。生态系统的核心是Prometheus服务器,我们将在下一章进行详细介绍。此外还有Alertmanager,它为Prometheus提供警报引擎并进行管理。
Prometheus项目还包括一系列exporter,用于监控应用程序和服务,并在端点上公开相关指标以进行抓取。核心exporter支持常见工具,如Web服务器、数据库等。许多其他exporter都是开源的,你可以从Prometheus社区查看。
Prometheus还发布了一系列客户端库,支持监控由多种语言编写的应用程序和服务。它们包括主流编程语言,如Python、Ruby、Go和Java。其他客户端库也可以从开源社区获取。

2.6 参考链接

2.7 小结

本章我们介绍了Prometheus的基本概念,以及Prometheus架构、Prometheus数据模型和Prometheus生态系统等方面的内容。
在下一章,我们将安装并配置Prometheus,并收集我们的第一个指标。

上一篇:Asp.Net应用程序中长时间装载页面时显示进度条


下一篇:带你读《Prometheus监控实战》之三:安装和启动Prometheus