一.背景

观察系统的运行状态，排查疑难问题，日志作为一种历史悠久的可观测手段，始终扮演着不可替代的角色。

科学的本地日志管理策略，不仅能在本地保留更完整历史记录，最小化性能开销，并且能为日志采集和后续分析提供便利。然而在实际运维中，我们时常遇到反例，这类管理缺陷带来的采集现在对于主流采集工具（LoongCollector（原 iLogtail）、Filebeat、Fluentbit、Vector、OpenTelemetry Collector）均无法完美解决，唯有从源头解决才是最佳实践。

我们将沉淀自阿里云云原生可观测团队的经验总结成本文，希望给大家一些启发，一起让日志更好地为大家服务。

二.反模式

1. 使用 copy truncate 模式轮转日志，因两个动作非原子并创建新文件，可能导致日志丢失或重复采集

使用 logrotate 的 copy truncate 模式轮转日志的原理是先复制原日志文件，然后截断原文件。这种方式存在以下问题：

a. copy 动作产生的新文件可能被当作新的内容重复采集。因为文件系统的 inode 变化，采集器可能无法正确识别这是轮转后的旧文件。

b. copy 和 truncate 之间产生的日志可能丢失。在这两个操作之间有一个时间窗口，此时写入的内容既不在复制的文件中，又会被截断操作清除。

c. truncate 操作可能导致文件大小变小和头部内容变化，缩小文件或改变文件头部签名会导致采集器误判为新文件，造成重复采集。

因此，copy truncate 模式可能导致日志重复采集、内容丢失或不一致的问题。

推荐使用 create 模式进行日志轮转，即创建新文件并重命名旧文件，这样可以保证文件的完整性和连续性。如果无法避免，请在配置采集配置时使用精确的路径名。

2. 使用 NAS、OSS 作为日志存储，因元信息不一致和 ls 性能低，可能导致日志采集截断或停止

网络附加存储(NAS)通常采用基于最终一致性的一致性模型，这在分布式系统中是常见的设计。在实时采集场景下，这可能导致以下问题：

a. 文件元信息与实际内容不一致。由于最终一致性，文件大小等元数据可能先于实际内容更新。

b. 读取到文件空洞。当元信息显示文件已增大，但实际内容尚未同步时，读取操作可能返回 \0 字符（文件空洞）。

c. 数据延迟。写入操作的结果可能不会立即对读取操作可见，导致采集延迟。

d. 数据丢失。由于 NAS 不支持 inotify 并且 list 性能低下，因此文件可能无法被发现，导致数据丢失。

这些问题可能导致采集到的数据与最终内容不一致。

建议使用 EBS，自建机器使用本地磁盘，以保证日志读写的效率和一致性。如无法避免，请在消费端做好异常日志的兼容逻辑。

3. 多进程写日志，因数据互相覆盖，可能导致采集到的数据不完整

多进程并发写入同一日志文件是一种常见但不推荐的做法，它可能导致以下问题：

a. 文件内容交叉。多个进程的写入可能相互交叉，导致日志条目混乱。

b. 采集不完整。当文件发生写入事件时，采集器开始采集数据。但如果采集过程中其他进程继续写入，这些新写入的内容可能被跳过。

c. 文件锁争用。多进程写入可能导致文件锁争用，影响写入性能和可靠性。

这种模式可能导致采集到的数据不完整且与文件的最终内容不一致。

推荐多进程写入各自不同文件，这样可以保证日志的完整性和顺序性。如无法避免，请在消费端做好异常日志的兼容逻辑。

4. 创建文件空洞释放日志文件空间，因改变文件签名和内容，可能导致日志重复采集或数据丢失

通过在文件头部创建空洞来释放日志文件空间是一种存在风险的做法，原因如下：

a. 文件签名改变。LoongCollector（原 iLogtail）为避免 inode 复用漏采数据，额外使用文件头部的内容作为文件唯一性的判断依据。创建空洞可能改变这个签名，导致采集器误判为新文件。

b. 数据完整性问题。创建空洞实际上是用 \0 字符替换了原有内容，可能导致重要的历史日志丢失。

c. 文件系统碎片化。频繁创建空洞可能导致文件系统碎片化，影响读写性能。

这种做法可能导致数据重复采集和历史数据丢失。

推荐使用标准的日志轮转机制来管理日志文件大小，如使用 logrotate 工具定期轮转日志文件，这样可以保证日志的完整性和可追溯性。如无法避免，建议使用 fallocate 而非 truncate 或 dd，并在消费端做好异常日志的兼容逻辑。

5. 频繁覆盖写文件，因文件内容频繁变化，可能导致采集数据不完整或不一致

频繁覆盖写整个日志文件是一种不安全的日志管理方式，可能导致以下问题：

a. 文件元信息与内容不一致。在覆盖过程中，文件大小等元信息可能先于实际内容更新，导致采集器读取到不完整或不一致的内容。

b. 数据丢失风险。如果在日志采集过程中发生覆盖写入，可能导致采集读取到的数据内容错乱或丢失。

c. 历史数据难以保留。频繁覆盖会导致无法保留历史日志，不利于问题追溯和分析。

这种做法可能导致采集到的内容与文件最终内容不一致，或完全丢失文件内容。

建议采用追加写入（append）的方式记录日志，并配合日志轮转机制管理文件大小。如无法避免，请在消费端做好异常日志的兼容逻辑。

6. 使用 vim 编辑文件保存，因创建新文件替换原文件，可能导致日志重复采集

使用 vim 编辑并保存文件时，vim 的保存机制可能导致以下问题：

a. inode 变化。vim 创建新文件替换原文件时，新文件的 inode 与原文件不同，可能导致采集器误判为新文件。

b. 文件签名改变。新文件的头部内容可能与原文件不同，改变了文件签名，导致采集器无法正确识别。

c. 文件内容丢失。当 vim 替换文件时，写入程序可能没有切换到新保存日志文件，可能导致日志内容丢失。

这种编辑方式可能导致日志重复采集或数据丢失。

如仅需查看日志，建议使用 less、grep 等只读工具。如无法避免，请在消费端做好去重和异常处理的逻辑。

三.总结

日志是系统运行的“黑匣子”，其管理质量直接影响故障排查效率与系统可靠性。通过规避本文提到的反模式，遵循使用日志库轮转、本地盘写入、单线程追加等最佳实践，可显著降低日志采集风险，提升可观测性能。