The Trade Desk 使用 Grafana Cloud 迁移到现代监控系统

当 Patrick O’Brien 面试 The Trade Desk™ 的站点可靠性工程师（Site Reliability Engineer）一职时，很明显，将公司的监控系统提升到新的水平是首要任务。

“我面试时有一部分是关于 The Trade Desk 之前的监控系统及其如何扩展的，”O’Brien 说道，他两年前加入了 The Trade Desk。“我当时就觉得这会是我早期的一项任务。”

在 O’Brien 入职前六个月加入工程部门并担任基础设施和 SRE 总监的 Carl Johnson 补充说：“我立刻意识到这是我们基础设施中需要额外努力解决的领域。招聘 Patrick 的核心目标之一就是改进这个领域。”

我们不仅在 Grafana 中追踪传统的技术和工程指标。我们还提供了各种业务团队所需的运营数据，以便了解业务的日常健康状况。
Carl Johnson，The Trade Desk 基础设施和 SRE 总监

这有充分的理由。The Trade Desk 是一家软件即服务（SaaS）公司，作为需求方平台运行，代表广告商及其在互联网上所有形式的数字媒体（传统展示广告、移动广告、音频广告、联网电视广告）上投放广告活动的能力。自 2009 年成立以来，The Trade Desk 已成长为一家上市公司，拥有超过 1,100 名员工，市值达 88.9 亿美元。

Johnson 表示，为了保持其巨大的成功，“我们拥有一个在全球范围内运行的基础设施，包括物理数据中心和云端。我们的运行规模非常大，处理的请求率通常以每秒百万计。”

O’Brien 说，以前 The Trade Desk “为我们监控系统的存储层托管一切。我们的所有主机都直接指向各种 EC2 实例，我们对磁盘存储层有很高的要求。”

Johnson 补充说：“The Trade Desk 以前使用的自研、自行管理和托管的存储系统非常耗费人力且难以扩展。单个节点经常会耗尽存储空间，或者由于该技术的单线程特性而过载。公司中的开发人员和人员对查询完成或指标缺失的不可靠性感到非常沮丧和恼火。”

“事情会经常出故障，所以我们旧的系统需要大量的照料，”O’Brien 说。他的目标是通过让 The Trade Desk 的监控“更简单、更可靠、更快、更便宜”来缓解这种情况。

开启数据洪流

O’Brien 花了一些时间研究开源替代方案，也考察了其他 SaaS 提供商来托管后端。但 Grafana Labs 在整个过程中很早就引起了他的注意。

The Trade Desk 已经在使用 Grafana 进行数据可视化，因为“我们监控所需的是灵活的可视化，不仅对 The Trade Desk 的所有工程师开放，而且对我们整个公司开放，”Johnson 说。“我们不仅在 Grafana 中追踪传统的技术和工程指标。我们还提供了各种业务团队所需的运营数据，以便了解业务的日常健康状况。”

Johnson 说：“Grafana 让我们能够灵活地管理这些可视化——无论是单个人员处理技术项目的范围，还是整个公司习惯定期查看的 Grafana 仪表盘。”

O’Brien 从会议圈了解了 Grafana Labs，并且知道它通过 Grafana Cloud（一个完全托管的 SaaS 指标平台）提供后端存储。

“我有点担心他们是否能够处理我们发送和查询的指标量，”O’Brien 承认，他对自己的犹豫非常坦诚。

O’Brien 说，作为试运行，Grafana Labs 团队同意“让我们打开数据洪流”一周。“这对于他们允许我们进行的 POC 来说非常有吸引力。”

Grafana Labs 团队协助设置了一个环境，使得 The Trade Desk 可以将最初的指标流分叉到两个不同的流中——一个在内部，另一个流向 Grafana Cloud。O’Brien 补充说：“我们在一些代码库中发现了一些需要调整的地方，Grafana Labs 的每个人都非常乐意提供帮助并提交更改，以帮助我们继续进行 POC。”

Grafana Cloud 的好处几乎是即时显现的。O’Brien 说：“查询时间立刻缩短了，许多开发人员似乎都注意到了这一点。此外，我们的可靠性也提高了很多。”

O’Brien 说，如今，“我们的存储节点数量为零，这曾是该技术栈中最昂贵的部分。现在我们只有三个节点，所有数据都回馈给 Grafana Labs。”

这次迁移不仅为公司节省了资金，还将工程部门从故障排除的麻烦中解脱出来。Johnson 说：“一旦我们使用了托管平台，指标使用方面的沮丧情绪几乎在一夜之间就得到了改善。我们知道它成功的原因是内部的那些抱怨和沮丧停止了。”

令他们惊讶的是，赞扬声开始传来。O’Brien 说：“最初在 The Trade Desk 设置我们监控技术栈的人给我发消息，只是为了告诉我现在的速度快了多少，以及他对它有多满意。”

Johnson 补充说：“他花了很多时间管理那个系统。如果你把我们继续沿着那条路走下去所节省的总时间加起来，我认为大部分投资回报率实际上来自于时间和劳动力的节省。我们都可以说，曾经耗费大量时间的事情现在已经完全从我们的视野中消失了。”

查询时间立刻缩短了，许多开发人员似乎都注意到了这一点。此外，我们的可靠性也提高了很多。
Patrick O’Brien，The Trade Desk 站点可靠性工程师 (SRE)

The Trade Desk 拥有全新的技术栈

现在工程师们不必再专注于故障排除，他们可以将精力集中在构建 The Trade Desk 的监控平台上了。

Johnson 解释说：“通过释放我们的项目负载和人员配置能力，我们可以着手提升标准，并积极主动地实施下一代监控、指标和警报系统，而不仅仅是维护多年来一直沿用并只是具有惯性的系统。”

有了新释放的资源，O’Brien 在去年重新组织了团队，专注于将公司的技术栈精简成一个更现代的系统。O’Brien 说：“2018 年是 Prometheus 之年。”

O’Brien 说：“我们的目标之一是能够更轻松地启动指标和警报。很高兴在 Prometheus 中，仪表盘的查询语言本质上就是编写警报的查询语言。将大量上下文和有用的信息嵌入到 Prometheus 警报中也非常容易，这对我们来说意义重大，因为在我们旧的系统中，我们必须想出一些巧妙的解决方案来丰富警报本身。”

大约在 The Trade Desk 决定采用 Prometheus 的时候，O’Brien 在阿姆斯特丹的 GrafanaCon 上会见了 Grafana Labs 团队，并讨论了“我们未来的一个大问号：我们如何处理指标的长期存储？”

Grafana Labs 首席执行官 Raj Dutt 告诉 O’Brien，Grafana Cloud 很快将能够支持 Prometheus 指标的后端存储。

巧合的是，The Trade Desk 项目与 Grafana Cloud 在 2018 年推出的原生 Prometheus 集成同时进行，因此两家公司再次合作——但这次合作“双方都遇到了障碍”，O’Brien 说。

O’Brien 说，从 Grafana Labs 的角度来看，“我们每秒发送的指标是 Cortex 后端从未见过的最多的一次。我们发送给 Grafana Labs 的数据洪流可能让产品副总裁 Tom Wilkie 少活了一年！”

从 The Trade Desk 的角度来看，他们遇到了新公司经常遇到的一个常见问题：如何围绕新的技术栈实施流程。O’Brien 说：“有相当多的学习曲线，我们必须学习如何构建我们的指标、如何编写我们的指标以及如何收集指标。”

O’Brien 说，总的来说，“The Trade Desk 和 Grafana Labs 都在并行努力，互相帮助以达到我们的期望。Grafana Labs 的同事在长期后端存储之外的许多不同方面提供了巨大的帮助。他们在 Prometheus 方面也非常有帮助，经常回答问题、讨论并帮助解决我们遇到的错误，或者对问题进行分类。”

现在，得益于 Prometheus 和 Grafana 中的模板功能，所有警报都必须包含一个指向仪表盘的链接，提供上下文，这样“如果 30 个主机触发了警报，就可以更容易地直接链接到显示这 30 个主机以及过去 24 小时历史记录的仪表盘，看看是否发生了什么异常情况，”O’Brien 解释说。“我们还开始在部署发生时进行图表展示，以便获得相关的上下文信息。”

故障排除也变得更加统一，因为 The Trade Desk 现在能够强制为每个警报链接运行手册。过去，“有时运行手册会包含一个指向 Grafana 仪表盘的链接以提供更多上下文，有时则不会，”O’Brien 说。“现在要求每个警报都必须链接运行手册，我们可以更好地规范书面警报，这有助于所有人。”