日志记录可以说是可观测性解决方案中最重要的元素。日志提供有关系统行为的基础且丰富的信息。在理想的情况下，您将做出有关日志记录的所有决策，并在整个系统中实施一致的方法。 然而，在现实世界中，您可能会使用遗留软件或处理不同的编程语言、框架和开源包，每种语言、框架和开源包都有自己的日志记录格式和结构。 由于系统中的日志格式如此多样化，您可以采取哪些步骤来从所有日志中提取最大价值？这就是我们将在这篇文章中介绍的内容。 我们将了解如何设计日志、大型系统中日志记录的挑战和解决方案，以及如何考虑基于日志的指标和长期保留。 让我们深入了解一下日志级别和格式。 测井设计 日志设计需要考虑很多因素，但最重要的两个方面是日志级别的使用以及是否使用结构化或非结构化日志格式。 日志级别 日志级别用于根据日志消息的严重性对日志消息进行分类。使用的具体日志级别可能会有所不同，具体取决于日志记录框架或系统。但是，常用的日志级别包括（按照详细程度从最高到最低的顺序）：    ：捕获系统采取的每一个操作，以重建全面的记录并解释任何状态变化。 TRACE    ：捕获用于调试目的的详细信息。这些消息通常仅在开发期间相关，不应在生产环境中启用。 DEBUG    ：提供有关系统操作的一般信息，以传达系统执行中的重要事件或里程碑。 INFO ：表示可能需要注意的潜在问题或情况。这些消息并不重要，但如有必要，应予以注意和调查。 警告    ：表示系统执行过程中发生的错误。这些消息通常会突出显示需要解决并可能影响系统功能的问题。 ERROR 在适当的级别进行日志记录有助于了解系统的行为、识别问题并有效地解决问题。 当涉及到您构建的系统组件时，我们建议您花一些时间来定义有用的日志级别集。了解每个日志级别的消息中应包含哪些类型的信息，并一致地使用日志级别。 稍后，我们将讨论如何处理第三方应用程序，您无法控制日志级别。我们还将研究您控制的遗留应用程序，但它们过于庞大而无法迁移到标准日志级别。 结构化日志与非结构化日志 结构化日志中的条目具有明确定义的格式，通常为键值对或 JSON 对象。这允许一致且机器可读的日志条目，从而更容易以编程方式解析和分析日志数据。 结构化日志记录支持高级日志查询和分析，使其在大型系统中特别有用。 另一方面，非结构化（自由格式）日志记录以更易于理解的格式捕获消息，没有预定义的结构。这种方法允许开发人员更自然、更灵活地记录消息。 然而，以编程方式从结果日志中提取特定信息可能非常具有挑战性。 在结构化日志和非结构化日志之间进行选择取决于您的具体需求以及系统的要求和约束。如果您预计需要高级日志分析或与日志分析工具集成，结构化日志可以提供显着的好处。 但是，如果您需要的只是简单性和可读性，那么非结构化日志可能就足够了。 在某些情况下，还可以使用混合方法，即对重要事件使用结构化日志，对更一般的消息使用非结构化日志。 对于大型系统，您应该尽可能倾向于结构化日志记录，但请注意，这会为您的规划增加另一个维度。对结构化日志消息的期望是同一组字段将在系统组件中一致使用。这需要战略规划。 记录挑战 对于包含多个组件的系统，每个组件很可能都有自己的模型来管理其日志。让我们回顾一下这带来的挑战。 不同的目的地 组件将记录到不同的目的地——文件、系统日志、stdout 或 stderr。在分布式系统中，收集这些分散的日志以进行有效利用是很麻烦的。 为此，您需要采用多样化的日志收集方法，例如使用来自 Sumo Logic 的 和 。 已安装收集器 托管收集器 不同的格式 某些组件将使用非结构化、自由格式的日志记录，不遵循任何特定格式。同时，结构化日志可能更有条理，但具有结构化日志的组件可能会采用完全不同的字段集。 统一从各种日志和格式中获得的信息需要正确的工具。 日志级别不一致 系统中的组件可能使用不同范围的日志级别。即使您将所有日志消息合并到集中式日志系统中（正如您应该的那样），您也需要处理所有日志级别的并集。 出现的一项挑战是何时应该对不同的日志级别进行相同的处理。例如，一个组件中的错误可能与另一组件中的严重错误相同，需要立即升级。 当不同组件中的相同日志级别意味着不同的事情时，您将面临相反的挑战。例如，一个组件中的 INFO 消息对于理解系统状态可能至关重要，而在另一组件中它们可能过于冗长。 日志存储成本 大型分布式系统会积累大量日志。收集和存储这些日志并不便宜。云中与日志相关的成本可能占系统总成本的很大一部分。 应对这些挑战 虽然大型分布式系统中的日志记录面临着巨大的挑战，但可以通过以下一些实践找到解决方案。 聚合您的日志 当您运行分布式系统时，您应该使用集中式日志记录解决方案。当您在系统中的每台计算机上运行日志收集代理时，这些收集器会将所有日志发送到您的中央可观察平台。  Sumo Logic 始终专注于 ，在日志聚合方面是同类中最好的。 日志管理和分析 走向统一格式 如果您想要关联日志数据以进行跨应用程序和组件的分析和故障排除，那么处理不同格式的日志是一个大问题。一种解决方案是将不同的日志转换为统一的格式。 此任务的工作量可能很高，因此请考虑分阶段执行此任务，从最重要的组件开始，然后逐步完成。 为您的应用程序建立日志记录标准 对于您自己的应用程序，努力建立一种标准日志记录方法，该方法采用一组统一的日志级别、单一的结构化日志格式和一致的语义。 如果您还有遗留应用程序，请评估与迁移它们以遵守您的标准相关的风险和成本级别。 如果迁移不可行，请像对待第三方应用程序一样对待您的旧应用程序。 丰富第三方来源的日志 丰富来自第三方来源的日志涉及使用来自外部系统或服务的上下文信息来增强日志数据。这可以更好地理解日志事件，有助于故障排除、分析和监控活动。 为了丰富您的日志，您可以集成外部系统（例如 API 或消息队列）来获取与日志事件相关的补充数据（例如用户信息、客户详细信息或系统指标）。 管理日志量、频率和保留 仔细管理日志量、频率和保留对于高效的日志管理和存储至关重要。 ：监控生成的日志量可帮助您控制资源消耗和性能影响。 量 ：根据事件的严重性和所需的监控级别确定记录频率。 频率 ：定义适合合规性要求、操作需求和可用存储的日志保留策略。 保留 ：定期归档或清除较旧的日志文件以有效管理日志文件大小。 轮换 ：压缩日志文件以减少存储要求。 压缩 基于日志的指标 通过分析日志数据得出的指标可以深入了解系统行为和性能。使用基于日志的指标有其优点和挑战。 好处 ：基于日志的指标提供对系统事件的详细而精细的洞察，使您能够识别模式、异常和潜在问题。 精细洞察 ：通过利用基于日志的指标，您可以全面监控系统，了解与可用性、性能和用户体验相关的关键指标。 全面监控 ：基于日志的指标提供可用于趋势分析、容量规划和性能优化的历史数据。通过检查一段时间内的日志趋势，您可以做出数据驱动的决策，以提高效率和可扩展性。 历史分析 ：您可以根据您的应用程序或系统定制基于日志的指标提取，重点关注对您的需求最有意义的事件和数据点。 灵活性和定制 挑战 ：由于所有组件中可用的指标集非常庞大，并且捕获所有指标是没有意义的，因此确定要捕获并从日志中提取哪些指标可能是一项复杂的任务。 定义有意义的指标 这种识别需要深入了解系统行为并与您的业务目标紧密结合。 ：解析日志以提取有用的指标可能需要专门的工具或自定义解析器。如果日志是非结构化的或从一个组件到下一个组件的格式不一致，则尤其如此。 数据提取和解析 设置此功能可能非常耗时，并且随着日志格式的更改或新日志源的出现，可能需要维护。 ：处理基于日志的指标的延迟可能会导致过时或不相关的指标。在大多数情况下，您需要一个能够对传入数据执行快速、实时处理的平台，以便有效地利用基于日志的指标。 实时分析的需求 ：持续捕获组件分析指标会给系统资源带来额外的压力。您需要在捕获足够的基于日志的指标和维持足够的系统性能之间找到良好的平衡。 性能影响 ：日志数据通常包含大量噪声和不相关信息，对有意义的指标没有贡献。仔细的日志过滤和标准化对于将数据收集集中在相关事件上是必要的。 数据噪声和不相关性 长期日志保留 在集中式系统中进行日志聚合之后，您仍然需要考虑长期日志保留策略。让我们讨论一下该领域的关键问题。 您应该将日志保留多长时间？ 您应该保留日志多长时间取决于几个因素，包括： ：某些日志（例如访问日志）可以在短时间内删除。其他日志（例如错误日志）可能需要保留较长时间，以备故障排除所需。 日志类型 ：医疗保健和金融等行业的法规要求组织将日志保留一定时间，有时甚至几年。 监管要求 ：您的公司可能有规定日志应保留多长时间的政策。 公司政策 ：如果您的日志很大，您可能需要更频繁地轮换或删除它们。 日志大小 ：无论您将日志存储在何处（本地还是云端），您都需要考虑存储成本。 存储成本 如何降低旧日志的详细程度和成本？ 当然，删除旧日志是降低存储成本的最简单方法。但是，这可能有点严厉，有时您可能希望保留旧日志中的信息。 当您想要保留旧日志中的信息，同时又想要经济高效时，请考虑采取以下一些措施： ：对于生成许多重复日志语句的组件，您可能只提取语句的子集（例如，每 10 个语句中的 1 个）。 日志下采样 ：对于包含大消息的日志，您可能会丢弃一些字段。例如，如果错误日志包含错误代码和错误描述，则只需保留错误代码即可获得所需的所有信息。 修剪日志 ：您可以压缩旧日志并将其移动到更便宜且不易访问的存储（尤其是在云中）。对于需要存储多年以满足法规遵从性要求的日志来说，这是一个很好的解决方案。 压缩和归档 结论 在本文中，我们研究了如何在大型系统中充分利用日志记录。 尽管这些系统中的日志记录提出了一系列独特的挑战，但我们已经研究了这些挑战的潜在解决方案，例如日志聚合、将日志转换为统一格式以及使用第三方来源的数据丰富日志。 日志记录是可观察性的关键部分。通过遵循本文中概述的实践，您可以确保有效管理日志，从而能够解决问题、识别问题并深入了解系统的行为。 而且您可以在保持伐木成本的同时做到这一点。 也发布 在这里

2022 - HackerNoon Contributor of the Year - Engineering

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Jobs

2022 - HackerNoon Contributor of the Year - Kubernetes

2022 - HackerNoon Contributor of the Year - Npm

2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Jobs

Nominated for 2022 - HackerNoon Contributor of the Year - Npm

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering

該音頻是用故事的原始語言製作的！

太長; 讀書

如何从日志中提取最大值

如何从日志中提取最大值

About Author

註釋

標籤

这篇文章刊登在

Related Stories

看不见的层面：为什么用户访谈是不可替代的资产

从论坛到信息流：社交媒体算法如何塑造数字互动

成功云迁移的完整指南：策略和最佳实践

扬帆起航：利用数据湖开发生产级 RAG 应用程序

看不见的层面：为什么用户访谈是不可替代的资产

从论坛到信息流：社交媒体算法如何塑造数字互动

成功云迁移的完整指南：策略和最佳实践

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps