随着计算生态系统变得越来越复杂，监控和分析那些通常断开连接的移动部件变得越来越具有挑战性。

今天的数据中心已经从单一供应商生产和销售一体化产品的时代发展而来，例如 EMC、NetApp、HP 甚至 Sun 拥有您的数据中心，您选择一个供应商并坚持使用它。这些相同的供应商为您提供了所需的工具来监控、分析和排除其整个堆栈的故障。

将焦点转移到现在，现在的景象似乎截然不同。相反，您会发现由各种大型和小型供应商提供的混合产品环境。专有机器与运行软件定义软件的现成商品设备并肩工作。您一半的应用程序可能托管在虚拟机中，通过虚拟机监控程序或只是在容器中启动。现代数据中心管理员或 DevOps 专业人员如何管理这样的环境？

存在各种平台和框架提供此类功能，但它们并非完全相同。在某些情况下，这些相同的工具需要与其他工具结合使用才能产生有用的东西（例如，ELK：Elasticsearch + Logstash + Kibana）。不幸的是，当试图诊断或发现计算环境中的问题时，这种安排只会增加复杂性和挫败感。

为了结束这种程度的复杂性，一家公司在其他公司中脱颖而出：Scalyr。Scalyr 开发并提供一整套服务器监控、日志管理、可视化和分析工具，这些工具与云服务集成。我最近有幸与 Scalyr CEO Steve Newman 进行了交谈。

他的名字不像史蒂夫·乔布斯或比尔·盖茨那样家喻户晓，但您会熟悉他的工作以及他对云技术的贡献。虽然这种情况很可能随着 Scalyr 而改变，但 Steve 最出名的是他在 Writely 方面的工作，这项技术后来被 Google 收购并重新命名为 Google Docs。在我们的对话中，Steve 和我借此机会讨论了 Scalyr、其解决方案及其解决的问题。

Steve Newman，Scalyr CEO

Petros Koutoupis： 请您简单介绍一下自己。Steve Newman 是谁？

Steve Newman： 我是一名工程师，无论从培训还是背景来看都是如此，并且我的大部分职业生涯都在创业环境中度过。这是因为我喜欢创造事物。在被收购后，我在 Google 工作了很多年，虽然这段经历本身很棒，但我内心的创业热情驱使我来到了 Scalyr。

PK： 那么，现在您创立了一家名为 Scalyr 的公司。请告诉我们，Scalyr 是什么？

SN： Scalyr 是一个为负责软件开发的工程师提供的日志管理平台。我们从应用程序、服务、容器和系统收集日志，并使这些数据可用，以帮助工程团队跟踪问题并全面管理现代开发和运营的复杂性。

PK： 为什么？您的产品解决了哪些问题？

SN： 传统的日志管理工具很复杂，而且在规模上通常非常慢。这导致了一种日志管理的“守门人”方法，只有少数人获得了专业知识（并且有耐心！）来访问这些关键数据。日志成为最后的手段，阻碍了团队快速或主动解决问题的能力。

我的联合创始人 Steven Czerwinski 和我自己在 Google 首次遇到了这个问题。我们当时正在领导一个基础设施项目，支持 Google Docs、Drive、Photos 和其他相关应用程序。有很多移动部件，工程团队花费了接近一半的时间仅仅是跟踪问题。我们在 2011 年创立了 Scalyr，旨在创建我们希望在 Google 拥有的工具——一种能够让我们理解海量遥测数据并快速了解复杂系统为何行为异常的工具。

PK： Scalyr 是如何工作的？

SN： 我们是一个完全托管的 SaaS 解决方案。日志使用我们的代理或一系列 API 集成发送到我们集中托管的搜索集群。然后，工程师使用我们的 Web 应用程序（或 API）来分析、可视化和探索日志。

关键组件是后端。我们从头开始构建了后端软件堆栈，针对日志管理中出现的数据访问模式进行了优化。我们方法的一些有趣之处在于

1) 与其他日志管理解决方案不同，我们不使用索引。关键词索引针对在由缓慢演变的人类语言文本（例如网页或产品描述）组成的语料库中查找“最佳十个匹配项”进行了优化。日志管理用例非常不同，具有小文本单元（单个日志消息），不断更新，充满了记录 ID 和其他非单词，这些单词会膨胀词汇量。最重要的是，日志管理查询通常可视化完整的数据集，而不是在十个高排名结果后停止。关键词索引在那里没有太大帮助，而且它们很复杂、维护成本高，并且通常会造成数分钟的摄取延迟。

我们采用了一种更简单的方法，构建了一个简化的列式数据存储，该存储针对日志数据进行了优化。基本思想是我们只是存储日志并扫描它们，就像传统的 grep 一样。然后，我们使用许多技巧来最大限度地减少需要扫描的数据量；例如，在查询日志的特定字段时，列式数据布局意味着我们只需要扫描这些字段。

2) 我们一次全局处理一个查询。这允许每个客户使用我们的整个搜索集群，总搜索性能为每秒 1.5 太字节。它足够快（96% 的查询在不到一秒的时间内完成），查询几乎从不排队——我们在下一个查询到达之前完成每个查询。这种方法的好处在于存在规模经济：随着我们的客户群增长，性能也会提高。

3) 我们为重复查询构建了一个单独的后端，例如仪表板或警报规则中使用的查询。系统的这部分基于时间序列数据库，每个查询都有一个自定义时间序列。摄取引擎在日志消息到达时自动更新这些时间序列。这意味着我们不需要执行查询来显示仪表板或评估警报规则——相关数据已在时间序列中预先计算。在数据库术语中，我们正在根据需要自动创建物化视图。

PK： 与现有解决方案相比，是什么让 Scalyr 脱颖而出或具有竞争力？

SN： 速度、简洁性和可扩展性。

速度从一开始就是我们任务的核心。日志是一个非常有用的、详细的数据源，但是当运行一个查询需要几分钟（或更长时间）时，工程师就会避免使用它们。我们在不到一秒的时间内满足大多数查询。我们还实时摄取数据：新日志在几秒钟内即可用于查询。

简洁性与速度息息相关，最好将其衡量为从工程师脑海中的问题到屏幕上的答案的时间。如果您花费五分钟与查询语言搏斗，那么世界上最快的后端也几乎没有用处。我们依靠我们的性能，以及我们解析日志并在摄取时提取结构化数据的能力，来提供一组可视化探索工具，使工程师无需成为查询语言专家即可获得答案。这里有一个查询语言，但您可以在不了解任何信息的情况下深入研究。

最后，客户通常会因为我们的可扩展性而选择我们。我们不仅在服务器数量和数据量增加时继续良好地工作，而且随着团队的成长也如此。无论是有 3 人还是 1,000 人查看日志，Scalyr 的工作速度都一样快。这有助于团队从传统日志管理的守门人模式转变为现代组织日益采用的并发、协作工程模式。

借助 Scalyr，公司首次拥有了一个日志管理平台，该平台不会对新用户收取无情的许可费，也不会涉及漫长的启动时间或需要学习深奥的查询语言。它是为需要快速行动的团队设计的。

PK： 谁将受益于使用 Scalyr？

SN： 我们的最佳客户是那些应用程序对业务至关重要的组织。从 B2B 软件到在线零售商、约会平台和媒体公司，每个企业的竞争优势越来越在于技术堆栈以及该堆栈可以发展的速度。Scalyr 对于实现这一目标至关重要。我们的一些客户包括 NBCUniversal、OkCupid、Zalando 和 ReturnPath。

在这些组织中，主要的 Scalyr 用户通常来自工程或 DevOps 部门。但是 Scalyr 非常易于使用，我们经常看到使用范围扩展到其他角色，例如支持部门，他们可以搜索日志以跟踪特定的客户问题。我们的一些客户有多达 1000 个拥有 Scalyr 登录名的个人。通常，每周有一半的用户处于活跃状态，与传统的日志管理平台相比，这是一个巨大的参与度。

PK： Scalyr 如何轻松地集成到当前的生产环境中？

SN： 我们的使命是在客户所在的地方与他们会合，因此我们支持许多不同的模型。有些人运行自己的服务器或虚拟服务器。有些人使用 Kubernetes，而另一些人则使用无服务器。无论如何，设置首先涉及检索日志。最常见的方法是使用轻量级代理，客户可以将其安装为容器、Sidecar 或他们需要的任何东西。我们还具有 API 集成，可以直接从当今使用的各种云服务中检索日志。

一旦日志开始流入，您就可以开始了，但一个重要的进一步步骤是设置解析规则。这使我们能够提取结构化数据，释放分析和可视化工具的全部功能。为了尽可能简化此过程，我们构建了三代解析引擎。当前的引擎非常易于使用，我们实际上在产品中放置了一个按钮，告诉我们的支持团队为您设置规则。当然，作为工程师，我们的许多客户更喜欢自己动手。

结论

在今天的互联网中，“应用程序”越来越是业务（想想 Uber、Airbnb、Amazon 等等），而查明停机时间的根本原因至关重要。随着系统或代码越来越多地通过容器、无服务器和其他技术进行分布，这个过程比以往任何时候都更加困难。这就是 Scalyr 及其日志分析平台发挥作用的地方。它非常快速且易于使用。要了解有关此优秀产品的更多信息，请访问 https://www.scalyr.com。