如何使用ElasTest实现测试的可观察性

- 日理万妓 2022-02-22 07:54 200阅读 0赞

在一个分布式的应用程序中，很难使用在开发非分布式应用程序中常用的调试技术。在出席2019年度欧洲测试大会（European Testing Conference 2019）时，Francisco Gortázar认为，把生产可观察性放到测试环境中有助于找到错误。他演示了ElasTest，这是开发人员利用可观察性以测试和验证分布式系统的工具。

Francisco Gortázar说，可观察性有助于我们理解应用程序的行为方式。理解分布式应用程序行为的唯一方法就是查看其生成的数据（其外部输出），以决定其内部状态。可观察性的目的是把从被观察的应用程序中获得的有用信息提供给测试人员及开发人员，他这样说到。

Francisco Gortázar建议，构建接近业务的高级抽象， 以便把有意义的事件与对用户没有直接影响的事件区分开来。他说，在生产中，我们通常从原始指标开始，但很快我们就需要开发自己的指标，并在这些指标上设置告警了。随时收集一切信息需要对大量信息进行管理，因此，他提议使用动态抽样以避免收集没有意义的事件，并专注于有影响的事件。当情况变得不正常时，就开始收集更多信息，以更好地诊断问题，并有希望找到解决方案。

ElasTest是用于提供测试环境中可观察性的开源工具，旨在帮助开发人员测试和验证复杂的分布式系统。它提供与ELK堆栈类似的功能，两者的主要区别在于对测试过程的认识。ElasTest理解什么是测试，并能够在必要的时候收集相关信息，并以一种相当直观的方式呈现出来，以分别查看错误和测试。

ElasTest项目由欧盟公开资助。该平台由欧洲学术机构、研究中心、大型工业公司和中小企业联合开发，使用开源软件社区的通用工具和服务。

InfoQ正在跟踪报道2019年度欧洲测试大会，并就测试中的可观察性采访了Francisco Gortázar。

**InfoQ：为什么收集有关分布式系统和云原生应用程序中正在发生的情况的信息那么难？**

> Francisco Gortázar：基本上，反映出的是两个主要问题：首先是从运行在不同机器上的多个服务中收集信息问题。需要用特定的软件发送所有信息给中央数据库以供在线或离线检查。其次是所生成的信息数量的问题。我们在这里碰到了大数据问题，因此，需要一个好的策略来删除旧的数据。

> 除此之外，测试环境还具有一些特性，使它们与生产环境有所不同。因此，有可能会发生这样的情况：在生产环境中使用同样的工具在部署和配置时需要花费大量的精力，因此，有时候，公司不希望在测试环境上投入大量精力。而运营团队通常忙于生产环境，无法将时间花在其他环境中。

**InfoQ：对于设置可观察性，您有什么建议？**

> Gortázar：很多不同的工具都有助于给我们的生产系统设置适当的可观察水平，但是，这需要投入很多精力把所有这些组合到一起，以便获得必要的可视化抽象。

> 理想情况下，我们应该在测试环境和生产环境中使用相同的工具。但是，通常，负责这些生产环境中可观察性系统的团队没有时间去为其他环境部署和维护类似的工具集。在这种情况下，至少开发人员和测试人员仍然可以使用能够给其测试环境带来一定程度可观察性的简单工具。

**InfoQ：在端到端的测试中，有哪些用于可观察性的工具？我们如何使用？**

> Gortázar：所谓的ELK栈（ELK是ElasticSearch、Logstash和Kibana的首字母缩写，它是通用工具集，用以管理来自Elastic co.的原始日志和指标）以及由该公司开发的Beat 代理使它非常轻松地从系统中收集日志和指标。一起部署我们要测试的系统和这些代理，并让它们发送信息给ElasticSearch数据库并不难。对那些失败的测试，我们可以使用Kibana进行进一步的问题调查。Kibana能够绘制所收集的指标，也可用于日志查询。这两个功能有助于更好地定位错误。

> 但是，在用于测试环境时，这些工具有局限性。当我们查看持续集成的系统时，事情就变得非常不同。通常，只在测试作为该集成过程中的部分运行时，才收集信息。此外，该信息只在测试失败（如，该应用程序没有完全按预期运行）时才有用。通常只有在检查该信息时，才能找到失败的根本原因。然而，该信息的呈现方式非常难以理解系统的行为。例如，控制面板通常不了解测试的边界（测试的起止时间），也无法过滤那些不相关测试的信息，除非我们知道它们在某个特定的时刻开始和结束。因此，隔离出有意义的信息是使用标准可观察性工具的问题之一。

**InfoQ：怎样才能找到错误的根本原因？**

> Gortázar：在分布式系统中，要找到问题的根源绝非易事。当我遇到该问题时，我希望能够把成功的执行和失败的执行进行比较。由于日志的自然属性（在不同的执行中产生的日志不同），这很难。工具应该能够识别出通用模式并去掉信息中不相关的部分，这些信息可能在两个不同的执行中不一样。

> 这个比较功能也应该可用于任何其他类型指标。如果我能够比较两个连续执行的请求的内存消耗或者延迟情况，也许能够理解为什么第二次执行会失败。

> 通常，需要更特定的工具来完成这类任务。在测试环境中，我们对要存储的那些信息有更多的控制，但是，我们需要在工具中提高对测试过程的认识。这样，我们能够在运行测试时，收集必要的信息，并提供适当的抽象以理解特定测试失败的原因。我们正在研究如何可视化用ElasTest收集的信息，以便更快更准确地定位错误。我们认为持续集成环境还有很大提升空间。

阅读英文原文：  
Observability in Testing with ElasTest