云原生之深入解析云原生架构的日志监控

云原生架构的日志监控要求现代 Web 应用程序采用与传统应用程序略有不同的方法。部分原因是应用程序环境要复杂得多，包括从微服务中获取数据、使用 Kubernetes 和其他容器技术，以及在许多情况下集成开源组件。所有这些复杂性使得有必要重新考虑聚合、分析和存储应用程序日志的策略。
日志是查看应用程序健康状况的好方法，特别是如果想了解更多关于那些只存在于瞬间的服务。但是，新的工具和技术也为您提供了前所未有的数据量，使得过滤噪音变得更加困难。
在本博客中，我们将探讨云原生架构日志监控的一些挑战，并描述为应用程序定义有效策略的四个步骤：
- 云原生环境中日志监控的最佳实践包括使用开放标准、实施中央日志管理解决方案以及避免在日志中收集个人信息。
- 在云原生架构中采用错误的日志管理方法可能会限制有效响应问题的能力，或者导致被特定供应商锁定。

从历史上看，日志监控更容易，因为大多数应用程序日志具有一致的结构和格式。转换这些数据并聚合信息很简单，允许团队收集和分析不同的日志，并将其分析为环境性能的单一视图。在云原生世界中，情况不再如此。
团队今天面临的一些主要挑战包括：
- 规模——由于云原生架构中发生的微服务、容器、基础设施层和编排的数量，团队最终很容易处理数十万个单独的日志。
- 临时存储——在容器化环境中，日志通常会进入内部文件系统，该文件系统可能仅在应用程序实例化时才存在。团队需要将日志数据收集到持久存储中，以便稍后分析性能并解决问题。
- 日志多样性——云原生应用程序从应用程序和服务器生成大量数据，但也使用云服务、编排器和 API 来正常运行。这些组件中的每一个都会生成有价值的信息，需要从不同的实例、节点、网关、主机或代理中收集这些信息。
- 供应商锁定——如果只使用特定供应商的日志工具，可能会被锁定在该环境及其专有的日志管理解决方案中。在多云环境中，如果为不同的服务提供商使用不同的日志记录工具，这可能会妨碍监控性能、解决问题和了解依赖关系的能力。
如果从一开始就采取正确的方法，那么通过智能模型克服这些挑战是可能的。

由于环境中生成的日志数据的多样性，最好的选择是实施一个日志管理解决方案，将所有日志统一到一个集合中，从集中式系统管理日志可以将所有日志自动聚合到一组可管理的数据中以供进一步分析。
可观察性平可以使用简化的流程来可视化和分析来自应用程序、基础架构和最终用户的数据，以收集和存储所有日志数据。

OpenTelemetry 等开放标准可以避免供应商锁定，并使用供应商中立的 API 优化日志监控流程。OpenTelemetry 将之前的两个标准（OpenTracing 和 OpenCensus）组合成一个工具、SDK 和 API 集合，能够检测代码、生成、收集和导出日志数据、跟踪和指标。
借助广泛的语言支持和与流行框架的集成，为应用程序遥测采用开放标准还将简化日志监控过程，OpenTelemetry 目前以多种语言处于测试阶段免费，并得到各种行业领导者的支持。

从可观察性平台获得集中式日志管理解决方案后，请考虑使用 eBPF 等新技术来收集数据。此外，寻找提供无代码界面的工具来可视化数据和自定义日志解析器，能够轻松地将日志信息转换和塑造成可用的格式。
通过改进的日志生成、收集和可视化功能，可以：
- 通过跟踪整个环境中的每个服务请求来排除应用程序性能故障；
- 改进容量规划、负载平衡和应用程序安全性；
- 将事务数据与操作数据相关联，以查看每个请求期间发生的情况；
- 摄取信息并扩展日志监控以检测数据中的模式。