适用于Java开发人员的微服务：日志管理

1.简介

通过本教程的这一部分，我们进入了可观察性的领域 。 听起来像是另一个花哨的流行语，那到底是什么？

在微服务体系结构固有的分布式系统中，有太多相互影响的移动部件，并且可能以无法预测的方式失败。

可观察性 是涉及测量，收集和分析来自系统的各种诊断信号的活动。 这些信号可能包括度量，跟踪，日志，事件，配置文件等等。 – https://medium.com/observability/microservices-observability-26a8b7056bb4

尽快发现问题，在系统中找出出现问题的确切位置，并找出确切原因，这些是与微服务相关的可观察性的最终目标。 这确实是一个非常困难的目标，需要采取综合措施。

我们将要讨论的可观察性的第一大Struts是日志记录。 做好日志后，它们可以包含有关您的应用程序和/或服务所处状态的宝贵（通常是非常宝贵的）详细信息。日志是直接将您带入应用程序或服务错误流的主要来源。 除此之外，在基础架构级别，日志在识别安全问题和事件方面特别有用。

毫不奇怪，我们将专注于应用程序和服务日志。 日志记录的艺术可能是我们开发人员一生中不断完善的技能。 我们知道日志应该是有用的，易于理解的（经常是我们或我们的队友在上面运行），并且包含足够的有意义的数据以重建流程并解决问题。 原木膨胀或原木短缺，都导致浪费宝贵的时间或/和资源，很难找到合适的平衡。 此外，与通过粗心的日志记录做法泄漏个人数据有关的事件并非罕见，但其后果是深远的。

微服务的分布式性质假设存在许多服务，这些服务由不同的团队管理，很可能使用不同的框架来实现，并且在不同的运行时和平台上运行。 它导致日志格式和实践的激增，但是尽管如此，您必须能够将所有日志合并到一个中央可搜索位置，并能够关联跨微服务和基础架构边界的事件和流。 听起来像是不可能完成的任务，不是吗？ 尽管当然不可能涵盖其中的每个日志记录框架或库，但这里还是要有一组核心原则。

2.结构化还是非结构化？

提出并强制使用适用于日志的通用格式是不现实的，因为每个单独的应用程序或服务都在做不同的事情。 但是，围绕结构化日志记录和非结构化日志记录展开了一般性辩论。

要了解争论的内容，让我们以JCG租车平台的一部分Reservation Services为例，看看典型的Spring Boot应用程序如何进行日志记录。

...
2019-07-27 14:13:34.080  INFO 15052 --- [           main] o.c.cassandra.migration.MigrationTask    : Keyspace rentals is already up to date at version 1
2019-07-27 14:13:34.927  INFO 15052 --- [           main] d.s.w.p.DocumentationPluginsBootstrapper : Documentation plugins bootstrapped
2019-07-27 14:13:34.932  INFO 15052 --- [           main] d.s.w.p.DocumentationPluginsBootstrapper : Found 1 custom documentation plugin(s)
2019-07-27 14:13:34.971  INFO 15052 --- [           main] s.d.s.w.s.ApiListingReferenceScanner     : Scanning for api listing references
2019-07-27 14:13:35.184  INFO 15052 --- [           main] o.s.b.web.embedded.netty.NettyWebServer  : Netty started on port(s): 18900
...

您可能会注意到，日志记录输出遵循某种模式，但总的来说，它只是一种自由样式文本，当图片中出现异常时，它将变得更加有趣。

2019-07-27 14:30:08.809  WARN 12824 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_RESERVATION-SERVICE/********:reservation-service:18900 - registration failed Cannot execute request on any known server

com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
	at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112) ~[eureka-client-1.9.12.jar:1.9.12]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.register(EurekaHttpClientDecorator.java:56) ~[eureka-client-1.9.12.jar:1.9.12]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$1.execute(EurekaHttpClientDecorator.java:59) ~[eureka-client-1.9.12.jar:1.9.12]
...

从此类日志中提取有意义的数据并不有趣。 本质上，您必须解析和匹配每个日志语句，确定它是单行还是多行，提取时间戳，日志级别，线程名称，键/值对，等等。 通常，它是可行的，但也很耗时，计算量大，易碎且难以维护。 让我们将其与结构化日志进行比较，在结构化日志中，格式或多或少是标准格式（例如JSON ），但是字段集可能（实际上将）有所不同。

{"@timestamp":"2019-07-27T22:12:19.762-04:00","@version":"1","message":"Keyspace rentals is already up to date at version 1","logger_name":"org.cognitor.cassandra.migration.MigrationTask","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2019-07-27T22:12:20.545-04:00","@version":"1","message":"Documentation plugins bootstrapped","logger_name":"springfox.documentation.spring.web.plugins.DocumentationPluginsBootstrapper","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2019-07-27T22:12:20.550-04:00","@version":"1","message":"Found 1 custom documentation plugin(s)","logger_name":"springfox.documentation.spring.web.plugins.DocumentationPluginsBootstrapper","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2019-07-27T22:12:20.588-04:00","@version":"1","message":"Scanning for api listing references","logger_name":"springfox.documentation.spring.web.scanners.ApiListingReferenceScanner","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2019-07-27T22:12:20.800-04:00","@version":"1","message":"Netty started on port(s): 18900","logger_name":"org.springframework.boot.web.embedded.netty.NettyWebServer","thread_name":"main","level":"INFO","level_value":20000}

这些是以结构方式表示的相同日志。 从索引和分析的角度来看，处理此类结构化数据非常容易，也更加方便。 请考虑支持您的微服务团队的结构化日志记录，它肯定会有所回报。

3.登录容器

确定日志格式后的下一个问题是应将这些日志写入何处。 为了找到正确的答案，我们可能会回到十二要素应用程序的原理。

十二要素应用程序永远不会将自己的输出流路由或存储。 它不应尝试写入或管理日志文件。 相反，每个正在运行的进程都将其未缓冲的事件流写入stdout 。 在本地开发期间，开发人员将在其终端的前台查看此流，以观察应用程序的行为。 – https://12factor.net/logs

由于所有JCG Car Rentals 微服务都在容器中运行，因此它们不必关心如何编写或存储日志，而应将其流式传输到stdout/stderr 。 执行/运行时环境将调用如何捕获和路由日志。 不用说，这样的模式是深受所有容器协调器（FE支持搬运工日志 ， kubectl日志 ，...）。 从侧面讲，处理多行日志语句将是一个挑战。

值得一提的是，在某些情况下，您可能会遇到将其日志写入日志文件而不是stdout/stderr的应用程序或服务。 请记住，由于容器文件系统是临时的，因此您将必须配置持久卷或使用数据发送程序将日志转发到远程端点，以防止日志永久丢失。

4.集中日志管理

到目前为止，我们已经讨论了简单的部分。 下一个（可能是最重要的一个）是日志管理和合并。

4.1弹性堆栈（以前称为ELK）

我们要讨论的第一个选项是过去称为ELK的东西 。 它是一个缩写，代表三个开源项目： Elasticsearch ， Logstash和Kibana 。

Elasticsearch 是一个分布式的RESTful搜索和分析引擎，能够解决越来越多的用例。 作为Elastic Stack的核心，它集中存储您的数据，以便您发现期望的数据并发现意外的数据。 – https://www.elastic.co/products/elasticsearch

Logstash 是一个开放源代码的服务器端数据处理管道，它同时从多个源中提取数据，进行转换，然后将其发送到您喜欢的“存储”。 – https://www.elastic.co/products/logstash

通过Kibana ，您可以可视化Elasticsearch数据并浏览Elastic Stack，从而可以执行任何工作，从跟踪查询负载到了解请求在应用程序中的流动方式。 – https://www.elastic.co/products/kibana

ELK为日志管理和聚合提供了完整的端到端管道，因此在社区中获得了极大的欢迎。 弹性堆栈是ELK的下一步发展，其中还包括另一个开源项目Beats 。

Beats 是单一用途数据托运人的平台。 他们将来自成百上千台机器和系统的数据发送到Logstash或 Elasticsearch 。 – https://www.elastic.co/products/beats

如果您正在考虑拥有自己的日志管理基础架构，那么Elastic Stack （或其前身ELK ）是第一选择。 但是请注意，从操作角度来看，保持Elasticsearch集群正常运行可能是一项挑战。

JCG租车平台使用Elastic Stack整合所有服务中的日志。 幸运的是，使用Logback和Logstash Logback Encoder将结构化日志发送到Logstash非常容易。 logback.xml配置片段如下所示。

    

    
        logstash:4560
        
    
    
    
        
        
    

日志立即可供搜索， Kibana实际上是一站式商店，可以对它们进行相当复杂的分析或查询。

来自Logstash的日志存储在Elasticsearch中并在Kibana中提供

或者，您可以只使用Logstash Logback编码器将日志写入stdout/stderr然后将输出拖到Logstash 。

4.2 Graylog

Graylog是另一个基于Elasticsearch和MongoDB构建的集中式开源日志管理解决方案。

Graylog 是领先的集中式日志管理解决方案，旨在建立开放标准，以捕获，存储和实时分析兆兆字节的机器数据。 通过使分析变得异常快速，高效，具有成本效益和灵活，我们可以提供更好的用户体验。 – https://www.graylog.org/

与Elastic Stack相比，主要区别之一是Graylog可以通过网络直接从应用程序或服务接收结构化日志（采用GELF格式）（大多数情况下，每个日志记录框架或库都受支持 ）。

4.3 GoAccess

GoAccess是一个开放源代码解决方案，专门用于实时分析来自Web服务器的日志。

GoAccess 是一个开源的实时Web日志分析器和交互式查看器，可在* nix系统的终端中或通过浏览器运行。 – https://goaccess.io/

它不是一个完善的日志管理产品，但是它确实具有独特的功能集，可以很好地满足您的运营需求。

4.4 Grafana Loki

Grafana Labs的 Loki无疑是开源日志管理领域的新来者，该声明于2018年底（不到一年前） 宣布 。

Loki 是受 Prometheus 启发的水平可扩展，高度可用的多租户日志聚合系统 。 它的设计具有很高的成本效益，并且易于操作。 它不索引日志的内容，而是为每个日志流设置一组标签。 – https://github.com/grafana/loki

Loki的目标是保持尽可能轻巧，因此故意将日志的索引编制和处理排除在范围之外。 它具有一流的Kubernetes支持，但请注意， Loki目前处于Alpha阶段，不建议在生产中使用。

5.日志传送

让我们从完整的现成的日志管理解决方案中稍微切换一下，以记录日志数据收集器和托运人。 它们的作用是通过介于两者之间将源日志流与底层后端系统分离。 作为弹性堆栈的一部分的Logstash和Beats就是很好的例子。

流利的

Fluentd是广泛使用的开源数据收集器，现已成为Cloud Native Computing Foundation （ CNCF ）的成员。

Fluentd 是一个开源数据收集器，它使您可以统一数据收集和使用以更好地使用和理解数据。 – https://www.fluentd.org/

成为CNCF成员的好处之一是有机会与Kubernetes紧密集成，而Fluentd无疑在此发光。 它通常在Kubernetes部署中用作日志传送器 。

阿帕奇水槽

Apache Flume可能是最古老的开源日志数据收集器和聚合器之一。

Flume 是一个分布式，可靠且可用的系统，用于高效地收集，聚合大量日志数据并将其从许多不同的源移动到集中式数据存储中。 – https://flume.apache.org/index.html

5.3 rsyslog

rsyslog是功能强大，模块化，安全和高性能的日志处理系统。 它接受来自各种来源（系统或应用程序）的数据，可以选择将其转换并输出到不同的目的地。 rsyslog的优点在于，它已预装在大多数Linux发行版中，因此基本上您可以在几乎任何容器中免费获得它。

6.云

领先的云提供商在集中式日志记录方面有完全不同的方法。 正如我们将要看到的，有些确实提供了专门的产品，而另一些则包括了日志管理，这是较大的一部分。

6.1 Google Cloud

Google Cloud可能是其中最好的实时日志管理和分析工具之一，称为Stackdriver Logging （ Stackdriver产品的一部分）。

Stackdriver Logging 可让您存储，搜索，分析，监视和警告Google Cloud Platform和Amazon Web Services（AWS）的日志数据和事件。 我们的API还允许从任何来源提取任何自定义日志数据。 Stackdriver Logging 是一项完全托管的服务，可以大规模执行，并且可以从数千个VM中提取应用程序和系统日志数据。 更好的是，您可以实时分析所有日志数据。 – https://cloud.google.com/logging/

AWS集成令人惊讶，但实际上它是由Fluentd的自定义发行版提供支持的 。

6.2 AWS

AWS日志管理产品的中心是CloudWatch Logs 。

通过CloudWatch Logs ，您可以在一个高度可扩展的服务中集中使用的所有系统，应用程序和AWS服务的日志。 然后，您可以轻松地查看它们，在它们中搜索特定的错误代码或模式，根据特定的字段对其进行过滤，或者将其安全地存档以供将来分析。 – https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html

除了CloudWatch Logs ， AWS还带来了由Amazon Elasticsearch Service支持的集中式日志记录解决方案实施的用例。

AWS提供了集中式日志记录解决方案，用于跨多个账户和AWS区域收集，分析和显示AWS上的日志。 该解决方案使用 可简化AWS云中Elasticsearch集群的部署，操作和扩展的托管服务 Amazon Elasticsearch Service （Amazon ES）以及与Amazon ES集成的分析和可视化平台Kibana。 结合其他AWS管理服务，此解决方案为客户提供了可自定义的多账户环境，以开始记录和分析其AWS环境和应用程序。 – https://aws.amazon.com/solutions/centralized-logging/

6.3 Microsoft Azure

Microsoft Azure用于管理日志的专用产品经历了两次转变，并且到今天为止已成为Azure Monitor的一部分。

Azure Monitor 日志是用于监视，管理，安全性，应用程序以及Azure中所有其他日志类型的中央分析平台。 – https://azure.microsoft.com/zh-CN/blog/azure-monitor-is-providing-a-unified-logs-experience/

7.无服务器

在无服务器的上下文中考虑日志的微妙之处很有趣。 起初，没有太大不同，对吧？ 弊端在于细节：粗心的日志记录工具可能会极大地影响执行时间，从而直接影响成本。 请记住这一点。

8.微服务：日志管理–结论

在本教程的这一部分中，我们开始讨论可观察性Struts，从日志开始。 尾随一个日志文件就足够了。 相反， 微服务架构带来了来自许多不同来源的日志集中和整合的挑战。 可以说，日志仍然是解决软件系统中的问题的主要信息来源，但是还有其他强大的手段可以对它们进行补充。

友善的提醒是，在整个教程中，我们专注于免费和开源产品，但是商业日志管理解决方案的市场巨大。 许多组织倾向于将日志管理工作转移给SaaS供应商，而只是为此付费。

9.接下来

在本教程的下一部分中，我们将继续关于可观察性的讨论，这次重点是度量。

翻译自: https://www.javacodegeeks.com/2019/08/microservices-log-management.html