处于运维岗位，最为头疼的情况便是线上系统突然间毫无预兆地崩溃了，然而在事后去查看日志之时，却惊异地发觉日志呈现出一片空白的状态。这样的状况不但使得故障复盘的进程陷入到了僵持不下的局面，更加表明我们对于系统的把控存在着尚未察觉的盲区。
“崩溃无记录”这般情形常常源自若干特定的问题。其一，日志级别设定得过高，进而忽略了ERROR级别之下的信息，致使一些关键信息没能被记录下来。其二，日志文件所在的磁盘满了，造成无法写入新的日志内容。其三，进程被诸如OOM Killer等机制瞬间终止，以至于来不及输出最后的信息。在容器环境当中，日志未配置持久化存储也是致使“崩溃无记录”的常见缘由。
在没有日志的情形下出现崩溃，其危害是极为巨大的。我们没办法精准地去定位根本原因，只能依靠猜测进而进行重启，然而问题有可能会再次发生爆发。这种状况致使故障复盘缺少依据，从而很难去制定出有效的预防措施。从安全方面来看，它还极有可能会掩盖住恶意攻击所留下的痕迹。
倘若要防止出现那种特别指定的情形，那就一定得切实保证日志系统自身拥有健壮性。得针对关键进程以及崩溃信号精心设定钩子，借由此来强行输出最后的状态。与此同时，可以选用独立的监视agent或者云平台日志服务，这样的话，就算主进程出现崩溃，也能够成功获取相关信息。而定期核查日志配置以及存储空间，这是最为基本的操作。
此外，针对于日志系统的维护工作，还务必予以重视好多数量、种类繁杂的细节之处。举例来说，需要确保日志记录具备精准无误的特点以及完整无缺的特性，接着对日志相关的数据开展加密方面的处理操作，以此来避免信息出现泄露这件事情的发生。并且，要构建健全完善的日志备份相关机制，从而防止数据出现丢失的状况。与此同时，持续不断地对日志系统的性能进行优化，让它能够在面临高并发这样的情形下，始终保持稳定的运行状态，进而持续不断地为系统的稳定运行作出非常有力的保障。
当你针对类似故障展开排查工作之际，另外还碰到过哪些令人头疼棘手的“无日志”情形呢？是否存在特别具备效力的工具或者排查此类故障的思路能够进行分享呀？
