Prometheus Prometheus

Prometheus 架构与拉取模型

为什么 Prometheus 是抓取而不是接收,以及目标、exporter 和服务发现如何结合在一起。

9 min 初级

大多数日志和监控工具是你向它们发送数据的。相比之下,Prometheus 是围绕拉取构建的:它按计划主动联系它所监控的东西,并询问它们当前的数字。这一设计决策塑造了它部署和配置方式的几乎所有其他方面,本指南涵盖由此产生的架构。

抓取:拉取而不是推送

Prometheus 定期向它监控的每个系统发送一个 HTTP 请求,并读回该系统当前指标值的快照。Prometheus 把这称为抓取(scraping),它所抓取的每个东西是一个目标(target)。一次抓取只携带那一刻的值;载荷中没有任何历史;Prometheus 是将一系列按间隔进行的抓取变成历史的东西。

拉取模型有一个实际的后果:Prometheus 监控的任何东西都需要暴露一个 HTTP 端点(按惯例是 /metrics),以它能理解的格式返回其当前值,而不是 Prometheus 需要为每一种可能的数据源准备一个入站监听器让它们把数据推过来。

目标:被插桩的应用与 exporter

目标属于两类之一:

  • 直接被插桩的应用。 你自己的服务,使用 Prometheus 官方客户端库之一,在 /metrics 端点原生地跟踪并暴露它自己的指标。
  • Exporter,用于任何自身不(或不能)暴露 Prometheus 指标的东西:数据库、Linux 主机、网络设备。exporter 是与被监控对象一起运行的小进程,把它的原生统计数据翻译成 Prometheus 的格式。用于主机级指标(CPU、内存、磁盘、网络)的 node_exporter,以及用于每个容器指标的 cAdvisor,是使用最广泛的两个。

因为暴露格式是刻意设计得很简单的文本(下一篇指南介绍),编写 exporter,甚至完全不用客户端库手工编写指标,即使对于没有官方 Prometheus 支持的东西来说,也是现实可行的。

寻找目标:静态配置或服务发现

Prometheus 需要一个要抓取的目标列表。对于少数稳定的主机,在 Prometheus 的配置文件中手工列出它们就可以了。对于任何更大或更动态的场景,即机器和容器来来去去,手工维护很快就变得不切实际。Prometheus 转而与服务发现机制集成,包括 DNS、Kubernetes API 服务器、云服务商 API 等,随着环境变化自动构建并持续更新它的目标列表。

存储:本地时间序列数据库

被抓取的样本落入 Prometheus 磁盘上自己的本地时间序列数据库(TSDB)。默认情况下,Prometheus 保留 15 天的数据;这是一个可配置的标志(--storage.tsdb.retention.time),而不是硬性限制,但 15 天对绝大多数真实的排障已经足够,因为大多数事故都是与几分钟或几小时前相比的,很少与几个月前比较。对于长期保留,或跨许多 Prometheus 服务器的集中存储,Prometheus 也可以被配置为将样本转发(remote-write)到外部存储系统,其权衡不同于它自己的本地 TSDB。

围绕核心服务器的部分

几个组件构成一个典型的部署:

  • Alertmanager 是 Prometheus 将触发的告警交给它的一个独立组件。它对告警去重、分组,并路由到电子邮件、Slack、PagerDuty 或你配置的任何其他目的地,将”检测到问题”与”决定通知谁以及如何通知”解耦。
  • Grafana(或 Prometheus 自带的 Web UI,或其他工具)是你通常探索和可视化数据的方式;Prometheus 本身专注于可靠地收集和存储指标,而不是充当仪表板层。
  • PromQL,即 Prometheus 的查询语言,是 Grafana 的仪表板和 Prometheus 自己的告警规则的构建基础。告警和仪表板不是被拼在一起的两个不同系统;它们是针对同一数据使用同一查询语言的两个消费者。本系列后面的指南直接介绍数据模型和 PromQL。

把各部分整合起来

   ┌──────────────┐        scrapes over HTTP        ┌──────────────┐
   │  Prometheus  │ ───────────────────────────────▶ │    Target    │
   │    server    │                                    │ (/metrics)   │
   └──────┬───────┘                                    └──────────────┘
          │ stores samples in
          ▼
   local TSDB (default 15d retention)
          │
   ┌──────┴───────────────┬───────────────────────┐
   ▼                       ▼                       ▼
firing alerting rules   PromQL queries          remote write
   │                    (Grafana, ad hoc)        (optional, external storage)
   ▼
Alertmanager → email / Slack / PagerDuty / ...

下游的一切,告警、仪表板、即席调试,都从抓取所填充的同一个 TSDB 中读取。本系列的其余部分从实际存储在其中的东西开始。

热门指南