日志管理入门（日志管理是怎么实现的）

现代应用程序设计的现实意味着，当出现意想不到的问题时，找到根本原因的能力可能很困难。这就是集中日志管理概念可以提供大量帮助的地方。这个 Refcard 教你日志管理过程的基本流程，提供了一个全面的问题清单，在评估日志管理解决方案时要考虑，建议你什么应该和不应该记录，并涵盖了日志管理的高级功能。

日志管理的现状

随着技术的成熟，开发应用程序的前景不断演变，提供了侧重于处理所需处理方面的专门部分。诸如微服务、基于 JavaScript 的客户端框架、容器化策略、云采用以及 ConfigurationasCode (或“ * as Code”)等方面为日志事件和消息的起源提供了一个新的现实。

这些方面中的每一个都可以在参与某种形式的应用程序服务交付时记录事件。如果不考虑集中的日志管理解决方案，那些依赖这些日志来支持和维护应用程序的人会发现自己处于不利地位，这种不利地位可能会影响他们所支持的那些组件的底线。不幸的是，这些日志的格式和结构因系统而异。

这就是集中日志管理概念可以提供大量帮助的地方。在下图中，一个集中的日志管理解决方案可以从应用程序的所有组件中摄取日志事件，以提供一个单一的源来进行审查和分析。

图1: 集中式日志管理工作流示例

当日志被合并和组织正确时，分配给情况的工程师可以轻松地遍历事件，而不必在包含在不同的专有系统中的日志文件之间进行切换。

在过去几年中，日志管理的优先事项出现了新的挑战:

• 需要更快地分析和调试
• 对要求ELK Stack整合
• 采用合适的存储层以降低周期性成本的能力

首选的日志管理解决方案应该直接或通过某种形式的集成来解决所有这些需求。此外，前瞻性解决方案将考虑下一代特性，如:

• 循环模式识别
• 机器学习和众包支持
• 异常检测
• 数据可视化

第二部分

谁使用集中日志管理？

DevOps

当出现意想不到的情况时，DevOps 工程师通常需要分析一组信息。来自应用程序环境中所有组件的源日志深藏在文件系统中，很可能使用专有的日志格式。即使可以收集所有日志，按时间顺序逐一查看每个日志以确定问题的原因也是一项乏味的任务。

相比之下，如果有一个集中的日志管理系统，日志不仅被合并，而且还被标准化和组织，这样 DevOps 工程师就可以回放正在调查的场景。在这样做的时候，更广泛的观点为确定根本原因提供了更大的机会。

在大多数情况下，集中日志管理对 DevOps 工作人员来说是有好处的。然而，其他三个领域可以成为集中日志管理解决方案的受益者: 安全性、遵从性、 IT 操作和软件工程。

Security

当扫描对给定应用程序或服务的未经授权的访问时，安全团队可以从集中的日志管理解决方案中受益。这种好处的范围既可以包括匿名的外部实体，也可以包括内部帐户。可以在集中式日志管理系统中创建解决方案中的报告，以匹配可能是可疑活动指示器的日志事件。考虑解决方案管理下的 API 记录的以下错误:

2022-02-14 03:07:15.824 ERROR 36209 — [main] AccessServiceImpl : User id (someUserId) does not have access to perform this operation

2022-02-14 05:27:07.212 ERROR 36209 — [main] OrderServiceImpl : User id (null) does not have access to review order (1001001)

2022-02-14 10:17:37.542 ERROR 36209 — [main] AccessServiceImpl : Attempt to access API without a proper token on IP 127.0.0.1

一旦丰富并吸收到集中的日志管理解决方案中，可以设置报告来跟踪错误类型(36209) ，显示日期/时间信息以及记录的消息。

Compliance

作为定期合规/审计任务的一部分，集中的日志管理解决方案可以帮助合规工作确保应用程序或其用户遵循已经建立的期望。对于需要遵守法规指南(SOx、 FDA、 HIPAA 等)的应用程序，采用集中式日志记录解决方案可以提供一站式的分析和认证源。

IT Operations

当采用集中的日志管理解决方案时，监视和理解 IT 基础设施的复杂性可以减少干扰。IT 操作人员可以使用该工具来了解系统如何相互交互，从而提供一个工具来帮助在日常任务(如系统维护中断)计划时作出决策。

Software Engineering

专注于构建特性、服务或集成的软件工程师可以从集中的日志管理中受益，而不管所使用的框架是什么。这是因为开发阶段分析和调试所需的日志事件是由从专有服务调用的框架、服务和容器来源的。

在非集中模型中，定位和分析独立日志所需的时间很快影响到工程师专注于交付为当前迭代计划的功能的时间。这种时间可能导致交付延迟，影响业务发起人所请求的特性和功能。

第三部分

日志管理: 基本过程和技术

集中式日志管理解决方案利用了如下所示的流程:

图2: 日志管理工作流示例

Collect

Collect 是建立到源系统的连接并在原生创建日志时摄取这些日志的过程。如果需要，可以确定路由到集中日志管理解决方案的日志级别

Parse

Parse 提供了将源日志消息转换为在集中式日志管理解决方案中标准化的格式的能力。这是一个重要方面，因为使用“扩展的”Apache 格式的 API 生成的日志与来自数据库服务器的日志不同(例如)。

正确解析下列日志事件:

1550149377 INFO Userid (someUserId) successfully logged in from IP 127.0.0.1

02/14/2022 03:07:15.824 ERROR 36209 — [main] AccessServiceImpl : User id (someUserId) does not have access to perform this operation

可以更新如下所示:

2022-02-14 08:02:57.000 (GMT) INFO Userid (someUserId) successfully logged in from IP 127.0.0.1

2022-02-14 08:07:15.824 (GMT) ERROR 36209 – AccessServiceImpl – User id (someUserId) does not have access to perform this operation

结果解析的消息为所有消息提供了标准化的外观，使分析人员能够更有效地处理日志的结果。

Enrich

Enrich 引入了进一步定义日志事件的能力。例如，增强功能可以执行必要的逻辑来分析记录的 IP 地址，使分析人员更容易理解被引用的系统或服务。此处还可以转录应用程序或特定于服务的常量，以限制交叉引用日志信息的需要。

以下事件:

1550149377 ERROR 90215 – ServiceProviderCallOut – Could not access service on 127.0.1.1 due to an internal error code 10017.

可以如下所示加以丰富:

2022-02-14 08:02:57.000 (GMT) – ERROR 90215 – SeviceProviderCallOut – Could not access DocumentGenerationProcessor 4C (127.0.1.1) due to an internal Socket Failure (error code 10017).

通过上述增强，时间戳被转换为 GMT 日期，IP 地址被转换为包含主机系统，错误代码被查找以返回其他信息。

Store

存储将收集、解析和丰富的日志保存到集中式日志管理解决方案所使用的数据存储中。此时，可以利用索引和筛选器来更深入地了解源系统中的本机日志。

Alert

使用存储在集中式日志管理解决方案中的必要信息，可以将警报配置为在事件升级到更高严重级别之前捕获事件。此时，集中的日志管理解决方案通常可以将事件发送到其他系统，以提供即时通知和升级。高级日志管理解决方案应该更进一步:

Real-time alerts 实时警报

使工程师能够处于情况的前端，在警报出现时接收到通知

Live tail log monitoring 实时跟踪日志监控

允许支持团队监视从源系统编写的日志，从而避免查看历史日志

分析

通过使用集中式日志管理解决方案的接口，分析人员可以搜索、过滤和检查与给定情况相关的所有事件，而无需直接从源系统检查日志。

第四部分

如何开始日志管理

什么需要记录(什么不需要记录)

处理和分析日志信息所需的时间非常重要，特别是在迫切需要解决意外情况时。因此，应进行一段时间的探索，以确定哪些信息将被记录，哪些信息将不被记录。在引言中提到的例子中，DevOps 工程师需要检查遇到事件的应用程序的合并事件。在大多数情况下，这种情况需要尽快得到解决。

这项工作可以很容易地包括来自微服务、数据库、客户机应用程序框架和安全层的日志。如果日志包含与分析无关的方面，则需要额外的时间来审查和丢弃此类信息。

考虑从参与集中式日志管理策略的身份验证/授权服务摄取的日志的以下示例:

1550149377 INFO Userid (someUserId) successfully logged in from IP 127.0.0.11550149382 INFO SSID for someUserId updated to reflect last login1550149385 WARN Password for someUserId will expire in 26 hours1550149415 INFO UserId (someUserId) granted access to SomeApplication via token #tokenGoesHere

虽然正在记录的信息是重要信息，但最好过滤掉所有事件，但以下信息除外:

1550149377 INFO Userid (someUserId) successfully logged in from IP 127.0.0.1

通过这样做，在危机期间需要检查的日志消息的数量被最小化，特别是在数百(或数千)用户正在访问应用程序的情况下。

敏感资料

另一个需要考虑的方面是确保保密信息(访问令牌、数据库连接字符串、加密密钥、帐户信息、用户信息等)不存储在集中的日志管理解决方案中。在上面的日志示例中，应该禁止将 # tokenGoesHere 日志消息摄入到集中的日志管理解决方案中，因为该令牌可能被认为是敏感信息。如果需要进行该事件，则应丰富该消息，使其只摄取以下信息:

1550149415 INFO UserId (someUserId) granted access to SomeApplication

制订指引

关键是要建立指导方针，以满足将使用该解决方案的整个用户社区的需求。这与其他应用程序的体系结构没有什么不同ーー理解日志事件不足和日志事件过多所引入的限制。一旦建立，这些信息应该与团队共享，这些团队可以创建由集中日志管理解决方案捕获的事件。

集中日志管理检查表

当决定评估集中的日志管理解决方案时，可用的产品的数量肯定会显得令人生畏。因此，了解哪些特性和功能对于您的实现非常重要是至关重要的。以下是需要考虑的一些高级别方面:

从0到60

– 什么是涉及到开始？从设置和配置到日志分析和调试的成功，新的实现跨越的速度有多快？

尽管达到全速所需的时间并不是一个独有的指标，但是了解正在评审的产品是否能够在没有大量设置和配置的情况下快速启动还是有一些好处的

易于数据探索

所有类型的用户都能轻松操作系统和查找数据吗？

请记住，用户通常更像是一个数据浏览器，而不是一个数据科学家。当从系统中提取结果时，任何内置的报告或过滤器都将导致更好的用户体验

分析师效率

– 系统的反应速度有多快，包括创建复杂搜索或过滤器的能力有多快？一旦返回数据，结果是否易于理解和利用？

如上所述，当试图从集中的日志管理解决方案中检索信息时，时间通常是驱动因素。同样，过滤器和报告可以帮助提高最终用户的效率

可伸缩性

– 解决方案在您的组织中的工作效果如何？是否所有系统都可以在一个集中的日志管理解决方案中运行，还是需要多个实例？五年后怎么样？

随着越来越多的系统被引入到该技术中，了解集中式日志管理解决方案如何扩展是非常重要的。虽然预计日志数据存储池变得越大，性能就会下降，但是理解预期的响应时间是在并行比较期间使用的一个有价值的指标

Storage

存储期望是什么，存储在哪里，目标实现的相关成本是什么？

了解存储的任何边界也很重要，特别是在系统性能方面。理想的日志管理系统应该包括以较低的价格利用分层存储来存储数据的能力(这种存储是为了历史目的而不是分析目的而维护的)

日志完整性

– 保留的信息是否包括一切必要的内容，还是需要额外努力才能从其他来源检索数据？

如果您发现自己不得不从集中式日志管理解决方案之外检索数据，那么与您的需求相关的功能上可能存在差距

数据增强功能

是否存在浓缩功能? 如果存在，其利用和维护的难易程度如何？

最好回顾一下当前的日志源，并更多地了解可能需要数据浓缩的边缘情况，这些边缘情况超出了典型的浓缩使用模式

开放/封闭源码

解决方案是否采用开源方法？这种方法如何与您的实体采用的其他解决方案配合使用？

Log collectors

– 如何定义日志收集器？它们是专有的还是由第三方/供应商创建的？这些日志收集器是否可以由解决方案集中管理，还是必须在日志源级别独立管理？

通常，专有开发的连接器会滞后于第三方/供应商本身创建的连接器。如果连接器可以通过集中的日志管理解决方案进行管理和配置，那么在日志源上维护配置的需求就会减少

配置为代码

– 解决方案是否采用“ * as Code”方法，允许将集中式日志管理解决方案的配置存储在代码存储库中？

如果您的组织接受“ * as Code”的概念，那么采用此原则的集中式日志管理解决方案将能够以编程方式构建和配置实例

特定于类的功能

– 解决方案是否包含帮助特定类别用户(DevOps、安全性、合规性、 ITOps)获得共同结果的特性？例如，是否存在报告来定位 HIPAA 这样的监管异常？

内置功能以协助特定的用例，将减少这些组所需的时间，以提高速度并识别集中日志管理解决方案中的价值

API 功能

是否有公共 API 可用于解决方案？

熟悉集中式日志管理解决方案的任何底层应用程序程序接口(API)可以进一步证明或利用实现返回的值

预期成本

产品是如何获得许可的？

理解成本模型将允许随着时间的推移进行产品比较，并且更多的组件在您的组织中采用集中的日志管理

CLM vs. SEIM

目标解决方案是集中式日志管理(CLM)解决方案，还是安全信息和事件管理(SEIM)产品？你目前的需求是否需要一个解决方案而不是另一个… 或者两个都需要？

批准的产品要求将是理解应该考虑什么类型的解决方案的指南。然而，了解 CLM 和 SEIM 之间的区别是很重要的

ELK Stack

潜在的解决方案是否利用了 ELK 堆栈？如果没有，那么存在哪些集成来利用这些工具来提高集中式日志记录解决方案的有效性和可观察性？

ELKStack 是一个理想的集合，可以很好地与集中式日志管理解决方案一起工作。它通过利用自然扩展的产品来与日志记录需求保持一致，从而促进了跨多个系统存储大量数据。一个目的驱动的搜索引擎与一组设计用于分析和观察集中日志数据的工具相结合

在每一种情况下，重要的是要考虑在产品评估期间需要采取哪些步骤来利用 ELK 堆栈和任何相关成本

日志管理的下一代特性

虽然集中式日志管理检查表部分提供了在可接受的解决方案中应该具有的特性和功能，但下面是提供前沿功能的产品的下一代(下一代)特性的集合。这些特性旨在利用技术来丰富日志管理经验。

循环模式识别

通过选择快速查看所有日志数据中的重复模式，分析师可以隔离问题和意外行为。实现展示模式透视图的能力将改变分析师对一系列无穷无尽的日志条目的看法，将其转换为一个分类表，显示如下所示的内容:

Count    Ratio   Pattern-----    ------  ---------------------------52,701   22.17%  License key has expired19,457    7.99%  Invalid User ID18,295    7.25%  New customer account created

在上面的示例中，大部分消息匹配许可证密钥已过期的模式，这可能不容易在大量单个日志条目中找到。

机器学习与众包

分析师经常发现自己在寻找一个意外问题的根本原因ーー这可能就像大海捞针。机器学习和众包支持的概念可以最大限度地减少确定根本原因所需的时间，而不是花费数小时试图缩小无穷无尽的日志条目海洋。采用机器学习的下一代解决方案可以帮助呈现集中日志事件中的关键术语，以及每个术语的出现次数。这使得分析师能够快速减少要处理的日志条目的数量，从而使干草堆变得更小。

由于要处理的日志集合较少，这些相同的市场领先者可以从集中日志管理服务之外的来源提供额外的信息。例如，打开一个给定的日志条目可以提供与所捕获的日志数据相关的预期信息，但它更进一步，将众包数据链接起来，例如:

讨论与记录的邮件或条件相关的线程

博客条目的重点是如何纠正这种情况

所使用的方法、函数或类的文档

与错误本身相关的其他信息

异常检测

不经常出现在日志中但在本质上非常有价值的问题通常称为异常。下一代解决方案应该提供检测异常的能力，这样就可以将异常表现出来并加以处理。异常检测利用机器学习模式自动隔离和调查基于异常行为的突发问题。

一旦指定了字段的基线集合并建立了查询，集中的日志管理服务就会构建一个模型，并开始分析和捕获异常行为和事件。这些检测到的事件可以作为新的实时警报浮出水面，以便及时了解新出现的问题。

数据可视化

可视化使分析人员能够以图形格式查看数据，这使他们能够更好地理解随着时间的推移进行的比较。通过为 X 和 Y 轴定义公共元素，可以利用下一代集中式日志管理解决方案中的数据来传递所捕获事件的状态。可以将这些可视化组合到一个仪表板中，以传递由集中的日志管理服务监视的环境的总体状态。

第五部分

结论

集中式日志管理解决方案的价值可以由一个实体的 IT 部门中的几个组来证明。通过适当的指导方针和成功的实现，利用集中日志管理的好处可以导致识别事件的根本原因并在问题升级之前接收通知的能力。

集中日志管理解决方案的实现应该与组织中引入的任何其他工具没有什么不同。需求和理解应该驱动哪些组件以正确的日志级别记录到解决方案中。任何敏感信息都应该被排除在中央日志管理解决方案之外，始终遵守任何规章制度的指导方针。

集中式日志管理解决方案的一个主要成功因素是分析人员能够找到所需的信息，而不必跨越解决方案本身，从而尽可能少地花费时间。集中的日志管理解决方案，包括预先设计的报告和功能，以协助所有类别的用户可以提供一个更快的周转与执行例行请求。

确定集中的日志管理解决方案是否适合您的需求，或者您的需求是否属于安全信息和事件管理解决方案集需要花费一些时间。虽然有些解决方案可能运行良好，但是了解您的目标终端状态有助于为您的公司确定最佳解决方案。

利用 ELK 堆栈和机器学习方法的系统自然比那些不利用 ELK 堆栈和机器学习方法的产品具有竞争优势。提供下一代特性不仅可以为分析师提供一整套可以利用的工具，而且还可以最大限度地减少意外情况可能造成的停机时间。