検索

6.3. ログ転送 API を使用したログの転送

download PDF

ログ転送 API により、コンテナーおよびノードログをクラスター内外の特定のエンドポイントに送信できるようにカスタムパイプラインを設定できます。既存のロギングサービス、外部 Elasticsearch クラスター、外部ログ集計ソリューション、またはセキュリティー情報およびイベント管理 (SIEM) システムなどの OpenShift Container Platform クラスターロギングで管理されていないリモート宛先および内部 OpenShift Container Platform Elasticsearch インスタンスにログをタイプ別に送信することができます。

重要

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

詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

異なるタイプのログを異なるシステムに送信して、組織の誰がそれぞれのタイプにアクセスできるかを制御できます。オプションの TLS サポートにより、組織の必要に応じてセキュアな通信を使用してログを送信することができます。

ログ転送 API の使用はオプションです。ログを内部の OpenShift Container Platform Elasticsearch インスタンスのみに転送する必要がある場合は、ログ転送 API を設定しないようにしてください。

6.3.1. ログ転送 API について

ログ転送 API を使用してクラスターログを転送するには、出力パイプライン の組み合わせが必要です。これらのリソースは、OpenShift Container Platform クラスター内外の特定のエンドポイントにログを送信します。

注記

デフォルトの内部 OpenShift Container Platform Elasticsearch ログストアのみを使用する必要がある場合は、出力およびパイプラインは設定しません。

output はログデータの宛先で、パイプラインは単一のソースまたは 1 つまたは複数の出力の単純なルーティングを定義します。

出力には、以下のいずれかが該当します。

  • elasticsearch を使用して、サーバー名または FQDN、および/または内部 OpenShift Container Platform Elasticsearch ログストアで指定される、外部の Elasticsearch 6 (すべてのリリース)クラスターにログを転送します。
  • forward を使用して、ログを外部のログ集計ソリューションに転送します。このオプションは Fluentd forward プロトコルを使用します。

パイプライン は、データの種類を出力に関連付けます。転送できるデータのタイプは以下のいずれかになります。

  • logs.app: クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。
  • logs.infra: ジャーナルログなどの、クラスターで実行されるインフラストラクチャーコンポーネントおよび OpenShift Container Platform ノードの両方で生成されるログ。インフラストラクチャーコンポーネントは、openshift*kube*、または default プロジェクトで実行される Pod です。
  • logs.audit: ノード監査システム (auditd) で生成されるログ (/var/log/audit/audit.log ファイルに保存される)、および Kubernetes apiserver および OpenShift apiserver の監査ログ。

ログ転送 API を使用するには、出力およびパイプラインと共にカスタム logforwarding 設定ファイルを作成し、指定した宛先にログを送信します。

以下の点に注意してください。

  • 内部 OpenShift Container Platform Elasticsearch ログストアは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に準拠しており、適切にセキュリティーが保護されていることを確認することが推奨されています。OpenShift Container Platform クラスターロギングはこれらの規制に準拠しません。
  • 出力は、シークレットを使用する TLS 通信をサポートします。シークレットには、tls.crttls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。転送機能を安全な方法で使用するには、シークレットにキー shared_key が含まれる必要があります。
  • キーやシークレット、サービスアカウント、ポートのオープン、またはグローバルプロキシー設定など、外部の宛先で必要となる可能性のある追加設定を作成し、維持する必要があります。

以下の例は、3 つの出力を作成します。

  • 内部 OpenShift Container Platform Elasticsearch ログストア
  • 非セキュアな外部で管理される Elasticsearch ログストア
  • セキュアな外部ログアグリゲーター (forward プロトコルを使用)。

3 つのパイプラインは以下を送信します。

  • 内部 OpenShift Container Platform Elasticsearch ログストアへのアプリケーションログ
  • 外部 Elasticsearch ログストアへのインフラストラクチャーログ
  • セキュリティーが保護されたデバイスへの監査ログ ( forward プロトコルを使用)

ログ転送の出力とパイプラインのサンプル

apiVersion: "logging.openshift.io/v1alpha1"
kind: "LogForwarding"
metadata:
  name: instance 1
  namespace: openshift-logging
spec:
  disableDefaultForwarding: true 2
  outputs: 3
   - name: elasticsearch 4
     type: "elasticsearch"  5
     endpoint: elasticsearch.openshift-logging.svc:9200 6
     secret: 7
        name: fluentd
   - name: elasticsearch-insecure
     type: "elasticsearch"
     endpoint: elasticsearch-insecure.messaging.svc.cluster.local
     insecure: true 8
   - name: secureforward-offcluster
     type: "forward"
     endpoint: https://secureforward.offcluster.com:24224
     secret:
        name: secureforward
  pipelines: 9
   - name: container-logs 10
     inputSource: logs.app 11
     outputRefs: 12
     - elasticsearch
     - secureforward-offcluster
   - name: infra-logs
     inputSource: logs.infra
     outputRefs:
     - elasticsearch-insecure
   - name: audit-logs
     inputSource: logs.audit
     outputRefs:
     - secureforward-offcluster

1
ログ転送 CR の名前は instance である必要があります。
2
ログ転送を有効にするパラメーター。ログ転送を有効にするには true に設定します。
3
出力の設定。
4
出力を記述する名前。
5
elasticsearch または forward のいずれかの出力タイプ。
6
ログ転送エンドポイント (サーバー名または FQDN のいずれか)。内部 OpenShift Container Platform Elasticsearch ログストアの場合は、elasticsearch.openshift-logging.svc:9200 を指定します。
7
TLS 通信のエンドポイントで必要なシークレットのオプションの名前。シークレットは openshift-logging プロジェクトに存在する必要があります。
8
エンドポイントがシークレットを使用しない場合のオプションの設定 (これにより、非セキュアな通信が発生します)。
9
パイプラインの設定。
10
パイプラインを説明する名前。
11
ソースタイプ (logs.applogs.infra、または logs.audit)。
12
CR に設定される単一または複数の出力の名前。
外部ログアグリゲーターが利用できない場合の Fluentd のログの処理

外部ロギングアグリゲーターが利用できず、ログを受信できない場合、Fluentd は継続してログを収集し、それらをバッファーに保存します。ログアグリゲーターが利用可能になると、バッファーされたログを含む、ログの転送が再開されます。バッファーが完全に一杯になると、Fluentd はログの収集を停止します。OpenShift Container Platform はログをローテーションし、それらを削除します。バッファーサイズを調整したり、永続ボリューム要求 (PVC) を Fluentd デーモンセットまたは Pod に追加したりすることはできません。

注記

内部 OpenShift Container Platform Elasticsearch ログストアは監査ログのセキュアなストレージを提供しないため、デフォルトで監査ログは内部 Elasticsearch インスタンスに保存されません。監査ログを内部ログストアに送信する必要がある場合 (Kibana で監査ログを表示するなど)、Forward audit logs to the log store で説明されているようにログ転送 API を使用する必要があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.