日志记录在云端应用的价值：与Kresten的问答访谈

本文要点

• 观测性这个词涵盖了系统发出的一系列信息。从事件或跟踪的详细日志，到传统监控事件或汇总统计数据，都在这个系列范围内。
• 将构成运行系统的各种组件或服务中的日志进行聚合，是一种监控、调试和理解现代软件系统的非常好的方法。
• 云技术和容器技术提供了许多优势，但是牺牲了“可理解性“，而“可理解性”也许是诠释“观测性”的最好方法。
• 传统监控通常随着时间的推移会减少度量指标。如果被监控的系统是成熟的且被很好理解的，这个方法也许行得通；但是，当你刚开始构建系统时，通常情况并非如此。
• 随着你开始逐渐了解你的日志，工程师们就会通过聚合查询开发出度量指标，而这对于系统的健康非常重要。这些查询得到的结果构成了系统 dashboard 和告警的数据来源。
• 为了调试或进行事故响应，你需要一个使得进行定制查询变得简单的系统；拥有一个不需要对记录的信息强加模式的日志解决方案是非常重要的。
• 日志会自然地从一种比较冗长的层次，演变成一种更加结构化的和更好信噪比的层次。如果忽略了营造这种演变就是一种反面模式。
• 人工智能（Artificial Intelligence，AI）和机器学习（Machine Learning，ML）在日志领域的未来影响可能会很大。现在，我们聚焦于借助开发人员编程获取日志，来让人工智能和机器学习分析这些信息，然后利用人类的智能（human intelligence）来提供解释。
• 人工智能和机器学习通常需要一个基线才能识别异常值，而随着一个生成日志的系统让其日志平台变得稳定，就能够提供这种基线。

Kresten Krab 是 Humio 的 CTO，InfoQ 最近与他坐下来讨论了日志记录在系统观测性这个话题中的角色。Krab 一开始就提到，云技术和容器技术提供了许多优势，但是牺牲了“可理解性”，而“可理解性”也许是诠释“观测性”的最好方法。这次讨论涉及许多话题，但是其中一个主题是，将构成运行系统的各种组件或服务中的日志进行聚合，是一种监控、调试和理解现代软件系统的非常好的方法。

此次采访的完整文字稿如下：

InfoQ: 您好，Kresten，非常感谢您今天接受 InfoQ 的采访。请您介绍一下自己，并大致介绍下您目前在 Humio 的工作，可以吗？

Kresten：过去这两年，我担任 Humio 的 CTO。Humio 是我们启动的一个创业项目，为 DevOps 团队提供一种更好的方法来理解他们的系统。20 年前，我联合创办了 Trifork，一家目前拥有超过 400 名员工的定制软件方案提供商。从那个时候，我们就一直将帮助其它公司使用新技术来获得成功作为我们的使命。

我和团队一起实现新技术、进行培训并组织会议来传播这些知识。在这个过程中，我们经历了不断增加的软件系统的复杂性，从 90 年代一开始的能够 web 访问的项目，一直到现在的复杂的云解决方案。同时，我也看到了一些团队在生产中努力尝试去理解、调试和监控他们的系统。

因此我们发现，将构成运行系统的各种组件或服务中的日志进行聚合，是一种监控、调试和理解这些系统的非常好的方法。在 Humio，我将这称为“感知系统细节”的能力。日志是理解一个系统的非常有性价比的集成点，因为日志已经存在在那里了。你不需要给现有系统增加功能来使它们生成日志：它们已经在生成日志，你只需要收集它们并根据同一个事件时间表将它们聚合起来。

我们发现，现有的日志管理工具提供商都要求你限制你的日志记录方式——包括成本、配额限制、复杂度和性能等，而我们认为我们可以做得更好。因此，你也可以说我们的使命就是要解除日志记录的限制。Humio 就是我们为此从头开始打造的产品，让每个人都能分享这种前景。

InfoQ: 最近有一些关于监测和观测性之间对比的讨论，而日志记录与这个话题有什么关联呢？

Kresten：我们非常欢迎关于这个话题的讨论。“观测性”这个词非常适合我们对于“感知系统细节”的陈述。我不认为这是一个相互对立的话题。观测性这个词涵盖了系统发出的一系列信息。从事件或跟踪的详细日志（最详细和丰富的信息），到传统监控事件或汇总统计数据，都在这个系列范围内。你可以从事件中获取统计信息，但是反过来却不行。Cindy Sridharan 发布的一篇关于“云端时代的监控（Monitoring in the Time of Cloud Native）”的博客，也是对于这些信息的一个非常好的解读。

因此，如果你只是用传统的监控方法来收集测量数据，那么你就是在错失信息。如果被监控的系统是成熟的和被很好理解的，还行得通；但是，当你一开始构建一个系统时，通常不是这样的情况。换句话说：你通常并不知道什么会造成事故，因此，拥有丰富的基础信息用来调查是非常有利的。这使你能够回顾过去并找到只有现在才能意识到的问题，而这是非常重要的。

我们提倡的观点是，所有这些原始信息非常适合存储到具有丰富查询能力的时间序列文本数据存储器中。并且，能够在一个共享的工具中同时处理事件格式的信息和测量指标格式的信息，不需要在调试时束手束脚，并且还不需要根据自己认为的重要性来理解一个系统，这些都是非常大的优势。如果你曾经有过“我要是用索引记录过那些信息就好了”的时刻，那么你就会明白我的意思。

InfoQ: 您能稍微讲解下实用的基于基础设施的日志记录，在过去 5 年中是如何演变的吗？云、容器和新的语言运行时环境，对于监控和记录日志会有怎样的影响？

Kresten：软件如今已经不再是一堆可以单独构建和测试的代码。云、容器和所有这些技术都明显提供了许多优势，但是牺牲了“可理解性”（而这可能是诠释“观测性”的最好方法）。系统组件变得更加零散和遥远，直接控制的可能性更小。这种演变伴随 DevOps 运动同时发生，改变了人们思考软件的方式。现在，有许多团队都是有一个他们关心的系统，而不是仅仅构建一堆软件，然后将它丢给隔壁的运维。

因此，“明白”软件系统的行为，如今很大程度上是不可能的。大多数软件系统，是由许多其它不受你控制的系统组合的。将你的软件系统当作一辆自动汽车：必须将它放到公路上才能进行测试和改进。但是，很多情况下，我们仍然在好像我们能够测试但其实并不能真实地测试的实验室开发软件。这是云和容器对于我们的软件系统的影响，并且我认为我们必须正面并解决这个问题。

InfoQ: 适合分布式系统的新架构模式，例如微服务、FaaS，对日志记录有什么影响？

Kresten：就能够暴露个体组件的资源消耗情况，以及能够单独改进系统的各个部分而言，我认为分布式系统的新架构模式在这些方面很有优势。但是，就整体理解系统而言，特别是如果你没有捕获和集中日志，这些架构模式就非常不利于了解系统全貌，因为信息分散在不同的平台和组件中。

很难从整体上谈论日志记录，但我可以说说我们在 Humio 做的一些关于这方面的事情。对于那些诸如 DC/OS、Mesos、Kubernetes、Heroku、CloudFoundry、AWS 之类的平台，我们进行了系统集成，来更容易地获取所有日志并将它们放在同一个地方。在每一个平台上，日志差不多都是以一种统一的方式记录，这使得日志基础设施能够在不需要大量配置的情况下捕获大量的日志。因此，在使用这些架构模式时，如果你的系统有这种共享的基础设施，你就可以在使用这些平台的同时非常方便地获取到日志。

InfoQ: 工程师们通常对日志系统都有什么类型的疑问，而现代日志平台对此如何进行调整？

Kresten：我们见证我们的用户经历了一个演变过程：一开始他们将日志平台作为一个搜索引擎，针对他们的日志任意进行文本搜索。但是很快，焦心就转变为从文本中提取信息，然后在提取到的数据上构建聚合统计。

随着你逐渐了解你的日志，工程师们就会通过聚合查询开发一些度量指标，而这些指标对于系统的健康非常重要。这些查询得到的结果构成了系统 dashboard 和告警的数据来源。对于大多数系统，你可以利用这些从日志数据中聚合统计出来的数据，而不是日志数据本身，作为监控指标。

为了调试或进行事故响应，你需要一个使得进行定制查询变得简单的系统；因此，拥有一个不依赖日志记录格式的日志记录解决方案是非常重要的。在这些情况下，我们通常见到，工程师们会问一些他们没有提前考虑过的问题。

开发者意识到他们可以与日志打交道时的反应是非常有趣的。随着你尝试去调试或优化你的系统，你会发现日志信息迭代地演变，变得更加结构化。
“迭代“一词在这里非常重要，因为你不可能让你的系统从一开始就构建完美的日志集。因此，你会不断重构你的日志系统：最初的子系统记录日志比较冗长，而当子系统变得成熟，你会逐渐降低日志数据中的信噪比。因此，你的日志平台应该能够应对这种多样性。

InfoQ: 您认为最常见的日志记录的反面模式是什么？您能建议一些方法来避免这种反面模式吗？

Kresten：听别人提到由于指标、成本或者公司政策而没有办法记录日志（或者没有权限访问日志）之类的事情，总是令我心碎。我们见过许多客户，他们通过摄取采样数据来减少日志记录。这在控制日志规模上是必要的，但是应该尽可能避免这样做。

之前，我已经提到了日志重构。日志系统会自然地从一个比较冗长的层次，演变到一个更加结构化的以及更好信噪比的层次。这个过程有点像给你的花园除杂草。我认为，如果忽略了进行这种重构就是一种反面模式。

InfoQ: 您认为，QA 和测试人员对于系统观测性，特别是对于日志记录来说，充当着怎样的角色？

日志对于测试和质量控制超级有用。作为我们自动化测试和持续集成配置的一部分，我们从构建操作中获取日志，以这些日志数据为基础运行查询，然后将查询结果作为测试报告依据以及构建报告和构建告警的一部分。通过这种方式，你可以利用日志聚合来构造集成测试，并将其作为提升测试效率和整体质量的方法。

InfoQ: 人工智能和机器学习对于日志记录，在实现更高效的日志记录方面，以及找出可见的（或者潜在的）问题方面，都会有哪些影响呢？

Kresten：我认为这个话题有点大。目前，我们聚焦于借助开发者编程来获取日志，然后让人工智能和机器学习分析这些日志，最后利用人类的智能来提供解释。人工智能和机器学习通常需要一个基线才能够识别异常值，而随着一个生成日志的系统使其日志平台变得稳定，就能够提供这种基线。日志的丰富性和日志中的高平均信息量对人工智能和机器学习都是一个挑战，因为它们更适合应用在低维环境中。

我认为，一个日志系统可以在任意日志中自动发现异常值是不可能的。你需要一些交互，在这些交互中让系统用户提取和概括对于发现异常值有用的日志流中的信息。对于某些特定类型的日志，这些信息或多或少可以自动获取到，但是在通常情况下，你需要某些数据科学家的能力来选择要查找的内容。

InfoQ: 再次感谢您抽出时间接受我们的采访。您还有什么要跟 InfoQ 的读者们分享的吗？

Kresten：也非常感谢您的采访。大家可以随意访问 humio.com ，试一试我们的 SaaS 解决方案或者向我们咨询如何在您自己的系统中运行 Humio。我们一直热衷于更深入地讨论日志记录相关的想法！

关于采访嘉宾

Kresten Krab 目前在 Humio 担任 CTO，提供技术领导和技术视野。他之前在 Trifork 担任 CTO 时，负责技术策略，并在分布式系统、数据库、erlang、Java 和移动应用开发等技术领域提供咨询建议。Kresten 是许多开源项目的贡献者，包括 GCC、GNU Objective-C、GNU Compiled Java、Emacs、Apache Geronimo/Yoko 等。在 Trifork 任职之前，Kresten 在 NeXT Software（目前已被苹果公司收购）工作，负责 Objective-C 工具链、调试器和运行时系统的开发。Kresten 有 Aarhus 大学的计算机科学专业的博士学位。

查看英文原文： The Value of Logging within Cloud Native Applications: A Q&A with Kresten Krab

感谢罗远航对本文的审校。