Fessの開発版に、ログの削除境界をUTCで計算する修正がマージされました。日本時間で動くサーバーでは、指定した保持日数より9時間早くログを削除してしまうケースへの対応です。ログを何日残すかの設定と、定期ジョブによる削除時刻を合わせて確認しましょう。
クリック・お気に入りログを削除対象へ加えた変更は以前の記事で紹介しています。今回は削除する日時の境界に関する修正です。
対応状況と適用条件
問題は、JVMの標準タイムゾーンがUTC以外で、保持日数を設定してLog Purgerがログ削除を行う場合に関係します。Asia/Tokyoでは、UTC保存の日時と比較する境界を日本時間の値で送っていたため、削除対象が9時間先まで広がっていました。修正後は境界をUTCで計算します。
保持期間の初期値は削除しない設定
管理画面の「システム > 全般」にあるログ削除日数は、初期値が-1です。-1の場合は期限による削除を行わず、保持し続けます。
「以前の検索ログを削除」の日数は、検索ログだけでなくクリックログ、お気に入りログ、チャットログにも使われます。「以前のユーザーログを削除」はユーザー情報に適用されます。「以前のジョブログを削除」にも初期値-1がありますが、今回のUTC修正は検索・クリック・お気に入り・チャット・ユーザー情報の5種類が対象です。
7日保持を日本時間で運用する例
日本時間2026年10月12日09:00、つまりUTCの2026年10月12日00:00に、7日保持の削除を実行する場合を考えます。
- 修正前に送られる境界: UTCとして解釈される2026年10月5日09:00
- 修正後に送られる境界: UTCの2026年10月5日00:00
修正前は、実際にはまだ7日経過していない9時間分も対象になります。修正後は現在時刻から7日を引いた境界以前を削除します。「7日前の日付の日本時間00:00」で区切る仕組みではなく、実行時刻から日数を引いた判定です。ユーザー情報は更新日時、検索・クリック・チャットは要求日時、お気に入りは作成日時が比較対象になります。
運用で確認すること
まず各保持日数と「システム > スケジューラ」のLog Purgerの実行設定を確認します。例えば検索ログ側を7日へ変更すると、クリック・お気に入り・チャットにも同じ日数が適用されるため、分析用途に必要な期間を先に決めてください。
修正はこれから行う削除の境界を変えるもので、既に削除されたログを復元するものではありません。保持設定を変える前に、必要なログを管理画面のバックアップなどで別途保管します。そこで取得するログの*.ndjsonは、管理画面からアップロードして復元する形式ではありません。
この保持設定はOpenSearch上のログを扱います。searchlog.logなどのファイルのローテーション・保管期間は別の設定なので、ディスク使用量を管理するときは両方を確認してください。