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

Simple Log Service:Kubernetes Pod からのテキストログの収集 (Sidecar モード)

最終更新日:Mar 01, 2026

Kubernetes 環境において、Sidecar モードは、アプリケーションログの詳細な管理、マルチテナントデータ分離、またはログ収集とアプリケーションライフサイクルの厳密な連動を保証するための理想的なログ収集ソリューションです。このモードでは、独立した LoongCollector (Logtail) コンテナーをアプリケーションの Pod にインジェクトします。この設定により、その Pod 専用のログ収集が可能になり、強力な柔軟性と隔離性を提供します。

仕組み

Sidecar モードでは、アプリケーションコンテナーと LoongCollector (Logtail) ログ収集コンテナーが、アプリケーションの Pod 内で並行して実行されます。これらは共有ボリュームとライフサイクル同期メカニズムを使用して連携します。

  • ログ共有:アプリケーションコンテナーは、ログファイルを共有ボリューム (通常は emptyDir ボリューム) に書き込みます。LoongCollector (Logtail) コンテナーは同じ共有ボリュームをマウントし、これによりこれらのログファイルをリアルタイムで読み取り、収集することができます。

  • 構成の関連付け:各 LoongCollector (Logtail) Sidecar コンテナーは、一意の カスタム ID を設定することで自身の ID を宣言します。Simple Log Service コンソールでは、同じ ID を使用するマシングループを作成できます。これにより、同じ ID を持つすべての Sidecar インスタンスに、そのマシングループで設定された収集構成が自動的に適用されます。

  • ライフサイクル同期:Pod が終了する際のログ損失を防ぐため、アプリケーションコンテナーと LoongCollector (Logtail) コンテナーは、共有ボリューム内のシグナルファイル (cornerstone および tombstone) を使用して通信します。このメカニズムは、Pod の グレースフルシャットダウン期間 (terminationGracePeriodSeconds) と連携して、グレースフルシャットダウンを保証します。まずアプリケーションコンテナーが書き込みを停止し、LoongCollector が残りのすべてのログの送信を完了した後、両方のコンテナーが一緒に終了します。

事前準備

ログを収集する前に、ログを管理および保存するためのプロジェクトと Logstore を作成する必要があります。これらのリソースが既にある場合は、このステップをスキップしてステップ 1:LoongCollector Sidecar コンテナーのインジェクションに進んでください。

  • プロジェクト:Simple Log Service におけるリソース管理単位であり、異なるプロジェクトやサービスのログを隔離し、管理するために使用されます。

  • Logstore:ログを保存するために使用されるログストレージ単位です。

プロジェクトの作成

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

  2. [プロジェクトの作成] をクリックし、以下のパラメーターを設定します:

    • [リージョン]:ログの発生元となるリージョンを選択します。プロジェクト作成後は変更できません。

    • [プロジェクト名]:Alibaba Cloud 内でグローバルに一意である必要があります。プロジェクト作成後は変更できません。

    • その他の設定はデフォルトのままで、[作成] をクリックします。その他のパラメーターの詳細については、「プロジェクトの作成」をご参照ください。

Logstore の作成

  1. プロジェクト名をクリックして、プロジェクト詳細ページに移動します。

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

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

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

    • [Logstore タイプ]:機能比較に基づいて、標準ストレージまたはクエリを選択します。

    • [課金モード]

      • [機能課金]:ストレージ、インデックス、読み書き操作などのリソースに対して個別に課金されます。このモードは、小規模なシナリオや機能の使用量が不確定な場合に適しています。

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

    • [データ保持期間]:ログを保持する日数を指定します。値は 1 から 3,650 までの整数です。3,650 は永久保持を示します。デフォルトは 30 日です。

    • その他のパラメーターはデフォルト設定のままで、[OK] をクリックします。その他のパラメーターの詳細については、「Logstore の管理」をご参照ください。

ステップ 1:LoongCollector Sidecar コンテナーのインジェクション

LoongCollector Sidecar コンテナーをアプリケーションの Pod にインジェクトし、共有ボリュームを設定してログ収集を有効にします。アプリケーションをまだデプロイしていない場合や、テストのみを行う場合は、付録:YAML の例を使用してプロセスを迅速に検証できます。

1. アプリケーション Pod の YAML 構成の変更

  1. 共有ボリュームの定義

    spec.template.spec.volumes に、containers と同じレベルで 3 つの共有ボリュームを追加します:

    volumes:
      # 共有ログディレクトリ (アプリケーションコンテナーが書き込み、Sidecar が読み取り)
      - name: ${shared_volume_name} # <-- volumeMounts の名前と一致させる必要があります
        emptyDir: {}
      
      # コンテナー間通信用のシグナルディレクトリ (グレースフルシャットダウン用)
      - name: tasksite
        emptyDir:
          medium: Memory  # パフォーマンス向上のため、媒体としてメモリを使用
          sizeLimit: "50Mi"
      
      # 共有ホストタイムゾーン構成:Pod 内のすべてのコンテナーのタイムゾーンを同期
      - name: tz-config # <-- volumeMounts の名前と一致させる必要があります
        hostPath:
          path: /usr/share/zoneinfo/Asia/Shanghai  # 必要に応じてタイムゾーンを変更
    
  2. アプリケーションコンテナーのマウント構成

    アプリケーションコンテナー (例:your-business-app-container) の volumeMounts セクションに、以下のマウント項目を追加します:

    LoongCollector によるログ収集を有効にするには、アプリケーションコンテナーがログを ${shared_volume_path} ディレクトリに書き込むようにしてください。
    volumeMounts:
      # 共有ログボリュームをアプリケーションのログ出力ディレクトリにマウント
      - name: ${shared_volume_name}
        mountPath: ${shared_volume_path}  # 例:/var/log/app
    
      # 通信ディレクトリをマウント
      - name: tasksite
        mountPath: /tasksite  # Loongcollector コンテナーとの通信用共有ディレクトリ
    
      # タイムゾーンファイルをマウント
      - name: tz-config
        mountPath: /etc/localtime
        readOnly: true
    
  3. LoongCollector Sidecar コンテナーのインジェクション

    spec.template.spec.containers 配列に、以下の Sidecar コンテナー定義を追加します:

    - name: loongcollector
      image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "[$(date)] LoongCollector: Starting initialization"
          
          # LoongCollector サービスを開始
          /etc/init.d/loongcollectord start
          
          # 構成のダウンロードとサービスの準備が完了するまで待機
          sleep 15
          
          # サービスステータスを確認
          if /etc/init.d/loongcollectord status; then
            echo "[$(date)] LoongCollector: Service started successfully"
            touch /tasksite/cornerstone
          else
            echo "[$(date)] LoongCollector: Failed to start service"
            exit 1
          fi
          
          # アプリケーションコンテナーの完了を待機 (tombstone ファイルシグナル経由)
          echo "[$(date)] LoongCollector: Waiting for business container to complete"
          until [[ -f /tasksite/tombstone ]]; do
            sleep 2
          done
          
          # 残りのログをアップロードする時間を確保
          echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
          sleep 30
          
          # サービスを停止
          echo "[$(date)] LoongCollector: Stopping service"
          /etc/init.d/loongcollectord stop
          echo "[$(date)] LoongCollector: Shutdown complete"
      # ヘルスチェック
      livenessProbe:
        exec:
          command: ["/etc/init.d/loongcollectord", "status"]
        initialDelaySeconds: 30
        periodSeconds: 10
        timeoutSeconds: 5
        failureThreshold: 3
      # リソース構成
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "2000m"
          memory: "2048Mi"
      # 環境変数構成
      env:
        - name: ALIYUN_LOGTAIL_USER_ID
          value: "${your_aliyun_user_id}"
        - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
          value: "${your_machine_group_user_defined_id}"
        - name: ALIYUN_LOGTAIL_CONFIG
          value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
        # Pod 終了前にすべてのログが送信されるようにフルドレインモードを有効化
        - name: enable_full_drain_mode
          value: "true"  
        # Pod 環境コンテキストをログタグとして追加
        - name: ALIYUN_LOG_ENV_TAGS
          value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
        # Pod とノードのメタデータをログタグとして自動的にインジェクト
        - name: "_pod_name_"
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: "_pod_ip_"
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: "_namespace_"
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: "_node_name_"
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: "_node_ip_"
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP
      # ボリュームマウント (アプリケーションコンテナーと共有)
      volumeMounts:
        # アプリケーションログディレクトリの読み取り専用マウント
        - name: ${shared_volume_name} # <-- 共有ログディレクトリ名
          mountPath: ${dir_containing_your_files} # <-- Sidecar 内の共有ディレクトリへのパス
          readOnly: true
        # 通信ディレクトリをマウント
        - name: tasksite
          mountPath: /tasksite
        # タイムゾーンをマウント
        - name: tz-config
          mountPath: /etc/localtime
          readOnly: true
    

2. アプリケーションコンテナーのライフサイクルロジックの変更

ワークロードの種類に応じて、Sidecar との協調的な終了をサポートするようにアプリケーションコンテナーを変更します:

短期タスク (Job/CronJob)

# 1. LoongCollector の準備が完了するまで待機
echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
  sleep 1
done
echo "[$(date)] Business: LoongCollector is ready, starting business logic"

# 2. コアビジネスロジックを実行 (ログが共有ディレクトリに書き込まれることを確認)
echo "Hello, World!" >> /app/logs/business.log

# 3. 終了コードを保存
retcode=$?
echo "[$(date)] Business: Task completed with exit code: $retcode"

# 4. ビジネスタスクが完了したことを LoongCollector に通知
touch /tasksite/tombstone
echo "[$(date)] Business: Tombstone created, exiting"

exit $retcode

長期サービス (Deployment / StatefulSet)

# シグナルハンドラ関数を定義
_term_handler() {
    echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."

    # グレースフルストップのために Nginx に QUIT シグナルを送信
    if [ -n "$NGINX_PID" ]; then
        kill -QUIT "$NGINX_PID" 2>/dev/null || true
        echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"

        # Nginx がグレースフルに停止するのを待機
        wait "$NGINX_PID"
        EXIT_CODE=$?
        echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
    fi

    # アプリケーションコンテナーが停止したことを LoongCollector に通知
    echo "[$(date)] [nginx-demo] Writing tombstone file"
    touch /tasksite/tombstone

    exit $EXIT_CODE
}

# シグナルハンドラを登録
trap _term_handler SIGTERM SIGINT SIGQUIT

# LoongCollector の準備が完了するまで待機
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do 
    sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"

# Nginx を開始
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"

# Nginx プロセスを待機
wait $NGINX_PID
EXIT_CODE=$?

# シグナルが原因でない終了の場合も LoongCollector に通知
if [ ! -f /tasksite/tombstone ]; then
    echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
    touch /tasksite/tombstone
fi

exit $EXIT_CODE

3. グレースフルシャットダウン期間の設定

spec.template.spec で、LoongCollector が残りのログをアップロードするのに十分な時間を確保するために、十分な終了猶予期間を設定します。

spec:
  # ... その他の既存の spec 構成 ...
  template:
    spec:
      terminationGracePeriodSeconds: 600  # 10 分間のグレースフルシャットダウン期間

4. 変数の説明

変数

説明

${your_aliyun_user_id}

ご利用の Alibaba Cloud アカウントの ID に設定します。詳細については、「ユーザー ID の設定」をご参照ください。

${your_machine_group_user_defined_id}

マシングループのカスタム ID を設定します。この ID はカスタムマシングループを作成するために使用されます。例:nginx-log-sidecar

重要

この ID がプロジェクトのリージョン内で一意であることを確認してください。

${your_region_config}

Simple Log Service プロジェクトのリージョンとアクセスに使用するネットワークタイプに基づいて構成を指定します。リージョンに関する情報については、「サービスリージョン」をご参照ください。

例:プロジェクトが中国 (杭州) リージョンにある場合、内部ネットワークアクセスには cn-hangzhou を、パブリックネットワークアクセスには cn-hangzhou-internet を使用します。

${shared_volume_name}

ボリュームのカスタム名を設定します。

重要

volumeMounts ノード下の name パラメーターは、volumes ノード下の name パラメーターと同じでなければなりません。これにより、LoongCollector コンテナーとアプリケーションコンテナーが同じボリュームにマウントされることが保証されます。

${dir_containing_your_files}

マウントパスを設定します。これは、収集対象のテキストログが配置されているコンテナー内のディレクトリです。

5. 構成の適用と結果の確認

  1. 次のコマンドを実行して変更をデプロイします:

    kubectl apply -f <YOUR-YAML>
  2. Pod のステータスを確認して、LoongCollector コンテナーが正常にインジェクトされたことを確認します:

    kubectl describe pod <YOUR-POD-NAME>

    2 つのコンテナー (アプリケーションコンテナーと loongcollector) のステータスが Normal であれば、インジェクションは成功です。

ステップ 2:カスタム ID を持つマシングループの作成

このステップでは、LoongCollector Sidecar インスタンスを Simple Log Service に登録します。これにより、収集構成を一元的に管理し、配信することができます。

操作手順

  1. マシングループの作成

    1. 対象のプロジェクトで、左側のナビゲーションウィンドウでimage[リソース] > [マシングループ]をクリックします。

    2. [マシングループ] ページで、machine group > [マシングループの作成] をクリックします。

  2. マシングループの構成

    以下のパラメーターを設定し、[OK] をクリックします:

    • [名前]:マシングループの名前。作成後は変更できません。名前は以下の要件を満たす必要があります:

      • 名前には小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。

      • 名前は小文字または数字で開始および終了する必要があります。

      • 長さは 2〜128 文字である必要があります。

    • [マシングループ ID][カスタム ID] を選択します。

    • [カスタム ID]ステップ 1 の YAML ファイルで LoongCollector コンテナーに設定した ALIYUN_LOGTAIL_USER_DEFINED_ID 環境変数の値を入力します。値は完全に一致する必要があります。そうでなければ、関連付けは失敗します。

  3. マシングループのハートビートステータスの確認

    マシングループが作成された後、その名前をクリックし、マシングループのステータス領域でハートビートステータスを確認します。

    • OK:LoongCollector が Simple Log Service に正常に接続し、マシングループが登録されたことを示します。

    • FAIL:

      • 構成がまだ有効になっていない可能性があります。構成が有効になるまで約 2 分かかります。ページをリフレッシュして後でもう一度試すことができます。

      • 2 分後もステータスが [FAIL] のままである場合は、「Logtail マシングループの問題のトラブルシューティング」を参照して問題を診断してください。

各 Pod は個別の LoongCollector インスタンスに対応します。詳細な管理を容易にするために、異なるサービスや環境には異なるカスタム ID を使用することを推奨します。

ステップ 3:収集構成の作成

このステップでは、LoongCollector がどのログファイルを収集し、ログ構造をどのように解析し、コンテンツをどのようにフィルターするかを定義します。その後、構成をマシングループに適用します。

操作手順

  1. [imageLogstores] ページで、対象の Logstore 名の前にある image をクリックして展開します。

  2. [データ収集] の横にある image アイコンをクリックします。[クイックデータ収集] ダイアログボックスで、[Kubernetes - ファイル] カードを見つけ、[今すぐ収集] をクリックします。

  3. [マシングループの構成] を行い、[次へ] をクリックします:

    • シナリオ[Kubernetes クラスター] を選択します。

    • デプロイ方法[Sidecar] を選択します。

    • マシングループの選択[ソースマシングループ] リストで、ステップ 2 で作成したカスタム ID ベースのマシングループを選択し、image をクリックして [適用済みマシングループ] リストに追加します。

  4. [Logtail 構成] ページで、Logtail 収集ルールを構成します。

1. グローバル構成と入力構成

収集構成の名前、ログソース、および収集範囲を定義します。

[グローバル構成]

  • [構成名]:収集構成のカスタム名。この名前はプロジェクト内で一意である必要があり、作成後は変更できません。命名規則:

    • 小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。

    • 小文字または数字で開始および終了する必要があります。

[入力構成]

  • [タイプ][テキストログ収集]

  • Logtail デプロイメントモード: [サイドカー] を選択します。

  • ファイルパスタイプ:

    • [コンテナー内のパス]:コンテナー内からログファイルを収集します。

    • [ホストパス]:ホスト上のローカルサービスからログを収集します。

  • [ファイルパス]:ログが収集されるパス。

    • Linux:パスはスラッシュ (/) で始まる必要があります。例えば、/data/mylogs/**/*.log/data/mylogs ディレクトリ内の .log 拡張子を持つすべてのファイルを指定します。

    • Windows:パスはドライブ文字で始まる必要があります。例えば、C:\Program Files\Intel\**\*.Log

  • [最大ディレクトリ監視深度][ファイルパス] のワイルドカード ** が一致できる最大のディレクトリ深度。デフォルト値は 0 で、現在のディレクトリのみを監視することを意味します。

2. ログの処理と構造化

生の非構造化ログを構造化された検索可能なデータに変換するために、ログ処理ルールを構成します。これにより、ログのクエリと分析の効率が向上します。まずサンプルログを追加することを推奨します:

[Logtail 構成] ページの [プロセッサー構成] セクションで、[サンプルログの追加] をクリックし、収集するログコンテンツを入力します。システムはサンプルに基づいてログ形式を識別し、正規表現と解析ルールの生成を支援し、構成を簡素化します。

ユースケース 1:複数行ログの処理 (Java スタックログなど)

Java の例外スタックや JSON オブジェクトなどのログは、しばしば複数行にわたるため、デフォルトの収集モードでは不完全な複数のレコードに分割され、コンテキストが失われます。これを防ぐには、複数行モードを有効にし、先頭行に一致する正規表現を構成して、同じログの連続する行を単一の完全なログにマージします。

例:

未処理の生ログ

デフォルトの収集モードでは、各行が個別のログとなり、スタックトレースが壊れ、コンテキストが失われる

複数行モードを有効にすると、先頭行に一致する正規表現が完全なログを識別し、その完全な意味構造を保持する

image

image

image

手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[複数行モード] を有効にします:

  • [タイプ] には、[カスタム] または [複数行 JSON] を選択します。

    • [カスタム]:可変形式の生ログの場合、[先頭行に一致する正規表現] を構成して、各ログの開始行を識別します。

      • [先頭行に一致する正規表現]:完全なデータ行に一致する正規表現を自動生成または手動で入力します。例えば、上記の例の正規表現は \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.* です。

        • 自動生成:[生成] をクリックします。次に、[ログサンプル] テキストボックスで、抽出したいログコンテンツを選択し、[自動生成] をクリックします。

        • 手動入力:[正規表現の手動入力] をクリックします。式を入力した後、[検証] をクリックします。

    • [複数行 JSON]:ログが標準の JSON 形式である場合、SLS は単一の生ログ内の改行を自動的に処理します。

  • [分割失敗時の処理方法]

    • [破棄]:行頭ルールに一致しないテキストセグメントを破棄します。

    • [単一行として保持]:一致しないテキストを別々の行に保持します。

シナリオ 2:構造化ログ

NGINX アクセスログやアプリケーション出力ログなど、生のログが非構造化または半構造化テキストである場合、直接のクエリや分析は非効率的です。SLS は、さまざまな形式の生ログを自動的に構造化データに変換できる多様なデータ解析プラグインを提供します。これにより、後続の分析、監視、アラートのための堅固なデータ基盤が提供されます。

例:

生ログ

構造化ログ

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"
body_bytes_sent: 368
http_referer: -
http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.x.x Safari/537.36
remote_addr:192.168.*.*
remote_user: -
request_length: 514
request_method: GET
request_time: 0.000
request_uri: /nginx-logo.png
status: 200
time_local: 15/Apr/2025:16:40:00

設定手順: [Logtail 設定] ページの [プロセッサ設定] セクションで:

  1. 解析プラグインの追加:解析プラグインを追加するには、[プロセッサーの追加] をクリックし、ログ形式に基づいて正規表現、デリミタ、または JSON 解析プラグインなどのプラグインを構成します。例えば、NGINX ログを収集するには、[ネイティブプロセッサー] > [データ解析 (NGINX モード)] を選択します。

  2. [NGINX ログ構成]:Nginx サーバー構成ファイル (nginx.conf) から log_format 定義を完全にコピーし、このテキストボックスに貼り付けます。

    例:

    log_format main  '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';
    重要

    ここでのフォーマット定義は、サーバーでログを生成するフォーマットと完全に同じでなければなりません。そうでなければ、ログ解析は失敗します。

  3. 一般的な構成パラメーターの説明:以下のパラメーターは複数のデータ解析プラグインに表示され、その機能と使用法は一貫しています。

    • 元のフィールド:解析対象のソースフィールドを指定します。デフォルトは content で、収集されたログエントリ全体です。

    • 解析失敗時に元のフィールドを保持:このオプションを有効にすることを推奨します。フォーマットの不一致などでログがプラグインによって解析できない場合、このオプションは生のログコンテンツが指定された元のフィールドに保持されることを保証します。

    • 解析成功時に元のフィールドを保持:選択した場合、ログが正常に解析されても生のログコンテンツは保持されます。

3. ログフィルタリング

DEBUG や INFO レベルのログなど、価値の低いまたは無関係なログを大量に収集すると、ストレージリソースを浪費し、コストを増加させ、クエリ効率に影響を与え、データ漏洩のリスクをもたらします。効率的で安全なログ収集のために、詳細なフィルターポリシーを実装できます。

コンテンツフィルタリングによるコスト削減

ログコンテンツに基づいてフィールドをフィルターし、例えばレベルが WARNING または ERROR のログのみを収集します。

例:

未処理の生ログ

WARNING または ERROR ログのみを収集

{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}
{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}
{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}

手順:[Logtail 構成] ページの [プロセッサー構成] セクションで

[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データフィルター] を選択します:

  • [フィールド名]:フィルタリングに使用するログフィールド。

  • [フィールド値]:フィルタリングに使用する正規表現。部分的なキーワード一致ではなく、完全一致のみがサポートされます。

ブラックリストによる収集範囲の制御

ブラックリストを使用して指定されたディレクトリやファイルを除外し、無関係または機密性の高いログがアップロードされるのを防ぎます。

手順:[Logtail 構成] ページの [入力構成] > [その他の入力構成] セクションで、[収集ブラックリスト] を有効にし、[追加] をクリックします。

ディレクトリとファイル名の完全一致およびワイルドカード一致をサポートします。サポートされているワイルドカードはアスタリスク (*) とクエスチョンマーク (?) のみです。
  • [ファイルパスブラックリスト]:除外するファイルパスを指定します。例:

    • /home/admin/private*.log/home/admin/ ディレクトリ内の private で始まり .log で終わるすべてのファイルを無視します。

    • /home/admin/private*/*_inner.log/home/admin/ ディレクトリ下の private で始まるディレクトリ内にある _inner.log で終わるファイルを無視します。

  • [ファイルブラックリスト]:収集中に無視するファイル名のリスト。例:

    • app_inner.log:収集中に app_inner.log という名前のすべてのファイルを無視します。

  • [ディレクトリブラックリスト]:ディレクトリパスはスラッシュ (/) で終わることはできません。例:

    • /home/admin/dir1/:ディレクトリブラックリストは有効になりません。

    • /home/admin/dir*:収集中に /home/admin/ ディレクトリ下の dir で始まるすべてのサブディレクトリ内のファイルを無視します。

    • /home/admin/*/dir/home/admin/ ディレクトリの第 2 レベルにある dir という名前のサブディレクトリ内のすべてのファイルを無視します。例えば、/home/admin/a/dir ディレクトリ内のファイルは無視されますが、/home/admin/a/b/dir ディレクトリ内のファイルは収集されます。

コンテナーフィルター

コンテナーのメタデータ (環境変数、Pod ラベル、名前空間、コンテナー名など) に基づいて収集条件を設定し、どのコンテナーのログを収集するかを正確に制御できます。

設定手順: [Logtail 設定] ページの [入力設定] エリアで、[コンテナフィルタリング] を有効にし、[追加] をクリックします。

複数の条件は AND 関係にあります。すべての正規表現マッチングは Go の RE2 正規表現エンジンに基づいており、PCRE などのエンジンと比較していくつかの制限があります。正規表現を記述する際は、「付録:正規表現の制限 (コンテナーフィルター)」のガイドラインに従ってください。
  • 環境変数ブラックリスト/ホワイトリスト:収集対象のコンテナーの環境変数に関する条件を指定します。

  • K8s Pod ラベルブラックリスト/ホワイトリスト:収集対象のコンテナーが配置されている Pod のラベルに関する条件を指定します。

  • K8s Pod 名正規表現一致:Pod 名で収集対象のコンテナーを指定します。

  • K8s 名前空間正規表現一致:名前空間名で収集対象のコンテナーを指定します。

  • K8s コンテナー名正規表現一致:コンテナー名で収集対象のコンテナーを指定します。

  • コンテナーラベルブラックリスト/ホワイトリスト:指定された条件を満たすラベルを持つコンテナーを収集します。これは Docker シナリオ用であり、Kubernetes シナリオでは推奨されません。

4. ログの分類

複数のアプリケーションやインスタンスが同じログ形式を共有している場合、ログのソースを区別することが困難になることがあります。このコンテキストの欠如は、クエリと分析の効率を低下させます。この問題を解決するために、トピックとログタグを構成して、コンテキストの関連付けと論理的な分類を自動化できます。

トピックの構成

複数のアプリケーションやインスタンスからのログが同じ形式で、パスが異なる場合 (例:/apps/app-A/run.log/apps/app-B/run.log)、ログのソースを区別することが困難です。マシングループ、カスタム名、またはファイルパス抽出に基づいてトピックを生成し、異なるサービスやパスからのログを柔軟に区別できます。

手順:[グローバル構成] > [その他のグローバル構成] > [ログトピックタイプ]:トピックを生成する方法を選択します。以下の 3 つのタイプがサポートされています:

  • マシングループトピック:収集構成が複数のマシングループに適用される場合、LoongCollector はサーバーのマシングループ名を __topic__ フィールドとして自動的に使用してアップロードします。これは、ホストごとにログを分割するユースケースに適しています。

  • [カスタム]customized://<custom_topic_name> の形式を使用します (例:customized://app-login)。この形式は、固定のビジネス識別子を持つ静的なトピックのユースケースに適しています。

  • ファイルパスからの抽出:ログファイルの完全なパスからキー情報を抽出し、ログソースを動的にマークします。これは、複数のユーザーやアプリケーションが同じログファイル名を共有しているが、パスが異なる状況に適しています。例えば、複数のユーザーやサービスが異なるトップレベルディレクトリにログを書き込むが、サブパスとファイル名が同一である場合、ファイル名だけではソースを区別できません:

    /data/logs
    ├── userA
    │   └── serviceA
    │       └── service.log
    ├── userB
    │   └── serviceA
    │       └── service.log
    └── userC
        └── serviceA
            └── service.log

    ファイルパスからの抽出を構成し、正規表現を使用して完全なパスからキー情報を抽出します。一致した結果は、トピックとして Logstore にアップロードされます。

    ファイルパス抽出ルール:正規表現のキャプチャグループに基づく

    正規表現を構成すると、システムはキャプチャグループの数と命名に基づいて出力フィールドの形式を自動的に決定します。ルールは以下の通りです:

    ファイルパスの正規表現では、スラッシュ (/) をエスケープする必要があります。

    キャプチャグループのタイプ

    ユースケース

    生成されるフィールド

    正規表現の例

    一致するパスの例

    生成されるフィールドの例

    単一のキャプチャグループ ((.*?) が 1 つのみ)

    ソースを区別するために 1 つのディメンションのみが必要 (ユーザー名や環境など)

    __topic__ フィールドを生成

    \/logs\/(.*?)\/app\.log

    /logs/userA/app.log

    __topic__: userA

    複数のキャプチャグループ - 名前なし (複数の (.*?))

    ソースを区別するために複数のディメンションが必要だが、意味的なタグは不要

    タグフィールド __tag__:__topic_{i}__ を生成。ここで {i} はキャプチャグループの序数

    \/logs\/(.*?)\/(.*?)\/app\.log

    /logs/userA/svcA/app.log

    __tag__:__topic_1__userA

    __tag__:__topic_2__svcA

    複数のキャプチャグループ - 名前付き ((?P<name>.*?) を使用)

    ソースを区別するために複数のディメンションが必要で、クエリや分析を容易にするためにフィールドの意味が明確であるべき

    タグフィールド __tag__:{name} を生成

    \/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log

    /logs/userA/svcA/app.log

    __tag__:user:userA;

    __tag__:service:svcA

ログタギング

ログタギング機能を有効にすると、コンテナーの環境変数や Kubernetes Pod のラベルからキー情報を抽出し、タグとして追加できます。これにより、ログを詳細にグループ化できます。

設定手順: [Logtail 設定] ページの [入力設定] セクションで、[ログタグ拡張] を有効にし、[追加] をクリックします。

  • [環境変数]:環境変数名とタグ名を設定します。環境変数の値はタグ名に保存されます。

    • 環境変数名:抽出する環境変数の名前を指定します。

    • タグ名:環境変数タグの名前。

  • [Pod ラベル]:Pod ラベル名とタグ名を設定します。Pod ラベルの値はタグに保存されます。

    • Pod ラベル名:抽出する Kubernetes Pod ラベルの名前。

    • タグ名:タグの名前。

5. 出力構成

デフォルトでは、すべてのログが収集され、lz4 圧縮を使用して現在の Logstore に送信されます。同じソースからのログを異なる Logstore に配信するには、次の手順を実行します:

動的な複数宛先への配信

重要
  • 複数宛先への送信は、LoongCollector 3.0.0 以降にのみ適用されます。Logtail はこの機能をサポートしていません。

  • 最大 5 つの出力先を構成できます。

  • 複数の出力先を構成した後、この収集構成は現在の Logstore の収集構成リストに表示されなくなります。複数宛先配信構成の表示、変更、または削除方法の詳細については、「複数宛先配信構成を管理するにはどうすればよいですか?」をご参照ください。

設定手順: [Logtail 設定] ページの [出力設定] エリア。

  1. image をクリックして出力構成を展開します。

  2. [出力ターゲットの追加] をクリックし、以下の構成を完了します:

    • [Logstore]:ターゲットの Logstore を選択します。

    • 圧縮方法: [lz4][zstd] をサポートします。

    • [ルーティング構成]:タグフィールドに基づいてログをルーティングします。ルーティング構成に一致するログは、ターゲットの Logstore にアップロードされます。ルーティング構成が空の場合、収集されたすべてのログがターゲットの Logstore にアップロードされます。

      • [タグ名]:ルーティングに使用されるタグフィールドの名前。フィールド名を直接入力します (例:__path__)。__tag__: プレフィックスは不要です。タグフィールドは次の 2 種類に分類されます:

        タグの詳細については、「LoongCollector 収集タグの管理」をご参照ください。
        • エージェント関連:収集エージェント自体に関連し、どのプラグインにも依存しません。例:__hostname____user_defined_id__

        • 入力プラグイン関連:入力プラグインに依存し、プラグインが関連情報を提供してログをエンリッチします。例:ファイル収集用の __path__、Kubernetes 収集用の _pod_name_ および _container_name_

      • [タグ値]:ログのタグフィールドの値がこの値と一致する場合、ログはターゲットの Logstore に送信されます。

      • [タグフィールドの破棄]:このオプションを有効にすると、アップロードされたログにタグフィールドが含まれなくなります。

ステップ 4:クエリと分析設定の構成

ログ処理とプラグインを構成した後、[次へ] をクリックして [クエリと分析の構成] ページに移動します:

  • 全文インデックスはデフォルトで有効になっており、生のログコンテンツに対するキーワード検索をサポートします。

  • フィールドによる正確なクエリを行うには、プレビューデータが読み込まれるのを待ってから、[インデックスの自動生成] をクリックします。SLS は、プレビューデータの最初のエントリに基づいてフィールドインデックスを生成します。

構成が完了したら、[次へ] をクリックして、収集プロセス全体の設定を完了します。

ステップ 5:アップロードされたログの表示

収集構成を作成してマシングループに適用すると、システムは自動的に構成を配信し、増分ログの収集を開始します。

  1. ログファイルに新しいコンテンツが追加されたことを確認する:LoongCollector は増分ログのみを収集します。tail -f /path/to/your/log/file を実行し、ビジネス操作をトリガーして新しいログが書き込まれることを確認できます。

  2. ログのクエリ:ターゲットの Logstore のクエリと分析ページに移動し、[検索と分析] をクリックして新しいログが取り込まれているかを確認します。デフォルトの時間範囲は過去 15 分です。コンテナーテキストログのデフォルトフィールドは次のとおりです:

    フィールド名

    説明

    __tag__:__hostname__

    コンテナーのホスト名。

    __tag__:__path__

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

    __tag__:_container_ip_

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

    __tag__:_image_name_

    コンテナーが使用するイメージの名前。

    説明

    同じハッシュを持つが名前やタグが異なる複数のイメージがある場合、収集構成はハッシュに基づいて名前の 1 つを選択して収集します。選択された名前が YAML ファイルで定義されたものと一致することは保証されません。

    __tag__:_pod_name_

    Pod の名前。

    __tag__:_namespace_

    Pod が属する名前空間。

    __tag__:_pod_uid_

    Pod の一意の識別子 (UID)。

ログ収集の完全性を確保するための主要な構成上の注意点

ログ収集の完全性を確保することは、LoongCollector Sidecar デプロイメントの核となる目標です。以下の構成パラメーターは、ログデータの完全性と信頼性に直接影響します。

LoongCollector のリソース構成

大量のデータが発生するシナリオでは、クライアント側での収集パフォーマンスを確保するために、合理的なリソース構成が基本となります。主要な構成パラメーターは次のとおりです:

# ログ生成レートに基づいて CPU とメモリリソースを構成
resources:
  limits:
    cpu: "2000m"       
    memory: "2Gi"

# 収集パフォーマンスに影響するパラメーター
env:
  - name: cpu_usage_limit
    value: "2"      
  - name: mem_usage_limit
    value: "2048"  
  - name: max_bytes_per_sec
    value: "209715200"
  - name: process_thread_count
    value: "8"                             
  - name: send_request_concurrency
    value: "20"                            

特定のデータ量と対応する構成の関係についての詳細情報は、「Logtail のネットワークタイプ、起動パラメーター、および構成ファイル」をご参照ください。

サーバー側のクォータ構成

サーバー側のクォータ制限やネットワーク異常は、クライアント側のデータ送信を妨げ、ファイル収集側にバックプレッシャーを生じさせ、ログの完全性に影響を与える可能性があります。CloudLens for SLS を使用してプロジェクトのリソースクォータを監視することを推奨します。

初期収集構成の最適化

Pod 起動時の初期ファイル収集ポリシーは、特に高速なデータ書き込みシナリオにおいて、データの完全性に直接影響します。

初期収集サイズを構成することで、新しいファイルからの最初の収集の開始位置を指定できます。デフォルトの初期収集サイズは 1024 KB です。

  • 最初の収集時に、ファイルが 1024 KB 未満の場合、収集はファイルの先頭から開始されます。

  • 最初の収集時に、ファイルが 1024 KB より大きい場合、収集はファイルの末尾から 1024 KB の位置から開始されます。

  • 初期収集サイズは 0 から 10,485,760 KB の範囲で設定できます。

enable_full_drain_mode

これはデータ整合性を確保するための重要なパラメーターです。LoongCollector が SIGTERM シグナルを受信したときに、すべてのデータ収集と送信を完了することを保証します。

# 収集の完全性に影響するパラメーター
env:
  - name: enable_full_drain_mode
    value: "true"                          # フルドレインモードを有効化

よくある質問

複数宛先配信構成を管理するにはどうすればよいですか?

複数宛先配信構成は複数の Logstore に関連付けられているため、プロジェクトレベルの管理ページで維持する必要があります:

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

  2. 対象のプロジェクトページで、左側のナビゲーションウィンドウの image[リソース] > [構成管理] を選択します。

    説明

    このページでは、誤って Logstore が削除された後に残ったものを含め、プロジェクト下のすべての収集構成を一元管理します。

次のステップ

  1. データの可視化:可視化ダッシュボードを使用して、主要なメトリックのトレンドを監視します。

  2. データ異常の自動アラート:アラートポリシーを設定して、システムの異常をリアルタイムで検出します。

  3. Simple Log Service は増分ログのみを収集します。履歴ログを収集するには、「履歴ログファイルのインポート」をご参照ください。

付録:YAML の例

この例は、アプリケーションコンテナー (Nginx) と LoongCollector Sidecar コンテナーを含む完全な Kubernetes Deployment 構成を示しています。Sidecar モードを使用してコンテナーログを収集するのに適しています。

開始する前に、次の 3 つの主要な置き換えを行ってください:

  1. ${your_aliyun_user_id} をご利用の Alibaba Cloud アカウントの UID に置き換えます。

  2. ${your_machine_group_user_defined_id}ステップ 3 で作成したマシングループのカスタム ID に置き換えます。カスタム ID は完全に一致する必要があります。

  3. ${your_region_config} を Simple Log Service プロジェクトのリージョンとネットワークタイプに一致する構成名に置き換えます。

    例:プロジェクトが中国 (杭州) にあり、内部ネットワークアクセスを使用する場合、値を cn-hangzhou に設定します。パブリックネットワークアクセスを使用する場合、値を cn-hangzhou-internet に設定します。

短期タスク (Job/CronJob)

apiVersion: batch/v1
kind: Job
metadata:
  name: demo-job
spec:
  backoffLimit: 3                   
  activeDeadlineSeconds: 3600        
  completions: 1                     
  parallelism: 1                    
  
  template:
    spec:
      restartPolicy: Never         
      terminationGracePeriodSeconds: 300 
      
      containers:
        # アプリケーションコンテナー
        - name: demo-job
          image: debian:bookworm-slim
          command: ["/bin/bash", "-c"]
          args:
            - |
              # LoongCollector の準備が完了するまで待機
              echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
              until [[ -f /tasksite/cornerstone ]]; do 
                sleep 1
              done
              echo "[$(date)] Business: LoongCollector is ready, starting business logic"
              
              # ビジネスロジックを実行
              echo "Hello, World!" >> /app/logs/business.log
              
              # 終了コードを保存
              retcode=$?
              echo "[$(date)] Business: Task completed with exit code: $retcode"
              
              # ビジネスタスクが完了したことを LoongCollector に通知
              touch /tasksite/tombstone
              echo "[$(date)] Business: Tombstone created, exiting"
              
              exit $retcode
          
          # リソース制限
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500"
              memory: "512Mi"
          
          # ボリュームマウント
          volumeMounts:
            - name: app-logs
              mountPath: /app/logs
            - name: tasksite
              mountPath: /tasksite


        # LoongCollector Sidecar コンテナー
        - name: loongcollector
          image: aliyun-observability-release-registry.cn-hongkong.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
          command: ["/bin/bash", "-c"]
          args:
            - |
              echo "[$(date)] LoongCollector: Starting initialization"
              
              # LoongCollector サービスを開始
              /etc/init.d/loongcollectord start
              
              # 構成のダウンロードとサービスの準備が完了するまで待機
              sleep 15
              
              # サービスステータスを確認
              if /etc/init.d/loongcollectord status; then
                echo "[$(date)] LoongCollector: Service started successfully"
                touch /tasksite/cornerstone
              else
                echo "[$(date)] LoongCollector: Failed to start service"
                exit 1
              fi
              
              # アプリケーションコンテナーの完了を待機
              echo "[$(date)] LoongCollector: Waiting for business container to complete"
              until [[ -f /tasksite/tombstone ]]; do 
                sleep 2
              done
              
              echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
              # 残りのログを送信するのに十分な時間を確保
              sleep 30
              
              echo "[$(date)] LoongCollector: Stopping service"
              /etc/init.d/loongcollectord stop
              
              echo "[$(date)] LoongCollector: Shutdown complete"
          
          # ヘルスチェック
          livenessProbe:
            exec:
              command: ["/etc/init.d/loongcollectord", "status"]
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          
          # リソース構成
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          
          # 環境変数構成
          env:
            - name: ALIYUN_LOGTAIL_USER_ID
              value: "your-user-id"
            - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
              value: "your-user-defined-id"
            - name: ALIYUN_LOGTAIL_CONFIG
              value: "/etc/ilogtail/conf/cn-hongkong/ilogtail_config.json"
            - name: ALIYUN_LOG_ENV_TAGS
              value: "_pod_name_|_pod_ip_|_namespace_|_node_name_"
            
            # Pod 情報のインジェクション
            - name: "_pod_name_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: "_pod_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: "_namespace_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: "_node_name_"
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
          
          # ボリュームマウント
          volumeMounts:
            - name: app-logs
              mountPath: /app/logs
              readOnly: true
            - name: tasksite
              mountPath: /tasksite
            - name: tz-config
              mountPath: /etc/localtime
              readOnly: true
      
      # ボリューム定義
      volumes:
        - name: app-logs
          emptyDir: {}
        - name: tasksite
          emptyDir:
            medium: Memory
            sizeLimit: "10Mi"
        - name: tz-config
          hostPath:
            path: /usr/share/zoneinfo/Asia/Shanghai

長期サービス (Deployment / StatefulSet)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: production
  labels:
    app: nginx-demo
    version: v1.0.0
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      
      maxSurge: 1          
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
        version: v1.0.0    
    spec:
      terminationGracePeriodSeconds: 600  # 10 分間のグレースフルシャットダウン期間
      
      containers:
        # アプリケーションコンテナー - Web アプリケーション
        - name: nginx-demo
          image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6          
          # 起動コマンドとシグナル処理
          command: ["/bin/sh", "-c"]
          args:
            - |
              # シグナルハンドラ関数を定義
              _term_handler() {
                  echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
                  
                  # グレースフルストップのために Nginx に QUIT シグナルを送信
                  if [ -n "$NGINX_PID" ]; then
                      kill -QUIT "$NGINX_PID" 2>/dev/null || true
                      echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
                      
                      # Nginx がグレースフルに停止するのを待機
                      wait "$NGINX_PID"
                      EXIT_CODE=$?
                      echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
                  fi
                  
                  # アプリケーションコンテナーが停止したことを LoongCollector に通知
                  echo "[$(date)] [nginx-demo] Writing tombstone file"
                  touch /tasksite/tombstone
                  
                  exit $EXIT_CODE
              }
              
              # シグナルハンドラを登録
              trap _term_handler SIGTERM SIGINT SIGQUIT

              # LoongCollector の準備が完了するまで待機
              echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
              until [[ -f /tasksite/cornerstone ]]; do 
                sleep 1
              done
              echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
              
              # Nginx を開始
              echo "[$(date)] [nginx-demo] Starting Nginx..."
              nginx -g 'daemon off;' &
              NGINX_PID=$!
              echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
              
              # Nginx プロセスを待機
              wait $NGINX_PID
              EXIT_CODE=$?
              
              # シグナルが原因でない終了の場合も LoongCollector に通知
              if [ ! -f /tasksite/tombstone ]; then
                  echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
                  touch /tasksite/tombstone
              fi
              
              exit $EXIT_CODE
                    
          # リソース構成
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "1Gi"
          
          # ボリュームマウント
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx
            - name: tasksite
              mountPath: /tasksite
            - name: tz-config
              mountPath: /etc/localtime
              readOnly: true

        # LoongCollector Sidecar コンテナー
        - name: loongcollector
          image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
          command: ["/bin/bash", "-c"]
          args:
            - |
              echo "[$(date)] LoongCollector: Starting initialization"
              
              # LoongCollector サービスを開始
              /etc/init.d/loongcollectord start
              
              # 構成のダウンロードとサービスの準備が完了するまで待機
              sleep 15
              
              # サービスステータスを確認
              if /etc/init.d/loongcollectord status; then
                echo "[$(date)] LoongCollector: Service started successfully"
                touch /tasksite/cornerstone
              else
                echo "[$(date)] LoongCollector: Failed to start service"
                exit 1
              fi
              
              # アプリケーションコンテナーの完了を待機
              echo "[$(date)] LoongCollector: Waiting for business container to complete"
              until [[ -f /tasksite/tombstone ]]; do 
                sleep 2
              done
              
              echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
              # 残りのログを送信するのに十分な時間を確保
              sleep 30
              
              echo "[$(date)] LoongCollector: Stopping service"
              /etc/init.d/loongcollectord stop
              
              echo "[$(date)] LoongCollector: Shutdown complete"
          
          # ヘルスチェック
          livenessProbe:
            exec:
              command: ["/etc/init.d/loongcollectord", "status"]
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          # リソース構成
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "2000m"
              memory: "2048Mi"
          
          # 環境変数構成
          env:
            - name: ALIYUN_LOGTAIL_USER_ID
              value: "${your_aliyun_user_id}"
            - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
              value: "${your_machine_group_user_defined_id}"
            - name: ALIYUN_LOGTAIL_CONFIG
              value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
            
            # Pod 停止時にすべてのログが送信されるようにフルドレインモードを有効化
            - name: enable_full_drain_mode
              value: "true"
            
            # Pod 環境コンテキストをログタグとして追加
            - name: "ALIYUN_LOG_ENV_TAGS"
              value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
            # Pod とノードの情報を取得
            - name: "_pod_name_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: "_pod_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: "_namespace_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: "_node_name_"
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: "_node_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
          
          # ボリュームマウント
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx
              readOnly: true
            - name: tasksite
              mountPath: /tasksite
            - name: tz-config
              mountPath: /etc/localtime
              readOnly: true
      
      # ボリューム定義
      volumes:
        - name: nginx-logs
          emptyDir: {}
        - name: tasksite
          emptyDir:
            medium: Memory
            sizeLimit: "50Mi"
        - name: tz-config
          hostPath:
            path: /usr/share/zoneinfo/Asia/Shanghai

付録:ネイティブ解析プラグインの詳細

[Logtail 構成] ページの [プロセッサー構成] セクションで、プロセッサーを追加して生ログを構造化します。既存の収集構成に処理プラグインを追加するには、次の手順に従います:

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

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

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

  4. Logtail 構成ページで、[編集] をクリックします。

このセクションでは、一般的なログ処理のユースケースをカバーする、一般的に使用される処理プラグインのみを紹介します。その他の機能については、「拡張プロセッサー」をご参照ください。
重要

プラグインの組み合わせルール (LoongCollector / Logtail 2.0 以降):

  • ネイティブプロセッサーと拡張プロセッサーは、独立して使用することも、必要に応じて組み合わせることもできます。

  • ネイティブプロセッサーはパフォーマンスと安定性が高いため、優先的に使用してください。

  • ネイティブ機能がビジネスニーズを満たせない場合は、構成済みのネイティブプロセッサーの後に拡張プロセッサーを追加して補足的な処理を行います。

順序の制約:

すべてのプラグインは構成された順序で順次実行され、処理チェーンを形成します。注意:すべてのネイティブプロセッサーは、どの拡張プロセッサーよりも前に配置する必要があります。拡張プロセッサーを追加した後は、さらにネイティブプロセッサーを追加することはできません。

正規表現解析

正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析できます。各フィールドは独立してクエリおよび分析できます。

例:

未処理の生ログ

正規表現解析プラグインの使用

127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php?action=rest-nonce HTTP/1.1" 200 41 "http://www.example.com/wp-admin/post-new.php?post_type=page" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0"
body_bytes_sent: 41
http_referer: http://www.example.com/wp-admin/post-new.php?post_type=page
http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0
remote_addr: 127.0.0.1
remote_user: -
request_method: GET
request_protocol: HTTP/1.1
request_uri: /wp-admin/admin-ajax.php?action=rest-nonce
status: 200
time_local: 16/Aug/2024:14:37:52 +0800

構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データ解析 (正規表現モード)] を選択します:

  • [正規表現]:ログに一致させるために使用します。自動生成または手動で入力できます:

    • 自動生成:

      • [正規表現の自動生成] をクリックします。

      • [ログサンプル] で、抽出したいログコンテンツを選択します。

      • [正規表現の生成] をクリックします。

        image

    • 手動入力:ログ形式に基づいて [正規表現の手動入力] を行います。

    式を構成した後、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかテストします。

  • [抽出されたフィールド]:抽出されたログコンテンツ (値) に対応するフィールド名 (キー) を設定します。

  • その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。


デリミタベースの解析

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

例:

未処理の生ログ

指定された文字 , で分割されたフィールド

05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java
ip:10.10.*.*
request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1
size:18204
status:200
time:05/May/2025:13:30:28
user_agent:aliyun-sdk-java

構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データ解析 (デリミタモード)] を選択します:

  • [デリミタ]:ログコンテンツを分割するために使用する文字を指定します。

    例:CSV ファイルの場合、[カスタム] を選択し、カンマ (,) を入力します。

  • [引用符]:フィールド値にセパレータが含まれている場合、誤った分割を避けるためにフィールドを囲む引用符を指定する必要があります。

  • [抽出されたフィールド]:分割された順序で各列にフィールド名 (キー) を設定します。以下のルールが適用されます:

    • フィールド名には文字、数字、アンダースコア (_) のみを含めることができます。

    • 名前は文字またはアンダースコア (_) で始まる必要があります。

    • 最大長は 128 バイトです。

  • その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。


標準 JSON 解析

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

例:

未処理の生ログ

標準 JSON キーと値のペアの自動抽出

{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}
ip: 10.200.98.220
request: {"status": "200", "latency" : "18204" }
time: 05/Jan/2025:13:30:28
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1
user-agent:aliyun-sdk-java

構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [データ解析 (JSON モード)] を選択します:

  • [元のフィールド]:デフォルト値は `content` です。このフィールドは、解析対象の生ログコンテンツを保存するために使用されます。

  • その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。


ネストされた JSON 解析

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

例:

未処理の生ログ

展開深度:0、展開深度をプレフィックスとして使用

展開深度:1、展開深度をプレフィックスとして使用

{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}
0_s_key_k1_k2_k3_k41:41
0_s_key_k1_k2_k3_k4_k51:51
0_s_key_k1_k2_k3_k4_k52:52
1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、[拡張プロセッサー] > [JSON フィールドの展開] を選択します:

  • [元のフィールド]:展開対象の元のフィールド名 (例:content)。

  • [JSON 展開深度]:JSON オブジェクトの展開レベル。値 0 はオブジェクトが完全に展開されることを示し、これがデフォルトです。値 1 は現在のレベルのみが展開されることを示します。

  • [展開されたキーを連結する文字]:JSON 展開中にフィールド名を連結するために使用される文字。デフォルトはアンダースコア (_) です。

  • [JSON 展開プレフィックス]:JSON 展開後のフィールド名にプレフィックスを指定します。

  • [配列の展開]:このオプションを有効にすると、配列がインデックス付きのキーと値のペアに展開されます。

    例:{"k":["a","b"]}{"k[0]":"a","k[1]":"b"} に展開されます。

    展開されたフィールドの名前を変更する場合 (例:prefix_s_key_k1 を new_field_name に変更)、[フィールド名の変更] プラグインを追加してマッピングを完了できます。
  • その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。


JSON 配列解析

json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。

例:

未処理の生ログ

JSON 配列構造の抽出

[{"key1":"value1"},{"key2":"value2"}]
json1:{"key1":"value1"}
json2:{"key2":"value2"}

手順: [Logtail 設定] ページの [プロセッサ設定] セクションで、[処理モード][SPL] に切り替え、[SPL ステートメント] を設定し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。

例:ログフィールド content の JSON 配列から要素を抽出し、結果を新しいフィールド json1 および json2 に保存します。

* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

Apache ログ解析

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

例:

未処理の生ログ

Apache Common Log Format combined 解析

1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36"
http_referer:https://www.example.com/referrer
http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36
remote_addr:192.168.1.10
remote_ident:-
remote_user:-
request_method:GET
request_protocol:HTTP/1.1
request_uri:/index.html
response_size_bytes:1234
status:200
time_local:[08/May/2024:15:30:28 +0800]

構成手順:[Logtail 構成] ページの [処理構成] セクションで、[処理プラグインの追加] をクリックし、[ネイティブ処理プラグイン] > [APACHE パターン解析] を選択します:

  • ログフォーマット: combined

  • [Apache 構成フィールド]:システムは [ログフォーマット] に基づいて構成を自動的に入力します。

    重要

    自動入力されたコンテンツが、サーバー上の Apache 構成ファイルで定義された LogFormat と完全に同じであることを確認してください。ファイルは通常 /etc/apache2/apache2.conf にあります。

  • その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。


データマスキング

ログ内の機密データをマスキングします。

例:

未処理の生ログ

マスキング結果

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]
[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

手順: [Logtail 設定] ページの [プロセッサ設定] セクションで、[プロセッサの追加] をクリックし、[ネイティブプロセッサ] > [データマスキング] を選択します:

  • [元のフィールド]:解析前のログコンテンツを含むフィールド。

  • [データマスキング方法]

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

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

  • [置換文字列][データマスキング方法][const] に設定されている場合、機密コンテンツを置き換える文字列を入力します。

  • [置換されるコンテンツの前のコンテンツ表現]:機密コンテンツを見つけるために使用される式で、RE2 構文を使用して構成されます。

  • [置換されるコンテンツに一致するコンテンツ表現]:機密コンテンツに一致する正規表現。式は RE2 構文で記述する必要があります。


時刻解析

ログ内の時刻フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。

例:

未処理の生ログ

時刻解析

{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

image

手順:[プロセッサー構成] ページの [Logtail 構成] セクションで、[プロセッサーの追加] をクリックし、[ネイティブプロセッサー] > [時刻解析] を選択します:

  • [元のフィールド]:解析前のログコンテンツを含むフィールド。

  • [時刻フォーマット]:ログ内のタイムスタンプに対応する時刻フォーマットを設定します。

  • [タイムゾーン]:ログ時刻フィールドのタイムゾーンを選択します。デフォルトでは、これは LoongCollector (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) モードを選択して互換性を確認できます。サポートされていない構文を使用すると、プラグインは正しく解析またはマッチングを行いません。