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

Simple Log Service:Kubernetes CRD を使用してクラスターからコンテナーログ (標準出力とファイル) を収集する

最終更新日:Nov 09, 2025

ログ収集設定を Kubernetes カスタムリソース定義 (CRD) として定義することで、Container Service for Kubernetes (ACK) や自己管理クラスターを含むすべてのクラスターで管理を統一できます。このアプローチは、一貫性がなくエラーが発生しやすい手動プロセスを、kubectl または CI/CD パイプラインによるバージョン管理された自動化に置き換えます。LoongCollector のホットリロード機能と組み合わせることで、構成の変更は収集コンポーネントを再起動することなく即座に有効になります。これにより、運用保守 (O&M) の効率とシステムの保守性が向上します。

従来の AliyunLogConfig CRD はメンテナンスされなくなりました。代わりに新しい AliyunPipelineConfig CRD を使用してください。新旧バージョンの比較については、「CRD タイプ」をご参照ください。
重要

CRD を使用して作成された収集構成は、対応する CRD を更新することによってのみ変更できます。Simple Log Service コンソールで行われた変更は CRD に同期されず、有効になりません。

適用性

  • 動作環境:

    • ACK (マネージド版および専用版) および自己管理 Kubernetes クラスターをサポートします。

    • Mount propagation: HostToContainer をサポートする Kubernetes バージョン 1.16.0 以降

    • コンテナーランタイム (Docker および Containerd のみ)

      • Docker:

        • docker.sock へのアクセス権が必要です。

        • 標準出力の収集は、JSON ログドライバーのみをサポートします。

        • overlay および overlay2 ストレージドライバーのみをサポートします。他のタイプの場合、ログディレクトリを手動でマウントする必要があります。

      • Containerd: containerd.sock へのアクセス権が必要です。

  • リソース要件: LoongCollector (Logtail) は system-cluster-critical の高い優先度で実行されます。クラスターリソースが不十分な場合、ノード上の既存の Pod を退去させる可能性があるため、デプロイしないでください。

    • CPU: 少なくとも 0.1 コアを予約してください。

    • メモリ: 収集コンポーネントには少なくとも 150 MB、コントローラーコンポーネントには少なくとも 100 MB が必要です。

    • 実際の使用量は、収集レート、監視対象のディレクトリとファイルの数、および送信のブロッキングによって異なります。実際の使用量が構成された制限の 80% 未満に留まるようにしてください。

  • 権限要件: デプロイに使用する Alibaba Cloud アカウントまたは RAM ユーザーは、AliyunLogFullAccess 権限を持っている必要があります。

    カスタム権限ポリシーを作成するには、「AliyunCSManagedLogRolePolicy」システムポリシーをご参照ください。このポリシーから権限をコピーし、ターゲットの RAM ユーザーまたはロールに付与して、詳細な権限を構成します。

収集構成の作成フロー

  1. LoongCollector のインストール: LoongCollector を DaemonSet としてデプロイし、クラスター内の各ノードで収集コンテナーが実行されるようにします。これにより、そのノード上のすべてのコンテナーからログを統一的に収集できます。

  2. Logstore の作成: Logstore はログデータのストレージユニットです。1 つのプロジェクトに複数の Logstore を作成できます。

  3. 収集構成 YAML ファイルの作成:kubectl を使用してクラスターに接続する」をご参照ください。次のいずれかの方法で収集構成ファイルを作成します。

    • 方法 1: 収集構成ジェネレーターを使用する

      Simple Log Service コンソールの 収集構成ジェネレーターを使用して、グラフィカルユーザーインターフェイスでパラメーターを入力し、標準の YAML ファイルを自動的に生成します。

    • 方法 2: YAML ファイルを手動で記述する

      このトピックの例とワークフローに基づいて YAML ファイルを記述します。最小構成から始めて、徐々に処理ロジックと高度な機能を追加していきます。

      このトピックでカバーされていない複雑なユースケースや、詳細なカスタマイズが必要なフィールドについては、「AliyunPipelineConfig パラメーター」をご参照ください。フィールド、値のルール、およびプラグイン機能の完全なリストが記載されています。

    完全な収集構成は、通常、次の部分で構成されます。

    • 最小構成 (必須): クラスターから Simple Log Service へのデータトンネルを構築します。これには 2 つの部分が含まれます。

      • 入力 (inputs): ログのソースを定義します。コンテナーログには、次の 2 つのログソースが含まれます。MySQL クエリ結果など、他の種類のログを収集するには、「入力プラグイン」をご参照ください。

        • コンテナー標準出力 (stdout および stderr): コンテナープログラムがコンソールに出力するログコンテンツ。

        • テキストログファイル: コンテナー内の指定されたパスに書き込まれるログファイル。

      • 出力 (flushers): ログの宛先を定義します。収集されたログを指定された Logstore に送信します。

        宛先プロジェクトまたは Logstore が存在しない場合、システムは自動的に作成します。事前に プロジェクトLogstore を手動で作成することもできます。
    • 一般的な処理構成 (オプション): processors フィールドを定義して、生ログに対して構造化解析 (正規表現やデリミタ解析など)、マスキング、またはフィルタリングを実行します。

      このトピックでは、一般的なログ処理のユースケースをカバーするネイティブ処理プラグインのみを説明します。その他の機能については、「拡張処理プラグイン」をご参照ください。
    • その他の詳細設定 (オプション): 複数行ログ収集やログタグのエンリッチメントなどの機能を実装して、より詳細な収集要件を満たします。

    構造の例:

    apiVersion: telemetry.alibabacloud.com/v1alpha1 # デフォルト値を使用します。変更しないでください。
    kind: ClusterAliyunPipelineConfig               # デフォルト値を使用します。変更しないでください。
    metadata:
      name: test-config                             # リソース名を設定します。Kubernetes クラスター内で一意である必要があります。
    spec:
      project:                                      # 宛先プロジェクトの名前を設定します。
        name: k8s-your-project                      
      config:                                       # Logtail 収集構成を設定します。
        inputs:                                     # Logtail 収集構成の入力プラグインを設定します。
          ...
        processors:                                 # Logtail 収集構成の処理プラグインを設定します。
          ...
        flushers:                                   # Logtail 収集構成の出力プラグインを設定します。
          ...
  4. 構成の適用

    kubectl apply -f <your_yaml>

LoongCollector (Logtail) のインストール

LoongCollector は、Simple Log Service (SLS) の次世代ログ収集エージェントであり、Logtail のアップグレード版です。LoongCollector と Logtail は同時にインストールできません。Logtail をインストールするには、「Logtail のインストールと構成」をご参照ください。

このトピックでは、LoongCollector の基本的なインストール手順のみを説明します。詳細なパラメーターについては、「LoongCollector のインストール (Kubernetes)」をご参照ください。すでに LoongCollector または Logtail をインストールしている場合は、このステップをスキップして、収集したログを保存するための Logstore の作成に進んでください。

ACK クラスター

Container Service for Kubernetes (ACK) コンソールから LoongCollector をインストールします。デフォルトでは、ログは現在の Alibaba Cloud アカウントに属する Simple Log Service (SLS) プロジェクトに送信されます。

  1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、ターゲットクラスターの名前をクリックして詳細ページを開きます。

  3. 左側のナビゲーションウィンドウで、[アドオン] をクリックします。

  4. [ログとモニタリング] タブで、loongcollector を見つけて [インストール] をクリックします。

    説明

    新しいクラスターの場合、[コンポーネント構成] ページで [Log Service を有効にする] を選択します。次に、[新しいプロジェクトを作成] または [既存のプロジェクトを使用] を選択します。

    インストールが完了すると、SLS は ACK クラスターが配置されているリージョンに関連リソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます

    リソースタイプ

    リソース名

    機能

    プロジェクト

    k8s-log-${cluster_id}

    異なるサービスのログを分離するためのリソース管理ユニット。

    より柔軟なログリソース管理のためにプロジェクトを作成するには、「プロジェクトの作成」をご参照ください。

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードのコレクション。

    Logstore

    config-operation-log

    重要

    この Logstore は削除しないでください。

    loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目をご参照ください。この Logstore に収集構成を作成しないでください。

自己管理クラスター

  1. Kubernetes クラスターに接続し、お使いのリージョンに対応するコマンドを実行して、LoongCollector とその依存コンポーネントをダウンロードします。

    中国国内のリージョン:

    wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

    中国国外のリージョン:

    wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh
  2. loongcollector-custom-k8s-package ディレクトリに移動し、./loongcollector/values.yaml 構成ファイルを変更します。

    # ===================== 必須パラメーター =====================
    # 収集されたログを管理するプロジェクトの名前。例: k8s-log-custom-sd89ehdq。
    projectName: ""
    # プロジェクトが配置されているリージョン。上海の例: cn-shanghai
    region: ""
    # プロジェクトを所有する Alibaba Cloud アカウントの ID。ID を引用符で囲みます。例: "123456789"
    aliUid: ""
    # ネットワークタイプ。有効な値: Internet および Intranet。デフォルト値: Internet。
    net: Internet
    # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID と AccessKey Secret。アカウントまたはユーザーは AliyunLogFullAccess システムポリシーを持っている必要があります。
    accessKeyID: ""
    accessKeySecret: ""
    # カスタムクラスター ID。ID には、大文字、小文字、数字、ハイフン (-) のみを含めることができます。
    clusterID: ""
  3. loongcollector-custom-k8s-package ディレクトリで、次のコマンドを実行して LoongCollector とその他の依存コンポーネントをインストールします。

    bash k8s-custom-install.sh install
  4. インストールが完了したら、コンポーネントの実行状態を確認します。

    Pod の起動に失敗した場合は、values.yaml の構成が正しいか、関連するイメージが正常にプルされたかを確認してください。
    # Pod の状態を確認します。
    kubectl get po -n kube-system | grep loongcollector-ds

    SLS はまた、以下のリソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます

    リソースタイプ

    リソース名

    機能

    プロジェクト

    values.yaml ファイルで指定した projectName の値

    異なるサービスのログを分離するためのリソース管理ユニット。

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードのコレクション。

    Logstore

    config-operation-log

    重要

    この Logstore は削除しないでください。

    loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目」をご参照ください。この Logstore に収集構成を作成しないでください。

Logstore の作成

すでに Logstore を作成している場合は、このステップをスキップして 収集の構成に進んでください。

  1. Simple Log Service コンソールにログインし、ターゲットプロジェクトの名前をクリックします。

  2. 左側のナビゲーションウィンドウで、image[ログストレージ] を選択し、[+] アイコンをクリックします。

  3. Logstore の作成ページで、次のコア構成を完了します。

    • [Logstore 名]: プロジェクト内で一意の名前を設定します。この名前は作成後に変更できません。

    • [Logstore タイプ]: 仕様の比較に基づいて、標準またはクエリを選択します。

    • [課金方法]:

      • [機能別課金]: ストレージ、インデックス、読み取り/書き込み操作など、各リソースに対して個別に課金されます。小規模なユースケースや、機能の使用量が不確かな場合に適しています。

      • [取り込みデータ量に応じた課金]: 取り込まれた生データの量によってのみ課金されます。30 日間の無料ストレージ期間と、データ変換や配信などの無料機能を提供します。コストモデルはシンプルで、ストレージ期間が 30 日に近い場合や、データ処理パイプラインが複雑な場合に適しています。

    • [データ保持期間]: ログを保持する日数を設定します。値の範囲は 1 日から 3650 日です。3650 の値は永続的なストレージを示します。デフォルトは 30 日です。

  4. 他の構成はデフォルト設定のままにして、[OK] をクリックします。他の構成の詳細については、「Logstore の管理」をご参照ください。

最小構成

<a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="2ba88d5208b3d">spec.config</a> では、入力 (inputs) と出力 (flushers) プラグインを構成します。これらのプラグインは、ログのソースと宛先を含む、コアのログ収集パスを定義します。

コンテナー標準出力 - 新バージョン

目的: コンソールに直接出力されるコンテナーの標準出力ログ (stdout/stderr) を収集します。

inputs プラグイン

収集構成の開始点。ログソースを定義します。現在、1 つの入力プラグインのみを構成できます。

  • Type String (必須)

    プラグインのタイプ。input_container_stdio に設定します。

  • IgnoringStderr boolean (オプション)

    標準エラーストリーム (stderr) を無視するかどうかを指定します。デフォルト値: false

    • true: stderr を収集しません。

    • false: stderr を収集します。

  • IgnoringStdout boolean (オプション)

    標準出力ストリーム (stdout) を無視するかどうかを指定します。デフォルト値: false

    • true: stdout を収集しません。

    • false: stdout を収集します。

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  # リソース名を設定します。Kubernetes クラスター内で一意である必要があり、作成された Logtail 収集構成の名前にもなります。
  name: new-stdio-config
spec:
  project:
    name: test-not-exist
  logstores:
    - name: new-stdio-logstore

  # LoongCollector (Logtail) の収集および処理構成を定義します。
  config:
    # --- 入力プラグイン: どこからログを収集するかを定義します ---
    inputs:
      # input_container_stdio プラグインを使用してコンテナーの標準出力を収集します。
      - Type: input_container_stdio
        IgnoringStderr: false
        IgnoringStdout: false

    # --- 処理プラグイン (オプション): ログをどのように解析および処理するかを定義します ---
    processors: []

    # --- 出力プラグイン: どこにログを送信するかを定義します ---
    flushers:
      - Type: flusher_sls    # SLS 出力プラグインを指定します。
        Logstore: new-stdio-logstore   

flushers 出力プラグイン

flusher_sls プラグインを構成して、収集したログをプロジェクト内の指定された Logstore に送信します。現在、1 つの出力プラグインのみを構成できます。

  • Type String (必須)

    プラグインのタイプ。flusher_sls に設定します。

  • Logstore String (必須)

    宛先 Logstore の名前。これにより、ログの実際の保存場所が決まります。

    説明

    指定された Logstore は存在するか、<a baseurl="t3010624_v1_6_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#471f2ca341s6j" id="4335117646mhr">spec.logstores</a> で宣言されている必要があります。

コンテナーのテキストファイルを収集する

目的: コンテナー内の特定のファイルパスに書き込まれたログ (従来の access.log や app.log ファイルなど) を収集します。

inputs プラグイン

収集構成の開始点。ログソースを定義します。現在、1 つの入力プラグインのみを構成できます。

  • Type String (必須)

    プラグインのタイプ。input_file に設定します。

  • FilePaths String (必須)

    収集したいログファイルのパスのリスト。

    • 現在、1 つのパスのみを構成できます。

    • ワイルドカード文字をサポートします:

      • *: 単一レベルのディレクトリ内のファイル名に一致します。

      • **: 複数レベルのサブディレクトリを再帰的に一致させます。一度しか出現できず、ファイル名の前にある必要があります。

  • MaxDirSearchDepth integer (オプション)

    パスに ** が含まれる場合、最大のディレクトリ深度を指定します。デフォルト値: 0。値の範囲: 0 から 1000。

  • FileEncoding String (オプション)

    ファイルのエンコード形式。デフォルト値: utf8。サポートされている値は次のとおりです。

    • utf8

    • gbk

  • EnableContainerDiscovery boolean (オプション)

    コンテナー検出機能を有効にするかどうかを指定します。デフォルト値: true

    説明

    このパラメーターは、LoongCollector (Logtail) が DaemonSet モードで実行され、収集ファイルパスがコンテナー内のパスである場合にのみ有効です。

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: easy-row-config
spec:
  # ログが送信される宛先プロジェクトを指定します。
  project:
    name: test-not-exist
  logstores:
    - name: easy-row-logstore

  # LoongCollector (Logtail) の収集および処理構成を定義します。
  config:
    # ログサンプル (オプション)
    sample: ''
    # --- 入力プラグイン: どこからログを収集するかを定義します ---
    inputs:
      # input_file プラグインを使用してコンテナーのテキストファイルを収集します。
      - Type: input_file         
        # ... 入力プラグインの特定の構成 ...
        # コンテナー内のファイルパス
        FilePaths:
          - /var/log/text1.log
        # 最大ディレクトリ監視深度  
        MaxDirSearchDepth: 0
        FileEncoding: utf8  
        # コンテナー検出機能を有効にします。
        EnableContainerDiscovery: true
        

    # --- 処理プラグイン (オプション): ログをどのように解析および処理するかを定義します ---
    processors: []    

    # --- 出力プラグイン: どこにログを送信するかを定義します ---
    flushers:
      - Type: flusher_sls        # SLS 出力プラグインを指定します。
        Logstore: easy-row-logstore

flushers 出力プラグイン

flusher_sls プラグインを構成して、収集したログをプロジェクト内の指定された Logstore に送信します。現在、1 つの出力プラグインのみを構成できます。

  • Type String (必須)

    プラグインのタイプ。flusher_sls に設定します。

  • Logstore String (必須)

    宛先 Logstore の名前。これにより、ログの実際の保存場所が決まります。

    説明

    指定された Logstore は存在するか、<a baseurl="t3010624_v1_6_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#471f2ca341s6j" id="0d8eb5204eevu">spec.logstores</a> で宣言されている必要があります。

一般的な処理構成

最小構成を完了した後、processors プラグインを追加して、生ログに対して構造化解析、マスキング、またはフィルタリングを実行できます。

コア構成: processors<a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="49324d8ed176z">spec.config</a> に追加して、処理プラグインを構成します。複数のプラグインを同時に有効にすることができます。

このトピックでは、一般的なログ処理のユースケースをカバーするネイティブ処理プラグインのみを説明します。追加機能については、「拡張処理プラグイン」をご参照ください。
重要

Logtail 2.0 以降のバージョンおよび LoongCollector コンポーネントについては、次のプラグインの組み合わせルールに従ってください。

  • まずネイティブプラグインを使用します。

  • ネイティブプラグインがニーズを満たせない場合は、ネイティブプラグインの後に拡張プラグインを構成します。

  • ネイティブプラグインは、拡張プラグインの前にのみ使用できます。

構造化構成

正規表現解析

正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。

キーフィールド

Type String (必須)

プラグインのタイプ。これを processor_parse_regex_native に設定します。

 # ...spec.config の下...
 processors:
  # 正規表現解析プラグインを使用してログコンテンツを解析します。
  - Type: processor_parse_regex_native
    # 生ログフィールドのソース、通常は content。
    SourceKey: content

    # ログフィールドを照合および抽出するために使用される正規表現。
    Regex: >-
      (\S+)\s-\s(\S+)\s$$([^]]+)$$\s"
      (\w+)\s(\S+)\s([^"]+)"
      \s(\d+)\s(\d+)\s"
      ([^"]+)"\s"
      ([^"]+).*

    # 抽出されたフィールドのリスト。正規表現グループに順番に対応します。
    Keys:
      - remote_addr
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_protocol
      - status
      - body_bytes_sent
      - http_referer
      - http_user_agent

    # 解析に失敗した場合にソースフィールドを保持するかどうかを指定します。
    KeepingSourceWhenParseFail: true

    # 解析に成功した場合にソースフィールドを保持するかどうかを指定します。
    KeepingSourceWhenParseSucceed: true

    # ソースフィールドが保持される場合、新しい名前を指定できます。
    RenamedSourceKey: fail

SourceKey String _(必須)

ソースフィールドの名前。

Regex String (必須)

ログに一致する正規表現。

Keys String (必須)

抽出されたフィールドのリスト。

KeepingSourceWhenParseFail boolean (オプション)

解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

KeepingSourceWhenParseSucceed boolean (オプション)

解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

RenamedSourceKey _String (オプション)

ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。

デリミタ解析

デリミタを使用してログコンテンツを構造化し、コンテンツをキーと値のペアに解析します。このメソッドは、単一文字および複数文字のデリミタをサポートします。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。これを processor_parse_delimiter_native に設定します。

# ...spec.config の下...
processors:
  # デリミタ解析プラグインの構成
  - Type: processor_parse_delimiter_native
    # 生フィールドのソース、通常は content
    SourceKey: content

    Separator: ','

    Quote: '"'

    # 抽出されたフィールドの名前を順番に定義します。
    Keys:
      - time
      - ip
      - request
      - status
      - size
      - user_agent

SourceKey String (必須)

ソースフィールドの名前。

Separator String _(必須)

フィールドセパレーター。たとえば、CSV ファイルはカンマ (,) を使用します。

Keys [String] (必須)

抽出されたフィールドのリスト。

Quote String (オプション)

引用符文字。カンマなどの特殊文字を含むフィールドコンテンツをラップするために使用します。

AllowingShortenedFields boolean (オプション)

抽出されたフィールドの数がキーの数より少なくてもよいかどうかを指定します。デフォルト値は true です。false に設定すると、このシナリオは解析失敗と見なされます。

OverflowedFieldsTreatment String (オプション)

抽出されたフィールドの数がキーの数より多い場合に実行するアクションを指定します。デフォルト値は extend です。有効な値には以下が含まれます。

  • extend: 追加のフィールドを保持します。各追加フィールドは、別のフィールドとしてログに追加されます。追加フィールドの名前は _column$i_ で、$i は 0 から始まる追加フィールドの序数です。

  • keep: 追加のフィールドを保持しますが、追加のコンテンツを単一のフィールドとしてログに追加します。フィールド名は _column0_ です。

  • discard: 追加のフィールドを破棄します。

KeepingSourceWhenParseFail boolean (オプション)

解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

KeepingSourceWhenParseSucceed boolean (オプション)

解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

RenamedSourceKey String (オプション)

ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。

標準 JSON 解析

オブジェクトタイプの JSON ログを構造化し、キーと値のペアに解析します。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。これを processor_parse_json_native に設定します。

# ...spec.config の下...
processors:
  # JSON 解析プラグインの構成
  - Type: processor_parse_json_native
    # 生ログフィールドのソース
    SourceKey: content

SourceKey String (必須)

ソースフィールドの名前。

KeepingSourceWhenParseFail boolean (オプション)

解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

KeepingSourceWhenParseSucceed boolean (オプション)

解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

RenamedSourceKey String (オプション)

ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。

ネストされた JSON 解析

展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。これを processor_json に設定します。

# ...spec.config の下...
processors:
  # JSON フィールド展開プラグインを構成します。
  - Type: processor_json
    # 解析するソースフィールドの名前を指定します。
    SourceKey: content
    
    ExpandDepth: 0

    ExpandConnector: '_'

    Prefix: expand

    IgnoreFirstConnector: false

    # 配列要素を個別のフィールドに展開するかどうかを指定します。
    ExpandArray: false

    # ソースフィールドのコンテンツを保持するかどうかを指定します。
    KeepSource: true

    # ソースフィールドが見つからない場合にエラーを報告するかどうかを指定します。
    NoKeyError: true

    # 展開されたフィールド名のプレフィックスとしてソースフィールド名を使用するかどうかを指定します。
    UseSourceKeyAsPrefix: false

    # JSON 解析に失敗した場合に生ログデータを保持するかどうかを指定します。
    KeepSourceIfParseError: true

SourceKey String (必須)

ソースフィールドの名前。

ExpandDepth integer (オプション)

JSON の展開深度。デフォルト値は 0 です。

  • 0: 解析可能な最も深いレベルまで展開します。

  • 1: 現在のレベルのみを展開します。以下同様です。

ExpandConnector String (オプション)

JSON 展開中のフィールド名に使用されるコネクタ。デフォルト値はアンダースコア (_) です。

Prefix String (オプション)

展開された JSON フィールドの名前のプレフィックス。

IgnoreFirstConnector String _(オプション)

最初のコネクタを無視するかどうかを指定します。これにより、トップレベルのフィールド名の前にコネクタが追加されるかどうかが決まります。デフォルト値は false です。

ExpandArray boolean (オプション)

配列タイプを展開するかどうかを指定します。デフォルト値は false です。

  • false (デフォルト): 配列は展開されません。

  • true: 配列は展開されます。たとえば、{"k":["1","2"]}{"k[0]":"1","k[1]":"2"} に展開されます。

説明

このパラメーターは Logtail 1.8.0 以降でサポートされています。

KeepSource boolean (オプション)

解析されたログにソースフィールドを保持するかどうかを指定します。デフォルト値は true です。

  • true: 保持

  • false: 破棄

NoKeyError boolean (オプション)

指定されたソースフィールドが生ログに見つからない場合にエラーを報告するかどうかを指定します。デフォルト値は true です。

  • true: エラーを報告します。

  • false: エラーを報告しません。

UseSourceKeyAsPrefix boolean (オプション)

すべての展開された JSON フィールド名のプレフィックスとしてソースフィールド名を使用するかどうかを指定します。

KeepSourceIfParseError boolean (オプション)

解析に失敗した場合に生ログデータを保持するかどうかを指定します。デフォルト値は true です。

  • true: 保持

  • false: 破棄

JSON 配列解析

json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。詳細については、「JSON 関数」をご参照ください。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。構造化プロセス言語 (SPL) プラグインの場合、これを processor_spl に設定します。

# ...spec.config の下...
processors:
  # SPL スクリプトを使用してログフィールドを処理します。
  - Type: processor_spl
    # スクリプトのタイムアウト (ミリ秒)。
    TimeoutMilliSeconds: 1000

    # content フィールドの JSON 配列から要素を抽出するために使用される SPL スクリプト。
    Script: >-
      * | extend
        json1 = json_extract(content, '$[0]'),
        json2 = json_extract(content, '$[1]')

Script String (必須)

SPL スクリプトのコンテンツ。このスクリプトは、content フィールドの JSON 配列から要素を抽出するために使用されます。

TimeoutMilliSeconds integer (オプション)

スクリプトのタイムアウト期間 (ミリ秒)。値は 0 から 10,000 の範囲である必要があります。デフォルト値は 1,000 です。

NGINX ログ解析

log_format の定義に基づいて、ログコンテンツをキーと値のペアに構造化します。デフォルトのフォーマットが要件を満たさない場合は、カスタムフォーマットを使用できます。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。NGINX ログ解析の場合、これを processor_parse_regex_native に設定します。

# ...spec.config の下...
processors:
  # NGINX ログ解析プラグインの構成
  - Type: processor_parse_regex_native
    # 生ログフィールドのソース
    SourceKey: content
    
    # 正規表現解析ルール
    Regex: >-
      (\S*)\s*-\s*(\S*)\s*\[
      (\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]
      \s*"(\S+)\s+(\S+)\s+\S+"
      \s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)
      \s*"([^"]*)"\s*"([^"]*)".*
    
    # 抽出されたフィールドのマッピング
    Keys:
      - remote_addr
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_time
      - request_length
      - status
      - body_bytes_sent
      - http_referer
      - http_user_agent
    
    # NGINX 固有の構成
    Extra:
      Format: >-
        log_format main  '$remote_addr - $remote_user [$time_local]
        "$request" ''$request_time $request_length ''$status
        $body_bytes_sent "$http_referer" ''"$http_user_agent"';
      LogType: NGINX

SourceKey String (必須)

ソースフィールドの名前。

Regex integer (必須)

正規表現。

Keys String (必須)

抽出されたフィールドのリスト。

Extra

  • Format String (必須)

    NGINX 構成ファイルのログ構成セクション。このセクションは [log_format] で始まる必要があります。

    本番環境では、ここでの log_format 定義は、NGINX 構成ファイル (通常は /etc/nginx/nginx.conf) の定義と一致する必要があります。
  • LogType String (必須)

    解析するログのタイプ。これを NGINX に設定します。

KeepingSourceWhenParseFail boolean (オプション)

解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

KeepingSourceWhenParseSucceed boolean (オプション)

解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

RenamedSourceKey String _(オプション)

ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。

Apache ログ解析

Apache ログ構成ファイルの定義に基づいて、ログコンテンツをキーと値のペアに構造化します。

キーフィールドの詳細

Type String (必須)

プラグインのタイプ。これを processor_parse_regex_native に設定します。

# ...spec.config の下...
processors:
  # Apache Combined ログ解析プラグイン (正規表現に基づく) を構成します。
  - Type: processor_parse_regex_native
    # 生ログフィールドのソース、通常は content。
    SourceKey: content

    # Apache combined 形式のログを照合および抽出するために使用される正規表現。
    Regex: >-
      ([0-9.-]+)\s                          # remote_addr
      ([\w.-]+)\s                           # remote_ident
      ([\w.-]+)\s                           # remote_user
      (\[[^\[\]]+\]|-)\s                    # time_local
      "((?:[^"]|\")+)"\s                     # request_method + request_uri + request_protocol
      "((?:[^"]|\")+)"\s                     # request_uri (繰り返しキャプチャ? ロジックを確認してください)
      "((?:[^"]|\")+)"\s                     # request_protocol
      (\d{3}|-)\s                           # status
      (\d+|-)\s                             # response_size_bytes
      "((?:[^"]|\")+)"\s                     # http_referer
      "((?:[^"]|\"|')+)"                     # http_user_agent

    # 抽出されたフィールドのリスト。正規表現グループに順番に対応します。
    Keys:
      - remote_addr
      - remote_ident
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_protocol
      - status
      - response_size_bytes
      - http_referer
      - http_user_agent

    # 追加のプラグイン情報 (オプション、ログ形式を記述するために使用)
    Extra:
      Format: >-
        LogFormat "%h %l %u %t \"%r\" %>s %b
        \"%{Referer}i\" \"%{User-Agent}i\"" combined
      LogType: Apache
      SubType: combined

SourceKey String (必須)

ソースフィールドの名前。

Regex integer (必須)

正規表現。

Keys String (必須)

抽出されたフィールドのリスト。

Extra

  • Format String (必須)

    Apache 構成ファイルのログ構成セクション。このセクションは通常、LogFormat で始まります。

  • LogType String (必須)

    解析するログのタイプ。これを Apache に設定します。

  • SubType String (必須)

    ログ形式。

    • common

    • combined

    • custom

KeepingSourceWhenParseFail boolean (オプション)

解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

KeepingSourceWhenParseSucceed boolean _(オプション)

解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は false です。

RenamedSourceKey String (オプション)

ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。

データマスキング

processor_desensitize_native プラグインを使用して、ログ内の機密データをマスキングします。

キーフィールド

Type String (必須)

プラグインのタイプ。値を processor_desensitize_native に設定します。

# ...spec.config の下...
processors:
  # ネイティブログマスキングプラグインを構成します。
  - Type: processor_desensitize_native

    # ソースフィールド名。
    SourceKey: content

    # マスキング方法。const は機密データを定数文字列に置き換えます。
    Method: const

    # 置換に使用される定数文字列。
    ReplacingString: '********'

    # 機密データの前にあるコンテンツの正規表現。
    ContentPatternBeforeReplacedString: 'password'':'''

    # 置換される機密データの正規表現。
    ReplacedContentPattern: '[^'']*'

    # すべての一致を置換するかどうかを指定します。デフォルト: true。
    ReplacingAll: true

SourceKey String (必須)

ソースフィールド名。

Method String (必須)

マスキング方法。有効な値:

  • const: 機密コンテンツを定数文字列に置き換えます。

  • md5: 機密コンテンツをその MD5 ハッシュに置き換えます。

ReplacingString String (オプション)

機密コンテンツを置き換えるために使用される定数文字列。このパラメーターは、Methodconst に設定されている場合に必須です。

ContentPatternBeforeReplacedString String (必須)

機密コンテンツのプレフィックスの正規表現。

ReplacedContentPattern String (必須)

機密コンテンツの正規表現。

ReplacingAll boolean (オプション)

解析が成功した後に元のフィールドを保持するかどうかを指定します。デフォルトは true です。

コンテンツフィルタリング

processor_filter_regex_native プラグインを構成して、正規表現に基づいてログフィールドの値を照合し、条件を満たすログのみを保持します。

キーフィールド

Type String (必須)

プラグインのタイプ。値は processor_filter_regex_native です。

# ...spec.config の下...
processors:
  # 正規表現フィルタリングプラグインを構成します (ログマスキングや禁止用語フィルタリングに使用できます)。
  - Type: processor_filter_regex_native

    # ログフィールドのコンテンツに一致する正規表現のリストを定義します。
    FilterRegex:
      # 例: ログフィールドの値に "WARNING" または "ERROR" が含まれるコンテンツに一致させます。
      - WARNING|ERROR

    # 一致させるログフィールド名を指定します。この例では level フィールドをフィルタリングします。
    FilterKey:
      - level

FilterRegex String (必須)

ログフィールドに一致する正規表現。

FilterKey String (必須)

一致させるログフィールドの名前。

時間解析

`processor_parse_timestamp_native` プラグインを構成して、ログ内の時間フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。

キーフィールド

Type String (必須)

プラグインのタイプ。processor_parse_timestamp_native に設定します。

# ...spec.config の下...
processors:
  # ネイティブ時間解析プラグインを構成します。
  - Type: processor_parse_timestamp_native
    # 生ログフィールドのソース、通常は content
    SourceKey: content

    # 時間形式の定義。ログ内の時間フィールドの形式と完全に一致する必要があります。
    SourceFormat: '%Y-%m-%d %H:%M:%S'
    
    SourceTimezone: 'GMT+00:00'

SourceKey String (必須)

ソースフィールド名。

SourceFormat String (必須)

時間形式」をご参照ください。この形式は、ログ内の時間フィールドの形式と完全に一致する必要があります。

SourceTimezone String (オプション)

ログ時間のタイムゾーン。デフォルトでは、マシンのタイムゾーンが使用されます。これは、LoongCollector プロセスが配置されている環境のタイムゾーンです。

フォーマット:

  • GMT+HH:MM: 東部タイムゾーン

  • GMT-HH:MM: 西部タイムゾーン

その他の詳細設定

最小構成を完了した後、次の操作を実行して、複数行ログの収集、ログトピックタイプの構成、およびより詳細なログ収集の構成を行うことができます。以下は、一般的な詳細設定とその機能です。

  • 複数行ログ収集の構成: 例外スタックトレースなど、単一のログエントリが複数行にまたがる場合、複数行モードを有効にし、行の開始を示す正規表現を構成してログの開始に一致させる必要があります。これにより、複数行のエントリが単一のログとして収集され、SLS Logstore に保存されることが保証されます。

  • ログトピックタイプの構成: 異なるログストリームに異なるトピックを設定して、ログデータを整理および分類します。これにより、関連するログをより適切に管理および取得できます。

  • 収集対象コンテナーの指定 (フィルタリングとブラックリスト): ホワイトリストとブラックリストの構成を含め、収集対象の特定のコンテナーとパスを指定します。

  • ログタグのエンリッチ: 環境変数と Pod ラベルに関連するメタデータを拡張フィールドとしてログに追加します。

複数行ログ収集の構成

デフォルトでは、Simple Log Service は単一行モードを使用し、ログを行ごとに分割して保存します。これにより、スタックトレース情報を含む複数行のログが分割され、各行が独立したログとして保存および表示されるため、分析には不向きです。

この問題に対処するために、複数行モードを有効にして、Simple Log Service がログを分割する方法を変更できます。ログエントリの開始に一致する正規表現を構成することで、生ログが行の開始ルールに従って分割および保存されることを保証できます。

コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="f3ede8f0e8rnz">spec.config.inputs</a> 構成に、Multiline パラメーターを追加します。

キーフィールド

Multiline

複数行ログ収集を有効にします。

  • Mode

    モードの選択。デフォルト値: custom

    • custom: 行の開始に一致するカスタム正規表現を示します。

    • JSON: 複数行 JSON。

  • StartPattern

    行の開始の正規表現。Mode が custom に設定されている場合に必須です。

# ...spec.config の下...
inputs:
  - Type: input_file
    # 複数行ログ収集を有効にします。
    Multiline:
      # モード選択: custom は行の開始に一致するカスタム正規表現を示します。
      Mode: custom
      # 正規表現は各ログエントリの開始 (新しいログのマーカー) に一致します。
      StartPattern: '\d+-\d+-\d+\s\d+:\d+:\d+'

ログトピックタイプの構成

コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="bd8af01817orq">spec.config</a> に、global パラメーターを追加してトピックを設定します。

キーフィールド

TopicType

トピックタイプ。オプションの値:

  • machine_group_topic: マシングループトピック。異なるマシングループからのログを区別するために使用されます。

  • filepath: ファイルパス抽出。異なるユーザーまたはアプリケーションによって生成されたログデータを区別するために使用されます。

  • custom: カスタム。カスタムの静的ログトピックを使用します。

マシングループトピック

spec: 
  config:
    global: 
    #この構成が適用されるマシングループトピックをトピックとして使用します。
      TopicType: machine_group_topic              

ファイルパス抽出

spec:  
  config:
    global: 
      TopicType: filepath
    # トピック形式。TopicType が filepath または custom に設定されている場合に必須です。
    # 抽出結果は __topic__: userA、__topic__: userB、および __topic__: userC です。
      TopicFormat: \/data\/logs\/(.*)\/serviceA\/.*

カスタム

spec:  
  config:
    global: 
      TopicType: custom
    # トピック形式。TopicType が filepath または custom に設定されている場合に必須です。
      TopicFormat: customized:// + カスタムトピック名

TopicFormat

トピック形式。これは、TopicType が filepath または custom に設定されている場合に必須です。

収集対象コンテナーの指定 (フィルタリングとブラックリスト)

フィルタリング

指定された条件を満たすコンテナーからのみログを収集します。複数の条件は論理 AND で結合されます。空の条件は無視されます。条件は正規表現をサポートします。

コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="aa519613f0gdu">spec.config.inputs</a> で、コンテナーフィルタリングのための ContainerFilters パラメーターを構成します。

キーフィールドの詳細

ContainerFilters

コンテナーフィルタリング

  • Pod ラベルのブラックリストとホワイトリスト

    • IncludeK8sLabel

      K8s Pod ラベルのホワイトリスト。ログを収集するコンテナーを指定します。

    • ExcludeK8sLabel

      K8s Pod ラベルのブラックリスト。特定の条件を満たすコンテナーからのログ収集を除外します。

  • 環境変数のブラックリストとホワイトリスト

    • IncludeEnv

      環境変数ホワイトリスト

    • ExcludeInv

      環境変数ブラックリスト

  • Pod、名前空間、およびコンテナー名の正規表現によるマッチング

    • K8sNamespaceRegex

      名前空間の正規表現マッチング

    • K8sPodRegex

      Pod 名の正規表現マッチング

    • K8sContainerRegex

      コンテナー名の正規表現マッチング

すべての正規表現マッチングは、Go の RE2 エンジンを使用します。このエンジンは、PCRE などのエンジンよりも機能が少ないです。「付録: 正規表現の制限 (コンテナーフィルタリング)」で説明されている制限に従って正規表現を記述してください。
# ...spec.config の下...
inputs:
  - Type: input_file # または input_container_stdio
    # 入力プラグインのタイプが input_file の場合、EnableContainerDiscovery を true に設定します。
    EnableContainerDiscovery: true
    # コンテナーフィルタリング
    ContainerFilters:
      # K8s Pod ラベルのホワイトリスト: ログを収集するコンテナーを指定します。
      IncludeK8sLabel:
        # 例: app ラベルの値が nginx または redis であるすべての Pod に一致させます。
        app: ^(nginx|redis)$

      # K8s Pod ラベルのブラックリスト: 特定の条件を満たすコンテナーからのログ収集を除外します。
      ExcludeK8sLabel:
        # 例: app:test ラベルを持つすべての Pod を除外します。
        app: test
      
      # 環境変数ホワイトリスト
      IncludeEnv:
        # NGINX_SERVICE_PORT=80 または NGINX_SERVICE_PORT=6379 を持つすべてのコンテナーに一致させます。
        NGINX_SERVICE_PORT: ^(80|6379)$

      # 環境変数ブラックリスト
      ExcludeEnv:
        # ENVIRONMENT=test を持つすべてのコンテナーを除外します。
        ENVIRONMENT: test
      
      # 名前空間の正規表現マッチング。例: default および nginx 名前空間内のすべてのコンテナーに一致させます。
      K8sNamespaceRegex: ^(default|nginx)$
      # Pod 名の正規表現マッチング。例: 名前が nginx-log-demo で始まるすべての Pod 内のコンテナーに一致させます。
      K8sPodRegex: ^(nginx-log-demo.*)$
      # コンテナー名の正規表現マッチング。例: container-test という名前のすべてのコンテナーに一致させます。
      K8sContainerRegex: ^(container-test)$

ブラックリスト

指定された条件を満たすファイルを除外するには、必要に応じて YAML ファイルの config.inputs の下にある次のパラメーターを使用します。

キーフィールドの詳細

# ...spec.config の下...
inputs:
  - Type: input_file
    # ファイルパスのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があり、アスタリスク (*) ワイルドカード文字をサポートします。
    ExcludeFilePaths:
      - /var/log/*.log

    # ファイル名のブラックリスト。指定された条件を満たすファイルを除外します。アスタリスク (*) ワイルドカード文字をサポートします。
    ExcludeFiles:
      - test

    # ディレクトリのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があり、アスタリスク (*) ワイルドカード文字をサポートします。
    ExcludeDirs:
      - /var/log/backup*               

ExcludeFilePaths

ファイルパスのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があります。アスタリスク (*) ワイルドカード文字がサポートされています。

ExcludeFiles

ファイル名のブラックリスト。指定された条件を満たすファイルを除外します。アスタリスク (*) ワイルドカード文字がサポートされています。

ExcludeDirs

ディレクトリのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があります。アスタリスク (*) ワイルドカード文字がサポートされています。

ログタグのエンリッチ

コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="c7eb12a5deg0j">spec.config.inputs</a>ExternalEnvTagExternalK8sLabelTag を構成することで、コンテナーの環境変数と Pod ラベルに関連するタグをログに追加できます。

キーフィールド

ExternalEnvTag

指定された環境変数の値をタグフィールドにマッピングします。フォーマット: <environment_variable_name>: <tag_name>

# ...spec.config の下...
inputs:
  - Type: input_file # または input_container_stdio
    ExternalEnvTag:
      <environment_variable_name>: <tag_name>
    
    ExternalK8sLabelTag:
      <pod_label_name>: <tag_name>          

ExternalK8sLabelTag

Kubernetes Pod ラベルの値をタグフィールドにマッピングします。フォーマット: <pod_label_name>: <tag_name>

構成例

シナリオ 1: NGINX アクセスログを収集し、構造化フィールドに解析する

NGINX ログを解析し、log_format の定義に基づいてログコンテンツを複数のキーと値のペアに構造化します。

完全な YAML の例

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: nginx-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        EnableContainerDiscovery: true
    processors:
      - Type: processor_parse_regex_native
        SourceKey: content
        Regex: >-
          (\S*)\s*-\s*(\S*)\s*\[(\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]\s*"(\S+)\s+(\S+)\s+\S+"\s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)\s*"([^"]*)"\s*"([^"]*)".*
        Keys:
          - remote_addr
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_time
          - request_length
          - status
          - body_bytes_sent
          - http_referer
          - http_user_agent
        Extra:
          Format: >-
            log_format main  '$remote_addr - $remote_user [$time_local]
            "$request" ''$request_time $request_length ''$status
            $body_bytes_sent "$http_referer" ''"$http_user_agent"';
          LogType: NGINX
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: >-
      192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png
      HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
      AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore
    

シナリオ 2: 複数行ログの収集と処理

デフォルトでは、Simple Log Service は単一行モードを使用し、ログを行ごとに分割して保存します。これにより、スタックトレース情報を含む複数行のログが分割され、各行が独立したログとして保存および表示されるため、分析には不向きです。

この問題に対処するために、複数行モードを有効にして、Simple Log Service がログを分割する方法を変更できます。ログエントリの開始に一致する正規表現を構成することで、生ログが行の開始ルールに従って分割および保存されることを保証できます。以下に例を示します。

完全な YAML の例

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: multiline-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        Multiline:
          StartPattern: '\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*'
          Mode: custom
          UnmatchedContentTreatment: single_line
        EnableContainerDiscovery: true
    processors: []
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: |-
      [2023-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happened
          at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
          at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
          at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore

よくある質問

ACK クラスターから別の Alibaba Cloud アカウントのプロジェクトにログを送信するにはどうすればよいですか?

ACK クラスターに Simple Log Service LoongCollector (Logtail) コンポーネントを手動でインストールし、宛先アカウントの Alibaba Cloud アカウント ID またはアクセス資格情報 (AccessKey) で構成します。これにより、コンテナーログを別の Alibaba Cloud アカウントの Simple Log Service プロジェクトに送信できます。

シナリオ: 組織構造、権限の分離、または統一された監視などの理由で、ACK クラスターから別の Alibaba Cloud アカウントの Simple Log Service プロジェクトにログデータを収集する必要があります。これを行うには、クロスアカウント構成のために LoongCollector (Logtail) を手動でインストールします。

手順: このセクションでは、LoongCollector の手動インストールを例として使用します。Logtail のインストール方法については、「Logtail のインストールと構成」をご参照ください。

  1. Kubernetes クラスターに接続し、お使いのリージョンに対応するコマンドを実行して、LoongCollector とその依存コンポーネントをダウンロードします。

    中国国内のリージョン:

    wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

    中国国外のリージョン:

    wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh
  2. loongcollector-custom-k8s-package ディレクトリに移動し、./loongcollector/values.yaml 構成ファイルを変更します。

    # ===================== 必須パラメーター =====================
    # 収集されたログを管理するプロジェクトの名前。例: k8s-log-custom-sd89ehdq。
    projectName: ""
    # プロジェクトが配置されているリージョン。上海の例: cn-shanghai
    region: ""
    # プロジェクトを所有する Alibaba Cloud アカウントの ID。ID を引用符で囲みます。例: "123456789"
    aliUid: ""
    # ネットワークタイプ。有効な値: Internet および Intranet。デフォルト値: Internet。
    net: Internet
    # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID と AccessKey Secret。アカウントまたはユーザーは AliyunLogFullAccess システムポリシーを持っている必要があります。
    accessKeyID: ""
    accessKeySecret: ""
    # カスタムクラスター ID。ID には、大文字、小文字、数字、ハイフン (-) のみを含めることができます。
    clusterID: ""
  3. loongcollector-custom-k8s-package ディレクトリで、次のコマンドを実行して LoongCollector とその他の依存コンポーネントをインストールします。

    bash k8s-custom-install.sh install
  4. インストールが完了したら、コンポーネントの実行状態を確認します。

    Pod の起動に失敗した場合は、values.yaml の構成が正しいか、関連するイメージが正常にプルされたかを確認してください。
    # Pod の状態を確認します。
    kubectl get po -n kube-system | grep loongcollector-ds

    SLS はまた、以下のリソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます

    リソースタイプ

    リソース名

    機能

    プロジェクト

    values.yaml ファイルで指定した projectName の値

    異なるサービスのログを分離するためのリソース管理ユニット。

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードのコレクション。

    Logstore

    config-operation-log

    重要

    この Logstore は削除しないでください。

    loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目」をご参照ください。この Logstore に収集構成を作成しないでください。

単一のログファイルまたはコンテナーの標準出力から複数の収集構成でログを収集するにはどうすればよいですか?

デフォルトでは、データの重複を防ぐため、Simple Log Service は各ログソースを単一の収集構成に制限しています。

  • テキストログファイルは、1 つの Logtail 収集構成にのみ一致できます。

  • コンテナーの標準出力 (stdout) は、1 つの標準出力収集構成によってのみ収集できます。

  1. Simple Log Service コンソールにログインし、ターゲットプロジェクトに移動します。

  2. ナビゲーションウィンドウで、image[Logstores] を選択し、ターゲット Logstore を見つけます。

  3. その名前の横にある image アイコンをクリックして、Logstore を展開します。

  4. [Logtail 構成] をクリックします。構成リストで、ターゲットの Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。

  5. Logtail 構成ページで、[編集] をクリックし、[入力構成] セクションまでスクロールします。

    • テキストファイルからログを収集する場合: [ファイルを複数回収集することを許可] を有効にします。

    • コンテナーの標準出力を収集する場合: [標準出力を複数回収集することを許可] を有効にします。

付録: 正規表現の使用制限 (コンテナーフィルタリング)

コンテナーフィルタリングに使用される正規表現は、Go の RE2 エンジンに基づいており、PCRE などの他のエンジンと比較して構文に制限があります。正規表現を記述する際には、以下の点に注意してください。

1. 名前付きグループ構文の違い

Go は (?P<name>...) 構文を使用して名前付きグループを定義します。PCRE の (?<name>...) 構文はサポートしていません。

  • 正しい例: (?P<year>\d{4})

  • 誤った例: (?<year>\d{4})

2. サポートされていない正規表現機能

以下の一般的で複雑な正規表現機能は RE2 では利用できません。これらは使用しないでください。

  • アサーション: (?=...), (?!...), (?<=...), および (?<!...)

  • 条件式: (?(condition)true|false)

  • 再帰的マッチング: (?R) および (?0)

  • サブルーチン参照: (?&name) および (?P>name)

  • アトミックグループ: (?>...)

3. 推奨事項

Regex101 などのツールで正規表現をデバッグする際は、互換性を確保するために Golang (RE2) モードを選択して検証してください。サポートされていない構文を使用すると、プラグインは式を正しく解析または照合できません。