RAM 上の VPN ランタイムはログについて何も語らない

読み取り専用イメージから起動し、実行状態を tmpfs に置く VPN サーバーは、現実的で有用な設計です。それをログなしと説明するのも簡単ですが、設計はそれを裏付けていません。保存場所はコピーがどこに住むかを決め、収集と保持は記録がそもそも存在するかを決めます。再起動が影響するのは前者だけで、この二つを切り分けることがレビューのすべてです。

まず、状態を書き込めるすべてのプロセスを列挙することから始めます：デーモン、認証サービス、ジャーナル、監視エージェント、管理ツール。

保存と収集は別の問い

書き手ごとに保存先と方針が異なります。VPN デーモンは状態ファイルを書き、認証バックエンドはアカウントイベントを書き、ジャーナルはサービスの出力を集め、監視エージェントはメトリクスをまったく別の場所へ送ります。その一つを再起動で消す設計は、残り三つについて何も語っていません。各書き手をその保存先までたどり、保存先がそもそもマシン上にあるかを記録します。

アプリケーション固有のファイル、アップロードされた診断、外部サービスにも同じ扱いが必要です。見慣れたローカルログがないことは、接続やアカウントの記録がどこにもない証拠にはならず、まだ行き先を見つけていない証拠です。

tmpfs は保証ではない

Linux の tmpfs は物理的な RAM ディスクではありません。カーネルのドキュメントは、マウントが許せばページをスワップに書き込めることを明記しており、つまり tmpfs のファイルは、アプリケーションが一度もコピーしなくてもディスクに到達し得ます。mount はスワップ対応の tmpfs が使われているかを示し、他のメモリファイルシステムはさらに別の振る舞いをします。/run 配下のパスが揮発性を意味すると決めつけず、実際のマウントオプションを読んでください。

次に、人が忘れがちな形で再起動を生き延びるものを棚卸しします：永続的なオーバーレイ、接続ストレージ、ハイバネーションイメージ、クラッシュダンプ、VM 全体のインフラスナップショットです。どれも一時的だと思っていた状態の候補の保存先です。その一覧は確認すべきものであり、どのホストにもすべてがあるという主張ではありません。

Journald には二つの保存先と転送機能がある

Journald はこの分離をきれいに示します。揮発ストレージは /run/log/journal 配下に、永続ストレージは /var/log/journal 配下にエントリを保ち、自動モードはその間を選びます。有効なモードは実行中のシステムから決まり、イメージの説明からではなく、揮発に切り替えても、すでに永続的に書かれたものは消えません。転送も別の経路で、ローカルに何も残さない保存設定でも、メッセージを別の宛先へ渡せます。

一方の設定がもう一方を制御しないため、有効なモードはジャーナル自体かその設定ファイルから読み、転送先は別に確認します。

再起動を生き延びるべきもの

ステートレスなランタイムは繰り返し可能な置き換えを支えますが、サービスが発明できない設定・認可・復旧の素材については意図的な供給元が必要です。ローカル書き込みを消すために唯一機能している登録や失効の状態を失うのは悪い取引であり、よくある取引です。何を意図的に残すかを決め、実際に残ることを確認します。

同じ理屈は運用記録にも当てはまります。セキュリティとサービス管理が本当に必要とするイベントを、正当な範囲と保持期間とともに決め、残りは最小化します。最小化はすべての診断を止めることと同じではありません。

有効な保存と転送の設定をいくつかの無害なイベントと突き合わせ、その後マシンを再起動するか交換して、何が残り、サービスがどこから状態を回復したかを再確認します。