Elastic 与 OpenTelemetry 合作改进 filelog 接收器

作为 OpenTelemetry (OTel) 中最新推出的通用可用信号，日志支持在功能范围和成熟度方面目前落后于跟踪和指标。在 Elastic，我们在日志用例及其带来的挑战方面拥有多年的丰富经验。为了推进 OpenTelemetry 的日志功能，我们专注于增强其日志功能。

在过去的几个月中，我们利用作为 Filebeat 的维护者的专业知识，处理了 filelog 接收器 在 OpenTelemetry Collector 中的功能，以帮助改进和扩展其潜力。我们的目标是为 OpenTelemetry 日志功能的演进做出有意义的贡献，确保它们满足强大的可观察性所需的高标准。

具体而言，我们专注于验证接收器在过去 Filebeat 中给我们带来麻烦的案例和方面是否得到了很好的覆盖——例如故障转移处理、自身遥测、测试覆盖率、文档和可用性。基于我们的探索，我们开始与 OTel 项目的维护人员进行有见地的对话，分享我们的想法以及我们经验中可能有所帮助的任何建议。此外，我们还开始提交 PR 以添加文档、进行增强、改进测试、修复错误，甚至实现全新的功能。

在这篇博文中，我们将为您提供我们迄今为止与 OpenTelemetry 社区合作完成的工作的预览，以及我们继续探索改进 OpenTelemetry Collector 以进行日志收集的方法的下一步计划。

增强 filelog 接收器的遥测

可观察性工具与其他任何软件组件一样，因此，需要像监控其他任何软件一样进行监控，以便能够调试问题和调整相关设置。特别是，filelog 接收器的用户会想知道它的性能如何。重要的是，filelog 接收器会发出足够的遥测数据，以用于常见的故障排除和优化用例。这包括足够的日志记录和可观察的指标，以提供对 filelog 接收器内部状态的深入了解。

虽然 filelog 接收器已经提供了一组良好的自身遥测数据，但我们发现了一些需要改进的地方。特别是，我们贡献了在关键事件（如发现、移动或截断日志文件时）发出自身遥测日志的功能。另一项贡献包括关于 filelog 接收器内部状态的 可观察指标，包括有多少文件被打开和正在被收集。您可以在相应的跟踪问题中找到更多信息。

改进 Kubernetes 容器日志解析

filelog 接收器已经能够解析 Kubernetes 容器日志一段时间了。但是，要正确解析来自 Kubernetes Pod 的日志，需要进行相当多的配置才能处理不同的运行时格式并提取重要的元信息，例如

, 等等。考虑到这一点，我们建议将这些复杂的配置抽象为更简单的特定容器解析器，并将此新功能贡献给 filelog 接收器。有了这个新功能，设置 Kubernetes 的日志收集变得更加容易 - 以前需要大约 80 行配置，而现在只需要 8 行配置。

您可以在相应的 OpenTelemetry 博客文章中了解有关新的容器日志解析器的更多详细信息。

评估测试覆盖率

从文件中收集日志可能会遇到不同的意外情况，例如重启、过载和错误情况。为了确保可靠且一致地收集日志，重要的是确保测试涵盖这些类型的情况。根据我们测试 Filebeat 的经验，我们评估了现有 filelog 接收器的测试，并考虑了这些情况。虽然大多数用例和场景都已经过充分测试，但我们发现了一些需要改进测试的场景，以确保可靠地收集日志。
在本博文创建时，我们正在努力贡献额外的测试，以解决已发现的测试覆盖率差距。您可以在 此 GitHub 问题中了解更多相关信息。

持久性评估

我们经常从 Elastic 的日志用户那里听到的另一个重要日志收集方面是故障转移处理能力和日志的传递保证。一些日志用例（例如审计日志）对传递保证有严格的要求。因此，重要的是 filelog 接收器提供可靠处理各种情况的功能，例如日志后端暂时不可用或 OTel Collector 意外重启。

总的来说，filelog 接收器已经具有相应的处理这种情况的功能。但是，有关如何通过实际示例设置可靠日志收集的用户文档是一个具有改进潜力的领域。

在这方面，除了验证持久性和偏移量跟踪功能外，我们还致力于改进相应的文档 1 2，并且还在就社区报告的问题进行协作，以确保日志的传递保证。

帮助用户自助

Elastic 在支持使用我们产品进行日志摄取的客户方面有着悠久而多样的历史。借鉴此经验，我们向 OpenTelemetry Collector 提出了几项文档改进建议，以帮助日志用户摆脱一些棘手的情况。

记录跟踪文件的结构

对于 filelog 接收器摄取的每个日志文件，它都需要跟踪已读取到文件中的位置，以便知道在向文件中添加新内容时从何处开始读取。默认情况下，filelog 接收器不会将此跟踪信息持久保存到磁盘，但可以配置为这样做。我们认为记录此跟踪文件的结构会很有用。当摄取意外停止时，查看此跟踪文件通常可以提供有关问题可能出在何处的线索。

符号链接目标更改的挑战

filelog 接收器会定期刷新其内存中应摄取的文件。这些刷新的发生间隔由

设置。在某些设置中，filelog 接收器摄取的日志文件是指向实际文件的符号链接。此外，这些符号链接可能会更新，以指向较新的文件。如果符号链接的目标在 filelog 接收器有机会刷新其内存之前更改了两次，它将错过第一次更改，因此不会摄取相应的目标文件。我们已经记录了这个极端情况，建议具有此类设置的用户应确保将其设置为足够低的值。

为接收器的 GA 提前规划 

最后但并非最不重要的一点，我们提出了使 filelog 接收器成为正式可用 (GA) 组件的话题。对于用户来说，能够依赖所使用功能的稳定性非常重要，因此不需要处理通过次要版本更新导致重大更改的风险。在这方面，对于 filelog 接收器，我们已经与维护者启动了第一项计划，以标记任何阻碍稳定性的问题，并使用

标签。一旦 OpenTelemetry 收集器达到版本我们将能够朝着特定接收器的 GA 努力。

结论

总的来说，OTel 的 filelog 接收器组件状态良好，为大多数日志收集用例提供了重要的功能。如果 filelog 接收器仍然存在较小的差距或需要改进的地方，我们很乐意贡献我们在 Filebeat 用例中的专业知识和经验。以上只是我们为帮助推进 OpenTelemetry 收集器，特别是日志收集，更接近稳定版本而做出的努力的开始。此外，我们很乐意帮助 filelog 接收器维护者进行组件的常规维护，因此，共同处理社区问题和 PR，共同制定组件的路线图等。

我们要感谢 OTel 收集器小组，特别是Daniel Jaglowski在 filelog 接收器上迄今为止的出色和建设性的合作！

请继续关注，了解更多关于我们未来在 OpenTelemetry 中的贡献和参与。