検索

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

download PDF

32.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 ロギングドライバーオプションの使用について説明しています。

32.2. デプロイ前の設定

  1. Ansible Playbook は集計されたロギングをデプロイおよびアップグレードするために利用できます。通常インストール (Advanced installation)と設定 のセクションに精通しておくようにしてください。このセクションでは、Ansible を使用する準備に必要な情報と設定に関する情報を提供します。EFK スタックの各種の領域を設定するために、パラメーターが Ansible インベントリーファイルに追加されています。
  2. サイジングのガイドラインを確認して、デプロイメントの最適な設定方法を判断してください。
  3. クラスターのルーターをデプロイしていることを確認します。
  4. Elasticsearch に必要なストレージがあることを確認します。各 Elasticsearch レプリカに独自のストレージボリュームが必要であることに注意してください。詳細については、「Elasticsearch 」を参照してください。
  5. プロジェクトを選択します。デプロイされたら、EFK スタックは OpenShift Container Platform クラスター内のすべてのプロジェクトのログを収集します。このセクションの例では、デフォルトのプロジェクトロギング を使用しています。プロジェクトがまだ存在していない場合は、Ansible Playbook によってプロジェクトが作成されます。プロジェクトに対してノードセレクターを指定する場合にのみ、プロジェクトを作成する必要があります。そうしない場合は、openshift-logging ロールによってプロジェクトが作成されます。

    $ oc adm new-project logging --node-selector=""
    $ oc project logging
    注記

    Fluentd はクラスター全体にデプロイする必要があり、セレクターによって Fluentd がデプロイされる場所が制限されるため、プロジェクトには空のノードセレクターを指定することをお勧めします。コンポーネントの配置を制御するには、コンポーネントごとにノードセレクターを指定して、デプロイメント設定に適用する必要があります。

32.3. ロギング Ansible 変数の指定

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

注記

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

パラメーター説明

openshift_logging_image_prefix

ロギングコンポーネントイメージのプレフィックス。たとえば、プレフィックスを registry.access.redhat.com/openshift3/ に設定すると registry.access.redhat.com/openshift3/logging-fluentd:latest が作成されます。

openshift_logging_image_version

ロギングコンポーネントイメージのバージョン。たとえば、バージョンを v3.9 に設定すると registry.access.redhat.com/openshift3/logging-fluentd:v3.9 が作成されます。

openshift_logging_use_ops

true に設定されている場合、操作ログに対して 2 番目の Elasticsearch クラスターと Kibana を設定します。Fluentd はメインクラスターと操作ログ用に予約されているクラスター (defaultopenshiftopenshift-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

集計されたロギングがデプロイされる 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' に設定されている場合、イベントルーターがインストールされます。両方が 'false' に設定されている場合、イベントルーターがアンインストールされます。

openshift_logging_eventrouter_image_prefix

イベントルーターのロギングイメージのプレフィックス。デフォルトでは openshift_logging_image_prefix に設定されています。

openshift_logging_eventrouter_image_version

ロギングイベントルーターのイメージバージョン。デフォルトでは 'openshift_logging_image_version' に設定されています。

openshift_logging_eventrouter_sink

イベントルーターのシンク (受信側) を選択します。stdoutglog がサポートされています。デフォルトでは stdout に設定されています。

openshift_logging_eventrouter_nodeselector

Pod が到達するノードを選択するためのラベルのマップ ("node":"infra""region":"west" など)。

openshift_logging_eventrouter_replicas

デフォルトでは '1' に設定されます。

openshift_logging_eventrouter_cpu_limit

イベントルーターに割り当てる最小 CPU 量。デフォルトでは '100m' に設定されます。

openshift_logging_eventrouter_memory_limit

イベントルーター 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_opstrue に設定されている場合は、Ops クラスターの openshift_logging_curator_cpu_limit と同等です。

openshift_logging_curator_ops_memory_limit

openshift_logging_use_opstrue に設定されている場合は、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_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_hostname と同等です。

openshift_logging_kibana_ops_cpu_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_cpu_limit と同等です。

openshift_logging_kibana_ops_memory_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_memory_limit と同等です。

openshift_logging_kibana_ops_proxy_debug

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_proxy_debug と同等です。

openshift_logging_kibana_ops_proxy_cpu_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_proxy_cpu_limit と同等です。

openshift_logging_kibana_ops_proxy_memory_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_kibana_proxy_memory_limit と同等です。

openshift_logging_kibana_ops_replica_count

openshift_logging_use_opstrue に設定されている場合は、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_enginetrue に設定されている場合には、コンテナーエンジンの監査ログが収集され、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_allow_cluster_reader

cluster-reader ロールに操作ログの読み取りが許可されている場合は true に設定します。

openshift_logging_es_ops_host

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_host と同等です。

openshift_logging_es_ops_port

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_port と同等です。

openshift_logging_es_ops_ca

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_ca と同等です。

openshift_logging_es_ops_client_cert

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_client_cert と同等です。

openshift_logging_es_ops_client_key

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_client_key と同等です。

openshift_logging_es_ops_cluster_size

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_cluster_size と同等です。

openshift_logging_es_ops_cpu_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_cpu_limit と同等です。

openshift_logging_es_ops_memory_limit

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_memory_limit と同等です。

openshift_logging_es_ops_pv_selector

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_pv_selector と同等です。

openshift_logging_es_ops_pvc_dynamic

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_pvc_dynamic と同等です。

openshift_logging_es_ops_pvc_size

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_pvc_size と同等です。

openshift_logging_es_ops_pvc_prefix

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_pvc_prefix と同等です。

openshift_logging_es_ops_recover_after_time

openshift_logging_use_opstrue に設定されている場合は、Ops クラスターの openshift_logging_es_recovery_after_time と同等です。

openshift_logging_es_ops_storage_group

openshift_logging_use_opstrue に設定されている場合は、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 インデックスを共有します。これにより、各操作ユーザーが同じクエリー、ビジュアライゼーション、およびダッシュボードを参照することができます。

openshift_logging_kibana_ops_nodeselector

Kibana インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。

openshift_logging_curator_ops_nodeselector

Curator インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。

カスタム証明書

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

ファイル名説明

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 ファイルへの制御ノード上の絶対パス。

32.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>

32.5. デプロイメントの概要と調整

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

32.5.1. Ops クラスター

注記

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

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

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

32.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-1logging-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 レプリカのストレージとして使用することができます。これを実行するには、以下のような準備が必要です。

  1. 関連するサービスアカウントに、ローカルボリュームをマウントし、編集する権限を指定する必要があります。

    $ oc adm policy add-scc-to-user privileged  \
           system:serviceaccount:logging:aggregated-logging-elasticsearch 1
    1
    ロギング Playbook を実行する際に、以前に作成したプロジェクトを使用します (例: logging)。
  2. それぞれの 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
  3. 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"}}}}}'
  4. これらの手順を実行すると、この例 (ストレージが各ノードの同じパスにマウントされていることを前提とします) のように、ローカルホストのマウントを各レプリカに適用できます (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 ホスト名を指定することができます。

  1. re-encrypt ルートとして Elasticsearch にアクセスするには、以下の変数を定義します。

    openshift_logging_es_allow_external=True
    openshift_logging_es_hostname=elasticsearch.example.com
  2. 以下の Ansible Playbook を実行します。

    $ ansible-playbook [-i </path/to/inventory>] \
        /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml
  3. Elasticsearch にリモートでログインするには、要求に 3 つの HTTP ヘッダーが含まれている必要があります。

    Authorization: Bearer $token
    X-Proxy-Remote-User: $username
    X-Forwarded-For: $ip_address
  4. ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。以下は例になります。

    $ oc login <user1>
    $ oc new-project <user1project>
    $ oc new-app <httpd-example>
  5. 要求内で使用するこの ServiceAccount のトークンを取得する必要があります。

    $ token=$(oc whoami -t)
  6. 以前に設定したトークンを使用して、公開ルート経由で 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

32.5.3. Fluentd

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

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

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_certyour_private_key の値は configmap/logging-fluentdsecure-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 プラグインの設定方法に関する説明はこちらを参照してください。

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

重要

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

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

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

パラメーター説明

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 の値は minimalmaximal です。デフォルトはありません。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

デフォルトは muxopenshift_master_default_subdomain を追加した値です。これは、external_clientsmux に接続するために使用するホスト名であり、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"}}}}}'

32.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 の名前です。

32.5.5. Curator

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

$PROJECT_NAME:
  $ACTION:
    $UNIT: $VALUE

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

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

変数名説明

PROJECT_NAME

プロジェクトの実際の名前 (myapp-devel など)。OpenShift Container Platform の操作ログについては、名前 .operations をプロジェクト名として使用します。

ACTION

実行するアクション。現在許可されているのは delete のみです。

UNIT

daysweeks、または 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)。

32.5.5.1. Curator 設定の作成

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

  1. 提供された ConfigMap を編集して Curator インスタンスを設定するには、以下を実行します。

    $ oc edit configmap/logging-curator
  2. 提供された ConfigMap を置換するには、以下を実行します。

    $ create /path/to/mycuratorconfig.yaml
    $ oc create configmap logging-curator -o yaml \
      --from-file=config.yaml=/path/to/mycuratorconfig.yaml | \
      oc replace -f -
  3. 変更を行った後に、Curator を再デプロイします。

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

32.6. クリーンアップ

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

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

32.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 を設定するには、以下の手順を実行します。

  1. すべての Fluentd Pod をスケールダウンします。
  2. Fluentd Pod の終了後に Elasticsearch をスケールダウンします。
  3. searchguard.http.xforwardedfor.header: DUMMY を Elasticsearch の設定セクションに追加します。

    $ oc edit configmap/logging-elasticsearch 1
    1
    この方法では、Elasticsearch の設定が ConfigMap に含まれている必要があります。
  4. Elasticsearch を拡張して元に戻します。
  5. すべての Fluentd Pod を拡張します。

32.8. 外部 Elasticsearch インスタンスへのログの送信

Fluentd は、Elasticsearch デプロイメント設定の ES_HOSTES_PORTOPS_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_HOSTOPS_HOST を同じ宛先に設定して、ES_PORTOPS_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 イメージを使用していない場合、同じマルチテナント機能は利用できず、データは特定のプロジェクトへのユーザーアクセスによる制限を受けません。

32.9. 外部 syslog サーバーへのログの送信

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

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

- name: REMOTE_SYSLOG_HOST 1
  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.conflogging-fluentd または logging-mux ConfigMap に設定できます。

Fluentd 環境変数

パラメーター説明

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 変数

パラメーター説明

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 変数

パラメーター説明

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 メッセージにペイロードを設定します。

32.10. Elasticsearch 管理操作の実行

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

注記

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

$ oc describe secret logging-elasticsearch

これらがない場合は、「手動でのアップグレード方法」を参照して、最新バージョンを使用していることをまず確認してください。

  1. メンテナンスを実行しようとしているクラスター内にある Elasticsearch Pod に接続します。
  2. Pod をクラスター内で検索するには、以下のいずれかのコマンドを使用します。

    $ oc get pods -l component=es -o name | head -1
    $ oc get pods -l component=es-ops -o name | head -1
  3. Pod に接続します。

    $ oc rsh <your_Elasticsearch_pod>
  4. Elasticsearch コンテナーに接続すると、インデックス API のマニュアルに従い、シークレットからマウントされた証明書を使用して Elasticsearch と通信することができます。

    Fluentd では、インデックス形式 project.{project_name}.{project_uuid}.YYYY.MM.DD を使用してログを Elasticsearch に送信します。ここで、YYYY.MM.DD はログレコードの日付です。

    たとえば uuid が 3b3594fa-2ccd-11e6-acb7-0eb6b35eaee3logging プロジェクトから 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"

32.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 に変更するには、以下の手順に従います。

  1. /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"
    }
    }
  2. Docker サービスを再起動します。

    systemctl restart docker
  3. 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

32.12. Elasticsearch の手動ロールアウト

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

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

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

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

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

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

注記

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

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

    $ 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" } }'
  2. 完了したら、ES クラスターの各 dc について oc rollout latest を実行して、最新バージョンの dc オブジェクトをデプロイします。

    $ oc rollout latest <dc_name>

    新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の dc に進むことができます。

  3. クラスターのすべての「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" } }'

32.12.2. Elasticsearch フルクラスター再起動の実行

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

注記

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

注記

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

  1. ES クラスターが停止しているときに、ES クラスターへのすべての外部通信を無効にします。以下のコマンドを実行して、非クラスターロギングサービス (logging-eslogging-es-ops など) を編集して、ES Pod に一致しないようにします。

    $  oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es-blocked","provider":"openshift"}}}'
  2. シャードの同期フラッシュを実行して、シャットダウン前のディスクへの書き込みを待機している保留中の操作がないようにします。

    $ 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'
  3. ノードを意図的に停止する際のシャードのバランシングを防止します。

    $ 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" } }'
  4. 完了したら、ES クラスターの各 dc について oc rollout latest を実行して、最新バージョンの dc オブジェクトをデプロイします。

    $ oc rollout latest <dc_name>

    新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の dc に進むことができます。

  5. 再起動が完了したら、ES クラスターへのすべての外部通信を有効にします。以下のコマンドを再度実行して、非クラスターロギングサービス (logging-eslogging-es-ops など) を編集して、ES Pod に一致するようにします。

    $ oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es","provider":"openshift"}}}'
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.