Yet Another Cloudwatch Exporter (YACE) 已正式加入 Prometheus 社区！此举将使其更易于用户访问，并为贡献者增强和维护该项目提供新的机会。还有一篇来自 Cristian Greco 的观点 的博客文章。

早期

当我最初启动 YACE 时，我根本没想到它会发展到如此规模。当时，我正在 Invision AG（与设计应用无关）工作，这是一家专注于劳动力管理软件的公司。他们全力支持我将该工具开源，并在我的队友 Kai Forsthövel 的帮助下，YACE 应运而生。

我们的首次提交是在 2018 年，我们的主要目标之一是使 CloudWatch 指标易于扩展并自动检测要测量的内容，同时保持用户体验的简单直观。InVision AG 由于机器学习工作负载而伸缩其基础设施，我们需要一个能够轻松检测新基础设施的工具。对简单性的关注始终是核心优先事项。从那时起，YACE 开始找到它的受众。

继柏林 PromCon 大会上最近发布的 Prometheus 3.0 beta 版之后，Prometheus 团队很高兴地宣布 Prometheus 3.0 版本现已立即可用！

这个最新版本标志着一个重要的里程碑，因为它是 7 年来的第一个主要版本。Prometheus 在这期间取得了长足的进步，从一个早期采用者的项目发展成为云原生监控堆栈的标准组成部分。Prometheus 3.0 旨在通过添加一些令人兴奋的新功能，同时在很大程度上保持与以前版本的稳定性和兼容性，来延续这一旅程。

完整的 3.0 版本在 beta 版的基础上增加了一些新功能，并引入了一些额外的破坏性变更，我们将在本文中进行描述。

Prometheus 团队自豪地宣布 Prometheus 3.0-beta 版本现已可用！您可以在此处下载。按照 beta 版本的惯例，我们**不**建议用户在关键生产系统上安装 Prometheus 3.0-beta，但我们确实希望每个人都对其进行测试并发现错误。

总的来说，唯一的破坏性变更是移除了已弃用的特性标志。Prometheus 团队努力确保向后兼容性，并且不破坏现有安装，因此下面描述的所有新功能都基于现有功能。大多数用户应该能够直接尝试 Prometheus 3.0，而无需进行任何配置更改。

OpenTelemetry 项目是一个可观测性框架和工具包，旨在创建和管理遥测数据，如追踪、指标和日志。它因其信号之间的一致规范以及减少厂商锁定的承诺而获得广泛采用，这正是我们所兴奋的。

回顾 2023

在过去的几年里，我们与 OpenTelemetry 社区合作，确保 OpenTelemetry 和 Prometheus 双向支持。这促成了官方规范的起草，用于在两个系统之间进行转换，以及允许您将 Prometheus 指标摄取到 OpenTelemetry Collector 中，反之亦然的实现。

从那时起，我们花费了大量时间来了解 OpenTelemetry 用户在将指标存储在 Prometheus 中时面临的挑战，并在此基础上，探索了我们如何解决这些挑战。一些提议的更改需要仔细考虑，以避免破坏任何一方的操作承诺，例如同时支持推和拉。在 2023 年柏林 PromCon 大会上，我们试图在其中一个演讲中总结我们的想法。

在我们在柏林举行的开发者峰会上，我们花费了大部分时间深入讨论这些变化以及我们对 OpenTelemetry 的总体立场，广泛的共识是，我们希望“成为 OpenTelemetry 指标的默认存储”！

我们已经组建了一个核心开发团队来领导这项倡议，我们将在 2024 年发布 Prometheus 3.0，其中 OTel 支持是其最重要的功能之一。以下是 2024 年即将推出的一些亮点。

PromCon Europe 是第八届完全致力于 Prometheus 监控系统的会议

德国柏林 – 2023 年 9 月 1 日 – CNCF 和 Prometheus 团队发布了 2023 年 9 月 28 日至 9 月 29 日在德国柏林举行的 PromCon Europe 2023 大会为期两天的单轨日程。与会者将能够从 21 场完整时长（25 分钟）的会议和多达 20 场五分钟的闪电演讲中进行选择，涵盖与 Prometheus 相关的各种主题。

PromCon 现已举办到第八届，它汇集了来自世界各地的 Prometheus 用户和开发者，以交流通过使用 Prometheus 所获得的知识、最佳实践和经验。项目委员会审查了 66 份提交内容，这些内容将对当前围绕 Prometheus 的最紧迫主题提供全新且信息丰富的见解。

“我们非常高兴 PromCon 能回到柏林。Prometheus 于 2012 年在柏林的 Soundcloud 启动。第一届 PromCon 在柏林举办，后来搬到了慕尼黑。今年我们将在柏林弗里德里希斯海因的 Radialsystem 举办，预计有大约 300 名与会者。柏林拥有一个充满活力的 Prometheus 社区，许多 Prometheus 团队成员都住在附近。这是一个与热爱系统和服务监控的 Prometheus 大家庭进行交流和联系的绝佳机会，”Polar Signals 高级软件工程师兼 Prometheus 团队成员 Matthias Loibl 说道，他也是今年 PromCon 项目委员会的负责人。“这将是一个了解 Prometheus 团队最新发展并与一些大型 Prometheus 用户近距离交流的绝佳活动。”

Prometheus 2.43 刚刚发布，它带来了令人兴奋的功能和增强。其中一项重要改进是 `stringlabels` 版本，它为标签使用了一种新的数据结构。这篇博客文章将回答一些关于 2.43 版本和 `stringlabels` 优化的常见问题。

`stringlabels` 版本是什么？

`stringlabels` 版本是 Prometheus 2.43 的一个版本，它为标签使用了一种新的数据结构。它将所有标签/值存储在一个字符串中，从而在大多数情况下减少了堆大小并带来了一些速度提升。这些优化并未包含在默认二进制文件中，需要使用 Go 标签 `stringlabels` 编译 Prometheus。

Bartek Płotka 自 2019 年以来一直是 Prometheus 的维护者，也是 Red Hat 的首席软件工程师。CNCF Thanos 项目的共同作者。CNCF 大使和 CNCF TAG 可观测性的技术负责人。业余时间，他与 O'Reilly 合作撰写了一本名为《高效 Go 编程》(Efficient Go) 的书。以上言论仅代表我个人观点！

我个人在 Prometheus 项目中最喜欢的一点，也是我加入团队的众多原因之一，就是它对项目目标的专注。Prometheus 始终致力于在提供实用、可靠、廉价但极其宝贵的基于指标的监控方面突破界限。Prometheus 极其稳定和健壮的 API、查询语言和集成协议（例如 Remote Write 和 OpenMetrics）使得云原生计算基金会（CNCF）的指标生态系统得以在这些坚实的基础上发展。结果，令人惊叹的事情发生了

• 我们可以看到社区导出器可以获取几乎所有内容的指标，例如容器、eBPF、Minecraft 服务器统计信息 甚至园艺时植物的健康状况。
• 如今，大多数人都希望云原生软件拥有一个 Prometheus 可以抓取的 HTTP/HTTPS `/metrics` 端点。这是一个在 Google 内部秘密开发并由 Prometheus 项目在全球推广的概念。
• 可观测性范式发生了转变。我们看到 SRE 和开发人员从第一天起就严重依赖指标，这提高了软件的弹性、可调试性和数据驱动的决策！

最终，我们几乎看不到没有运行 Prometheus 的 Kubernetes 集群。

今天，我们启动了 Prometheus 一致性计划，目标是确保 Prometheus 监控领域不同项目和供应商之间的互操作性。虽然法律文书工作仍有待最终确定，但我们已经进行了测试，并将以下内容视为我们的第一轮结果。作为此次发布的一部分，Julius Volz 更新了他的 PromQL 测试结果。

快速提醒：该计划名为 Prometheus **一致性**(Conformance)，软件可以**符合**(compliant)特定测试，从而得出**兼容性**(compatibility)评级。术语可能看起来很复杂，但这使我们能够讨论这个话题而无需使用冗长的词语。

正如奥斯卡·王尔德所说，模仿是最真诚的奉承形式。

勒索软件组织最近盗用了“Prometheus”和“Thanos”这两个名称。除了告知您此事正在发生之外，我们对此无能为力。您也无能为力，除了意识到此事正在发生。

虽然我们**没有**理由相信这个组织会试图欺骗任何人下载我们项目的假冒二进制文件，但我们仍然建议遵循常见的供应链和安全实践。部署软件时，请通过以下机制之一进行操作

正如 CNCF 和 我们自己所宣布的，我们正在启动一个 Prometheus 一致性计划。

为了在正式运行测试之前让每个人对生态系统有一个概述，我们想展示我们这个愉快的小型测试套件组的最新成员：Prometheus Remote Write 合规性测试套件根据我们的规范测试 Remote Write 协议的发送方部分。

在周一的 PromCon 会议上，Tom Wilkie 展示了数周前录制时的测试结果。在现场环节，他已经提供了一个更新。两天后，我们又有了两个更新：添加了可观测性管道工具 Vector，以及现有系统的新版本。

Prometheus 是云原生领域及其他领域的指标监控标准。为了确保互操作性，保护用户免受意外，并实现更多并行创新，Prometheus 项目正在 CNCF 的帮助下推出 Prometheus 一致性计划，以认证组件的合规性和 Prometheus 的兼容性。

CNCF 理事会预计将在下次会议上正式审查并批准该计划。我们邀请更广泛的社区在此加速阶段帮助改进我们的测试。

在我们广泛且不断扩展的测试套件的帮助下，项目和供应商可以确定其对我们规范的符合性以及在 Prometheus 生态系统中的兼容性。

您是否曾经选择某个事物的热门 10 条时间序列，结果却不是 10 条而是 100 条？如果是，这篇博客就是为您准备的。让我为您讲解一下潜在的问题以及我是如何解决它的。

目前，`topk()` 查询只有作为即时查询才有意义，因为您可以精确地获得 `k` 个结果，但当您将其作为范围查询运行时，您可能会获得远超 `k` 个的结果，因为每个步骤都是独立评估的。这个 `@` 修饰符允许您固定范围查询中所有步骤的排名。

在 Prometheus v2.25.0 中，我们引入了一个新的 PromQL 修饰符 `@`。与 `offset` 修饰符允许您将向量选择器、范围向量选择器和子查询的评估相对于评估时间偏移固定持续时间类似，`@` 修饰符允许您固定这些选择器的评估，而不受查询评估时间的影响。此语法的功劳归 Björn Rabenstein 所有。

<vector-selector> @ <timestamp>
<range-vector-selector> @ <timestamp>
<subquery> @ <timestamp>

<timestamp> 是一个 Unix 时间戳，用浮点文字描述。

我们始终按照 SemVer 模型对稳定性及破坏性变更做出严格承诺。情况将一如既往。

由于我们希望在实验方面更加大胆，我们计划更多地使用特性标志。

从 v2.25.0 开始，我们引入了一个名为禁用功能的新部分，其中包含隐藏在 `--enable-feature` 标志后的功能。您可以期待未来版本中会有越来越多的功能添加到此部分。

此列表中的功能被认为是实验性的，只要它们仍然在 `--enable-feature` 之后，就附带以下考虑事项：

1. 如果该功能有任何 API（Web API、代码接口等），API 规范可能会改变。
2. 该功能的行为可能会改变。
3. 它们可能会打破您对 Prometheus 可能有的一些假设。
   • 例如，关于查询不会提前评估样本时间的假设，将被 `@` 修饰符和负偏移打破。
4. 它们可能不稳定，但我们当然会尽力保持其稳定。

新的 Prometheus 2.13.0 版本已发布，一如既往，它包含了许多修复和改进。您可以在此处阅读更改内容。然而，有一个功能是某些项目和用户一直在等待的：远程读取 API 的分块流式版本。

在本文中，我将深入探讨我们在远程协议中更改了什么、为什么更改以及如何有效地使用它。

远程 API

自 1.x 版本以来，Prometheus 就能够使用远程 API 直接与其存储进行交互。

此 API 允许第三方系统通过两种方法与指标数据进行交互：

• **写入** - 接收 Prometheus 推送的样本
• **读取** - 从 Prometheus 拉取样本

这两种方法都使用 HTTP，消息通过 protobufs 编码。两种方法的请求和响应都使用 snappy 压缩。

在我们对 Prometheus 用户进行的一系列采访中，来自 ForgeRock 的 Ludovic Poitou 讲述了他们的监控历程。

您能介绍一下自己以及 ForgeRock 的业务吗？

我是 Ludovic Poitou，ForgeRock 的产品管理总监，工作地点在法国格勒诺布尔附近。ForgeRock 是一家国际身份和访问管理软件公司，拥有 500 多名员工，2010 年成立于挪威，现在总部位于美国旧金山。我们提供解决方案，以保护与客户、员工、设备和各种事物之间的每次在线交互。我们拥有 800 多个客户，涵盖金融公司到政府服务。

您在使用 Prometheus 之前的监控经验如何？

ForgeRock 身份平台一直提供监控接口。但该平台由 4 个主要产品组成，每个产品都有不同的选项。例如，目录服务产品通过 SNMP、JMX 或 LDAP 提供监控信息，在最新版本中甚至通过 HTTP 提供 RESTful API。其他产品只有 REST 或 JMX。因此，监控整个平台是复杂的，需要能够集成这些协议的工具。

在我们对 Prometheus 用户进行的一系列采访中，来自 Hostinger 的 Donatas Abraitis 讲述了他们的监控历程。

您能介绍一下自己以及 Hostinger 的业务吗？

我是 Donatas Abraitis，Hostinger 的系统工程师。顾名思义，Hostinger 是一家主机托管公司。自 2004 年以来，我们拥有约 3000 万客户，其中包括 000webhost.com 项目——免费网站托管提供商。

您在使用 Prometheus 之前的监控经验如何？

当 Hostinger 还是一家相当小的公司时，市场上只有 Nagios、Cacti 和 Ganglia 作为开源监控工具。这就像告诉年轻人什么是软盘驱动器一样，但 Nagios 和 Cacti 至今仍在开发周期中。

即使当时没有自动化工具。Bash + Perl 也能完成工作。如果您想扩展您的团队和您自己，自动化永远不应被忽视。没有自动化，就意味着更多的人工操作。

当时大约有 150 台物理服务器。相比之下，截至今天，我们拥有大约 2000 台服务器，包括虚拟机和物理机。

对于网络设备，SNMP 仍然被广泛使用。随着“白盒”交换机的兴起，SNMP 变得不那么必要了，因为可以安装常规工具。

您可以在交换机内部运行 `node_exporter` 或任何其他导出器，而不是 SNMP，以人类可读的格式公开您需要的任何指标。美胜于丑，对吧？

我们使用 CumulusOS，在我们的案例中它主要是 x86，因此运行任何 Linux 程序都完全没有问题。

引言

顾名思义，子查询是查询的一部分，它允许您在查询中执行范围查询，这在以前是不可能实现的。这是一个长期存在的特性请求：prometheus/prometheus/1227。

子查询支持的拉取请求最近已合并到 Prometheus 中，并将在 Prometheus 2.7 中可用。让我们在下面了解更多信息。

动机

有时，在需要使用较低分辨率/范围（例如 `5m`）的 `rate` 来发现问题，同时又需要对这些数据进行更高范围（例如 `1h` 的 `max_over_time`）的聚合时，会出现一些情况。

以前，上述操作无法通过单个 PromQL 查询实现。如果您想对警报规则或图表的查询进行范围选择，则需要基于该查询创建一个记录规则，并对记录规则创建的指标执行范围选择。示例：`max_over_time(rate(my_counter_total[5m])[1h])`。

当您想快速获取跨越数天或数周的数据结果时，可能需要等待相当长的时间，直到您的记录规则中有了足够的数据才能使用。忘记添加记录规则可能会令人沮丧。而且为查询的每个步骤创建记录规则将是乏味的。

有了子查询支持，所有的等待和挫败感都得到了解决。

在我们对 Prometheus 用户进行的一系列采访中，来自 Presslabs 的 Mile Rosu 讲述了他们的监控历程。

您能介绍一下自己以及 Presslabs 的业务吗？

Presslabs 是一个高性能的托管式 WordPress 托管平台，面向出版商、企业品牌和数字代理机构，旨在 100% 的时间为他们的网站访客提供无缝体验。

最近，我们为核心产品开发了一个创新组件——WordPress 商业智能。用户现在可以在一个综合仪表板中获取实时、可操作的数据，以支持从问题到部署的短周期流程和其网站的持续改进。

我们支持每月高达 20 亿页面浏览量的无缝交付，通过一个由 100 台机器组成的集群，这些机器完全致力于为要求严苛的客户提供托管式 WordPress 托管服务。

我们目前正致力于为全球 WordPress 发布者带来最佳体验。在此旅程中，Kubernetes 正在促进我们迈向高可用性 WordPress 托管基础设施的未来标准。

我们很高兴地宣布，截至今天，Prometheus 已在 CNCF 中毕业。

Prometheus 是有史以来第二个达到这一级别的项目。通过让 Prometheus 毕业，CNCF 表明它对我们的代码和功能迭代速度、我们的成熟度和稳定性以及我们的治理和社区流程充满信心。这也为任何内部讨论监控工具选择的人提供了外部质量验证。

自达到孵化级别以来，发生了许多事情；其中一些值得关注：

• 我们完全重写了存储后端，以支持服务中的高流失率
• 我们大力推动了稳定性，尤其是在 2.3.2 版本中
• 我们启动了一项文档推广计划，特别注重简化 Prometheus 的采用和加入社区的过程

Prometheus 内置了许多服务发现 (SD) 系统的集成，例如 Consul、Kubernetes 和 Azure 等公共云提供商。但是，我们无法为所有服务发现选项提供集成实现。Prometheus 团队在支持现有 SD 集成方面已经捉襟见肘，因此为每个可能的 SD 选项维护一个集成是不可行的。在许多情况下，当前的 SD 实现是由团队外部人员贡献的，然后没有得到良好的维护或测试。我们希望承诺只提供与我们知道可以维护并且按预期工作的服务发现机制的直接集成。因此，目前暂停了新的 SD 集成。

然而，我们知道仍然有人希望能够与其他 SD 机制集成，例如 Docker Swarm。最近，一项小的代码更改和一个示例被提交到 Prometheus 仓库中的文档目录，用于实现自定义服务发现集成，而无需将其合并到主要的 Prometheus 二进制文件中。此代码更改允许我们利用内部的 Discovery Manager 代码来编写另一个可执行文件，该文件与新的 SD 机制交互并输出一个与 Prometheus 的 `file_sd` 兼容的文件。通过将 Prometheus 和我们的新可执行文件共同放置，我们可以配置 Prometheus 读取我们可执行文件生成的 `file_sd` 兼容输出，从而从该服务发现机制中抓取目标。未来，这将使我们能够将 SD 集成移出主要的 Prometheus 二进制文件，并将使用适配器的稳定 SD 集成移入 Prometheus `discovery` 包。

使用 `file_sd` 的集成，例如那些通过适配器代码实现的集成，列在此处。

让我们看一下示例代码。

在我们对 Prometheus 用户进行的一系列采访中，来自 Datawire 的 Richard Li 讲述了他们如何过渡到 Prometheus。

您能介绍一下自己以及 Datawire 的业务吗？

在 Datawire，我们开发开源工具，帮助开发人员在 Kubernetes 上更快地编写代码。我们的项目包括用于 Kubernetes 服务本地开发的 Telepresence；基于 Envoy Proxy 构建的 Kubernetes 原生 API 网关 Ambassador；以及构建/部署系统 Forge。

我们在 AWS 的 Kubernetes 中运行着多项关键云服务，以支持我们的开源工作。这些服务支持的用例包括每天动态配置数十个 Kubernetes 集群，然后由我们的自动化测试基础设施使用。

您在使用 Prometheus 之前的监控经验如何？

我们使用了 AWS CloudWatch。这很容易设置，但我们发现随着我们采用更分布式的开发模式（微服务），我们希望获得更大的灵活性和控制力。例如，我们希望每个团队都能根据需要定制他们的监控，而无需操作方面的帮助。

在我们对 Prometheus 用户进行的一系列采访中，来自 Scalefastr 的 Kevin Burton 讲述了他们如何使用 Prometheus。

您能介绍一下自己以及 Scalefastr 的业务吗？

我叫 Kevin Burton，我是 Scalefastr 的首席执行官。我的背景是分布式系统，之前我曾经营 Datastreamer 公司，该公司构建了一个 PB 级分布式社交媒体爬虫和搜索引擎。

在 Datastreamer，我们遇到了基础设施的可扩展性问题，并构建了一个基于 Debian、Elasticsearch、Cassandra 和 Kubernetes 的高性能集群。

我们发现许多客户也在为其基础设施苦恼，我对他们在 AWS 和 Google Cloud 上托管大量内容所支付的费用感到惊讶。

我们不断评估在云中运行的成本，对我们而言，我们的托管成本大约是我们目前支付的 5-10 倍。

我们决定推出一个基于开源和云原生技术的新云平台，如 Kubernetes、Prometheus、Elasticsearch、Cassandra、Grafana、Etcd 等。

我们目前正在托管一些 PB 级客户，并于本月软发布我们的新平台。

12 月 6 日星期三是奥斯汀 CloudNativeCon 的 Prometheus 日，我们为您准备了一系列精彩的演讲和活动。前往 Prometheus 沙龙获取关于如何最佳监控 Kubernetes 的实践建议，参加一系列关于 Prometheus 各个方面的演讲，然后与一些 Prometheus 开发人员在 CNCF 展位交流，所有这些之后还有 Prometheus 欢乐时光。继续阅读以获取更多详情...

大约一年半前，我们发布了 Prometheus 1.0 版本。此次发布标志着该项目的一个重要里程碑。我们已经实现了一系列广泛的功能，这些功能构成了 Prometheus 简单而极其强大的监控理念。

从那时起，我们添加并改进了各种服务发现集成，扩展了 PromQL，并首次尝试了远程 API，以实现可插拔的长期存储解决方案。

但还有什么变化值得推出一个新的主要版本呢？

发生了什么

两周前，来自世界各地的 Prometheus 用户和开发者齐聚慕尼黑，参加 PromCon 2017，这是围绕 Prometheus 监控系统举办的第二届会议。本次活动的目的是交流 Prometheus 监控方面的知识、最佳实践，并建立专业联系。谷歌慕尼黑办公室今年为我们提供了更大的场地，这使我们得以将参会人数从 80 人增加到 220 人，而且仍然座无虚席！

观看回顾视频，了解本次活动的盛况

今天我们发布了 Prometheus 2.0 的第三个 Alpha 版本。除了新存储层中的各种错误修复之外，它还包含一些计划中的重大更改。

标志变更

首先，我们迁移到了一个新的标志库，该库使用更常见的双破折号 -- 作为标志前缀，而不是 Prometheus 之前使用的单破折号。部署必须相应调整。此外，此 Alpha 版本中删除了一些标志。Prometheus 1.0.0 以来的完整列表如下：

• web.telemetry-path
• 所有 storage.remote.* 标志
• 所有 storage.local.* 标志
• query.staleness-delta
• alertmanager.url

继续我们的 Prometheus 用户系列访谈，L’Atelier Animation 的 Philippe Panaite 和 Barthelemy Stevens 谈论了他们如何将动画工作室的监控系统从 Nagios、Graphite 和 InfluxDB 的混合方案切换到 Prometheus。

能否介绍一下您自己和 L’Atelier Animation 的业务吗？

L’Atelier Animation 是一家位于加拿大美丽城市蒙特利尔的 3D 动画工作室。我们的第一部故事片 《芭蕾舞者》（又名《跃动》）于 2017 年在全球上映，美国预计今年晚些时候上映。

我们目前正在努力制作一部动画电视剧和我们的第二部故事片。 我们的基础设施包括大约 300 台渲染刀片服务器、150 台工作站和二十台各种服务器。除少数几台 Mac 电脑外，所有设备都运行 Linux (CentOS)，没有一台 Windows 机器。

继续我们的 Prometheus 用户系列访谈，iAdvize 的 Laurent COMMARIEU 谈论了他们如何用 Prometheus 替代了原有的 Nagios 和 Centreon 监控系统。

您能介绍一下 iAdvize 的业务吗？

我是 Laurent COMMARIEU，iAdvize 的一名系统工程师。我在 60 人的研发部门中，属于一个由 5 名系统工程师组成的团队。我们的主要工作是确保应用程序、服务和底层系统正常运行。我们与开发人员合作，确保他们的代码能以最便捷的方式投入生产，并在每个环节提供必要的反馈。这就是监控的重要性所在。

iAdvize 是一个全栈式对话商务平台。无论通过何种沟通渠道（聊天、电话、视频、Facebook 页面、Facebook Messenger、Twitter、Instagram、WhatsApp、短信等），我们都能让品牌轻松地集中与客户互动。我们的客户遍布 40 个国家，涵盖电子商务、银行、旅游、时尚等行业。我们是一家拥有 200 名员工的国际公司，在法国、英国、德国、西班牙和意大利设有办事处。我们在 2015 年筹集了 1600 万美元。

2016 年 7 月，Prometheus 随着 1.0 版本的发布达到了一个重要的里程碑。从那时起，增加了许多新功能，例如新的服务发现集成和我们的实验性远程 API。我们还意识到，基础设施领域的新发展，特别是 Kubernetes，使得被监控的环境变得更加动态。毫不奇怪，这给 Prometheus 带来了新的挑战，我们也在其存储层中发现了性能瓶颈。

在过去的几个月里，我们一直在设计和实现一种新的存储概念，它解决了这些瓶颈并显著提高了整体性能。它也为添加热备份等功能铺平了道路。

这些变化是如此基础，以至于它将触发一个新的主要版本发布：Prometheus 2.0。在其稳定版发布之前，我们计划进行存储之外的重要功能和变更。然而，今天我们发布了 Prometheus 2.0 的早期 Alpha 版本，以启动新存储的稳定化进程。

继续我们的 Prometheus 用户系列访谈，Europace 的 Tobias Gesellchen 谈论了他们是如何发现 Prometheus 的。

您能介绍一下 Europace 的业务吗？

Europace AG 开发并运营基于网络的 EUROPACE 金融市场，这是德国最大的抵押贷款、建筑金融产品和个人贷款平台。一个完全集成的系统连接了大约 400 家合作伙伴——银行、保险公司和金融产品分销商。每月有数千用户在 EUROPACE 上执行约 35,000 笔交易，总价值高达 40 亿欧元。我们的工程师定期在 http://tech.europace.de/ 和 @EuropaceTech 上发表博客。

继续我们的 Prometheus 用户系列访谈，Weaveworks 的 Tom Wilkie 谈论了他们如何选择 Prometheus 并在此基础上进行构建。

您能介绍一下 Weaveworks 吗？

Weaveworks 提供了 Weave Cloud 服务，该服务通过结合开源项目和软件即服务来“运营化”微服务。

Weave Cloud 包括：

• 使用 Weave Scope 进行可视化
• 使用 Weave Flux 进行持续部署
• 使用容器 SDN Weave Net 进行网络管理
• 使用我们的开源分布式 Prometheus 即服务 Weave Cortex 进行监控。

您可以免费试用 Weave Cloud 60 天。了解我们产品的最新信息，请查看我们的博客、Twitter 或 Slack（邀请链接）。

继续我们的 Prometheus 用户系列访谈，Canonical 谈论了他们如何向 Prometheus 转型。

您能介绍一下您自己和 Canonical 的业务吗？

Canonical 最为人所知的可能是其作为 Ubuntu Linux 的赞助商。我们还开发或贡献了许多其他开源项目，包括 MAAS、Juju 和 OpenStack，并为这些产品提供商业支持。Ubuntu 为大多数 OpenStack 部署提供支持，包括 55% 的生产云和 58% 的大型云部署。

我所在的 BootStack 团队是我们的全托管私有云服务。我们为 Canonical 客户构建并运营 OpenStack 云。

继续我们的 Prometheus 用户系列访谈，JustWatch 谈论了他们如何建立监控系统。

您能介绍一下您自己和 JustWatch 的业务吗？

对消费者而言，JustWatch 是一个流媒体搜索引擎，帮助用户查找哪里可以合法地在线观看电影和电视剧，以及影院上映信息。您可以在 17 个国家/地区搜索 Netflix、HBO、Amazon Video、iTunes、Google Play 等所有主要流媒体提供商的电影内容。

对于电影工作室或视频点播提供商等客户，我们是一家国际电影营销公司，通过我们的消费者应用程序收集全球粉丝的购买行为和电影品味的匿名数据。我们帮助电影工作室向正确的受众推广其内容，并使数字视频广告更加高效，从而最大限度地减少无效覆盖。

继续我们的 Prometheus 用户系列访谈，Compose 谈论了他们如何将其监控系统从 Graphite 和 InfluxDB 迁移到 Prometheus。

您能介绍一下您自己和 Compose 的业务吗？

Compose 为全球开发者提供生产就绪的数据库集群即服务。应用程序开发人员只需点击几下，就能在几分钟内获得一个多主机、高可用、自动备份且安全的数据库。这些数据库部署随后会根据需求自动扩展，这样开发人员就可以把时间花在构建出色的应用程序上，而不是运行数据库上。

我们服务于 AWS、Google Cloud Platform 和 SoftLayer 的每个区域，每个区域至少有两个可用区，拥有数十个主机集群。每个集群都跨越支持的可用区，并承载着约 1000 个在其私有网络中的高可用数据库部署。更多的区域和提供商正在开发中。

接下来是我们的 Prometheus 用户系列访谈，DigitalOcean 谈论了他们如何使用 Prometheus。Carlos Amedee 还在 PromCon 2016 上谈到了 推广的社会层面。

您能介绍一下您自己和 DigitalOcean 的业务吗？

我叫 Ian Hansen，在平台指标团队工作。DigitalOcean 提供简单的云计算服务。迄今为止，我们已在 13 个区域创建了 2000 万个 Droplets（SSD 云服务器）。我们最近还发布了一款新的块存储产品。

继续我们的 Prometheus 用户系列访谈，ShuttleCloud 谈论了他们如何开始使用 Prometheus。ShuttleCloud 的 Ignacio 还在 PromCon 2016 上解释了 Prometheus 如何适合您的小型初创公司。

ShuttleCloud 的业务是什么？

ShuttleCloud 是世界上可扩展性最强的电子邮件和联系人数据导入系统。我们帮助包括 Google 和 Comcast 在内的一些领先电子邮件和地址簿提供商，通过数据导入自动化切换体验，从而促进用户增长和互动。

通过将我们的 API 集成到他们的产品中，我们的客户允许他们的用户轻松地将电子邮件和联系人从一个参与提供商迁移到另一个，从而减少了用户切换到新提供商时面临的阻力。支持 24/7 电子邮件服务的提供商包括所有主要的美国互联网服务提供商：Comcast、Time Warner Cable、AT&T、Verizon 等。

通过为最终用户提供简单的电子邮件迁移途径（同时完全控制导入工具的用户界面），我们的客户显著提高了用户激活率和新用户引导效率。

发生了什么

上周，来自世界各地的八十名 Prometheus 用户和开发者齐聚柏林两天，参加了首届关于 Prometheus 监控系统的会议：PromCon 2016。本次会议的目标是交流使用 Prometheus 所获得的知识、最佳实践和经验。我们还希望发展社区，并帮助人们建立围绕服务监控的专业联系。以下是第一天上午的一些印象

让我们来谈谈一个特别普遍的误解。每当讨论监控系统并提及 Prometheus 的拉取式指标收集方法时，总会有人插话说，拉取式方法“根本无法扩展”。给出的理由往往模糊不清，或者只适用于与 Prometheus 根本不同的系统。事实上，我们曾在最大规模的环境中使用过拉取式监控，这一说法与我们自己的运营经验是相悖的。

我们已经有一篇 FAQ 文章解释了 为什么 Prometheus 选择拉取而非推送模式，但它没有专门关注扩展性方面。让我们仔细研究一下围绕这一说法的常见误解，并分析它们是否以及如何适用于 Prometheus。

今年一月，我们发表了一篇博客文章，回顾了Prometheus 公开面世的第一年，总结了对我们而言这是一段多么奇妙的旅程，并希望它对您来说也是一个创新且有用的监控解决方案。从那时起，Prometheus 也加入了云原生计算基金会（Cloud Native Computing Foundation），作为继 Kubernetes 之后的第二个核心项目，我们在此与许多优秀项目为伍。

我们最近的工作重点是提供一个稳定的 API 和用户界面，这以 Prometheus 1.0 版本为标志。我们很高兴地宣布，我们已经实现了这一目标，Prometheus 1.0 今日正式发布。

1.0 版本对您意味着什么？

如果您已经使用 Prometheus 一段时间，您可能已经注意到，在过去一年中，破坏性变更的频率和影响显著降低。本着同样的原则，达到 1.0 版本意味着后续的 1.x 版本将保持 API 稳定。升级不会破坏基于 Prometheus API 构建的程序，更新也不需要重新初始化存储或更改部署。自定义仪表板和告警在 1.x 版本更新中也将保持不变。我们相信 Prometheus 1.0 是一个可靠的监控解决方案。既然 Prometheus 服务器已经达到了稳定的 API 状态，其他模块也将随着时间的推移陆续发布自己的 1.0 稳定版本。

自 Prometheus 诞生以来，我们一直在寻找一种独立于任何单一公司的可持续项目治理模式。最近，我们一直在与新成立的云原生计算基金会（Cloud Native Computing Foundation，简称 CNCF）进行讨论，该基金会由 Google、CoreOS、Docker、Weaveworks、Mesosphere 以及其他领先的基础设施公司支持。

今天，我们很高兴地宣布，CNCF 的技术监督委员会一致投票决定接受 Prometheus 作为继 Kubernetes 之后的第二个托管项目！您可以在CNCF 的官方新闻稿中找到有关这些计划的更多信息。

Prometheus 服务器的嵌入式时间序列数据库 (TSDB) 将每个时间序列的原始采样数据组织成大小为 1024 字节的固定块。除了原始采样数据外，每个块还包含一些元数据，允许为每个块选择不同的编码方式。最根本的区别在于编码版本。您可以通过命令行标志 -storage.local.chunk-encoding-version 为新创建的块选择版本。到目前为止，只有两个受支持的版本：0 用于原始增量编码，1 用于改进的双增量编码。随着 0.18.0 版本的发布，我们添加了版本 2，它是另一种双增量编码。我们称之为 *varbit 编码*，因为它涉及块内每个样本的可变位宽。尽管版本 1 在几乎所有方面都优于版本 0，但版本 1 和版本 2 之间存在真正的权衡。这篇博客文章将帮助您做出决定。版本 1 仍然是默认编码，因此如果您在阅读本文后想尝试版本 2，则必须通过命令行标志明确选择它。来回切换没有害处，但请注意，现有块一旦创建，其编码版本就不会改变。然而，这些块将根据配置的保留时间逐步淘汰，并因此被命令行标志中指定的编码的块所取代。

这是 Prometheus 用户系列访谈的第二篇，旨在让他们分享评估和使用 Prometheus 的经验。

您能介绍一下您自己和 ShowMax 的业务吗？

我是 Antonin Kral，负责 ShowMax 的研究和架构。在此之前，我曾担任架构师和 CTO 职务 12 年。

ShowMax 是一家于 2015 年在南非推出的订阅式视频点播服务。我们拥有庞大的内容库，包含超过 20,000 集电视剧和电影。我们的服务目前在全球 65 个国家/地区可用。当知名竞争对手在美国和欧洲激烈竞争时，ShowMax 正在应对一个更困难的问题：如何在撒哈拉以南非洲地区一个连接状况不佳的村庄里观看视频？全球已有 35% 的视频以流媒体形式播放，但仍有许多地方尚未被这场革命触及。

我们管理着大约 50 项服务，它们主要运行在围绕 CoreOS 构建的私有集群上。它们主要处理来自我们客户端（Android、iOS、AppleTV、JavaScript、三星电视、LG 电视等）的 API 请求，其中一些在内部使用。最大的内部管道之一是视频编码，在处理大量摄入批次时，它可以占用 400 多台物理服务器。

我们的大多数后端服务都是用 Ruby、Go 或 Python 编写的。当用 Ruby 编写应用程序时，我们使用 EventMachine（在 MRI 上使用 Goliath，在 JRuby 上使用 Puma）。Go 通常用于需要大吞吐量且业务逻辑不多的应用程序。对于用 Python 编写的服务，我们对 Falcon 非常满意。数据存储在 PostgreSQL 和 ElasticSearch 集群中。我们使用 etcd 和自定义工具来配置 Varnishes 以进行请求路由。

这是 Prometheus 用户系列访谈的第一篇，旨在让他们分享评估和使用 Prometheus 的经验。我们的第一次访谈对象是来自 Life360 的 Daniel。

您能介绍一下您自己和 Life360 的业务吗？

我是 Daniel Ben Yosef，又名 dby，我是 Life360 的一名基础设施工程师，在此之前，我曾担任系统工程职位 9 年。

Life360 创造了帮助家庭保持联系的技术，我们是面向家庭的“家庭网络”应用程序。我们非常忙碌地为这些家庭提供服务——在高峰期，我们每分钟为 7000 万注册家庭处理 70 万个请求。

我们在生产环境中管理着大约 20 项服务，主要处理来自移动客户端（Android、iOS 和 Windows Phone）的位置请求，高峰期涉及超过 150 多个实例。冗余和高可用性是我们的目标，我们努力尽可能保持 100% 的正常运行时间，因为家庭信任我们能够提供服务。

我们将用户数据存储在 MySQL 多主集群和 12 节点 Cassandra 环中，后者在任何给定时间都存储着大约 4TB 的数据。我们的服务使用 Go、Python、PHP 编写，并计划将 Java 引入我们的技术栈。我们使用 Consul 进行服务发现，当然，我们的 Prometheus 设置也与它集成了。

Alertmanager 处理 Prometheus 服务器发送的告警，并根据其标签将通知发送给不同的接收者。

接收者可以是许多不同集成中的一种，例如 PagerDuty、Slack、电子邮件，或通过通用 webhook 接口实现的自定义集成（例如 JIRA）。

模板

发送到接收者的消息是通过模板构建的。Alertmanager 附带默认模板，但也允许定义自定义模板。

在这篇博客文章中，我们将逐步介绍 Slack 通知的一个简单自定义。

我们使用这个简单的 Alertmanager 配置，它将所有告警发送到 Slack

global:
  slack_api_url: '<slack_webhook_url>'

route:
  receiver: 'slack-notifications'
  # All alerts in a notification have the same value for these labels.
  group_by: [alertname, datacenter, app]

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'

默认情况下，Alertmanager 发送的 Slack 消息如下所示

它向我们显示有一个触发中的告警，后面是告警分组的标签值（alertname、datacenter、app），以及告警共有的其他标签值（critical）。

序章

整整一年前的今天，我们正式向全世界宣布了 Prometheus。这是一个绝佳的机会，让我们回顾并分享自那时以来项目所发生的一些精彩事件。但首先，让我们从头说起。

尽管我们早在 2012 年就在 GitHub 上启动了 Prometheus 的开源项目，但一开始我们并未大肆宣传。我们希望给项目时间来成熟，并能够无摩擦地进行实验。Prometheus 于 2013 年在 SoundCloud 逐渐引入用于生产监控，随后在公司内部的使用越来越多，并于 2014 年得到了我们在 Docker 和 Boxever 的朋友的一些早期采用。多年来，Prometheus 变得越来越成熟，尽管它已经解决了人们的监控问题，但对更广泛的公众来说仍然是未知的。

在上一篇文章中，我们介绍了 Prometheus 中进行服务发现的许多新方法。从那时起，发生了许多事情。我们改进了内部实现，并收到了来自社区的巨大贡献，增加了对 Kubernetes 和 Marathon 服务发现的支持。这些将在 0.16 版本发布时提供。

我们还提到了自定义服务发现的话题。

并非所有类型的服务发现都通用到可以直接包含在 Prometheus 中。很有可能您的组织已经有一个专有系统，您只需使其与 Prometheus 协同工作即可。这并不意味着您无法享受到自动发现新监控目标的便利。

在本文中，我们将实现一个小型实用程序，它将基于高一致性分布式键值存储 etcd 的自定义服务发现方法连接到 Prometheus。

编者按：本文是 Prometheus 用户撰写的客座文章。

如果您正在为数以万计的挑剔游戏玩家运营网络，您需要真正了解网络内部发生了什么。哦，而且所有东西都需要在短短五天内从头开始搭建。

如果您以前从未听说过 DreamHack，这里有一个简介：召集 20,000 人，其中大部分人自带电脑。融入职业游戏（电子竞技）、编程竞赛和现场音乐会。结果就是世界上最大的，完全致力于数字领域一切的节日。

要使这样的活动成为可能，需要大量的基础设施。这种规模的普通基础设施需要数月才能建成，但 DreamHack 的工作人员在短短五天内就从头开始搭建了一切。这当然包括配置网络交换机等工作，但也包括建设电力分配系统、设置食品和饮料商店，甚至搭建实际的桌子。

负责构建和运营所有网络相关事务的团队官方称为网络团队，但我们通常称自己为 *tech* 或 *dhtech*。这篇文章将重点介绍 dhtech 的工作以及我们在 DreamHack Summer 2015 期间如何使用 Prometheus 来尝试将我们的监控水平提升到一个新的高度。

在约翰·奥尔斯波 (John Allspaw) 的*《致监控/指标/告警公司的一封公开信》*中，他断言试图“在正确的时间完美地检测异常是不可能的”。

我曾见过一些有才能的工程师试图构建系统，以基于时间序列数据自动检测和诊断问题。虽然演示肯定能奏效，但数据显示数据总是过于嘈杂，以至于这种方法除了最简单的真实系统之外，无法适用于其他任何系统。

然而，并非所有希望都已破灭。有许多常见的异常可以通过自定义规则进行检测和处理。Prometheus 的查询语言为您提供了发现这些异常并避免误报的工具。

本周我们发布了 Prometheus v0.14.0——一个包含许多期待已久的新增功能和改进的版本。

在用户端，Prometheus 现在支持新的服务发现机制。除了 DNS-SRV 记录，它现在开箱即用地支持 Consul，并且基于文件的接口允许您连接自己的发现机制。随着时间的推移，我们计划向 Prometheus 添加其他常见的服务发现机制。

除了许多小修复和改进之外，您现在还可以通过向 Prometheus 进程发送 SIGHUP 信号来在运行时重新加载配置。有关完整变更列表，请查看此版本的更新日志。

在这篇博客文章中，我们将仔细研究内置的服务发现机制并提供一些实用示例。作为额外资源，请参阅Prometheus 的配置文档。

距离我们公开宣布 Prometheus 0.10.0 版本已经将近三个月了，现在我们已经到了 0.13.1 版本。

SoundCloud 的公告博客文章仍然是 Prometheus 关键组件的最佳概述，但围绕 Prometheus 还有许多其他在线活动。这篇文章将让您了解所有您可能错过的信息。

未来，我们将使用此博客发布更多文章和公告，以帮助您充分利用 Prometheus。