云原生架构的日志监控要求现代 Web 应用程序采用与传统应用程序略有不同的方法。部分原因是应用程序环境要复杂得多，包括从微服务中获取数据、使用 Kubernetes 和其他容器技术，以及在许多情况下集成开源组件。所有这些复杂性使得有必要重新考虑聚合、分析和存储应用程序日志的策略。
日志是查看应用程序健康状况的好方法，特别是如果您想了解更多关于那些只存在于瞬间的服务。但是，新的工具和技术也为您提供了前所未有的数据量，使得过滤噪音变得更加困难。在本文章中，我们将探讨云原生架构日志监控的一些挑战，并描述帮助您为应用程序定义有效策略的四个步骤。
云原生环境中日志监控的最佳实践包括使用开放标准、实施中央日志管理解决方案以及避免在日志中收集个人信息。
在云原生架构中采用错误的日志管理方法可能会限制您有效响应问题的能力，或者导致您被特定供应商锁定。
云原生架构的日志监控有哪些挑战?从历史上看，日志监控更容易，因为大多数应用程序日志具有一致的结构和格式。转换这些数据并聚合信息很简单，允许团队收集和分析不同的日志，并将其分析为环境性能的单一视图。在云原生世界中，情况不再如此。
团队今天面临的一些主要挑战包括：
规模——由于云原生架构中发生的微服务、容器、基础设施层和编排的数量，团队最终很容易处理数十万个单独的日志。临时存储——在容器化环境中，日志通常会进入内部文件系统，该文件系统可能仅在应用程序实例化时才存在。团队需要将日志数据收集到持久存储中，以便稍后分析性能并解决问题。日志多样性——云原生应用程序从应用程序和服务器生成大量数据，但也使用云服务、编排器和 API 来正常运行。这些组件中的每一个都会生成有价值的信息，您需要从不同的实例、节点、网关、主机或代理中收集这些信息。供应商锁定——如果您只使用特定供应商的日志工具，您可能会被锁定在该环境及其专有的日志管理解决方案中。在多云环境中，如果您为不同的服务提供商使用不同的日志记录工具，这可能会妨碍您监控性能、解决问题和了解依赖关系的能力。如果您从一开始就采取正确的方法，那么通过智能模型克服这些挑战是可能的。
云原生架构中日志监控的智能模型以下是您应该在日志监控策略中包含的一些最佳实践。
1. 实施日志管理解决方案由于您的环境中生成的日志数据的多样性，最好的选择是实施一个日志管理解决方案，将所有日志统一到一个集合中。从集中式系统管理日志可以将所有日志自动聚合到一组可管理的数据中以供进一步分析。可观察性平台[2]使您可以使用简化的流程来可视化和分析来自应用程序、基础架构和最终用户的数据，以收集和存储所有日志数据。
2. 应用日志采用开放标准OpenTelemetry[3]等开放标准可帮助您避免供应商锁定，并使用供应商中立的 API 优化日志监控流程。OpenTelemetry 将之前的两个标准(OpenTracing 和 OpenCensus)组合成一个工具、SDK 和 API 集合，使您能够检测代码、生成、收集和导出日志数据、跟踪和指标。
借助广泛的语言支持和与流行框架的集成，为您的应用程序遥测采用开放标准还将简化您的日志监控过程[4]。OpenTelemetry 目前以多种语言处于测试阶段，免费，并得到各种行业领导者的[5]支持。
3. 采用最新的跟踪和日志记录技术从可观察性平台获得集中式日志管理解决方案后，请考虑使用eBPF 等新技术[6]来收集数据。此外，寻找提供无代码界面的工具来可视化您的数据和自定义日志解析器，使您能够轻松地将日志信息转换和塑造成可用的格式。
通过改进的日志生成、收集和可视化功能，您可以：
通过跟踪整个环境中的每个服务请求来排除应用程序性能故障。改进您的容量规划、负载平衡和应用程序安全性。将事务数据与操作数据相关联，以查看每个请求期间发生的情况。摄取信息并扩展日志监控以检测数据中的模式。4. 只记录您需要的内容最后，日志需要包含必要的元数据，以便在您分析性能时提供足够的上下文。使用日志管理解决方案，生成日志很容易，但如果信息不是立即有用，则不会提供任何好处。日志信息应该可以帮助您了解应用程序中正在发生的事情或快速做出决定。
请记住通过对所有私人信息使用匿名标识符从日志中排除敏感数据。使用此日志管理最佳实践指南[7]来制定策略并确保避免云原生日志监控中的常见陷阱。
