在PromCon Online 2020期间，我作了题为“普罗米修斯及其生态系统的未来”的演讲。我想与您分享其要点。
概要
自上一次PromCon会议-2019年以来，Prometheus发生了许多变化。
2.14
2.14 版本在React中引入了一个新接口。尽管它的功能仍落后于旧功能，但我们正在努力并继续对其进行改进。
2.15
版本2.15属于Metadata API的标志。该普罗米修斯曝光格式长期以来一直支持独特的表达
HELP，TYPE等等，但是普罗米修斯本身用来简单地丢弃该数据。现在它们仍然存在，您可以通过API打开对它们的外部访问。例如，Grafana已经利用了这一机会，并向用户提供有关其工作时间序列的其他信息：
2.16
2.16 版着重于各种改进和稳定性。例如，自2016年以来，用户一直在询问是否可以在UI中选择本地时间以及查询日志的实现-很好地解决了这些问题。
2.17
说到挥之不去的功能请求，版本2.17终于在ACID中为数据库带来了期待已久的“ I” ：隔离。
2.18
在2.18中，改进了对公开格式实例的跟踪和支持。实例是在Prometheus中实现OpenMetrics的第一个用户注意到的影响。通过将它们与Grafana结合使用，可以实现方便的粒度，从而使您可以从
... ...转到：
2.19
在2.19中，我们减少了多达50％的内存消耗！尽管Prometheus已经非常有效，但仍有很大的优化潜力-这既令人兴奋又令人生畏。
该图很好地说明了这一点：
2.20
2.20 版拥有自v2.6（！）以来最长的变更日志。主要的一种可能是对Docker Swarm和DigitalOcean的本机服务发现支持。
但是，除了实现两个独立的服务发现机制之外，还有一个更重要的变化：我们将Prometheus与众不同，并重新审视了许多旧的解决方案和已建立的方法。世界已经发生了变化（也许我们也对此有所帮助）-在项目本身和其他方面都必须考虑到这一点。
node_exporter
总而言之，我想指出的是，node_exporter已达到1.0版，现在包括EXPERIMENTAL TLS支持。云原生计算基金会赞助了Cure53对node_exporter的审核（它既涵盖了一般的导出者，也涵盖了我们的TLS实施）。这是值得的：我们不仅在将TLS复制到其他出口商之前检查了TLS，而且还使用node_exporter作为豚鼠来复制其他模式。
未来
有时候，我觉得我们作为一个项目，正在固步自封。不久前，我以格言“普罗米修斯缺乏特色”为座右铭，在格拉法纳（Grafana）进行了一次集思广益的会议，并鼓励红帽做同样的事情。在整个过程中，我们创建了有关Prometheus整个团队均可使用的所有内容的文档。它用作解决特定主题的框架，在开发高峰期间（一旦这些要点准备好）就分解为要讨论的要点。
开发者峰会
去年，我们举行了两次开发峰会：一次在KubeCon欧盟之后，第二次在PromCon之后。原计划在2020年做同样的事情，但是COVID阻止了。今年没有峰会，但我相信我们已经找到了出路：更短，更频繁和虚拟的会议。我们将花费4个小时而不是一次花费1-2天。第一次此类开发者峰会于7月10日举行，下一次峰会可能于8月7日举行。在处理完所有累积的问题之前，我们将继续进行处理（尽管随着上述文档中越来越多的项目添加，它们的数量一直在不断增长）。
现在，我想做两件事：
- , . , , . , . — , , .
- , , . , , .
元数据开始为Prometheus带来真正的价值（请参阅上面的2.15）。我们需要实现更多选项来处理元数据（例如，通过远程读/写分发它）。以下共识未涵盖有趣的问题，例如“如果元数据更改/消失了怎么办？” 或“如果它们成为攻击媒介怎么办？”
共识：我们希望更好地维护元数据。这项工作将在一份特别文件中进行。
共识：PR 6815将作为一种实验性解决方法。最有可能的是，它在3.x版本中会有所不同。
工作流更改和s / master / main /
除去工作过程中堆积的垃圾这一主题不需要特殊说明，但是应该说几句有关消除废话（术语统一）的内容。我们认真对待清理术语：这不是最重要的事情，而是我们现在可以做的事情。在等待来自GitHub的相应工具包时。一旦出现，我们将尝试通过社区桥吸引带薪实习生从事这项工作。
我正在与Linux Foundation和CNCF进行谈判，以潜在地在所有项目中实现这一点。对于对此主题感兴趣的人来说，这是一个绝佳的机会：探索许多项目，使用各种工具并结识许多人的机会。通过Twitter（@TwitchiH）或通过邮件（richih与我联系 如果您有兴趣，请访问grafana.com。
共识：在所有Prometheus /存储库中设置“在合并之前需要状态检查” ...不允许在主分支中直接推送？不允许强行推入主分支？
共识：禁止强行推入所有主要分支。
共识：缺省行为允许压入主分支，但是对于某些“重要”存储库，应禁用它，例如prometheus / prometheus（由维护者自行决定）。
填充数据（回填）
这是最古老的功能要求之一，也是如何达成共识的一个很好的例子。普罗米修斯团队在这个问题上有很多不同的意见，很难达成共识。因此，我写了一个有限且非常具体的共识提案，其中包含三个标准：“我们希望至少在不与起始区块重叠的区块中支持通过网络回填。” 经过冗长的讨论并试图达成共识，很明显，这并非易事。因此，我重新拟订如下：“我们要支持回填在网络上至少流是不相交用头块
”。
只有通过强制每个人发表在这个问题上他们自己的意见，我们能够走到最后的版本：“我们愿意支持回填在通过网络 块是不相交与头块，只要它是正确实施。”选择此处的每个词来反映共识的确切范围和边界。
: Prometheus OpenMetrics, CSV- .
: backfilling , .
: backfilling , .
: backfilling , .
与使事情井然有序相关的另一项任务。在这里，我要批评Go：它是在一个单声道为标准的世界中开发的。 Google将所有（或大部分）通用代码存储在一个存储库中。这种方法具有许多优点，但是不能很好地转化为现实条件。 Go正在缓慢但必定会逐渐摆脱这一遗产。
有趣的事实：我几乎在讨论开始时就写了共识性建议。很明显，我们至少会尝试一下。显然，本·科奇（Ben Kochie）会自愿这样做。很显然，node_exporter将成为“受害者”。通常，我们会努力改善工作流程，Ben始终是志愿者，node_exporter是测试平台，然后从中将结果复制到其他导出器。是的，很重要的一点是，讨论要持续一段时间，人们要自己解决这个问题，而不是面对事实。
共识：在node_exporter中将其删除，看看我们是否对结果满意。
邮件列表和IRC
Google在中国被封锁，但是我们的邮件列表可以在中国使用。我们决定尝试通过电子邮件进行订阅。我检查了一下：prometheus-users+subscribe@googlegroups.com有效。如果愿意，您还可以阅读档案（https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html）。
另外，我们确保每个人都可以通过矩阵使用IRC，因为对于某些xkcd 1782来说，IRC是非常相关的。
:
, Google ; - .
docs/community , Google.
IRC, Matrix; , .
让我重复我在峰会上所说的话：“我不喜欢2015年普罗米修斯的第一件事就是文档；在2020年，我只是讨厌她。它很难使用并且几乎没有用，仅适用于已经知道自己在做什么或者至少对这些概念有一个好主意的人。简而言之，我们将朝着这个方向努力：
:
:
* (user manual) .
* (reference) , PromQL /.
* (guides), .
Diana Payton , .. .
.
如果您有兴趣，我们目前正在寻找Grafana Cloud上的技术撰稿人，他将负责Prometheus的官方上游文档。归根结底，我们认真对待社区。
与往常一样，dev-summit中的注释将被发布。您还可以阅读2020-1峰会和过去几年的峰会的结果。
译者的PS
另请参阅我们的博客：