Fessの運用において、監視はシステムの安定性と信頼性を維持するために不可欠です。今回は、Fessの運用に必要な監視観点や項目について解説します。

リソース監視

まずは、Fessを稼働させるサーバリソース観点での監視項目を考えていきます。

Fessは、以下の機能が1つのプロセスとして、サーバリソースを消費します。

  1. Fess (ウェブアプリケーション)
  2. Fess (クローラー)
  3. Fess (サジェスト生成)
  4. Fess (サムネイル生成)
  5. OpenSearch (検索エンジン)

1と5は常時起動しているプロセスで、2〜4は定期的に実行されるプロセスです。1台のサーバでFessを運用する場合、これらのプロセスが全て動いても問題が起きないだけのサーバリソースを用意する必要があります。最小構成では、2CPUと4Gメモリーがあれば、Fessを利用できます。

これらの機能が消費するリソースの監視項目は以下になります。

  • CPU使用率
  • メモリー使用率
  • ディスク使用率

これらの項目は、一般的な監視ツールを通じて監視できますので、ご利用の環境に適したツールを選定してください。

以下にプロセスごとの監視時の注意点をまとめます。

Fess (ウェブアプリケーション)

利用者に検索機能を提供する主要部分です。検索処理は主にOpenSearchで行われるため、この部分は軽めの処理が多いですが、アクセス数が極端に多い場合はリソースの消費が顕著になるため注意が必要です。

リソース状況を把握するために、管理APIを利用することで、JVMやOSの状態情報をFessから取得することができます。 以下のように http://<Server Name>/api/admin/statsにアクセストークンを指定してリクエストします。

$ curl -H "Authorization: access_token" "http://localhost:8080/api/admin/stats"

管理用APIについては、第14回 管理用APIの使い方の記事を参照してください。

Fess (クローラー)

クローラーはスケジューラで指定した時刻に起動されます。データの取得とインデックス作成の前処理を行うため、多くのCPUとメモリーを消費します。特にクロール対象やクロール設定によっては、リソース消費が大幅に増加する可能性があります。

リソース消費を抑制するため、fess_config.propertiesでadaptive.load.controlを設定することでCPU使用率を調整できます。例えば、この値を50に設定すると、CPU使用率が50%を超えている場合は、処理を一時停止して、CPU使用率が下がるまで待ちます。

Fess (サジェスト生成)

サジェスト生成はスケジューラで指定した時刻に起動されます。OpenSearchから検索ログを取得し、サジェスト用データを作成するため、CPUを主に使用します。こちらもadaptive.load.controlによる負荷調整が可能です。

Fess (サムネイル生成)

サムネイル生成はスケジューラで指定した時刻に起動されます。生成に必要なサムネイル情報をOpenSearchから取得し、生成したサムネイル画像を保存します。ディスク使用量に加えて、サムネイル生成にPlaywrightを使用する場合はCPUも大きく利用します。adaptive.load.control によりCPU使用率の調整が行えます。

OpenSearch (検索エンジン)

Fessで扱うさまざまなデータを格納し、各処理からアクセスされるため、CPU、メモリー、ディスクの消費が大きくなります。ディスク使用量が90%を超えると書き込みが停止するため、特に注意が必要です。

上記の内容を踏まえて、サーバリソースが消費されすぎていないかを確認できる状態で運用してください。

死活監視

死活監視では定期的なヘルスチェックを行い、Fessにアクセスできないなどの異常を検知します。ヘルスチェックは、Fessが提供するAPIを利用できます。

このAPIを使用する場合はJSON形式でレスポンスを返すため、設定で「JSONレスポンス」が有効になっていることを確認してください。設定は、管理画面の左メニュー「システム」＞「全般」を選択し、全般設定の画面で「JSONレスポンス」で確認できます。「JSONレスポンス」にチェックが入っていない場合は、チェックを入れて「更新」ボタンをクリックして設定を保存してください。

サーバの状態を確認するには、以下のように http://<Server Name>/api/v1/health のリクエストを送信し、状態が正常であれば、レスポンスのstatusフィールドにgreenが返されます。green以外が返された場合は、適切な通知や対応を行う必要があります。（実行結果はjqコマンドで整形しています）

$ curl http://localhost:8080/api/v1/health | jq .
{
  "data": {
    "status": "green",
    "timed_out": false
  }
}

検索利用者向けAPIについてはFessのドキュメントにも記載していますので、こちらも参考にしてみてください。

ログ監視

Fessのログファイルでは、システム稼働に影響がある問題はERROR、それ以外の問題はWARNのログレベルでログメッセージを出力しています。

Fessの運用に影響がある問題を検知したい場合は、以下のログファイルを対象にして、ERRORレベルのログメッセージを検知してください。

  • fess.log
  • fess-crawler.log
  • fess-thumbnail.log
  • fess-suggest.log

Fessでは、さまざまなライブラリを利用して、多くの機能を実現しています。そのため、Fessの稼働に影響がない場合でも、利用しているライブラリがERRORレベルでログメッセージを出力する場合があります。そのような場合は、ERRORであっても該当メッセージを除外するなどで、ログファイルの監視対応をしてください。

その他

クロール完了の通知

クロールジョブが完了した場合に通知することで、通常に比べて処理に時間がかかっているなど、クロールの状況を把握することができます。

Slackに通知する場合の手順は、記事として掲載していますので、第51回 クロール完了通知をSlackに送信するの記事を参照してください。

インデックスされたドキュメント数

Fessが提供している検索APIを利用し、インデックスされているドキュメント数を確認することができます。定期的にドキュメント数をチェックすることで、検索対象が想定していない数になっている、極端な増減があったなどの変化を捉えることができると思います。

死活監視と同様、検索APIを利用するには「JSONレスポンス」が有効になっている必要があります。

ドキュメント数は http://<Server Name>/api/v1/documents?q=*:* のリクエストを送信し、レスポンスのrecord_countフィールドの値を取得します。 以下の例でいうと、31625がドキュメント数になります。

$ curl "http://localhost:8080/api/v1/documents?q=*:*" | jq .record_count
31625

*　*　*

本記事では、Fessの運用における監視項目について解説しました。これらの監視を適切に実施することで、システムの異常を早期に検知し、迅速に対応することが可能になります。監視設定を行う際は、今回の記事を参考にしてください。