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

Simple Log Service:Kubernetes CRD を使用したクラスターからのコンテナログ(標準出力およびファイル)の収集

最終更新日:Mar 27, 2026

Kubernetes のカスタムリソース定義 (CRD) としてログ収集設定を定義することで、Container Service for Kubernetes (ACK) クラスターおよびセルフマネージドクラスターを含むすべてのクラスターにおける管理を統一できます。このアプローチにより、一貫性に欠け誤りが生じやすい手動プロセスを、kubectl および CI/CD パイプラインによるバージョン管理された自動化に置き換えます。LoongCollector に組み込まれたホットリロード機能により、再起動なしで変更を即座に適用でき、運用効率およびシステムの保守性を直接向上させます。

旧式の AliyunLogConfig CRD は今後メンテナンスされません。代わりに新しい AliyunPipelineConfig CRD をご使用ください。新旧バージョンの比較については、「CRD の種類」をご参照ください。
重要

CRD を使用して作成した収集設定は、対応する CRD を更新することでのみ変更可能です。Simple Log Service (SLS) コンソールで行った変更は CRD と同期されず、反映されません。

注意事項

  • 実行環境:

    • ACK(マネージドおよび専用エディション)およびセルフマネージド Kubernetes クラスターをサポートします。

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

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

      • Docker:

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

        • 標準出力の収集には JSON ログドライバーのみがサポートされます。

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

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

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

    • 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:収集設定ジェネレーターの使用

      SLS コンソールの収集設定ジェネレーターを使用して、パラメーターをビジュアルに指定し、標準的な YAML ファイルを自動生成します。

    • 方法 2:YAML ファイルの手動作成

      本トピックのサンプルおよびワークフローに基づいて YAML ファイルを作成します。最小構成から始め、順次処理ロジックおよび高度な機能を追加していきます。

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

    完全な収集設定には、通常以下のような要素が含まれます:

    • 最小構成(必須):クラスターから SLS へのデータトンネルを構築します。以下の 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 は、SLS が提供する次世代ログ収集エージェントであり、Logtail のアップグレード版です。両者は共存できません。Logtail のインストールについては、「Logtail のインストールおよび構成」をご参照ください。

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

ACK クラスター

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

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

  2. クラスターページで、対象のクラスター名をクリックし、その詳細ページを開きます。

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

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

    説明

    新規クラスターの場合、詳細オプションセクションで、Log Service の有効化を選択します。その後、プロジェクトの作成またはプロジェクトの選択を行います。

    インストールが完了すると、SLS は ACK クラスターが存在するリージョンに自動的に関連リソースを作成します。Simple Log Service コンソールにログインして確認してください

    リソースタイプ

    リソース名

    機能

    プロジェクト

    k8s-log-${cluster_id}

    異なるサービスのログを分離するためのリソース管理単位です。

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

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードの集合です。

    重要

    LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその 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 アカウントの UID。引用符で囲んでください。例: "123456789"
    aliUid: ""
    # ネットワークタイプ。オプション:Internet(パブリックネットワーク)および Intranet(内部ネットワーク)。デフォルト値:Internet。
    net: Internet
    # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID および AccessKey Secret。アカウントまたはユーザーには AliyunLogFullAccess システムポリシーが必要です。
    accessKeyID: ""
    accessKeySecret: ""
    # カスタムクラスター ID。大文字、小文字、数字、ハイフン (-) のみ使用可能です。
  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}

    ログ収集ノードの集合です。

    重要

    LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。

Logstore の作成

すでに Logstore を作成済みの場合は、この手順をスキップし、収集設定の構成に進んでください。

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

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

  3. Logstore の作成ページで、以下の主要なパラメーターを設定します:

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

    • Logstore タイプ:仕様を比較して「標準」または「クエリ」を選択します。

    • 課金モード

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

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

    • データ保持期間:ログを保持する日数を設定します。1~3650 日の範囲で指定できます。3650 を指定すると永続保存となります。デフォルトは 30 日です。

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

最小構成

spec.config 内で、入力 (inputs) および出力 (flushers) プラグインを構成し、ログ収集の基本的なパス(ログのソースおよび送信先)を定義します。

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

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

inputs プラグイン

収集設定の起点です。ログのソースを定義します。現在は 1 つの入力プラグインのみを設定できます。

  • タイプ 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: # 複数の送信先に送信する必要がない場合は、1 つのフラッシャーのみを設定します。
    - Type: flusher_sls    # SLS 出力プラグインを使用することを指定します。
    Logstore: new-stdio-logstore1
    - Type: flusher_sls    # SLS 出力プラグインを使用することを指定します。
    Logstore: new-stdio-logstore2
 

flushers 出力プラグイン

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

  • タイプ String (必須)

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

  • Logstore String (必須)

    対象 Logstore の名前です。これにより、ログの実際の保存場所が決定されます。

    説明
    • 指定された Logstore は、存在するか、spec.LogStores で宣言されている必要があります。

コンテナテキストファイルの収集

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

inputs プラグイン

収集設定の起点です。ログのソースを定義します。現在は 1 つの入力プラグインのみを設定できます。

  • タイプ String (必須)

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

  • FilePaths String (必須)

    収集対象のログファイルのパスのリストです。

    • 現在は 1 つのパスのみを設定できます。

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

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

      • **:マルチレベルのサブディレクトリを再帰的に一致させます。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: # 複数の送信先に送信する必要がない場合は、1 つのフラッシャーのみを設定します。
    - Type: flusher_sls        # SLS 出力プラグインを使用することを指定します。
    Logstore: easy-row-logstore1
    - Type: flusher_sls        # SLS 出力プラグインを使用することを指定します。
    Logstore: easy-row-logstore2

flushers 出力プラグイン

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

  • タイプ String (必須)

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

  • Logstore String (必須)

    対象 Logstore の名前です。これにより、ログの実際の保存場所が決定されます。

    説明
    • 指定された Logstore は、存在するか、spec.LogStores で宣言されている必要があります。

一般的な処理設定

最小構成の完了後、生ログに対して構造化解析、マスキング、フィルタリングなどの処理を行うために、処理プラグインを追加します。

基本構成spec.config 内に processors を追加し、処理プラグインを構成します。複数のプラグインを同時に追加できます。

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

Logtail 2.0 以降および LoongCollector コンポーネントでは、以下のプラグイン組み合わせルールに従うことを推奨します:

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

  • ネイティブプラグインで要件を満たせない場合、ネイティブプラグインの後に拡張プラグインを構成します。

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

構造化された構成

正規表現解析

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

主なフィールド

タイプ 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 (任意)

ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。

デリミタ解析

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

主なフィールド

タイプ 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 です。許容しない場合、この状況は解析失敗として扱われます。

OverflowedFieldsTreatment String (任意)

抽出されたフィールド数がキー数より多い場合の動作を指定します。デフォルト値は extend です。サポートされる値は以下のとおりです:

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

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

  • discard:余分なフィールドを破棄します。

KeepingSourceWhenParseFail boolean (任意)

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

KeepingSourceWhenParseSucceed boolean (任意)

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

RenamedSourceKey String (任意)

ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。

標準 JSON 解析

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

主なフィールド

タイプ 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 ログをキーと値のペアに解析します。

主なフィールド

タイプ 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 関数の詳細については、「JSON 関数」をご参照ください。

主なフィールド

タイプ String (必須)

プラグインのタイプです。SPL プラグインのタイプは processor_spl です。

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

    # SPL スクリプトのコンテンツで、content フィールド内の JSON 配列から要素を抽出します。
    Script: >-
      * | extend
        json1 = json_extract(content, '$[0]'),
        json2 = json_extract(content, '$[1]')

Script String (必須)

SPL スクリプトのコンテンツで、content フィールド内の JSON 配列から要素を抽出します。

TimeoutMilliSeconds integer (任意)

スクリプトのタイムアウト期間です。値の範囲は 0~10000 です。単位はミリ秒で、デフォルト値は 1000 です。

NGINX ログ解析

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

主なフィールド

タイプ 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 は、通常 /etc/nginx/nginx.conf ファイルにある Nginx 構成ファイルの定義と一致している必要があります。
  • LogType String (必須)

    解析対象のログのタイプです。NGINX を設定します。

KeepingSourceWhenParseFail boolean (任意)

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

KeepingSourceWhenParseSucceed boolean (任意)

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

RenamedSourceKey String (任意)

ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。

Apache ログ解析

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

主なフィールド

タイプ 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 (repeated capture? check logic)
      "((?:[^"]|\"|')+)"                     # 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 プラグインを使用して、ログ内の機密データをマスクします。

主なフィールド

タイプ 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 プラグインを構成し、正規表現に基づいてログフィールド値をマッチさせ、条件を満たすログのみを保持します。

主なフィールド

タイプ 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__ フィールドとして設定します。

主なフィールド

タイプ 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:西部タイムゾーン

その他の高度な設定

より高度なユースケースでは、以下の設定を検討してください:

  • マルチラインログ収集の構成:例外スタックトレースなど、1 つのログエントリが複数行にわたる場合、マルチラインモードを有効化し、ログの開始をマッチさせる正規表現を構成する必要があります。これにより、マルチラインエントリが SLS Logstore 内で 1 つのログとして収集および保存されます。

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

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

  • ログタグの充実化:環境変数および Pod ラベルに関連するメタデータを、拡張フィールドとしてログに追加します。

マルチラインログ収集の構成

Java スタックトレースなど、複数行にわたるログエントリを正しく解析するには、マルチラインモードを有効化する必要があります。これにより、定義された開始パターンに基づいて関連する行が 1 つのログエントリとしてグループ化されます。

基本構成spec.config.inputs 構成内に Multiline パラメーターを追加します。

主なフィールド

Multiline

マルチラインログ収集を有効化します。

  • Mode

    モードの選択です。デフォルト値は custom です。

    • custom:行の開始をマッチさせるカスタム正規表現を示します。

    • JSON:マルチライン JSON です。

  • StartPattern

    行の開始をマッチさせる正規表現です。custom に設定されている場合に必須です。

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

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

基本構成spec.config 内で 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)で結合されます。空の条件は無視されます。条件には正規表現が使用できます。

基本構成spec.config.inputs 内で、コンテナフィルタリングのための ContainerFilters パラメーターを構成します。

主なフィールド

ContainerFilters

コンテナフィルタリング

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

    • IncludeK8sLabel

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

    • ExcludeK8sLabel

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

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

    • IncludeEnv

      環境変数ホワイトリスト

    • ExcludeInv

      環境変数ブラックリスト

  • Pod/Namespace/コンテナ名の正規表現マッチング

    • 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

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

ログタグの充実化

基本構成spec.config.inputs 内で ExternalEnvTag および ExternalK8sLabelTag を構成することで、コンテナ環境変数および 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>

構成例

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
    

マルチラインログの収集と処理

マルチラインモードを有効にすることで、定義された開始パターンに基づいて関連する行が 1 つのログエントリにグループ化されます。以下に例を示します。

完全な 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 クラスターに LoongCollector (Logtail) を手動でインストールし、対象の Alibaba Cloud アカウント ID または AccessKey を設定します。これにより、コンテナログを別の Alibaba Cloud アカウントの SLS プロジェクトに送信できます。

ユースケース:組織構造、権限の分離、または一元的なモニタリングなどの理由により、ACK クラスターから別の Alibaba Cloud アカウントの SLS プロジェクトにログデータを収集します。クロスアカウント構成のために 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 アカウントの UID。引用符で囲んでください。例: "123456789"
    aliUid: ""
    # ネットワークタイプ。オプション:Internet(パブリックネットワーク)および Intranet(内部ネットワーク)。デフォルト値:Internet。
    net: Internet
    # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID および AccessKey Secret。アカウントまたはユーザーには AliyunLogFullAccess システムポリシーが必要です。
    accessKeyID: ""
    accessKeySecret: ""
    # カスタムクラスター 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}

    ログ収集ノードの集合です。

    重要

    LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。

同じログファイルまたはコンテナ標準出力を複数の収集設定で同時に収集するにはどうすればよいですか?

デフォルトでは、データ重複を防ぐため、各ログソースは 1 回のみ収集されます。複数の設定で同じソースから収集を許可するには、Logtail 構成設定で対応するオプションを有効にしてください。

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

  2. ナビゲーションウィンドウで、imageLogstore を選択し、対象の Logstore を見つけます。

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

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

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

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

    • コンテナ標準出力を収集する場合:異なる Logtail 構成による収集を許可を有効にします。

付録:コンテナフィルタリングにおける正規表現の制限

コンテナフィルタリングに使用する正規表現は、Go 言語の RE2 エンジンに基づいています。このエンジンは、PCRE などの他の正規表現エンジンと比較して、構文上の制限がいくつか存在します。正規表現を作成する際は、以下の制限事項にご注意ください。

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

Go 言語では、名前付きグループに (?P<name>...) 構文を使用します。(?<name>...) のような PCRE で使用される構文はサポートされていません。

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

  • 不適切な構文:(?<year>\d{4})

2. サポートされていない正規表現の特徴

以下に示す一般的かつ複雑な正規表現の特徴は、RE2 では利用できません。

  • アサーション: (?=...)(?!...)(?<=...)(?<!...)

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

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

  • サブプログラム参照: (?&name)(?P>name)

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

3. 推奨事項

Regex101 などのツールで正規表現のデバッグを行う場合、互換性を確保するために「Golang (RE2)」モードを選択してください。サポートされていない構文を使用すると、プラグインが式を正しく解析またはマッチできない可能性があります。