Grafana Mimir 和VictoriaMetrics：性能测试（上）

目录

前言：

方法

Prometheus-基准测试工具

Mimir设置

VictoriaMetrics 设置

衡量标准

快速统计

结果

---

前言：

        在进行性能测试时，Grafana Mimir和VictoriaMetrics是两个流行的工具，用于监控和分析系统的性能。
  根据 Grafana Labs 的测试，Mimir 可以扩展到十亿个活动时间序列和 5000 万个样本/秒的摄取率。该基准测试需要运行一个具有 7,000 个 CPU 内核和 30 TiB RAM 的集群，这使其成为我所听说的最大和最昂贵的时间序列数据库公共基准测试。做得好！
  重现如此规模的基准并不容易。幸运的是，在大多数情况下，用户的工作负载要求要低得多，更容易模拟。在这篇博文中，我将尝试比较 VictoriaMetrics 和 Grafana Mimir 集群在相同硬件上在中等工作负载下运行的性能和资源使用情况。

方法

  比较两种不同的产品最复杂的事情是保持透明和公正。特别是当您非常熟悉一种产品而对另一种产品完全陌生时。非常感谢 Mimir 的工程团队，我们在准备此基准时联系了他们。他们愿意并开放地回答与产品相关的问题并解释实施细节，这非常值得赞赏并且非常有帮助。
  VictoriaMetrics 和 Grafana Mimir 是时间序列数据库，支持大部分相同的协议和 API。但是，它们具有不同的体系结构和组件，这使得比较更加复杂。在基准测试中，我将使用有限数量的资源，并尽我所能将它们分配给两个集群。
  然后，我将运行一轮基准测试，看看这两种解决方案如何处理相同的工作负载，以及它们使用分配的资源的效率如何。
  基准测试将在 Google Kubernetes Engine 中运行，该引擎由 e2-standard-16 节点（每个节点有 16 个 vCPU 和 64GiB 内存）和基于标准 SSD 的持久卷组成。

Prometheus-基准测试工具

  为了生成负载，我将使用 Prometheus-benchmark 工具。它在 VictoriaMetrics 内部用于测试和基准测试新版本。我认为，由于以下原因，该工具会产生类似生产的工作负载：
●作为摄取指标的来源，它使用真实的 node_exporter 目标，这通常是大多数生产环境的情况；
●作为读取查询的来源，它使用推荐的 node_exporter 警报规则列表；
●非零指标流失率会产生额外的压力，模拟在 Kubernetes 中定期重新部署 pod 的场景。  Benchmark 运行两个相同的隔离服务集。它们中的每一个都被配置为抓取指标，通过远程写入将它们转发到配置的存储，并定期执行警报规则。基准测试的配置如下：

1. # how frequently to scrape node_exporter targets
2. scrapeInterval: 15s
3. # how often to execute configured rules
4. queryInterval: 15s
5. # defines the number of node_exporter instances to scrape
6. targetsCount: 6000
7. # percent of node_exporter targets to update
8. # in order to generate series churn rate
9. scrapeConfigUpdatePercent: 1
10. # specifies how frequently to update targets
11. # for generating time series churn rate
12. scrapeConfigUpdateInterval: 10m

  基准测试中的每个 node_exporter 目标生成大约 900 个（取决于运行 node_exporter 的硬件）时间序列。 targetsCount=6000 和 scrapeInterval=15s 以 360k 样本/秒的摄取速率生成大约 550 万个活动系列到每个配置的远程存储。配