サイドカーモードは、各アプリケーションポッドに専用の LoongCollector (Logtail) コンテナを注入し、ポッドごとにログ収集を行います。きめ細かい制御、マルチテナント分離、またはライフサイクルにバインドされたログ収集が必要な場合は、このモードを使用してください。
仕組み
サイドカーモードでは、アプリケーションコンテナと LoongCollector (Logtail) コンテナが Pod 内で並行して実行され、ログアクセスとライフサイクルの同期のためにボリュームを共有します。
-
ログの共有:アプリケーションコンテナは共有ボリューム (通常は
emptyDir) にログを書き込み、LoongCollector (Logtail) コンテナはそのボリュームを読み取り専用でマウントしてリアルタイムで収集します。 -
設定の関連付け:各 LoongCollector (Logtail) サイドカーは、一意の
カスタム識別子を介してそのアイデンティティを宣言します。同じ識別子を持つ Simple Log Service (SLS) コンソールのマシングループは、一致するすべてのサイドカーインスタンスに収集設定を配布します。 -
ライフサイクルの同期:共有ボリューム内のシグナルファイル (
cornerstoneとtombstone) がコンテナのシャットダウンを調整します。これと正常な終了の猶予期間(terminationGracePeriodSeconds) を組み合わせることで、Pod が終了する前に LoongCollector (Logtail) が残りのログの送信を完了することが保証されます。
事前準備
ログを保存するためのプロジェクトと Logstore を作成します。すでに作成済みの場合は、ステップ 1:LoongCollector サイドカーコンテナの注入に進んでください。
-
プロジェクト: Simple Log Service におけるリソース管理の単位であり、プロジェクトまたはサービスごとにログを分離します。
-
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 # パフォーマンス向上のため、medium にはメモリを使用します sizeLimit: "50Mi" # ホストのタイムゾーン設定を共有: Pod 内のすべてのコンテナのタイムゾーンを同期します - name: tz-config # <-- 名前は volumeMounts 内の名前と一致させる必要があります hostPath: path: /usr/share/zoneinfo/Asia/Shanghai # 必要に応じてタイムゾーンを変更してください -
アプリケーションコンテナのマウント設定
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 -
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: 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 application 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} # <-- サイドカー内の共有ディレクトリへのパス readOnly: true # 通信ディレクトリをマウントします - name: tasksite mountPath: /tasksite # タイムゾーンをマウントします - name: tz-config mountPath: /etc/localtime readOnly: true
2. アプリケーションコンテナのライフサイクルロジックの調整
ワークロードの種類に応じて、サイドカーと連携して終了できるようにアプリケーションコンテナを修正します。
短時間で終了するタスク (Job/CronJob)
# 1. LoongCollector の準備完了を待機します
echo "[$(date)] Application: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] Application: LoongCollector is ready, starting application logic"
# 2. アプリケーションの主要ロジックを実行します (ログが共有ディレクトリに書き込まれるようにしてください)
echo "Hello, World!" >> /app/logs/business.log
# 3. 終了コードを保存します
retcode=$?
echo "[$(date)] Application: Task completed with exit code: $retcode"
# 4. アプリケーションタスクが完了したことを LoongCollector に通知します
touch /tasksite/tombstone
echo "[$(date)] Application: 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 application 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. 変数
|
パラメータ |
説明 |
|
|
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 - ファイル] カードを見つけ、今すぐ統合 をクリックします。 -
サーバグループ設定 を行い、次へ をクリックします。
-
シナリオ:Kubernetes シナリオ を選択します。
-
デプロイ方法:[サイドカー] を選択します。
-
マシングループの選択:ソースサーバーグループ リストで、手順 2 で作成したマシングループを選択します。
をクリックして、適用されたサーバーグループ リストに移動します。
-
-
Logtail 設定 ページで、Logtail の収集ルールを設定します。
1. グローバル設定と入力設定
収集設定の名前、ログソース、および収集範囲を定義します。
グローバル設定:
-
設定名: 収集設定のカスタム名。プロジェクト内で一意である必要があります。作成後に変更できません。命名規則は以下のとおりです。
-
小文字、数字、ハイフン(-)、アンダースコア(_)のみ使用可能です。
-
小文字または数字で始まり、小文字または数字で終わる必要があります。
-
[入力設定]:
-
[タイプ]:テキストログ収集 を選択します。
-
[Logtail デプロイモード]:[サイドカー] を選択します。
-
[ファイルパスのタイプ]:
-
[コンテナ内のパス]:コンテナ内からログファイルを収集します。
-
[ホストパス]:ホストからローカルサービスのログを収集します。
-
-
[ファイルパス]:ログ収集用のパス。
-
Linux:パスはスラッシュ (/) で始まる必要があります。たとえば、
/data/mylogs/**/*.logは、/data/mylogsディレクトリとそのサブディレクトリにある、拡張子が .log のすべてのファイルを指定します。 -
Windows:パスはドライブ文字で始まる必要があります (例:
C:\Program Files\Intel\**\*.Log)。
-
-
[ディレクトリ監視の最大深度]:ファイルパス 内の
**ワイルドカードの最大ディレクトリ深度を指定します。デフォルト値の 0 は、現在のディレクトリのみを監視します。
2. ログの処理と構造化
生の非構造化ログを構造化・検索可能なデータに変換するログ処理ルールを構成します。これにより、ログクエリおよび分析の効率が向上します。まず、ログサンプルを追加 します。
プロセッサ設定 セクションの Logtail 構成 ページで、ログサンプルの追加 をクリックし、収集対象のログコンテンツを入力します。システムがサンプルに基づいてログ形式を識別し、正規表現および解析ルールを自動生成することで、構成を簡素化します。
ユースケース 1:マルチラインログ(Java スタックログなど)の処理
Java 例外スタックや JSON オブジェクトなどのログは、多くの場合複数行にわたるため、デフォルトの収集モードでは不完全なレコードに分割され、コンテキストが失われてしまいます。これを防ぐため、マルチラインモードを有効化し、「最初の行を一致させる正規表現」を構成して、同一ログの連続する行を 1 つの完全なログとしてマージします。
例:
|
処理なしの生ログ |
デフォルト収集モードでは各行が個別のログとなり、スタックトレースが分割されてコンテキストが失われる |
マルチラインモードを有効化すると、「最初の行を一致させる正規表現」により完全なログが識別され、完全な意味論的構造が保持される |
|
|
|
|
手順: プロセッサ設定 セクションの Logtail 構成 ページで、マルチラインモード を有効化します。
-
タイプ で、カスタム または マルチライン JSON を選択します。
-
カスタム: 形式が可変の生ログの場合、「最初の行を一致させる正規表現」を構成して、各行の開始を識別します。
-
最初の行を一致させる正規表現: 完全なデータ行に一致する正規表現を自動生成または手動で入力します。前述の例の正規表現は
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*です。-
自動生成: 生成 をクリックします。その後、ログサンプル テキストボックスで抽出対象のログコンテンツを選択し、自動生成 をクリックします。
-
手動入力: 正規表現を手動で入力 をクリックします。式を入力後、検証 をクリックします。
-
-
-
マルチライン JSON: ログが標準 JSON 形式の場合、SLS が自動的に単一の生ログ内の改行を処理します。
-
-
分割失敗時の処理方法:
-
破棄: 開始行ルールに一致しないテキストセグメントを破棄します。
-
1 行単位で保持: 一致しなかったテキストを個別の行として保持します。
-
シナリオ 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 構成 ページで
プロセッサの追加 をクリックし、 を選択します。
-
フィールド名: フィルタリングに使用するログフィールド。
-
フィールド値: フィルタリングに使用する正規表現。部分的なキーワード一致ではなく、完全一致のみがサポートされます。
収集ブロックリスト
ブラックリストを使用して、指定されたディレクトリまたはファイルを除外し、関係のないまたは機密性の高いログのアップロードを防止します。
手順: セクションの 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[ファイルパスの抽出] を設定し、正規表現を使用して完全なパスから重要な情報を抽出します。マッチした結果は、トピックとしてログストアにアップロードされます。
ファイルパス抽出ルール:正規表現キャプチャグループに基づく
正規表現を構成する際、システムはキャプチャグループの数および名前に基づいて自動的に出力フィールド形式を決定します。ルールは以下のとおりです。
ファイルパスの正規表現では、スラッシュ(/)をエスケープする必要があります。
キャプチャグループの種類
ユースケース
生成されるフィールド
正規表現の例
一致するパスの例
生成されるフィールドの例
単一のキャプチャグループ(
(.*?)が 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. 出力設定
デフォルトでは、すべてのログは lz4 形式で圧縮されて現在の Logstore に送信されます。ログを複数の 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
ポッドの名前です。
tag:namespace
ポッドが属する名前空間です。
tag:pod_uid
ポッドの一意の識別子 (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 network types, startup parameters, and configuration files」をご参照ください。
サーバー側のクォータ設定
サーバー側のクォータ制限やネットワークの問題によってデータ転送がブロックされると、バックプレッシャーが発生し、ログの完全性に影響します。CloudLens for SLS を使用してプロジェクトのリソースクォータを監視してください。
初回収集設定の最適化
Pod 起動時のファイル初回収集ポリシーは、特に高スループットシナリオでは、ログの完全性に影響します。
初回収集サイズは、新しいファイルで収集を開始する位置を指定します。デフォルト:1024 KB。
-
ファイルサイズが 1024 KB 未満の場合、先頭から収集を開始します。
-
ファイルサイズが 1024 KB を超える場合、末尾から 1024 KB 手前の位置から収集を開始します。
-
初回収集サイズの範囲は 0~10,485,760 KB (10 GB) です。
enable_full_drain_mode
このパラメーターは、LoongCollector が SIGTERM シグナルを受信して終了する前に、すべてのデータ収集とデータ転送を完了することを保証します。
# 収集の完全性を保証するためのパラメーター
env:
- name: enable_full_drain_mode
value: "true" # フルドレインモードを有効にします
よくある質問
複数送信先配信設定の管理
複数送信先配信設定は複数の Logstore に適用されるため、プロジェクトレベルで管理する必要があります。
-
Log Service コンソールにログインし、対象のプロジェクト名をクリックします。
-
対象のプロジェクトページで、左側のナビゲーションペインから
の順にクリックします。説明このページでは、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: 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: "500m"
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: 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_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"
- 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 サイドカーコンテナ
- 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: "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、タイムスタンプ、リクエストメソッドとパス、ステータスコード、リファラー、ユーザーエージェントなどのフィールドが含まれます。
-
-
手動入力:ログ形式に基づいて[手動で入力]します。
式を入力した後、検証 をクリックして、ログの内容を正しく解析できるかテストします。
-
-
[ログ抽出フィールド]:抽出された各ログの内容 (値) にフィールド名 (キー) を設定します。
-
その他のパラメーターについては、「シナリオ 2:構造化ログ」の一般的なパラメーターの説明をご参照ください。
区切り文字解析
区切り文字解析を使用して、ログの内容をキーと値のペアに分割します。単一文字および複数文字の区切り文字に対応しています。
例:
|
処理なしの生ログ |
指定された文字 |
|
|
手順:Logtail 設定 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
[区切りモード]:ログの内容の分割に使用する文字。
例:CSV ファイルの場合、カスタム を選択し、コンマ (,) を入力します。
-
[引用符]:フィールド値に区切り文字が含まれる場合、誤った分割を防ぐためにフィールドを囲む引用符を指定する必要があります。
-
[ログ抽出フィールド]:各列に順番にフィールド名 (キー) を割り当てます。フィールド名は次のルールに従う必要があります。
-
文字、数字、アンダースコア (_) のみを含めることができます。
-
先頭は文字またはアンダースコア (_) である必要があります。
-
長さは最大 128 バイトです。
-
-
その他のパラメーターについては、「シナリオ 2:構造化ログ」の一般的なパラメーターの説明をご参照ください。
JSON 解析
JSON オブジェクト形式のログを、キーと値のペアに解析します。
例:
|
処理なしの生ログ |
標準 JSON キーと値のペアの自動抽出 |
|
|
手順:Logtail 設定 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
[元のフィールド]:デフォルト値は
contentです。このフィールドには解析対象の生ログが含まれます。 -
その他のパラメーターについては、「シナリオ 2:構造化ログ」の一般的なパラメーターの説明をご参照ください。
JSON フィールドの展開
ネストされた JSON オブジェクトを含むフィールドを、複数のキーと値のペアに展開します。
例:
|
処理なしの生ログ |
展開深度:0、展開深度をプレフィックスとして使用 |
展開深度:1、展開深度をプレフィックスとして使用 |
|
|
|
手順:Logtail 設定 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、 を選択します。
-
[元のフィールド]:展開する元のフィールドの名前 (例:
content)。 -
[JSON 拡張度]:JSON オブジェクトの展開レベル。値が 0 (デフォルト) の場合はオブジェクトを完全に展開します。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 構成 ページで、プロセッサの追加 をクリックし、 を選択します。
-
元のフィールド: 解析前のログコンテンツを含むフィールド。
-
データマスキング方法:
-
const: 機密コンテンツを定数文字列に置き換えます。
-
md5: 機密コンテンツをその MD5 ハッシュに置き換えます。
-
-
置換文字列: データマスキング方法 が const に設定されている場合、機密コンテンツを置き換える文字列を入力します。
-
置換されるコンテンツの前のコンテンツ式: 機密コンテンツを見つけるために使用される式。これは RE2 構文 を使用して構成されます。
-
置換されるコンテンツに一致するコンテンツ式: 機密コンテンツに一致させるために使用される正規表現。式は RE2 構文 で記述する必要があります。
時間解析
ログ内の時間フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。
例:
|
処理なしの生ログ |
時間解析 |
|
|
手順: プロセッサ設定 セクションの 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) モードを選択する必要があります。サポートされていない構文を使用すると、プラグインは正しく解析またはマッチングできません。



