Confluence で OpenSearch を監視する
AWS でホストされているかオンプレミスかにかかわらず、OpenSearch クラスターの健全性とパフォーマンスを維持するためには、監視が不可欠です。プロアクティブな監視は、リソースの制約やクラスターの不安定性といった潜在的な問題を、アプリケーションやユーザーに影響が及ぶ前に特定するのに役立ちます。
このガイドでは、AWS OpenSearch サービスとセルフホスト型 OpenSearch の両方の環境で、監視とアラートを設定するための実践的な推奨事項を紹介します。以下を参照してください。
一般的に追跡されているメトリック。
AWS CloudWatch やオープンソース ツール (Prometheus、Grafana など) を使用したダッシュボードとアラートの設定方法。
アラートの解釈と対応に関するベスト プラクティス。
On this page:
監視方法
OpenSearch クラスターの監視にはいくつかの方法があります。どの方法が最適であるかは、デプロイ モデルや運用上の設定によって異なります。
AWS ホスト型 OpenSearch
AWS OpenSearch サービスで管理されるクラスターの場合は、AWS CloudWatch が主要な監視ソリューションとなります。CloudWatch では、クラスターの健全性、リソース使用率、検索のパフォーマンスなど、OpenSearch ドメインから幅広いメトリックが自動的に収集されます。ダッシュボードを作成し、設定可能なアラームを設定することで、クラスターのステータスを常に把握できます。AWS ホスト型 OpenSearch サービスの監視の詳細については、こちらをご確認ください。
セルフホスト型 OpenSearch
セルフホスト型 OpenSearch クラスターの場合は、Prometheus や Grafana などのオープンソースの監視ツールが一般的に使用されています。OpenSearch Prometheus Exporter プラグインではクラスターのメトリックが収集され、収集されたメトリックは Grafana ダッシュボードで可視化、分析できます。この方法は柔軟性に優れ、カスタマイズが可能であり、ニーズに合わせて監視をカスタマイズできます。Prometheus はアラート ルールもサポートしているため、カスタムしきい値に基づいてプロアクティブな通知を受け取ることができます。セルフホスト型 OpenSearch の監視の詳細については、こちらをご確認ください。
主要なメトリックとアラート
OpenSearch クラスターが AWS でホストされているか、オンプレミスであるかにかかわらず、安定性、パフォーマンス、信頼性を維持するためには、以下の主要なメトリックを監視することが重要です。
カテゴリ | メトリック | なぜ重要なのか |
|---|---|---|
クラスターの健全性と可用性 | クラスターのステータス (緑、黄、赤): 全体的な健全性とシャードの割り当て | クラスターの問題を早期に検出 |
ノードの可用性: 参加イベントと離脱イベント | 予期しないノードの変更を特定 | |
リソース使用率 | ディスク使用量と空きストレージ容量 | ディスク容量不足によるシステム停止を防止 |
CPU 使用率 | リソースのボトルネックを強調 | |
JVM メモリの負荷、ヒープ使用量 | パフォーマンスの低下を防止 | |
パフォーマンスの測定指標 | 検索レイテンシとインデックス作成レイテンシ: 検索とインデックス作成の所要時間 | ユーザー エクスペリエンスを高速化 |
スレッド プール キュー: 検索 / 書き込みキューのサイズ | バックログや速度低下を特定 | |
エラー率と失敗 | 5xx エラーの発生率 | 不安定性や設定ミスを検出 |
自動スナップショットの失敗、バックアップ完了ステータス | 確実なデータ保護 | |
Confluence 固有のメトリック | 特定時点 (PIT) コンテキスト: PIT 検索の使用状況 | Confluence 検索の信頼性確保のために重要 |
スクロール コンテキスト：スクロール API の使用状況 | 一括データ操作において重要 |
トラブルシューティングとベスト プラクティス
OpenSearch の一般的な監視では、AWS CloudWatch アラームを使用して、クラスターの健全性、リソース使用率、パフォーマンス、エラー率を追跡できます。各アラームには、トラブルシューティングの手順とベスト プラクティスが記載されています。Amazon OpenSearch サービスの推奨される CloudWatch アラームについては、こちらをご確認ください。
Confluence 固有のメトリック
特定時点 (PIT) メトリック
CurrentPointInTime (開いている PIT コンテキストの数) または AvgPointInTimeAliveTime (PIT コンテキストの平均存続期間) のアラームは、PIT 検索がすぐに終了しないか、同時実行可能な PIT コンテキストの数がクラスターの制限に近づいているか、その制限を超えていることを示します。
これらのアラームには以下の方法で対処できます。
PIT キープアライブ期間を設定する
confluence.cfg.xmlファイルのopensearch.point-in-time.keep-aliveプロパティを設定して、PIT がアクティブな期間を制御します。この値を小さくすると、PIT コンテキストをより早く閉じることができ、リソース使用量を最小限に抑えることができます。ただし、この値を小さくしすぎると、ユーザーが検索結果をスクロールする前に PIT コンテキストが期限切れになる可能性があるため、検索結果が正常に生成されない可能性があります。既定は 120 秒ですが、ワークロードと監視データに基づいて慎重に調整してください。
異常なパターンを監視する
オープン PIT コンテキストが急増していることに気付いた場合は、Confluence の使用状況に最近の変更 (新しいプラグイン、統合、過剰な PIT 検索を生成する可能性のある一括操作など) がないか確認してください。PIT 制限を引き上げる
ワークロードでより多くの同時 PIT コンテキストを処理する必要がある場合は、次のように、OpenSearch REST API を使用してsearch.max_open_point_in_time_contextノード設定を更新し、制限を引き上げてください。PUT _cluster/settings { "persistent": { "search.max_open_point_in_time_context": <desired_limit> } }この制限を引き上げると、より多くのリソースが使用されます。変更後は、クラスタの健全性とリソース使用量を監視してください。
スクロール メトリック
ScrollCurrent (未完了のスクロール コンテキストの数) に関するアラームは、スクロールがクリーンアップされていないことを示している可能性があり、リソース リークやクラスターの不安定化につながるおそれがあります。
これらのアラームには以下の方法で対処できます。
権限を確認する
スクロール コンテキストを削除またはクリアするために必要な権限が Confluence に付与されていることを確認してください。適切な権限がないと、スクロールが蓄積され、クリーンアップされない可能性があります。使用パターンを監視する
スクロールの使用量が多い状態が続いている場合は、一括操作や長時間実行されるクエリがないか確認してください。未完了のスクロール コンテキストの数を減らすため、それらの操作を最適化するか、別の方法でバッチ処理することを検討してください。
デバッグのためにログ記録を有効にする
詳細なログ記録を有効にすると、トラブルシューティングやパフォーマンス分析に役立ちます。OpenSearch には、低速クエリやインデックス作成のボトルネックなどの問題を特定するためのログ記録オプションが複数用意されています。パフォーマンスへの影響を最小限に抑えるために、これらのログ記録はトラブルシューティング中にのみ、一時的に有効にしてください。
リクエストレベルの低速クエリ ログ: 設定された実行時間を超えたクエリをキャプチャします。これらのログでは、非効率的なクエリや問題のあるクエリを見つけることができます。
シャードレベルの低速インデックス作成ログ: シャード レベルでインデックス作成操作の速度が予想よりも低い場合に、その操作を記録します。
シャードレベルの低速検索ログ: シャードレベルで検索操作の速度が低い場合に、その操作を記録します。
詳細については、以下をご覧ください。