在Grbob电竞频道afana实验室，我们看到越来越多的客户正在收集数亿个活动时间序列，但他们需要一种解决方案来可靠地存储和查询如此大量的数据。
所以在三月份，我们宣布我们新的开源TSDB，Grafana米密尔，是世界上可扩展性最强、性能最好的开源时间序列数据库。我们想要确保Grafana云，它运行于米密尔在为我们的客户解锁之前，可以轻松地大规模支持指标，因此在2021年，我们对Mimir进行了广泛的负载测试10亿活性系列(是的，10亿)。
我们也有机会测试极限Grafana企业度量它也在Mimir上运行。bob电竞频道Grafana实验室有一个对可伸缩性有极高要求的客户，希望在稳定状态下对5亿个活动系列的持续负载进行为期2周的压力测试。没有其他供应商能够满足该客户的这些要求，这使Grafana实验室有机会作为专家与他们合作bob电竞频道普罗米修斯在规模。在2022年2月，我们会见了GEM客户，并为我们的测试建立了目标:
- 5亿个活动系列，每度量可达500万个基数
- 每分钟10,000次查询
- 72小时的持续行动
在这篇博客文章中，我们将回顾我们如何与客户合作进行大规模测试的每个阶段，并使用Grafana Enterprise Metrics在客户的基础设施上成功地扩展Grafana Mimir。
第一次负载测试:50M活动系列，每分钟100个查询
对于这个客户，我们了解到使用我们的云是禁止的。相反，我们需要运行Grafana Enterprise Metrics，这是我们基于Grafana Mimir的预置企业度量解决方案。我们需要使用客户的云，所以我们决定在AWS中使用EKS集群构建一个镜像环境，其配置与客户的环境类似，只是更小。我们首先通过部署GEM短歌并在50M有源系列上进行基本负载测试。
为了达到我们的第一个基准，我们决定使用增量增加内部负载Grafana k6云测试以及错误和延迟导致Grafana转k6，在这个过程中不断调整以稳定集群。
最终，我们以10倍于我们通常运行的正常活动系列(15M vs 1.5M)来运行摄取器，以减少所需的副本数量。减少所需的副本数量非常重要，原因有两个:它减少了用于存储摄取器环的八卦集群的压力，并且减少了将配置更新推出到每个摄取器的时间。我们知道，当我们扩展到500米时，我们会稍微调整摄取器的配置，所以相对快速的推出对于高效地取得进展至关重要。(作为参考，当我们对10亿个活动系列进行负载测试时，每个摄取器运行5M个活动系列。)
我们能够向客户交付一组Kubernetes的初始清单，显示我们能够使用50M主动系列和100qpm运行。所以我们认为接下来的步骤很简单:从这里开始，我们只需要10倍的比例……对吧?
在GEM和Grafana Cloud上测试Grafana Mimir的差异
值得指出的是，我们使用GEM将Grafana Mimir扩展到5亿活跃系列与使用Grafana Cloud将活跃系列扩展到10亿之间的一些主要区别。
虽然两者在技术上使用相同的二进制文件，但Grafana Cloud有自动化层和整个Grafana实验室团队致力于维护平台。bob电竞频道所以对于这次500米的主动系列测试，重要的不仅仅是达到我们的目标。我们还想看看我们能在多大程度上让客户的运营团队在他们的基础设施上运行GEM on-prem，这些基础设施不具备与用于Grafana Cloud的基础设施相同的所有功能。
例如，Grafana Cloud有一个自定义授权层来支持计费和将Mimir作为SaaS产品运行的其他方面。通过使用GEM，该客户的500M主动系列测试必须使用GEM内置的身份验证。随着测试规模的扩大，我们将GEM的身份验证推向了极限，并在GEM缓存与身份验证相关的错误的方式中发现了一个错误。一旦确定，我们就能够开发一个修复程序，并在第二天推出一个新的GEM映像。
最后，对于该客户，我们与Grafana k6云工程团队密切合作，对Grafana k6远程写包进行了显著的性能改进。这最终节省了大量与基础设施相关的成本，因为测试的最终版本只能够在3个底层AWS EC2实例上运行，而不需要我们最初根据以前的测试估计的12个实例。
配置客户的Mimir测试集群
测试集群(如下所示)是通过将客户基础设施上的GEM配置与我们的内部测试集群相匹配来配置的。我们允许流量从Grafana k6 Cloud ip流出，以方便负载测试。最后，我们还将指标和日志发送到Grafana Cloud堆栈，这被证明是非常有价值的。如果没有GEM的可见性和有价值的见解，我们就无法成功地在客户的基础设施上进行测试，而GEM是我们通过将度量标准和日志发送到Grafana Cloud而获得的。
第二次负载测试:300M活动系列，每分钟2000个查询
下一个试金石是达到300M主动系列和2000 qpm。
为了实现这一目标，我们首先将客户端的负载测试扩大到150M有源系列，每小时1500个qpm。此时，我们在GEM缓存身份验证错误的方式中发现了一个错误(在上面的Grafana Cloud vs. GEM框中引用)。我们还增加了摄取器内存、摄取器、存储网关和压缩磁盘。
在此之前的每个负载测试阶段，我们都将客户的集群扩大到足以处理相应测试的摄取容量。然而，现在500M活动系列已经触手可及，我们决定在运行300M活动系列测试之前，先对500M活动系列的集群进行扩展。这样就有了100多个摄取器、分发器和查询器组件，以及30个压缩器、50个存储网关和20个查询前端。由于这种快速扩展，我们遇到了运行摄取器和压缩器所需的EBS卷的AWS配额限制。当这些问题在AWS支持下得到解决时，这阻碍了几天的扩展。
我们还增加了压缩磁盘空间，并启用了Grafana Mimir的压缩分片split-and-merge压实机,负责将多个TSDB块压缩成一个更大的块的组件。属性直接支持将伸缩性扩展到此点及以上分割合并压缩算法．由于新算法令人难以置信的性能，我们几乎忘记了压实器，只是在每次测试中检查它是否工作。
第三个负载测试:500M活动系列，每分钟10,000个查询
当在客户端将负载测试扩大到500M活动系列和10,000 qpm时，我们最初遇到了一个奇怪的问题:少量查询持续失败，每2小时我们就会看到错误率的大幅上升。
在上面的截图中，左边图表中的红色部分显示了每两小时出现一次的失败查询峰值。您可能还注意到错误率的峰值与p99查询延迟的峰值完全一致。事实证明，这是由摄取器上的TSDB头部压实引发的。这是一个每2小时发生一次的过程，目的是从当前内存中的样本中切割一个新的TSDB块用于长期存储。在此期间，查询延迟略有增加是正常的，特别是对于需要来自摄取器的最近数据的查询。
此时，有必要更详细地讨论正在执行的读取测试。如前所述，我们每分钟运行10,000个查询。每次调度执行查询时，我们的k6 Cloud测试随机选择几个参数来决定实际使用的是什么查询。这些参数是根据客户对GEM的预期使用情况与他们商定的。
每个参数都有几个选项，每个选项都有一个相关的被选择的概率。例如，每个查询都有1%的几率运行一个返回5M系列的标签选择器。其余99%的查询使用返回1K系列的标签选择器运行。为特定的PromQL表达式定义了类似的参数，以计算查询应该是即时查询还是范围查询，以及要考虑的时间范围的长度。
所以这个测试的重要因素是:
- 有些查询的基数非常高
- 所有查询都涉及最近一分钟内的最新数据
- 特定的PromQL表达式有点随机，但用于复制实际使用
考虑到所有这些信息，我们做了一些简单的更改，并将错误率降低到可以忽略不计的水平。首先，我们仔细看了一下查询分片性能．结果表明，由于编写方式的原因，只有大约50%的查询是可分片的。例如，查询愤怒的(test_metric [m] 5日)不可分片。在高基数查询的情况下，这实际上将返回5M个不同的结果序列。这并不奇怪，执行速度很慢，因为在产生结果之前，必须将大量数据加载到单个查询器pod中。
修复方法很简单:在实践中，即使是非常高基数数据的查询通常也会在可视化之前由一些较低基数标签聚合。我们将查询重写为Sum by (label_with_50_values) (irate(test_metric[5m]))．尽管仍然在处理命名指标下的所有数据，但现在只返回50个不同的结果，而不是5M个不同的结果test_metric．GEM现在能够同时有效地将该查询分片到许多查询器pod上，这极大地改善了查询延迟。
其次，我们注意到一些查询实际上被转换为太多的分片，这在简单查询(比如基数只有1K的查询)的情况下增加了不必要的开销。为了解决这个问题，我们减少了-query-frontend.query-sharding-total-shards从72降至12。这极大地减少了摄取器处理的请求数量，而不会显著影响查询延迟。
最后，现在重新审视查询调度器行为，我们大大增加了最大查询调度器队列大小，以便在这些临时延迟高峰期间为系统提供更大的灵活性。我们计算了期望在网关超时内执行的分片查询的最大数量。计算结果是(10k qpm * 12个分片查询/查询* 2分钟超时)，得出的最大队列大小为240k。
有了所有这些更改，仪表板显示的情况就不一样了。虽然在TSDB头压缩期间延迟仍然会激增，但根本没有查询失败。相反，查询只是在查询调度器中排队，并尽快处理。
最后一点，已经有了GEM的实验特性完全消除头部压实延迟峰值。可以通过-blocks-storage.tsdb.head-chunks-write-queue-size国旗。在这次测试中，我们选择不启用它，因为我们仍在收集有关Grafana Cloud中真实性能的数据，并且我们通常避免向我们的预部署客户推荐实验功能。
最终负荷试验:快速增加样品摄取率
到目前为止，我们已经成功地展示了GEM扩展到500亿活跃系列的能力，并且没有发现会阻止扩展到更高的重大问题。客户要求我们运行最后一个测试来证明一个特定的场景:当在短时间内向GEM添加数百万个活动系列时会发生什么?
我们一起设计了以下测试场景来演示GEM处理以下场景的能力:
- 发送400M主动系列1小时
- 在1分钟内，爬升到500M主动系列
- 发送500M主动系列1小时
- 在1分钟内，降至400M主动系列
- 发送400M主动系列1小时
- 同样的10公里qpm在整个3小时内
通过对k6 Cloud测试脚本的一些更改，我们添加了在任意间隔集上递增和下降的功能。我们在周五下午早些时候开始了最后的测试，到周末我们得到了我们的结果:GEM表现完美。额外的100M活性序列被均匀地分布在摄取器中，一旦数据停止到达，就会在下一次头部压缩时清理干净。
最终资源分配
最后，我们在整个集群中确定了以下规模:
结论
重要的是要注意，这是作为GEM架构的压力测试运行的，在这里描述的配置和推荐的生产环境之间有一些显著的差异:
- 该测试完全在单个GEM租户中运行。我们建议将您的使用分配给多个租户。理想情况下，租户不大于~10M的活动系列。
- 在多租户环境中，我们建议启用洗牌分片．这可以防止一个租户由于错误配置、恶意行为等导致其他租户停机。
- 我们建议启用zone-aware复制．这样可以通过Grafana Rollout Operator．它还可以防止可用区丢失导致GEM停机。
最后，我们能够证明，Grafana Enterprise Metrics可以帮助客户将他们的指标扩展到500M活动系列甚至更多，同时提供一个on-prem解决方案，使您能够在现有的基础设施中工作并拥有您的数据。要了解更多关于Grafana企业度量的信息，请求演示或更多信息来自我们的团队。
如果没有Grafana k6，就不可能理解Grafana Mimir和Grafana Enterprise Metrics的功能，Grafana k6是由斯德哥尔摩科技初创公司k6创建的现代开源负载测试工具bob电竞频道2021年收购Grafana Labs．要了解如何在组织中部署Grafana k6进行负载测试，请参阅联系我们的Grafana k6团队．
