普罗米修斯出现以后已经过了很长时间，生态系统变得复杂起来。当开始学习新知识时，如果不了解背景，就无法理解目前的状况。因此，我认为有必要提供一个大致的历史解释来作为辅助，我会将其记录下来。如果发现有记忆错误或理解不足导致的错误，我会及时进行修订。

普罗米修斯登场前的监视

一般来说，我们会为每个服务器（服务）部署一个代理（进程），代理会将数据推送到中央集中的监控服务器。

在规模较大且难以扩展的在线部署环境中，这种类型的监控系统仍然在使用中。

在服务数量较少的情况下，这种形式运作得很好。
然而，随着云时代的到来，监控服务的数量开始爆炸增长，出现了“监控服务器负荷过重，感到困扰”的问题。

普罗米修斯的出场

在全球范围内，已经发现以下策略是解决由于“监视服务器负载过大而导致困扰”的问题的有效方法，同时保守主义者们也在为此苦苦挣扎。

• 各サービスに簡易的な web サーバを置き、メトリクスとして収集する意義のある情報を出力させる。

監視サーバは、自分の余力がある範囲で、各サービスにある web サーバへ問い合わせ、時系列データとして保存する。

虽然不一定非得坚持使用HTTP，但在目前来说，对于处理文本数据而言，HTTP是最便捷的协议。

通过从监视服务器（监视サーバ）进行拉取而不是推送（push）来实现思维的转变，从而诞生了适用于云时代大规模服务集群的监视工具。

起初，这似乎是谷歌内部的工具，但 Prometheus 将其知识开源化了。

远程书写

在 Prometheus 中，监控的风格发生了巨大的变化。然而，尽管 Prometheus 能够应对大规模的集群，但对于数据的持久性却没有深入考虑，导致长期数据保存方面存在问题。

作为解决这一问题的方法，我们提供了一种功能：“首先使用Prometheus收集指标，但如果需要长期保存，则将指标写入另一个时间序列数据库”。

这就是 Remote write。

灭霸、科尔特斯、米米尔

从规格上来说，支持远程写入的数据库可以使用任何查询语言。
但出现了一种特意与Prometheus的查询语言PromQL兼容的解决方案。
首先，诞生了Thanos。

因此，可以通过相同的查询语句，实现以下的灵活运用。

• 直近のデータは(DBのサイズが小さいので検索が軽い) Prometehus で

古いデータは Remote write 先の Thanos で

然而（特别是在初期阶段），Thanos 在资源消耗方面存在难题，并且在操作上很困难。为了解决这个问题，Cortex作为竞争对手出现了，然后GrafanaLab公司对其进行了分叉，产生了Mimir。

虽然可能还有其他的实施方式，但只要掌握了上述的三种开源软件实施方法。

代理人模式

随着像Thanos一样兼容PromQL的存储方案的普及和性能的改善，人们开始思考是否可以直接向Remote write的目标发送查询而不是使用Prometheus。随着这样的趋势出现，开始有人开始尝试这种方式进行操作。

远程写入是一种推送方式。
回想起之前的Prometheus监测工具，这可能看起来像是倒退，但实际上不仅仅是简单地倒退。“首先通过Prometheus进行拉取收集，然后再一次性通过远程写入进行推送”，这样的操作并不是简单的倒退。软件技术的进步往往是“寄人篱下，再倒还”的形象，这在这里也适用。

无论如何，如果在Remote write上进行查询的话，Prometheus不需要查询功能。也就是说，可以更加轻量化Prometheus。除了省资源这个好处之外，还可以减少源代码量，从而减少错误的期望值。

结果，实施了 Prometheus 的代理模式，仅进行指标的抓取和远程推送。

Grafana代理

顺便说一下，除了以”agent mode”运行的Prometheus之外，还有一个提供类似功能的开源软件，叫做grafana-agent。
提起Grafana，我们通常会想到可视化工具，但是grafana-agent与可视化工具没有直接的关系。它由Grafana的开发公司GrafanaLabs提供。有点令人困惑。

受管服务和Prometheus

Azure、AWS等的”Prometheus”作为托管服务提供，实际上更接近于将其视为类似Thanos的”PromQL和Remote write兼容的时序数据库”，这更符合现实情况。

光读了《入门Prometheus》这样的书，并没有足够的知识来理解到这个程度，所以很容易会有”为什么需要agent呢?”这样的疑问。

总结

在Prometheus及其周边领域，经历了这样的变化。最后提到，如果您想要尝试Prometheus但担心维护可用性太麻烦，那么您可以在本文中找到一些整理…应该。

另外，正如开头所提到的，这里可能存在记忆错误或理解不足导致的错误记录，并非完全可信，请核实…