すべてのプロダクト
Search
ドキュメントセンター

Simple Log Service:DaemonSetモードでKubernetesコンテナからテキストログを収集する

最終更新日:Oct 22, 2024

個別のLogtailプロセスを使用してKubernetesノード上のすべてのコンテナからログを収集する場合は、DaemonSetモードでKubernetesクラスターにLogtailをインストールできます。 このトピックでは、DaemonSetモードでコンテナテキストログを収集する実装、制限、前提条件、および手順について説明します。

実装

image

DaemonSetモード

  • DaemonSetモードでは、Kubernetesクラスター内のノードで1つのLogtailコンテナのみが実行されます。 Logtailを使用して、ノード上のすべてのコンテナからログを収集できます。

  • ノードがKubernetesクラスターに追加されると、クラスターは新しいノードにLogtailコンテナーを自動的に作成します。 Kubernetesクラスターからノードが削除されると、クラスターはノード上のLogtailコンテナーを自動的に破棄します。 DaemonSetsとカスタム識別子ベースのマシングループにより、Logtailプロセスを手動で管理する必要がなくなります。

コンテナ検出

  • Logtailコンテナが他のコンテナからログを収集する前に、Logtailコンテナは実行中のコンテナを特定して判断する必要があります。 このプロセスはコンテナ検出と呼ばれます。 コンテナー検出フェーズでは、LogtailコンテナーはKubernetesクラスターのkube-apiserverコンポーネントと通信しません。 代わりに、Logtailコンテナは、Logtailコンテナが実行されているノードのコンテナランタイムデーモンと通信して、ノード上のすべてのコンテナに関する情報を取得します。 これにより、コンテナ検出プロセスでkube-apiserverコンポーネントに圧力が発生するのを防ぎます。

  • Logtailを使用してログを収集する場合、名前空間ポッド名ポッドラベルコンテナー環境変数などの条件を指定して、Logtailがログを収集するコンテナーを特定できます。

コンテナーのファイルパスマッピング

Kubernetesクラスター内のポッドは分離されています。 その結果、ポッド内のLogtailコンテナは、別のポッド内のコンテナのファイルに直接アクセスできません。 コンテナのファイルシステムは、コンテナホストのファイルシステムをコンテナにマウントすることによって作成される。 Logtailコンテナは、コンテナホストのルートディレクトリを含むファイルシステムがLogtailコンテナにマウントされた後にのみ、コンテナホスト上の任意のファイルにアクセスできます。 これにより、Logtailコンテナはファイルシステム内のファイルからログを収集できます。 コンテナ内のファイルパスとコンテナホスト上のファイルパスの関係は、ファイルパスマッピングと呼ばれます。

たとえば、コンテナ内のファイルパスは /log/app.logです。 ファイルパスマッピング後、コンテナーホスト上のファイルパスは /var/lib/docker/containers/<container-id>/log/app.logになります。 既定では、コンテナーホストのルートディレクトリを含むファイルシステムは、logtailコンテナーの /Logtail_hostディレクトリにマウントされます。 したがって、Logtailコンテナは /logtail_host/var/lib/docker/containers/<container-id>/log/app.logからログを収集します。

制限事項

  • コンテナランタイム: Logtailは、Dockerエンジンまたはcontainerdエンジンを使用するコンテナーからのみデータを収集できます。 Dockerコンテナーの場合、オーバーレイおよびoverlay2ストレージドライバーのみがサポートされます。 他のストレージドライバを使用する場合は、ログのディレクトリにボリュームをマウントする必要があります。 そして、一時ディレクトリが生成される。

  • ボリュームのマウント: Apsara File Storage NAS (NAS) ファイルシステムがPersistentVolumeClaim (PVC) を使用してログのディレクトリにマウントされている場合、DaemonSetモードでLogtailをインストールすることはできません。 この場合、SidecarまたはDeploymentモードでLogtailをインストールすることを推奨します。 その後、Logtailはログを収集できます。 詳細については、「SidecarモードでのKubernetesコンテナーからのテキストログの収集」をご参照ください。.

  • ログファイルパス:

    • コンテナ内のファイルパスのシンボリックリンクはサポートされていません。 収集ディレクトリとして実際のパスを指定する必要があります。

    • アプリケーションコンテナのデータディレクトリにボリュームがマウントされている場合は、データディレクトリまたはそのサブディレクトリをコレクションディレクトリとして指定する必要があります。 たとえば、ボリュームが /var/log/serviceディレクトリにマウントされ、収集ディレクトリを /var/logに設定した場合、Logtailは /var/logディレクトリからログを収集できません。 収集ディレクトリとして /var/log/serviceまたはそのサブディレクトリを指定する必要があります。

  • ログ収集の停止:

    • Docker: コンテナが停止すると、Logtailは現在のコンテナファイルハンドルを直ちに解放します。 その後、コンテナは予想通りに出ることができる。 コンテナが停止する前にネットワークの待ち時間やリソースの過剰消費などの問題により収集待ち時間が存在する場合、コンテナが停止する前に収集された一部のログが失われる可能性があります。

    • containerd: コンテナーが停止すると、すべてのログが送信されるまで、Logtailは現在のコンテナーファイルハンドルを解放しません。 この期間中、ファイルは開いたままです。 ネットワーク待ち時間やリソースの過剰消費などの問題により収集待ち時間が存在する場合、コンテナはタイムリーに破壊されない可能性があります。

前提条件

  • Logtailコンポーネントがインストールされます。 詳細については、「ACKクラスターへのLogtailコンポーネントのインストール」をご参照ください。

  • Logtailがインストールされているサーバーでは、ポート80と443が有効になります。 サーバーがElastic Computing Service (ECS) インスタンスの場合、関連するセキュリティグループルールを再設定してポートを有効にすることができます。 セキュリティグループルールの設定方法の詳細については、「セキュリティグループルールの追加」をご参照ください。

  • ログは、ログを収集するコンテナーで継続的に生成されます。 Logtailは増分ログのみを収集します。 Logtail構成がサーバーに配信されて適用された後にサーバー上のログファイルが更新されない場合、Logtailはファイルからログを収集しません。 詳細については、「ログファイルの読み取り」をご参照ください。

  • 必要なUNIXドメインソケットが存在し、LogtailにはUNIXドメインソケットに対するアクセス権限があります。 UNIXドメインソケットは、コンテナエンジンによって異なります。

    • Docker: /run/docker.sock

    • containerd: /run/containerd/containerd.sock

Logtail構成の作成

警告

CustomResourceDefinition (CRD) を使用してLogtail設定を作成し、Simple Log ServiceコンソールでLogtail設定を変更した場合、変更はCRDと同期されません。 CRDを使用して作成されたLogtail構成を変更する場合は、CRDを変更する必要があります。 Simple Log Serviceコンソールで設定を変更すると、Logtail設定の不整合が発生する可能性があります。

コンソール

  1. にログインします。Simple Log Serviceコンソール.

  2. [クイックデータのインポート] セクションで、[データのインポート] をクリックします。 [データのインポート] ダイアログボックスで、[Kubernetes-ファイル] カードをクリックします。

    image

  3. 必要なプロジェクトとLogstoreを選択します。 [次へ] をクリックします。 この例では、Logtailコンポーネントのインストールに使用するプロジェクトと、作成するLogstoreを選択します。

  4. [マシングループの設定] ステップで、次の操作を実行します。

    1. ビジネス要件に基づいて、次のいずれかの設定を使用します。

      • Kubernetesクラスター > ACK Daemonset

      • Kubernetesクラスター > DaemonSetモードの自己管理クラスター

        重要

        以降の設定は、前述の設定によって異なります。

    2. 必要なマシングループが [応用サーバーグループ] セクションに追加されていることを確認します。 そして、[次へ] をクリックします。 Container Service for Kubernetes (ACK) クラスターにLogtailコンポーネントをインストールすると、Simple Log Servicek8s-group-${your_k8s_cluster_id} という名前のマシングループを自動的に作成します。 このマシングループを直接使用できます。

      重要
  5. Logtail設定を作成し、[次へ] をクリックします。 Simple Log Serviceは、Logtail設定の作成後にログの収集を開始します。

    説明

    Logtail設定を有効にするには、最大3分かかります。

    グローバル設定

    パラメーター

    説明

    設定名

    Logtail設定の名前を入力します。 名前はプロジェクト内で一意である必要があります。 Logtail設定を作成した後、Logtail設定の名前を変更することはできません。

    ログトピックの種類

    ログトピックを生成する方法を選択します。 詳細については、「ログトピック」をご参照ください。

    • マシングループトピック: マシングループのトピックがログトピックとして使用されます。 異なるマシングループのログを区別する場合は、このオプションを選択します。

    • ファイルパスの抽出: カスタム正規表現を指定する必要があります。 正規表現に一致するファイルパスの一部がログトピックとして使用されます。 異なるソースのログを区別する場合は、このオプションを選択します。

    • カスタム: カスタムログトピックを指定する必要があります。

    高度なパラメータ

    オプションです。 グローバル設定に関連する詳細パラメーターを設定します。 詳細については、「CreateLogtailPipelineConfig」をご参照ください。

    入力設定

    パラメーター

    説明

    Logtail展開モード

    Logtailのデプロイモードを選択します。 この例では、Daemonsetが選択されています。

    ファイルパスタイプ

    ログの収集に使用するファイルパスの種類を選択します。 有効な値: コンテナー内のパスとホストパス。 hostPathボリュームがコンテナーにマウントされていて、コンテナーホスト上のマッピングされたファイルパスに基づいてファイルからログを収集する場合は、このパラメーターをホストパスに設定します。 他のシナリオでは、このパラメーターを [コンテナーのパス] に設定します。

    ファイルパス

    • 必要なコンテナーがLinuxホストで実行されている場合は、スラッシュ (/) で始まるパスを指定します。 例: /apsara/nuwa/**/app.Log

    • 必要なコンテナーがWindowsホストで実行されている場合は、ドライブ文字で始まるパスを指定します。 例: C:\Program Files\Intel\**\*.Log

    正確なディレクトリと正確な名前を指定できます。 ワイルドカード文字を使用して、ディレクトリと名前を指定することもできます。 詳細については、「ワイルドカードの一致」をご参照ください。 このパラメーターを設定すると、アスタリスク (*) または疑問符 (?) のみをワイルドカード文字として使用できます。

    Simple Log Serviceは、指定されたディレクトリのすべてのレベルで、指定された条件に一致するログファイルをスキャンします。 例:

    • /apsara/nuwa/**/*.logを指定した場合、Simple Log Serviceは、名前の接尾辞が /apsara/nuwaディレクトリとディレクトリの再帰サブディレクトリにログインします。

    • を指定した場合/var/logs/app_*/**/*.logSimple Log Serviceは、次の条件を満たすログファイルからログを収集します。. ログ. ファイルは、/var/logsディレクトリ下のサブディレクトリ、またはサブディレクトリの再帰サブディレクトリに格納されます。 サブディレクトリの名前は、app_* パターンと一致します。

    • /var/log/nginx/**/access * を指定した場合、Simple Log Serviceは、名前が /var/log/nginxディレクトリのaccessで始まるログファイルと、ディレクトリの再帰的なサブディレクトリからログを収集します。

    最大ディレクトリ監視深度

    監視するサブディレクトリのレベルの最大数を指定します。 サブディレクトリは、指定したログファイルディレクトリにあります。 このパラメーターは、ファイルパスの値に含まれるワイルドカード文字 **と一致するサブディレクトリのレベルを指定します。 値が0の場合は、指定したログファイルディレクトリのみを監視することを指定します。

    警告

    最小要件に基づいてこのパラメーターを設定することを推奨します。 大きな値を指定すると、Logtailはより多くのモニタリングリソースを消費し、収集待ち時間を引き起こす可能性があります。

    Container Metadataプレビューの有効化

    [Container Metadata Previewの有効化] をオンにすると、Logtail設定の作成後に、一致したコンテナ情報と完全なコンテナ情報を含むコンテナメタデータを表示できます。

    コンテナフィルタリング

    • Logtailのバージョン

      • Logtailのバージョンが1.0.34より前の場合、環境変数コンテナーラベルのみを使用してコンテナーをフィルター処理できます。

      • Logtailのバージョンが1.0.34以降の場合、異なるレベルのKubernetes情報を使用してコンテナをフィルタリングすることを推奨します。 情報には、ポッド名名前空間コンテナ名、およびコンテナラベルが含まれます。

    • フィルター条件

      重要
      • コンテナラベルは、docker inspectコマンドを実行して取得します。 コンテナラベルはKubernetesラベルとは異なります。 詳細については、「コンテナーラベルの取得」をご参照ください。

      • 環境変数は、コンテナーを起動するように設定されている環境変数と同じです。 詳細については、「環境変数の取得」をご参照ください。

      1. Kubernetes名前空間とコンテナー名は、コンテナーラベルにマップできます。 名前空間のラベルはio.kubernetes.pod.nameスペースです。 コンテナ名のラベルはio.kubernetes.container.nameです。 2つのラベルを使用してコンテナをフィルタリングすることを推奨します。 たとえば、ポッドの名前空間はbackend-prodで、ポッド内のコンテナーの名前はworker-serverです。 ワーカーサーバーコンテナのログを収集する場合は、コンテナラベルホワイトリストにio.kubernetes.pod.nameスペース: backend-prodまたはio.kubernetes.container.name : worker-serverを指定できます。

      2. 2つのラベルがビジネス要件を満たさない場合は、環境変数ホワイトリストまたは環境変数ブラックリストを使用してコンテナをフィルタリングできます。

    • K8sポッド名レギュラーマッチング

      ポッド名を入力します。 ポッド名は、テキストログの収集元となるコンテナを指定します。 正規表現マッチングがサポートされています。 たとえば、^(nginx-log-demo.*)$ を指定すると、nginx-log-demoで始まる名前のポッド内のすべてのコンテナが一致します。

    • K8s名前空間正規マッチング

      名前空間名を入力します。 名前空間名は、テキストログの収集元となるコンテナを指定します。 正規表現マッチングがサポートされています。 たとえば、^(default | nginx)$ を指定すると、nginx名前空間とdefault名前空間のすべてのコンテナーが一致します。

    • K8sコンテナ名レギュラーマッチング

      コンテナ名を入力します。 コンテナ名は、テキストログの収集元となるコンテナを指定します。 正規表現マッチングがサポートされています。 Kubernetesコンテナ名はspec.containersで定義されています。 たとえば、^(container-test)$ を指定すると、名前がcontainer-testであるすべてのコンテナが一致します。

    • 容器ラベルのホワイトリスト

      コンテナーラベルのホワイトリストを設定します。 ホワイトリストは、テキストログの収集元となるコンテナを指定します。

      Label Nameパラメーターに重複する値を指定しないでください。 重複する値を指定した場合は、1つの値のみが有効になります。

      • [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定したラベル名がコンテナーラベルに含まれるコンテナーが一致します。

      • [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定された [ラベル名: ラベル値] を含むコンテナラベルを持つコンテナが一致します。

        デフォルトでは、Label Valueパラメーターの値に対して文字列照合が実行されます。 コンテナは、コンテナラベルの値がLabel Valueパラメーターの値と同じである場合にのみ一致します。 ラベル値パラメーターに、キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、Label Nameパラメーターをappに設定し、Label Valueパラメーターを ^(test1 | test2)$ に設定した場合、コンテナラベルにapp:test1またはapp:test2が含まれるコンテナが一致します。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアの1つで構成されるコンテナーラベルがコンテナーにある場合、コンテナーは照合されます。

    • Container Labelブラックリスト

      コンテナーラベルブラックリストを設定します。 ブラックリストは、テキストログが収集されないコンテナを指定します。

      Label Nameパラメーターに重複する値を指定しないでください。 重複する値を指定した場合は、1つの値のみが有効になります。

      • [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定したラベル名がコンテナーラベルに含まれるコンテナーは除外されます。

      • [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定された [ラベル名: ラベル値] がコンテナーラベルに含まれるコンテナーは除外されます。

        デフォルトでは、Label Valueパラメーターの値に対して文字列照合が実行されます。 コンテナラベルの値がラベル値パラメーターの値と同じである場合にのみ、コンテナが除外されます。 ラベル値パラメーターに、キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、Label Nameパラメーターをappに設定し、Label Valueパラメーターを ^(test1 | test2)$ に設定した場合、コンテナラベルにapp:test1またはapp:test2が含まれるコンテナは除外されます。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアのいずれかで構成されるコンテナーラベルがコンテナーに含まれている場合、コンテナーは除外されます。

    • 環境変数ホワイトリスト

      環境変数ホワイトリストを設定します。 ホワイトリストは、テキストログの収集元となるコンテナを指定します。

      • 環境変数名パラメーターに値を指定し、環境変数値パラメーターに値を指定しない場合、指定された環境変数名が環境変数に含まれるコンテナーが一致します。

      • [環境変数名] パラメーターと [環境変数値] パラメーターの値を指定した場合、環境変数に指定された環境変数名: 環境変数値が含まれるコンテナーが一致します。

        デフォルトでは、環境変数値パラメーターの値に対して文字列照合が実行されます。 コンテナは、環境変数の値が環境変数値パラメーターの値と同じである場合にのみ一致します。 環境変数値パラメーターに、キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、環境変数名パラメーターをNGINX_SERVICE_PORTに設定し、環境変数値パラメーターを ^(80 | 6379)$ に設定した場合、ポート番号が80 6379のコンテナーが一致します。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアの1つで構成される環境変数がコンテナーにある場合、コンテナーは照合されます。

    • 環境変数ブラックリスト

      環境変数ブラックリストを設定します。 ブラックリストは、テキストログが収集されないコンテナを指定します。

      • 環境変数名パラメーターに値を指定し、環境変数値パラメーターに値を指定しない場合、指定された環境変数名が環境変数に含まれるコンテナーは除外されます。

      • 環境変数名および環境変数値パラメーターに値を指定した場合、指定された環境変数名: 環境変数値が環境変数に含まれるコンテナーは除外されます。

        デフォルトでは、環境変数値パラメーターの値に対して文字列照合が実行されます。 コンテナは、環境変数の値が環境変数の値パラメーターの値と同じである場合にのみ除外されます。 環境変数値パラメーターに、キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、環境変数名パラメーターをNGINX_SERVICE_PORTに設定し、環境変数値パラメーターを ^(80 | 6379)$ に設定した場合、ポート番号が80 6379のコンテナーは除外されます。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアの1つで構成される環境変数がコンテナーにある場合、コンテナーは除外されます。

    • Kubernetes Podラベルホワイトリスト

      Kubernetesポッドラベルのホワイトリストを設定します。 ホワイトリストは、テキストログの収集元となるコンテナを指定します。

      • [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しないと、指定したラベル名がポッドラベルに含まれるコンテナーが一致します。

      • [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定された [ラベル名: ラベル値] を含むポッドラベルを持つコンテナーが一致します。

        デフォルトでは、Label Valueパラメーターの値に対して文字列照合が実行されます。 コンテナーは、ポッドラベルの値がラベル値パラメーターの値と同じである場合にのみ一致します。 キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、Label Nameパラメーターをenvironmentに設定し、Label Valueパラメーターを ^(dev | pre)$ に設定した場合、ポッドラベルにenvironment:devまたはenvironment:preが含まれるコンテナーが一致します。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアのいずれかで構成されるポッドラベルがコンテナーに含まれている場合、コンテナーは照合されます。

    • Kubernetesポッドラベルブラックリスト

      Kubernetesポッドラベルブラックリストを設定します。 ブラックリストは、テキストログが収集されないコンテナを指定します。

      • [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定されたラベル名がポッドラベルに含まれるコンテナーは除外されます。

      • [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定すると、指定されたラベル名: ラベル値がポッドのラベルに含まれるコンテナーが除外されます。

        デフォルトでは、Label Valueパラメーターの値に対して文字列照合が実行されます。 コンテナーは、ポッドラベルの値がラベル値パラメーターの値と同じである場合にのみ除外されます。 ラベル値パラメーターに、キャレット (^) で始まり、ドル記号 ($) で終わる値を指定した場合、正規表現マッチングが実行されます。 たとえば、Label Nameパラメーターをenvironmentに設定し、Label Valueパラメーターを ^(dev | pre)$ に設定した場合、ポッドラベルにenvironment:devまたはenvironment:preが含まれるコンテナーは除外されます。

      キーと値のペアは、OR演算子を使用して評価されます。 指定されたキーと値のペアのいずれかで構成されるポッドラベルがコンテナーに含まれている場合、コンテナーは除外されます。

    ログタグの強化

    環境変数とポッドラベルを使用してログタグを指定します。

    ファイルのエンコード

    ログファイルのエンコード形式を選択します。

    最初のコレクションサイズ

    Logtailがファイルからログを最初に収集するときに、Logtailがログファイルから収集できるデータのサイズを指定します。 First Collection Sizeのデフォルト値は1024です。 (単位:KB)

    • ファイルサイズが1,024 KB未満の場合、Logtailはファイルの先頭からデータを収集します。

    • ファイルサイズが1,024 KBを超える場合、Logtailはファイル内の最後の1,024 KBのデータを収集します。

    ビジネス要件に基づいて、最初のコレクションサイズを指定できます。 有効な値: 0 ~ 10485760 (単位:KB)

    コレクションブラックリスト

    [コレクションブラックリスト] をオンにする場合、ブラックリストを設定して、Simple Log Serviceがログを収集するときにスキップするディレクトリまたはファイルを指定する必要があります。 正確なディレクトリとファイル名を指定できます。 ワイルドカード文字を使用して、ディレクトリとファイル名を指定することもできます。 このパラメーターを設定すると、アスタリスク (*) または疑問符 (?) のみをワイルドカード文字として使用できます。

    重要
    • ワイルドカード文字を使用してファイルパスを設定し、指定したディレクトリ内の一部のディレクトリをスキップする場合は、Collection Blacklistを設定して完全なディレクトリを入力する必要があります。

      たとえば、[ファイルパス]/home/admin/app */log/*.logに設定し、/home/admin/app1 * ディレクトリ内のすべてのサブディレクトリをスキップする場合は、[ディレクトリブラックリスト] を選択し、[ディレクトリ名] フィールドに /home/admin/app1 */** と入力する必要があります。 /home/admin/app1 * と入力した場合、ブラックリストは有効になりません。

    • ブラックリストが使用されているとき、計算オーバーヘッドが生成される。 ブラックリストには最大10エントリを追加することを推奨します。

    • スラッシュ (/) で終わるディレクトリパスは指定できません。 たとえば、パスを /home/admin/dir1/ に設定した場合、ディレクトリのブラックリストは有効になりません。

    次の種類のブラックリストがサポートされています: ファイルパスブラックリスト、ファイルブラックリスト、およびディレクトリブラックリスト。

    ファイルパスブラックリスト

    • [File Path Blacklist] を選択し、[File Path Name] フィールドに /home/admin/private *.logと入力すると、名前の接頭辞がprivate、接尾辞がであるすべてのファイルが表示されます。/home/admin/ ディレクトリへのログインはスキップされます。

    • [File Path Blacklist] を選択し、[File Path Name] フィールドに /home/admin/private */*_inner.logと入力した場合、/home/admin/ ディレクトリのプレフィックスがprivateであるサブディレクトリの_inner.logで名前がサフィックスされているファイルはすべてスキップされます。 たとえば、/home/admin/private/app_inner.logファイルはスキップされますが、/home/admin/private/app.logファイルはスキップされません。

    ファイルブラックリスト

    [File Blacklist] を選択し、[File Name] フィールドにapp_inner.logと入力すると、名前がapp_inner.logであるすべてのファイルがスキップされます。

    ディレクトリブラックリスト

    • [Directory Blacklist] を選択し、[Directory Name] フィールドに /home/admin/dir1と入力すると、/home/admin/dir1ディレクトリ内のすべてのファイルがスキップされます。

    • [Directory Blacklist] を選択し、[Directory Name] フィールドに /home/admin/dir * と入力した場合、/home/admin/ ディレクトリの名前の先頭にdirが付いているすべてのサブディレクトリのファイルはスキップされます。

    • [Directory Blacklist] を選択し、[Directory Name] フィールドに /home/admin/*/dirと入力した場合、/home/admin/ ディレクトリの各第2レベルのサブディレクトリのdirサブディレクトリにあるすべてのファイルがスキップされます。 たとえば、/home/admin/a/dirディレクトリのファイルはスキップされますが、/home/admin/a/b/dirディレクトリのファイルはスキップされません。

    ファイルの複数回の収集を許可

    デフォルトでは、ログファイルからログを収集するために使用できるLogtail設定は1つだけです。 複数のLogtail設定を使用してログファイルからログを収集するには、[ファイルの複数回の収集を許可] をオンにします。

    高度なパラメータ

    Logtail設定の特定のパラメーターを手動で設定する必要があります。 詳細については、「Logtailパイプライン設定の作成」をご参照ください。

    プロセッサ構成

    パラメーター

    説明

    ログのサンプル

    実際のシナリオから収集されたサンプルログを追加します。 サンプルログを使用して、ログ処理に関連するパラメーターを簡単に設定できます。 複数のサンプルログを追加できます。 ログの長さの合計が1,500文字を超えないようにしてください。

    [2023-10-01T10:30:01,000] [情報] java.lang.Exception: 例外が発生しました
        at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
        at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
        TestPrintStackTrace.main(TestPrintStackTrace.java:16) 

    マルチラインモード

    • 複数行のログの種類を指定します。 複数行のログは、複数の連続した行にまたがっています。 このパラメーターを設定して、ログファイル内の各複数行ログを識別できます。

      • カスタム: 複数行のログは、Regex to Match First lineの値に基づいて識別されます。

      • 複数行のJSON: 各JSONオブジェクトは複数行に展開されます。 例:

        {
          "name": "John Doe" 、
          "年齢": 30、
          "address": {
            "city": "New York",
            "国": "アメリカ"
          }
        }
    • 分割が失敗した場合の処理方法を設定します。

      スレッド "main" java.lang.NullPointerExceptionの

      例外
          at com.example.MyClass.methodA(MyClass.java:12)
          at com.example.MyClass.methodB(MyClass.java:34)
          at com.example.MyClass.main(MyClass.java: 1/2 0) 

      上記のサンプルログの場合、Simple log Serviceはログを破棄するか、ログの分割に失敗した場合に1行ずつログとして保持します。

      • 破棄: ログは破棄されます。

      • 1行の保持: ログテキストの各行はログとして保持されます。 合計4つのログが保持されます。

    処理方法

    [プロセッサ] を選択します。 データ処理用にネイティブプラグイン拡張プラグインを追加できます。 データ処理用のLogtailプラグインの詳細については、「Logtailプラグインの概要」をご参照ください。

    重要

    データ処理のLogtailプラグインの制限があります。 詳細については、Simple Log Serviceコンソールの画面上の手順を参照してください。

    • V2.0より前のLogtail

      • ネイティブプラグインと拡張プラグインを同時に追加することはできません。

      • ネイティブプラグインは、テキストログの収集にのみ使用できます。 ネイティブプラグインを追加するときは、次の項目に注意してください。

        • データ処理には、データ解析 (Regexモード) 、データ解析 (デリミターモード) 、データ解析 (JSONモード) 、データ解析 (NGINXモード) 、データ解析 (Apacheモード) 、データ解析 (IISモード) のいずれかを最初のプラグインとして追加する必要があります。

        • 最初のプラグインを追加した後、1つのTime Parsingプラグイン、1つのData Filteringプラグイン、および複数のData Maskingプラグインを追加できます。

      • 拡張プラグインは、ネイティブプラグインを追加した後にのみ追加できます。

    • Logtail V2.0

      • データ処理用のネイティブプラグインを任意に組み合わせることができます。

      • ネイティブプラグインと拡張プラグインを組み合わせることができます。 拡張プラグインがネイティブプラグインの後に追加されていることを確認します。

  6. インデックスの作成プレビュー 次に、[次へ] をクリックします。 デフォルトでは、Simple Log Serviceでフルテキストインデックスが有効になっています。 手動モードまたは自動モードで収集したログに基づいてフィールドインデックスを設定することもできます。 自動モードでフィールドインデックスを設定するには、[自動インデックス生成] をクリックします。 これにより、Simple Log Serviceは自動的にフィールドインデックスを作成します。 詳細については、「インデックスの作成」をご参照ください。

    重要

    ログのすべてのフィールドをクエリする場合は、フルテキストインデックスを使用することを推奨します。 特定のフィールドのみをクエリする場合は、フィールドインデックスを使用することを推奨します。 これは、インデックストラフィックを減らすのに役立ちます。 フィールドを分析する場合は、フィールドインデックスを作成する必要があります。 分析のために、クエリ文にSELECT文を含める必要があります。

  7. [クエリログ] をクリックします。 次に、Logstoreのクエリと分析ページにリダイレクトされます。

    インデックスが有効になるまで約1分待つ必要があります。 次に、収集したログを [生ログ] タブで表示できます。 詳細については、「ログの照会と分析」をご参照ください。

(推奨) CRD - AliyunPipelineConfig

Logtail設定の作成

重要

LogtailコンポーネントV0.5.1以降のみがAliyunPipelineConfigをサポートしています。

Logtail設定を作成するには、AliyunPipelineConfig CRDからCRを作成するだけです。 Logtail設定が作成されると、自動的に適用されます。 CRに基づいて作成されたLogtail設定を変更する場合は、CRを変更する必要があります。

  1. クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します

  2. 次のコマンドを実行して、YAMLファイルを作成します。

    次のコマンドで、cube.yamlはサンプルファイル名です。 ビジネス要件に基づいて別のファイル名を指定できます。

    vim cube.yaml
  3. YAMLファイルに次のスクリプトを入力し、ビジネス要件に基づいてパラメーターを設定します。

    重要
    • configNameパラメーターの値は、Logtailコンポーネントのインストールに使用するSimple Log Serviceプロジェクトで一意である必要があります。

    • Logtail設定ごとにCRを設定する必要があります。 複数のCRが同じLogtail設定に関連付けられている場合、最初のCR以外のCRは有効になりません。

    • AliyunPipelineConfig CRDに関連するパラメーターの詳細については、「 (推奨) AliyunPipelineConfigを使用してLogtail構成を管理する」をご参照ください。 この例では、Logtail設定にテキストログ収集の設定が含まれています。 詳細については、「CreateLogtailPipelineConfig」をご参照ください。

    • config.flushers.Logstoreパラメーターで指定されたLogstoreが存在することを確認します。 spec.logstoreパラメーターを設定して、Logstoreを自動的に作成できます。

    特定のコンテナから単一行のテキストログを収集する

    この例では、example-k8s-fileという名前のLogtail設定が作成され、クラスター内のappを含む名前のコンテナーから1行のテキストログが収集されます。 ファイルはtest.LOGで、パスは /data/logs/app_1です。

    収集されたログは、k8s-log-testという名前のプロジェクトに属するk8s-fileという名前のLogstoreに保存されます。

    apiVersion: telemetry.alibabacloud.com/v1alpha1
    # ClusterAliyunPipelineConfig CRDからCRを作成します。
    種類: ClusterAliyunPipelineConfig
    メタデータ:
      # リソースの名前を指定します。 名前は、現在のKubernetesクラスターで一意である必要があります。 この名前は、作成されたLogtail設定の名前と同じです。
      名前: example-k8s-file
    spec:
      # ログを収集するプロジェクトを指定します。
      プロジェクト:
        名前: k8s-log-test
      # ログを保存するLogstoreを作成します。
      logstore:
        -name: k8s-file
      # Logtail設定のパラメーターを設定します。
      config:
        # Logtail入力プラグインを設定します。
        入力:
          # input_fileプラグインを使用して、コンテナからテキストログを収集します。
          -タイプ: input_file
            # コンテナ内のファイルパスを指定します。
            FilePaths:
              - /data/logs/app_1/**/test.LOG
            # コンテナー検出機能を有効にします。 
            EnableContainerDiscovery: true
            # フィルターコンテナーに条件を追加します。 複数の条件は、論理ANDを使用して評価されます。 
            ContainerFilters:
              # 必要なコンテナが属するポッドの名前空間を指定します。 正規表現マッチングがサポートされています。 
              K8sNamespaceRegex: デフォルト
              # 必要なコンテナの名前を指定します。 正規表現マッチングがサポートされています。 
              K8sContainerRegex: ^(.* app.*)$
        # Logtail出力プラグインを設定します。
        flushers:
          # flusher_slsプラグインを使用して、特定のLogstoreにログを送信します。 
          -タイプ: flusher_sls
            # Logstoreが存在することを確認します。
            Logstore: k8s-file
            # エンドポイントが有効であることを確認します。
            エンドポイント: cn-hangzhou.log.aliyuncs.com
            リージョン: cn-hangzhou
            TelemetryType: ログ 

    すべてのコンテナから複数行のテキストログを収集し、正規表現を使用してログを解析する

    この例では、クラスター内のすべてのコンテナーから複数行のテキストログを収集するために、example-k8sファイルという名前のLogtail設定が作成されます。 ファイルはtest.LOGで、パスは /data/logs/app_1です。 収集されたログはJSONモードで解析され、k8s-log-testという名前のプロジェクトに属するk8s-fileという名前のLogstoreに保存されます。

    次の例で提供されるサンプルログは、{"content": "2024-06-19 16:35:00 INFOテストログ \nline-1\nline-2\nend"} の形式でinput_fileプラグインによって読み取られます。 次に、ログは正規表現に基づいて {"time": "2024-06-19 16:35:00" 、"level": "INFO" 、"msg": "test log\nline-1\nline-2\nend"} に解析されます。

    apiVersion: telemetry.alibabacloud.com/v1alpha1
    # ClusterAliyunPipelineConfig CRDからCRを作成します。
    種類: ClusterAliyunPipelineConfig
    メタデータ:
      # リソースの名前を指定します。 名前は、現在のKubernetesクラスターで一意である必要があります。 この名前は、作成されたLogtail設定の名前と同じです。
      名前: example-k8s-file
    spec:
      # ログを収集するプロジェクトを指定します。
      プロジェクト:
        名前: k8s-log-test
      # ログを保存するLogstoreを作成します。
      logstore:
        -name: k8s-file
      # Logtail設定のパラメーターを設定します。
      config:
        # サンプルログを指定します。 このパラメーターは空のままにできます。
        サンプル: |
          2024-06-19 16:35:00 INFOテストログ
          ライン-1
          ライン-2
          end
        # Logtail入力プラグインを設定します。
        入力:
          # input_fileプラグインを使用して、コンテナから複数行のテキストログを収集します。
          -タイプ: input_file
            # コンテナ内のファイルパスを指定します。
            FilePaths:
              - /data/logs/app_1/**/test.LOG
            # コンテナー検出機能を有効にします。 
            EnableContainerDiscovery: true
            # 複数行のログ収集を有効にします。
            マルチライン:
              # 正規表現に基づいて、ログの最初の行の先頭に一致するようにカスタムモードを指定します。
              モード: カスタム
              # ログの最初の行の先頭を一致させるために使用される正規表現を指定します。
              StartPattern: \d +-\d +-\d +.*
        # Logtail処理プラグインを指定します。
        プロセッサ:
          # processor_parse_regex_nativeプラグインを使用して、指定された正規表現に基づいてログを解析します。
          -タイプ: processor_parse_regex_native
            # 入力フィールドの名前を指定します。
            SourceKey: content
            # 解析に使用される正規表現を指定します。 キャプチャグループを使用してフィールドを抽出します。
            正規表現: (\d +-\d +-\d +\s *\d +:\d +:\d +)\s *(\S +)\s *(.*)
            # 抽出するフィールドを指定します。
            キー: ["time", "level", "msg"]
        # Logtail出力プラグインを設定します。
        flushers:
          # flusher_slsプラグインを使用して、特定のLogstoreにログを送信します。 
          -タイプ: flusher_sls
            # Logstoreが存在することを確認します。
            Logstore: k8s-file
            # エンドポイントが有効であることを確認します。
            エンドポイント: cn-hangzhou.log.aliyuncs.com
            リージョン: cn-hangzhou
            TelemetryType: ログ 
  4. 次のコマンドを実行してLogtail設定を適用します。 Logtail設定が適用されると、Logtailは指定されたコンテナからテキストログの収集を開始し、そのログをSimple Log Serviceに送信します。

    次のコマンドで、cube.yamlはサンプルファイル名です。 ビジネス要件に基づいて別のファイル名を指定できます。

    kubectl apply -f cube.yaml
    重要

    ログを収集したら、インデックスを作成する必要があります。 次に、Logstore内のログを照会および分析できます。 詳細については、「インデックスの作成」をご参照ください。

CRD - AliyunLogConfig

Logtail設定を作成するには、AliyunLogConfig CRDからCRを作成するだけです。 Logtail設定が作成されると、自動的に適用されます。 CRに基づいて作成されたLogtail設定を変更する場合は、CRを変更する必要があります。

  1. クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します

  2. 次のコマンドを実行して、YAMLファイルを作成します。

    次のコマンドで、cube.yamlはサンプルファイル名です。 ビジネス要件に基づいて別のファイル名を指定できます。

    vim cube.yaml
  3. YAMLファイルに次のスクリプトを入力し、ビジネス要件に基づいてパラメーターを設定します。

    重要
    • configNameパラメーターの値は、Logtailコンポーネントのインストールに使用するSimple Log Serviceプロジェクトで一意である必要があります。

    • 複数のCRが同じLogtail設定に関連付けられている場合、いずれかのCRを削除または変更すると、Logtail設定が影響を受けます。 CRが削除または変更されると、関連する他のCRのステータスがSimple Log ServiceのLogtail設定のステータスと一致しなくなります。

    • CRパラメーターの詳細については、「AliyunLogConfigを使用したLogtail設定の管理」をご参照ください。 この例では、Logtail設定にテキストログ収集の設定が含まれています。 詳細については、「CreateConfig」をご参照ください。

    特定のコンテナから単一行のテキストログを収集する

    この例では、example-k8s-fileという名前のLogtail構成が作成され、クラスター内の名前がappで始まるすべてのポッドのコンテナーから単一行のテキストログが収集されます。 ファイルはtest.LOGで、パスは /data/logs/app_1です。 収集されたログは、k8s-log-testという名前のプロジェクトに属するk8s-fileという名前のLogstoreに保存されます。

    apiVersion: log.alibabacloud.com/v1alpha1
    kind: AliyunLogConfig
    metadata:
      # Specify the name of the resource. The name must be unique in the current Kubernetes cluster. 
      name: example-k8s-file
      namespace: kube-system
    spec:
      # Specify the name of the project. If you leave this parameter empty, the project named k8s-log-<your_cluster_id> is used.
      project: k8s-log-test
      # Specify the name of the Logstore. If the specified Logstore does not exist, Simple Log Service automatically creates a Logstore. 
      logstore: k8s-file
      # Configure the parameters for the Logtail configuration. 
      logtailConfig:
        # Specify the type of the data source. If you want to collect text logs, set the value to file. 
        inputType: file
        # Specify the name of the Logtail configuration. 
        configName: example-k8s-file
        inputDetail:
          # Specify the simple mode to collect text logs. 
          logType: common_reg_log
          # Specify the log file path. 
          logPath: /data/logs/app_1
          # Specify the log file name. You can use wildcard characters (* and ?) when you specify the log file name. Example: log_*.log. 
          filePattern: test.LOG
          # Set the value to true if you want to collect text logs from containers. 
          dockerFile: true
          # Specify conditions to filter containers.
          advanced:
            k8s:
              K8sPodRegex: '^(app.*)$'
  4. 次のコマンドを実行してLogtail設定を適用します。 Logtail設定が適用されると、Logtailは指定されたコンテナからテキストログの収集を開始し、そのログをSimple Log Serviceに送信します。

    次のコマンドで、cube.yamlはサンプルファイル名です。 ビジネス要件に基づいて別のファイル名を指定できます。

    kubectl apply -f cube.yaml
    重要

    ログを収集したら、インデックスを作成する必要があります。 次に、Logstore内のログを照会および分析できます。 詳細については、「インデックスの作成」をご参照ください。

Logtail設定の表示

コンソール

  1. Simple Log Serviceコンソール.

  2. [プロジェクト] セクションで、対象のプロジェクトをクリックします。

  3. [ログストレージ] > [ログストア] を選択します。 対象のLogtail設定の > アイコンをクリックします。 [データインポート] > [Logtail設定] を選択します。

  4. 対象のLogtail設定をクリックして、設定の詳細を表示します。

(推奨) CRD - AliyunPipelineConfig

AliyunPipelineConfig CRDを使用して作成されたすべてのLogtail設定を表示する

kubectl get clusteraliyunpipelineconfigsコマンドを実行して、Logtail設定を表示できます。

AliyunPipelineConfig CRDを使用して作成されたLogtail設定の詳細を表示する

次のコマンドを実行して、Logtail設定の詳細を表示できます。 次のコマンドで、<config_name> は、AliyunPipelineConfig CRDから作成される必要なCRの名前を指定します。 ビジネス要件に基づいて値を指定できます。

kubectl get clusteraliyunpipelineconfigs <config_name> -o yaml

次のサンプルコードは、サンプル出力を提供します。 この例では、Logtail設定は、[特定のコンテナーからの単一行テキストログの収集] で作成されたCRに基づいて作成されます。 statusパラメーターを表示して、Logtail設定が適用されているかどうかを確認できます。

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  finalizers:
    - finalizer.pipeline.alibabacloud.com
  name: example-k8s-file
# The expected configuration.
spec:
  config:
    flushers:
      - Endpoint: cn-hangzhou.log.aliyuncs.com
        Logstore: k8s-file
        Region: cn-hangzhou
        TelemetryType: logs
        Type: flusher_sls
    inputs:
      - EnableContainerDiscovery: true
        FilePaths:
          - /data/logs/app_1/**/test.LOG
        Type: input_file
  logstores:
    - encryptConf: {}
      name: k8s-file
  project:
    name: k8s-log-clusterid
# The application status of the CR.
status:
  # Whether the CR is successfully applied.
  success: true
  # The status information of the CR.
  message: success
  # The update time of the current status.
  lastUpdateTime: '2024-06-19T09:21:34.215702958Z'
  # The Logtail configuration that was successfully applied. Default values are used in the Logtail configuration.
  lastAppliedConfig:
    # The time when the Logtail configuration was applied.
    appliedTime: '2024-06-19T09:21:34.215702958Z'
    # The detailed settings of the Logtail configuration.
    config:
      configTags:
        sls.crd.cluster: e2e-cluster-id
        sls.crd.kind: ClusterAliyunPipelineConfig
        sls.logtail.channel: CRD
      flushers:
        - Endpoint: cn-hangzhou.log.aliyuncs.com
          Logstore: k8s-file
          Region: cn-hangzhou
          TelemetryType: logs
          Type: flusher_sls
      inputs:
        - EnableContainerDiscovery: true
          FilePaths:
            - /data/logs/app_1/**/test.LOG
          Type: input_file
      name: example-k8s-file
    logstores:
      - appendMeta: true
        autoSplit: true
        encryptConf: {}
        maxSplitShard: 64
        name: k8s-file
        shardCount: 2
        ttl: 30
    machineGroups:
      - name: k8s-group-clusterid
    project:
      description: 'k8s log project, created by alibaba cloud log controller'
      endpoint: cn-hangzhou.log.aliyuncs.com
      name: k8s-log-clusterid

CRD - AliyunLogConfig

AliyunLogConfig CRDを使用して作成されたすべてのLogtail設定を表示する

kubectl get aliyunlogconfigsコマンドを実行して、Logtail設定を表示できます。 次の図は、サンプル出力を示しています。

image.png

AliyunLogConfig CRDを使用して作成されたLogtail構成の詳細を表示する

kubectl get aliyunlogconfigs <config_name> -o yamlコマンドを実行して、Logtail設定の詳細を表示できます。 次のコマンドで、<config_name> は、AliyunLogConfig CRDから作成される必要なCRの名前を指定します。 ビジネス要件に基づいて値を指定できます。 次の図は、サンプル出力を示しています。

出力のstatusおよびstatusCodeパラメーターは、Logtail設定のステータスを示します。

  • statusCodeパラメーターの値が200の場合、Logtail設定が適用されます。

  • statusCodeパラメーターの値が200でない場合、Logtail設定は適用されません。

image.png

収集したログの照会と分析

  1. Simple Log Serviceコンソールの [プロジェクト] セクションで、管理するプロジェクトをクリックして、プロジェクトの詳細ページに移動します。

    image

  2. 管理するLogstoreを見つけ、Logstoreの上にポインターを移動し、图标アイコンをクリックしてから、[検索と分析] を選択してKubernetesクラスターのログを表示します。

    image

コンテナテキストログのデフォルトフィールド

次の表に、各コンテナテキストログにデフォルトで含まれるフィールドを示します。

フィールド名

説明

__タグ __:__ ホスト名__

コンテナーホストの名前。

__tag __:__ path__

コンテナー内のログファイルのパス。

__tag __:_ container_ip_

コンテナーのIPアドレス。

__タグ __:_ image_name_

コンテナーで使用されるイメージの名前。

__tag __:_ pod_name_

ポッドの名前。

__tag __:_ 名前空間_

ポッドが属する名前空間。

__tag __:_ pod_uid_

ポッドの一意識別子 (UID) 。

関連ドキュメント