# **方案比较（Comparison to alternatives）** <br /> ## **Prometheus vs. Graphite** ### 领域范围（Scope） Graphite 专注于成为具有查询语言（Query language）和图形功能的被动时间序列数据库。 其他任何问题都采取通过外部组件解决。 Prometheus 是一个完整的监控和趋势分析系统，其中包括内置的基于时间序列数据的主动抓取，存储，查询，制图和报警。 它知道世界应该是什么样（应该存在哪些 endpoint，什么时间序列模式有问题等），并且能积极尝试查找错误。 ### 数据模型（Data model） Graphite 为已命名的时间序列存储数值样本，就像 Prometheus 一样。但是，Prometheus 的元数据模型更加丰富：虽然 Graphite metric 名称由点分割的组件（dot-separated components）组成，这些组件隐含地编码构建了维度（encode dimensions），但是 Prometheus 显式地将维度通过 K-V pair（称为标签 labels）进行编码，其将标签附加到一个 metric 上。这使得通过查询这些标签来过滤、聚合/分组、匹配更加的简单。 此外，尤其是当将 Graphite 与 StatsD 结合使用时，通常只在所有受监控的实例上存储聚合的数据，而不是将实例（instance）保留为一个维度，并能够深入分析单个有问题的实例。 例如，通常在 Graphite / StatsD 中，存储`通过 POST 请求 /tracks 且 response code 是 500 的 HTTP 请求数`的编码如下： ~~~ stats.api-server.tracks.post.500 -> 93 ~~~ 在 Prometheus 中，可以像这样编码相同的数据（假设三个api服务器实例）： ~~~ api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34 api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28 api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31 ~~~ ### 存储（Storage） Graphite 以 Whisper 格式将时间序列数据存储在本地磁盘上，这是一种 RRD 样式的数据库，它希望样本以固定的时间间隔到达。 每个时间序列都存储在一个单独的文件中，新样本在一定时间后会覆盖旧样本。 Prometheus 也对每个时间序列创建一个本地文件，但任意时间间隔抓取（arbitrary intervals as scrapes）和规则评估（rule evaluations）发生时，都允许存储样本。 由于新的样本是简单的追加到文件中，因此旧数据可以保留任意久。Prometheus 也适用于许多短生命周期的，经常变化的时间序列。 ### 总结（Summary） Prometheus 除了更易于运行和集成到您的环境之外，还提供了更丰富的数据模型和查询语言。 如果您想要一个可以长期保存历史数据的集群解决方案，那么Graphite 可能是一个更好的选择。 ## **Prometheus vs. InfluxDB** ## **Prometheus vs. OpenTSDB** ## **Prometheus vs. Nagios** ## **Prometheus vs. Sensu**