你是否发现自己总是在查阅 container_memory_usage_bytes、container_memory_working_set_bytes 和 container_memory_rss 之间的区别？选错了指标，内存限制就会欺骗你，基准测试会误导你，而容器最终会遭遇 OOMKilled。

你并不孤单。甚至有一个 9 年前的 Kubernetes 问题  记录了用户的这种挫败感。

原因很简单：内存的使用方式不止一种。最容易被忽略的一点就是 页缓存（page cache）  语义。对于某些容器，页缓存占用的内存可能占据报告使用量的大部分，尽管这些内存很大程度上是可以回收的，这导致这些指标之间存在令人困惑的差异。

在过去的一年里，Prometheus 社区一直在努力推进几项有趣且雄心勃勃的变革，这些变革在过去可能被视为具有争议或不可行。虽然外界对这些进展可能感知不多（例如，抱歉，这并非 OpenClaw Prometheus 插件 🙃），但 Prometheus 开发人员正在有机地引导 Prometheus 走向一个确定的、连贯的未来。一点一点地，我们意外地接近了作为开源项目从未梦想过能实现的目标！

这篇文章希望开启一个系列博客，分享一些可能令 Prometheus 新老用户和开发人员感到兴奋的雄心勃勃的转变。在这篇文章中，我想重点介绍复合类型原生存储的构想，它正在理清长期以来堆积的诸多挑战。请务必查看文中提供的链接，了解如何尽早采用其中的一些变更或参与贡献！

在 Prometheus 中使用元数据标签来丰富指标信息可能会出奇地棘手，即使你是一位 PromQL 大师！传统上用于此目的的 PromQL 连接查询本身非常复杂，因为它必须指定要连接的标签、要加入的 info 指标，以及要丰富其中的标签。新的（仍处于实验阶段的）info() 函数提供了一种更简单的方法，只需在一个函数调用中包装查询，即可实现标签丰富。

在 Prometheus 3.0 中，我们引入了 info() 函数，这是一种用 info 指标中的标签来丰富时序数据的强大新方法。与传统的连接查询技术相比，info() 的特别之处在于它让你无需指定“标识标签”、要加入的 info 指标，以及要丰富其中的（“数据”或“非标识”）标签。注意，在此特定上下文中，“标识标签”是指识别相关 info 指标的那一组标签，它们与相关的非 info 指标共享。这些就是你在 Prometheus 连接查询  中进行连接的标签。从概念上讲，它们可以与关系数据库中的 外键  相比较。

除了主要功能外，info() 还解决了一个长期困扰连接查询的微妙而关键的问题：即当非标识 info 指标标签发生变化时（结合缺乏过期标记，如 OTLP 摄取的情况），导致查询失败的“抖动问题（churn problem）”。

无论你是在处理 OpenTelemetry 资源属性、Kubernetes 标签还是任何其他元数据，info() 函数都能让你的 PromQL 查询更简洁、更可靠且更易于理解。

Prometheus 的 目标重新打标（target relabeling）功能允许你调整发现目标的标签，甚至完全丢弃该目标。虽然重新打标规则功能强大，但却很难理解和调试。你的规则必须匹配服务发现机制返回的预期标签，任何步骤出错都可能导致目标标签错误或被意外丢弃。

为了帮助你查明出错（或正确执行）的地方，Prometheus 3.8.0 在 Web UI 中添加了一个重新打标可视化器 ，让你能够检查每个重新打标规则是如何应用于发现目标的标签的。让我们看看它是如何工作的！

我最初接触 Prometheus 项目是通过 Linux 基金会指导计划 ，当时我负责 UX 研究。我记得刚入选实习生时，内心非常焦虑。不仅是对 Prometheus，我对整个可观测性领域都很陌生。我担心自己能力不足，在一个高度以开发为中心的领域工作，却没有任何开发背景。

事实证明，这种焦虑是多余的。我后来为该项目做出了有意义的贡献，并且我了解到，我的这种经历在开源界的非技术贡献者中几乎是普遍存在的。

如果你也有同样的不确定感，这篇文章正是为你而写的。我将分享你可能会面临（或已经面临）的挑战、为什么你的贡献很重要，以及如何找到在 Prometheus 社区中的位置。

Yet Another Cloudwatch Exporter  (YACE) 已正式加入 Prometheus 社区！此举将使其更易于用户获取，并为贡献者增强和维护该项目开辟新机遇。Cristian Greco 也从他的视角撰写了一篇博文，阐述了对此次合并的看法。

早期阶段

当我刚开始做 YACE 时，完全没想到它会发展到今天的规模。当时，我正在 Invision AG （不要与那个设计应用混淆）工作，这是一家专注于劳动力管理软件的公司。他们全力支持我将该工具开源，并在我的队友 Kai Forsthövel  的帮助下，YACE 应运而生。

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

继最近在柏林 PromCon 上发布 Prometheus 3.0 测试版 后，Prometheus 团队很高兴地宣布 Prometheus 3.0 正式版现已发布！

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

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

Prometheus 团队很自豪地宣布 Prometheus 3.0-beta 版本可用！你可以点击此处 下载。按照测试版发布的惯例，我们不建议用户在关键生产系统上安装 Prometheus 3.0-beta，但我们非常希望大家试用并提交 Bug。

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

OpenTelemetry 项目  是一个可观测性框架和工具集，旨在创建和管理跟踪（traces）、指标（metrics）和日志（logs）等遥测数据。由于其在信号间的一致规范以及减少供应商锁定的承诺，它正得到广泛采用，这是我们非常乐见的。

回顾 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 日至 29 日在德国柏林举行的单轨 PromCon Europe 2023 会议的为期两天的日程安排。与会者将能够从 21 场完整时长（25 分钟）的会议和多达 20 场五分钟的闪电演讲中进行选择，涵盖与 Prometheus 相关的不同主题。

PromCon 今年已是第八届，汇集了来自世界各地的 Prometheus 用户和开发人员，交流知识、最佳实践以及使用 Prometheus 获得的经验。程序委员会审查了 66 份提交的议题，这些议题将为当今 Prometheus 周围最紧迫的话题提供全新且信息丰富的见解。

“我们非常高兴 PromCon 能回到柏林。Prometheus 始于 2012 年柏林的 Soundcloud。第一届 PromCon 就在柏林举办，之后移师慕尼黑。今年我们将接待约 300 名与会者，地点位于柏林 Friedrichshain 的 Radialsystem。柏林拥有充满活力的 Prometheus 社区，许多 Prometheus 团队成员就住在附近。这是一个与 Prometheus 大家庭建立联系和交流的好机会，他们都热衷于系统和服务监控，”Polar Signals 高级软件工程师兼 Prometheus 团队成员、负责今年 PromCon 程序委员会的 Matthias Loibl 表示。“这将是一次了解 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 Observability 技术负责人。闲暇时，他正在编写一本名为“Efficient Go”的书（由 O'Reilly 出版）。观点仅代表个人！

我个人热爱 Prometheus 项目，这也是我加入团队的众多原因之一，在于该项目对目标的高度聚焦。Prometheus 一直致力于在提供务实、可靠、廉价且极其宝贵的基于指标的监控方面不断突破界限。Prometheus 超级稳定和健壮的 API、查询语言以及集成协议（例如远程写入和 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）合规测试套件，它根据我们的规范 测试远程写入协议的发送方部分。

在周一的 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 开始，我们引入了一个名为 禁用特性（disabled features） 的新部分，这些特性隐藏在 --enable-feature 标志后面。在未来的版本中，你可以期待越来越多的特性被添加到此部分。

此列表中的特性被视为实验性的，只要它们仍处于 --enable-feature 之后，就需遵循以下考虑事项

1. 如果该特性具有任何 API（Web API、代码接口等），API 规范可能会发生变化。
2. 该特性的行为可能会发生变化。
3. 它们可能会破坏你可能对 Prometheus 持有的某些假设。
   • 例如，查询不会提前查看评估时间以获取样本的假设，这将因 @ 修饰符和负偏移量而破坏。
4. 它们可能不稳定，但当然，我们会尽力保持其稳定。

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

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

远程 API

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

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

• 写入 (Write) - 接收 Prometheus 推送的样本
• 读取 (Read) - 从 Prometheus 拉取样本

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

继续我们的 Prometheus 用户系列访谈，来自 ForgeRock 的 Ludovic Poitou 讲述了他们的监控之旅。

你能介绍一下你自己以及 ForgeRock 是做什么的吗？

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

在使用 Prometheus 之前，您的监控体验是怎样的？

ForgeRock Identity Platform 一直提供监控接口。但该平台由 4 个主要产品组成，每个产品都有不同的选项。例如，Directory Services 产品通过 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 上更快地编写代码。我们的项目包括 Telepresence （用于 Kubernetes 服务的本地开发）；Ambassador （基于 Envoy Proxy  构建的 Kubernetes 原生 API 网关）；以及 Forge （一个构建/部署系统）。

为了支持我们的开源工作，我们在 AWS 的 Kubernetes 中运行了多个关键任务云服务。这些服务支持诸如每天动态配置数十个 Kubernetes 集群等用例，这些集群随后被用于我们的自动化测试基础设施。

在使用 Prometheus 之前，您的监控体验是怎样的？

我们曾经使用过 AWS CloudWatch。它很容易设置，但我们发现，随着我们采用更分布式的开发模型（微服务），我们需要更多的灵活性和控制权。例如，我们希望每个团队都能根据需要自定义其监控，而无需运维部门的协助。

延续我们的 Prometheus 用户系列访谈，来自 Scalefastr 的 Kevin Burton 讲述了他们如何使用 Prometheus。

你能介绍一下你自己以及 Scalefastr 是做什么的吗？

我的名字是 Kevin Burton，我是 Scalefastr  的 CEO。我的背景是分布式系统，我之前运营过 Datastreamer，这是一家构建了 PB 级分布式社交媒体爬虫和搜索引擎的公司。

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

我们发现我们的许多客户也在与他们的基础设施做斗争，我惊讶于他们为在 AWS 和 Google Cloud 上托管大量内容所支付的费用。

我们不断评估在云端运行的成本，对于我们来说，我们的托管成本大约是我们目前支付费用的 5 到 10 倍。

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

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

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

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

从那时起，我们添加并改进了各种服务发现集成，扩展了 PromQL，并试验了远程 API 的第一个迭代，以支持可插拔的长期存储解决方案。

但是还有什么变化值得发布一个新的主要版本呢？

发生了什么

两周前，来自世界各地的 Prometheus 用户和开发者齐聚慕尼黑参加 PromCon 2017 ，这是关于 Prometheus 监控系统的第二次会议。本次活动的目的是交流知识和最佳实践，并围绕 Prometheus 监控建立专业联系。Google 慕尼黑办公室今年为我们提供了更大的空间，使我们能够从 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 动画工作室。我们的第一部长篇电影 “Ballerina” （也称为“Leap”）于 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  进行持续部署
• 使用 Weave Net  进行网络连接，即容器 SDN
• 使用 Weave Cortex 进行监控 ，这是我们开源的、分布式的“Prometheus 即服务”。

您可以免费试用 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。Ignacio 还解释了 Prometheus 如何适合小型初创公司 。

ShuttleCloud 是做什么的？

ShuttleCloud 是世界上最可扩展的电子邮件和联系人数据导入系统。我们帮助一些领先的电子邮件和通讯录提供商（包括 Google 和 Comcast）通过自动化数据导入过程中的切换体验，从而提高用户增长和参与度。

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

通过为终端用户提供简单的电子邮件迁移路径（同时保留对导入工具 UI 的完全控制），我们的客户显着改善了用户激活和引导过程。

发生了什么

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

让我们谈谈一个特别顽固的神话。每当讨论监控系统并提到 Prometheus 基于拉取的指标收集方法时，总会有人不可避免地插话称“从根本上来说，拉取式方法是无法扩展的”。给出的原因往往很模糊，或者只适用于与 Prometheus 从根本上不同的系统。事实上，在最大规模下使用过拉取式监控后，这种说法与我们的实际运营经验背道而驰。

我们已经有一篇常见问题解答，内容是关于为什么 Prometheus 选择拉取而不是推送，但它并没有专门关注扩展性方面。让我们仔细看看围绕这一说法的常见误解，并分析它们是否以及如何应用于 Prometheus。

一月份，我们发布了一篇关于Prometheus 公开开发的第一年的博客文章，总结了我们这一段惊人的旅程，希望它对您来说是一个创新且有用的监控解决方案。从那时起，Prometheus 也加入了云原生计算基金会（CNCF），我们在这里与继 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 成立以来，我们一直在为项目寻找一种可持续的治理模型，该模型独立于任何单一公司。最近，我们一直在与新成立的 云原生计算基金会  (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 encoding），因为它涉及块内每个样本的可变位宽。虽然版本 1 在几乎每个方面都优于版本 0，但在版本 1 和 2 之间确实存在取舍。这篇博客文章将帮助您做出决定。版本 1 仍然是默认编码，因此如果您在阅读本文后想要尝试版本 2，则必须通过命令行标志显式选择它。来回切换没有坏处，但请注意，现有块一旦创建就不会更改其编码版本。但是，这些块将根据配置的保留时间逐渐淘汰，从而被命令行标志中指定的编码块所取代。

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

你能介绍一下你自己以及 ShowMax 是做什么的吗？

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

ShowMax 是一家于 2015 年在南非推出的订阅视频点播服务。我们拥有内容丰富的目录，包含 20,000 多集电视节目和电影。我们的服务目前在全球 65 个国家/地区可用。当更知名的竞争对手在美国和欧洲混战时，ShowMax 正在解决一个更困难的问题：如何在撒哈拉以南非洲几乎无法连接网络的村庄里“刷剧”？全球 35% 的视频已经实现流媒体化，但仍有许多地方尚未受到这场革命的影响。

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

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

这是 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 人聚集在一起，其中大部分人都会自带电脑。加入职业电子竞技 (eSports)、编程竞赛和现场音乐会。其结果就是全球最大的、完全致力于数字领域的一切活动的艺术节。

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

构建和运营与网络相关的一切事务的团队被正式称为网络团队，但我们通常称自己为 tech 或 dhtech。这篇文章将重点介绍 dhtech 的工作，以及我们在 2015 年夏季 DreamHack 期间如何使用 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。