Fessの設定系インデックスの再構築機能 

Fessをアップグレードする際、設定系インデックス（fess_config、fess_user、fess_log）のマッピングが変更されていることがあります。これまではマッピングの変更を手動で反映する必要がありましたが、管理画面のメンテナンス機能から簡単に再構築できるようにしました。

背景

Fessでは、検索ドキュメント用のインデックス（fess.YYYYMMDD）とは別に、設定情報を保存する設定系インデックスがあります。バージョンアップ時にマッピングの変更があった場合、設定系インデックスにも最新のマッピングを適用する必要があります。これまではOpenSearchの管理ツールなどを使って手動で対応する必要がありましたが、この作業を管理画面から実行できるようにしました。

再構築の仕組み

管理画面のメンテナンスページに「Rebuild Config Index」カードを追加しました。再構築は以下の手順で安全に実行されます。

  1. バックアップの作成: 対象インデックスのデータをバックアップ用インデックスにリインデックス
  2. インデックスの削除と再作成: 元のインデックスを削除し、最新のマッピングで再作成
  3. データの復元: バックアップからデータをリインデックスして復元
  4. エイリアスの再設定: エイリアスを再設定してサービスを継続
  5. 検証: ドキュメント数を検証し、不整合があれば自動でロールバック

再構築対象のインデックスは、fess_config、fess_user、fess_logの3種類から個別に選択できます。検索ドキュメント用のインデックス（DOC_INDEX）は対象外です。

デフォルトデータの読み込み

「Load Default Data」チェックボックスをオンにすると、再構築時にデフォルトのバルクデータを投入できます。この際、OpType.CREATEを使用しているため、既存のドキュメントは上書きされません。新規のデフォルトデータのみが追加されます。

利用方法

管理画面の「メンテナンス」ページにアクセスすると、「Rebuild Config Index」セクションが表示されます。再構築したいインデックスのチェックボックスを選択し、必要に応じて「Load Default Data」にチェックを入れて実行します。

この機能を利用するには、OpenSearchのreindexモジュールが必要です。Fessのmodule.xmlにreindexモジュールのインストール設定が追加されています。

詳細はPR #3097を参照してください。

Fessのスクリプト監査ログの改善

Fessでは、スクリプトの実行内容をaudit.logに出力する機能がありますが、実際に運用してみると、ログが長すぎて扱いにくいという問題がありました。今回、スクリプト監査ログの最大長を設定可能にし、あわせて文字列の正規化処理の順序も修正しました。

問題点

以前の実装では、スクリプトの監査ログに記録されるテキストの最大長が1000文字にハードコードされていました。スクリプトの実行内容をaudit.logに出力するようにしていましたが、ログが長くなりすぎて確認しづらく、実用的ではありませんでした。

また、文字列の正規化処理の順序にも問題がありました。制御文字（改行、タブなど）の置換を先に行ってから切り詰めていたため、切り詰め位置を超えた部分の制御文字まで不要に処理されていました。

改善内容

最大長の設定プロパティ追加

fess_config.propertiesにscript.audit.log.max.lengthプロパティを追加し、監査ログに記録するスクリプトテキストの最大長を設定できるようにしました。デフォルト値は100です。

# スクリプト監査ログの最大長（デフォルト: 100）
script.audit.log.max.length=100

以前のデフォルト値1000文字で運用していた環境では、必要に応じて明示的に設定してください。

script.audit.log.max.length=1000

正規化処理の順序修正

ActivityHelper.normalizeScript()メソッドで、処理の順序を変更しました。

変更前: 制御文字の置換 → 切り詰め
変更後: 切り詰め → 制御文字の置換

これにより、切り詰め位置を超えた部分の制御文字に対する不要な処理がなくなり、効率的になりました。

GroovyEngineの最適化

GroovyEngineでは、監査ログが無効な場合の早期リターンを追加しました。初期化時にscriptAuditLogEnabledフラグをキャッシュしておくことで、監査ログが無効な場合はlogScriptExecution()メソッドで無駄な処理を行わずに即座にリターンします。また、getCurrentScheduledJob()でのnullチェックも追加しています。

まとめ

スクリプトの実行内容をaudit.logに出力する機能自体は便利ですが、実際に使ってみると、ログが長すぎて扱いにくいという問題がありました。今回の改善で、最大長を環境に合わせて設定できるようになり、処理効率も向上しました。この変更はFess 15.6.0で利用可能になる予定です。

FessのログをSlackやGoogle Chatに通知する

Fessでは以前からクロール完了やOpenSearchの状態検知をSlackやGoogle Chat、メールで通知する機能がありましたが、ERROR/WARNレベルのログを通知する機能はありませんでした。運用中にエラーが発生した際に、ログファイルを見ないと気づけないという課題があったので、ログ通知機能を追加しました。

概要

この機能は、Fessのメインプロセスだけでなく、クローラー、サジェスト、サムネイルのサブプロセスで発生したERROR/WARNログを収集し、Slack、Google Chat、メールに通知します。各プロセスのログイベントはLog4j2のカスタムAppenderで捕捉され、インメモリバッファに蓄積した後、OpenSearchのキューインデックスに書き込まれます。その後、定期実行ジョブがキューから読み取り、既存の通知インフラを通じて通知を送信する仕組みです。

設定方法

管理画面での有効化

管理画面の「全般」設定に「ログ通知」のチェックボックスが追加されています。これを有効にするだけで、ログ通知が機能します。デフォルトでは無効になっています。

通知先の設定

通知先はFessの既存の通知設定を利用します。管理画面の「全般」設定で、SlackのWebhook URLやGoogle ChatのWebhook URL、メール設定を行ってください。以前のSlack通知の記事で紹介した設定と同じです。

通知レベルの設定

デフォルトではERRORレベルのみが通知対象です。WARNレベルも含めたい場合は、system.propertiesで以下のように設定できます。

log.notification.level=WARN

その他の設定項目

fess_config.propertiesで以下の項目をカスタマイズできます。

# バッファに蓄積できる最大イベント数（デフォルト: 1000）
log.notification.buffer.size=1000

# OpenSearchへのフラッシュ間隔（ミリ秒、デフォルト: 30000 = 30秒）
log.notification.flush.interval=30000

# 通知に表示する最大イベント数（デフォルト: 50）
log.notification.max.display.events=50

# メッセージの最大長（デフォルト: 200）
log.notification.max.message.length=200

仕組み

ログ通知は以下のコンポーネントで構成されています。

  1. LogNotificationAppender: Log4j2のカスタムAppenderで、ERROR/WARNログイベントを捕捉してバッファに蓄積します。無限ループを防ぐために、通知処理自体のログは除外されます
  2. LogNotificationHelper: インメモリバッファの管理とライフサイクルを担当します
  3. LogNotificationTarget: TimeoutTargetの実装で、30秒ごとにバッファの内容をOpenSearchのキューインデックスにフラッシュします
  4. LogNotificationJob: 5分ごとに実行されるスケジュールジョブで、OpenSearchのキューからイベントを読み取り、レベルごとにグループ化して通知を送信します

複数インスタンスで運用している場合も、ホスト名ベースでフィルタリングされるため、各インスタンスのログが正しく区別されます。

まとめ

この機能により、Fessの運用中に発生したエラーをリアルタイムに近い形で把握できるようになります。ログ監視の仕組みを別途構築する必要がなくなるので、小規模な環境や手軽に通知を受けたい場合に便利です。