分布式架构日志管理架构_微服务的分布式日志记录架构

分布式架构日志管理架构

在本文中，我们将了解在记录微服务时需要遵循的最佳实践以及在微服务领域中处理分布式日志记录的体系结构。众所周知，微服务可以在多个主机上运行。为了满足单个业务需求，我们可能需要与在不同计算机上运行的多个服务进行对话。因此，微服务生成的日志消息分布在多个主机上。作为开发人员或管理员，如果您想对任何问题进行故障排除，您将一无所知。因为您不知道在哪个主机上运行微服务来满足您的请求。即使您知道哪个主机满足了您的请求，转到不同的主机并提取日志并将它们与所有微服务请求相关联也是一个麻烦的过程。如果您的环境是自动扩展的，那么对问题进行故障排除是无法想象的。以下是一些实践，可以使我们的生活更轻松地解决微服务领域的问题。

集中和外部化日志存储

由于微服务在多个主机上运行，因此如果将跨主机生成的所有日志发送到外部集中式位置。 从那里您可以轻松地从一个地方获取日志信息。 它可能是另一个具有高可用性的物理系统，S3存储桶或另一个存储。 如果您将环境托管在AWS上，则可以很好地利用CloudWatch或任何其他云提供商，然后可以找到合适的服务。

记录结构化数据

通常，我们将日志消息（它们是原始文本输出）放在日志文件中。 有各种可用的日志编码器，它们会发出JSON日志消息。 添加所有必需的字段以进行日志。 因此，我们将在日志中提供正确的数据以对任何问题进行故障排除。 以下是一些配置JSON附加程序的有用链接。

如果您将Logstash用作日志聚合工具，则可以配置一些编码器以输出JSON日志消息。

生成相关性ID并将相同的相关性ID传递给下游服务，并将相关性ID作为响应的一部分返回

当我们进行第一个微服务调用时，生成一个关联ID，并将相同的关联ID传递给下游服务。 记录所有微服务调用之间的相关性ID。 因此，我们可以使用来自响应的相关性ID来跟踪日志。

如果您正在使用Spring Cloud开发微服务，则可以将Spring Sleuth模块与 Zipkin 一起使用

允许动态更改日志记录级别并使用异步日志记录

我们将在代码中使用不同的日志级别，并在代码中具有足够的日志记录语句。 我们应该有*地动态更改日志级别，因此启用适当的日志级别非常有帮助。 这样，我们无需启用最低日志记录级别即可在服务器启动期间打印所有日志，并避免了过多日志记录的开销。 添加异步日志追加程序。 这样记录器线程将不会被阻塞请求线程。 如果您使用的是Spring Cloud，请使用Spring Boot admin动态地更改日志级别。

使日志可搜索

使日志中的所有字段都可搜索。 例如，如果掌握相关性ID，则可以基于相关性ID搜索所有日志以找出请求流。

现在，我们将看到微服务世界中的日志管理体系结构。此解决方案使用ELK堆栈。通常，针对不同的环境，我们将具有不同的日志配置。对于开发环境，我们将使用控制台附加程序或文件附加程序，它们将在本地主机中输出日志。在开发过程中这很容易和方便。对于其他环境，我们会将日志发送到集中位置。我们将讨论的体系结构是针对QA和更高环境的。

在上述架构中，我们配置了Kafka日志附加程序，以将日志消息输出到Kafka集群。从Kafka群集中，消息将被提取到Logstash。将日志消息提取到Logstash时，我们可以根据需要转换信息。 Logstash的输出将保存在Elastic search中。使用Kibana可视化工具，我们可以使用记录的参数搜索索引的日志。记住，我们可以使用Rabbit MQ / Active MQ等消息代理而不是Kafka。以下是一些关于附加程序的有用链接。

在下面给出的第二个选项中，我们将使用Logstash附加程序将日志消息写入主机上的文件。 Filebeat代理将监视日志文件，并将日志信息提取到Logstash群集。

在第一个和第二个选项中，我选择第一个选项。以下是我的理由。

如果系统具有自动缩放功能的高度可伸缩性，则将根据需要创建和销毁实例。在这种情况下，如果您选择第二种方法，则如果主机被销毁，可能会丢失日志文件。但是，当我们登录时使用第一个选项时，消息将到达中间件。它非常适合自动缩放环境。
第二种选择是我们在主机上安装Filebeat或类似的文件监视程序。由于某些原因，如果这些代理停止工作，我们可能无法从该主机获取日志。同样，我们丢失了日志信息。

在接下来的文章中，我们将讨论更多关于微服务的文章。直到敬请期待！！！

翻译自: https://www.javacodegeeks.com/2017/07/distributed-logging-architecture-microservices.html