Prometheus入门介绍


【编者的话】本文是Prometheus的一篇入门文章,介绍了Prometheus的来源、特点、优势,以及一些关键概念和核心模块的功能。

几个月以前,我开始探索一个功能强大的DevOps平台/技术——Kubernetes,随着我开始深入分析Kubernetes的工作原理以及如何更好的使用它,经常在博客里看到术语“Pormetheus”,那么什么是Prometheus,为何被大家如此广泛地提及呢?

在这篇博文中,我希望能给你提供一个完整的入门指南,帮助你理解Prometheus是什么,有何用处,以及如何使用它。我将不会深入分析如何安装Prometheus,但是会介绍它的工作原理,使用方法,以及它可以为你和你的团队带来什么益处。

如果你比较着急(如今谁又不是呢:-)),那么请翻到文末阅读概要总结部分,这部分言简意赅地总结了我所讲的所有内容,而且只需要花费你一分钟的时间。

Prometheus是什么?

在希腊神话中,普罗米修斯是不朽的泰坦神之一,他违抗众神旨意,偷走火种给了人类,从而创造了文明。

“好吧,兄弟,故事不错,但这跟软件有什么关系?”

嗯……跟希腊神话很像,Prometheus(本博文的主题)是一个开源监控系统,被设计用于帮助我们了解应用程序和系统的运行情况。

Prometheus由SoundCloud在2012年创建,因为他们当时已有的监控平台已无法满足应用需求。但是直到2016年Prometheus的第一个版本v1才正式对外发布。如今,Prometheus被公认为是CNCF(Cloud Native Computing Foundation)的成员项目。

“很好,现在我知道了古希腊神话,以及Prometheus从何而来,但是它到底是什么呢?”

Prometheus本质上只是另一个度量数据的收集和分析工具,包含3个核心组件:
  • 时序数据库,用于保存所有度量数据。
  • 数据收集器,负责从外部来源拉取指标并将其推入数据库。
  • Web服务器,为配置和查询存储的数据提供简单的Web界面。


如果你像我一样喜欢图形化的系统架构,下面这张图可以帮助理解Prometheus的架构:
Screenshot_1.png

其中:
  • PromSQL,是用于从Prometheus中检索指标的查询语言。我计划以后写一篇详细的博文,向您介绍如何在Grafana中使用度量数据来构建一些功能强大的仪表板。
  • AlertManager(告警管理),允许我们根据Prometheus采样的指标定义告警(比如内存/ CPU使用率过高或请求时延达到峰值)。
  • Pushgateway(推送网关),允许应用和服务将指标推送到Prometheus,而非标准的由Prometheus主动拉取。
  • Service discocery(服务发现),Prometheus在一开始就被设计为只需极少配置即可完成初始安装,以及适于在诸如Kubernetes之类的动态环境中运行。因此它可以对正在运行的服务进行自动发现,并尝试对其应监视的内容作出最佳的猜测。


什么让Prometheus如此与众不同?

在继续下文之前,我想暂停一下,并说出在我看来,Promentheus与其他可能已被你熟知的监控系统之间的关键区别:
  • 大多数监控系统(Amazon CloudWatch,ApplicationInsights,NewRelic等)使用推送机制,即应用程序/服务器等客户端负责将度量数据推送到监控系统。
  • Prometheus则不同,它依赖于应用程序/服务器等客户端提供的简单HTTP接口,以便其数据收集模块可以从客户端拉取度量数据。


但为什么我要在乎这一点呢?

简单来说,这个新模型具备以下几点优势:
  • Prometheus不需要安装任何客户端软件或者配置在目标服务器上,甚至不需要在容器镜像中开启度量数据收集。
  • Prometheus不需要应用程序消耗CPU周期去将度量数据推送到集中收集平台。
  • Prometheus提供了集中的配置和管理控制台,让我们可以看到上一次从各目标系统拉取度量数据的时间信息。
  • Prometheus可以优雅地处理服务失效和不可用的场景。当目标应用程序出现故障,Prometheus可以记录下来,而在推送机制的监控系统中,我们往往不确定为什么没有收到数据,是数据在传输过程中丢失了,还是我们的服务已经死掉了。
  • Prometheus使用时需数据库,因此我们不必保存成千上万条单独的指标记录,相反,我们只需要定期打快照,并比较两次快照之间的变化。这减少了网络流量,以及指标平台的开销。
  • 对于不适用拉取的场景,比如无法长期运行的临时任务,Prometheus提供了推送网关(Pushgateway),以允许应用程序根据需要推送数据,从而可以做到两全其美:-)。


2.gif

Prometheus的度量数据的格式是什么样的?

Prometheus定义了非常好的基于文本的度量数据格式:
Screenshot_2.png

从上图可以看到,这些数据是相对可读的,另外我们还有TYPE和HELP等注释以帮助我们理解。

该示例中包含3个不同的指标(http_server_requests_total,http_server_request_duration_seconds和http_server_exceptions_total),每个指标都有其类型,并负责监控应用程序的特定方面。

关于示例有几个值得注意的点:
  • Prometheus的指标类型非常有限,当前提供3中类型:计数器(counter)、仪表盘(Guage)和直方图(Histogram),不久的将来将会有其他一些新的类型出来。
  • TYPE和HELP注释可以针对每个指标给我们提供用户友好的提示。
  • Prometheus在度量表中类型中具有“标签”的概念(可以理解为帮助我们理解指标的辅助属性)。
  • 标签使用{}语法显示,并可以在http_server_requests_total中看到。
  • Prometheus规定了每种指标类型的命名规范和以及度量单位


Prometheus的指标类型

在写这篇文章的时候,Prometheus支持3中指标类型,分别是:
  • 计数器(counter),样本数据仅能单调递增,一般用于你想知道某个事件发生了多少次的场景。
  • 仪表盘(Guage),代表样本数据可以任意变化,即可增可减。好比汽车的仪表盘,这种类型表示某个指标的当前值。
  • 直方图(Histogram),是最复杂的一种,它将样本数据进行分片,每个样本数据落入不同的桶(bucket),类似表示某件事情花了多长时间,或者某个东西有多大。


关于直方图的一些要点

弄明白这些让我花了不少时间。基本上,直方图是按桶累积的,为了更好的解释,我将对上图中的直方图指标进行细分:
  • 直方图不仅提供分片_bucket指标,同时也提供_sum和_count两个指标。
  • 示例中的应用程序只有1个请求(因为_count的值为1)。
  • 示例中1次请求供花费了0.251396秒(因为_sum的值告诉了我们请求花费的总时间)。
  • 请求共落入6个时间桶(记住我说过的桶是累积的),每个桶代表了一个“小于等于”的时间片,并且被标记为{le="秒数"}。请求共花费0.231396秒,所以被统计进了所有取值大于0.231396的桶中。但是如果我们的请求花费的时间是0.004秒,小于取值为0.005的最小的桶,那么每个桶豆浆显示统计值为1。
  • 有一个标记为{le=" Inf"}的特殊的桶,用来统计所有请求时间大于最大桶对应时间(我们的示例中为10秒)的请求。


度量标签让事情更简单

正如前面所讲,Prometheus指标还支持标签,用于对统计数据其他维度的标识。有效使用标签,可以通过更少的指标提供对数据更深的洞悉。

示例场景

我们希望跟踪程序中发生异常的次数。

如何解决?

我们可以对每个代码片段设置一个统计指标(area_x_error_count),其值随着错误发生而递增。当然这样也可以工作的,但是有以下问题:
  • 每当我们新增一个代码段,我们都需要创建一个新指标。
  • 我们的指标结合会随之膨胀。
  • 当我们查询数据时,我们需要笨拙地写多个查询才能统计所有的错误。


一个使用标签的替代方案

我们为整个应用程序设置一个指标,并使用标签代表不同的代码区域,比如application_error_count{area="x"}。现在我们不需要在每次新增代码时创建新标签。

我们的指标集将只包含很少的指标,而且数据仅在应用标签时才进行分片。

我们的指标被合并为一个关键值,这使得我们可以使用强大的PromSQL来创建复杂的图表来反映我们的应用程序运行情况。

当数据全部收集好之后,接下来会发生什么?

一旦你的度量数据存储在Prometheus,一切都将在你的掌握之中。Prometheus提供了自己的用户界面,允许你对数据进行查询、查看,以及绘制图表:
Screenshot_3.png

Prometheus使用自己的查询语言——PromSQL,一种非常强大的语言,它利用直方图等度量类型为我们提供一些非常有趣的报告功能。

我不打算在这里讨论如何编写查询(因为这是一篇给初学者的博客),但是如果你想学习更多,那么Prometheus的网站上有一些非常有用的PromSQL基础知识的介绍

然而,Prometheus真正的强大之处在于其能够连接到强大的可视化平台,比如Grafana和告警系统PagerDuty,从而为你提供完整的DevOps监控解决方案。

将来我还会再写一篇博文,用于介绍如何将Prometheus和Grafana连接起来,构建度量指标的仪表盘,届时我将深入介绍更多关于PromSQL的细节,以及如何最大限度的利用数据。

概要总结

如果你很忙,不想花时间阅读正篇文章,那么这里有一些非常简略的要点总结:
  • Prometheus是一个功能强大的收集和查询度量数据的工具。
  • Prometheus的工作模式是通过应用程序/服务商提供的HTTP接口定期获取度量数据。
  • Prometheus每次收集度量数据时,会在Prometheus数据库中存储一个度量数据的快照。
  • 通过PromSQL,Prometheus Web界面,或者其他类似Grafana的工具,我们可以查询/分析度量数据快照之间的差异,用以建模/表示数据岁时间变化的趋势。
  • 使用较少的度量名称,但是通过标签来表示度量指标的不同维度(相信我,你会甘心我提供的这个小技巧)。
  • 只有三种度量类型可供使用(计数器、仪表盘和直方图),所以请为作业选择正确的度量类型。
  • 计数器只能递增,并记录事件发生的次数。仪表盘用来跟踪可以增加和减少的数值,就想汽车上的时速仪表盘。
  • 直方图用于将度量数据拆分到可观察的桶。
  • 直方图是累积的,也是最不直观解的度量类型。
  • 在对指标进行命名时,请确保遵循Prometheus的指导原则
  • 请确保遵循Prometheus的指导原则,使用正确的度量单位(比如,度量时间总是使用秒数)。


结语

Prometheus是一个功能极其强大的监控系统,其设计之初就考虑到了之初动态环境,就像Kubernetes一样。尽管Prometheus的核心平台运行在Kubernetes之上,但是很重要的一点是,任何应用程序/基础设施,只要可以提供一个按照Prometheus兼容的文本格式提供度量数据的Web服务,就可以被监控。

现在有太多团队把监控和性能作为最后考虑的因素。说实话,我已经记不得我曾经问过多少个团队“这东西性能如何”或者“我们的应用程序平均响应时间是多少?”,最后只会看到一脸茫然,耸耸肩说“我们完全没有线索”。

现在已经没有任何借口了。那些说“哦,我们无法访问日志”或者“我们没有时间设置监控”的日志一去不复返了。因为如果你的团队正在使用Kubernetes(老实说,如果你没有,你可能会拼命往上面迁移),那么Prometheus会替你做很多繁重的工作。
5.gif


原文链接:Prometheus For Beginners(翻译:木木TM)

0 个评论

要回复文章请先登录注册