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

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

最終更新日:Jan 15, 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 クラスターをサポートします。

    • 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 を使用してクラスターに接続します。次の 2 つの方法のいずれかで収集設定ファイルを作成します。

    • 方法 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}

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

    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 アカウントの UID。UID は引用符で囲んでください。例:"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 の管理」をご参照ください。

最小構成

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

flushers 出力プラグイン

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

  • Type String (必須)

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

  • Logstore String (必須)

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

    説明

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

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

目的:コンテナ内の特定のファイルパスに書き込まれるログ (従来の 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: # 複数の宛先に送信する必要がない場合は、1 つのフラッシャーのみを設定します。
    - Type: flusher_sls        # SLS 出力プラグインの使用を指定します。
    Logstore: easy-row-logstore1
    - Type: flusher_sls        # SLS 出力プラグインの使用を指定します。
    Logstore: easy-row-logstore2

flushers 出力プラグイン

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

  • Type String (必須)

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

  • Logstore String (必須)

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

    説明

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

一般的な処理設定

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

コア構成spec.configprocessors を追加して、処理プラグインを設定します。複数のプラグインを同時に追加できます。

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

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。許可しない場合、このシナリオは解析失敗として扱われます。

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

キーフィールド

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

キーフィールド

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 (必須)

ソースフィールド名です。

正規表現 整数 (必須)

正規表現。

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 (必須)

ソースフィールド名です。

正規表現 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 ラベルに関連するメタデータを拡張フィールドとしてログに追加します。

複数行ログ収集の設定

複数行にまたがるログエントリ (Java のスタックトレースなど) を正しく解析するには、複数行モードを有効にします。これにより、定義された開始パターンに基づいて、関連する行が単一のログエントリにグループ化されます。

コア構成spec.config.inputs 設定に 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+'

ログトピックタイプの設定

コア構成spec.configglobal パラメーターを追加してトピックを設定します。

キーフィールド

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/名前空間/コンテナ名の正規表現マッチング

    • 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.inputsExternalEnvTagExternalK8sLabelTag を設定することにより、コンテナの環境変数と 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 アクセスログを収集して構造化フィールドに解析する

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

完全な 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
    

複数行ログの収集と処理

複数行モードを有効にして、定義された開始パターンに基づいて関連する行が単一のログエントリにグループ化されるようにします。以下に例を示します。

完全な 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。UID は引用符で囲んでください。例:"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 に収集設定を作成しないでください。

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

デフォルトでは、各ログソースはデータの重複を防ぐために一度しか収集されません。複数の設定で同じソースから収集できるようにするには、Logtail 構成設定で対応するオプションを有効にします。

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

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

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

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

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

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

    • コンテナの標準出力を収集する場合:[異なる 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) モードを選択してください。サポートされていない構文を使用すると、プラグインは式を正しく解析または照合できません。