コレクター

Elastic Agent と Metricbeat は、監視データを監視クラスターに収集して送信するための推奨方法です。

以前にレガシー収集方法を設定している場合は、Elastic Agent または Metricbeat 収集に移行する必要があります。レガシー収集を他の収集方法と併用しないでください。

コレクターは、その名の通り、物を収集します。各コレクターは、監視することを選択した Elasticsearch および X-Pack のパブリック API からデータを取得するために、各収集間隔ごとに一度実行されます。データ収集が完了すると、データは一括で エクスポーター に渡され、監視クラスターに送信されます。エクスポーターの数に関係なく、各コレクターは収集間隔ごとに一度だけ実行されます。

収集されるデータタイプごとにコレクターは1つだけです。言い換えれば、作成される監視ドキュメントは、複数のコレクターからマージされるのではなく、単一のコレクターから生成されます。Elasticsearch の監視機能には、最適なパフォーマンスのために重複を最小限に抑えることを目的としたいくつかのコレクターがあります。

各コレクターは、ゼロまたはそれ以上の監視ドキュメントを作成できます。たとえば、index_stats コレクターは、不要な呼び出しを避けるために、すべてのインデックス統計を同時に収集します。

コレクター データタイプ 説明
クラスタ統計 cluster_stats クラスターの状態に関する詳細を収集します。これには、実際のクラスターの一部（たとえば GET /_cluster/state）やそれに関する統計（たとえば、GET /_cluster/stats）が含まれます。これにより、単一のドキュメントタイプが生成されます。X-Pack 5.5 より前のバージョンでは、これは実際には3つの別々のコレクターであり、3つの別々のタイプ（cluster_stats、cluster_state、cluster_info）が生成されました。5.5以降、これら3つはすべて cluster_stats に統合されます。これは、選出された マスターノードでのみ実行され、収集されたデータ（cluster_stats）は主に UI を制御します。このデータが存在しない場合、選出されたマスターノードの設定ミス、データ収集に関連するタイムアウト、またはデータの保存に関する問題を示します。収集ごとに単一のドキュメントが生成されます。
インデックス統計 indices_stats、index_stats クラスター内のインデックスに関する詳細を、要約と個別に収集します。これにより、インデックス統計出力の一部を表す多くのドキュメントが作成されます（たとえば、GET /_stats）。この情報は一度だけ収集する必要があるため、選出された マスターノードで収集されます。このコレクターの最も一般的な失敗は、極端な数のインデックスに関連しており、そのため収集にかかる時間が長くなり、タイムアウトが発生します。収集ごとに1つの要約 indices_stats ドキュメントが生成され、インデックスごとに1つの index_stats ドキュメントが生成されます。
インデックス回復 index_recovery クラスター内のインデックス回復に関する詳細を収集します。インデックス回復は、クラスター レベルでの シャード の割り当てを表します。インデックスが回復されない場合、それは使用できません。これは、スナップショットを介したシャードの復元にも対応しています。この情報は一度だけ収集する必要があるため、選出された マスターノードで収集されます。このコレクターの最も一般的な失敗は、極端な数のシャードに関連しており、そのため収集にかかる時間が長くなり、タイムアウトが発生します。これにより、すべての回復を含む単一のドキュメントがデフォルトで生成されますが、これは非常に大きくなる可能性がありますが、プロダクションクラスターでの回復の最も正確な状況を示します。
シャード shards すべてのインデックスのすべての 割り当てられた シャードに関する詳細を収集します。特に、シャードが割り当てられているノードを含みます。この情報は一度だけ収集する必要があるため、選出された マスターノードで収集されます。このコレクターは、他のほとんどのコレクターとは異なり、ネットワークのタイムアウトの問題なしにルーティングテーブルを取得するためにローカルクラスター状態を使用します。各シャードは、別々の監視ドキュメントで表されます。
ジョブ job_stats すべての機械学習ジョブ統計（たとえば、`````GET

/ml/anomaly_detectors/_stats`````）に関する詳細を収集します。この情報は一度だけ収集する必要があるため、選出された マスターノードで収集されます。ただし、マスターノードが収集を実行できるようにするには、マスターノードの xpack.ml.enabled を true（デフォルト）に設定し、機械学習をサポートするライセンスレベルを持っている必要があります。 |
| ノード統計 | node_stats | メモリ使用率や CPU 使用率（たとえば、GET /_nodes/_local/stats）など、実行中のノードに関する詳細を収集します。これは、監視機能が有効になっている すべての_ ノードで実行されます。一般的な失敗の1つは、セグメントファイルが多すぎるためにノード統計リクエストがタイムアウトすることです。その結果、コレクターはファイルシステム統計が計算されるのを待つのに多くの時間を費やし、最終的にタイムアウトします。収集ごとに単一の node_stats ドキュメントが作成されます。これは、ノードが互いに通信できるが、監視クラスターとは通信できない問題を発見するのに役立つように、ノードごとに収集されます（たとえば、断続的なネットワークの問題やメモリの圧迫）。 |

Elasticsearch の監視機能は、各ノードのすべての適切なコレクターによる Elasticsearch 監視データの収集を実行するために、単一スレッドのスケジューラーを使用します。このスケジューラーは各ノードによってローカルに管理され、その間隔は xpack.monitoring.collection.interval を指定することによって制御され、デフォルトは 10 秒（10s）です。

基本的に、各コレクターは同じ原則で動作します。各収集間隔ごとに、各コレクターが実行すべきかどうかが確認され、その後、適切なコレクターが実行されます。個々のコレクターの失敗は、他のコレクターに影響を与えません。

収集が完了すると、すべての監視データがエクスポーターに渡され、監視データが監視クラスターにルーティングされます。

Kibana の監視チャートにギャップが存在する場合、通常はコレクターが失敗したか、監視クラスターがデータを受信しなかった（たとえば、再起動中であった）ためです。コレクターが失敗した場合、収集を試みたノードにログされたエラーが存在するはずです。

収集は現在、選出されたマスターノードに余分なオーバーヘッドを避けるために、直列で行われています。このアプローチの欠点は、コレクターが同じ収集期間内で異なるバージョンのクラスター状態を観察する可能性があることです。実際には、これは大きな違いを生じず、コレクターを並行して実行してもそのような可能性を防ぐことはできません。

コレクターの構成オプションに関する詳細については、監視収集設定を参照してください。

Elastic Stack 全体からのデータ収集

Elasticsearch の監視機能は、Elastic Stack の他の部分からも監視データを受信します。このようにして、スタックのための予定外の監視データコレクターとして機能します。

デフォルトでは、データ収集は無効になっています。Elasticsearch の監視データは収集されず、Kibana、Beats、Logstash などの他のソースからのすべての監視データは無視されます。監視データの収集を有効にするには、xpack.monitoring.collection.enabled を true に設定する必要があります。詳細は 監視設定 を参照してください。

データが受信されると、それはエクスポーターに転送され、すべての監視データと同様に監視クラスターにルーティングされます。

このスタックレベルの「コレクター」は、Elasticsearch の監視機能の収集間隔の外に存在するため、xpack.monitoring.collection.interval 設定の影響を受けません。したがって、データは受信されるたびにエクスポーターに渡されます。この動作により、Kibana、Logstash、または Beats のインデックスが予期せず作成される可能性があります。

監視データが収集され処理される間、いくつかのプロダクションクラスターのメタデータが受信ドキュメントに追加されます。このメタデータにより、Kibana は監視データを適切なクラスターにリンクできます。このリンクが監視しているインフラストラクチャにとって重要でない場合、Logstash と Beats を構成して監視データを直接監視クラスターに報告する方が簡単かもしれません。このシナリオでは、プロダクションクラスターが監視データに関連する余分なオーバーヘッドを追加することを防ぎ、Logstash ノードや Beats が多数ある場合に非常に便利です。

典型的な監視アーキテクチャに関する詳細については、動作の仕組み を参照してください。