今日のCPU使用率が100％のサーバーの問題が発生しました。サーバーを元に戻すためにハードリセットを行う必要がありましたが、今は高負荷の原因を特定しようとしています。
残念ながら、Journalctlは再起動するまでログ情報を表示しません。これで、journalctl --verify破損したファイルが表示されました。これが問題に関連していると仮定していますが、破損する前のログをどのように表示できますか？journalctl --since yesterday2日前から試してみましたが、まだ成功していませんでした。
答え1
比較的小さなログパーティションを作成し、オプションとマウントパスに追加します/etc/fstab。sync/var/log
...<previos fstab lines>...
UUID=<UUID of created partition> /var/log ext4 rw,sync 0 0
これにより、システムは書き込みをキャッシュせずにブロックデバイスに直接ログを書き込むので、ログメッセージは発生したとおりに記録され、再起動時に削除されません。ただし、同期ログの書き込みはIO集約的であり、本番サーバーでの長期使用には適していないことに注意してください。
答え2
まず腐敗（検知による腐敗）について話してみようjournalctl --verify。
ディスク形式に冗長性がないため、ログの破損は回復できません。また、場合によっては、ファイルの途中での破損により、「尾」を読み取ることができなくなります（実際には別のトピックです）。ただし、journald異常終了のログファイルは絶対に記録してはならないため、異常終了による被害は無害です。
しかし、これは実際には関係ありません。
最後の起動ログを表示するために使用できますjournalctl -b -1。
あなたの場合の問題は、ブロックI / Oが通常後書きキャッシュされるため、ハードウェアがリセットされるまで最後のNエントリを見ることができないことです。 I/O を同期する以外にできることはあまりありません。