这一切都始于皮质的水平可伸缩集群版本普罗米修斯它是三年前创建的，现在是CNCF沙盒项目。
Cortex使用PromQL引擎和相同的块格式普罗米修斯-完全相同的代码库。“我们真正做的是把它以不同的方式粘合在一起，使用一堆分布式系统、算法和一致的哈希来实现它水平扩展Grabob电竞频道fana实验室的产品副总裁汤姆·威尔基在最近的讨论．“它的问题陈述和灭霸非常相似，但我们用一种完全不同的方式解决它。”
Wilkie说:“Cortex为你提供了(所有Prometheus服务器的)全局视图。Cortex确保您的图表中没有空白，同时还提供了多租户的长期存储。
在普罗米修斯的世界里，经验法则是单个查询的基数不应该太大。在单个Prometheus服务器和单个查询中，不应该有超过100,000个不同的时间序列，即使在使用大型聚合时也是如此。
Cortex允许你将所有的指标从多个Prometheus服务器发送到一个Cortex集群中，这突然让10万个时间序列的规则变得更加难以坚持。“在Grbob电竞频道afana实验室，我们有大约15个Kubernetes集群分布在世界各地。所以我们至少有15个普罗米修斯服务器，”威尔基说。在这样的规模下，“在一个查询中编写一个涉及100万个序列和几百gb数据的查询是非常容易的，而且您希望该查询能够快速返回。”
在他的演讲中，Wilkie展示了Grafana实验室团队是如何解决这个问题的，现在可bob电竞频道以帮助执行非常快的PromQL查询。
介绍皮质查询器
使用与Prometheus相同的PromQL引擎，Cortex从“查询器”开始。它是一个无状态的查询微服务，这意味着“你想运行多少就可以运行多少，”Wilkie说。
大约一年前，当团队正在开发Cortex时，用户模式很简单:如果有人注意到查询很慢，他们就倾向于运行更多的查询。然而，多跑步的问题在于，它实际上并没有帮助。
“当查询速度较慢时，很少会出现高并发查询负载。大多数人加载一个仪表盘，如果你是一个真正的狂人，它每五秒钟就会重新加载它的图表，你可能会看到四到五个面板，”Wilkie说。“你从仪表板上看到一个QPS。这不是一个很高的查询负载。我不需要多个并行查询器来提高速度。增加更多的查询并不能让它变得更快。”
还有更大的问题要面对。“当你发送一个大查询，要查看30多天的数据时，它只会命中一个查询器。更糟糕的是，它实际上会在查询器中命中单个goroutine。它将在那里加载过程中的所有数据并将结果发送给你，”Wilkie说。“实际上，你查询的时间越长，它就会越慢。”
该团队考虑的另一个因素是，用户会受到他们所运行的芯片速度的限制。“芯片变得越来越慢。它们并没有变得更快，”威尔基指出。“他们正在获得更多的内核，所以我们可以并行运行更多的内核，但这并没有帮助，因为我没有高并发负载。我的并发负载很低，但人们会向我发送更大的查询，持续30天或更长时间。”
Grafana实验室团队做的第一bob电竞频道件事就是添加缓存，特别是memcached。所实现的高Veeramachneni他是Grafana实验室的Prometheus维护者之一，目标是确保索引缓存尽bob电竞频道可能有效，但也不会缓存过度，偶尔返回陈旧的结果。“这真的很棘手，”威尔基说。
幸运的是，块缓存是不可变的。“一旦我们写了它们，我们就可以永远地缓存它们。他们永远不会改变，”威尔基说。“更好的是，他们实际上是内容解决。所以如果你有相同的块，它们就会自我重复。”
但所有这些并没有真正解决问题，威尔基说。因此，该团队开始构建一个查询前端，灵感来自康卡斯特编写的代码骗子．
Wilkie解释说:“我们开始建造自己的机器人，因为我们想做一些稍微不同的事情。“实际上，我们最初只是着眼于植入骗子到皮层。我发现Trickster最大的问题之一——这不是挖苦——是很难嵌入，实际上他们现在正在试图解决这个问题。”
“我们不喜欢进程内缓存，因为我们喜欢经常升级我们的软件。我们不喜欢在磁盘上持久缓存，因为磁盘很慢。ssd也是如此，”Wilkie说。“我们沉迷于memcache，因为它很快，而且它与我们的进程是分开的。我们的memcached可以持续几天，几周，几个月，然后我们就不得不升级它们了。所以我们在所有地方都添加了缓存。”
高速缓存如何影响大脑皮层
现在深入了解一下Cortex的查询前端是如何与缓存一起工作的。
上面，我们正在寻找一个传送作业和传送作业的请求率。
首先要做的是步进对齐。bob电竞频道Grafana Labs现在默认将开始和结束时间与步骤对齐。Wilkie说:“我们这样做的原因是，如果你现在要求一个以15秒为基准的查询器，普罗米修斯会从现在开始返回15秒，执行一个即时查询，再返回15秒，执行一个即时查询，以此类推。”“如果你现在问一个问题，四五秒后，它会倒退15秒，你可以看到它们没有对齐。所以你会得到一个微妙而略微不同的结果。”
对齐很重要，因为它增加了结果的可缓存性。Wilkie说:“如果没有这个，我们就无法准确地缓存结果。”“这就是为什么在早期版本的《Grafana》中，如果你混合刷新，线条会跳跃一些。”
查询前端的下一步是按天划分查询。“关键是这些查询现在是独立执行的，所以它们在多个核心或多个不同的Go例程上执行，”Wilkie说。“现在我们可以用多核处理器进行扩展。所以如果你问我一个30天的查询，我就会发出30个一天的查询，然后并行执行。”
接下来，用户可以仔细查看结果缓存。“你会发现你之前就要求过这一天，所以你不需要问普罗米修斯。你没有在缓存中看到某一天，所以它可能被驱逐了，或者缓存忘记了它。一个单独的一天实际上可能被分解成多个子查询，”Wilkie说。
“在这里你必须非常小心。你必须考虑包容和排他的界限。”Wilkie补充道。“Cortex是一个多租户系统，所以我们有效地运行一个单一的大型集群，在一个集群或分区数据上有数百个用户。”
为此，“我们真正想避免的一件事是，一个用户提出一个非常大的查询，并杀死所有其他用户。所以这些结果实际上是排队的。”Wilkie说。“然后还有一个调度程序，这非常简单。它只是随机选择一个队列，所以至少我们在用户之间有一个真正基本的服务质量。如果一个用户来刷新，在查询中执行100个QPS，每个人都会均匀变慢，执行100个QPS的用户会饿死自己。”
但请注意，上面提到的功能都不是Cortex特有的。这只是一个PromQL缓存库进程，它在前面实现了PromQL API，并在底部与实现PromQL API的东西对话。我们可以做这个凡事都要努力威尔基指出。“我们可以让灭霸得逞。我们可以让普罗米修斯成功。我们可以让它适用于任何实现PromQL API的东西，这也是我喜欢Prometheus项目的原因之一:越来越多的东西似乎实现了我们的API和查询语言，这太酷了。”
结果
那么这种方法的效果如何呢?
如果我们在一个公开的Prometheus服务器上运行一个小型的，7天的查询，它可能需要大约4秒。
如果我们把Cortex查询前端放在它前面，一个空缓存(因此只是平行查询)下降到~1s。
当我们重新运行查询，使其命中缓存的结果时，这可能会下降到~100ms。
自己试试吧，请点击查看演示Wilkie在下面展示了所有这些组件如何组合在一起，极大地改善了你的PromQL查询:
《皮质》的下一个目标是什么
基于原文设计文档对于《Cortex》，以下是项目未来的一些重要想法。
Wilkie解释说:“按时间并行查询非常酷，可以使查询更快，但我真正想做的是按序列并行查询。”“所以你可以考虑一个维度系列和另一个维度。我想把这些日子分成100个不同的片段，每个片段都是整个系列的1/100。”
Ganesh Vernekar(Grafana Labs Cortebob电竞频道x团队的另一名开发人员)也使Cortex能够自动识别表达式中的子查询，并自动将它们替换为相关的报告规则。这个功能还没有合并，但很快就会合并。
此外，Wilkie说:“当我们开发Cortex并破坏它时，有时我们不得不回头问我们的Prometheus开发人员为什么我们破坏Cortex，所以如果这个库可以处理HA对中的缺口，那么它将非常有用。”
最后，团队想知道:他们想要看到什么?这有用吗?这容易部署吗?这会让你的工作变得更快吗?可靠吗?你发现任何漏洞了吗?查看更多关于GitHub上的Cortex项目．
