Prometheus thanos Victoriametrics比较 victoria prometheus 区别 转载
IDE,运维,k8s,Prometheus相关视频讲解：
C语言程序设计入门之环境安装
Linux shell脚本编程入门详细讲解
Prometheus监控系统介绍
Thanos和 VictoriaMetrics都是用来作为 Prometheus 长期存储的成熟方案，其中 VictoriaMetrics也开源了其集群版本，功能更加强大。
主要功能：
长期存储，可以保留任意时间的监控数据。
对多个 Prometheus 实例采集的数据进行全局聚合查询。
可水平扩展。
Thanos：
Thanos包含以下几个核心组件：
Sidecar:
每个 Prometheus 实例都包含一个 Sidecar，它与 Prometheus 实例运行在同一个 Pod中。它有两个作用：
将本地超过 2 小时的监控数据上传到对象存储，如 Amazon S3 或 Google 云存储。
将本地监控数据（小于 2 小时）提供给 Thanos Query 查询。
Store Gateway :
将对象存储的数据提供给 Thanos Query 查询。
Query:
实现了 Prometheus 的查询 API，将 Sidecar和对象存储提供的数据进行聚合最终返回给查询数据的客户端。
Compact :
默认情况下，Sidecar 以 2 小时为单位将监控数据上传到对象存储中。Compactor会逐渐将这些数据块合并成更大的数据块，以提高查询效率，减少所需的存储大小。
Ruler :
通过查询 Query获取全局数据，然后对监控数据评估记录规则[11]和告警规则，决定是否发起告警。还可以根据规则配置计算新指标并存储，同时也通过 StoreAPI 将数据暴露给 Query，同样还可以将数据上传到对象存储以供长期保存。由于 Query 和底层组件的可靠性较低，Ruler组件通常故障率较高。
Receiver :
这是一个实验性组件，适配了 Prometheus 的 remote write API，也就是所有Prometheus 实例可以实时将数据 push 到 Receiver。在 Thanos v0.5.0 时，该组件还没有正式发布。
架构图：
Thanos 需要通过以下步骤来建立写入过程：
禁用每个 Prometheus 实例的本地数据压缩。具体做法是将 --storage.tsdb.min-block-duration 和 --storage.tsdb.max-block-duration 这两个参数的值设置为相同的值。
Thanos 要求关闭压缩是因为 Prometheus 默认会以 2, 25, 25*5 的周期进行压缩，如果不关闭，可能会导致 Thanos 刚要上传一个 block，这个 block 却被压缩中，导致上传失败。更多详情请参考这个 issue[17]。如果 --storage.tsdb.retainer.time 参数的值远远高于 2 小时，禁用数据压缩可能会影响 Prometheus 的查询性能。
在所有的 Prometheus 实例中插入 Sidecar，这样 Sidecar 就可以将监控数据上传到对象存储。
设置 Sidecar 监控。
为每个对象存储的 bucket 配置压缩器，即 Compact 组件。
1.
2.
3.
4.
5.
6.
7.
8.
9.
VictoriaMetrics：
VictoriaMetrics 集群版包含以下几个核心组件：
vmstorage : 存储数据。
vminsert : 通过 remote write API 接收来自 Prometheus 的数据并将其分布在可用的vmstorage 节点上。
vmselect : 从 vmstorage 节点获取并聚合所需数据，返回给查询数据的客户端（如Grafana）。每个组件可以使用最合适的硬件配置独立扩展到多个节点。
架构图：
VictoriaMetrics 需要在 Prometheus 中添加远程存储的配置，以将采集到的样本数据通过 Remote Write的方式写入远程存储 VictoriaMetrics 中，不需要在 Prometheus 中插入 Sidecar，也不需要禁用本地数据压缩。
总结：
Thanos 和 VictoriaMetrics 分别使用了不同的方法来提供长期存储、聚合查询和水平扩展性。
VictoriaMetrics通过标准的 remote_write API[40] 接收来自 Prometheus 实例写入的数据，然后将其持久化（如 GCE HDD磁盘、Amazon EBS[42] 或其他磁盘）。而 Thanos 则需要禁用每个 Prometheus实例的本地数据压缩，并使用非标准的 Sidecar 将数据上传至 S3 或 GCS。同时还需要设置 Compactor，用于将对象存储bucket 上的小数据块合并成大数据块。
VictoriaMetrics 开箱即实现了全局查询视图的 Prometheus queryAPI。由于 Prometheus会实时将抓取到的数据复制到远程存储，所以它不需要在集群外建立任何外部连接来实现全局查询。Thanos 需要设置 StoreGateway、SIdecar 和 Query 组件才能实现全局查询。对于大型的 Thanos 集群来说，在 Query组件和位于不同数据中心（可用区域）的 Sidecar 之间提供可靠安全的连接是相当困难的。Query 组件的性能会受到性能最差的Sidecar 或 Store Gateway 的影响。
VictoriaMetrics 集群可以快速部署到 Kubernetes中，因为它的架构非常简单[44]。而 Thanos 在 Kubernetes 中的部署和配置非常复杂。
-----------------------------------
Prometheus thanos Victoriametrics比较 victoria prometheus 区别
https://blog.51cto.com/u_14172/10431195
C语言程序设计入门之环境安装
Linux shell脚本编程入门详细讲解
Prometheus监控系统介绍
Thanos和 VictoriaMetrics都是用来作为 Prometheus 长期存储的成熟方案，其中 VictoriaMetrics也开源了其集群版本，功能更加强大。
主要功能：
长期存储，可以保留任意时间的监控数据。
对多个 Prometheus 实例采集的数据进行全局聚合查询。
可水平扩展。
Thanos：
Thanos包含以下几个核心组件：
Sidecar:
每个 Prometheus 实例都包含一个 Sidecar，它与 Prometheus 实例运行在同一个 Pod中。它有两个作用：
将本地超过 2 小时的监控数据上传到对象存储，如 Amazon S3 或 Google 云存储。
将本地监控数据（小于 2 小时）提供给 Thanos Query 查询。
Store Gateway :
将对象存储的数据提供给 Thanos Query 查询。
Query:
实现了 Prometheus 的查询 API，将 Sidecar和对象存储提供的数据进行聚合最终返回给查询数据的客户端。
Compact :
默认情况下，Sidecar 以 2 小时为单位将监控数据上传到对象存储中。Compactor会逐渐将这些数据块合并成更大的数据块，以提高查询效率，减少所需的存储大小。
Ruler :
通过查询 Query获取全局数据，然后对监控数据评估记录规则[11]和告警规则，决定是否发起告警。还可以根据规则配置计算新指标并存储，同时也通过 StoreAPI 将数据暴露给 Query，同样还可以将数据上传到对象存储以供长期保存。由于 Query 和底层组件的可靠性较低，Ruler组件通常故障率较高。
Receiver :
这是一个实验性组件，适配了 Prometheus 的 remote write API，也就是所有Prometheus 实例可以实时将数据 push 到 Receiver。在 Thanos v0.5.0 时，该组件还没有正式发布。
架构图：
Thanos 需要通过以下步骤来建立写入过程：
禁用每个 Prometheus 实例的本地数据压缩。具体做法是将 --storage.tsdb.min-block-duration 和 --storage.tsdb.max-block-duration 这两个参数的值设置为相同的值。
Thanos 要求关闭压缩是因为 Prometheus 默认会以 2, 25, 25*5 的周期进行压缩，如果不关闭，可能会导致 Thanos 刚要上传一个 block，这个 block 却被压缩中，导致上传失败。更多详情请参考这个 issue[17]。如果 --storage.tsdb.retainer.time 参数的值远远高于 2 小时，禁用数据压缩可能会影响 Prometheus 的查询性能。
在所有的 Prometheus 实例中插入 Sidecar，这样 Sidecar 就可以将监控数据上传到对象存储。
设置 Sidecar 监控。
为每个对象存储的 bucket 配置压缩器，即 Compact 组件。
1.
2.
3.
4.
5.
6.
7.
8.
9.
VictoriaMetrics：
VictoriaMetrics 集群版包含以下几个核心组件：
vmstorage : 存储数据。
vminsert : 通过 remote write API 接收来自 Prometheus 的数据并将其分布在可用的vmstorage 节点上。
vmselect : 从 vmstorage 节点获取并聚合所需数据，返回给查询数据的客户端（如Grafana）。每个组件可以使用最合适的硬件配置独立扩展到多个节点。
架构图：
VictoriaMetrics 需要在 Prometheus 中添加远程存储的配置，以将采集到的样本数据通过 Remote Write的方式写入远程存储 VictoriaMetrics 中，不需要在 Prometheus 中插入 Sidecar，也不需要禁用本地数据压缩。
总结：
Thanos 和 VictoriaMetrics 分别使用了不同的方法来提供长期存储、聚合查询和水平扩展性。
VictoriaMetrics通过标准的 remote_write API[40] 接收来自 Prometheus 实例写入的数据，然后将其持久化（如 GCE HDD磁盘、Amazon EBS[42] 或其他磁盘）。而 Thanos 则需要禁用每个 Prometheus实例的本地数据压缩，并使用非标准的 Sidecar 将数据上传至 S3 或 GCS。同时还需要设置 Compactor，用于将对象存储bucket 上的小数据块合并成大数据块。
VictoriaMetrics 开箱即实现了全局查询视图的 Prometheus queryAPI。由于 Prometheus会实时将抓取到的数据复制到远程存储，所以它不需要在集群外建立任何外部连接来实现全局查询。Thanos 需要设置 StoreGateway、SIdecar 和 Query 组件才能实现全局查询。对于大型的 Thanos 集群来说，在 Query组件和位于不同数据中心（可用区域）的 Sidecar 之间提供可靠安全的连接是相当困难的。Query 组件的性能会受到性能最差的Sidecar 或 Store Gateway 的影响。
VictoriaMetrics 集群可以快速部署到 Kubernetes中，因为它的架构非常简单[44]。而 Thanos 在 Kubernetes 中的部署和配置非常复杂。
-----------------------------------
Prometheus thanos Victoriametrics比较 victoria prometheus 区别
https://blog.51cto.com/u_14172/10431195
