在 Prometheus 中用元数据标签丰富指标可能非常棘手，即使您是 PromQL 专家！传统上用于此的 PromQL JOIN 查询本身就很复杂，因为它必须指定要 JOIN 的标签、要 JOIN 的 info 指标以及要丰富到的标签。新的、仍处于实验阶段的 info() 函数，提供了一种更简单的方法，使标签丰富就像将查询包装在单个函数调用中一样简单。

在 Prometheus 3.0 中，我们引入了 info() 函数，这是一种强大的新方法，可以丰富您的时间序列，使其包含来自 info 指标的标签。与传统的 JOIN 查询技术相比，info() 的特别之处在于它使您无需指定标识性标签、要 JOIN 的 info 指标以及要丰富到的（“数据”或“非标识性”）标签。请注意，“标识性标签”在此特定上下文中指的是用于识别相关 info 指标的标签集，并且与相关的非 info 指标共享。它们是在 Prometheus JOIN 查询  中 JOIN 的标签。概念上，它们可以与关系数据库中的外键 进行比较。

除了主要功能外，info() 还解决了困扰 JOIN 查询多年的一个微妙但关键的问题：当非标识性 info 指标标签发生变化时会导致查询失败的“变动问题”，以及缺失的陈旧性标记（如 OTLP 摄取中的情况）。

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

Prometheus 的目标重新标记功能允许您修改已发现目标的标签，甚至完全删除目标。重新标记规则虽然强大，但可能难以理解和调试。您的规则必须与服务发现机制返回的预期标签匹配，并且任何一个步骤的错误都可能导致目标被错误标记或意外删除。

为了帮助您弄清楚问题出在哪里（或对在哪里），Prometheus 3.8.0 刚刚在 Prometheus 服务器的 Web UI 中添加了一个重新标记可视化工具 ，该工具允许您检查每个重新标记规则如何应用于已发现目标的标签。让我们看看它是如何工作的！

我第一次接触 Prometheus 项目是通过 Linux Foundation 导师计划 ，在那里我进行了用户体验研究。我记得当我被选为受训者时感到多么焦虑。我不仅对 Prometheus 是新手，对可观测性也是新手。我担心自己力不从心，在一个高度以开发人员为中心的领域工作，却没有开发背景。

事实证明，那种焦虑是多余的。我继续为该项目做出了有意义的贡献，并且我了解到，我所经历的几乎是所有对开源做出非技术贡献的人的普遍感受。

如果您也感到同样的担忧，那么这篇文章就是为您准备的。我将分享您可能会面临（或已经面临）的挑战，您的贡献为何重要，以及如何找到在 Prometheus 社区中的位置。

Yet Another Cloudwatch Exporter  (YACE) 已正式加入 Prometheus 社区！此举将使其对用户更加易于访问，并为贡献者提供了增强和维护该项目的新机会。此外，您还可以从Cristian Greco 的视角 阅读一篇博文。

早期

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

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

在柏林 PromCon 上 Prometheus 3.0 beta 发布后，Prometheus 团队很高兴地宣布 Prometheus Version 3.0 已正式发布！

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

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

Prometheus 团队很荣幸地宣布 Prometheus Version 3.0-beta 版本现已发布！您可以在这里 下载。按照 beta 版本发布的传统，我们不建议用户在关键生产系统上安装 Prometheus 3.0-beta，但我们希望每个人都进行测试并找出 bug。

总的来说，唯一的破坏性更改是移除了已弃用的功能标志。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 周围最紧迫的话题提供一个新鲜且信息丰富的视角。

Prometheus 团队成员、今年 PromCon 项目委员会负责人、Polar Signals 高级软件工程师 Matthias Loibl 表示：“我们非常高兴 PromCon 回到柏林。Prometheus 于 2012 年在柏林 Soundcloud 公司启动。第一届 PromCon 在柏林举办，之后移至慕尼黑。今年，我们将在腓特烈斯海因的 Radialsystem 举办约 300 名与会者。“柏林拥有充满活力的 Prometheus 社区，许多 Prometheus 团队成员居住在该地区。这是一个绝佳的机会，可以与所有热衷于系统和服务监控的 Prometheus 大家庭成员进行交流和联系。“这将是一个了解 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的技术负责人。业余时间，他与 O'Reilly 合作撰写一本题为《高效 Go》的书。观点仅代表个人！

我个人喜欢 Prometheus 项目的一点，也是我加入该团队的众多原因之一，是它对项目目标的专注。Prometheus 始终致力于在提供实用、可靠、廉价但非常有价值的基于指标的监控方面突破界限。Prometheus 超稳定和强大的 API、查询语言和集成协议（例如 Remote Write 和OpenMetrics ）允许云原生计算基金会 (CNCF) 指标生态系统在这些坚实的基础上成长。因此，发生了许多了不起的事情。

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

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

今天，我们启动了 Prometheus Conformance Program，目标是确保 Prometheus 监控领域不同项目和供应商之间的互操作性。尽管法律文件仍需最终确定，但我们已经进行了测试，并认为以下是我们第一轮的测试结果。作为此次发布的一部分，Julius Volz 更新了他的 PromQL 测试结果 。

快速提醒一下：该计划称为 Prometheus Conformance（合规性），软件可以compliant（符合）特定测试，从而产生compatibility（兼容性）评级。这种命名法可能看起来很复杂，但它使我们能够就此话题进行讨论，而无需使用冗长的陈述。

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

“Prometheus”和“Thanos”的名字最近被一个勒索软件组织采用 。我们对此无能为力，只能告知您这种情况正在发生。您也无能为力，只能意识到这种情况正在发生。

虽然我们不认为该组织会试图诱骗任何人下载我们项目的虚假二进制文件，但我们仍然建议遵循常见的供应链和安全实践。部署软件时，请通过以下机制之一进行部署：

如CNCF 和我们自己所宣布的那样，我们正在启动一项 Prometheus 合规性计划。

为了让大家在正式运行测试前对生态系统的现状有一个整体了解，我们想展示一下我们快乐的小型测试套件系列中的最新成员：Prometheus Remote Write 合规性测试套件，它根据我们的 规范  来测试 Remote Write 协议的发送端。

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

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

CNCF 治理委员会预计将在下次会议上正式审查和批准该计划。我们邀请更广泛的社区在这一启动阶段帮助改进我们的测试。

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

您是否曾经选择某个事物的 Top 10 时间序列，但结果不是 10 个而是 100 个？如果是，那么这个内容是为你准备的。我将带您了解根本问题以及我是如何解决它的。

目前，topk() 查询仅在即时查询（ instant query ）中有意义，因为您可以获得正好 k 个结果。但当您将其作为范围查询（ range query ）运行时，您可能会获得远超 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 规范可能会发生变化，如果该功能具有任何 API（Web API、代码接口等）。
2. 功能的行为可能会发生变化。
3. 它们可能会打破您对 Prometheus 的某些假设。
   • 例如，查询不应超前于样本评估时间的假设，这将因 @ 修饰符和负偏移量而打破。
4. 它们可能不稳定，但我们当然会努力保持它们的稳定性。

新的 Prometheus 版本 2.13.0 已发布，和往常一样，它包含许多修复和改进。您可以 在此处  阅读已更改的内容。但是，有一些功能是某些项目和用户一直在等待的：分块、流式传输版本的 remote read API 。

在本文中，我将深入探讨我们在 remote 协议中进行的更改、更改的原因以及如何有效使用它。

Remote API

从 1.x 版本开始，Prometheus 就能够通过 remote API 直接与其存储进行交互。

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

• 写入 - 接收 Prometheus 推送的样本
• 读取 - 从 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 提供监控信息，在最新版本中甚至可以通过 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 的必要性降低了，因为可以安装常规工具。

与 SNMP 相比，您可以运行 node_exporter 或交换机内的任何其他 exporter，以人类可读的格式暴露您需要的任何指标。美好胜于丑陋，对吧？

我们使用 CumulusOS，在我们的情况下它主要是 x86，因此运行任何类型的 Linux 程序都没有问题。

简介

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

子查询支持的 pull request  最近已合并到 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 Business Intelligence 开发了一个创新组件。用户现在可以在一个全面的仪表板中获取实时、可操作的数据，以支持快速的问题-部署流程和网站的持续改进。

我们支持每月的页面浏览量高达 20 亿次，拥有一个完全致力于为高要求客户提供托管 WordPress 的 100 台机器集群。

我们目前正致力于为全球 WordPress 出版商提供最佳体验。在此过程中，Kubernetes 正在为我们通往高可用性 WordPress 托管基础设施的未来标准铺平道路。

我们很高兴地宣布，从今天起，Prometheus 在 CNCF  内毕业。

Prometheus 是 CNCF 有史以来第二个达到此级别的项目。通过使 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  的首席执行官。我曾从事分布式系统方面的工作，并且曾经营过 Datastreamer，一家构建了 PB 级分布式社交媒体爬虫和搜索引擎的公司。

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

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

我们持续评估云端运行的成本，对我们来说，我们的托管成本将是目前支付的 5-10 倍。

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

我们目前托管着一些 PB 级客户，并将在本月软启动我们的新平台。

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

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

自那时以来，我们增加了和改进了各种服务发现集成，扩展了 PromQL，并尝试了远程 API 的第一版，以实现可插拔的长期存储解决方案。

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

发生了什么

两周前，来自世界各地的 Prometheus 用户和开发者聚集在慕尼黑参加了第二次关于 Prometheus 监控系统的会议：PromCon 2017 。本次活动旨在交流知识和最佳实践，并围绕 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 Pages、Facebook Messenger、Twitter、Instagram、WhatsApp、SMS 等）集中与客户互动。我们的客户遍布 电子商务、银行、旅游、时尚等领域，分布在 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-as-a-Service。

您可以 免费试用 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 万个 Droplet（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 完全不同的系统。事实上，我们曾在最大的规模上使用过拉取式监控，这种说法与我们自身的运维经验相悖。

我们已经有一个关于 为什么 Prometheus 选择拉取而非推送 的 FAQ 条目，但它并没有特别关注可扩展性方面。让我们仔细看看关于这种说法常见的误解，并分析它们是否以及如何适用于 Prometheus。

一月，我们发布了一篇关于Prometheus 公开开发的第一年的博客文章，总结了对我们而言这是一段奇妙的旅程，也希望为你们提供了创新且有用的监控解决方案。自那时以来，Prometheus 已加入云原生计算基金会，我们身处一个优秀的环境，成为继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 代表原始 delta 编码，1 代表改进的 double-delta 编码。随着发布0.18.0 ，我们添加了版本 2，这是另一种 double-delta 编码。我们称之为varbit 编码，因为它在块内为每个样本使用可变位宽。虽然版本 1 在几乎所有方面都优于版本 0，但在版本 1 和 2 之间存在真正的权衡。这篇博客文章将帮助您做出决定。版本 1 仍然是默认编码，因此如果您在阅读本文后想尝试版本 2，您必须通过命令行标志显式选择它。来回切换没有坏处，但请注意，现有块一旦创建就不会更改其编码版本。但是，这些块将根据配置的保留时间逐渐淘汰，从而被带有命令行标志中指定的编码的新块替换。

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

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

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

ShowMax 是一家订阅式视频点播服务，于 2015 年在南非推出。我们拥有丰富的节目库，包含超过 20,000 集电视剧和电影。我们的服务目前在全球 65 个国家/地区提供。虽然在美国和欧洲的竞争对手们正在激烈交战，ShowMax 却面临着一个更严峻的问题：如何在撒哈拉以南非洲连接不佳的村庄里 binge-watch？全球已有 35% 的视频流媒体播放，但仍有许多地方未受这场革命的影响。

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

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

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

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

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

Life360 创建技术来帮助家庭保持联系，我们是家庭的网络应用。我们忙于处理这些家庭——在高峰时段，每分钟处理 70 万次请求，为 7000 万注册家庭服务。

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

我们在 MySQL 主-主集群和我们的 12 节点 Cassandra 环中存储用户数据，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 Summer 期间如何利用 Prometheus 将我们的监控提升到一个新的水平。

在 John Allspaw 的《致监控/指标/告警公司的公开信 》中，他声称“试图完美地、及时地检测异常是不可能的”。

我曾见过几位才华横溢的工程师试图构建系统，根据时间序列数据自动检测和诊断问题。虽然制作演示版本是可能的，但对于现实世界中非常简单的系统之外的任何东西，数据总是过于嘈杂，无法使这种方法奏效。

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

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

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

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

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

自从我们公开宣布 Prometheus v0.10.0 以来，已经过去了近三个月，现在我们已经更新到 v0.13.1。

SoundCloud 的公告博客文章 仍然是 Prometheus 关键组件的最佳概述，但围绕 Prometheus 还有很多其他的在线活动。这篇帖子将让您了解您错过的任何内容。

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