サイドカーモードでは、各アプリケーション 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: ログのストレージユニットです。
プロジェクトの作成
Logstore の作成
ステップ 1: LoongCollector サイドカーコンテナをインジェクトする
ログ収集のために、共有ボリュームを持つ LoongCollector サイドカーコンテナをアプリケーション Pod にインジェクトします。簡単なテストには、「付録: YAML の例」をご利用ください。
1. Pod の YAML 設定を変更する
-
共有ボリュームを定義する
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 # 必要に応じてタイムゾーンを変更してください -
アプリケーションコンテナのマウントを設定する
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 -
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. 変数
|
パラメーター |
説明 |
|
|
ご利用の Alibaba Cloud アカウント ID。「ユーザー識別子の設定」をご参照ください。 |
|
|
マシングループを作成するために使用されるカスタム識別子。例: 重要
この識別子がプロジェクトのリージョン内で一意であることを確認してください。 |
|
|
ご利用の SLS プロジェクトのリージョンとネットワークアクセスタイプに対応する設定。「サービスリージョン」をご参照ください。 例: プロジェクトが中国 (杭州) リージョンにある場合、Alibaba Cloud 内部ネットワークアクセスには |
|
|
共有ボリュームのカスタム名。 重要
|
|
|
テキストログが配置されている LoongCollector コンテナ内のマウントパス。 |
5. 設定の適用と確認
-
以下のコマンドを実行して変更をデプロイします。
kubectl apply -f <YOUR-YAML> -
Pod のステータスを確認して、LoongCollector コンテナが正常にインジェクトされたことを確認します。
kubectl describe pod <YOUR-POD-NAME>2 つのコンテナ (アプリケーションコンテナと
loongcollector) が表示され、そのステータスが Running であれば、インジェクションは成功です。
ステップ 2: カスタム識別子マシングループを作成する
LoongCollector サイドカーインスタンスを SLS に登録し、収集設定を一元管理します。
手順
-
マシングループの作成
-
対象のプロジェクトに移動します。左側のナビゲーションウィンドウで、
をクリックします。 -
[マシングループ] ページで、
> マシングループの作成 をクリックします。
-
-
マシングループの設定
以下のパラメーターを設定し、OK をクリックします。
-
名前: マシングループの名前。作成後は変更できません。名前は以下の要件を満たす必要があります。
-
小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。
-
先頭と末尾は小文字または数字である必要があります。
-
長さは 2~128 文字である必要があります。
-
-
マシングループの識別子: ユーザー定義 ID を選択します。
-
ユーザー定義 ID: ステップ 1 の YAML ファイルで LoongCollector コンテナに設定した
ALIYUN_LOGTAIL_USER_DEFINED_ID環境変数の値を入力します。値は完全に一致する必要があります。一致しない場合、関連付けは失敗します。
-
-
マシングループのハートビートステータスを確認する
マシングループを作成した後、その名前をクリックして [マシングループステータス] セクションでハートビートステータスを確認します。
-
OK: LoongCollector が SLS に接続し、マシングループが登録されました。
-
FAIL:
-
設定変更が有効になるまで最大 2 分かかる場合があります。ページを更新してステータスを再度確認してください。
-
2 分経ってもステータスが FAIL のままである場合は、「Logtail マシングループの問題のトラブルシューティング」をご参照ください。
-
-
各 Pod は個別の LoongCollector インスタンスに対応します。詳細な管理を行うには、アプリケーションや環境ごとに異なるカスタム識別子を使用してください。
ステップ 3: 収集設定を作成する
収集設定は、LoongCollector がどのログファイルを収集し、どのように解析し、どのコンテンツをフィルタリングするかを定義します。
手順
-
[Logstore] ページで、対象の Logstore 名の前にある
をクリックして展開します。 -
データのインポート の横にある
をクリックします。データのインポート ダイアログボックスで、Kubernetes - File カードを見つけ、今すぐ統合 をクリックします。 -
サーバグループ設定 を構成し、次へ をクリックします。
-
シナリオ: Kubernetes シナリオ を選択します。
-
デプロイ方法: [Sidecar] を選択します。
-
マシングループの選択: [ソースサーバーグループ リストで、ステップ 2 で作成したマシングループを選択します。
をクリックして [適用されたサーバーグループ リストに移動します。
-
-
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 オブジェクトなどのログは、しばしば複数行にわたります。デフォルトの収集モードでは、これらは複数の不完全なレコードに分割され、コンテキストが失われます。これを防ぐには、複数行モードを有効にし、行頭の正規表現を設定して、同じログの連続する行を単一の完全なエントリにマージします。
例:
未処理の生ログ | デフォルトの収集モードでは、各行が独立したログとして扱われます。スタックトレースは分断され、コンテキストが失われます。 | 複数行モードを有効にすると、行頭の正規表現が完全なログを識別し、完全な意味構造を保持します。 |
| デフォルトモードでは、このログは 6 つの独立したレコードに分割されます。最初のレコードには | 複数行モードを有効にすると、 |
手順: [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 は、さまざまなデータ解析プラグインを提供しており、異なる形式の生ログを自動的に構造化データに変換できます。これにより、その後の分析、モニタリング、アラート機能のための強固な基盤が提供されます。
例:
未処理の生ログ | 構造化解析後のログ |
| |
設定手順: [Logtail 設定 ページの [設定の処理 エリアで:
-
解析プラグインの追加: 処理プラグインの追加 をクリックし、ログ形式に基づいて 正規表現、区切り文字、または JSON 解析プラグイン などを設定します。例えば、NGINX ログを収集するには、 を選択します。
-
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 と完全に一致する必要があります。そうでない場合、解析は失敗します。
-
一般的な設定パラメーターの説明: 以下のパラメーターは多くの解析プラグインで共通しており、一貫した機能を持ちます。
-
元のフィールド: 解析対象のソースフィールドを指定します。デフォルトは
contentで、収集されたログエントリ全体です。 -
解析失敗時に元のフィールドを保持: 推奨。プラグインがログの解析に失敗した場合、このオプションは元のフィールドに生ログのコンテンツを保持します。
-
解析成功時に元のフィールドを保持: 選択した場合、このオプションは解析が成功した後も生ログのコンテンツを保持します。
-
3. ログフィルタリング
大量の価値の低いログ (DEBUG や INFO レベルなど) は、ストレージを浪費し、コストを増加させ、クエリ効率を低下させ、データ漏えいのリスクをもたらします。効率的で安全なログ収集のために、フィルタリングポリシーを設定します。
コンテンツフィルタリング
ログコンテンツのフィールドに基づいてフィルタリングできます。例えば、レベルが WARNING または ERROR のログのみを収集するなどです。
例:
未処理の生ログ |
|
| |
手順: [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 設定 ページの 出力設定 エリア。
-
をクリックして出力設定を展開します。 -
出力先の追加 をクリックし、以下の設定を完了します。
-
Logstores: 宛先の Logstore を選択します。
-
圧縮方法: lz4 と zstd がサポートされています。
-
ルート設定: タグフィールドに基づいてログをルーティングします。システムは一致するログを宛先の Logstore にアップロードします。この設定が空の場合、システムは収集されたすべてのログをこの宛先にアップロードします。
-
タグ名: ルーティングに使用するタグフィールドの名前。フィールド名のみを入力します (例:
__path__)。__tag__:プレフィックスは含めません。タグフィールドは 2 つのカテゴリに分類されます。タグについては、「LoongCollector 収集タグの管理」をご参照ください。
-
エージェント関連: 収集エージェントに関連し、プラグインから独立しています。例:
__hostname__、__user_defined_id__。 -
入力プラグイン関連: 入力プラグインによって提供され、ログにコンテキスト情報を付加します。例: ファイル収集のための
__path__、Kubernetes 収集のための_pod_name_や_container_name_。
-
-
タグ値: ログのタグフィールドがこの値と一致する場合、システムはそのログをこの宛先 Logstore に送信します。
-
このタグフィールドを破棄するかどうか: 有効にすると、システムはアップロード前にこのタグフィールドをログから削除します。
-
-
ステップ 4: クエリと分析を設定する
ログ処理とプラグインを設定した後、次へ をクリックして [クエリと分析の設定 ページに進みます。
システムはデフォルトで フルテキストインデックス を有効にし、元のログコンテンツに対してキーワード検索を実行できるようにします。
フィールドごとに正確なクエリを実行するには、ページ上でプレビューデータがロードされるのを待ってから、自動インデックスの生成 をクリックします。SLS は、プレビューデータの最初のエントリに基づいて フィールドインデックス を生成します。
設定が完了したら、次へ をクリックして収集設定を完了します。
ステップ 5: アップロードされたログを表示する
収集設定を作成してマシングループに適用すると、自動的にデプロイされ、増分ログの収集が開始されます。
-
新しいログエントリの確認: LoongCollector は増分ログのみを収集します。
tail -f /path/to/your/log/fileを実行し、アプリケーションを使用して新しいログエントリを生成します。 -
ログのクエリ: 対象の 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 に適用されるため、プロジェクトレベルで管理する必要があります。
-
Log Service コンソールにログインし、対象のプロジェクト名をクリックします。
-
対象の Project ページの左側のナビゲーションウィンドウで、
をクリックします。説明このページでは、Logstore が削除された後に残ったものを含め、プロジェクト内のすべての収集設定を一元管理します。
次のステップ
-
データ可視化: 可視化ダッシュボードを使用して、主要メトリックのトレンドを監視します。
-
データ異常の自動アラート: アラートポリシーを設定して、システム異常をリアルタイムで検出します。
-
SLS は増分ログのみを収集します。履歴ログを収集するには、「履歴ログファイルのインポート」をご参照ください。
付録: YAML の例
Nginx アプリケーションコンテナと LoongCollector サイドカーコンテナを含む、完全な Kubernetes 設定です。
この設定を使用する前に、以下のプレースホルダーを置き換えてください。
-
${your_aliyun_user_id}をご利用の Alibaba Cloud アカウント ID に置き換えます。 -
${your_machine_group_user_defined_id}を、 ステップ 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構成 ページで、[設定の処理 エリアで、生ログを構造化するための処理プラグインを追加できます。既存の収集設定に処理プラグインを追加するには、以下の手順に従います。
左側のナビゲーションウィンドウで、
[Logstores] を選択し、対象の Logstore を見つけます。その名前の左にある
をクリックして Logstore を展開します。Logtail構成 をクリックします。設定リストで、対象の Logtail 設定を見つけ、[アクション] 列の Logtail 設定の管理 をクリックします。
Logtail 設定ページで、編集 をクリックします。
このセクションでは、一般的なログ処理シナリオをカバーする、よく使用される処理プラグインのみを紹介します。その他の機能については、「拡張処理プラグイン」をご参照ください。
プラグインの組み合わせルール (LoongCollector / Logtail 2.0 以降に適用):
ネイティブおよび拡張処理プラグインは、必要に応じて独立して、または組み合わせて使用できます。
ネイティブ処理プラグインは、パフォーマンスと安定性が高いため、最初に使用することを推奨します。
ネイティブ機能がビジネス要件を満たせない場合は、設定済みのネイティブプラグインの後に拡張処理プラグインを追加して、補足的な処理を実行できます。
順序の制約:
すべてのプラグインは設定された順序で逐次実行され、処理チェーンを形成します。注意: すべてのネイティブ処理プラグインは、どの拡張処理プラグインよりも前に配置する必要があります。拡張処理プラグインを追加した後は、それ以上ネイティブ処理プラグインを追加することはできません。
正規表現解析
正規表現を使用してログからフィールドを抽出し、キーと値のペアとして独立したクエリと分析を可能にします。
例:
未処理の生ログ | 正規表現解析プラグインの使用 |
| |
手順: [Logtail 設定 ページの [設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
正規表現: ログコンテンツに一致する正規表現。自動生成するか、手動で入力できます。
-
自動生成:
-
ヘルプ をクリックします。
-
ログサンプル ボックスで、抽出するログコンテンツを選択します。
-
正規表現の生成 をクリックします。
例えば、Apache Combined 形式のログを [ログサンプル] ボックスに貼り付けると、クライアント IP、タイムスタンプ、リクエストメソッドとパス、ステータスコード、Referer、User-Agent などのフィールドが含まれます。
-
-
手動入力: ログ形式に基づいて 手動で入力 します。
式を入力した後、検証 をクリックして、ログコンテンツを正しく解析できるかテストします。
-
-
ログ抽出フィールド: 抽出された各ログコンテンツ (値) にフィールド名 (キー) を設定します。
-
その他のパラメーターについては、「ユースケース 2: 構造化ログ」の一般的なパラメーターの説明をご参照ください。
区切り文字解析
区切り文字解析を使用して、ログコンテンツをキーと値のペアに分割します。単一文字および複数文字の区切り文字をサポートします。
例:
未処理の生ログ | 指定された文字 |
| |
手順: [Logtail 設定 ページの [設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
区切りモード: ログコンテンツを分割するために使用する文字。
例: CSV ファイルの場合、カスタム を選択し、カンマ (,) を入力します。
-
引用符: フィールド値に区切り文字が含まれる場合、誤った分割を防ぐためにフィールドを囲む引用符を指定する必要があります。
-
ログ抽出フィールド: 各列に順番にフィールド名 (キー) を割り当てます。フィールド名は以下のルールを満たす必要があります。
-
文字、数字、アンダースコア (_) のみを含めることができます。
-
先頭は文字またはアンダースコア (_) である必要があります。
-
長さは最大 128 バイトです。
-
-
その他のパラメーターについては、「ユースケース 2: 構造化ログ」の一般的なパラメーターの説明をご参照ください。
JSON 解析
JSON オブジェクト形式のログをキーと値のペアに解析します。
例:
未処理の生ログ | 標準 JSON キー値の自動抽出 |
| |
手順: [Logtail 設定 ページの [設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
元のフィールド: デフォルト値は
contentです。このフィールドには、解析対象の生ログが含まれます。 -
その他のパラメーターについては、「ユースケース 2: 構造化ログ」の一般的なパラメーターの説明をご参照ください。
JSON フィールドの展開
ネストされた JSON オブジェクトを含むフィールドを、複数のキーと値のペアに展開します。
例:
未処理の生ログ | 展開深度: 0、展開深度をプレフィックスとして使用 | 展開深度: 1、展開深度をプレフィックスとして使用 |
| | |
手順: Logtail 設定 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
元のフィールド: 展開する元のフィールド名。例:
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 配列構造の抽出 |
| |
手順: [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 共通ログ形式 |
| |
手順: [Logtail 設定 ページの [設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
ログ形式: combined
-
APACHE 設定フィールド: システムは、選択された ログ形式 に基づいてこのフィールドを自動的に入力します。
重要自動入力されたコンテンツが、サーバーの Apache 設定ファイル (通常は
/etc/apache2/apache2.conf) のLogFormat定義と完全に一致することを確認してください。 -
その他のパラメーターについては、「ユースケース 2: 構造化ログ」の一般的なパラメーターの説明をご参照ください。
データマスキング
ログ内の機密データをマスキングします。
例:
未処理の生ログ | マスキング結果 |
| |
手順: [Logtail構成 ページで、[設定の処理 エリアで、処理プラグインの追加 をクリックし、 を選択します。
時刻解析
ログ内の時刻フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。
例:
未処理の生ログ | 時刻解析 |
| SLS ログ詳細ビューでは、JSON ログが正しく構造化フィールドに解析されます。各フィールド ( |
手順: [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) モードを選択してください。サポートされていない構文は、正しい解析やマッチングを妨げます。