Exporters

エクスポーター

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

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

エクスポーターの目的は、Elastic Stack の任意のソースから収集されたデータを取得し、それを監視クラスターにルーティングすることです。複数のエクスポーターを設定することも可能ですが、一般的かつデフォルトの設定は単一のエクスポーターを使用することです。

Elasticsearch には 2 種類のエクスポーターがあります:

• local
• Elasticsearch 監視機能で使用されるデフォルトのエクスポーター。このエクスポーターはデータを同じクラスターにルーティングします。ローカルエクスポーター を参照してください。
• http
• 推奨されるエクスポーターで、HTTP 経由でアクセス可能な任意のサポートされている Elasticsearch クラスターにデータをルーティングするために使用できます。プロダクション環境では、常に別の監視クラスターを使用する必要があります。HTTP エクスポーター を参照してください。

両方のエクスポーターは同じ目的を果たします: 監視クラスターを設定し、監視データをルーティングすることです。ただし、これらのタスクは非常に異なる方法で実行されます。物事が異なる方法で進行しても、両方のエクスポーターは同じデータを送信することができます。

エクスポーターは、ノードとクラスターの両方のレベルで設定可能です。クラスター全体の設定は、各ノードの elasticsearch.yml ファイルの設定よりも優先されます。エクスポーターを更新すると、更新されたバージョンのエクスポーターに完全に置き換えられます。

すべてのノードが同じ設定を共有することが重要です。そうでない場合、監視データが異なる方法でルーティングされたり、異なる場所に送信されたりする可能性があります。

エクスポーターが監視データを監視クラスターにルーティングする際、最適なパフォーマンスのために _bulk インデックスを使用します。すべての監視データは、同じノード上のすべての有効なエクスポーターに一括で転送されます。そこから、エクスポーターは監視データをシリアライズし、監視クラスターに一括リクエストを送信します。キューイングは行われず、メモリ内またはディスクに永続化されないため、エクスポート中の失敗はそのバッチの監視データの損失を引き起こします。この設計は Elasticsearch への影響を制限し、次の試行が成功することを前提としています。

監視データをルーティングするには、適切な監視インデックスにインデックス化する必要があります。データがインデックス化されると、デフォルトでは日次インデックスパターンで名前付けされた監視インデックスに存在します。Elasticsearch 監視データの場合、これは .monitoring-es-6-* に一致するインデックスです。そこから、データは監視クラスター内に存在し、必要に応じてキュレーションまたはクリーンアップされる必要があります。監視データをキュレーションしないと、最終的にノードが満杯になり、ディスクスペース不足によりクラスターが失敗する可能性があります。

インデックス、特に監視インデックスのキュレーションを管理することを強くお勧めします。そのためには、クリーンサービス または Elastic Curator を利用できます。

ディスクのウォーターマーク（洪水段階のウォーターマークとして知られる）もあり、クラスターがディスクスペース不足に陥るのを防ぎます。この機能がトリガーされると、すべてのインデックス（監視インデックスを含む）が読み取り専用になり、問題が修正され、ユーザーが手動でインデックスを再び書き込み可能にするまでその状態が続きます。アクティブな監視インデックスが読み取り専用の間は、新しいデータを書き込む（インデックスする）ことができず、書き込み失敗を示すエラーが継続的にログに記録されます。詳細については、ディスクベースのシャード割り当て設定 を参照してください。

デフォルトエクスポーター

ノードまたはクラスターがエクスポーターを明示的に定義していない場合、次のデフォルトエクスポーターが使用されます:

Yaml

xpack.monitoring.exporters.default_local:
  type: local

他のエクスポーターがすでに定義されている場合、デフォルトエクスポーターは 作成されません。新しいエクスポーターを定義する場合、デフォルトエクスポーターが存在する場合は、自動的に削除されます。

エクスポーターテンプレートとインジェストパイプライン

エクスポーターが監視データをルーティングする前に、特定の Elasticsearch リソースを設定する必要があります。これらのリソースには、テンプレートとインジェストパイプラインが含まれます。エクスポーターが監視データをルーティングする前に必要なテンプレートを以下の表に示します:

テンプレートは、監視インデックスのデフォルト設定とマッピングを制御する通常の Elasticsearch テンプレートです。

デフォルトでは、監視インデックスは毎日作成されます（例: .monitoring-es-6-2017.08.26）。index.name.time_format 設定を使用して、監視インデックスのデフォルトの日付サフィックスを変更できます。この設定を使用して、特定の http エクスポーターによって監視インデックスが作成される頻度を制御できます。local エクスポーターではこの設定を使用できません。詳細については、HTTP エクスポーター設定 を参照してください。

一部のユーザーは、すべての インデックスパターンに一致する独自のテンプレートを作成し、それによって作成される監視インデックスに影響を与えます。監視インデックスの _source ストレージを無効にしないことが重要です。無効にすると、Kibana の監視機能が機能せず、クラスターの監視データを視覚化できなくなります。

エクスポーターが監視データをルーティングする前に必要なインジェストパイプラインを以下の表に示します:

エクスポーターは、データを送信する前にこれらのリソースのセットアップを処理します。リソースのセットアップが失敗した場合（たとえば、セキュリティ権限のため）、データは送信されず、警告がログに記録されます。

空のパイプラインは、インデックス作成中にコーディネーティングノードで評価され、特別な努力なしに無視されます。これにより、空のパイプラインは安全で、何もしない操作となります。

すべてのノードで node.ingest が無効になっている監視クラスターでは、インジェストパイプライン機能の使用を無効にすることが可能です。ただし、これを行うと、古い監視データをアップグレードするという目的がブロックされます。6.0 以降、インジェストパイプライン機能は監視クラスターの要件となります。少なくとも 1 つのノードで node.ingest を有効にする必要があります。

5.5 以降を実行しているノードが監視クラスターでテンプレートとインジェストパイプラインを設定した場合、Kibana 5.5 以降を使用して監視クラスターのすべての後続データを表示する必要があります。この更新が行われたかどうかを確認する最も簡単な方法は、.monitoring-es-6-* に一致するインデックスの存在を確認することです（または新しいパイプラインの存在を具体的に確認します）。5.5 より前のバージョンでは .monitoring-es-2-* が使用されていました。

エクスポーターによって作成される各リソースには version フィールドがあり、リソースを置き換える必要があるかどうかを判断するために使用されます。version フィールドの値は、リソースを変更した監視機能の最新バージョンを表します。リソースが監視機能の外部の誰かまたは何かによって編集された場合、次回の自動更新時にその変更は失われます。