关键点
在分布式的、可扩展的系统(通常包含不稳定的基础设施)中排除故障的效率通常取决于是否有充分的日志记录和搜索设备。
唯一事件ID、事务追踪技术和结构化的日志输出等技术，让我们得以透彻地了解应用程序的行为，以及应用程序是否在正常运作。
日志记录不再会“拖慢”系统性能，相反地，它在系统故障恢复中有重要的速度增益，尤其是在使用了日志聚合的情况下。
我们需要测试核心操作需求，如日志记录。
我们可以采用类似功能性需求的方式来测试日志，比如用户故事和BDD场景等。
现代日志聚合和搜索工具为团队的建立、测试和运行软件系统提供了重要的新功能。通过把日志作为一个核心系统组件，并使用如唯一事件ID、事务追踪技术和结构化的日志输出等技术，我们可以获得对应用程序的行为和正常运作的丰富的见解，尤其是跨组件的视图。这篇文章解释了 为什么测试日志是有价值的和如何用现代日志聚合工具做日志测试 。这种方法使日志成为了一种渠道，使分布式系统更具可测试性。
日志在整体上会为各方面提速
按一直以来的观点，许多人认为，日志会“拖慢”软件。如果使用的是同步文件I / O、慢速磁盘存储、甚至更慢的网络速度，从这些方面来看这种观点有一定的道理。因此，我们往往对在现场环境中运行的软件中记录下来的日志，抱着审慎的态度。然而，异步文件I/O和SSD存储正在成为常态，1GB、10GB，甚至100Gb以太网也越来越普遍，日志的性能特性现在已经变得不同。
现在，除了时间关键型的应用程序，如金融交易和其他复杂算法的情况下，在软件系统中我们已经很少单纯地优化软件的运行速度了。特别是在分布式系统、云和物联网(IoT)的背景下，我们需要考虑的是在发生错误后，恢复服务的时间(通常被称为“平均恢复时间”，Mean Time to Recovery，MTTR)。同时，我们也要考虑在上游(测试)环境里，确定问题原因所需要的时间。
现代日志聚合和搜索工具——比如ElasticSearch、Logstash、Kibana、LogEntries、Loggly、Sematext等等——给我们提供了丰富的方法与我们的软件的进行交互，它提供了丰富的用户接口去判断应用程序的行为，也提供了可编程的REST API来在多台服务器之间搜索和关联事件。
虽然额外的日志记录可能会导致软件程序的执行速度下降5%-10%。但如果在要搜索的位置具有详细的可用信息就可以帮助我们更迅速地诊断问题，加快我们对故障的响应，并且往往可以显著地减少发现一些隐藏得非常深的错误的时间!
快速的I / O和存储以及现代日志工具的组合——特别是当有工具提供给所有测试人员和开发人员时，就使我们能够把日志作为我们的软件系统的一个重要组成部分;这会让我们产生疑问：如果日志是我们的软件系统的一个重要组成部分，我们该如何测试它呢?
以包裹追踪做类比
我们大多数人都非常熟悉在线包裹追踪工具。这些工具使我们只要有一个追踪ID就能够看到我们的包裹在哪里。这些工具有两个有趣的功能：通过派送网络能够跟踪一个特定的包裹，并且也可以显示出涉及到的这个包裹在不同的时间的各种不同的状态(或事件)。
在跟踪一个包裹时，我们可以看到这些状态，比如“到达仓库”、“运输中”和“已送达”等等;这些都代表了特定的状态或事件，并且每一个都有一个系统内的内部标识符(ID)——事件ID。
在现代的异步分布式软件系统中，我们可以使用一种类似的技术来跟踪跨不同模块的运作执行情况。为了帮助我们做到这一点，我们定义了一些我们自己的事件ID，并把这些事件ID与我们正在使用的系统相关联起来。
预期事件和相关性ID的测试
我们不应该把时间花在测试日志子系统本身之上，比如log4net、log4j，等等;我们应该假设日志的功能(写入磁盘、切转日志文件、刷新缓冲，等等)都已经就绪了。相反，我们应该集中精力确保三个独立但相关的东西：