Codex日志Bug一年写穿1TB固态？工程傲慢的代价

看完了，不得不说这个数据量是真的离谱。21天37TB，合着一天快2TB的日志量？这已经不是“没做压力测试”的问题了，是压根没想过logs也能把盘写穿吧。我其实挺好奇的，Codex这种级别的项目，日志框架总该有轮转策略吧？哪怕默认的rolling file appender配个大小限制，也不至于搞成这样。说到底还是那句老话——开发时“我能跑就行”，上线后“怎么挂了”。

不过话说回来，我也见过不少团队把日志当“廉价监控”用，TRACE级别随便开，然后扔给ELK去消化。问题是本地开发环境没人管，一上生产就炸。我猜Codex那边大概率是有人开了debug或者trace模式部署上去就没关，再加上没有写保护或者磁盘配额，直接酿成事故。这其实挺典型的，大厂内部工具反而容易出这种“低级错误”，因为大家都默认基础架构是稳固的，没人会想到有人能写出这种级别的日志洪流。

另外你提到“LLM工具越来越忽略基础设施防御性编程”，我深有同感。很多AI项目的开发节奏太快，模型输出优先，结果日志、限流、熔断这些“不性感”的东西全被搁置。等到用户量上去，或者跑个什么长链任务，一个没加缓冲的日志写操作就能把SSD寿命吃光。我甚至见过有人把模型推理的中间结果全部写进日志的，那文件大小直接起飞。

说到这，我倒想问问，有没有人知道Codex后来是怎么修的？是加了个日志级别的远程开关，还是直接上了异步日志加背压？这种问题光改配置不够，得从架构层堵住漏洞才行。不然今天写穿固态，明天可能就写崩网络IO了。

这种问题我太熟了，之前我们团队有个内部工具也是debug日志没做限流，上线三天就干废了一块512G的SSD。其实加个写入速率限制和日志轮转也就是半小时的活，但就是没人愿意在快速迭代里停下来做这种“不显眼”的防御性设计。想问问你们后来是怎么推动团队把这种基础设施层的检查加到发布流程里的？我们还在靠出事故长记性。

这问题说白了就是典型的“开发环境和生产环境脱节”。本地测的时候日志量小，一上线上并发流量直接爆炸，而且Level::TRACE这种级别默认开启还不限流，摆明了没考虑过写入带宽和磁盘寿命。更离谱的是，LLM工具现在普遍依赖日志做调试，但连个最基础的轮转策略和写入阈值告警都没做，这已经不是傲慢的问题了，是整个工程交付流程里缺少了最起码的SLA评审环节。

这问题我太熟了，之前做边缘AI设备的时候就踩过类似坑——日志库默认全量输出，上线三天TF卡写报废。其实加个日志轮转和写入速率限制就几行代码的事，但团队赶版本基本没人会主动去碰log4cplus的配置。说到底还是测试环境太理想化，没拿消费级SSD跑过72小时持续写入的破坏性测试，这种“能跑就行”的心态在AI产品里确实要命。

确实，这种问题说白了就是没把基础设施当回事。我去年在团队里也踩过类似的坑，不过是日志轮转配置写错了，导致单个日志文件涨到200GB，直接把测试环境的磁盘怼爆了。当时排查的时候还以为是SSD坏了，结果一看日志文件时间戳，好家伙，24小时写了将近2TB。

Codex这个案例更离谱，37TB 21天，平均每天1.76TB，这写入量别说消费级固态了，企业级P5800X这种傲腾盘也扛不住一年。而且我猜他们大概率是用了默认的log4j或者类似库的配置，没做任何大小或时间的滚动策略。其实加个maxFileSize和maxBackupIndex，或者直接上异步日志+限流，这种问题根本不会出现。

说到“能用就行”的哲学，我深有体会。现在很多AI项目团队里，算法和工程是脱节的。算法丢个模型过来，工程侧急着上线，日志这种“边角料”没人认真review。结果就是线上出问题，连排查的日志都找不到，或者找到了也读不了——因为文件太大打不开。

另外我补充一点，TRACE级别的日志在生产环境默认就该关掉，这应该是工程常识。除非你明确知道自己在调试某个特定模块，而且做好了回收机制。Codex这个情况，我怀疑连日志级别的动态调整都没做，不然不可能在用户侧暴露这么低级的配置。

说到底，这不是技术能力问题，是工程流程里少了几个关键检查点：有没有写入量预估？有没有磁盘监控告警？有没有日志系统的熔断机制？如果这三个里面任何一个做了，都不至于让用户发现这个bug。傲慢的代价就是，让用户帮你做压力测试。