第33章コンテナーログの集計

33.1. 概要
リンクのコピー

OpenShift Container Platform のクラスター管理者として、EFK スタックをデプロイして各種の OpenShift Container Platform サービスのログを集計できます。アプリケーション開発者は、表示アクセス権を持つプロジェクトのログを表示することができます。EFK スタックは、複数のコンテナーまたは削除された Pod からのものであっても、ホストとアプリケーションからログを集計します。

EFK スタックは ELK スタックの変更バージョンであり、以下で構成されています。

Elasticsearch (ES): すべてのログが格納されるオブジェクトストア。
Fluentd: ノードからログを収集し、そのログを Elasticsearch に送ります。
Kibana: Elasticsearch の Web UI。

クラスターにデプロイされると、スタックはすべてのノードおよびプロジェクトのログを Elasticsearch に集計し、ログを表示するために Kibana UI を提供します。クラスター管理者はすべてのログを表示できますが、アプリケーション開発者は表示権限を持つプロジェクトのログのみを表示できます。スタックのコンポーネントは安全な通信を実行します。

注記

「Docker コンテナーログの管理」では、コンテナーログを管理し、ノードディスクが満杯になることを阻止するための json-file ロギングドライバーオプションの使用について説明しています。

33.2. デプロイ前の設定
リンクのコピー

Ansible Playbook は集計されたロギングをデプロイおよびアップグレードするために利用できます。『クラスターのインストールガイド』を十分に理解しておくようにしてください。このセクションでは、Ansible を使用する準備に必要な情報と設定に関する情報を提供します。EFK スタックの各種の領域を設定するために、パラメーターが Ansible インベントリーファイルに追加されています。
「サイジングのガイドライン」を確認して、デプロイメントの最適な設定方法を判断してください。
クラスターのルーターをデプロイしていることを確認します。
Elasticsearch に必要なストレージがあることを確認します。各 Elasticsearch レプリカに独自のストレージボリュームが必要であることに注意してください。詳細については、「Elasticsearch」を参照してください。
プロジェクトを選択します。デプロイされたら、EFK スタックは OpenShift Container Platform クラスター内のすべてのプロジェクトのログを収集します。このセクションの例では、デフォルトのプロジェクトロギング を使用しています。プロジェクトがまだ存在していない場合は、Ansible Playbook によってプロジェクトが作成されます。プロジェクトに対してノードセレクターを指定する場合にのみ、プロジェクトを作成する必要があります。そうしない場合は、openshift-logging ロールによってプロジェクトが作成されます。
```
$ oc adm new-project logging --node-selector=""
$ oc project logging
```
注記
Fluentd はクラスター全体にデプロイする必要があり、セレクターによって Fluentd がデプロイされる場所が制限されるため、プロジェクトには空のノードセレクターを指定することをお勧めします。コンポーネントの配置を制御するには、コンポーネントごとにノードセレクターを指定して、デプロイメント設定に適用する必要があります。

33.3. ロギング Ansible 変数の指定
リンクのコピー

EFK デプロイメントのパラメーターをインベントリーホストファイルに指定して、デフォルトを上書きすることができます。パラメーターを選択する前に、「Elasticsearch」と「Fluentd」のセクションを参照してください。

注記

デフォルトでは、Elasticsearch サービスはクラスターのノード間での TCP 通信にポート 9300 を使用します。

Expand

パラメーター	説明
`openshift_logging_use_ops`	`true` に設定されている場合、操作ログに対して 2 番目の Elasticsearch クラスターと Kibana を設定します。Fluentd はメインクラスターと操作ログ用に予約されているクラスター (default、openshift、openshift-infra の各プロジェクトのログ、Docker、OpenShift、およびジャーナルのシステムログで構成される) の間でログを分割します。これにより、2 番目の Elasticsearch クラスターと Kibana がデプロイされます。デプロイメントは名前に含まれる -ops サフィックスで見分けることができ、以下に一覧表示されている並列デプロイメントオプションがあります。並列デプロイメントオプションについては、「Curator 設定の作成」で説明されています。
`openshift_logging_master_url`	Kubernetes マスターの URL。これは公開されている必要はありませんが、クラスター内からアクセスできる必要があります (例: https://<PRIVATE-MASTER-URL>:8443)。
`openshift_logging_master_public_url`	Kubernetes マスターの公開された URL。これは、Kibana プロキシーによる認証のリダイレクトに使用されます (例: https://<CONSOLE-PUBLIC-URL-MASTER>:8443)。
`openshift_logging`	集計されたロギングがデプロイされる namespace。
`openshift_logging_install_logging`	ロギングをインストールする場合は `true` に設定します。ロギングをアンインストールする場合は `false` に設定します。
`openshift_logging_purge_logging`	通常のアンインストールでは、再インストール中の予期せぬデータ損失を防ぐために PVC が維持されます。Ansible Playbook が完全かつ不可逆的にすべてのロギング永続データ (PVC を含む) を確実に削除するようにするには、`openshift_logging_install_logging` を 'false' に設定してアンインストールをトリガーし、`openshift_logging_purge_logging` を 'true' に設定します。デフォルトでは 'false' に設定されています。
`openshift_logging_install_eventrouter`	`openshift_logging_install_logging` と併用します。いずれも 'true' に設定されている場合は、eventrouter がインストールされ、'false' に設定されている場合は、eventrouter がアンインストールされます。
`openshift_logging_eventrouter_image_prefix`	eventrouter のロギングイメージのプレフィックス
`openshift_logging_eventrouter_image_version`	ロギング eventrouter のイメージバージョン
`openshift_logging_eventrouter_sink`	eventrouter のシンク (受信側) を選択します。`stdout` と `glog` がサポートされています。デフォルトでは `stdout` に設定されています。
`openshift_logging_eventrouter_nodeselector`	Pod が到達するノードを選択するためのラベルのマップ (`"node":"infra"`、`"region":"west"` など)。
`openshift_logging_eventrouter_replicas`	デフォルトでは '1' に設定されます。
`openshift_logging_eventrouter_cpu_limit`	eventrouter に割り当てる最小 CPU 量。デフォルトでは '100m' に設定されます。
`openshift_logging_eventrouter_memory_limit`	eventrouter Pod のメモリー制限。デフォルトでは '128Mi' に設定されます。
`openshift_logging_eventrouter_namespace`	eventrouter がデプロイされる project。デフォルトでは 'default' に設定されます。重要プロジェクトを `default` または `openshift-*` 以外に設定しないでください。異なるプロジェクトを指定する場合、他のプロジェクトからのイベント情報が運用ユーザーに制限されていないインデックスにリークされる可能性があります。デフォルト以外のプロジェクトを使用するには、`oc new-project` を使用して通常の方法でプロジェクトを作成します。
`openshift_logging_image_pull_secret`	認証済みレジストリーからコンポーネントイメージをプルするために使用される既存のプルシークレットの名前を指定します。
`openshift_logging_curator_default_days`	ログレコードを削除するために Curator が使用するデフォルトの最小期間 (日単位)。
`openshift_logging_curator_run_hour`	Curator が実行される時刻 (時間)。
`openshift_logging_curator_run_minute`	Curator が実行される時刻 (分)。
`openshift_logging_curator_run_timezone`	実行時間を割り出すために Curator が使用するタイムゾーン。タイムゾーンは、`America/New_York` または `UTC` など、tzselect(8) または timedatectl(1) の "リージョン/ローカリティー" 形式の文字列で指定します。
`openshift_logging_curator_script_log_level`	Curator のスクリプトログレベル。
`openshift_logging_curator_log_level`	Curator プロセスのログレベル。
`openshift_logging_curator_cpu_limit`	Curator に割り当てる CPU 量。
`openshift_logging_curator_memory_limit`	Curator に割り当てるメモリー量。
`openshift_logging_curator_nodeselector`	Curator インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。
`openshift_logging_curator_ops_cpu_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_curator_cpu_limit` と同等です。
`openshift_logging_curator_ops_memory_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_curator_memory_limit` と同等です。
`openshift_logging_kibana_hostname`	Kibana に到達する Web クライアントの外部ホスト名。
`openshift_logging_kibana_cpu_limit`	Kibana に割り当てる CPU 量。
`openshift_logging_kibana_memory_limit`	Kibana に割り当てるメモリー量。
`openshift_logging_kibana_proxy_debug`	`true` の場合、Kibana プロキシーのログレベルを DEBUG に設定します。
`openshift_logging_kibana_proxy_cpu_limit`	Kibana プロキシーに割り当てる CPU 量。
`openshift_logging_kibana_proxy_memory_limit`	Kibana プロキシーに割り当てるメモリー量。
`openshift_logging_kibana_replica_count`	Kibana を拡張して達成するレプリカ数。
`openshift_logging_kibana_nodeselector`	Kibana インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。
`openshift_logging_kibana_env_vars`	{"ELASTICSEARCH_REQUESTTIMEOUT":"30000"} など、Kibana デプロイメント設定に追加する環境変数のマッピング。
`openshift_logging_kibana_key`	Kibana ルートの作成時に使用する公開されているキー。
`openshift_logging_kibana_cert`	Kibana ルートの作成時にキーに一致する証明書。
`openshift_logging_kibana_ca`	オプション。キーに添付する CA と、Kibana ルートの作成時に使用される証明書。
`openshift_logging_kibana_ops_hostname`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_hostname` と同等です。
`openshift_logging_kibana_ops_cpu_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_cpu_limit` と同等です。
`openshift_logging_kibana_ops_memory_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_memory_limit` と同等です。
`openshift_logging_kibana_ops_proxy_debug`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_proxy_debug` と同等です。
`openshift_logging_kibana_ops_proxy_cpu_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_proxy_cpu_limit` と同等です。
`openshift_logging_kibana_ops_proxy_memory_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_proxy_memory_limit` と同等です。
`openshift_logging_kibana_ops_replica_count`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_kibana_replica_count` と同等です。
`openshift_logging_es_allow_external`	`true` に設定すると、Elasticsearch を re-encrypt ルートとして公開します。デフォルトでは `false` に設定されます。
`openshift_logging_es_hostname`	ルートと TLS サーバーの証明書に使用する外部向けホスト名。デフォルトでは `es` に設定されます。たとえば、`openshift_master_default_subdomain` が `=example.test` に設定されている場合、`openshift_logging_es_hostname` のデフォルト値は `es.example.test` になります。
`openshift_logging_es_cert`	Elasticsearch が外部 TLS サーバー証明書に使用する証明書の場所。デフォルトは、生成される証明書になります。
`openshift_logging_es_key`	Elasticsearch が外部 TLS サーバー証明書に使用するキーの場所。デフォルトは、生成されるキーになります。
`openshift_logging_es_ca_ext`	Elasticsearch が外部 TLS サーバーに使用する CA 証明書の場所。デフォルトは内部 CA です。
`openshift_logging_es_ops_allow_external`	`true` に設定すると、Elasticsearch が re-encrypt ルートとして公開されます。デフォルトでは `false` に設定されます。
`openshift_logging_es_ops_hostname`	ルートと TLS サーバー証明書に使用する外部向けホスト名。デフォルトでは `es-ops` に設定されます。たとえば、`openshift_master_default_subdomain` が `=example.test` に設定されている場合、`openshift_logging_es_ops_hostname` のデフォルト値は `es-ops.example.test` になります。
`openshift_logging_es_ops_cert`	Elasticsearch が外部 TLS サーバー証明書に使用する証明書の場所。デフォルトは、生成される証明書になります。
`openshift_logging_es_ops_key`	Elasticsearch が外部 TLS サーバー証明書に使用するキーの場所。デフォルトは、生成されるキーになります。
`openshift_logging_es_ops_ca_ext`	Elasticsearch が外部 TLS サーバーに使用する CA 証明書の場所。デフォルトは内部 CA です。
`openshift_logging_fluentd_nodeselector`	Fluentd インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。Fluentd を実行する必要があるノード (通常はすべて) には、Fluentd が実行およびログ収集できるようになる前に、このラベルを付ける必要があります。インストール後に Aggregated Logging クラスターを拡張する際に、`openshift_logging` ロールがこのノードセレクターを使用して `openshift_logging_fluentd_hosts` によって提供されるノードにラベルを付けます。インストールの一環として、Fluentd ノードセレクターのラベルを永続化されたノードラベルの一覧に追加することをお勧めします。
`openshift_logging_fluentd_cpu_limit`	Fluentd Pod の CPU 上限。
`openshift_logging_fluentd_memory_limit`	Fluentd Pod のメモリー上限。
`openshift_logging_fluentd_journal_read_from_head`	最初の起動時に Fluentd がジャーナルの先頭から読み取る必要がある場合は、`true` に設定します。これを使用することで、現在のログレコードを受信する ES で遅延が発生する可能性があります。
`openshift_logging_fluentd_hosts`	Fluentd をデプロイするためにラベルを付ける必要があるノードの一覧。デフォルトでは、全ノードに ['--all'] のラベルを付けます。null 値は `openshift_logging_fluentd_hosts={}` です。Fluentd Pod を起動するには、DaemonSet の `nodeSelector` を、['host1.example.com', 'host2.example.com'] などの有効なラベルに更新します。
`openshift_logging_fluentd_audit_container_engine`	`openshift_logging_fluentd_audit_container_engine` が `true` に設定されている場合には、コンテナーエンジンの監査ログが収集され、ES に保存されます。この変数を有効にすると、EFK が指定の監査ログファイルか、デフォルトの `/var/log/audit.log` ファイルを監視することができ、プラットフォームのコンテナーエンジンに関する監査情報を収集して、Kibana に配置します。
`openshift_logging_fluentd_audit_file`	監査ログファイルの場所。デフォルトは `/var/log/audit/audit.log` です。この変数を有効にすると、EFK が指定の監査ログファイルか、デフォルトの `/var/log/audit.log` ファイルを監視することができ、プラットフォームのコンテナーエンジンに関する監査情報を収集して、Kibana に配置します。
`openshift_logging_fluentd_audit_pos_file`	監査ログファイルの Fluentd `in_tail` の位置ファイルが配置される場所。デフォルトは `/var/log/audit/audit.log` です。この変数を有効にすると、EFK が指定の監査ログファイルか、デフォルトの `/var/log/audit.log` ファイルを監視することができ、プラットフォームのコンテナーエンジンに関する監査情報を収集して、Kibana に配置します。
`openshift_logging_es_host`	Fluentd がログを送信する必要がある ES サービスの名前。
`openshift_logging_es_port`	Fluentd がログを送信する必要がある ES サービスのポート。
`openshift_logging_es_ca`	Fluentd が `openshift_logging_es_host` との通信に使用する CA の場所。
`openshift_logging_es_client_cert`	Fluentd が `openshift_logging_es_host` に使用するクライアント証明書の場所。
`openshift_logging_es_client_key`	Fluentd が `openshift_logging_es_host` に使用するクライアントキーの場所。
`openshift_logging_es_cluster_size`	デプロイする Elasticsearch レプリカ。冗長性を実現するには 3 つ以上のレプリカが必要です。
`openshift_logging_es_cpu_limit`	ES クラスターの CPU 量の上限。
`openshift_logging_es_memory_limit`	Elasticsearch インスタンスごとに予約する RAM 容量。512 M 以上である必要があります。使用可能なサフィックスは G、g、M、m です。
`openshift_logging_es_number_of_replicas`	すべての新規インデックスのプライマリーシャードごとのレプリカシャード数。デフォルトは '0' に設定されています。実稼働環境のクラスターに対しては、`1` 以上を設定することが推奨されます。
`openshift_logging_es_number_of_shards`	ES で作成される新規インデックスごとのプライマリシャード数。デフォルトは '1' に設定されます。
`openshift_logging_es_pv_selector`	特定の PV を選択するために PVC に追加されるキー/値のマップ。
`openshift_logging_es_pvc_dynamic`	バッキングストレージを動的にプロビジョニングするには、パラメーターの値を `true` に設定します。`true` に設定すると、storageClass の仕様が PVC から省略されます。`openshift_logging_es_pvc_storage_class_name` のパラメーターの値を設定すると、この値は、`openshift_logging_es_pvc_dynamic` パラメーターの値を上書きします。
`openshift_logging_es_pvc_storage_class_name`	デフォルト以外のストレージクラスを使用するには、`glusterprovisioner` または `cephrbdprovisioner` などのストレージクラス名を指定します。ストレージクラス名を指定した後には、openshift_logging_es_pvc_dynamic の値が何であっても、動的ボリュームプロビジョニングがアクティブになります。
`openshift_logging_es_pvc_size`	Elasticsearch インスタンスごとに作成する Persistent Volume Claim (永続ボリューム要求) のサイズ (例: 100 G)。省略する場合は、PVC が作成されず、代わりに一時ボリュームが使用されます。
`openshift_logging_es_pvc_prefix`	Elasticsearch インスタンスのストレージとして使用される Persistent Volume Claim (永続ボリューム要求) の名前のプレフィックス。logging-es-1 のように、インスタンスごとに数字が付加されます。まだ存在していない場合は、サイズ `es-pvc-size` を使用して作成されます。 `openshift_logging_es_pvc_prefix` が設定されている場合: `openshift_logging_es_pvc_dynamic`=`true` であると、`openshift_logging_es_pvc_size` の値はオプションになります。 `openshift_logging_es_pvc_dynamic`=`false` であると、`openshift_logging_es_pvc_size` の値を設定する必要があります。
`openshift_logging_es_recover_after_time`	リカバリーを試みる前に ES が待機する時間。
`openshift_logging_es_storage_group`	Elasticsearch ストレージボリュームにアクセスするための補助グループ ID の数。バッキングボリュームはこのグループ ID によるアクセスを許可する必要があります。
`openshift_logging_es_nodeselector`	Elasticsearch インスタンスをデプロイできるターゲットのノードを判断するマップとして指定されているノードセレクター。このノードセレクターは、Elasticsearch インスタンスの実行用に予約または最適化されているノードにこれらのインスタンスを配置するために使用することができます。たとえば、セレクターは `{"node-type":"infrastructure"}` と指定できます。Elasticsearch をデプロイする前に、少なくとも 1 つのアクティブノードにこのラベルを付ける必要があります。
`openshift_logging_es_ops_host`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_host` と同等です。
`openshift_logging_es_ops_port`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_port` と同等です。
`openshift_logging_es_ops_ca`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_ca` と同等です。
`openshift_logging_es_ops_client_cert`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_client_cert` と同等です。
`openshift_logging_es_ops_client_key`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_client_key` と同等です。
`openshift_logging_es_ops_cluster_size`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_cluster_size` と同等です。
`openshift_logging_es_ops_cpu_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_cpu_limit` と同等です。
`openshift_logging_es_ops_memory_limit`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_memory_limit` と同等です。
`openshift_logging_es_ops_pv_selector`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_pv_selector` と同等です。
`openshift_logging_es_ops_pvc_dynamic`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_pvc_dynamic` と同等です。
`openshift_logging_es_ops_pvc_size`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_pvc_size` と同等です。
`openshift_logging_es_ops_pvc_prefix`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_pvc_prefix` と同等です。
`openshift_logging_es_ops_recover_after_time`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_recovery_after_time` と同等です。
`openshift_logging_es_ops_storage_group`	`openshift_logging_use_ops` が `true` に設定されている場合は、Ops クラスターの `openshift_logging_es_storage_group` と同等です。
`openshift_logging_es_ops_nodeselector`	Elasticsearch インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。このノードセレクターは、Elasticsearch インスタンスの実行用に予約または最適化されているノード上にこれらのインスタンスを配置するために使用できます。たとえば、セレクターは `node-type=infrastructure` と指定できます。Elasticsearch をデプロイする前に、少なくとも 1 つのアクティブノードにこのラベルを付ける必要があります。
`openshift_logging_elasticsearch_kibana_index_mode`	デフォルト値 `unique` では、各ユーザーが独自の Kibana インデックスを持つことができます。このモードでは、保存されたクエリー、ビジュアライゼーション、およびダッシュボードは共有されません。値 `shared_ops` を設定することもできます。このモードでは、すべての操作ユーザーが Kibana インデックスを共有します。これにより、各操作ユーザーが同じクエリー、ビジュアライゼーション、およびダッシュボードを参照することができます。操作ユーザーであるかどうかを判別するには、以下を実行します。 `#oc auth can-i view pod/logs -n default yes` 適切なアクセスがない場合は、クラスター管理者にお問い合わせください。
`openshift_logging_kibana_ops_nodeselector`	Kibana インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。
`openshift_logging_curator_ops_nodeselector`	Curator インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。

カスタム証明書

デプロイメントプロセスで生成されるものを利用する代わりに、以下のインベントリー変数を使用してカスタム証明書を指定できます。カスタム証明書は、ユーザーのブラウザーと Kibana 間の通信を暗号化し、保護するために使用されます。これらが指定されない場合は、セキュリティー関連のファイルが生成されます。

Expand

ファイル名	説明
`openshift_logging_kibana_cert`	Kibana サーバーのブラウザー向けの証明書。
`openshift_logging_kibana_key`	ブラウザー向けの Kibana 証明書で使用されるキー。
`openshift_logging_kibana_ca`	ブラウザー向けの Kibana 証明書用に使用される CA ファイルへの制御ノード上の絶対パス。
`openshift_logging_kibana_ops_cert`	Ops Kibana サーバーのブラウザー向け証明書。
`openshift_logging_kibana_ops_key`	ブラウザー向けの Ops Kibana 証明書で使用されるキー。
`openshift_logging_kibana_ops_ca`	ブラウザー向けの Ops Kibana 証明書用に使用される CA ファイルへの制御ノード上の絶対パス。

33.4. EFK スタックのデプロイ
リンクのコピー

EFK スタックは Ansible Playbook を使用して EFK コンポーネントにデプロイされます。デフォルトのインベントリーファイルを使用して、デフォルトの OpenShift Ansible の場所から Playbook を実行します。

$ ansible-playbook [-i </path/to/inventory>] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

Playbook を実行すると、スタックをサポートするために必要なすべてのリソース (シークレット、ServiceAccount、DeploymentConfig など) がデプロイされます。Playbook はスタックが実行されるまでコンポーネント Pod のデプロイを待機します。待機手順が失敗しても、デプロイメントは成功する可能性があります。つまり、レジストリーからコンポーネントイメージを取得できる場合があります。これには数分の時間がかかる可能性があります。以下を使用してプロセスを確認できます。

$ oc get pods -w

最終的に Pod のステータスは Running になります。関連イベントの取得によるデプロイメント時の Pod のステータスを確認するには、以下を実行します。

$ oc describe pods/<pod_name>

Pod の実行に失敗したら、ログを確認してください。

$ oc logs -f <pod_name>

33.5. デプロイメントの概要と調整
リンクのコピー

このセクションでは、デプロイされたコンポーネントに対して行うことができる調整について説明します。

33.5.1. Ops クラスター
リンクのコピー

注記

default、openshift、および openshift-infra プロジェクトのログが自動的に集計され、Kibana インターフェースで .operations 項目にグループ化されます。

EFK スタックをデプロイしたプロジェクト (ここでは logging) は .operations に集計 されず、その ID の下に表示されます。

インベントリーファイルで openshift_logging_use_ops を true に設定した場合、Fluentd はメインの Elasticsearch クラスターと操作ログ用に予約された別のクラスター間でログを分割するように設定されます。この操作ログはノードシステムログおよびプロジェクト default、openshift、openshift-infra として定義されています。したがって、操作ログのインデックス化、アクセス、管理を行うために個別の Elasticsearch クラスター、個別の Kibana、および個別の Curator がデプロイされます。これらのデプロイメントは、-ops を含む名前によって区別されます。このオプションを有効にする場合は、これらの個別のデプロイメントに留意してください。-ops が含まれるという名前の変更はありますが、以下の説明の大部分が操作クラスターにも適用されます (存在する場合)。

33.5.2. Elasticsearch
リンクのコピー

高可用性環境には、それぞれが別のホスト上にある Elasticsearch のレプリカが少なくとも 3 つ必要です。Elasticsearch レプリカには各自のストレージが必要ですが、OpenShift Container Platform のデプロイメント設定ではすべての Pod 間でストレージボリュームを共有します。そのため、拡張時には、EFK デプロイヤーによって Elasticsearch の各レプリカに各自のデプロイメント設定が行われます。

インベントリーファイルで openshift_logging_es_cluster_size を変更し、ロギング Playbook を再実行することで、作成後にクラスターを拡張することができます。追加のクラスタリングパラメーターは変更可能で、「ロギング Ansible 変数の指定」で説明されています。

以下に示すようにストレージおよびネットワークの場所を選択する際の留意事項については、Elastic のドキュメントを参照してください。

すべての Elasticsearch デプロイメントの表示

現在の Elasticsearch デプロイメントをすべて表示するには、以下を実行します。

$ oc get dc --selector logging-infra=elasticsearch

ノードセレクター

Elasticsearch は大量のリソースを使用する可能性があるため、クラスターのすべてのメンバーでは、メンバー同士およびリモートストレージとのネットワーク接続の待機時間を短く設定する必要があります。待機時間を短く設定するには、ノードセレクターを使用してインスタンスを専用ノード、つまりクラスター内の専用リージョンに指定します。

ノードセレクターを設定するには、インベントリーファイルで openshift_logging_es_nodeselector 設定オプションを指定します。これはすべての Elasticsearch デプロイメントに適用されます。そのため、ノードセレクターを個別化する必要がある場合は、デプロイメント後に各デプロイメント設定を手動で編集する必要があります。ノードセレクターは Python と互換性のある dict (辞書) として指定されます。たとえば、{"node-type":"infra", "region":"east"} のようになります。

永続的な Elasticsearch ストレージ

デフォルトでは、openshift_logging Ansible ロールは Pod のすべてのデータが再起動時に消失する一時デプロイメントを作成します。実稼働環境での使用では、Elasticsearch デプロイメント設定ごとに永続ストレージボリュームを指定します。デプロイ前に必要な Persistent Volume Claim (永続ボリューム要求) を作成するか、またはそれらを独自に作成されるようにできます。PVC には openshift_logging_es_pvc_prefix 設定 (デフォルトでは logging-es-) と一致する名前を付ける必要があります。各 PVC 名には連番が追加され、logging-es-1、logging-es-2 などのようになります。デプロイメントに必要な PVC がすでに存在する場合は、その PVC が使用されます。PVC が存在せず、openshift_logging_es_pvc_size が指定されている場合は、そのサイズ要求を使用して PVC が作成されます。

警告

Lucene は NFS でサポートされていないファイルシステムの動作に依存するため、NFS ストレージをボリュームまたは永続ボリュームとして (または Gluster などの NAS を介して) 使用することは Elasticsearch ストレージではサポートされません。その場合、データ破損やその他の問題が発生する可能性があります。NFS ストレージが要件である場合は、大規模なファイルをボリュームに配置してストレージデバイスとして使用し、1 つのホスト上でそれをローカルにマウントすることができます。たとえば、NFS ストレージボリュームが /nfs/storage にマウントされている場合は、以下のようになります。

$ truncate -s 1T /nfs/storage/elasticsearch-1
$ mkfs.xfs /nfs/storage/elasticsearch-1
$ mount -o loop /nfs/storage/elasticsearch-1 /usr/local/es-storage
$ chown 1000:1000 /usr/local/es-storage

次に、以下で説明するように /usr/local/es-storage をホストマウントとして使用します。異なるバッキングファイルをそれぞれの Elasticsearch レプリカのストレージとして使用します。

このループバックはノード上で、OpenShift Container Platform の外部から手動で保守する必要があります。コンテナー内から保守することはできません。

各ノードホスト上のローカルディスクボリューム (利用可能な場合) を Elasticsearch レプリカのストレージとして使用することができます。これを実行するには、以下のような準備が必要です。

関連するサービスアカウントに、ローカルボリュームをマウントし、編集する権限を指定する必要があります。
```
$ oc adm policy add-scc-to-user privileged  \
       system:serviceaccount:logging:aggregated-logging-elasticsearch 
```
1
1
ロギング Playbook を実行する際に、以前に作成したプロジェクトを使用します (例: logging)。

それぞれの Elasticsearch レプリカの定義にパッチを適用し、その権限を要求する必要があります。以下に例を示します (Ops クラスターの場合は --selector component=es-ops に変更)。

$ for dc in $(oc get deploymentconfig --selector component=es -o name); do
    oc scale $dc --replicas=0
    oc patch $dc \
       -p '{"spec":{"template":{"spec":{"containers":[{"name":"elasticsearch","securityContext":{"privileged": true}}]}}}}'
  done

Elasticsearch レプリカは、ローカルストレージを使用するために適切なノード上に配置する必要があります。また、適切なノードが一定期間ダウンしている場合であっても、移動させてはなりません。この場合は、管理者がストレージを割り当てたノードに対して一意のノードセレクターを各 Elasticsearch レプリカに提供する必要があります。ノードセレクターを設定するには、各 Elasticsearch デプロイメント設定を編集し、nodeSelector セクションを追加または編集して、必要な各ノードに対して適用した一意のラベルを指定します。
```
apiVersion: v1
kind: DeploymentConfig
spec:
  template:
    spec:
      nodeSelector:
        logging-es-node: "1" 
```
1
1
このラベル (この場合は logging-es-node=1) が付与されている単一のノードを持つレプリカを、ラベルによって一意に識別する必要があります。oc label コマンドを使用して、必要に応じてノードにラベルを適用してください。
代わりに oc patch コマンドを使用して、ノードセレクターの適用を自動化することもできます。
```
$ oc patch dc/logging-es-<suffix> \
   -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-es-node":"1"}}}}}'
```
これらの手順を実行すると、この例 (ストレージが各ノードの同じパスにマウントされていることを前提とします) のように、ローカルホストのマウントを各レプリカに適用できます (Ops クラスターの場合は --selector component=es-ops に変更します)。
```
$ for dc in $(oc get deploymentconfig --selector component=es -o name); do
    oc set volume $dc \
          --add --overwrite --name=elasticsearch-storage \
          --type=hostPath --path=/usr/local/es-storage
    oc rollout latest $dc
    oc scale $dc --replicas=1
  done
```

Elasticsearch のスケールの変更

クラスターで使用される Elasticsearch インスタンスの数を増やす必要がある場合、このタスクは永続ボリュームの特性や、データの保存やクラスターのリカバリーに関する Elasticsearch の設定方法により、Elasticsearch デプロイメント設定の拡張ほど簡単に実行できません。また、拡張時には各 Elasticsearch クラスターノードのデプロイメント設定を作成する必要があります。

Elasticsearch のスケールを変更する最も簡単な方法は、前述のようにインベントリーホストファイルを変更し、ロギング Playbook を再実行することです。デプロイメント用に永続ストレージが提供されていると仮定すると、この方法によって混乱が生じることはないはずです。

注記

新しい openshift_logging_es_cluster_size の値が、クラスターにある現在の Elasticsearch のノード数 (スケールアップした後) より大きい場合のみ、ロギング Playbook を使用して Elasticsearch クラスターのサイズを調節できます。

カスタマイズを維持する必要があるなどの理由で再インストールを希望しない場合は、デプロイヤーによって提供されるテンプレートを使用して、新規の Elasticsearch デプロイメント設定をクラスターに追加することができます。ただし、これにはより複雑な手順が必要になります。

ルートとしての Elasticsearch の公開

デフォルトでは、OpenShift の集計ロギングでデプロイされた Elasticsearch はロギングクラスターの外部からアクセスできません。データにアクセスする必要があるツールに対しては、Elasticsearch への外部アクセスのルートを有効にすることができます。

OpenShift トークンを使用して Elasticsearch にアクセスできます。また、サーバー証明書を作成する際に (Kibana と同様に)、外部の Elasticsearch および Elasticsearch Ops ホスト名を指定することができます。

re-encrypt ルートとして Elasticsearch にアクセスするには、以下の変数を定義します。
```
openshift_logging_es_allow_external=True
openshift_logging_es_hostname=elasticsearch.example.com
```

以下の Ansible Playbook を実行します。

$ ansible-playbook [-i </path/to/inventory>] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

Elasticsearch にリモートでログインするには、要求に 3 つの HTTP ヘッダーが含まれている必要があります。
```
Authorization: Bearer $token
X-Proxy-Remote-User: $username
X-Forwarded-For: $ip_address
```
ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。以下は例になります。
```
$ oc login <user1>
$ oc new-project <user1project>
$ oc new-app <httpd-example>
```
要求内で使用するこの ServiceAccount のトークンを取得する必要があります。
```
$ token=$(oc whoami -t)
```

以前に設定したトークンを使用して、公開ルート経由で Elasticsearch にアクセスできる必要があります。

$ curl -k -H "Authorization: Bearer $token" -H "X-Proxy-Remote-User: $(oc whoami)" -H "X-Forwarded-For: 127.0.0.1" https://es.example.test/project.my-project.*/_search?q=level:err | python -mjson.tool

33.5.3. Fluentd
リンクのコピー

Fluentd はノードラベルセレクターに従ってレプリカをデプロイする DeamonSet としてデプロイされます。ノードラベルセレクターはインベントリーパラメーター openshift_logging_fluentd_nodeselector を使用して指定することができ、デフォルトは logging-infra-fluentd です。OpenShift クラスターのインストールの一環として、Fluentd ノードセレクターを永続化されたノードラベルの一覧に追加することが推奨されます。

Fluentd は journald をシステムログソースとして使用します。これらは、オペレーティングシステム、コンテナーランタイム、および OpenShift からのログメッセージです。

利用可能なコンテナーのランタイムでは、ログメッセージのソースを特定するための最小限の情報が提供されます。ログ収集およびログの正規化は、Pod が削除されてから行われるので、ラベルまたはアノテーションなどの追加のメタデータが API サーバーから取得できません。

ログコレクターがログの処理を完了する前に、特定の名前および namespace が指定された Pod が削除された場合には、よく似た名前の Pod および namespace とログメッセージを区別する方法がなくなる可能性があります。これにより、ログがインデックス化され、Pod をデプロイしたユーザーが所有していないインデックスにアノテーションが付けられる可能性があります。

重要

利用可能なコンテナーのランタイムでは、ログメッセージのソースを特定するための最小限の情報が提供され、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、その出処を突き止められるわけではありません。

OpenShift Container Platform 3.9 のクリーンインストールではデフォルトのログドライバーとして json-file を使用します。ただし、OpenShift Container Platform 3.7 からアップグレードされた環境では既存の journald ログドライバーの設定が維持されます。json-file ログドライバーを使用することが推奨されます。既存のログドライバー設定を json-file に変更する手順については、「集計されたロギングドライバーの変更」を参照してください。

外部ログアグリゲーターにログを送信するための Fluentd の設定

secure-forward プラグインを使用して、デフォルトの Elasticsearch ではなく外部のログアグリゲーターにログのコピーを送信するように Fluentd を設定することができます。ここから、ローカルでホストされている Fluentd によるログレコードの処理後に、さらなるログの処理が可能です。

ロギングデプロイメントでは、外部アグリゲーターを設定するための secure-forward.conf セクションが Fluentd configmap に用意されています。

<store>
@type secure_forward
self_hostname pod-${HOSTNAME}
shared_key thisisasharedkey
secure yes
enable_strict_verification yes
ca_cert_path /etc/fluent/keys/your_ca_cert
ca_private_key_path /etc/fluent/keys/your_private_key
ca_private_key_passphrase passphrase
<server>
  host ose1.example.com
  port 24284
</server>
<server>
  host ose2.example.com
  port 24284
  standby
</server>
<server>
  host ose3.example.com
  port 24284
  standby
</server>
</store>

oc edit コマンドを使用して更新できます。

$ oc edit configmap/logging-fluentd

secure-forward.conf で使用される証明書を Fluentd Pod にマウントされる既存のシークレットに追加することができます。your_ca_cert と your_private_key の値は configmap/logging-fluentd の secure-forward.conf で指定されている値と一致している必要があります。

$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 /path/to/your_ca_cert.pem)'}]"
$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 /path/to/your_private_key.pem)'}]"

注記

your_private_key は、汎用名に置き換えます。これは、JSON パスへのリンクで、お使いのホストシステムのパスではありません。

外部アグリゲーターを設定する際は、Fluentd からのメッセージを安全に受信できる必要があります。

外部アグリゲーターが別の Fluentd サーバーである場合、fluent-plugin-secure-forward プラグインがインストールされていて、それによって提供される入力プラグインを使用する必要があります。

<source>
  @type secure_forward

  self_hostname ${HOSTNAME}
  bind 0.0.0.0
  port 24284

  shared_key thisisasharedkey

  secure yes
  cert_path        /path/for/certificate/cert.pem
  private_key_path /path/for/certificate/key.pem
  private_key_passphrase secret_foo_bar_baz
</source>

fluent-plugin-secure-forward リポジトリーに fluent-plugin-secure-forward プラグインの設定方法に関する詳細の説明があります。

Fluentd から API サーバーへの接続数の削減

重要

mux はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

mux は Secure Forward のリスナーサービスです。

Expand

パラメーター	説明
`openshift_logging_use_mux`	デフォルトは `False` に設定されています。`True` に設定されている場合は、`mux` というサービスがデプロイされます。このサービスは、クラスターで実行されるノードエージェント Fluentd deamonset の Fluentd `secure_forward` アグリゲーターとして機能します。`openshift_logging_use_mux` を使用して OpenShift API サーバーへの接続数を減らし、生ログを `mux` に送信して Kubernetes メタデータプラグインをオフにするように Fluentd の各ノードを設定します。これには、`openshift_logging_mux_client_mode` を使用する必要があります。
`openshift_logging_mux_client_mode`	`openshift_logging_mux_client_mode` の値は `minimal` と `maximal` です。デフォルトはありません。`openshift_logging_mux_client_mode` により、Fluentd ノードエージェントは、ログを Elasticsearch に直接送信するのではなく mux に送信します。値 `maximal` は、Fluentd がレコードを `mux` に送信する前にできるだけ多くの処理をノードで実行することを意味しています。`maximal` 値は `mux` を使用する場合に推奨されます。値 `minimal` は、Fluentd がまったく処理を行わないことを意味しており、処理用に生ログを `mux` に送信します。`minimal` 値の使用は推奨されません。
`openshift_logging_mux_allow_external`	デフォルトは `False` に設定されます。`True` に設定されている場合は、`mux` サービスがデプロイされ、クラスターの外部で実行されている Fluentd クライアントが `secure_forward` を使用してログを送信できるように設定されます。これにより、OpenShift ロギングを OpenShift 以外のクライアント、または他の OpenShift クラスターの中央ロギングサービスとして使用することができます。
`openshift_logging_mux_hostname`	デフォルトは `mux` に `openshift_master_default_subdomain` を追加した値です。これは、`external_clients` が `mux` に接続するために使用するホスト名であり、TLS サーバーの証明書サブジェクトで使用されます。
`openshift_logging_mux_port`	24284
`openshift_logging_mux_cpu_limit`	500M
`openshift_logging_mux_memory_limit`	1Gi
`openshift_logging_mux_default_namespaces`	デフォルトは `mux-undefined` です。一覧の最初の値は未定義のプロジェクトに使用する namespace であり、これにデフォルトで作成する追加の namespace が続きます。通常、この値を設定する必要はありません。
`openshift_logging_mux_namespaces`	デフォルト値は空であり、外部の `mux` クライアント向けに追加の namespace を作成し、ログと関連付けることができます。この値を設定する必要があります。

Fluentd でのログのスロットリング

特に冗長なプロジェクトについては、管理者は処理される前の Fluentd によるログの読み取り速度を減速することができます。

警告

スロットリングは設定されたプロジェクトのログ集計が遅れる一因になる可能性があります。Fluentd が追い付く前に Pod が削除された場合、ログエントリーが消失する可能性があります。

注記

Systemd ジャーナルをログソースとして使用している場合、スロットリングは機能しません。スロットリングの実装は、各プロジェクトの個々のログファイルの読み取りを調整できる機能によって決まります。ジャーナルからの読み取り時に、単一のログソースしか存在せず、ログファイルは存在しないと、ファイルベースのスロットリングは利用できません。Fluentd プロセスに読み込まれるログエントリーを制限する方法はありません。

Fluentd に対して制限する必要があるプロジェクトを指示するには、デプロイメント後に ConfigMap のスロットル設定を編集します。

$ oc edit configmap/logging-fluentd

throttle-config.yaml キーの形式は、プロジェクト名と、各ノードでのログの読み取りに必要な速度が含まれる YAML ファイルです。デフォルトはノードごとに一度に 1,000 行です。以下に例を示します。

プロジェクト

project-name:
  read_lines_limit: 50

second-project-name:
  read_lines_limit: 100

ロギング

logging:
  read_lines_limit: 500

test-project:
  read_lines_limit: 10

.operations:
  read_lines_limit: 100

EFK スタックのいずれかの部分を変更する場合は (具体的には Elasticsearch または Fluentd)、まず Elasicsearch をゼロにスケールダウンして、他のノードと一致しないように Fluentd を調整する必要があります。次に、変更を行って、Elasicsearch と Fluentd のスケールを元に戻します。

Elasicsearch をゼロに調整するには、以下を実行します。

$ oc scale --replicas=0 dc/<ELASTICSEARCH_DC>

デーモンセット設定の nodeSelector がゼロに一致するように変更します。

Fluentd ノードセレクターの取得:

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       logging-infra-fluentd: "true"

oc patch コマンドでの deamonset の nodeSelector 変更:

$ oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"nonexistlabel":"true"}}}}}'

Fluentd ノードセレクターの取得:

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       "nonexistlabel: "true"

Elastcsearch のサイズをゼロから元に戻します。

$ oc scale --replicas=# dc/<ELASTICSEARCH_DC>

deamonset 設定の nodeSelector を変更して logging-infra-fluentd: "true" に戻します。

oc patch コマンドでの deamonset の nodeSelector 変更:

oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd":"true"}}}}}'

33.5.4. Kibana
リンクのコピー

OpenShift Container Platform の Web コンソールから Kibana コンソールにアクセスするには、マスター webconsole-config configmap ファイルに loggingPublicURL パラメーターを追加し、Kibana コンソールの URL (kibana-hostname パラメーター) を指定します。値は HTTPS URL である必要があります。

...
clusterInfo:
  ...
  loggingPublicURL: "https://kibana.example.com"
...

loggingPublicURL パラメーターを設定すると、OpenShift Container Platform Web コンソールの Browse Pods <pod_name> Logs タブに View Archive ボタンが作成されます。このボタンは Kibana コンソールにリンクします。

通常通り Kiabana デプロイメントを拡張して冗長性を実現できます。

$ oc scale dc/logging-kibana --replicas=2

注記

ロギング Playbook の複数の実行にわたってスケールを維持するには、インベントリーファイルの openshift_logging_kibana_replica_count を必ず更新してください。

openshift_logging_kibana_hostname 変数によって指定されたサイトにアクセスすることで、ユーザーインターフェースを確認できます。

Kibana に関する詳細については、Kibana のドキュメントを参照してください。

Kibana Visualize

Kibana Visualize を使用すると、視覚化機能やダッシュボードを作成してコンテナーを監視できます。また Pod ログにより、管理者ユーザー (cluster-admin または cluster-reader) はデプロイメント、namespace、Pod、およびコンテナーごとにログを表示することができます。

Kibana Visualize は Elasticsearch および ES-OPS Pod 内に存在し、それらの Pod 内で実行する必要があります。ダッシュボードとその他の Kibana UI オブジェクトを読み込むには、まずはダッシュボードに追加するユーザーとして Kibana にログインしてから、ログアウトする必要があります。これにより、以下の手順で使用するユーザーごとの必要な設定が作成されます。次に、以下を実行します。

$ oc exec <$espod> -- es_load_kibana_ui_objects <user-name>

ここで、$espod はいずれかの Elasticsearch Pod の名前です。

33.5.5. Curator
リンクのコピー

Curator を利用することで、管理者はスケジュールされた Elasticsearch のメンテナンス操作を設定し、プロジェクトごとに自動的に実行することができます。これは、設定に基づいてアクションを毎日実行するようにスケジュール設定されています。Elasticsearch クラスターごとに 1 つの Curator Pod のみを使用することが推奨されます。Curator は以下の構造を持つ YAML 設定ファイルで設定されます。

$PROJECT_NAME:
  $ACTION:
    $UNIT: $VALUE

$PROJECT_NAME:
  $ACTION:
    $UNIT: $VALUE
 ...

利用可能なパラメーターを以下に示します。

Expand

変数名	説明
`PROJECT_NAME`	プロジェクトの実際の名前 (myapp-devel など)。OpenShift Container Platform の操作ログについては、名前 `.operations` をプロジェクト名として使用します。
`ACTION`	実行するアクション。現在許可されているのは `delete` のみです。
`UNIT`	`days`、`weeks`、または `months` のいずれか。
`VALUE`	単位数を示す整数。
`.defaults`	`.defaults` を `$PROJECT_NAME` として使用して、指定されていないプロジェクトのデフォルトを設定します。
`runhour`	(数値) Curator ジョブを実行する時刻 (時、24 時間形式)。`.defaults` で使用します。
`runminute`	(数値) Curator ジョブを実行する時刻 (分)。`.defaults` で使用します。
`timezone`	(文字列) tzselect(8) または timedatectl(1) 形式での文字列。デフォルトのタイムゾーンは UTC です。
`.regex`	プロジェクト名に一致する正規表現の一覧。
`pattern`	適切にエスケープされた有効な正規表現パターン。一重引用符で囲まれています。

たとえば、以下のように Curator を設定します。

1 day を経過した myapp-dev プロジェクトのインデックスを削除する
1 week を経過した myapp-qe プロジェクトのインデックスを削除する
8 weeks を経過したoperations ログを削除する
31 days を経過したその他すべてのプロジェクトのインデックスを削除する
毎日午前 0 時に Curator ジョブを実行する

以下を使用します。

config.yaml: |
  myapp-dev:
    delete:
      days: 1

  myapp-qe:
    delete:
      weeks: 1

  .operations:
    delete:
      weeks: 8

  .defaults:
    delete:
      days: 31
    runhour: 0
    runminute: 0
    timezone: America/New_York

  .regex:
    - pattern: '^project\..+\-dev\..*$'
      delete:
        days: 15
    - pattern: '^project\..+\-test\..*$'
      delete:
        days: 30

重要

month を操作の $UNIT として使用する場合、Curator は今月の当日ではなく、今月の最初の日からカウントを開始します。たとえば、今日が 4 月 15 日であり、現時点で 2 カ月を経過したインデックスを削除する場合 (delete: months: 2)、Curator は 2 月 15 日より古い日付のインデックスを削除するのではなく、2 月 1 日より古いインデックスを削除します。つまり、今月の最初の日付まで遡り、次にその日付から丸 2 カ月遡ります。Curator で厳密な指定を行うための最適な方法として、日数で指定することができます (例: delete: days: 30)。

33.5.5.1. Curator 設定の作成
リンクのコピー

openshift_logging Ansible ロールは、Curator が設定の読み取りに使用する ConfigMap を提供します。この ConfigMap を編集するか、または置き換えることで、Curator を再設定することができます。現時点で、Ops および非 Ops 両方の Curator インスタンスを設定するために logging-curator ConfigMap が使用されています。.operations 設定はすべてアプリケーションログ設定と同じ場所にあります。

提供された ConfigMap を編集して Curator インスタンスを設定するには、以下を実行します。
```
$ oc edit configmap/logging-curator
```

提供された ConfigMap を置換するには、以下を実行します。

$ create /path/to/mycuratorconfig.yaml
$ oc create configmap logging-curator -o yaml \
  --from-file=config.yaml=/path/to/mycuratorconfig.yaml | \
  oc replace -f -

変更を行った後に、Curator を再デプロイします。

$ oc rollout latest dc/logging-curator
$ oc rollout latest dc/logging-curator-ops

33.6. クリーンアップ
リンクのコピー

デプロイメント中に生成されたものをすべて削除します。

$ ansible-playbook [-i </path/to/inventory>] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml \
    -e openshift_logging_install_logging=False

33.7. Kibana のトラブルシューティング
リンクのコピー

OpenShift Container Platform で Kibana コンソールを使用することで発生する可能性がある問題は簡単に解決できますが、この場合役に立つエラーメッセージは表示されません。OpenShift Container Platform に Kibana をデプロイする際に問題が発生した場合は、以下のトラブルシューティングセクションを確認してください。

ログインループ

Kibana コンソールの OAuth2 プロキシーはマスターホストの OAuth2 サーバーとシークレットを共有する必要があります。シークレットが両方のサーバーで同一でない場合はログインループが発生する可能性があり、Kibana のログインページに継続的にリダイレクトされます。

この問題を修正するには、現在の OAuthClient を削除し、openshift-ansible を使用して openshift_logging ロールを再実行します。

$ oc delete oauthclient/kibana-proxy
$ ansible-playbook [-i </path/to/inventory>] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

コンソール表示時の不明なエラー

Kibana コンソールにアクセスしようとする際に、以下のブラウザーエラーが表示される場合があります。

{"error":"invalid_request","error_description":"The request is missing a required parameter,
 includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."}

このエラーは、OAuth2 クライアントとサーバー間の不一致が原因で発生します。ログイン後にサーバーが安全にリダイレクトできるように、クライアントのリターンアドレスがホワイトリストで指定されている必要があります。

この問題を修正するには、OAuthClient エントリーを置き換えます。

$ oc delete oauthclient/kibana-proxy
$ ansible-playbook [-i </path/to/inventory>] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

問題が解決しない場合は、OAuth クライアントに一覧表示されている URL の Kibana にアクセスしていることを確認してください。この問題は、転送先ポート (標準の 443 HTTPS ポートではなく 1443 など) の URL にアクセスすることで発生する可能性があります。OAuth クライアントを編集することで、サーバーのホワイトリストを調整できます。

$ oc edit oauthclient/kibana-proxy

コンソール表示時の 503 エラー

Kibana コンソールを表示する時にプロキシーエラーが発生する場合は、2 つの問題のうちのいずれかが原因である可能性があります。

1 つ目の問題は、Kibana が Pod を認識していない可能性があります。Elasticsearch の起動が遅い場合、Kibana はそれに到達しようとしてタイムアウトする場合があります。関連サービスにエンドポイントがあるかどうか確認してください。

$ oc describe service logging-kibana
Name:                   logging-kibana
[...]
Endpoints:              <none>

Kibana Pod が実行中である場合、エンドポイントが一覧表示されます。実行中でない場合は、Kibana Pod とデプロイメントの状態を確認してください。デプロイメントをスケールダウンして、再び元に戻さなければならない場合があります。

考えられる 2 つ目の問題として、Kibana サービスにアクセスするためのルートがマスクされている場合に発生する可能性があります。これは、あるプロジェクトでテストデプロイメントを実行し、次に最初のデプロイメントを完全に削除することなく別のプロジェクトでデプロイした場合に発生する可能性があります。複数のルートが同じ宛先に送信される場合、デフォルトルーターは最初に作成されたルートにのみルーティングします。問題が発生するルートをチェックして、そのルートが複数の場所で定義されているかどうかを確認してください。

$ oc get route  --all-namespaces --selector logging-infra=support

F-5 ロードバランサーと有効にされた X-Forwarded-For

X-Forwarded-For が有効にされた Kibana の前に F-5 ロードバランサーの使用を試みる場合、Elasticsearch Searchguard プラグインが Kibana からの接続を適切に受け取ることができないという問題が発生する可能性があります。

Kibana のエラーメッセージの例

Kibana: Unknown error while connecting to Elasticsearch

Error: Unknown error while connecting to Elasticsearch
Error: UnknownHostException[No trusted proxies]

余分なヘッダーを無視するように Searchguard を設定するには、以下の手順を実行します。

すべての Fluentd Pod をスケールダウンします。
Fluentd Pod の終了後に Elasticsearch をスケールダウンします。
searchguard.http.xforwardedfor.header: DUMMY を Elasticsearch の設定セクションに追加します。
```
$ oc edit configmap/logging-elasticsearch 
```
1
1
この方法では、Elasticsearch の設定が ConfigMap に含まれている必要があります。
Elasticsearch を拡張して元に戻します。
すべての Fluentd Pod を拡張します。

33.8. 外部 Elasticsearch インスタンスへのログの送信
リンクのコピー

Fluentd は、Elasticsearch デプロイメント設定の ES_HOST、ES_PORT、OPS_HOST、および OPS_PORT 環境変数の値にログを送信します。アプリケーションログは ES_HOST の宛先に、操作ログは OPS_HOST の宛先に送信されます。

注記

AWS Elasticsearch インスタンスへのログの直接送信はサポートされていません。Fluentd Secure Forward を使用して、fluent-plugin-aws-elasticsearch-service プラグインで設定した制御対象の Fluentd のインスタンスにログを送信してください。

ログを特定の Elasticsearch インスタンスに送信するには、デプロイメント設定を編集して、上記の変数の値を必要なインスタンスに置き換えます。

$ oc edit dc/<deployment_configuration>

外部 Elasticsearch インスタンスにアプリケーションログと操作ログの両方を含めるには、ES_HOST と OPS_HOST を同じ宛先に設定して、ES_PORT と OPS_PORT にも同一の値があるようにします。

外部でホストされている Elasticsearch インスタンスが TLS を使用していない場合、_CLIENT_CERT、_CLIENT_KEY、_CA 変数を空になるように更新します。TLS を使用していてもそれが Mutual TLS ではない場合は、_CLIENT_CERT と _CLIENT_KEY 変数を空になるように更新し、logging-fluentd シークレットについて、Elasticsearch インスタンスと通信するための適切な _CA 値でパッチを適用するか再作成します。指定された Elasticsearch インスタンスと同様に Mutual TLS を使用している場合、logging-fluentd シークレットについて、クライアントキー、クライアント証明書、CA を使ってパッチを適用するか再作成します。

注記

指定された Kibana と Elasticsearch イメージを使用していない場合、同じマルチテナント機能は利用できず、データは特定のプロジェクトへのユーザーアクセスによる制限を受けません。

33.9. 外部 syslog サーバーへのログの送信
リンクのコピー

fluent-plugin-remote-syslog プラグインをホストで使用して、ログを外部 syslog サーバーに送信します。

環境変数を logging-fluentd または logging-mux デプロイメント設定で設定します。

- name: REMOTE_SYSLOG_HOST


  value: host1
- name: REMOTE_SYSLOG_HOST_BACKUP
  value: host2
- name: REMOTE_SYSLOG_PORT_BACKUP
  value: 5555

1: 必要なリモート syslog ホスト。各ホストで必須です。

これによって 2 つの宛先が作成されます。host1 の syslog サーバーはデフォルトポート 514 でメッセージを受信し、host2 は同じメッセージをポート 5555 で受信します。

または、独自のカスタム fluent.conf を logging-fluentd または logging-mux ConfigMap に設定できます。

Fluentd 環境変数

Expand

パラメーター	説明
`USE_REMOTE_SYSLOG`	デフォルトは `false` です。`fluent-plugin-remote-syslog` gem を使用できるようにするには、`true` に設定します。
`REMOTE_SYSLOG_HOST`	(必須) リモート syslog サーバーのホスト名または IP アドレス。
`REMOTE_SYSLOG_PORT`	接続先のポート番号。デフォルトは `514` です。
`REMOTE_SYSLOG_SEVERITY`	syslog の重大度を設定します。デフォルトは `debug` です。
`REMOTE_SYSLOG_FACILITY`	syslog ファシリティーを設定します。デフォルトは `local0` です。
`REMOTE_SYSLOG_USE_RECORD`	デフォルトは `false` です。レコードの重大度フィールドおよびファシリティーフィールドを使用して syslog メッセージに設定するには、`true` に設定します。
`REMOTE_SYSLOG_REMOVE_TAG_PREFIX`	タグからプレフィックスを削除します。デフォルトは `''` (空) です。
`REMOTE_SYSLOG_TAG_KEY`	これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。
`REMOTE_SYSLOG_PAYLOAD_KEY`	これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。

警告

この実装は安全ではないため、接続にスヌーピングがないことを保証できる環境でのみ使用してください。

Fluentd ロギング Ansible 変数

Expand

パラメーター	説明
`openshift_logging_fluentd_remote_syslog`	デフォルトは `false` に設定されます。fluent-plugin-remote-syslog gem を使用できるようにするには、`true` に設定します。
`openshift_logging_fluentd_remote_syslog_host`	リモート syslog サーバーのホスト名または IP アドレス。必須です。
`openshift_logging_fluentd_remote_syslog_port`	接続先のポート番号。デフォルトは `514` です。
`openshift_logging_fluentd_remote_syslog_severity`	syslog の重大度を設定します。デフォルトは `debug` です。
`openshift_logging_fluentd_remote_syslog_facility`	syslog ファシリティーを設定します。デフォルトは `local0` です。
`openshift_logging_fluentd_remote_syslog_use_record`	デフォルトは `false` に設定されます。レコードの重大度フィールドおよびファシリティーフィールドを使用して syslog メッセージに設定するには、`true` に設定します。
`openshift_logging_fluentd_remote_syslog_remove_tag_prefix`	タグからプレフィックスを削除します。デフォルトは `''` (空) です。
`openshift_logging_fluentd_remote_syslog_tag_key`	文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。
`openshift_logging_fluentd_remote_syslog_payload_key`	文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。

Mux ロギング Ansible 変数

Expand

パラメーター	説明
`openshift_logging_mux_remote_syslog`	デフォルトは `false` に設定されます。fluent-plugin-remote-syslog gem を使用できるようにするには、`true` に設定します。
`openshift_logging_mux_remote_syslog_host`	リモート syslog サーバーのホスト名または IP アドレス。必須です。
`openshift_logging_mux_remote_syslog_port`	接続先のポート番号。デフォルトは `514` です。
`openshift_logging_mux_remote_syslog_severity`	syslog の重大度を設定します。デフォルトは `debug` です。
`openshift_logging_mux_remote_syslog_facility`	syslog ファシリティーを設定します。デフォルトは `local0` です。
`openshift_logging_mux_remote_syslog_use_record`	デフォルトは `false` に設定されます。レコードの重大度フィールドおよびファシリティーフィールドを使用して syslog メッセージに設定するには、`true` に設定します。
`openshift_logging_mux_remote_syslog_remove_tag_prefix`	タグからプレフィックスを削除します。デフォルトは `''` (空) です。
`openshift_logging_mux_remote_syslog_tag_key`	文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。
`openshift_logging_mux_remote_syslog_payload_key`	文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。

33.10. Elasticsearch 管理操作の実行
リンクのコピー

Elasticsearch と通信して管理操作を実行するのに使用する管理者の証明書、キー、CA は、logging-elasticsearch シークレット内にあります。

注記

これらが EFK インストールにあるかどうかを確認するには、以下のコマンドを実行します。

$ oc describe secret logging-elasticsearch

メンテナンスを実行しようとしているクラスター内にある Elasticsearch Pod に接続します。
Pod をクラスター内で検索するには、以下のいずれかのコマンドを使用します。
```
$ oc get pods -l component=es -o name | head -1
$ oc get pods -l component=es-ops -o name | head -1
```
Pod に接続します。
```
$ oc rsh <your_Elasticsearch_pod>
```
Elasticsearch コンテナーに接続すると、インデックス API のマニュアルに従い、シークレットからマウントされた証明書を使用して Elasticsearch と通信することができます。
Fluentd では、インデックス形式 project.{project_name}.{project_uuid}.YYYY.MM.DD を使用してログを Elasticsearch に送信します。ここで、YYYY.MM.DD はログレコードの日付です。
たとえば uuid が 3b3594fa-2ccd-11e6-acb7-0eb6b35eaee3 の logging プロジェクトから 2016 年 6 月 15 日以降のすべてのログを削除するには、以下のコマンドを実行します。
```
$ curl --key /etc/elasticsearch/secret/admin-key \
  --cert /etc/elasticsearch/secret/admin-cert \
  --cacert /etc/elasticsearch/secret/admin-ca -XDELETE \
  "https://localhost:9200/project.logging.3b3594fa-2ccd-11e6-acb7-0eb6b35eaee3.2016.06.15"
```

33.11. 集計されたロギングのドライバーの変更
リンクのコピー

集計されたロギングについては、json-file ログドライバーの使用を推奨します。

重要

json-file ドライバーを使用する場合は、Docker バージョン docker-1.12.6-55.gitc4618fb.el7_4 now 以降を使用していることを確認してください。

Fluentd では、/etc/docker/daemon.json ファイルおよび /etc/sysconfig/docker ファイルをチェックして、Docker が使用しているドライバーを判別します。

docker info コマンドを使用すると、Docker が使用しているドライバーを確認できます。

# docker info | grep Logging

Logging Driver: journald

json-file に変更するには、以下の手順に従います。

/etc/sysconfig/docker ファイルまたは /etc/docker/daemon.json ファイルのいずれかを変更します。

以下は例を示しています。

# cat /etc/sysconfig/docker
OPTIONS=' --selinux-enabled --log-driver=json-file --log-opt max-size=1M --log-opt max-file=3 --signature-verification=False'

cat /etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "1M",
"max-file": "1"
}
}

Docker サービスを再起動します。
```
systemctl restart docker
```
Fluentd を再起動します。
警告
13 以上のノードで一度に Fluentd を再起動すると、Kubernetes スケジューラーに大きな負荷が生成されます。以下の手順に従って Fluentd を再起動する場合は、細心の注意を払ってください。
Fluentd を再起動する方法は 2 つあります。1 つのノードまたはノードセット上で Fluentd を再起動するか、またはすべてのノードで Fluentd を再起動できます。
1. 以下の手順は、1 つのノードまたはノードセット上で Fluentd を再起動する方法を示しています。
  1. Fluentd が実行しているノードの一覧を表示します。
    
    $ oc get nodes -l logging-infra-fluentd=true
  2. 各ノードについて、ラベルを削除して Fluentd をオフにします。
    
    $ oc label node $node logging-infra-fluentd-
  3. Fluentd がオフになっていることを確認します。
    
    $ oc get pods -l component=fluentd
  4. 各ノードについて Fluentd を再起動します。
    
    $ oc label node $node logging-infra-fluentd=true
2. 以下の手順は、すべてのノード上で Fluentd を再起動する方法を示しています。
  1. すべてのノードで Fluentd をオフにします。
    
    $ oc label node -l logging-infra-fluentd=true --overwrite logging-infra-fluentd=false
  2. Fluentd がオフになっていることを確認します。
    
    $ oc get pods -l component=fluentd
  3. すべてのノードで Fluentd を再起動します。
    
    $ oc label node -l logging-infra-fluentd=false --overwrite logging-infra-fluentd=true
  4. Fluentd がオンになっていることを確認します。
    
    $ oc get pods -l component=fluentd

33.12. Elasticsearch の手動ロールアウト
リンクのコピー

OpenShift Container Platform 3.7 では Aggregated Logging スタックで Elasticsearch Deployment Config オブジェクトが更新され、Config Change Trigger が除外されました。このため、dc を変更しても自動ロールアウトは実行されなくなります。これは、ES クラスターで意図しない再起動を回避するものでしたが、クラスターメンバーの再起動時にシャードのリバランスが過剰に発生しまう可能性があります。

このセクションでは、ローリング再起動とフル再起動の 2 つの再起動手順を説明します。ローリング再起動はダウンタイムを発生させずに Elasticsearch クラスターに適切な変更を適用し (3 つのマスターが設定されている場合)、フル再起動は既存データを損なわずに大規模な変更を安全に適用します。

33.12.1. Elasticsearch ローリングクラスター再起動の実行
リンクのコピー

以下のいずれかの変更を行う場合は、ローリング再起動を推奨します。

Elasticsearch Pod の実行で再起動が必要なノード
logging-elasticsearch configmap
logging-es-* デプロイメント設定
新規イメージのデプロイメントまたはアップグレード

これは今後推奨される再起動ポリシーになります。

注記

openshift_logging_use_ops が True に設定される場合、ES クラスターへのアクションを ops クラスターに対して繰り返す必要があります。

ノードを意図的に停止する際のシャードのバランシングを防止します。

$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> --
          curl -s
          --cacert /etc/elasticsearch/secret/admin-ca \
          --cert /etc/elasticsearch/secret/admin-cert \
          --key /etc/elasticsearch/secret/admin-key \
          -XPUT 'https://localhost:9200/_cluster/settings' \
          -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'

完了したら、ES クラスターの各 dc について oc rollout latest を実行して、最新バージョンの dc オブジェクトをデプロイします。
```
$ oc rollout latest <dc_name>
```
新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の dc に進むことができます。

クラスターのすべての「dc」がロールアウトされたら、シャードバランシングを再度有効にします。

$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> --
          curl -s
          --cacert /etc/elasticsearch/secret/admin-ca \
          --cert /etc/elasticsearch/secret/admin-cert \
          --key /etc/elasticsearch/secret/admin-key \
          -XPUT 'https://localhost:9200/_cluster/settings' \
          -d '{ "transient": { "cluster.routing.allocation.enable" : "all" } }'

33.12.2. Elasticsearch フルクラスター再起動の実行
リンクのコピー

Elasticsearch のメジャーバージョンの変更など、変更プロセス中にデータ整合性が損なわれる危険性がある変更の場合は、フル再起動を推奨します。

注記

openshift_logging_use_ops が True に設定される場合、ES クラスターへのアクションを ops クラスターに対して繰り返す必要があります。

注記

logging-es-ops サービスに変更を行う場合は、パッチとして代わりにコンポーネント "es-ops-blocked" および "es-ops" を使用します。

ES クラスターが停止しているときに、ES クラスターへのすべての外部通信を無効にします。以下のコマンドを実行して、非クラスターロギングサービス (logging-es や logging-es-ops など) を編集して、ES Pod に一致しないようにします。
```
$  oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es-blocked","provider":"openshift"}}}'
```

シャードの同期フラッシュを実行して、シャットダウン前のディスクへの書き込みを待機している保留中の操作がないようにします。

$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> --
          curl -s
          --cacert /etc/elasticsearch/secret/admin-ca \
          --cert /etc/elasticsearch/secret/admin-cert \
          --key /etc/elasticsearch/secret/admin-key \
          -XPOST 'https://localhost:9200/_flush/synced'

ノードを意図的に停止する際のシャードのバランシングを防止します。

$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> --
          curl -s
          --cacert /etc/elasticsearch/secret/admin-ca \
          --cert /etc/elasticsearch/secret/admin-cert \
          --key /etc/elasticsearch/secret/admin-key \
          -XPUT 'https://localhost:9200/_cluster/settings' \
          -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'

完了したら、各 ES クラスターの各 dc について、すべてのレプリカをスケールダウンします。
```
$ oc scale dc <dc_name> --replicas=0
```
スケールダウンが完了したら、ES クラスターの各 dc について oc rollout latest を実行して、最新バージョンの dc オブジェクトをデプロイします。
```
$ oc rollout latest <dc_name>
```
新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の dc に進むことができます。
デプロイメントが完了したら、各 ES クラスターの dc について、レプリカをスケールアップします。
```
$ oc scale dc <dc_name> --replicas=1
```
スケールアップが完了したら、ES クラスターへのすべての外部通信を有効にします。以下のコマンドを再度実行して、非クラスターロギングサービス (logging-es や logging-es-ops など) を編集して、ES Pod に一致するようにします。
```
$ oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es","provider":"openshift"}}}'
```

第33章コンテナーログの集計

33.1. 概要
リンクのコピー

33.2. デプロイ前の設定
リンクのコピー

33.3. ロギング Ansible 変数の指定
リンクのコピー

33.4. EFK スタックのデプロイ
リンクのコピー

33.5. デプロイメントの概要と調整
リンクのコピー

33.5.1. Ops クラスター
リンクのコピー

33.5.2. Elasticsearch
リンクのコピー

33.5.3. Fluentd
リンクのコピー

33.5.4. Kibana
リンクのコピー

33.5.5. Curator
リンクのコピー

33.5.5.1. Curator 設定の作成
リンクのコピー

33.6. クリーンアップ
リンクのコピー

33.7. Kibana のトラブルシューティング
リンクのコピー

33.8. 外部 Elasticsearch インスタンスへのログの送信
リンクのコピー

33.9. 外部 syslog サーバーへのログの送信
リンクのコピー

33.10. Elasticsearch 管理操作の実行
リンクのコピー

33.11. 集計されたロギングのドライバーの変更
リンクのコピー

33.12. Elasticsearch の手動ロールアウト
リンクのコピー

33.12.1. Elasticsearch ローリングクラスター再起動の実行
リンクのコピー

33.12.2. Elasticsearch フルクラスター再起動の実行
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第33章 コンテナーログの集計

33.1. 概要リンクのコピーリンクがクリップボードにコピーされました!

33.2. デプロイ前の設定リンクのコピーリンクがクリップボードにコピーされました!

33.3. ロギング Ansible 変数の指定リンクのコピーリンクがクリップボードにコピーされました!

33.4. EFK スタックのデプロイリンクのコピーリンクがクリップボードにコピーされました!

33.5. デプロイメントの概要と調整リンクのコピーリンクがクリップボードにコピーされました!

33.5.1. Ops クラスターリンクのコピーリンクがクリップボードにコピーされました!

33.5.2. Elasticsearchリンクのコピーリンクがクリップボードにコピーされました!

33.5.3. Fluentdリンクのコピーリンクがクリップボードにコピーされました!

33.5.4. Kibanaリンクのコピーリンクがクリップボードにコピーされました!

33.5.5. Curatorリンクのコピーリンクがクリップボードにコピーされました!

33.5.5.1. Curator 設定の作成リンクのコピーリンクがクリップボードにコピーされました!

33.6. クリーンアップリンクのコピーリンクがクリップボードにコピーされました!

33.7. Kibana のトラブルシューティングリンクのコピーリンクがクリップボードにコピーされました!

33.8. 外部 Elasticsearch インスタンスへのログの送信リンクのコピーリンクがクリップボードにコピーされました!

33.9. 外部 syslog サーバーへのログの送信リンクのコピーリンクがクリップボードにコピーされました!

33.10. Elasticsearch 管理操作の実行リンクのコピーリンクがクリップボードにコピーされました!

33.11. 集計されたロギングのドライバーの変更リンクのコピーリンクがクリップボードにコピーされました!

33.12. Elasticsearch の手動ロールアウトリンクのコピーリンクがクリップボードにコピーされました!

33.12.1. Elasticsearch ローリングクラスター再起動の実行リンクのコピーリンクがクリップボードにコピーされました!

33.12.2. Elasticsearch フルクラスター再起動の実行リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第33章コンテナーログの集計

33.1. 概要
リンクのコピー

33.2. デプロイ前の設定
リンクのコピー

33.3. ロギング Ansible 変数の指定
リンクのコピー

33.4. EFK スタックのデプロイ
リンクのコピー

33.5. デプロイメントの概要と調整
リンクのコピー

33.5.1. Ops クラスター
リンクのコピー

33.5.2. Elasticsearch
リンクのコピー

33.5.3. Fluentd
リンクのコピー

33.5.4. Kibana
リンクのコピー

33.5.5. Curator
リンクのコピー

33.5.5.1. Curator 設定の作成
リンクのコピー

33.6. クリーンアップ
リンクのコピー

33.7. Kibana のトラブルシューティング
リンクのコピー

33.8. 外部 Elasticsearch インスタンスへのログの送信
リンクのコピー

33.9. 外部 syslog サーバーへのログの送信
リンクのコピー

33.10. Elasticsearch 管理操作の実行
リンクのコピー

33.11. 集計されたロギングのドライバーの変更
リンクのコピー

33.12. Elasticsearch の手動ロールアウト
リンクのコピー

33.12.1. Elasticsearch ローリングクラスター再起動の実行
リンクのコピー

33.12.2. Elasticsearch フルクラスター再起動の実行
リンクのコピー