在COVID-19大流行期间，Cortex如何帮助REWE digital确保稳定性，同时扩展杂货配送服务

REWE数字为德国最大的食品连锁企业之一REWE建立了推动电子商务、应用程序和食品取送服务的技术。与食品供应链中的其他公司一样，REWE在2019冠状病毒病大流行期间看到了需求激增。由于去年采用了Cortex，监控团队能够在不断增长的规模下确保稳定性。

REWE数字子公司成立于2014年，旨在推进母公司的数字转型，因此“我们拥有相当现代的技术堆栈，”云平台工程师Martin Schneppenheim说。很多平台都是使用GKE在Kubernetes上运行的，而有些仍然使用Nomad在prem上运行。不过，该组织采用的Spotify部落模式也带来了一些挑战。REWE digital有四个部落——ECOM、FULFILLMENT、CONTENT和PLATFORM——虽然这些部落大多采用相同的技术，但Schneppenheim说:“每个平台团队都有自己的解决方案，比如Kafka、Prometheus和Grafana。”

此外，在过去的6年里，公司的员工从30人增长到约600人。

随着这种快速增长，他们在2018年底意识到，他们需要一个新的基础设施解决方案。当他们在普罗米修斯号上遇到一些内存不足的问题时，转折点出现了，他说，“我们不知道为什么。”

每个部落都有自己的Prometheus HA配对，供部落中的所有团队使用。其中一个部落使用了一对Prometheus对，每个实例需要30- 60g的RAM。Schneppenheim说:“我们仍然看到了一些随机的内存不足事件，我们相信这是因为一些查询加载了太多的样本。”“我们有几个平台团队在做基本相同的事情，我们希望在整个组织范围内解决这些问题。”

使用我们新的SaaS方法，对[新集群]进行监视就像添加一个Prometheus对(它将度量发送到我们的Cortex集群)和在我们的Grafana组织中添加这个新租户一样简单。

- Martin Schneppenheim, REWE digital云平台工程师

搜索可伸缩的监视解决方案

解决方案需要支持Prometheus展示格式，因为所有REWE的微服务都有一个Prometheus端点。团队希望对项目的持久性有信心。在考虑了M3, Victoria Metrics和灭霸之后，REWE数字团队决定选择Cortex。他说:“《Cortex》刚刚作为CNCF项目发布，有几个来自不同公司的开发者。“这对我们来说是另一个加分点。”

他补充道，主要的卖点是Cortex的多租户支持，这也涉及到Cortex内置的不同保护机制，以限制租户的使用。这意味着单个租户不能影响其他租户的整体性能。“每个平台团队都在为他们的部落提供普罗米修斯，”Schneppenheim说，“我们希望转向类似于软件即服务的方法，只有一个团队提供Cortex，它可以被公司内的所有团队使用。”

实现

实施从大数据部门开始，这个部门当时是公司最小的部门。(后来它与其他部落合并了)“我们已经设置了普罗米修斯，我们只是将数据源从普罗米修斯切换到Cortex，”Schneppenheim说。“一开始我们只是在一个仪表板上切换数据源，后来我们切换了整个部落的数据源，所以所有仪表板默认使用Cortex数据源，而Prometheus部署基本上就像远程编写Prometheus。我们总是有机会切换回Prometheus实例，以防出现任何失败，所以没有太大的风险。”

事实上，事情进展得很顺利，几个月后，ECOM部落开始为Cortex编写指标。同时，平台部落决定创建一个Grafana实例，并使用组织来提供多租户。在第二次迁移之后，部落的团队能够将仪表板迁移到新的Grafana实例，然后开始对数据进行查询。到今年年底，所有的部落都将迁移到Cortex和Grafana实例。

Schneppenheim表示，REWE digital在“非常早期的阶段”就采用了Cortex。起初，“有时我们不得不阅读代码，因为几乎没有文档，但我们仍然相信我们做出了正确的决定，因为我们在调试一些问题(通常是错误配置)方面得到了(来自社区的)大量支持。”

他指出，在过去的一年里，配置变得更简单了，在1.0版本中设置了默认值，并提供了更多的文档:“事情肯定变得更好了。”

OOM没有那么多的杀戮，即使有，我们在Grafana也看不到。这对我们来说很重要，我们的开发人员有一个平稳的体验。

- Martin Schneppenheim, REWE digital云平台工程师

结果

事实证明，在COVID-19大流行期间，Cortex的水平扩展至关重要，当时REWE的食品杂货和食品配送服务面临着极高的需求。“我们的首要目标是确保稳定性，所以我们必须扩大规模，我们部署了更多的集装箱，”他说。“一方面，这意味着我们拥有比以前更多的参数，另一方面，我相信我们的开发者会更密切地关注我们的仪表盘，所以我们也有了更多的查询。”

Schneppenheim说，在过去的两个月里，读写显著增加，平台能够处理增加的负载。另外，“部署另一组查询器非常容易，”他说。

除此之外，施本海姆说:“我们公司最大的优势是，我们现在有一个团队，可以提供一种内部服务。”虽然部落的运营团队仍然需要管理他们自己的普罗米修斯服务器，但他们拥有一个更加稳定和可扩展的系统。挑战是查询时不可预测的资源使用情况，一些查询可能加载太多的数据，导致Prometheus进入OOM，但有了Cortex处理所有查询，这就不再是问题了。虽然Schneppenheim的团队仍然只有两个人(他们招聘!)，他补充道:“我们可以花更多时间学习如何运行它，成为公司内部的专家，研究《Cortex》及其相关内容，比如我们每两周左右就会看到的高基数度量系列。我们现在是所有监控的联络人。”

还有其他的技术优势:“我们的普罗米修斯和格拉夫纳已经没有缺口了，”他说。“如果Prometheus实例失败或需要重新启动，我们会自动切换到具有HA跟踪器的副本，这是一件很棒的事情。”

由于Cortex能够缓存查询结果，REWE数字团队发现仪表板变得“超级快，因为查询可能已经被缓存了，它只需要加载新的30秒左右，自上次刷新以来，”Schneppenheim说。“预装仪表盘的加载或刷新非常非常快。”

另外，《Cortex》的留存率更高。“我们现在有60天的留存期;我们过去只有七天，”他说。

随着基础设施的发展，好处也很明显。REWE digital还增加了几个小型的Kubernetes集群，“很明显，这些集群与我们最大的集群具有相同的监控/警报需求，”他说。在此之前，团队必须部署Prometheus和一个单独的Grafana实例(以及NGINX和DNS设置)。

他说:“使用我们新的SaaS方法，对这些进行监控就像添加一个Prometheus对一样简单，它将指标发送到我们的Cortex集群，并在我们的Grafana组织中添加这个新租户。”

有了Cortex，他们还能够解决两个用例(由于技术原因而被拆分的Kubernetes集群和云迁移)，这两个用例需要来自两个不同集群的指标才能对同一个租户可用。“开发团队需要跨这两个集群聚合指标，这很容易做到，因为我们只是在相同的租户ID下摄入它们，”Schneppenheim说。

那些内存不足的问题呢?他说:“我们在不断发展，不仅是在查询方面，而且在我们加入团队和部落的过程中，也在吸收参数方面。”“但我们已经对它进行了很好的调整，并没有那么多的OOM死亡，即使有，我们也没有在Grafana看到他们。这对我们来说很重要，我们的开发人员有一个平稳的体验。(大多数部落使用Grafana警报;一个使用Prometheus Alertmanager。)

展望未来

REWE digital目前的主要关注点是将其他团队带到Cortex。但展望未来，科考队正在探索Grafana代理没有使用Prometheus Alertmanager的部落。“他们不需要普罗米修斯的提醒;他们只使用普罗米修斯来刮刮目标，并将样本发送到我们的Cortex，”他说，“所以这肯定是有趣的，特别是考虑到性能的提高。它的唯一目的是将指标作为我们的远程写入后端发送给Cortex，所以未来可能会有其他优势，如更紧密的监控。”

开发中的Cortex Blocks存储引擎对团队来说也很有趣，因为它可以解决小BigTable集群的瓶颈问题。他说:“我们只运行了三个BigTable节点，BigTable读取延迟有时在一秒内达到峰值，这也是直方图中的上限。”“如果用户打开Grafana仪表板，在很长一段时间内查询多个面板，就会出现这种情况。我们希望从BigTable切换到新的存储引擎可以解决这个问题，因为对象存储(GCS)是按需扩展的。”

REWE数字团队已经建立并开放了自己的源代码皮质网关，这在项目路线图上。“这可能是我们做出贡献的机会，”施本海姆说。

Schneppenheim也希望REWE digital在Cortex上所取得的积极成果能够进一步在整个REWE集团组织中得到采用。“我们只是REWE集团中的一家小公司，”他说，但“我们可能会把它作为内部软件作为服务提供给集团的其他部门。他们可以信任我们的解决方案。”

故事最初发表于:https://cortexmetrics.io/