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

Simple Log Service:Kubernetes Pod のテキストログを収集する (サイドカーモード)

最終更新日:Oct 10, 2026

サイドカーモードでは、各アプリケーション Pod に専用の LoongCollector (Logtail) コンテナをインジェクトし、Pod ごとのログ収集を実現します。このモードは、詳細な制御、マルチテナント分離、またはライフサイクルにバインドされたログ収集が必要な場合に最適です。

仕組み

サイドカーモードでは、アプリケーションコンテナと LoongCollector (Logtail) コンテナが Pod 内で並行して実行され、ログアクセスとライフサイクル同期のためにボリュームを共有します。

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

  • 構成の関連付け: 各 LoongCollector (Logtail) サイドカーは、一意の カスタム識別子 を通じて自身の ID を宣言します。SLS コンソールで同じ識別子を持つマシングループが、一致するすべてのサイドカーに収集設定を配信します。

  • ライフサイクル同期: 共有ボリューム内のシグナルファイル (cornerstone および tombstone) がコンテナのシャットダウンを調整します。これらは グレースフルシャットダウン期間 (terminationGracePeriodSeconds) と連携し、Pod が終了する前に LoongCollector (Logtail) が残りのログの送信を完了することを保証します。

事前準備

ログを保存するためのプロジェクトと Logstore を作成します。すでに作成済みの場合は、「ステップ 1: LoongCollector サイドカーコンテナをインジェクトする」に進んでください。

  • プロジェクト: SLS におけるリソース管理の単位で、プロジェクトやサービスごとにログを分離します。

  • 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 サイドカーコンテナをインジェクトする

ログ収集のために、共有ボリュームを持つ LoongCollector サイドカーコンテナをアプリケーション Pod にインジェクトします。簡単なテストには、「付録: YAML の例」をご利用ください。

1. Pod の YAML 設定を変更する

  1. 共有ボリュームを定義する

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

    volumes:
      # 共有ログディレクトリ (アプリケーションコンテナが書き込み、サイドカーが読み取る)
      - 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 セクションに、以下のボリュームマウントを追加します。

    アプリケーションコンテナが ${shared_volume_path} ディレクトリにログを書き込むようにしてください。これにより、LoongCollector がログを収集できるようになります。
    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 サイドカーコンテナをインジェクトする

    spec.template.spec.containers 配列に、以下のサイドカーコンテナ定義を追加します。

    - 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: 初期化を開始します"
          # LoongCollector サービスを開始
          /etc/init.d/loongcollectord start
          # 設定がダウンロードされ、サービスが準備完了するまで待機
          sleep 15
          # サービスステータスを確認
          if /etc/init.d/loongcollectord status; then
            echo "[$(date)] LoongCollector: サービスの開始に成功しました"
            touch /tasksite/cornerstone
          else
            echo "[$(date)] LoongCollector: サービスの開始に失敗しました"
            exit 1
          fi
          # アプリケーションコンテナの完了を待機 (tombstone ファイルシグナル経由)
          echo "[$(date)] LoongCollector: アプリケーションコンテナの完了を待機しています"
          until [[ -f /tasksite/tombstone ]]; do
            sleep 2
          done
          # 残りのログをアップロードする時間を確保
          echo "[$(date)] LoongCollector: ビジネス処理が完了しました。ログ転送を待機しています"
          sleep 30
          # サービスを停止
          echo "[$(date)] LoongCollector: サービスを停止しています"
          /etc/init.d/loongcollectord stop
          echo "[$(date)] LoongCollector: シャットダウンが完了しました"
      # ヘルスチェック
      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} # <-- サイドカー内の共有ディレクトリへのパス
          readOnly: true
        # 通信ディレクトリをマウント
        - name: tasksite
          mountPath: /tasksite
        # タイムゾーンをマウント
        - name: tz-config
          mountPath: /etc/localtime
          readOnly: true
    

2. アプリケーションコンテナのライフサイクルロジックを調整する

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

短命タスク (Job/CronJob)

# 1. LoongCollector の準備が完了するまで待機
echo "[$(date)] Application: LoongCollector の準備完了を待機しています..."
until [[ -f /tasksite/cornerstone ]]; do
  sleep 1
done
echo "[$(date)] Application: LoongCollector の準備が完了しました。アプリケーションロジックを開始します"
# 2. コアアプリケーションロジックを実行 (ログが共有ディレクトリに書き込まれることを確認)
echo "Hello, World!" >> /app/logs/business.log
# 3. 終了コードを保存
retcode=$?
echo "[$(date)] Application: タスクが終了コード $retcode で完了しました"
# 4. アプリケーションタスクが完了したことを LoongCollector に通知
touch /tasksite/tombstone
echo "[$(date)] Application: tombstone を作成しました。終了します"
exit $retcode

長命サービス (Deployment / StatefulSet)

# シグナルハンドラ関数を定義
_term_handler() {
    echo "[$(date)] [nginx-demo] SIGTERM をキャッチしました。グレースフルシャットダウンを開始します..."
    # グレースフルストップのために Nginx に QUIT シグナルを送信
    if [ -n "$NGINX_PID" ]; then
        kill -QUIT "$NGINX_PID" 2>/dev/null || true
        echo "[$(date)] [nginx-demo] Nginx PID: $NGINX_PID に SIGQUIT を送信しました"
        # Nginx がグレースフルに停止するのを待機
        wait "$NGINX_PID"
        EXIT_CODE=$?
        echo "[$(date)] [nginx-demo] Nginx が終了コード $EXIT_CODE で停止しました"
    fi
    # アプリケーションコンテナが停止したことを LoongCollector に通知
    echo "[$(date)] [nginx-demo] tombstone ファイルを書き込んでいます"
    touch /tasksite/tombstone
    exit $EXIT_CODE
}
# シグナルハンドラを登録
trap _term_handler SIGTERM SIGINT SIGQUIT
# LoongCollector の準備が完了するまで待機
echo "[$(date)] [nginx-demo]: LoongCollector の準備完了を待機しています..."
until [[ -f /tasksite/cornerstone ]]; do 
    sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector の準備が完了しました。アプリケーションロジックを開始します"
# Nginx を開始
echo "[$(date)] [nginx-demo] Nginx を開始しています..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx が PID: $NGINX_PID で開始されました"
# Nginx プロセスを待機
wait $NGINX_PID
EXIT_CODE=$?
# シグナルが原因でない終了の場合も LoongCollector に通知
if [ ! -f /tasksite/tombstone ]; then
    echo "[$(date)] [nginx-demo] 予期せぬ終了です。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。「ユーザー識別子の設定」をご参照ください。

${your_machine_group_user_defined_id}

マシングループを作成するために使用されるカスタム識別子。例: nginx-log-sidecar。

重要

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

${your_region_config}

ご利用の SLS プロジェクトのリージョンとネットワークアクセスタイプに対応する設定。「サービスリージョン」をご参照ください。

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

${shared_volume_name}

共有ボリュームのカスタム名。

重要

volumeMounts の name は volumes の name と一致する必要があります。これにより、両方のコンテナが同じ共有ボリュームをマウントすることが保証されます。

${dir_containing_your_files}

テキストログが配置されている LoongCollector コンテナ内のマウントパス。

5. 設定の適用と確認

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

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

    kubectl describe pod <YOUR-POD-NAME>

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

ステップ 2: カスタム識別子マシングループを作成する

LoongCollector サイドカーインスタンスを SLS に登録し、収集設定を一元管理します。

手順

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

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

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

  2. マシングループの設定

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

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

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

      • 先頭と末尾は小文字または数字である必要があります。

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

    • マシングループの識別子: ユーザー定義 ID を選択します。

    • ユーザー定義 ID: ステップ 1 の YAML ファイルで LoongCollector コンテナに設定した ALIYUN_LOGTAIL_USER_DEFINED_ID 環境変数の値を入力します。値は完全に一致する必要があります。一致しない場合、関連付けは失敗します。

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

    マシングループを作成した後、その名前をクリックして [マシングループステータス] セクションでハートビートステータスを確認します。

    • OK: LoongCollector が SLS に接続し、マシングループが登録されました。

    • FAIL:

各 Pod は個別の LoongCollector インスタンスに対応します。詳細な管理を行うには、アプリケーションや環境ごとに異なるカスタム識別子を使用してください。

ステップ 3: 収集設定を作成する

収集設定は、LoongCollector がどのログファイルを収集し、どのように解析し、どのコンテンツをフィルタリングするかを定義します。

手順

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

  2. データのインポート の横にある image をクリックします。データのインポート ダイアログボックスで、Kubernetes - File カードを見つけ、今すぐ統合 をクリックします。

  3. サーバグループ設定 を構成し、次へ をクリックします。

    • シナリオ: Kubernetes シナリオ を選択します。

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

    • マシングループの選択: [ソースサーバーグループ リストで、ステップ 2 で作成したマシングループを選択します。image をクリックして [適用されたサーバーグループ リストに移動します。

  4. Logtail 設定 ページで、Logtail 収集ルールを設定します。

1. グローバル設定と入力設定

収集設定の名前、ログソース、収集範囲を定義します。

グローバル設定:

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

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

    • 先頭と末尾は小文字または数字である必要があります。

入力設定:

  • タイプ: テキストログ収集 を選択します。

  • Logtail デプロイモード: [Sidecar] を選択します。

  • ファイルパスのタイプ:

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

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

    • dockerFile: 収集したいログファイルがコンテナ内にある場合 (上記のコンテナパスオプションを参照)、収集設定で dockerFile: true を設定する必要があります。そうしないと、Logtail は設定を通常のファイル収集として処理し、コンテナ内のログファイルを検出できず、ログが欠落する原因となります。

      • コンソール: [詳細オプション] で、コンテナファイル収集を選択します。または、コンソールには別途 [Docker ファイル - コンテナ] のデータ収集エントリポイントも用意されています。

      • CRD: inputDetail の下で dockerFile: true を設定します。

  • ファイルパス: ログ収集のパス。

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

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

  • ディレクトリ監視の最大深度: [ファイルパス の ** ワイルドカードの最大ディレクトリ深度を指定します。デフォルト値の 0 はカレントディレクトリのみを監視します。

  • dockerFile: 対象ファイルがコンテナ内にあるかどうかを指定します。Sidecar モードでコンテナ内からログファイルを収集する場合、このパラメーターを true に設定する必要があります。そうしないと、ファイルは通常のホストファイルとして収集され、期待される収集動作と一致しません。タイプ: ブール値。必須: いいえ。デフォルト値: false。

2. ログの処理と構造化

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

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

シナリオ 1: 複数行ログの処理 (Java スタックトレースなど)

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

例:

未処理の生ログ

デフォルトの収集モードでは、各行が独立したログとして扱われます。スタックトレースは分断され、コンテキストが失われます。

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

2025-11-13 10:52:20.557 ERROR [app-thread-0] --- java.sql.SQLException: No suitable driver found for jdbc:mysql://db.host:3306/prod_db
    at com.datastore.util.DataProcessor.save(DataProcessor.java:434)
    at io.awesomeapp.util.PaymentGateway.fetchData(PaymentGateway.java:463)
    at org.awesomeapp.util.UserService.processRequest(UserService.java:252)
    at io.datastore.service.DatabaseConnector.fetchData(DatabaseConnector.java:172)
    at org.datastore.service.UserService.fetchData(UserService.java:517)

デフォルトモードでは、このログは 6 つの独立したレコードに分割されます。最初のレコードには java.sql.SQLException エラーメッセージのみが含まれ、残りの 5 つのスタックフレーム (例: at com.datastore.util.DataProcessor.save(...)) は別々のエントリとして保存されます。スタックフレームはクエリを通じて元の例外と関連付けることができず、トラブルシューティングのためにコンテキストを再構築する手作業が必要になります。

複数行モードを有効にすると、java.sql.SQLException: No suitable driver found for jdbc:mysql://db.host:3306/prod_db エラーログと 5 つのスタックフレーム (DataProcessor.save → UserService.fetchData) が、ログクエリサービスで単一のレコードとして収集されます。メタデータ列には、IP、ホスト名、ログパスなどのフィールドも表示されます。

手順: [Logtail構成 ページで、[設定の処理 エリアで マルチラインモード を有効にします。

  • タイプ: カスタム または マルチライン JSON を選択します。

    • カスタム: 生ログの形式が固定されていません。各ログエントリの開始行を識別するために、行先頭の正規表現 を設定する必要があります。

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

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

          レガシーな Kubernetes 標準出力収集モードは、[サンプルログを追加] および正規表現の自動生成機能をサポートしていません。正規表現をテストするには、テキストログタイプの Logstore を作成し、その Logstore で正規表現をテストしてから、対象の Logstore の Logtail 設定に正規表現を貼り付けます。

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

    • マルチライン JSON: すべての生ログが標準の JSON 形式である場合、Simple Log Service (SLS) は単一の JSON ログ内の改行を自動的に処理します。

  • 分割失敗の処理方法:

    • Discard: テキストセグメントが行頭ルールに一致しない場合、破棄されます。

    • 単一行を保持: 一致しないテキストは分割され、元の単一行モードで保持されます。

シナリオ 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 : Mozi11a/5.0 (Nindows NT 10.0; Win64; x64) AppleMebKit/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"';
    重要

    形式定義は、サーバー上の log_format と完全に一致する必要があります。そうでない場合、解析は失敗します。

  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構成 ページの [設定の処理 エリアで

処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > フィルタリング処理 を選択します。

  • Field Name: フィルタリングするログフィールド。

  • フィールド値: フィルタリングに使用する正規表現。全文一致のみがサポートされており、部分的なキーワード一致はサポートされていません。

収集ブラックリスト

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

手順: [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 の 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 Label 関連: Pod ラベル名とタグ名を設定します。Pod ラベルの値がタグの値として保存されます。

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

    • タグ名: タグの名前。

5. 出力設定

デフォルトでは、すべてのログが現在の Logstore に lz4 圧縮で送信されます。ログを複数の Logstore に配信するには、追加の出力先を設定します。

動的な複数宛先への配信

重要
  • 複数宛先への配信は、LoongCollector 3.0.0 以降でのみ利用可能です。この機能は Logtail ではサポートされていません。

  • 最大 5 つの出力先を設定できます。

  • 複数の出力先を設定すると、収集設定は現在の Logstore の収集設定リストに表示されなくなります。複数宛先配信設定を表示、変更、または削除するには、「複数宛先配信設定の管理」をご参照ください。

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

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

  2. 出力先の追加 をクリックし、以下の設定を完了します。

    • Logstores: 宛先の Logstore を選択します。

    • 圧縮方法: lz4 と zstd がサポートされています。

    • ルート設定: タグフィールドに基づいてログをルーティングします。システムは一致するログを宛先の 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

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

    説明

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

    tag:pod_name

    Pod の名前。

    tag:namespace

    Pod が属する名前空間。

    tag:pod_uid

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

ログの完全性を保証するための主要な設定

これらの設定パラメーターは、ログ収集の完全性と信頼性に直接影響します。

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 を設定するには、「Logtail のネットワークタイプ、起動パラメーター、設定ファイル」をご参照ください。

サーバー側のクォータ設定

サーバー側のクォータ制限やネットワークの問題は、データ転送を妨げ、バックプレッシャーを生じさせてログの完全性に影響を与える可能性があります。「CloudLens for SLS を使用してプロジェクトのリソースクォータを監視する」をご参照ください。

初期収集設定の最適化

Pod 起動時の初期ファイル収集ポリシーは、特に高スループットのシナリオでログの完全性に影響します。

初期収集サイズは、新しいファイルでの収集開始位置を指定します。デフォルト: 1024 KB。

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

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

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

enable_full_drain_mode

SIGTERM シグナルを受信した際に、LoongCollector が終了する前にすべてのデータ収集と転送を完了することを保証します。

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

よくある質問

複数宛先配信設定の管理

複数宛先配信設定は複数の Logstore に適用されるため、プロジェクトレベルで管理する必要があります。

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

  2. 対象の Project ページの左側のナビゲーションウィンドウで、imageリソース > 設定の管理 をクリックします。

    説明

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

次のステップ

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

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

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

付録: YAML の例

Nginx アプリケーションコンテナと LoongCollector サイドカーコンテナを含む、完全な Kubernetes 設定です。

この設定を使用する前に、以下のプレースホルダーを置き換えてください。

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

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

  3. ${your_region_config} を、ご利用の SLS プロジェクトのリージョンとネットワークタイプに一致する設定名に置き換えます。

    例: プロジェクトが中国 (杭州) リージョンにある場合、内部ネットワークアクセスには 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: LoongCollector の準備完了を待機しています..."
              until [[ -f /tasksite/cornerstone ]]; do 
                sleep 1
              done
              echo "[$(date)] Business: LoongCollector の準備が完了しました。ビジネスロジックを開始します"
              # アプリケーションロジックを実行します。
              echo "Hello, World!" >> /app/logs/business.log
              # 終了コードを保存します。
              retcode=$?
              echo "[$(date)] Business: タスクが終了コード $retcode で完了しました"
              # タスクが終了したことを LoongCollector に通知します。
              touch /tasksite/tombstone
              echo "[$(date)] Business: tombstone を作成しました。終了します"
              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 サイドカーコンテナ
        - 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: 初期化を開始します"
              # LoongCollector サービスを開始します。
              /etc/init.d/loongcollectord start
              # 設定がダウンロードされ、サービスが準備完了するまで待機します。
              sleep 15
              # サービスステータスを確認します。
              if /etc/init.d/loongcollectord status; then
                echo "[$(date)] LoongCollector: サービスの開始に成功しました"
                touch /tasksite/cornerstone
              else
                echo "[$(date)] LoongCollector: サービスの開始に失敗しました"
                exit 1
              fi
              # アプリケーションコンテナの終了を待ちます。
              echo "[$(date)] LoongCollector: ビジネスコンテナの完了を待機しています"
              until [[ -f /tasksite/tombstone ]]; do 
                sleep 2
              done
              echo "[$(date)] LoongCollector: ビジネス処理が完了しました。ログ転送を待機しています"
              # 残りのログを送信するために十分な時間を確保します。
              sleep 30
              echo "[$(date)] LoongCollector: サービスを停止しています"
              /etc/init.d/loongcollectord stop
              echo "[$(date)] LoongCollector: シャットダウンが完了しました"
          # ヘルスチェック
          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] SIGTERM をキャッチしました。グレースフルシャットダウンを開始します..."
                  # グレースフルストップのために Nginx に QUIT シグナルを送信します。
                  if [ -n "$NGINX_PID" ]; then
                      kill -QUIT "$NGINX_PID" 2>/dev/null || true
                      echo "[$(date)] [nginx-demo] Nginx PID: $NGINX_PID に SIGQUIT を送信しました"
                      # Nginx がグレースフルに停止するのを待ちます。
                      wait "$NGINX_PID"
                      EXIT_CODE=$?
                      echo "[$(date)] [nginx-demo] Nginx が終了コード $EXIT_CODE で停止しました"
                  fi
                  # アプリケーションコンテナが停止したことを LoongCollector に通知します。
                  echo "[$(date)] [nginx-demo] tombstone ファイルを書き込んでいます"
                  touch /tasksite/tombstone
                  exit $EXIT_CODE
              }
              # シグナルハンドラを登録します。
              trap _term_handler SIGTERM SIGINT SIGQUIT
              # LoongCollector の準備が完了するまで待機します。
              echo "[$(date)] [nginx-demo]: LoongCollector の準備完了を待機しています..."
              until [[ -f /tasksite/cornerstone ]]; do 
                sleep 1
              done
              echo "[$(date)] [nginx-demo]: LoongCollector の準備が完了しました。ビジネスロジックを開始します"
              # Nginx を開始します。
              echo "[$(date)] [nginx-demo] Nginx を開始しています..."
              nginx -g 'daemon off;' &
              NGINX_PID=$!
              echo "[$(date)] [nginx-demo] Nginx が PID: $NGINX_PID で開始されました"
              # Nginx プロセスの終了を待ちます。
              wait $NGINX_PID
              EXIT_CODE=$?
              # プロセスがシグナルなしで終了した場合、LoongCollector に通知します。
              if [ ! -f /tasksite/tombstone ]; then
                  echo "[$(date)] [nginx-demo] 予期せぬ終了です。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 サイドカーコンテナ
        - 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: 初期化を開始します"
              # LoongCollector サービスを開始します。
              /etc/init.d/loongcollectord start
              # 設定がダウンロードされ、サービスが準備完了するまで待機します。
              sleep 15
              # サービスステータスを確認します。
              if /etc/init.d/loongcollectord status; then
                echo "[$(date)] LoongCollector: サービスの開始に成功しました"
                touch /tasksite/cornerstone
              else
                echo "[$(date)] LoongCollector: サービスの開始に失敗しました"
                exit 1
              fi
              # アプリケーションコンテナの終了を待ちます。
              echo "[$(date)] LoongCollector: ビジネスコンテナの完了を待機しています"
              until [[ -f /tasksite/tombstone ]]; do 
                sleep 2
              done
              echo "[$(date)] LoongCollector: ビジネス処理が完了しました。ログ転送を待機しています"
              # 残りのログを送信するために十分な時間を確保します。
              sleep 30
              echo "[$(date)] LoongCollector: サービスを停止しています"
              /etc/init.d/loongcollectord stop
              echo "[$(date)] LoongCollector: シャットダウンが完了しました"
          # ヘルスチェック
          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 設定 ページの [設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > 正規表現解析 を選択します。

  • 正規表現: ログコンテンツに一致する正規表現。自動生成するか、手動で入力できます。

    • 自動生成:

      • ヘルプ をクリックします。

      • ログサンプル ボックスで、抽出するログコンテンツを選択します。

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

        例えば、Apache Combined 形式のログを [ログサンプル] ボックスに貼り付けると、クライアント IP、タイムスタンプ、リクエストメソッドとパス、ステータスコード、Referer、User-Agent などのフィールドが含まれます。

    • 手動入力: ログ形式に基づいて 手動で入力 します。

    式を入力した後、検証 をクリックして、ログコンテンツを正しく解析できるかテストします。

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

  • その他のパラメーターについては、「ユースケース 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 のフィールドプレフィックス拡張: 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 共通ログ形式 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 設定ファイル (通常は /etc/apache2/apache2.conf) の LogFormat 定義と完全に一致することを確認してください。

  • その他のパラメーターについては、「ユースケース 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"}

SLS ログ詳細ビューでは、JSON ログが正しく構造化フィールドに解析されます。各フィールド (cluster, level, message, time, userId) とその値が独立して表示されます。

手順: [Logtail構成 ページで、[設定の処理 エリアで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > 時間解析 を選択します。

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

  • 時間形式: ログ内の時刻コンテンツに基づいて、対応する時刻形式を設定します。

  • タイムゾーン: ログの時刻フィールドのタイムゾーンを選択します。デフォルトでは、LoongCollector (Logtail) プロセスが実行されている環境のタイムゾーンであるマシンタイムゾーンが使用されます。

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

コンテナフィルタリングの正規表現は、PCRE と比較して構文に制限がある Go RE2 エンジンを使用します。

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) モードを選択してください。サポートされていない構文は、正しい解析やマッチングを妨げます。