Elasticsearch:yml パラメーターの設定

注意事項

構成の変更

2. yml ファイル構成ページに移動できます。

   1. 左側のナビゲーションウィンドウで、設定と管理 > ES クラスターの設定 をクリックします。

   2. ES クラスター構成ページで、YML 設定 の横にある 設定の編集 をクリックします。

3. YML 設定 ダイアログボックスで、パラメーターを設定します。

   説明

   elasticsearch.yml の内容を表示するには、Kibana コンソールにログインし、GET _cluster/settings?include_defaults コマンドを実行します。

   パラメーター	説明
   自動インデックス	Elasticsearch インスタンスが新しいドキュメントを受信した際に、該当するインデックスが存在しない場合に、システムが自動的にインデックスを作成できるかどうかを指定します。 これは yml ファイル内の action.auto_create_index 設定項目に対応します。デフォルト値は false です。 デフォルトでは、Alibaba Cloud Elasticsearch では自動インデックス作成が許可されていません。以下のいずれかの方法で有効化できます： 重要 自動作成されるインデックスは、ご期待に沿わない可能性があります。この機能を有効化する前に、影響を十分に評価することを推奨します。 コンソールの クラスター設定 ページから有効化します。これは静的 yml 構成であり、インスタンスの再起動をトリガーします。 再起動を必要としない動的手法で迅速に有効化します。Kibana コンソールにログインし、以下のコマンドを使用して自動インデックス作成を許可します： すべてのインデックスの自動作成を許可 PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "true" } } } 重要 この手法では、すべてのインデックスに対して自動作成が有効化されます。true を false に変更すると、無効化できます。 指定したインデックスのみの自動作成を許可。以下の例では、システムインデックスのみの自動作成を許可しています： PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "+.*,-*" } } }
   削除する時にインデックス名の指定	インデックスを削除する際に、インデックス名を明示的に指定する必要があるかどうかを指定します。ワイルドカードを使用して指定 を選択すると、ワイルドカード文字を使用して複数のインデックスを一括削除できます。削除されたインデックスは復元できません。この構成は慎重に使用してください。 これは yml ファイル内の action.destructive_requires_name 設定項目に対応します。デフォルト値は true です。
   監査ログのインデックス作成	有効化すると、Elasticsearch インスタンスに対する create、delete、update、query などの操作に関する監査ログが記録されます。このログ情報はディスク領域を消費し、パフォーマンスに影響を与える可能性があります。有効化しないことを推奨します。この構成は慎重に使用してください。パラメーターの詳細については、「監査ログ (audit log) の設定」をご参照ください。 重要 Elasticsearch 7.x 以降では、コンソールから監査ログを表示できます。ただし、この機能は一部のリージョンでのみ利用可能です。詳細については、「使用制限」をご参照ください。ログを表示するには、まず 監査ログ を有効化する必要があります。詳細については、「ログの照会」をご参照ください。その他のバージョンでは、クラスター内で監査ログを表示する必要があります。たとえば、Kibana コンソールで .security_audit_log-* で始まるインデックスを確認することで監査ログを表示できます。 これは yml ファイル内の xpack.security.audit.enabled 設定項目に対応します。デフォルト値は false です。
   Watcher の有効化	有効化すると、X-Pack の Watcher 機能を使用できます。ディスク領域を大量に消費しないよう、定期的に .watcher-history* インデックスをパージしてください。 これは yml ファイル内の xpack.watcher.enabled 設定項目に対応します。デフォルト値は false です。
   その他の設定	以下は、サポートされている構成項目の一部です。特定の Elasticsearch バージョンが明記されていない限り、これらの項目は Elasticsearch 5.x、6.x、7.x と互換があります。 オリジン間リソース共有 (CORS) アクセスの設定 http.cors.enabled http.cors.allow-origin http.cors.max-age http.cors.allow-methods http.cors.allow-headers http.cors.allow-credentials Reindex ホワイトリストの設定 reindex.remote.whitelist 監査ログ (audit log) の設定 Elasticsearch 7.x および 8.x バージョンでは、xpack.security.audit.logfile.events.include パラメーターの設定のみがサポートされています。5.x および 6.x バージョンでは、以下のパラメーターがサポートされています： xpack.watcher.enabled xpack.notification xpack.security.audit.enabled xpack.security.audit.index.bulk_size xpack.security.audit.index.flush_interval xpack.security.audit.index.rollover xpack.security.audit.index.events.include xpack.security.audit.index.events.exclude xpack.security.audit.index.events.emit_request_body xpack.security.audit.index.settings.index LDAP 機能 5.x を除くすべてのバージョンでサポートされています： xpack.security.authc.realms.ldap1 xpack.security.authc.realms.active_directory1 xpack.security.authc.realms.pki1 xpack.security.authc.realms.saml1 xpack.security.authc.realms.kerberos1 xpack.security.authc.token.enabled キューのサイズ設定 thread_pool.bulk.queue_size（5.x および 6.x バージョン用） thread_pool.write.queue_size（6.x、7.x、8.x バージョン用） thread_pool.search.queue_size カスタム SQL プラグインの構成 xpack.sql.enabled デフォルトでは、Elasticsearch インスタンスは X-Pack に付属する SQL プラグインを有効化しています。カスタム SQL プラグインをアップロードするには、xpack.sql.enabled を false に設定します。
   強制アップデート	yml 構成の変更を強制的に適用するかどうかを制御します。有効な値： 閉じる: このオプションは変更を強制しません。 インプレース変更やブルーグリーン変更など、希望の変更方法を選択できます。 操作の安全性を確保するため、システムはノードの可用性やシャードの割り当てなど、クラスターのヘルスステータスを検証します。 有効化：変更が強制されます。システムはノード障害や未割り当てシャードなど、クラスターの健全性ステータスを無視します。これにより、再起動フェーズ中にサービスの不安定化が発生する可能性があります。
   アップデートモード	yml ファイル構成の変更を適用する方法を制御します。有効な値： 説明 「変更方法」は、強制アップデート パラメーターが 閉じる に設定されている場合にのみ設定する必要があります。 ローリングアップデート（デフォルト）：クラスター内のノードに対してローリング方式で変更を適用します。この方法ではデータのコピーは不要であり、所要時間はデータ量に影響されませんが、クラスターのパフォーマンスに一定の影響を与えます。 ブルーグリーンリリースの変更：クラスターに同数の新規ノードを追加し、データをコピーした後、サービスを新規ノードにシームレスに切り替えます。このプロセスは比較的スムーズですが、所要時間が長く、ノードの IP アドレスが変更されます。 変更方法の詳細については、「変更方法」をご参照ください。

   重要

   • yml ファイルの構成変更は、クラスターのローリングリスタートをトリガーします。クラスター内のインデックスにレプリカが存在し、クラスター負荷が正常（CPU 使用率約 60 %、ヒープメモリ使用率約 50 %、load_1m が CPU コア数未満）である場合、再起動中もサービスの可用性は維持されます。再起動の所要時間は、クラスター規模、データ量、負荷によって異なります。非ピーク時間帯にこの操作を実行することを推奨します。

   • クラスター負荷が高い場合、またはインデックスにレプリカがない場合、あるいは多数の書き込みまたはクエリ操作を伴うビジネスの場合、変更処理中に一時的なアクセスタイムアウトが発生する可能性があります。ビジネスへの影響を軽減するため、クライアントのアクセススクリプトにリトライ機構を構成することを推奨します。

   • インスタンスの yml 構成に対してスケールアウトまたはスケールインなどのブルー・グリーン変更が進行中で、インスタンスステータスが「適用中」の場合、追加の変更にはインプレース変更方法のみを使用できます。「変更履歴の表示」から、yml 構成に対してブルー・グリーン変更が進行中かどうかを確認できます。

4. この操作は、インスタンスを再起動します。確認してから操作を行ってください。 を選択し、OK をクリックします。

   確認後、Elasticsearch インスタンスが再起動します。進行状況は「タスク一覧」で確認できます。インスタンスの再起動が完了すると、yml ファイルの構成が完了します。

オリジン間リソース共有 (CORS) アクセスの設定

Reindex API ホワイトリストの設定

マルチクラスター間データ移行のセキュリティを確保するため、ES_2 クラスターのプライベートネットワーク接続アドレスおよび通信ポート番号を、ES_1 の Reindex API ホワイトリストに追加する必要があります。

1. ES_1 の セキュリティ ページに移動します。次に、プライベート接続の設定 をクリックし、さらに 編集 をクリックします。プライベート接続の設定 サイドバーで、対象の エンドポイント ID をクリックします。

   

2. VPC コンソールの エンドポイント接続 タブで、エンドポイント ID の横にある アイコンをクリックして、対応するドメイン名を表示します。

   重要

   Reindex API ホワイトリストを構成する前に、ドメイン名からゾーン情報を削除する必要があります。

   たとえば、完全なドメイン名が「ep-bp1****************-cn-hangzhou-i.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com」の場合、ゾーン情報「-cn-hangzhou-i」を削除して、最終的なドメイン名「ep-bp1bp1****************.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com」を取得します。

   

3. ES_1 の yml ファイルで Reindex API ホワイトリストを構成できます。ホワイトリストには、エンドポイントのドメイン名および通信ポートを含める必要があります。

   reindex:
     remote:
       whitelist: >-
         ep-bp1bp1****************.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com:9200

   

監査ログ (audit log) の設定

7.x 以降

1. YML 設定 パネルに移動します。

   詳細については、「構成の変更」をご参照ください。

2. 有効化 を 監査ログのインデックス作成 パラメーターで選択することで、監査ログを有効化できます。

3. 監査ログの構成をカスタマイズします。

   監査ログを有効化した後、その他の設定 内で xpack.security.audit.logfile.events.include パラメーターを構成できます。以下の例を参照してください。

   xpack:
     security:
       audit:
         logfile:
           events:
             include the following: >-
               access_denied,anonymous_access_denied,authentication_failed,connection_denied,tampered_request,run_as_denied,run_as_granted

   重要

   • 7.x 以降のインスタンスでは、xpack.security.audit.logfile.events.include パラメーターのみを構成できます。

   • デフォルトの監査ログ構成では、拒否または失敗したリクエストの監査ログのみ出力されます。成功したリクエストの監査ログを取得するには、access_granted イベントを追加する必要があります。これを追加すると、すべてのアクセス情報がディスクに保存されるため、ディスク使用率が高くなる可能性があります。トラブルシューティングが完了したら、監査ログ機能を無効化することを推奨します。

4. 監査ログを表示できます。

   7.x 以降のインスタンスでは、監査ログ検索 を有効化することで、コンソールの ログ照会 ページで監査ログを表示できます。詳細については、「ログの照会」をご参照ください。監査ログ機能は、特定のリージョンでのみ利用可能です。詳細については、「使用制限」をご参照ください。

5.x および 6.x

1. YML 設定 パネルに移動します。

   詳細については、「yml ファイル構成」をご参照ください。

2. 監査ログの有効化を行うには、監査ログのインデックス作成 パラメーターに対して 監査ログ検索の開始 を選択します。

   以下は、監査ログのインデックス化のデフォルト構成です。必要に応じて調整できます。

   xpack.security.audit.index.bulk_size: 5000
   xpack.security.audit.index.events.emit_request_body: false
   xpack.security.audit.index.events.exclude: run_as_denied,anonymous_access_denied,realm_authentication_failed,access_denied,connection_denied
   xpack.security.audit.index.events.include the following: authentication_failed,access_granted,tampered_request,connection_granted,run_as_granted
   xpack.security.audit.index.flush_interval: 180s
   xpack.security.audit.index.rollover: hourly
   xpack.security.audit.index.settings.index.number_of_replicas: 1
   xpack.security.audit.index.settings.index.number_of_shards: 10

   構成	デフォルト設定	説明
   xpack.security.audit.index.bulk_size	1000	複数の監査イベントを監査ログインデックスにバッチで書き込む場合、書き込むイベント数を設定するために使用できます。
   xpack.security.audit.index.flush_interval	1s	バッファリングされたイベントをインデックスにフラッシュする頻度を制御します。
   xpack.security.audit.index.rollover	daily	新しいインデックスへのローリングオーバーの頻度を制御します。hourly、daily、weekly、または monthly を設定できます。
   xpack.security.audit.logfile.events.include	access_denied,anonymous_access_denied,authentication_failed, connection_denied,tampered_request,run_as_denied,run_as_granted	監査ログに収集可能な監査ログイベントを制御します。監査ログ機能は一部のリージョンでのみ利用可能です。詳細については、「使用制限」をご参照ください。イベントタイプの完全な一覧については、「監査イベントタイプ (7.x)」をご参照ください。
   xpack.security.audit.index.events.include	access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted	監査ログインデックスに書き込まれる監査ログイベントを制御します。これは 5.x および 6.x インスタンスでのみサポートされています。イベントタイプの完全な一覧については、「監査イベントタイプ (6.x)」をご参照ください。
   xpack.security.audit.index.events.exclude	null（デフォルトでは、イベントは処理されません）	インデックス構築時に除外する監査ログイベントです。
   xpack.security.audit.index.events.emit_request_body	false	authentication_failed などの特定のイベントタイプがトリガーされた際、REST 経由で送信されたリクエストボディを無視するか含めるかを指定します。

   警告

   監査ログに RequestBody 情報が含まれている場合、ログファイル内に機密情報が公開される可能性があります。

3. 監査ログを表示します。

   5.x および 6.x インスタンスでは、監査ログが有効化されると、監査ログファイルが .security_audit_log-* で始まるインデックス名で Elasticsearch インスタンスに出力されます。したがって、Kibana コンソールで .security_audit_log-* で始まるインデックスを確認することで監査ログを表示できます。

   重要

   監査ログインデックスはインスタンスのストレージ領域を消費します。Elasticsearch では自動的な有効期限およびパージポリシーがサポートされていないため、古い監査ログインデックスを手動でパージする必要があります。

4. （任意） 監査ログの保存に使用するインデックスシャードを構成します。

   5.x および 6.x インスタンスでは、xpack.security.audit.index.settings を使用して、監査ログの保存に使用するインデックスシャードを構成できます。以下の構成では、監査ログインデックスのシャード数およびレプリカ数を 1 に設定しています。

   xpack.security.audit.index.settings:
     index:
       number_of_shards: 1
       number_of_replicas: 1

   説明

   構成パラメーターを渡して監査ログインデックスを生成する場合は、監査ログインデックスの有効化（xpack.security.audit.enabled を true に設定）時にこの構成を含めてください。そうしない場合、監査ログインデックスは number_of_shards: 5 および number_of_replicas: 1 のデフォルト構成を使用します。

キューのサイズ設定