运行在 RAM 上的 VPN 并不等于没有日志

从只读镜像启动、把运行状态放在 tmpfs 上的 VPN 服务器是一种真实且有用的设计。它也很容易被描述成“没有日志”，但设计本身并不能证明这一点。存储位置决定副本住在哪里；收集与保留决定记录是否存在，而重启只影响前者。把这两件事分开，就是全部审查工作。

先列出所有可能写入状态的进程：守护进程、认证服务、日志系统、任何监控代理，以及管理工具。

存储与收集是两个不同的问题

每个写入者都有自己的目的地和自己的策略。VPN 守护进程写状态文件，认证后端写账户事件，日志系统收集服务输出，监控代理则把指标发往完全不同的地方。让其中一处随重启消失的设计，对其余三处只字未提。沿着每个写入者追到它的目的地，并记下那个目的地是否根本不在这台机器上。

应用专属文件、上传的诊断信息以及外部服务也需要同样对待。本地没有熟悉的日志，并不能证明连接或账户记录不存在；它只证明你还没找到它们去了哪里。

tmpfs 不是保证

Linux 的 tmpfs 不是物理内存盘。内核文档明确写道，在挂载允许时页面可以被写入交换分区，因此 tmpfs 文件可能在应用从未复制的情况下落到磁盘上。mount 会显示是否有由交换分区支撑的 tmpfs 在使用，而其他内存文件系统的行为又不一样。请阅读实际的挂载选项，而不是假定 /run 下的路径就意味着易失性。

然后盘点那些以人们容易忘记的方式在重启后仍然存在的东西：持久的上层、挂载的存储、休眠镜像、崩溃转储，以及整个 VM 的基础设施快照。每一项都可能是你以为只存在于瞬时的状态的去处。这份清单是用来核查的，而不是断言每台主机都具备全部。

Journald 有两个目的地和一个转发器

Journald 很清楚地展示了这种分离。易失存储把条目放在 /run/log/journal 下，持久存储放在 /var/log/journal 下，自动模式则在两者之间选择；生效的模式来自正在运行的系统，而不是镜像的描述。切换到易失模式并不会删除已经持久写入的内容。转发也是独立的通道：即使某项存储设置不在本地保留任何内容，也可以把消息交给另一个目标。

从日志本身或其配置文件读出实际生效的模式，然后单独检查转发目标，因为一项设置并不控制另一项。

什么必须经受重启

无状态运行时支持可重复的替换，但它需要为服务无法凭空生成的配置、授权和恢复材料提供有意的来源。为了消除本地写入而丢掉唯一可用的注册或撤销状态，是一笔糟糕的交易，而且很常见。要有意决定什么必须保留下来，然后验证它确实保留了。

同样的道理适用于运维记录。决定安全和运维管理真正需要哪些事件，并给出有依据的范围和保留期，其余则尽量最小化。最小化并不等于关掉所有诊断。

把实际生效的存储和转发配置与几个无害事件对照检查，然后重启或更换机器，再看还剩下什么、服务从哪里恢复了状态。