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

Simple Log Service:Kubernetes CRD を使用したコンテナログの収集

最終更新日:Aug 29, 2026

ログ収集設定を Kubernetes CRD として定義することで、バージョン管理、環境固有のデプロイ、および kubectl または CI/CD パイプラインを使用した Container Service for Kubernetes (ACK) クラスターおよび自己管理型クラスター間での自動リリースが可能になります。LoongCollector は、再起動なしで設定変更をホットリロードします。

レガシーの AliyunLogConfig CRD は非推奨です。代わりに AliyunPipelineConfig を使用してください。比較については、CRD タイプをご参照ください。
重要

CRD ベースの収集設定は、CRD を更新することによってのみ変更できます。Simple Log Service (SLS) コンソールで行われた変更は同期されず、有効になりません。

適用範囲

  • 動作環境

    • ACK クラスター (マネージド版および専用版) および自己管理型 Kubernetes クラスター。

    • Kubernetes のバージョンは 1.16.0 以降であり、Mount propagation: HostToContainer をサポートしている必要があります。

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

      • Docker:

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

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

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

      Log Service コンソールの収集設定ジェネレーターを使用して、パラメーターを視覚的に設定し、標準の YAML ファイルを自動的に生成します。

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

      このドキュメントの例に基づいて YAML ファイルを手動で作成します。最小構成から始めて、処理ロジックを追加し、次に高度な機能を有効にするというように、段階的に構築します。

      このドキュメントでカバーされていない複雑なシナリオや、詳細なカスタマイズが必要なフィールドについては、フィールドの完全なリスト、値のルール、およびプラグイン機能の詳細について、AliyunPipelineConfig パラメーターリファレンスをご参照ください。

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

    • 最小構成 (必須):この構成は、クラスターから 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 は SLS の次世代ログ収集エージェントであり、Logtail のアップグレード版です。両者は共存できません。代わりに Logtail をインストールするには、Logtail のインストールと設定をご参照ください。

基本的な LoongCollector のインストールについては、以下の手順に従ってください。詳細なパラメーターについては、インストールと設定をご参照ください。LoongCollector または Logtail がすでにインストールされている場合は、logstore の作成に進んでください。

ACK クラスター

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

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

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

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

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

    説明

    クラスターを作成する際、コンポーネント設定 ページで、Log Service の使用 チェックボックスをオンにします。その後、プロジェクトの作成 または プロジェクトの選択 を選択できます。

    インストールが完了すると、SLS は ACK クラスターのリージョンに関連リソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。

    リソースタイプ

    リソース名

    説明

    プロジェクト

    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
    # AliyunLogFullAccess ポリシーを持つ Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID とシークレット。
    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 はまた、以下のリソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。

    リソースタイプ

    リソース名

    説明

    プロジェクト

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

    異なるサービスからのログを分離します。

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードのグループ。

    重要

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

Logstore の作成

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

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

  2. 左側のナビゲーションウィンドウで、imageログ管理 を選択し、[+] をクリックします。

  3. Logstore の作成ページで、次のコアパラメーターを設定します。

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

    • Logstore タイプ:仕様に基づいて標準ストレージまたはクエリを選択します。

    • 課金モード:

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

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

    • Data Retention Period:ログを保持する日数を設定します。値の範囲は 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> では、入力プラグインと出力プラグインを設定して、ログソースとログの送信先を定義します。

コンテナ標準出力

目的:コンソールに直接出力されるコンテナ標準出力ログ (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 つ以上の flusher を設定してログの送信先を定義します。この例では、2 つの Logstore にログを送信します。
      - Type: flusher_sls    # SLS 出力プラグインを指定します。
        Logstore: new-stdio-logstore1
      - Type: flusher_sls    # SLS 出力プラグインを指定します。
        Logstore: new-stdio-logstore2
        

flushers (出力プラグイン)

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

  • 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> に宣言されている必要があります。

    • 複数の出力ターゲットを設定すると、設定は Logstore の設定リストに表示されなくなります。複数ターゲットの設定を管理するには、複数ターゲットの設定を管理するにはどうすればよいですか?をご参照ください。

コンテナテキストファイル

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

inputs (入力プラグイン)

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

  • Type String (必須)

    input_file に設定します。

  • FilePaths String (必須)

    ログファイルへのパスのリスト。

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

    • 次のワイルドカード文字を使用できます。

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

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

  • MaxDirSearchDepth integer (任意)

    パスに ** が含まれる場合の再帰検索の最大ディレクトリ深度。デフォルト:0。有効な値:0〜1,000。

  • 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 つ以上の flusher を設定してログの送信先を定義します。この例では、2 つの Logstore にログを送信します。
      - Type: flusher_sls        # SLS 出力プラグインを指定します。
        Logstore: easy-row-logstore1
      - Type: flusher_sls        # SLS 出力プラグインを指定します。
        Logstore: easy-row-logstore2

flushers (出力プラグイン)

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

  • 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> に宣言されている必要があります。

    • 複数の出力ターゲットを設定すると、設定は Logstore の設定リストに表示されなくなります。複数ターゲットの設定を管理するには、複数ターゲットの設定を管理するにはどうすればよいですか?をご参照ください。

一般的な設定

最小構成を完了した後、processor プラグインを追加して、生ログを解析、マスキング、またはフィルタリングします。

コア構成: 処理プラグインを構成するには、<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> に processors を追加します。これにより、複数のプラグインを同時に有効にすることができます。

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

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

Keys よりも少ない抽出フィールドを許可するかどうか。デフォルト:true。許可しない場合、操作は解析失敗として扱われます。

OverflowedFieldsTreatment String (任意)

Keys よりも多くのフィールドが抽出された場合の動作。デフォルト: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
    KeepingSourceWhenParseFail: true
    RenamedSourceKey: raw_log

SourceKey String (必須)

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

KeepingSourceWhenParseFail boolean (任意)

解析に失敗した場合にソースフィールドを保持するかどうか。デフォルト:false。

KeepingSourceWhenParseSucceed boolean (任意)

解析が成功した場合にソースフィールドを保持するかどうか。デフォルト:false。

RenamedSourceKey String (任意)

保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。

説明

CRD YAML のパラメーター名は camelCase (例:RenamedSourceKey) を使用します。snake_case (例:renamed_source_key) の名前は無効です。

ネストされた 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 (任意)

すべての展開されたフィールド名に追加するプレフィックス。

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

true に設定すると、すべての展開されたフィールド名のプレフィックスとしてソースフィールド名を使用します。

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

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

Script String (必須)

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

TimeoutMilliSeconds integer (任意)

スクリプト実行のタイムアウト (ミリ秒)。値は 0〜10,000 の間でなければなりません。デフォルト値:1,000。

NGINX ログ解析

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

パラメーター

例

Type String (必須)

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

NGINX ログを解析するための正規表現。

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 設定ファイルで定義されたフォーマットに基づいて、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 String (必須)

Apache ログを解析するための正規表現。

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

機密データを置き換える定数文字列。このパラメーターは、Method が const に設定されている場合に必須です。

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

FilterRegex パターンを適用するログフィールド名のリスト。

時刻解析

ログの時刻フィールドを解析し、その結果をログの __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 より東のタイムゾーン

  • GMT-HH:MM:GMT より西のタイムゾーン

高度な設定

最小構成を完了した後、これらの高度な設定を使用して、より詳細な収集を行います。

  • 複数行ログ収集の設定:開始パターンの正規表現で複数行モードを有効にし、複数行にまたがるエントリ (スタックトレースなど) を単一のログレコードとして収集します。

  • ログトピックタイプの設定:ログストリームにトピックを割り当てて、整理と取得を容易にします。

  • 収集対象コンテナの指定 (フィルタリングとブラックリスト登録):ホワイトリストとブラックリストを使用して、特定のコンテナとパスからのみログを収集します。

  • タグによるログのエンリッチ:環境変数と Pod ラベルからのメタデータをログにタグとして追加します。

複数行ログ収集の設定

デフォルトでは、SLS はログを 1 行ずつ分割し、スタックトレースのような複数行のエントリを別々のレコードに分割します。

複数行モードを有効にし、開始パターンの正規表現を設定して、複数行のエントリを単一のログレコードにグループ化します。

キー設定:<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 ラベルのホワイトリスト。指定された Pod ラベルを持つコンテナからログを収集します。

    • ExcludeK8sLabel

      K8s Pod ラベルのブラックリスト。指定された Pod ラベルを持つコンテナからのログを除外します。

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

    • IncludeEnv

      環境変数のホワイトリスト。

    • ExcludeEnv

      環境変数のブラックリスト。

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

    • K8sNamespaceRegex

      正規表現で名前空間名に一致させます。

    • K8sPodRegex

      正規表現で Pod 名に一致させます。

    • K8sContainerRegex

      正規表現でコンテナ名に一致させます。

すべての正規表現マッチングは、Go 言語の RE2 エンジンに基づいており、PCRE (Perl 互換正規表現) などのエンジンと比較して特定の制限があります。正規表現は、付録:コンテナフィルタリングの正規表現の制限のガイドラインに従って記述してください。
# ...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> で、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> です。

設定例

ユースケース 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:複数行ログの処理

デフォルトでは、SLS は各行を個別のログエントリとして扱い、スタックトレースのような複数行のログを複数のレコードに分割します。

開始パターンの正規表現で複数行モードを有効にして、複数行ログのすべての行を単一のエントリにグループ化します。

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

よくある質問

複数ターゲットへの配信の管理

複数ターゲットへの配信設定は複数の Logstore に関連付けられており、プロジェクトレベルの管理ページで管理する必要があります。

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

  2. 「プロジェクト」ページの左側のナビゲーションウィンドウで、imageリソース > 設定の管理をクリックします。

    説明

    このページには、誤って削除された Logstore の残りの設定を含む、プロジェクト内のすべての収集設定がリストされます。

ACK ログをアカウントをまたいだプロジェクトに送信する

ACK クラスターに LoongCollector (Logtail) を手動でインストールし、ターゲットアカウントの認証情報で設定して、別の Alibaba Cloud アカウントのプロジェクトにログを送信します。

利用シーン:組織構造、権限隔離、または統一されたモニタリングのために、ACK クラスターから別のアカウントのプロジェクトにログを収集します。

操作手順:この手順では、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
    # AliyunLogFullAccess ポリシーを持つ Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID とシークレット。
    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 はまた、以下のリソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。

    リソースタイプ

    リソース名

    説明

    プロジェクト

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

    異なるサービスからのログを分離します。

    マシングループ

    k8s-group-${cluster_id}

    ログ収集ノードのグループ。

    重要

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

単一ソースに対する複数収集

デフォルトでは、SLS は重複を防ぐために、各ログソースを単一の収集設定に制限します。

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

  • コンテナの標準出力 (stdout) は、1 つの標準出力収集設定にのみ一致できます。

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

  2. 左側のナビゲーションウィンドウで、imageLogstore を選択し、ターゲットの 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) モードを選択してください。サポートされていない構文を使用すると、プラグインが正しく解析またはマッチングできなくなります。