Elasticsearchの設定 - ネットワーキング（Networking） - 《Elasticsearchガイドv8.15》日本語

ネットワーキング
ネットワーク構成に注意してください！
一般的に使用されるネットワーク設定
ネットワークアドレスの特別な値
高度なHTTP設定
- HTTP クライアントの設定
高度なトランスポート設定
高度なリモートクラスター (API キーベースモデル) 設定
リクエストトレース
- REST リクエストトレーサ
- トランスポートトレーサ
ネットワーキングスレッドモデル

ネットワーキング

各Elasticsearchノードには2つの異なるネットワークインターフェースがあります。クライアントはHTTPインターフェースを使用してElasticsearchのREST APIにリクエストを送信しますが、ノードはトランスポートインターフェースを使用して他のノードと通信します。トランスポートインターフェースは、リモートクラスターとの通信にも使用されます。トランスポートインターフェースは、長寿命のTCPチャネルを介して送信されるカスタムバイナリプロトコルを使用します。両方のインターフェースは、セキュリティのためのTLSを使用するように構成できます。

これらのインターフェースの両方を同時にnetwork.*設定を使用して構成できます。より複雑なネットワークがある場合は、http.*およびtransport.*設定を使用してインターフェースを独立して構成する必要があるかもしれません。可能な場合は、network.*設定を使用して両方のインターフェースに適用し、構成を簡素化し、重複を減らしてください。

デフォルトでは、Elasticsearchはlocalhostにのみバインドされており、これはリモートからアクセスできないことを意味します。この構成は、同じホスト上で実行されている1つ以上のノードで構成されたローカル開発クラスターには十分です。複数のホストにまたがるクラスターを形成するか、リモートクライアントがアクセスできるようにするには、network.hostのような一部のネットワーク設定を調整する必要があります。

ネットワーク構成に注意してください！

保護されていないノードを公共のインターネットにさらさないでください。そうしないと、世界中の誰でもクラスター内のデータをダウンロード、変更、または削除できるようになります。

Elasticsearchを非ローカルアドレスにバインドするように構成すると、一部の警告が致命的な例外に変換されます。ネットワーク設定を構成した後にノードが起動を拒否した場合は、進む前にログに記録された例外に対処する必要があります。

一般的に使用されるネットワーク設定

ほとんどのユーザーは、次のネットワーク設定のみを構成する必要があります。

network.host
(静的, 文字列) このノードのHTTPおよびトランスポートトラフィックのアドレスを設定します。ノードはこのアドレスにバインドし、公開アドレスとしても使用します。IPアドレス、ホスト名、または特別な値を受け入れます。
デフォルトは_local_です。ただし、セキュリティの自動構成により、http.host: 0.0.0.0がelasticsearch.yml構成ファイルに追加され、HTTPトラフィックのデフォルトが上書きされます。
http.port
(静的, 整数) HTTPクライアント通信のためにバインドするポート。単一の値または範囲を受け入れます。範囲が指定されている場合、ノードは範囲内の最初の利用可能なポートにバインドします。
デフォルトは9200-9300です。
transport.port
(静的, 整数) ノード間の通信のためにバインドするポート。単一の値または範囲を受け入れます。範囲が指定されている場合、ノードは範囲内の最初の利用可能なポートにバインドします。この設定は、すべてのマスター候補ノードで単一のポートに設定してください。
デフォルトは9300-9400です。
remote_cluster.port
(静的, 整数) リモートクラスタークライアント通信のためにバインドするポート。単一の値を受け入れます。
デフォルトは9443です。

ネットワークアドレスの特別な値

Elasticsearchが自動的にアドレスを決定するように構成するには、次の特別な値を使用します。network.host、network.bind_host、network.publish_host、およびHTTPおよびトランスポートインターフェースの対応する設定を構成する際にこれらの値を使用します。

_local_
システム上の任意のループバックアドレス、例えば127.0.0.1。
_site_
システム上の任意のサイトローカルアドレス、例えば192.168.0.1。
_global_
システム上の任意のグローバルスコープのアドレス、例えば8.8.8.8。
_[networkInterface]_
[networkInterface]という名前のネットワークインターフェースのアドレスを使用します。例えば、en0というインターフェースのアドレスを使用したい場合は、network.host: _en0_を設定します。
0.0.0.0
利用可能なすべてのネットワークインターフェースのアドレス。

一部のシステムでは、これらの特別な値が複数のアドレスに解決されます。その場合、Elasticsearchはそのうちの1つを公開アドレスとして選択し、ノードの再起動ごとに選択が変更される可能性があります。ノードがすべての可能なアドレスでアクセス可能であることを確認してください。


### IPv4とIPv6
これらの特別な値は、デフォルトでIPv4およびIPv6アドレスの両方を生成しますが、`````:ipv4`````または`````:ipv6`````のサフィックスを追加することで、それぞれIPv4またはIPv6アドレスのみに制限することもできます。例えば、`````network.host: "_en0:ipv4_"`````はこのノードのアドレスをインターフェース`````en0`````のIPv4アドレスに設定します。
## クラウドでの発見
クラウドで[EC2発見プラグイン](https://www.elastic.co/guide/en/elasticsearch/plugins/8.15/discovery-ec2.html)または[Google Compute Engine発見プラグイン](https://www.elastic.co/guide/en/elasticsearch/plugins/8.15/discovery-gce-network-host.html#discovery-gce-network-host)をインストールして実行する場合、さらに特別な設定が利用可能です。
## バインディングと公開
Elasticsearchは、バインディングと公開として知られる2つの異なる目的のためにネットワークアドレスを使用します。ほとんどのノードはすべてに同じアドレスを使用しますが、より複雑なセットアップでは、異なる目的のために異なるアドレスを構成する必要があるかもしれません。
Elasticsearchのようなアプリケーションがネットワーク通信を受信したい場合、受信すべきトラフィックのアドレスをオペレーティングシステムに示す必要があります。これをそのアドレスに*バインド*することと呼びます。Elasticsearchは必要に応じて複数のアドレスにバインドできますが、ほとんどのノードは単一のアドレスにのみバインドします。Elasticsearchは、ホストにそのアドレスを持つネットワークインターフェースがある場合にのみ、そのアドレスにバインドできます。必要に応じて、トランスポートインターフェースとHTTPインターフェースを異なるアドレスにバインドするように構成できます。
各Elasticsearchノードには、クライアントや他のノードが連絡できるアドレスがあり、これを*公開アドレス*と呼びます。各ノードには、HTTPインターフェース用の1つの公開アドレスと、トランスポートインターフェース用の1つの公開アドレスがあります。これら2つのアドレスは何でも構いませんが、ホストのネットワークインターフェースのアドレスである必要はありません。唯一の要件は、各ノードが次の条件を満たす必要があることです：
-  スニッフィングを使用して発見するすべてのクライアントがそのHTTP公開アドレスにアクセスできること。
-  クラスター内の他のすべてのノードと、[リモートクラスター](7781101e63c937c9.md#sniff-mode)を使用して発見するリモートクラスターがそのトランスポート公開アドレスにアクセスできること。
ホスト名を使用してトランスポート公開アドレスを指定すると、Elasticsearchは起動時にこのホスト名をIPアドレスに解決し、他のノードは再度名前を解決するのではなく、結果として得られたIPアドレスを使用します。混乱を避けるために、すべてのネットワーク場所でノードのアドレスに解決されるホスト名を使用してください。
### 単一のアドレスを使用する
最も一般的な構成は、Elasticsearchがクライアントや他のノードにアクセス可能な単一のアドレスにバインドすることです。この構成では、`````network.host`````をそのアドレスに設定するだけで済みます。バインドまたは公開アドレスを別々に設定する必要はなく、HTTPまたはトランスポートインターフェースのアドレスを別々に構成する必要もありません。
### 複数のアドレスを使用する
[高度なネットワーク設定](9a9abf9168effbcb.md#advanced-network-settings)を使用して、Elasticsearchを複数のアドレスにバインドするか、バインドしているアドレスとは異なるアドレスを公開することができます。`````network.bind_host`````をバインドアドレスに設定し、`````network.publish_host`````をこのノードが公開されるアドレスに設定します。複雑な構成では、HTTPおよびトランスポートインターフェースのこれらのアドレスを異なるように構成できます。
## 高度なネットワーク設定
これらの高度な設定を使用すると、複数のアドレスにバインドしたり、バインディングと公開に異なるアドレスを使用したりできます。ほとんどの場合、これらは必要なく、[一般的に使用される設定](9a9abf9168effbcb.md#common-network-settings)を使用できる場合は使用しないでください。
-   `````network.bind_host

(静的, 文字列) ノードが受信接続をリッスンするためにバインドすべきネットワークアドレス。IPアドレス、ホスト名、および特別な値のリストを受け入れます。デフォルトはnetwork.hostで指定されたアドレスです。この設定は、複数のアドレスにバインドする場合や、バインディングと公開に異なるアドレスを使用する場合にのみ使用してください。
network.publish_host
(静的, 文字列) クライアントや他のノードがこのノードに連絡するために使用できるネットワークアドレス。IPアドレス、ホスト名、または特別な値を受け入れます。デフォルトはnetwork.hostで指定されたアドレスです。この設定は、複数のアドレスにバインドする場合や、バインディングと公開に異なるアドレスを使用する場合にのみ使用してください。


### 高度なTCP設定
次の設定を使用して、HTTPおよびトランスポートインターフェースで使用されるTCP接続の低レベルパラメータを制御します。
-   `````network.tcp.keep_alive

(静的, ブール) ネットワークソケットのSO_KEEPALIVEオプションを構成し、各接続がTCPキープアライブプローブを送信するかどうかを決定します。デフォルトはtrueです。
network.tcp.keep_idle
(静的, 整数) ネットワークソケットのTCP_KEEPIDLEオプションを構成し、接続がアイドル状態でTCPキープアライブプローブを送信し始めるまでの時間（秒）を決定します。デフォルトは-1で、システムのデフォルトを使用します。この値は300秒を超えることはできません。LinuxおよびmacOSでのみ適用されます。
network.tcp.keep_interval
(静的, 整数) ネットワークソケットのTCP_KEEPINTVLオプションを構成し、TCPキープアライブプローブを送信する間隔（秒）を決定します。デフォルトは-1で、システムのデフォルトを使用します。この値は300秒を超えることはできません。LinuxおよびmacOSでのみ適用されます。
network.tcp.keep_count
(静的, 整数) ネットワークソケットのTCP_KEEPCNTオプションを構成し、接続が切断される前に送信される未確認のTCPキープアライブプローブの数を決定します。デフォルトは-1で、システムのデフォルトを使用します。LinuxおよびmacOSでのみ適用されます。
network.tcp.no_delay
(静的, ブール) ネットワークソケットのTCP_NODELAYオプションを構成し、TCPノーディレイが有効かどうかを決定します。デフォルトはtrueです。
network.tcp.reuse_address
(静的, ブール) ネットワークソケットのSO_REUSEADDRオプションを構成し、アドレスを再利用できるかどうかを決定します。デフォルトはWindowsではfalse、それ以外ではtrueです。
network.tcp.send_buffer_size
(静的, バイト値) ネットワークソケットのTCP送信バッファのサイズを構成します。デフォルトは-1で、システムのデフォルトを使用します。
network.tcp.receive_buffer_size
(静的, バイト値) TCP受信バッファのサイズを構成します。デフォルトは-1で、システムのデフォルトを使用します。

高度なHTTP設定

次の高度な設定を使用して、トランスポートインターフェースとは独立してHTTPインターフェースを構成します。また、ネットワーク設定を使用して両方のインターフェースを同時に構成することもできます。

http.host
(静的, 文字列) HTTPトラフィックのためのこのノードのアドレスを設定します。ノードはこのアドレスにバインドし、HTTP公開アドレスとしても使用します。IPアドレス、ホスト名、または特別な値を受け入れます。この設定は、トランスポートインターフェースとHTTPインターフェースに異なる構成が必要な場合にのみ使用してください。
デフォルトはnetwork.hostで指定されたアドレスです。ただし、セキュリティの自動構成により、http.host: 0.0.0.0がelasticsearch.yml構成ファイルに追加され、デフォルトが上書きされます。
http.bind_host
(静的, 文字列) ノードが受信HTTP接続をリッスンするためにバインドすべきネットワークアドレス。IPアドレス、ホスト名、および特別な値のリストを受け入れます。デフォルトはhttp.hostまたはnetwork.bind_hostで指定されたアドレスです。この設定は、複数のアドレスにバインドする必要がある場合や、バインディングと公開に異なるアドレスを使用する必要がある場合、またトランスポートインターフェースとHTTPインターフェースに異なるバインディング構成が必要な場合にのみ使用してください。
http.publish_host
(静的, 文字列) スニッフィングを使用してノードに連絡するHTTPクライアントのためのネットワークアドレス。IPアドレス、ホスト名、または特別な値を受け入れます。デフォルトはhttp.hostまたはnetwork.publish_hostで指定されたアドレスです。この設定は、複数のアドレスにバインドする必要がある場合や、バインディングと公開に異なるアドレスを使用する必要がある場合、またトランスポートインターフェースとHTTPインターフェースに異なるバインディング構成が必要な場合にのみ使用してください。
http.publish_port
(静的, 整数) HTTP公開アドレスのポート。この設定は、公開ポートをhttp.portと異なるものにする必要がある場合にのみ構成します。デフォルトはhttp.portを介して割り当てられたポートです。
http.max_content_length
(静的, バイト値) HTTPリクエストボディの最大サイズ。ボディが圧縮されている場合、制限は圧縮前のHTTPリクエストボディサイズに適用されます。デフォルトは100mbです。この設定を100mbを超えるように構成すると、クラスターの不安定性を引き起こす可能性があり、推奨されません。Bulk APIにリクエストを送信する際にこの制限に達した場合、クライアントを構成して各バルクリクエストで送信するドキュメントを減らしてください。100mbを超える個々のドキュメントをインデックスしたい場合は、Elasticsearchに送信する前にそれらを小さなドキュメントに前処理してください。たとえば、生データをElasticsearchの外部のシステムに保存し、Elasticsearchがインデックスするドキュメントに生データへのリンクを含めます。
http.max_initial_line_length
(静的, バイト値) HTTP URLの最大サイズ。デフォルトは4kbです。
http.max_header_size
(静的, バイト値) 許可されるヘッダーの最大サイズ。デフォルトは16kbです。
http.compression
(静的, ブール) 可能な場合は圧縮をサポートします（Accept-Encodingを使用）。HTTPSが有効な場合、デフォルトはfalseです。それ以外の場合、デフォルトはtrueです。
HTTPSの圧縮を無効にすると、BREACH攻撃などの潜在的なセキュリティリスクが軽減されます。HTTPSトラフィックを圧縮するには、http.compressionをtrueに明示的に設定する必要があります。
http.compression_level
(静的, 整数) HTTPレスポンスの圧縮レベルを定義します。有効な値は1（最小圧縮）から9（最大圧縮）の範囲です。デフォルトは3です。
http.cors.enabled
(静的, ブール) クロスオリジンリソースシェアリングを有効または無効にします。これにより、別のオリジンのブラウザがElasticsearchに対してリクエストを実行できるかどうかが決まります。trueに設定すると、Elasticsearchは事前フライトCORSリクエストを処理できるようになります。Elasticsearchは、リクエストで送信されたOriginがhttp.cors.allow-originリストによって許可されている場合、Access-Control-Allow-Originヘッダーでこれらのリクエストに応答します。false（デフォルト）に設定すると、ElasticsearchはOriginリクエストヘッダーを無視し、実質的にCORSリクエストを無効にします。なぜなら、ElasticsearchはAccess-Control-Allow-Originレスポンスヘッダーで応答することは決してないからです。
クライアントがOriginヘッダーを持つ事前フライトリクエストを送信しない場合、またはサーバーからのレスポンスヘッダーを確認してAccess-Control-Allow-Originレスポンスヘッダーを検証しない場合、クロスオリジンセキュリティが損なわれます。CORSがElasticsearchで有効になっていない場合、クライアントが知る唯一の方法は、事前フライトリクエストを送信し、必要なレスポンスヘッダーが欠落していることに気付くことです。
http.cors.allow-origin
(静的, 文字列) 許可するオリジン。値の前後にスラッシュ(/)を追加すると、これは正規表現として扱われ、HTTPおよびHTTPSをサポートできます。例えば、/https?:\/\/localhost(:[0-9]+)?/を使用すると、両方の場合にリクエストヘッダーが適切に返されます。デフォルトでは、オリジンは許可されていません。
ワイルドカード(*)は有効な値ですが、セキュリティリスクと見なされます。なぜなら、あなたのElasticsearchインスタンスはどこからでもクロスオリジンリクエストを受け入れるからです。
http.cors.max-age
(静的, 整数) ブラウザはCORS設定を決定するために「事前フライト」OPTIONSリクエストを送信します。max-ageは、結果がキャッシュされる秒数を定義します。デフォルトは1728000（20日）です。
http.cors.allow-methods
(静的, 文字列) 許可するメソッド。デフォルトはOPTIONS, HEAD, GET, POST, PUT, DELETEです。
http.cors.allow-headers
(静的, 文字列) 許可するヘッダー。デフォルトはX-Requested-With, Content-Type, Content-Length, Authorization, Accept, User-Agent, X-Elastic-Client-Metaです。
http.cors.expose-headers
(静的) クライアントに公開するレスポンスヘッダー。デフォルトはX-elastic-productです。
http.cors.allow-credentials
(静的, ブール) Access-Control-Allow-Credentialsヘッダーを返すべきかどうか。デフォルトはfalseです。
このヘッダーは、設定がtrueに設定されている場合にのみ返されます。
http.detailed_errors.enabled
(静的, ブール) HTTPレスポンスでの詳細なエラーレポートが有効かどうかを構成します。デフォルトはtrueで、これは、?error_traceパラメータを含むHTTPリクエストが例外に遭遇した場合、スタックトレースを含む詳細なエラーメッセージを返すことを意味します。falseに設定すると、?error_traceパラメータを持つリクエストは拒否されます。
http.pipelining.max_events
(静的, 整数) HTTP接続が閉じられる前にメモリにキューされる最大イベント数。デフォルトは10000です。
http.max_warning_header_count
(静的, 整数) クライアントHTTPレスポンスの警告ヘッダーの最大数。デフォルトは-1で、警告ヘッダーの数は無制限です。
http.max_warning_header_size
(静的, バイト値) クライアントHTTPレスポンスの警告ヘッダーの最大合計サイズ。デフォルトは-1で、警告ヘッダーのサイズは無制限です。
http.tcp.keep_alive
(静的, ブール) このソケットのSO_KEEPALIVEオプションを構成し、TCPキープアライブプローブを送信するかどうかを決定します。デフォルトはnetwork.tcp.keep_aliveです。
http.tcp.keep_idle
(静的, 整数) HTTPソケットのTCP_KEEPIDLEオプションを構成し、接続がアイドル状態でTCPキープアライブプローブを送信し始めるまでの時間（秒）を決定します。デフォルトはnetwork.tcp.keep_idleで、システムのデフォルトを使用します。この値は300秒を超えることはできません。LinuxおよびmacOSでのみ適用されます。
http.tcp.keep_interval
(静的, 整数) HTTPソケットのTCP_KEEPINTVLオプションを構成し、TCPキープアライブプローブを送信する間隔（秒）を決定します。デフォルトはnetwork.tcp.keep_intervalで、システムのデフォルトを使用します。この値は300秒を超えることはできません。LinuxおよびmacOSでのみ適用されます。
http.tcp.keep_count
(静的, 整数) HTTPソケットのTCP_KEEPCNTオプションを構成し、接続が切断される前に送信される未確認のTCPキープアライブプローブの数を決定します。デフォルトはnetwork.tcp.keep_countで、システムのデフォルトを使用します。LinuxおよびmacOSでのみ適用されます。
http.tcp.no_delay
(静的, ブール) HTTPソケットのTCP_NODELAYオプションを構成し、TCPノーディレイが有効かどうかを決定します。デフォルトはtrueです。
http.tcp.reuse_address
(静的, ブール) HTTPソケットのSO_REUSEADDRオプションを構成し、アドレスを再利用できるかどうかを決定します。デフォルトはWindowsではfalse、それ以外ではtrueです。
http.tcp.send_buffer_size
(静的, バイト値) HTTPトラフィックのTCP送信バッファのサイズ。デフォルトはnetwork.tcp.send_buffer_sizeです。
http.tcp.receive_buffer_size
(静的, バイト値) HTTPトラフィックのTCP受信バッファのサイズ。デフォルトはnetwork.tcp.receive_buffer_sizeです。
http.client_stats.enabled
(動的, ブール) HTTPクライアント統計の収集を有効または無効にします。デフォルトはtrueです。
http.client_stats.closed_channels.max_count
(静的, 整数) http.client_stats.enabledがtrueの場合、Elasticsearchが統計を報告する最大の閉じたHTTPチャネルの数を設定します。デフォルトは10000です。
http.client_stats.closed_channels.max_age
(静的, 時間値) http.client_stats.enabledがtrueの場合、HTTPチャネルを閉じた後にElasticsearchがそのチャネルの統計を報告する最大の時間の長さを設定します。デフォルトは5mです。

HTTP クライアントの設定

多くの HTTP クライアントやプロキシは、ブラウザのような応答遅延のために設定されており、デフォルトでかなり短いタイムアウトを課し、Elasticsearch がリクエストの処理を完了するのにこのタイムアウトを超える時間がかかると失敗を報告します。Elasticsearch はすべてのリクエストに対して最終的に応答しますが、一部のリクエストは完了するのに数分の処理時間を要する場合があります。クライアントのデフォルトの応答タイムアウトがあなたのニーズに適しているかどうかを慎重に考慮してください。多くの場合、失敗するよりも応答を待つ方が良いので、応答タイムアウトを無効にする必要があります：

タイムアウトに反応してリクエストを再試行する場合、再試行は元のリクエストを保持していた同じキューの最後に配置されることがよくあります。したがって、より忍耐強く待つ代わりにタイムアウトして再試行すると、リクエストの処理が完了するまでに時間がかかります。再試行は Elasticsearch に追加の負荷をかけます。
リクエストが冪等でなく再試行できない場合、リクエストを失敗させることが最後の手段です。応答をより忍耐強く待つことで、通常は全体の操作が成功します。

クライアントで応答タイムアウトを無効にする場合は、代わりに TCP keepalive を設定してください。TCP keepalive は、ネットワーク障害が発生した場合にクライアントが無限に待機するのを防ぐための推奨方法です。

高度なトランスポート設定

次の高度な設定を使用して、HTTP インターフェースとは独立してトランスポートインターフェースを構成します。ネットワーク設定を使用して、両方のインターフェースを一緒に構成します。

transport.host
(Static, string) トランスポートトラフィックのためのこのノードのアドレスを設定します。このノードはこのアドレスにバインドし、トランスポート公開アドレスとしても使用します。IP アドレス、ホスト名、または特別な値を受け入れます。この設定は、トランスポートと HTTP インターフェースの異なる構成が必要な場合にのみ使用してください。
デフォルトは network.host で指定されたアドレスです。
transport.bind_host
(Static, string) ノードが受信トランスポート接続をリッスンするためにバインドすべきネットワークアドレスです。IP アドレス、ホスト名、および特別な値のリストを受け入れます。デフォルトは transport.host または network.bind_host で指定されたアドレスです。複数のアドレスにバインドする必要がある場合や、公開とバインドに異なるアドレスを使用する必要がある場合、トランスポートと HTTP インターフェースの異なるバインディング構成が必要な場合にのみこの設定を使用してください。
transport.publish_host
(Static, string) 他のノードがこのノードに連絡できるネットワークアドレスです。IP アドレス、ホスト名、または特別な値を受け入れます。デフォルトは transport.host または network.publish_host で指定されたアドレスです。複数のアドレスにバインドする必要がある場合や、公開とバインドに異なるアドレスを使用する必要がある場合、トランスポートと HTTP インターフェースの異なるバインディング構成が必要な場合にのみこの設定を使用してください。
transport.publish_port
(Static, integer) トランスポート公開アドレスのポートです。このパラメータは、公開ポートを transport.port とは異なるものにする必要がある場合にのみ設定します。デフォルトは transport.port で割り当てられたポートです。
transport.connect_timeout
(Static, time value) 新しい接続を開始するための接続タイムアウト（時間設定形式）。デフォルトは 30s です。
transport.compress
(Static, string) 他のノードに送信する前に圧縮されるトランスポートリクエストを決定します。Elasticsearch は、対応するリクエストが圧縮されている場合にのみトランスポート応答を圧縮します。transport.compression_scheme も参照してください。これは使用される圧縮スキームを指定します。次の値を受け入れます：
- false
- トランスポートリクエストは圧縮されません。このオプションは最も多くのネットワーク帯域幅を使用しますが、圧縮と解凍の CPU オーバーヘッドを回避します。
- indexing_data
- ノード間で送信される生のインデックスデータのみを圧縮します。これは、インジェスト、CCR（ブートストラップを除く）、および操作ベースのシャード回復（生の Lucene データをコピーするファイルベースの回復を除く）中に行われます。このオプションは、ネットワーク帯域幅の節約と圧縮および解凍に必要な追加の CPU の間の良いトレードオフです。このオプションがデフォルトです。
- true
- すべてのトランスポートリクエストが圧縮されます。このオプションは、ネットワーク帯域幅の観点で indexing_data よりもパフォーマンスが向上する可能性がありますが、圧縮と解凍作業に最も多くの CPU を必要とします。
transport.compression_scheme
(Static, string) transport.compress 設定によって圧縮が選択されたリクエストの圧縮スキームを構成します。deflate または lz4 のいずれかを受け入れ、圧縮率と CPU 使用率の間の異なるトレードオフを提供します。Elasticsearch は、対応するリクエストと同じ圧縮スキームを応答に使用します。デフォルトは lz4 です。
transport.tcp.keep_alive
(Static, boolean) トランスポートソケットの SO_KEEPALIVE オプションを構成します。これは、TCP keepalive プローブを送信するかどうかを決定します。デフォルトは network.tcp.keep_alive です。
transport.tcp.keep_idle
(Static, integer) トランスポートソケットの TCP_KEEPIDLE オプションを構成します。これは、接続がアイドル状態になるまでの時間（秒）を決定します。デフォルトは network.tcp.keep_idle が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。この値は 300 秒を超えることはできません。システムのデフォルトが 300 よりも高い場合、この値は自動的に 300 に低下します。Linux および macOS のみ適用されます。
transport.tcp.keep_interval
(Static, integer) トランスポートソケットの TCP_KEEPINTVL オプションを構成します。これは、TCP keepalive プローブを送信する間隔（秒）を決定します。デフォルトは network.tcp.keep_interval が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。この値は 300 秒を超えることはできません。システムのデフォルトが 300 よりも高い場合、この値は自動的に 300 に低下します。Linux および macOS のみ適用されます。
transport.tcp.keep_count
(Static, integer) トランスポートソケットの TCP_KEEPCNT オプションを構成します。これは、接続が切断される前に送信される未確認の TCP keepalive プローブの数を決定します。デフォルトは network.tcp.keep_count が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。Linux および macOS のみ適用されます。
transport.tcp.no_delay
(Static, boolean) トランスポートソケットの TCP_NODELAY オプションを構成します。これは、TCP no delay が有効かどうかを決定します。デフォルトは true です。
transport.tcp.reuse_address
(Static, boolean) ネットワークソケットの SO_REUSEADDR オプションを構成します。これは、アドレスを再利用できるかどうかを決定します。デフォルトは network.tcp.reuse_address です。
transport.tcp.send_buffer_size
(Static, byte value) トランスポートトラフィックの TCP 送信バッファのサイズです。デフォルトは network.tcp.send_buffer_size です。
transport.tcp.receive_buffer_size
(Static, byte value) トランスポートトラフィックの TCP 受信バッファのサイズです。デフォルトは network.tcp.receive_buffer_size です。
transport.ping_schedule
(Static, time value) トランスポート接続上でアプリケーションレベルの ping を送信する間隔を構成します。これにより、トランスポート接続が失敗したときに迅速に検出できます。デフォルトは -1 で、アプリケーションレベルの ping は送信されません。可能な限り TCP keepalives (transport.tcp.keep_alive を参照) を使用する必要があります。

トランスポートプロファイル

Elasticsearch は、トランスポートプロファイルを使用して、異なるインターフェースで複数のポートにバインドすることを許可します。この例の設定を参照してください。

Yaml

transport.profiles.default.port: 9300-9400
transport.profiles.default.bind_host: 10.0.0.1
transport.profiles.client.port: 9500-9600
transport.profiles.client.bind_host: 192.168.0.1
transport.profiles.dmz.port: 9700-9800
transport.profiles.dmz.bind_host: 172.16.1.2

default プロファイルは特別です。これは、他のプロファイルに特定の設定が設定されていない場合のフォールバックとして使用され、このノードがクラスター内の他のノードに接続する方法です。他のプロファイルは任意の名前を持つことができ、受信接続のための特定のエンドポイントを設定するために使用できます。

次のパラメータは、上記の例のように各トランスポートプロファイルで構成できます：

port: バインドするポート。
bind_host: バインドするホスト。
publish_host: 情報 API で公開されるホスト。

プロファイルは、トランスポート設定セクションで指定された他のすべてのトランスポート設定もサポートし、これらをデフォルトとして使用します。たとえば、transport.profiles.client.tcp.reuse_address を明示的に構成でき、そうでない場合は transport.tcp.reuse_address にデフォルトします。

長寿命のアイドル接続

2 つのノード間のトランスポート接続は、長期間アイドル状態の TCP 接続の数で構成されています。それにもかかわらず、Elasticsearch はこれらの接続を開いたままにする必要があり、ファイアウォールなどの外部の影響によってノード間の接続が閉じられると、クラスターの操作が中断される可能性があります。Elasticsearch ノード間の長寿命のアイドル接続を保持するためにネットワークを構成することが重要です。たとえば、*.tcp.keep_alive を有効にして、keepalive インターバルがアイドル接続を閉じる原因となる可能性のあるタイムアウトよりも短いことを確認するか、keepalive を構成できない場合は transport.ping_schedule を設定します。特定の年齢に達したときに接続を切断するデバイスは、Elasticsearch クラスターに問題を引き起こす一般的な原因であり、使用してはいけません。

リクエスト圧縮

デフォルトの transport.compress 設定オプション indexing_data は、ノード間の生のインデックスソースデータの輸送に関連するリクエストのみを圧縮します。このオプションは、主にインジェスト、CCR、およびシャード回復中に送信されるデータを圧縮します。このデフォルトは、ローカルクラスター通信に対して通常意味があり、生のドキュメントを圧縮することで、最小限の CPU 影響でノード間のネットワーク使用量を大幅に削減します。

transport.compress 設定は、常にローカルクラスターリクエスト圧縮を構成し、リモートクラスターリクエスト圧縮のフォールバック設定です。リモートリクエスト圧縮をローカルリクエスト圧縮とは異なる方法で構成したい場合は、cluster.remote.${cluster_alias}.transport.compress 設定を使用してリモートクラスターごとに設定できます。

応答圧縮

圧縮設定は応答の圧縮を構成しません。Elasticsearch は、受信リクエストが圧縮されている場合に応答を圧縮します。圧縮が有効でない場合でも、受信リクエストが圧縮されている場合に応答を圧縮します。同様に、受信リクエストが非圧縮の場合、圧縮が有効であっても応答を圧縮しません。応答を圧縮するために使用される圧縮スキームは、リモートノードがリクエストを圧縮するために使用したのと同じスキームになります。

高度なリモートクラスター (API キーベースモデル) 設定

次の高度な設定を使用して、リモートクラスターインターフェース (API キーベースモデル) をトランスポートインターフェースとは独立して構成します。ネットワーク設定を使用して、両方のインターフェースを一緒に構成することもできます。

remote_cluster_server.enabled
(Static, boolean) リモートクラスターサーバーを有効にするかどうかを決定します。この設定は、true でなければならず、remote_cluster.port およびすべての後続のリモートクラスター設定が有効になるために必要です。有効にすると、クラスターは API キーベースモデルを使用してクロスクラスターリクエストを処理できます。デフォルトは false です。
remote_cluster.host
(Static, string) リモートクラスターサーバートラフィックのためのこのノードのアドレスを設定します。このノードはこのアドレスにバインドし、リモートクラスターサーバーの公開アドレスとしても使用します。IP アドレス、ホスト名、または特別な値を受け入れます。この設定は、リモートクラスターサーバーとトランスポートインターフェースの異なる構成が必要な場合にのみ使用してください。
デフォルトは transport.bind_host で指定されたアドレスです。
remote_cluster.bind_host
(Static, string) ノードが受信リモートクラスター接続をリッスンするためにバインドすべきネットワークアドレスです。IP アドレス、ホスト名、および特別な値のリストを受け入れます。デフォルトは remote_cluster.host で指定されたアドレスです。複数のアドレスにバインドする必要がある場合や、公開とバインドに異なるアドレスを使用する必要がある場合、リモートクラスターサーバーとトランスポートインターフェースの異なるバインディング構成が必要な場合にのみこの設定を使用してください。
remote_cluster.publish_host
(Static, string) ノードが他のノードから連絡を受けることができるネットワークアドレスです。IP アドレス、ホスト名、または特別な値を受け入れます。デフォルトは remote_cluster.host で指定されたアドレスです。複数のアドレスにバインドする必要がある場合や、公開とバインドに異なるアドレスを使用する必要がある場合、リモートクラスターサーバーとトランスポートインターフェースの異なるバインディング構成が必要な場合にのみこの設定を使用してください。
remote_cluster.publish_port
(Static, integer) リモートクラスターサーバー公開アドレスのポートです。このパラメータは、公開ポートを remote_cluster.port とは異なるものにする必要がある場合にのみ設定します。デフォルトは remote_cluster.port で割り当てられたポートです。
remote_cluster.tcp.keep_alive
(Static, boolean) リモートクラスターソケットの SO_KEEPALIVE オプションを構成します。これは、TCP keepalive プローブを送信するかどうかを決定します。デフォルトは transport.tcp.keep_alive です。
remote_cluster.tcp.keep_idle
(Static, integer) トランスポートソケットの TCP_KEEPIDLE オプションを構成します。これは、接続がアイドル状態になるまでの時間（秒）を決定します。デフォルトは transport.tcp.keep_idle が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。この値は 300 秒を超えることはできません。システムのデフォルトが 300 よりも高い場合、この値は自動的に 300 に低下します。Linux および macOS のみ適用されます。
remote_cluster.tcp.keep_interval
(Static, integer) トランスポートソケットの TCP_KEEPINTVL オプションを構成します。これは、TCP keepalive プローブを送信する間隔（秒）を決定します。デフォルトは transport.tcp.keep_interval が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。この値は 300 秒を超えることはできません。システムのデフォルトが 300 よりも高い場合、この値は自動的に 300 に低下します。Linux および macOS のみ適用されます。
remote_cluster.tcp.keep_count
(Static, integer) トランスポートソケットの TCP_KEEPCNT オプションを構成します。これは、接続が切断される前に送信される未確認の TCP keepalive プローブの数を決定します。デフォルトは transport.tcp.keep_count が設定されている場合、またはそれ以外の場合はシステムのデフォルトです。Linux および macOS のみ適用されます。
remote_cluster.tcp.no_delay
(Static, boolean) トランスポートソケットの TCP_NODELAY オプションを構成します。これは、TCP no delay が有効かどうかを決定します。デフォルトは transport.tcp.no_delay です。
remote_cluster.tcp.reuse_address
(Static, boolean) ネットワークソケットの SO_REUSEADDR オプションを構成します。これは、アドレスを再利用できるかどうかを決定します。デフォルトは transport.tcp.reuse_address です。
remote_cluster.tcp.send_buffer_size
(Static, byte value) トランスポートトラフィックの TCP 送信バッファのサイズです。デフォルトは transport.tcp.send_buffer_size です。
remote_cluster.tcp.receive_buffer_size
(Static, byte value) トランスポートトラフィックの TCP 受信バッファのサイズです。デフォルトは transport.tcp.receive_buffer_size です。

リクエストトレース

HTTP およびトランスポート層で行われた個々のリクエストをトレースできます。

トレースは、クラスターを不安定にする可能性のある非常に高いログボリュームを生成することがあります。忙しいまたは重要なクラスターでリクエストトレースを有効にしないでください。

REST リクエストトレーサ

HTTP 層には、受信リクエストと対応する出力応答をログに記録する専用のトレーサがあります。org.elasticsearch.http.HttpTracer ロガーのレベルを TRACE に設定することでトレーサを有効にします：

Python

resp = client.cluster.put_settings(
   persistent={
   "logger.org.elasticsearch.http.HttpTracer": "TRACE"
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   "logger.org.elasticsearch.http.HttpTracer": 'TRACE'
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   "logger.org.elasticsearch.http.HttpTracer": "TRACE",
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
   "persistent" : {
   "logger.org.elasticsearch.http.HttpTracer" : "TRACE"
   }
}

どの URI がトレースされるかを制御するために、含めるおよび除外するワイルドカードパターンのセットを使用できます。デフォルトでは、すべてのリクエストがトレースされます。

Python

resp = client.cluster.put_settings(
   persistent={
   "http.tracer.include": "*",
   "http.tracer.exclude": ""
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   'http.tracer.include' => '*',
   'http.tracer.exclude' => ''
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   "http.tracer.include": "*",
   "http.tracer.exclude": "",
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
   "persistent" : {
   "http.tracer.include" : "*",
   "http.tracer.exclude" : ""
   }
}

デフォルトでは、トレーサはこれらのフィルターに一致する各リクエストと応答の概要をログに記録します。各リクエストと応答の本文も記録するには、システムプロパティ es.insecure_network_trace_enabled を true に設定し、org.elasticsearch.http.HttpTracer および org.elasticsearch.http.HttpBodyTracer ロガーのレベルを TRACE に設定します：

Python

resp = client.cluster.put_settings(
   persistent={
   "logger.org.elasticsearch.http.HttpTracer": "TRACE",
   "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE"
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   "logger.org.elasticsearch.http.HttpTracer": 'TRACE',
   "logger.org.elasticsearch.http.HttpBodyTracer": 'TRACE'
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   "logger.org.elasticsearch.http.HttpTracer": "TRACE",
   "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE",
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
   "persistent" : {
   "logger.org.elasticsearch.http.HttpTracer" : "TRACE",
   "logger.org.elasticsearch.http.HttpBodyTracer" : "TRACE"
   }
}

各メッセージ本文は圧縮され、エンコードされ、切り分けられて切り捨てを回避します：

テキスト

[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 1]: H4sIAAAAAAAA/9...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 2]: 2oJ93QyYLWWhcD...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body (gzip compressed, base64-encoded, and split into 2 parts on preceding log lines)

各チャンクには内部リクエスト ID (この例では [276]) が注釈されており、チャンクを対応する要約行と相関させるために使用する必要があります。出力を再構築するには、データを base64 デコードし、gzip を使用して解凍します。たとえば、Unix 系システムでは：

cat httptrace.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

HTTP リクエストおよび応答の本文には、資格情報やキーなどの機密情報が含まれている可能性があるため、HTTP 本文トレースはデフォルトで無効になっています。システムプロパティ es.insecure_network_trace_enabled を true に設定することで、各ノードで明示的に有効にする必要があります。この機能は、機密情報を含まないテストシステムを主に対象としています。このプロパティを機密情報を含むシステムで設定した場合、ログへの不正アクセスから保護する必要があります。

トランスポートトレーサ

トランスポート層には、受信および送信リクエストと応答をログに記録する専用のトレーサがあります。org.elasticsearch.transport.TransportService.tracer ロガーのレベルを TRACE に設定することでトレーサを有効にします：

Python

resp = client.cluster.put_settings(
   persistent={
   "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE"
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   "logger.org.elasticsearch.transport.TransportService.tracer": 'TRACE'
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE",
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
   "persistent" : {
   "logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
   }
}

どのアクションがトレースされるかを制御するために、含めるおよび除外するワイルドカードパターンのセットを使用できます。デフォルトでは、故障検出の ping を除いて、すべてのリクエストがトレースされます：

Python

resp = client.cluster.put_settings(
   persistent={
   "transport.tracer.include": "*",
   "transport.tracer.exclude": "internal:coordination/fault_detection/*"
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   'transport.tracer.include' => '*',
   'transport.tracer.exclude' => 'internal:coordination/fault_detection/*'
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   "transport.tracer.include": "*",
   "transport.tracer.exclude": "internal:coordination/fault_detection/*",
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
   "persistent" : {
   "transport.tracer.include" : "*",
   "transport.tracer.exclude" : "internal:coordination/fault_detection/*"
   }
}

ネットワーキングスレッドモデル

このセクションでは、Elasticsearch のネットワーキングサブシステムで使用されるスレッドモデルについて説明します。この情報は Elasticsearch を使用するために必要ではありませんが、クラスター内のネットワーク問題を診断している高度なユーザーにとっては役立つかもしれません。

Elasticsearch ノードは、TCP チャンネルのコレクションを介して通信し、これらは一緒にトランスポート接続を形成します。Elasticsearch クライアントは HTTP を介してクラスターと通信し、これも 1 つ以上の TCP チャンネルを使用します。これらの TCP チャンネルの各チャンネルは、ノード内の transport_worker スレッドのうちの 1 つによって正確に所有されます。この所有スレッドは、チャンネルが開かれたときに選択され、チャンネルの寿命の間は同じままです。

各 transport_worker スレッドは、所有するチャンネルを介してデータを送受信する責任を単独で負います。さらに、各 HTTP およびトランスポートサーバーソケットは、transport_worker スレッドのいずれかに割り当てられます。そのワーカーは、所有するサーバーソケットへの新しい受信接続を受け入れる責任を負います。

Elasticsearch のスレッドが特定のチャンネルを介してデータを送信したい場合、そのデータを実際の送信のために所有する transport_worker スレッドに渡します。

通常、transport_worker スレッドは受信したメッセージを完全に処理しません。代わりに、少量の予備処理を行い、その後、メッセージを別のスレッドプールに手渡します。たとえば、バルクメッセージは write スレッドプールに手渡され、検索は search スレッドプールのいずれかに手渡され、統計やその他の管理タスクのリクエストは主に management スレッドプールに手渡されます。ただし、メッセージの処理が非常に迅速であると予想される場合、Elasticsearch は他の場所に手渡すオーバーヘッドを負うことなく、transport_worker スレッドで処理をすべて行います。

デフォルトでは、CPU ごとに 1 つの transport_worker スレッドがあります。それに対して、TCP チャンネルは数万に達することがあります。TCP チャンネルにデータが到着し、その所有する transport_worker スレッドがビジー状態の場合、データはスレッドが行っていることを終えるまで処理されません。同様に、出力データは、所有する transport_worker スレッドが空くまでチャンネルを介して送信されません。これは、すべての transport_worker スレッドが頻繁にアイドル状態であることを要求します。アイドル transport_worker は、スタックダンプで次のようになります：

テキスト

"elasticsearch[instance-0000000004][transport_worker][T#1]" #32 daemon prio=5 os_prio=0 cpu=9645.94ms elapsed=501.63s tid=0x00007fb83b6307f0 nid=0x1c4 runnable  [0x00007fb7b8ffe000]
   java.lang.Thread.State: RUNNABLE
    at sun.nio.ch.EPoll.wait(java.base@17.0.2/Native Method)
    at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@17.0.2/EPollSelectorImpl.java:118)
    at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@17.0.2/SelectorImpl.java:129)
    - locked <0x00000000c443c518> (a sun.nio.ch.Util$2)
    - locked <0x00000000c38f7700> (a sun.nio.ch.EPollSelectorImpl)
    at sun.nio.ch.SelectorImpl.select(java.base@17.0.2/SelectorImpl.java:146)
    at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)

ノードのホットスレッド API では、アイドル transport_worker スレッドが次のように報告されます：

テキスト

0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
   10/10 snapshots sharing following 9 elements
   java.base@17.0.2/sun.nio.ch.EPoll.wait(Native Method)
   java.base@17.0.2/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
   java.base@17.0.2/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
   java.base@17.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:146)
   io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
   io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
   io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
   io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
   java.base@17.0.2/java.lang.Thread.run(Thread.java:833)

transport_worker スレッドは常に RUNNABLE 状態であるべきであり、入力を待っているときでさえ、ネイティブ EPoll#wait メソッドでブロックされるためです。idle= 時間は、スレッドが入力を待っている時間の割合を報告し、cpu= 時間は、スレッドが受信した入力を処理している時間の割合を報告します。

transport_worker スレッドが頻繁にアイドル状態でない場合、作業のバックログが蓄積される可能性があります。これにより、所有するチャンネルでのメッセージ処理に遅延が生じる可能性があります。どの作業が遅延するかを正確に予測することは困難です：

チャンネルよりもスレッドがはるかに多くあります。特定のチャンネルに関連する作業がそのワーカースレッドに遅延を引き起こしている場合、そのスレッドが所有する他のすべてのチャンネルも遅延します。
TCP チャンネルからワーカースレッドへのマッピングは固定されていますが、任意です。各チャンネルは、チャンネルが開かれたときにラウンドロビン方式で所有スレッドに割り当てられます。各ワーカースレッドは、さまざまな種類のチャンネルを多数担当します。
各ペアのノード間には多くのチャンネルが開かれています。各リクエストについて、Elasticsearch は適切なチャンネルからラウンドロビン方式で選択します。一部のリクエストは遅延ワーカーが所有するチャンネルに到達し、他の同一のリクエストはスムーズに動作しているチャンネルに送信される可能性があります。

バックログがあまりにも蓄積されると、一部のメッセージが数秒遅延する可能性があります。ノードは、ヘルスチェックに失敗する可能性があり、クラスターから削除されることがあります。時には、ノードのホットスレッド API を使用して、ビジーな transport_worker スレッドの証拠を見つけることができます。ただし、この API 自体はネットワークメッセージを送信するため、transport_worker スレッドがビジーすぎると正しく機能しない可能性があります。スタックダンプを取得するには jstack を使用するか、Java Flight Recorder を使用してプロファイリングトレースを取得する方が信頼性があります。これらのツールは、JVM が実行している作業とは独立しています。

サーバーログから遅延の理由を特定することも可能です。たとえば、次のロガーを参照してください：

org.elasticsearch.transport.InboundHandler
このロガーは、受信メッセージの処理がネットワークスレッドを不合理に長く占有する場合に警告を報告します。これはほぼ確実にバグです。警告には、処理に不合理に長い時間がかかったメッセージを特定するために使用できる情報が含まれています。
org.elasticsearch.transport.OutboundHandler
このロガーは、送信メッセージにかかる時間が予想以上に長い場合に警告を報告します。この期間には、ネットワークの混雑が解消されるのを待つ時間や、同じネットワークスレッドで他の作業を処理するのにかかる時間が含まれるため、ログエントリに指定された送信メッセージに関連するバグが存在することを常に示すわけではありません。
org.elasticsearch.common.network.ThreadWatchdog
このロガーは、ネットワークスレッドが 2 回の連続チェックの間に進展しなかったことに気付いたときに警告とスレッドダンプを報告します。これはほぼ確実にバグです：

テキスト

[WARN ][o.e.c.n.ThreadWatchdog   ] the following threads are active but did not make progress in the preceding [5s]: [elasticsearch[instance-0000000004][transport_worker][T#1]]]
[WARN ][o.e.c.n.ThreadWatchdog   ] hot threads dump due to active threads not making progress [part 1]: H4sIAAAAAAAA/+1aa2/bOBb93l8hYLUYFWgYvWw5AQbYpEkn6STZbJyiwAwGA1qiY8US6ZJUHvPr90qk/JJky41TtDMuUIci...
[WARN ][o.e.c.n.ThreadWatchdog   ] hot threads dump due to active threads not making progress [part 2]: LfXL/x70a3eL8ve6Ral74ZBrp5x7HmUD9KXQz1MaXUNfFC6SeEysxSw1cNXL9JXYl3AigAE7ywbm/AZ+ll3Ox4qXJHNjVr6h...
[WARN ][o.e.c.n.ThreadWatchdog   ] hot threads dump due to active threads not making progress (gzip compressed, base64-encoded, and split into 2 parts on preceding log lines; ...

スレッドダンプを再構築するには、データを base64 デコードし、gzip を使用して解凍します。たとえば、Unix 系システムでは：

cat watchdog.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

このメカニズムは、次の設定で制御できます：

network.thread.watchdog.interval
(Static, time value) ウォッチドッグチェックの間隔を定義します。デフォルトは 5s です。ネットワークスレッドウォッチドッグを無効にするには 0 に設定します。
network.thread.watchdog.quiet_time
(Static, time value) ウォッチドッグ警告の間隔を定義します。デフォルトは 10m です。

ネットワーキング（Networking）

ネットワーキング

ネットワーク構成に注意してください！

一般的に使用されるネットワーク設定

ネットワークアドレスの特別な値

高度なHTTP設定

HTTP クライアントの設定

高度なトランスポート設定

トランスポートプロファイル

Yaml

長寿命のアイドル接続

リクエスト圧縮

応答圧縮

高度なリモートクラスター (API キー ベースモデル) 設定

リクエストトレース

REST リクエストトレーサ

Python

Ruby

Js

コンソール

Python

Ruby

Js

コンソール

Python

Ruby

Js

コンソール

テキスト

トランスポートトレーサ

Python

Ruby

Js

コンソール

Python

Ruby

Js

コンソール

ネットワーキングスレッドモデル

テキスト

テキスト

テキスト

高度なリモートクラスター (API キーベースモデル) 設定