AdformAdform 如何通过 Grafana 将 1,300 种不同的数据源整合到一个中心可观测性系统
科技界充满了起源故事，都根植于不起眼的起点。从惠普和亚马逊（车库）到 Facebook（宿舍），灵感和创新无处不在。
2002 年，三个人挤在哥本哈根的一个地下室里，决心改变数字广告买家和卖家的方式：我们如何才能让这个过程变得更好？他们的答案是 Adform，一个广告技术平台，目前为全球 25,000 名客户提供支持。
Adform 面向消费者的可用性和各种赞誉——比如入选 Gartner 魔力象限和获得红点设计奖的用户体验奖——背后是其开发和运营团队为持续创新付出的巨大幕后努力。正如 Adform 营销高级副总裁 Louis e Kloster 所说：“构建一个先进的广告技术平台确实是一个复杂的过程。”
这促使 Adform 的 DevOps 团队重新评估他们的可观测性解决方案，并纠结于当年创建公司时的同一个问题：我们如何才能让这个过程变得更好？
经过多年在初创模式下运营，开发人员根据个人偏好和过往经验随意选择工具，现在是时候后退一步，将分散无序的可观测性策略重组为集中、连贯的方法。“我们希望在自己信任的产品上构建监控即服务，”Adform 的 DevOps 技术主管 Linas Daneliukas 说。
他们相信 Grafana 可以帮助他们实现这一目标。通过充分利用 Grafana 开放且可组合的平台并将其与 Prometheus 结合使用，Adform 的开发人员能够在保持他们所使用工具灵活性的同时，允许 DevOps 团队在组织内部提供集中式的监控体验。如今，Adform 在 Grafana 中运行着 1,400 多个仪表盘，连接了 1,300 多个数据源，并在 86 个组织中拥有近 200 名活跃用户。
“作为运营商，我们可以控制实例本身，但团队可以控制他们自己的小空间，并可以根据需要进行扩展，”Daneliukas 说。“开发人员获得了他们所需的控制权，同时仍有人可以管理整个实例。因此，这对我们和他们来说是双赢的。”
Adform 的新可观测性口号：一个中心系统
DevOps 服务交付经理 Tomas Dabašinskas 表示，在 Adform 的早期，开发人员“使用的是他们了解的或认为好的工具”。
但随着公司成熟和更多团队的组建，这种脱节的生态系统在维护和改进方面导致了入职困难、报告挑战和基础设施效率低下。任何优化现有解决方案的梦想都随着他们面临持续故障排除和临时问题解决的现实而破灭。“我们甚至无法保持所有东西都是最新的，”Daneliukas 说。
大约在 2018 年，DevOps 团队改变了他们的方法。“作为公司，我们决定转向集中式服务，”Dabašinskas 补充道。
第一个重点是创建监控即服务解决方案。最初，他们尝试使用现有的软件，例如 Graphite、Nagios、Zadig、Graylog、ELK Stack 和多个 Prometheus 实例。
我们尝试进行整合和工具筛选，以便进一步发展。然而，我们认为自己是一家现代公司，并希望了解最佳实践和新兴事物。因此，我们决定放弃所有与可观测性相关的现有方案，并创建一个由 Grafana 提供支持的统一中心系统。
Linas Daneliukas，Adform Devops 技术主管
然而，迁移并非没有挑战。改变总是困难的，特别是当它涉及人们修改他们的流程时。但 Grafana 管理大量数据源的能力使 Adform 得以通过将 Grafana 作为其技术栈的核心部分，缓慢地将其团队过渡到使用 Prometheus 来获取指标。“我们知道开发人员立即迁移到 Prometheus 很困难，”Dabašinskas 说。“但 Grafana 支持从 Graphite 到 Prometheus 及其他选项，这为这段过渡期 [开发人员仍可以使用他们偏好的工具] 提供了可能。”
这一切努力都是值得的。Grafana 不仅整合了数据，还拉近了团队之间的距离——即使他们对可观测性工具有不同的看法。通过 Grafana 的组织功能，DevOps 团队在 Adform 的 Grafana 实例中为 Adform 的每个组织提供了独立的监控体验，与管理多个实例相比，这是一种更具成本效益且更简化的方式。用户拥有查看所有其他组织数据的权限，同时保留对自己组织数据的管理权限。
“这是一种很好的方式，既能分隔我们的团队，又能让他们保持可见性，以便他们可以找到彼此的仪表盘和可视化图表，”Daneliukas 说。“这也不会在未来造成障碍。我们不想创建一个未来必须弃用的解决方案。我们对工具的要求设置得很高，这样我们就不会在五到十年后陷入困境。”
Grafana 的开源根基和日益壮大的全球社区也符合 Adform 的标准。如果开发人员遇到问题，Grafana 的在线社区已成为同步如何优化其技术栈的首要资源。“所有问题都可以通过社区论坛解决，”Daneliukas 说。在活跃社区的帮助下，“我们从未遇到过卡住的问题。一切都很简单。使用 Grafana，我们不会遇到障碍。”
相反，他们有一个新功能和新特性的路线图，总是值得期待。
选择 Grafana 对我们来说是显而易见的，因为我们看到了这个工具的未来前景和其背后的社区。它正在不断发展。这是最简单也是最好的路径。
Linas Daneliukas，Adform Devops 技术主管
Grafana 带来的收获清单
拥有一个跨环境的可视化工具，同时仍然维护多个数据源，是 Adform DevOps 团队将开发人员从犹豫的参与者转变为 Grafana 高级用户的关键。
“最大的影响是人们可以找到他们想要的东西，”Daneliukas 说。“当我们使用不同的工具时，如果触发了警报，很难知道该联系谁，在哪里找到仪表盘。然后你需要该监控系统的凭据，而你并不总是有。你基本上对正在发生的大多数事情都是盲目的。现在，有了中心监控系统，当你在公司内部任何地方看到警报时，你可以点击警报并获得访问权限。你可以转到他们的组织并查看相应的仪表盘。数据就在你眼前。”
这种透明性——得益于 Grafana 对 Prometheus Alertmanager 的内置支持——促进了 Adform 团队之间更好的沟通和跨部门协作。“现在一切都变得井井有条，”Daneliukas 继续说道。“你可以确信，当你和开发团队谈论监控时，你们使用的是同一种语言。你知道 Grafana 是我们可视化指标的地方，而 Prometheus 是我们用来收集指标的工具。你不会花一个小时与某人讨论如何解决问题，结果却发现他们使用的是自己的监控解决方案，这就是为什么一切似乎都对不上号。”
整合也意味着运营效率的提升。最初，开发团队平均每月每团队花费 1-3 名全职员工（FTEs）用于基础设施维护和监控。有 25 个团队，这意味着每月总共有 75 名全职员工用于维护，而非创新。现在，这个数字已降至每团队 1 名全职员工。团队还提供更全面的维护，确保使用最新版本的软件。
在办公室里走动，你会看到到处都是显示 Grafana 仪表盘的电视屏幕。人们不断地参考它们。最终，使用 Grafana，故障排除的便捷性呈指数级提高，同时我们将监控技术栈的 CPU 使用率降低了 50%。
Linas Daneliukas，Adform Devops 技术主管
Adform 迈向未来
Dabašinskas 表示，随着持续扩展，Adform 期待探索使用 Grafana 进行改进的其他方式，他提到了 Grafana Alerting。“我们肯定会对其进行测试，因为对我们来说，它将兼顾两者优点：既能以代码形式管理 Prometheus 格式的告警，又能通过 Grafana UI 以用户友好的方式查看和管理所有告警，”他说。
在团队持续努力“让 Adform 的可观测性变得非常简单”的过程中，他们最近在一次公司范围的黑客马拉松期间成功进行了 Grafana Loki 的概念验证（PoC），团队使用 Loki 收集了 3,000 多台虚拟机的所有日志。“我们想一夜之间从零开始实现所有功能，结果成功了！”Daneliukas 说。“我们有一个单独的 Loki 实例，正在收集每台虚拟机的操作系统级日志。你只需打开仪表盘，选择你的机器，即可获取日志。这真是令人惊叹。现在我们已将其纳入实施路线图。”
Adform 的 DevOps 团队也在考虑进行 Grafana Mimir 的概念验证（PoC），以在其不断扩展的 Grafana 技术栈中继续构建易于使用的可观测性体验。
我们喜欢无缝、统一的体验。我们的开发人员也希望如此。我们从未决定将一切都构建在 Grafana 之上。它只是自然而然地发生了。我们并非偏爱 Grafana，但它一次又一次地出现在我们的首选列表中。
Linas Daneliukas，Adform Devops 技术主管
最初是作为提供监控即服务的努力，之后自然而然地演变为包含日志即服务，然后又加入了追踪。很快，Daneliukas 和 Dabašinskas 就能实现最终愿景：提供可观测性即服务。
随着业务和技术的不断潮起潮落，Daneliukas 和 Dabašinskas 正在思考如何赋能 Adform 的团队来实现公司的雄心。“我们希望让开发团队的工作尽可能轻松，这样他们就能专注于日常成功构建面向客户的应用，”Dabašinskas 说。“他们需要合适的工具。通过我们提供监控和日志即服务，他们就能专注于重要的事情。”
