本文讨论过去几十年中研究日志分析的工具和流程是如何演进的。
日志分析是IT管理员（或SRE，或DevOps专业人员，或任何您想称之为的人）已经做了几十年的事情。因此，跟踪日志分析的历史是理解软件管理的有用方式，研究人们在长时间内随技术发展是如何发生思维变化的。
Linux早期的日志分析
如果您查看最新Linux或其他类Unix系统的CLI环境，您会注意到其中安装的许多最基本的工具可帮助您搜索或转换文本。比如grep，head，tail和sed。
这些工具对于各种文本操作任务很有用，对于早期的Unix系统管理员来说，它们构成了可用于执行日志分析的工具集的基础。
换句话说，早期的Unix没有提供从多个源聚合成日志文件，或自动将日志文件从一种格式转换为另一种格式的工具。没有提供实时监控日志数据和向管理员发送警报的工具。它当然没有用户友好的GUI来可视化从日志分析中获得的数据。
相反，管理员使用基本的文本操作和搜索工具来根据需要理解日志文件。考虑到当时软件的原始性质，这是他们可以管理的最好的。
瀑布时代的对数分析
到了20世纪90年代和21世纪初，那时正处于瀑布式软件交付的时代。
那时日志分析变得更加复杂。有更多的日志需要分析。操作系统为启动和系统事件等任务保留了单独的日志。应用程序通常也会保留自己的日志，但不一定集中在一个位置。此外，软件部署开始变得分散，增加了远程日志聚合的重要性。
这些需求导致创建了新一代的日志分析工具，例如syslog-ng和rsyslog，分别于1998年和2004年首次亮相。这两个工具提供了支持通过网络进行日志收集的关键功能。
与此同时，Windows世界中出现了一连串的专有日志分析工具，其中许多专用于特定任务。例如，有BootHawk，它支持分析引导和日志数据，以便改进Windows系统的启动和登录时间。
这些工具使管理员可以更轻松地查看日志数据，但他们并没有消除执行手动日志分析的需要。这在当时并不是什么大不了的事，因为这又是瀑布式软件交付的时代。如果通过手动排序日志数据来回应软件问题需要一段时间并不重要，因为用户习惯于在软件更新之间等待数年。持续交付和用户优先软件开发尚未成为常见做法。
日志分析和DevOps
今天，情况发生了变化，瀑布式软件交付的世界已经让位于DevOps。出现了新的日志分析技术以适应它。
在DevOps中，自动化就是一切。因此，手动日志分析不再有效。它削弱了持续交付，持续反馈和持续可见性流程。
类似地，单独分析来自多个源的日志数据是低效的。DevOps支持打破阻碍工作流程的孤岛。虽然大多数人可能不会将不同的日志文件视为一种孤岛，但它们基本上符合该孤岛定义。如果必须为要分析的每种类型的日志或每个主机专门建立单独的日志分析工作流，最终会得到一个非常孤立的工作流。
这就是为什么在DevOps世界中，日志聚合工具变得至关重要。现代日志聚合工具从多个位置收集日志数据，以及多种日志类型，并允许管理员通过单一窗格研究数据。
简而言之，在DevOps的世界中，IT团队不再部署六种不同的工具来收集和分析日志。今天的日志分析工具集允许一个工具满足多个日志分析需求。
结论
在过去的几十年里，日志分析工具和实践已经走过了很多。这些变化反映了日志数据本身的演变，日志已经从手动分析的原始形式发展成需要大规模聚合的方式，并且要求实时地，以满足DevOps的需求、持续可见的。