容器化应用常把日志写到标准输出和标准错误，由容器运行时或节点采集器读取。这个模式简化了应用与日志平台的耦合，却不会自动限制磁盘增长，也不保证日志已抵达集中存储。可靠设计需要同时控制应用输出、采集路径、缓冲行为、本地轮转和远端保留，并监控每一段的积压和丢失。📚
建议每条日志包含时间戳、级别、服务名、实例标识、版本和请求关联标识，便于跨实例定位同一请求。结构化单行格式利于采集器解析。异常堆栈和多行日志需要确认采集器的拼接规则，否则一条异常可能被拆成多条记录，造成误判。不要把请求ID等高基数字段作为昂贵的索引标签；可保留为可检索字段。
日志输出应遵循数据最小化原则。密码、令牌、会话标识、完整请求体和不必要的个人信息不应进入日志。应用开发时应在输出边界做脱敏，并通过测试样例验证，而不是只依赖日志平台后处理。🔐
Docker日志驱动可以管理容器标准输出的读取和存储；也可以由节点代理读取日志并发送到集中平台。无论采用哪种方式，都应明确谁负责本地文件轮转、谁负责远端保留。若多个组件同时轮转同一文件，可能出现文件句柄仍指向旧文件、日志重复采集或遗漏。采集方案还应明确采集端不可达时的行为：阻塞应用写入、丢弃新日志、在本地缓存，还是达到缓存上限后覆盖旧数据。
本地磁盘预算可先用平均每日日志量 × 本地保留天数 × 实例数估算，并根据峰值流量、错误风暴和轮转开销增加空间余量。日志量随请求量变化时，应测量正常高峰和故障峰值，而不只用平均日的数字。节点磁盘容量还要留给镜像层、容器可写层和系统日志。📊
至少关注采集延迟、队列深度、发送失败数、丢弃数、重试次数、本地磁盘使用率和日志文件增长速度。若本地日志持续增长而远端没有数据，可能是采集进程未运行、权限不足、解析失败或网络出口受阻。若远端有数据但时间顺序异常，要检查时钟同步、时区字段和缓冲批次，而不是立即认为应用乱序。
只读命令docker inspect CONTAINER可检查容器配置的日志驱动；docker logs CONTAINER能读取部分本地日志，却不能证明集中平台已经收到全部记录。应从采集端指标和平台查询结果双向验证。🚦
运行排障日志和合规审计数据的保留目标可能不同。短期运行日志可以按容量和排障窗口设置保留；审计日志则需由组织策略确定访问控制、完整性和保留周期。远端保留不能替代采集链路的本地缓冲，本地缓存也不能替代长期归档。应明确容量满时保留最新记录还是优先保护关键级别日志，并评估是否会阻塞应用。
日志平台还要限制索引字段和写入速率。把每个请求ID、用户ID都作为独立标签，会迅速增加索引基数和查询负担。对于异常激增，应配置采样或限速策略，同时保留聚合计数，避免降噪后完全看不见故障规模。📈
容易误判：能够执行容器日志读取命令，只能证明本地有可读记录，不能证明远端采集完整。日志保留也不是备份；重要审计信息要有独立策略。🛡️
