如何应对云原生革命带来的日志管理挑战？

作者：雨果的书房 2020-06-16 14:11:04

云计算

云原生 由于向云原生技术(例如，松耦合服务，微服务架构以及容器和Kubernetes等技术)的转移，过去的日志管理策略已不再足够。在云原生世界中成功管理日志需要对日志的聚合，分析等方式进行根本性的更改。

以前，日志管理相对简单。日志的数量，类型和结构都很简单且易于管理。

但是，在过去的几年中，所有这些简单性都没有出现。由于向云原生技术(例如，松耦合服务，微服务架构以及容器和Kubernetes等技术)的转移，过去的日志管理策略已不再足够。在云原生世界中成功管理日志需要对日志的聚合，分析等方式进行根本性的更改。

这就是云原生革命如何改变了日志管理的本质，以及IT和DevOps团队可以做什么以继续有效地管理日志。

[[330310]]

是什么使云原生日志记录与众不同

乍一看，云原生环境中的日志管理似乎与常规日志记录没有什么不同。云原生基础架构和应用程序仍会生成日志，并且日志管理流程的基本步骤(收集，聚合，分析和轮换)仍然适用。

但是，如果您开始尝试监视云本机环境，那么很快就会很清楚，要有效地管理日志要困难得多。原因有四个。

1.更多日志

首先，最简单的是要处理更多的日志。

在云原生时代之前，大多数应用程序都是运行在单个服务器上的整体组件。每个应用程序通常仅生成一个日志(如果它甚至完全创建了自己的日志;有时，应用程序会将数据记录到Syslog中)。每个服务器通常还只生成少量日志，其中主要是Syslog和auth。因此，要管理整个环境的日志，您只需要处理几个日志。

相比之下，在云原生环境中，您通常使用微服务体系结构-可能有十几个或更多不同的服务在运行，每个服务都提供了组成整个应用程序所需的不同功能。每个微服务都可以生成自己的日志。

不仅如此，还有更多的基础架构层;因此，通过扩展，更多的日志。您不仅具有基础主机服务器及其生成的日志，而且还具有位于应用程序和基础架构之间的抽象层(如Docker或Kubernetes或两者，取决于您的使用方式)创建的日志。

简而言之，向云本机的转变意味着IT团队已经从争夺支持的每个应用程序的少数几个单独日志的竞争发展到十几个甚至更多。

2.更多日志类型

总体上不仅有更多的日志，而且还有更多类型的日志。您不仅拥有服务器日志和应用程序日志，还拥有云基础架构的日志，Kubernetes或Docker的日志，身份验证日志，Windows和Linux的日志(因为现在更常见的是在同一操作系统中同时使用两种类型的操作系统)商店)等等。

这种多样性增加了复杂性，这不仅是因为要管理的日志数据类型更多，而且还因为这些日志类型的格式经常不同。结果，使用正则表达式匹配或其他类型的通用查询一次解析所有日志变得更加困难。

3.多样化的记录架构

随着日志数量和类型的增加，现在在应用程序环境中公开日志数据的方式变得更加复杂和变化。

Kubernetes是一个很好的例子。Kubernetes提供了一些内置功能，可以在节点级别收集日志。进行收集的确切方式取决于环境变量。例如，它在安装了systemd的系统上记录日志，但是直接写入/ var / log中的.log文件。

使事情变得更加复杂的是，Kubernetes没有对集群级日志的本地支持，尽管同样可以使用多种方法。您可以使用在每个Kubernetes节点上运行的日志记录代理来为集群生成日志数据，也可以在sidecar容器中运行日志记录代理。或者，您可以尝试直接从应用程序生成集群范围的日志数据，前提是您的集群体系结构和应用程序使此操作切实可行。

最重要的是，即使在同一平台内，日志记录体系结构的设置方式也存在很大差异。结果，在云原生环境中设计统一的日志管理流程变得越来越困难，该流程可以在需要支持的所有应用程序或平台上一致地工作。

4.非永久性日志存储

云本机日志记录的最后一个挑战来自以下事实：某些云本机应用程序缺少持久性数据存储。容器就是最好的例子。

当容器实例停止运行时，存储在容器中的所有数据将被永久销毁。因此，如果日志数据存储在容器内(默认情况下通常是默认情况下)，它将与容器一起消失。由于容器是短暂的，实例会暂停并被删除，而新实例会自动旋转，因此并不是在容器关闭之前询问管理员是否要保存日志数据。它将关闭并被删除，并随同您的日志数据一起使用，除非您事先将该数据移到了其他地方。

如果您只关心实时处理日志数据，那么这种瞬态可能还可以。但是，如果您需要在一段时间内保持历史日志可用，那么在容器停止运行时丢失日志数据是不可接受的。

云原生日志管理的最佳准则

为了应对在云原生环境中遭遇的这些挑战，团队可以使用以下准则。

1.统一日志收集和汇总

要使用多种不同类型的日志格式和架构来支持和记忆，尝试分别管理每个系统的日志是不可行的。而是实施统一的集中式日志管理解决方案，该解决方案可自动从环境的所有部分收集数据并将其聚合到一个位置。

2.采用灵活的日志管理解决方案

您的日志管理工具和流程应该能够支持任何类型的环境，而无需重新配置环境。例如，如果您有一个Kubernetes集群以一种方式公开日志数据，而另一个集群以另一种方式进行日志记录，则您应该能够从这两个集群中收集和分析日志，而不必更改任何一个集群的处理方式。日志。同样，如果您有一个应用程序在一个公共云上运行，而另一个应用程序在另一云上运行，则不必为了从一个中央位置管理其日志而修改任何一个云环境的默认日志记录行为。

3.实时收集日志

确保没有持久存储的环境中的日志不会消失的一种方法是实时收集日志数据并将其聚集在一个独立的位置。这样，日志数据一出生就将保存在持久性日志管理器中，即使容器关闭也将保持可用。与尝试仅在固定时间段内从容器内部收集日志数据相比，此方法更为可取，如果容器比您预期的更早关闭，则可能会丢失一些日志。

4.使用自定义日志解析器

除了忽略以常规分析工具无法支持的方式构造的日志之外，还可以利用自定义日志解析器来处理任何格式的数据。这样，您就不会冒从非标准日志中遗漏重要见解的风险。

结论

云本机日志管理从根本上不同于管理常规整体应用程序的日志数据。不仅日志数据的规模有所增加(尽管有所增加)，而且在记录，结构化和公开日志数据的方式上还存在更大的多样性。面对这些挑战，有效地管理日志需要一个日志管理解决方案，该解决方案必须完全集中和统一来自您支持的所有系统的日志数据，同时还提供从非标准日志类型中获取见解的能力。