在监控领域中，Graphite和Prometheus目前似乎存在着明显的对立。在MetricFire，我们提供Graphite和Prometheus两者作为服务。作为MetricFire的观点，这两者都是可靠的选择，但用户在做决定时应注意的重要因素是最终希望如何进行监控。

让我们介绍这篇文章中最重要的区别，以及在使用各自的服务时如何进行比较。

请务必尝试MetricFire的Hosted Graphite和Hosted Prometheus的免费试用，看看它们如何适应您的使用需求。

总结

Prometheus与Graphite是两个以时间序列数据库为核心构建的开源监控平台。每个数据点都标有一个用于识别的名称和/或标签，作为其独特的时间序列的一部分。Prometheus始终支持标签（在Prometheus术语中称为标签），而Graphite在2018年引入了标签的概念。

Prometheus和Graphite最初使用时最明显的区别在于Prometheus是通过主动获取方式（拉取）从目标终端点请求指标数据，而Graphite则是被动接收方式（推送），只要格式正确就接收指标数据。这被称为“拉取指标与推送指标”，是服务之间许多其他差异的核心模型之一。

石墨的机制

请点击此链接了解有关Prometheus或Graphite的更多信息：https://www.promlts.com/resources/prometheus-or-graphite#

石墨从10年前开始存在并且非常受欢迎。然而，启动和运行服务器有些棘手。

Graphite采用了比Prometheus更简单的架构，分为三个部分。

数据收集

Graphite有三个Carbon守护程序，可以将数据点转换为新的指标并进行聚合，或提供一个中继器以将数据传输到多个存储后端。Carbon可以被动地接收各种协议的指标，并且除了简单的字符串格式之外没有其他要求。这使得在应用程序内轻松生成指标，并可以通过UDP快速发送，或通过TCP更可靠地发送，还可以对逐行分离的数据点进行批量处理和打包，或使用Python的pickle对象进行处理。

数据点的存储

普通的石墨会使用Whisper数据库格式来保存指标数据。Carbon中继会执行复制和一致性的哈希处理，并支持分片的指标存储，以增加冗余性和容量。在Whisper中，需要预先确定存储的总时间框架，包括规定随时间推移解决方案的规则。一旦确定存储标准，文件就会被创建，使用的总空间量会立即被使用，并且不会被更改。

数据可视化

Graphite使用简单的Django应用程序可以将度量图可视化。还可以使用Graphite函数进行查询和转换，提供渲染API以访问外部服务，如Grafana。

普罗米修斯的机制

请点击以下链接了解Prometheus或者Graphite:
https://www.promlts.com/resources/prometheus-or-graphite#

Prometheus是Google Borgmon工具的直系后裔，由专注于处理高度容器化环境的工程师开发而成。这是为SREs (Site Reliability Engineers) 所创造，旨在满足SREs的需求，并具备一些出色的功能，但要充分发挥其优势，则需要更高级的专业知识和访问权限。与现有服务的集成可能不直观，但只需安装和执行即可简单搞定。

普罗米修斯并不是简单地分成部分，但为了完成工作，承担的任务仍然是被区分的。

获取数据点

Prometheus会通过HTTP连接到目标端点以请求指标。此作业可以包含包含端点的静态配置，或者设置服务发现来告诉Prometheus在哪里找到指标。

数据点存储

普罗米修斯将指标保存在本地磁盘的一个位置。根据设置的“记录规则”，在保存指标之前可以进行一些转换。指标最初以2小时的块形式保存在内存中，然后被压缩为更长时间的块形式。默认保留期为15天。普罗米修斯的设计目的是将其用作数据滑动窗口，而不是长期存储数据。

数据可视化

Prometheus提供了一个图形化界面，用户可以使用PromQL查询语言来探索指标或绘制简单的图表。此外，它还提供了查看监测对象端点、任意报警规则及其当前状态的功能，以及轻松确认当前配置的方法。查询API还允许第三方应用（如Grafana）使用PromQL请求指标数据。

警报

Prometheus与Graphite不同，它内置了警报功能，但在确认警报规则或将警报状态显示在UI页面方面有一定的限制。AlertManager是另一个工具，可以同时处理多个Prometheus服务器的警报通知。

你对每个服务的使用感受如何？

（1）编写需要监视的应用程序的方法

监视构建者本身并不实际进行监视，但必须为其他用户设置好监视功能，以便他们能够进行监视。

石墨的优点是：

为了发送Graphite格式的数据点，向应用程序代码中添加行非常简单，相对直观和简单。有一些支持这一功能的模块和库，但是编写自己的代码是最简单的选择，并且没有任何维护依赖。Hosted Graphite语言指南中提供了一些示例供您参考。

石墨的缺点：

1. 如果应用程序非常活跃，会在非常短的时间内发送大量数据点，可能会给Graphite的摄入处理带来压力（这是高频批处理服务中最常见的问题）。

 

如果出站流量受限，可能会导致防火墙问题。

普罗米修斯的优点：

1. 有几个优秀的客户端库可以将Prometheus的指标添加到代码中，并支持创建/metrics端点并根据请求提供数据。还有编写导出器的指南可供参考。

 

一旦设置完成，即使Prometheus实例移动，也不需要更改应用的配置。

Prometheus的缺点:

1. 客户端库表示需要额外的依赖来进行跟踪，并且如果没有管理自己的监控服务器，则Prometheus管理员始终需要设置作业以获取指标。

 

1. Prometheus服务器需要有访问应用程序运行的服务器或容器的权限，并且最理想的情况是通过服务发现进行发现。

 

如果应用程序是短期服务或批处理服务，则可能需要设置Prometheus的Pushgateway。

（2）监视单一环境如容器集群。

负责监控应用程序的运行环境和性能，甚至包括未由自己编写的部分，以满足工程师和SRE团队的责任。

石墨的优点是：

1. 有许多监视代理可以将Graphite格式的度量发送到给定的任意端点。

 

1. 分层度量的命名格式可以很好地反映环境的常见结构（环境→节点组→服务器→服务），但Graphite还支持为多维度度量标记。

 

度量可以从任何地方发送到中央的Graphite服务器，并可以使用存储集群以实现冗余性。

石墨的缺点：

1. 由于大多数监控代理的默认点层次指标名称包含主机名，因此当主机名更改时（例如容器扩展或AWS EC2实例重新启动），将创建新的指标集。

 

1. 如果指标接收停止，其准确的含义是不明确的-无法确定是否存在指标发送问题或者指标生成已停止，需要进行审查才能确定。

 

1. 同样，虽然可以启动具有指标发送问题的新服务器/服务，但在至少接收到指标一次之前，无法自动知道指标是否丢失。

 

1. 警报功能需要完全独立处理，例如使用Grafana警报或者Cabot等。并不是所有容器都具有将指标发送到外部的访问权限。

 

在容器监控代理中，与Graphite的集成并不理想。集群或集群中主机名的频繁更改可能会导致无关数据增加指标计数。

Prometheus的优点：

根据环境的不同，支持Prometheus监控的监控代理有许多选项，其中包括cAdvisor，它是一种主要的Docker容器监控工具。您可以通过服务发现来获取要抓取的端点列表 – Prometheus是为Kubernetes构建的，因此k8s的Pod和节点容器是不断变化的，但k8s可以随时提供端点列表。抓取任务意味着当指标不再流动时，可以轻松发现端点是否停止响应 – 端点状态始终在进行监控。由于对端点的访问是通过在本地运行Prometheus来处理的，所以不会出现外部防火墙的问题。

Prometheus的缺点：

1. 服务发现受到限制，仅支持有限数量的服务，若要支持更多服务，需使用基于DNS的发现或生成包含详细信息的文件。如果不监控标准服务，则需要特殊服务来创建和维护。

 

1. 有两种选择，即使用有限的时间框架的指标存储或使用环境资源。

 

1. 由于所有内容都在集群内执行，所以即使集群出现问题，也没有冗余性。在集群外执行会增加额外成本，可能导致无法访问容器内的服务。

 

在全球范围内跨越其他团队作为服务运行是困难的。请参阅以下部分（监控多个环境/位置）进行说明。

(3) 监视多个环境和地点

不仅仅是一个环境，还涉及监控SRE或监控团队，负责监视具有不同物理位置和网络环境的多个环境。

石墨的优点：

1. 如果每个位置/环境都具有发送出站数据的能力，则不会有访问或权限问题。

 

1. 指标可能在世界各地的不同位置生成，但可以设置一个地方来查看它们。

 

所有环境都可以使用自定义的设置进行监控和指标生成，不需要准备每个开发团队的专家。

石墨的缺点是：

如果Graphite的端点移动或更改，则需要将新值推出到整个车队，并重新启动适当的服务以捕获它。另外，为了符合安全合规性，可能需要限制发送数据点到网络外端点的出站流量。这些问题可以通过使用本地的Carbon中继或statsd服务器来处理，这样可以减少需要重新配置的位置数量，但也会增加需要维护的不同服务数量。

普罗米修斯的优点：

通过将Prometheus的安装和配置简化自动化，使得这种多站点环境设置的维护更加容易。

Prometheus的缺点:

1. 通常情况下，需要在逻辑上分离环境，并且由于Prometheus需要通过HTTP连接与每个服务进行通信，所以通常需要在与服务相同的网络中运行。

 

使用Prometheus联邦可以将指标集成到一个地方，但通常意味着进行降采样和指标聚合。对于SRE来说，他们可以直接访问每个环境的服务，所以这可能不是问题，但对于非SRE来说，尤其是在应用程序在多个环境/物理位置运行时，获取访问指标的权限可能会很困难。

(4) 图表阅读、指标浏览和警报设置等
商务分析师、销售代表、支持代理以及其他用户都希望能够从与自己无关的数据中提取出数据的含义。由于Prometheus是一个专为完整监视而构建的系统，因此对于不熟悉监视的人来说，它可能不是最理想的解决方案，因为可能难以理解。

石墨

• Graphiteは、モニタリングや（限定的な）異常検知だけでなく、ビジネスインテリジェンスやパフォーマンス分析など、あらゆる分野に適した機能を長年にわたって蓄積してきました。

 

• Graphiteのクエリ言語はシンプルなフォーマットで、プログラミングを少しでもやったことがある人なら誰でも知っているようなものです。それがなくても、それは非常に簡単に手に取ることができます。

 

• 階層的なメトリクスとオートコンプリートのサポートにより、メトリクスを生成するシステムについて直接知識がなくても、メトリクス名の参照が非常に簡単になります。Grafanaのようなツールは、メトリクスと同じように関数をブラウズできるようにするのに良い仕事をしています。

 

Graphiteには個別のアラートサービスが必要ですが、カジュアルなユーザーにとってはGrafanaのアラートサービスで十分な場合が多いです。

普罗米修斯

• PromQLは特定の言語や既存の構造に基づいているわけではないので、一から学ぶ必要があります。複雑すぎるわけではありませんが、Graphiteの関数ほど単純ではありません。

 

• 階層構造がないので、メトリクスのブラウジングが貧弱で、Prom自体もあまり役に立ちません。関数とキーワードは同じことをしているように見えますが、使い方が異なります。メトリックを取得せずに利用可能なタグを参照する機能はなく、タグの利用可能な値を参照する機能もありません。

 

• どのようなメトリクスやラベルが存在し、それらが何を意味するのかをすでに知っているという強い推測がありますが、これは一部のユーザーにとっては合理的ですが、他のユーザーにとってはそうではありません。

 

• 必要なすべてのデータを取得するために、異なる Prometheus サーバーの束にログインしなければならないかもしれませんが、それがどこで実行されているか、統合されているかどうか、どのようなメトリクスが統合されているかによって異なります。

 

古いメトリクスが必要になるかもしれない – remote_write と remote_read がそれを助けてくれますし、Metricfire のようなサービスにストレージをアウトソースすることもできます。

请问您觉得最适合您的工具是什么？

总结一下，选择Prometheus还是Graphite取决于您的具体情况。本文考虑了四个主要用例，讨论了两种工具的功能、相似之处与区别、优点和缺点。

根据我们之前所见，每个工具都有各自的优点和缺点，正确的选择取决于特定的使用情况和设置。

如果您不想花费时间在无用的设置上，并且希望立即以较低的成本开始监视，请尝试MetricFire的托管Prometheus和托管Graphite服务。您可以在14天的免费试用期内试用它们。

另外，您可以从这里预约示范，请进一步询问更详细的信息。

那么，在下一篇文章中见！