Kubernetes 環境において、Sidecar モードは、アプリケーションログの詳細な管理、マルチテナントデータ分離、またはログ収集とアプリケーションライフサイクルの厳密な連動を保証するための理想的なログ収集ソリューションです。このモードでは、独立した LoongCollector (Logtail) コンテナーをアプリケーションの Pod にインジェクトします。この設定により、その Pod 専用のログ収集が可能になり、強力な柔軟性と隔離性を提供します。
仕組み
Sidecar モードでは、アプリケーションコンテナーと LoongCollector (Logtail) ログ収集コンテナーが、アプリケーションの Pod 内で並行して実行されます。これらは共有ボリュームとライフサイクル同期メカニズムを使用して連携します。
ログ共有:アプリケーションコンテナーは、ログファイルを共有ボリューム (通常は
emptyDirボリューム) に書き込みます。LoongCollector (Logtail) コンテナーは同じ共有ボリュームをマウントし、これによりこれらのログファイルをリアルタイムで読み取り、収集することができます。構成の関連付け:各 LoongCollector (Logtail) Sidecar コンテナーは、一意の
カスタム IDを設定することで自身の ID を宣言します。Simple Log Service コンソールでは、同じ ID を使用するマシングループを作成できます。これにより、同じ ID を持つすべての Sidecar インスタンスに、そのマシングループで設定された収集構成が自動的に適用されます。ライフサイクル同期:Pod が終了する際のログ損失を防ぐため、アプリケーションコンテナーと LoongCollector (Logtail) コンテナーは、共有ボリューム内のシグナルファイル (
cornerstoneおよびtombstone) を使用して通信します。このメカニズムは、Pod のグレースフルシャットダウン期間(terminationGracePeriodSeconds) と連携して、グレースフルシャットダウンを保証します。まずアプリケーションコンテナーが書き込みを停止し、LoongCollector が残りのすべてのログの送信を完了した後、両方のコンテナーが一緒に終了します。
事前準備
ログを収集する前に、ログを管理および保存するためのプロジェクトと Logstore を作成する必要があります。これらのリソースが既にある場合は、このステップをスキップしてステップ 1:LoongCollector Sidecar コンテナーのインジェクションに進んでください。
プロジェクト:Simple Log Service におけるリソース管理単位であり、異なるプロジェクトやサービスのログを隔離し、管理するために使用されます。
Logstore:ログを保存するために使用されるログストレージ単位です。
プロジェクトの作成
Logstore の作成
ステップ 1:LoongCollector Sidecar コンテナーのインジェクション
LoongCollector Sidecar コンテナーをアプリケーションの Pod にインジェクトし、共有ボリュームを設定してログ収集を有効にします。アプリケーションをまだデプロイしていない場合や、テストのみを行う場合は、付録:YAML の例を使用してプロセスを迅速に検証できます。
1. アプリケーション Pod の YAML 構成の変更
共有ボリュームの定義
spec.template.spec.volumesに、containersと同じレベルで 3 つの共有ボリュームを追加します:volumes: # 共有ログディレクトリ (アプリケーションコンテナーが書き込み、Sidecar が読み取り) - name: ${shared_volume_name} # <-- volumeMounts の名前と一致させる必要があります emptyDir: {} # コンテナー間通信用のシグナルディレクトリ (グレースフルシャットダウン用) - name: tasksite emptyDir: medium: Memory # パフォーマンス向上のため、媒体としてメモリを使用 sizeLimit: "50Mi" # 共有ホストタイムゾーン構成:Pod 内のすべてのコンテナーのタイムゾーンを同期 - name: tz-config # <-- volumeMounts の名前と一致させる必要があります hostPath: path: /usr/share/zoneinfo/Asia/Shanghai # 必要に応じてタイムゾーンを変更アプリケーションコンテナーのマウント構成
アプリケーションコンテナー (例:
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: trueLoongCollector Sidecar コンテナーのインジェクション
spec.template.spec.containers配列に、以下の Sidecar コンテナー定義を追加します:- name: loongcollector image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun command: ["/bin/bash", "-c"] args: - | echo "[$(date)] LoongCollector: Starting initialization" # LoongCollector サービスを開始 /etc/init.d/loongcollectord start # 構成のダウンロードとサービスの準備が完了するまで待機 sleep 15 # サービスステータスを確認 if /etc/init.d/loongcollectord status; then echo "[$(date)] LoongCollector: Service started successfully" touch /tasksite/cornerstone else echo "[$(date)] LoongCollector: Failed to start service" exit 1 fi # アプリケーションコンテナーの完了を待機 (tombstone ファイルシグナル経由) echo "[$(date)] LoongCollector: Waiting for business container to complete" until [[ -f /tasksite/tombstone ]]; do sleep 2 done # 残りのログをアップロードする時間を確保 echo "[$(date)] LoongCollector: Business completed, waiting for log transmission" sleep 30 # サービスを停止 echo "[$(date)] LoongCollector: Stopping service" /etc/init.d/loongcollectord stop echo "[$(date)] LoongCollector: Shutdown complete" # ヘルスチェック livenessProbe: exec: command: ["/etc/init.d/loongcollectord", "status"] initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 # リソース構成 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "2000m" memory: "2048Mi" # 環境変数構成 env: - name: ALIYUN_LOGTAIL_USER_ID value: "${your_aliyun_user_id}" - name: ALIYUN_LOGTAIL_USER_DEFINED_ID value: "${your_machine_group_user_defined_id}" - name: ALIYUN_LOGTAIL_CONFIG value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json" # Pod 終了前にすべてのログが送信されるようにフルドレインモードを有効化 - name: enable_full_drain_mode value: "true" # Pod 環境コンテキストをログタグとして追加 - name: ALIYUN_LOG_ENV_TAGS value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_" # Pod とノードのメタデータをログタグとして自動的にインジェクト - name: "_pod_name_" valueFrom: fieldRef: fieldPath: metadata.name - name: "_pod_ip_" valueFrom: fieldRef: fieldPath: status.podIP - name: "_namespace_" valueFrom: fieldRef: fieldPath: metadata.namespace - name: "_node_name_" valueFrom: fieldRef: fieldPath: spec.nodeName - name: "_node_ip_" valueFrom: fieldRef: fieldPath: status.hostIP # ボリュームマウント (アプリケーションコンテナーと共有) volumeMounts: # アプリケーションログディレクトリの読み取り専用マウント - name: ${shared_volume_name} # <-- 共有ログディレクトリ名 mountPath: ${dir_containing_your_files} # <-- Sidecar 内の共有ディレクトリへのパス readOnly: true # 通信ディレクトリをマウント - name: tasksite mountPath: /tasksite # タイムゾーンをマウント - name: tz-config mountPath: /etc/localtime readOnly: true
2. アプリケーションコンテナーのライフサイクルロジックの変更
ワークロードの種類に応じて、Sidecar との協調的な終了をサポートするようにアプリケーションコンテナーを変更します:
短期タスク (Job/CronJob)
# 1. LoongCollector の準備が完了するまで待機
echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] Business: LoongCollector is ready, starting business logic"
# 2. コアビジネスロジックを実行 (ログが共有ディレクトリに書き込まれることを確認)
echo "Hello, World!" >> /app/logs/business.log
# 3. 終了コードを保存
retcode=$?
echo "[$(date)] Business: Task completed with exit code: $retcode"
# 4. ビジネスタスクが完了したことを LoongCollector に通知
touch /tasksite/tombstone
echo "[$(date)] Business: Tombstone created, exiting"
exit $retcode長期サービス (Deployment / StatefulSet)
# シグナルハンドラ関数を定義
_term_handler() {
echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
# グレースフルストップのために Nginx に QUIT シグナルを送信
if [ -n "$NGINX_PID" ]; then
kill -QUIT "$NGINX_PID" 2>/dev/null || true
echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
# Nginx がグレースフルに停止するのを待機
wait "$NGINX_PID"
EXIT_CODE=$?
echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
fi
# アプリケーションコンテナーが停止したことを LoongCollector に通知
echo "[$(date)] [nginx-demo] Writing tombstone file"
touch /tasksite/tombstone
exit $EXIT_CODE
}
# シグナルハンドラを登録
trap _term_handler SIGTERM SIGINT SIGQUIT
# LoongCollector の準備が完了するまで待機
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
# Nginx を開始
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
# Nginx プロセスを待機
wait $NGINX_PID
EXIT_CODE=$?
# シグナルが原因でない終了の場合も LoongCollector に通知
if [ ! -f /tasksite/tombstone ]; then
echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
touch /tasksite/tombstone
fi
exit $EXIT_CODE3. グレースフルシャットダウン期間の設定
spec.template.spec で、LoongCollector が残りのログをアップロードするのに十分な時間を確保するために、十分な終了猶予期間を設定します。
spec:
# ... その他の既存の spec 構成 ...
template:
spec:
terminationGracePeriodSeconds: 600 # 10 分間のグレースフルシャットダウン期間4. 変数の説明
変数 | 説明 |
| ご利用の Alibaba Cloud アカウントの ID に設定します。詳細については、「ユーザー ID の設定」をご参照ください。 |
| マシングループのカスタム ID を設定します。この ID はカスタムマシングループを作成するために使用されます。例: 重要 この ID がプロジェクトのリージョン内で一意であることを確認してください。 |
| Simple Log Service プロジェクトのリージョンとアクセスに使用するネットワークタイプに基づいて構成を指定します。リージョンに関する情報については、「サービスリージョン」をご参照ください。 例:プロジェクトが中国 (杭州) リージョンにある場合、内部ネットワークアクセスには |
| ボリュームのカスタム名を設定します。 重要
|
| マウントパスを設定します。これは、収集対象のテキストログが配置されているコンテナー内のディレクトリです。 |
5. 構成の適用と結果の確認
次のコマンドを実行して変更をデプロイします:
kubectl apply -f <YOUR-YAML>Pod のステータスを確認して、LoongCollector コンテナーが正常にインジェクトされたことを確認します:
kubectl describe pod <YOUR-POD-NAME>2 つのコンテナー (アプリケーションコンテナーと
loongcollector) のステータスが Normal であれば、インジェクションは成功です。
ステップ 2:カスタム ID を持つマシングループの作成
このステップでは、LoongCollector Sidecar インスタンスを Simple Log Service に登録します。これにより、収集構成を一元的に管理し、配信することができます。
操作手順
マシングループの作成
対象のプロジェクトで、左側のナビゲーションウィンドウで
をクリックします。[マシングループ] ページで、 をクリックします。
マシングループの構成
以下のパラメーターを設定し、[OK] をクリックします:
[名前]:マシングループの名前。作成後は変更できません。名前は以下の要件を満たす必要があります:
名前には小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。
名前は小文字または数字で開始および終了する必要があります。
長さは 2〜128 文字である必要があります。
[マシングループ ID]:[カスタム ID] を選択します。
[カスタム ID]:ステップ 1 の YAML ファイルで LoongCollector コンテナーに設定した
ALIYUN_LOGTAIL_USER_DEFINED_ID環境変数の値を入力します。値は完全に一致する必要があります。そうでなければ、関連付けは失敗します。
マシングループのハートビートステータスの確認
マシングループが作成された後、その名前をクリックし、マシングループのステータス領域でハートビートステータスを確認します。
OK:LoongCollector が Simple Log Service に正常に接続し、マシングループが登録されたことを示します。
FAIL:
構成がまだ有効になっていない可能性があります。構成が有効になるまで約 2 分かかります。ページをリフレッシュして後でもう一度試すことができます。
2 分後もステータスが [FAIL] のままである場合は、「Logtail マシングループの問題のトラブルシューティング」を参照して問題を診断してください。
各 Pod は個別の LoongCollector インスタンスに対応します。詳細な管理を容易にするために、異なるサービスや環境には異なるカスタム ID を使用することを推奨します。
ステップ 3:収集構成の作成
このステップでは、LoongCollector がどのログファイルを収集し、ログ構造をどのように解析し、コンテンツをどのようにフィルターするかを定義します。その後、構成をマシングループに適用します。
操作手順
[
Logstores] ページで、対象の Logstore 名の前にある
をクリックして展開します。[データ収集] の横にある
アイコンをクリックします。[クイックデータ収集] ダイアログボックスで、[Kubernetes - ファイル] カードを見つけ、[今すぐ収集] をクリックします。[マシングループの構成] を行い、[次へ] をクリックします:
シナリオ:[Kubernetes クラスター] を選択します。
デプロイ方法:[Sidecar] を選択します。
マシングループの選択:[ソースマシングループ] リストで、ステップ 2 で作成したカスタム ID ベースのマシングループを選択し、
をクリックして [適用済みマシングループ] リストに追加します。
[Logtail 構成] ページで、Logtail 収集ルールを構成します。
1. グローバル構成と入力構成
収集構成の名前、ログソース、および収集範囲を定義します。
[グローバル構成]:
[構成名]:収集構成のカスタム名。この名前はプロジェクト内で一意である必要があり、作成後は変更できません。命名規則:
小文字、数字、ハイフン (-)、アンダースコア (_) のみを含めることができます。
小文字または数字で開始および終了する必要があります。
[入力構成]:
[タイプ]:[テキストログ収集]。
Logtail デプロイメントモード: [サイドカー] を選択します。
ファイルパスタイプ:
[コンテナー内のパス]:コンテナー内からログファイルを収集します。
[ホストパス]:ホスト上のローカルサービスからログを収集します。
[ファイルパス]:ログが収集されるパス。
Linux:パスはスラッシュ (/) で始まる必要があります。例えば、
/data/mylogs/**/*.logは/data/mylogsディレクトリ内の .log 拡張子を持つすべてのファイルを指定します。Windows:パスはドライブ文字で始まる必要があります。例えば、
C:\Program Files\Intel\**\*.Log。
[最大ディレクトリ監視深度]:[ファイルパス] のワイルドカード
**が一致できる最大のディレクトリ深度。デフォルト値は 0 で、現在のディレクトリのみを監視することを意味します。
2. ログの処理と構造化
生の非構造化ログを構造化された検索可能なデータに変換するために、ログ処理ルールを構成します。これにより、ログのクエリと分析の効率が向上します。まずサンプルログを追加することを推奨します:
[Logtail 構成] ページの [プロセッサー構成] セクションで、[サンプルログの追加] をクリックし、収集するログコンテンツを入力します。システムはサンプルに基づいてログ形式を識別し、正規表現と解析ルールの生成を支援し、構成を簡素化します。
ユースケース 1:複数行ログの処理 (Java スタックログなど)
Java の例外スタックや JSON オブジェクトなどのログは、しばしば複数行にわたるため、デフォルトの収集モードでは不完全な複数のレコードに分割され、コンテキストが失われます。これを防ぐには、複数行モードを有効にし、先頭行に一致する正規表現を構成して、同じログの連続する行を単一の完全なログにマージします。
例:
未処理の生ログ | デフォルトの収集モードでは、各行が個別のログとなり、スタックトレースが壊れ、コンテキストが失われる | 複数行モードを有効にすると、先頭行に一致する正規表現が完全なログを識別し、その完全な意味構造を保持する |
|
|
|
手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[複数行モード] を有効にします:
[タイプ] には、[カスタム] または [複数行 JSON] を選択します。
[カスタム]:可変形式の生ログの場合、[先頭行に一致する正規表現] を構成して、各ログの開始行を識別します。
[先頭行に一致する正規表現]:完全なデータ行に一致する正規表現を自動生成または手動で入力します。例えば、上記の例の正規表現は
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*です。自動生成:[生成] をクリックします。次に、[ログサンプル] テキストボックスで、抽出したいログコンテンツを選択し、[自動生成] をクリックします。
手動入力:[正規表現の手動入力] をクリックします。式を入力した後、[検証] をクリックします。
[複数行 JSON]:ログが標準の JSON 形式である場合、SLS は単一の生ログ内の改行を自動的に処理します。
[分割失敗時の処理方法]:
[破棄]:行頭ルールに一致しないテキストセグメントを破棄します。
[単一行として保持]:一致しないテキストを別々の行に保持します。
シナリオ 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"';重要ここでのフォーマット定義は、サーバーでログを生成するフォーマットと完全に同じでなければなりません。そうでなければ、ログ解析は失敗します。
一般的な構成パラメーターの説明:以下のパラメーターは複数のデータ解析プラグインに表示され、その機能と使用法は一貫しています。
元のフィールド:解析対象のソースフィールドを指定します。デフォルトは
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 のラベルに関する条件を指定します。
K8s Pod 名正規表現一致:Pod 名で収集対象のコンテナーを指定します。
K8s 名前空間正規表現一致:名前空間名で収集対象のコンテナーを指定します。
K8s コンテナー名正規表現一致:コンテナー名で収集対象のコンテナーを指定します。
コンテナーラベルブラックリスト/ホワイトリスト:指定された条件を満たすラベルを持つコンテナーを収集します。これは Docker シナリオ用であり、Kubernetes シナリオでは推奨されません。
4. ログの分類
複数のアプリケーションやインスタンスが同じログ形式を共有している場合、ログのソースを区別することが困難になることがあります。このコンテキストの欠如は、クエリと分析の効率を低下させます。この問題を解決するために、トピックとログタグを構成して、コンテキストの関連付けと論理的な分類を自動化できます。
トピックの構成
複数のアプリケーションやインスタンスからのログが同じ形式で、パスが異なる場合 (例:/apps/app-A/run.log と /apps/app-B/run.log)、ログのソースを区別することが困難です。マシングループ、カスタム名、またはファイルパス抽出に基づいてトピックを生成し、異なるサービスやパスからのログを柔軟に区別できます。
手順::トピックを生成する方法を選択します。以下の 3 つのタイプがサポートされています:
マシングループトピック:収集構成が複数のマシングループに適用される場合、LoongCollector はサーバーのマシングループ名を
__topic__フィールドとして自動的に使用してアップロードします。これは、ホストごとにログを分割するユースケースに適しています。[カスタム]:
customized://<custom_topic_name>の形式を使用します (例:customized://app-login)。この形式は、固定のビジネス識別子を持つ静的なトピックのユースケースに適しています。ファイルパスからの抽出:ログファイルの完全なパスからキー情報を抽出し、ログソースを動的にマークします。これは、複数のユーザーやアプリケーションが同じログファイル名を共有しているが、パスが異なる状況に適しています。例えば、複数のユーザーやサービスが異なるトップレベルディレクトリにログを書き込むが、サブパスとファイル名が同一である場合、ファイル名だけではソースを区別できません:
/data/logs ├── userA │ └── serviceA │ └── service.log ├── userB │ └── serviceA │ └── service.log └── userC └── serviceA └── service.logファイルパスからの抽出を構成し、正規表現を使用して完全なパスからキー情報を抽出します。一致した結果は、トピックとして Logstore にアップロードされます。
ファイルパス抽出ルール:正規表現のキャプチャグループに基づく
正規表現を構成すると、システムはキャプチャグループの数と命名に基づいて出力フィールドの形式を自動的に決定します。ルールは以下の通りです:
ファイルパスの正規表現では、スラッシュ (/) をエスケープする必要があります。
キャプチャグループのタイプ
ユースケース
生成されるフィールド
正規表現の例
一致するパスの例
生成されるフィールドの例
単一のキャプチャグループ (
(.*?)が 1 つのみ)ソースを区別するために 1 つのディメンションのみが必要 (ユーザー名や環境など)
__topic__フィールドを生成\/logs\/(.*?)\/app\.log/logs/userA/app.log__topic__: userA複数のキャプチャグループ - 名前なし (複数の
(.*?))ソースを区別するために複数のディメンションが必要だが、意味的なタグは不要
タグフィールド
__tag__:__topic_{i}__を生成。ここで{i}はキャプチャグループの序数\/logs\/(.*?)\/(.*?)\/app\.log/logs/userA/svcA/app.log__tag__:__topic_1__userA__tag__:__topic_2__svcA複数のキャプチャグループ - 名前付き (
(?P<name>.*?)を使用)ソースを区別するために複数のディメンションが必要で、クエリや分析を容易にするためにフィールドの意味が明確であるべき
タグフィールド
__tag__:{name}を生成\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log/logs/userA/svcA/app.log__tag__:user:userA;__tag__:service:svcA
ログタギング
ログタギング機能を有効にすると、コンテナーの環境変数や Kubernetes Pod のラベルからキー情報を抽出し、タグとして追加できます。これにより、ログを詳細にグループ化できます。
設定手順: [Logtail 設定] ページの [入力設定] セクションで、[ログタグ拡張] を有効にし、[追加] をクリックします。
[環境変数]:環境変数名とタグ名を設定します。環境変数の値はタグ名に保存されます。
環境変数名:抽出する環境変数の名前を指定します。
タグ名:環境変数タグの名前。
[Pod ラベル]:Pod ラベル名とタグ名を設定します。Pod ラベルの値はタグに保存されます。
Pod ラベル名:抽出する Kubernetes Pod ラベルの名前。
タグ名:タグの名前。
5. 出力構成
デフォルトでは、すべてのログが収集され、lz4 圧縮を使用して現在の Logstore に送信されます。同じソースからのログを異なる Logstore に配信するには、次の手順を実行します:
動的な複数宛先への配信
複数宛先への送信は、LoongCollector 3.0.0 以降にのみ適用されます。Logtail はこの機能をサポートしていません。
最大 5 つの出力先を構成できます。
複数の出力先を構成した後、この収集構成は現在の Logstore の収集構成リストに表示されなくなります。複数宛先配信構成の表示、変更、または削除方法の詳細については、「複数宛先配信構成を管理するにはどうすればよいですか?」をご参照ください。
設定手順: [Logtail 設定] ページの [出力設定] エリア。
をクリックして出力構成を展開します。[出力ターゲットの追加] をクリックし、以下の構成を完了します:
[Logstore]:ターゲットの Logstore を選択します。
圧縮方法: [lz4] と [zstd] をサポートします。
[ルーティング構成]:タグフィールドに基づいてログをルーティングします。ルーティング構成に一致するログは、ターゲットの Logstore にアップロードされます。ルーティング構成が空の場合、収集されたすべてのログがターゲットの 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_
コンテナーが使用するイメージの名前。
説明同じハッシュを持つが名前やタグが異なる複数のイメージがある場合、収集構成はハッシュに基づいて名前の 1 つを選択して収集します。選択された名前が YAML ファイルで定義されたものと一致することは保証されません。
__tag__:_pod_name_
Pod の名前。
__tag__:_namespace_
Pod が属する名前空間。
__tag__:_pod_uid_
Pod の一意の識別子 (UID)。
ログ収集の完全性を確保するための主要な構成上の注意点
ログ収集の完全性を確保することは、LoongCollector Sidecar デプロイメントの核となる目標です。以下の構成パラメーターは、ログデータの完全性と信頼性に直接影響します。
LoongCollector のリソース構成
大量のデータが発生するシナリオでは、クライアント側での収集パフォーマンスを確保するために、合理的なリソース構成が基本となります。主要な構成パラメーターは次のとおりです:
# ログ生成レートに基づいて CPU とメモリリソースを構成
resources:
limits:
cpu: "2000m"
memory: "2Gi"
# 収集パフォーマンスに影響するパラメーター
env:
- name: cpu_usage_limit
value: "2"
- name: mem_usage_limit
value: "2048"
- name: max_bytes_per_sec
value: "209715200"
- name: process_thread_count
value: "8"
- name: send_request_concurrency
value: "20"
特定のデータ量と対応する構成の関係についての詳細情報は、「Logtail のネットワークタイプ、起動パラメーター、および構成ファイル」をご参照ください。
サーバー側のクォータ構成
サーバー側のクォータ制限やネットワーク異常は、クライアント側のデータ送信を妨げ、ファイル収集側にバックプレッシャーを生じさせ、ログの完全性に影響を与える可能性があります。CloudLens for SLS を使用してプロジェクトのリソースクォータを監視することを推奨します。
初期収集構成の最適化
Pod 起動時の初期ファイル収集ポリシーは、特に高速なデータ書き込みシナリオにおいて、データの完全性に直接影響します。
初期収集サイズを構成することで、新しいファイルからの最初の収集の開始位置を指定できます。デフォルトの初期収集サイズは 1024 KB です。
最初の収集時に、ファイルが 1024 KB 未満の場合、収集はファイルの先頭から開始されます。
最初の収集時に、ファイルが 1024 KB より大きい場合、収集はファイルの末尾から 1024 KB の位置から開始されます。
初期収集サイズは 0 から 10,485,760 KB の範囲で設定できます。
enable_full_drain_mode
これはデータ整合性を確保するための重要なパラメーターです。LoongCollector が SIGTERM シグナルを受信したときに、すべてのデータ収集と送信を完了することを保証します。
# 収集の完全性に影響するパラメーター
env:
- name: enable_full_drain_mode
value: "true" # フルドレインモードを有効化
よくある質問
複数宛先配信構成を管理するにはどうすればよいですか?
複数宛先配信構成は複数の Logstore に関連付けられているため、プロジェクトレベルの管理ページで維持する必要があります:
Simple Log Service コンソールにログインし、対象のプロジェクト名をクリックします。
対象のプロジェクトページで、左側のナビゲーションウィンドウの
を選択します。説明このページでは、誤って Logstore が削除された後に残ったものを含め、プロジェクト下のすべての収集構成を一元管理します。
次のステップ
データの可視化:可視化ダッシュボードを使用して、主要なメトリックのトレンドを監視します。
データ異常の自動アラート:アラートポリシーを設定して、システムの異常をリアルタイムで検出します。
Simple Log Service は増分ログのみを収集します。履歴ログを収集するには、「履歴ログファイルのインポート」をご参照ください。
付録:YAML の例
この例は、アプリケーションコンテナー (Nginx) と LoongCollector Sidecar コンテナーを含む完全な Kubernetes Deployment 構成を示しています。Sidecar モードを使用してコンテナーログを収集するのに適しています。
開始する前に、次の 3 つの主要な置き換えを行ってください:
${your_aliyun_user_id}をご利用の Alibaba Cloud アカウントの UID に置き換えます。${your_machine_group_user_defined_id}をステップ 3 で作成したマシングループのカスタム ID に置き換えます。カスタム ID は完全に一致する必要があります。${your_region_config}を Simple Log Service プロジェクトのリージョンとネットワークタイプに一致する構成名に置き換えます。例:プロジェクトが中国 (杭州) にあり、内部ネットワークアクセスを使用する場合、値を
cn-hangzhouに設定します。パブリックネットワークアクセスを使用する場合、値をcn-hangzhou-internetに設定します。
短期タスク (Job/CronJob)
apiVersion: batch/v1
kind: Job
metadata:
name: demo-job
spec:
backoffLimit: 3
activeDeadlineSeconds: 3600
completions: 1
parallelism: 1
template:
spec:
restartPolicy: Never
terminationGracePeriodSeconds: 300
containers:
# アプリケーションコンテナー
- name: demo-job
image: debian:bookworm-slim
command: ["/bin/bash", "-c"]
args:
- |
# LoongCollector の準備が完了するまで待機
echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] Business: LoongCollector is ready, starting business logic"
# ビジネスロジックを実行
echo "Hello, World!" >> /app/logs/business.log
# 終了コードを保存
retcode=$?
echo "[$(date)] Business: Task completed with exit code: $retcode"
# ビジネスタスクが完了したことを LoongCollector に通知
touch /tasksite/tombstone
echo "[$(date)] Business: Tombstone created, exiting"
exit $retcode
# リソース制限
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500"
memory: "512Mi"
# ボリュームマウント
volumeMounts:
- name: app-logs
mountPath: /app/logs
- name: tasksite
mountPath: /tasksite
# LoongCollector Sidecar コンテナー
- name: loongcollector
image: aliyun-observability-release-registry.cn-hongkong.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
command: ["/bin/bash", "-c"]
args:
- |
echo "[$(date)] LoongCollector: Starting initialization"
# LoongCollector サービスを開始
/etc/init.d/loongcollectord start
# 構成のダウンロードとサービスの準備が完了するまで待機
sleep 15
# サービスステータスを確認
if /etc/init.d/loongcollectord status; then
echo "[$(date)] LoongCollector: Service started successfully"
touch /tasksite/cornerstone
else
echo "[$(date)] LoongCollector: Failed to start service"
exit 1
fi
# アプリケーションコンテナーの完了を待機
echo "[$(date)] LoongCollector: Waiting for business container to complete"
until [[ -f /tasksite/tombstone ]]; do
sleep 2
done
echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
# 残りのログを送信するのに十分な時間を確保
sleep 30
echo "[$(date)] LoongCollector: Stopping service"
/etc/init.d/loongcollectord stop
echo "[$(date)] LoongCollector: Shutdown complete"
# ヘルスチェック
livenessProbe:
exec:
command: ["/etc/init.d/loongcollectord", "status"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# リソース構成
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
# 環境変数構成
env:
- name: ALIYUN_LOGTAIL_USER_ID
value: "your-user-id"
- name: ALIYUN_LOGTAIL_USER_DEFINED_ID
value: "your-user-defined-id"
- name: ALIYUN_LOGTAIL_CONFIG
value: "/etc/ilogtail/conf/cn-hongkong/ilogtail_config.json"
- name: ALIYUN_LOG_ENV_TAGS
value: "_pod_name_|_pod_ip_|_namespace_|_node_name_"
# Pod 情報のインジェクション
- name: "_pod_name_"
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: "_pod_ip_"
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: "_namespace_"
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: "_node_name_"
valueFrom:
fieldRef:
fieldPath: spec.nodeName
# ボリュームマウント
volumeMounts:
- name: app-logs
mountPath: /app/logs
readOnly: true
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# ボリューム定義
volumes:
- name: app-logs
emptyDir: {}
- name: tasksite
emptyDir:
medium: Memory
sizeLimit: "10Mi"
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
長期サービス (Deployment / StatefulSet)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-demo
namespace: production
labels:
app: nginx-demo
version: v1.0.0
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
version: v1.0.0
spec:
terminationGracePeriodSeconds: 600 # 10 分間のグレースフルシャットダウン期間
containers:
# アプリケーションコンテナー - Web アプリケーション
- name: nginx-demo
image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
# 起動コマンドとシグナル処理
command: ["/bin/sh", "-c"]
args:
- |
# シグナルハンドラ関数を定義
_term_handler() {
echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
# グレースフルストップのために Nginx に QUIT シグナルを送信
if [ -n "$NGINX_PID" ]; then
kill -QUIT "$NGINX_PID" 2>/dev/null || true
echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
# Nginx がグレースフルに停止するのを待機
wait "$NGINX_PID"
EXIT_CODE=$?
echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
fi
# アプリケーションコンテナーが停止したことを LoongCollector に通知
echo "[$(date)] [nginx-demo] Writing tombstone file"
touch /tasksite/tombstone
exit $EXIT_CODE
}
# シグナルハンドラを登録
trap _term_handler SIGTERM SIGINT SIGQUIT
# LoongCollector の準備が完了するまで待機
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
# Nginx を開始
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
# Nginx プロセスを待機
wait $NGINX_PID
EXIT_CODE=$?
# シグナルが原因でない終了の場合も LoongCollector に通知
if [ ! -f /tasksite/tombstone ]; then
echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
touch /tasksite/tombstone
fi
exit $EXIT_CODE
# リソース構成
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "1000m"
memory: "1Gi"
# ボリュームマウント
volumeMounts:
- name: nginx-logs
mountPath: /var/log/nginx
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# LoongCollector Sidecar コンテナー
- name: loongcollector
image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
command: ["/bin/bash", "-c"]
args:
- |
echo "[$(date)] LoongCollector: Starting initialization"
# LoongCollector サービスを開始
/etc/init.d/loongcollectord start
# 構成のダウンロードとサービスの準備が完了するまで待機
sleep 15
# サービスステータスを確認
if /etc/init.d/loongcollectord status; then
echo "[$(date)] LoongCollector: Service started successfully"
touch /tasksite/cornerstone
else
echo "[$(date)] LoongCollector: Failed to start service"
exit 1
fi
# アプリケーションコンテナーの完了を待機
echo "[$(date)] LoongCollector: Waiting for business container to complete"
until [[ -f /tasksite/tombstone ]]; do
sleep 2
done
echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
# 残りのログを送信するのに十分な時間を確保
sleep 30
echo "[$(date)] LoongCollector: Stopping service"
/etc/init.d/loongcollectord stop
echo "[$(date)] LoongCollector: Shutdown complete"
# ヘルスチェック
livenessProbe:
exec:
command: ["/etc/init.d/loongcollectord", "status"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# リソース構成
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "2000m"
memory: "2048Mi"
# 環境変数構成
env:
- name: ALIYUN_LOGTAIL_USER_ID
value: "${your_aliyun_user_id}"
- name: ALIYUN_LOGTAIL_USER_DEFINED_ID
value: "${your_machine_group_user_defined_id}"
- name: ALIYUN_LOGTAIL_CONFIG
value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
# Pod 停止時にすべてのログが送信されるようにフルドレインモードを有効化
- name: enable_full_drain_mode
value: "true"
# Pod 環境コンテキストをログタグとして追加
- name: "ALIYUN_LOG_ENV_TAGS"
value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
# Pod とノードの情報を取得
- name: "_pod_name_"
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: "_pod_ip_"
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: "_namespace_"
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: "_node_name_"
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: "_node_ip_"
valueFrom:
fieldRef:
fieldPath: status.hostIP
# ボリュームマウント
volumeMounts:
- name: nginx-logs
mountPath: /var/log/nginx
readOnly: true
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# ボリューム定義
volumes:
- name: nginx-logs
emptyDir: {}
- name: tasksite
emptyDir:
medium: Memory
sizeLimit: "50Mi"
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
付録:ネイティブ解析プラグインの詳細
[Logtail 構成] ページの [プロセッサー構成] セクションで、プロセッサーを追加して生ログを構造化します。既存の収集構成に処理プラグインを追加するには、次の手順に従います:
左側のナビゲーションウィンドウで、
[Logstores] を選択し、ターゲットの Logstore を見つけます。その名前の前にある
アイコンをクリックして Logstore を展開します。[Logtail 構成] をクリックします。構成リストで、ターゲットの Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。
Logtail 構成ページで、[編集] をクリックします。
このセクションでは、一般的なログ処理のユースケースをカバーする、一般的に使用される処理プラグインのみを紹介します。その他の機能については、「拡張プロセッサー」をご参照ください。
プラグインの組み合わせルール (LoongCollector / Logtail 2.0 以降):
ネイティブプロセッサーと拡張プロセッサーは、独立して使用することも、必要に応じて組み合わせることもできます。
ネイティブプロセッサーはパフォーマンスと安定性が高いため、優先的に使用してください。
ネイティブ機能がビジネスニーズを満たせない場合は、構成済みのネイティブプロセッサーの後に拡張プロセッサーを追加して補足的な処理を行います。
順序の制約:
すべてのプラグインは構成された順序で順次実行され、処理チェーンを形成します。注意:すべてのネイティブプロセッサーは、どの拡張プロセッサーよりも前に配置する必要があります。拡張プロセッサーを追加した後は、さらにネイティブプロセッサーを追加することはできません。
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析できます。各フィールドは独立してクエリおよび分析できます。
例:
未処理の生ログ | 正規表現解析プラグインの使用 |
| |
構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
[正規表現]:ログに一致させるために使用します。自動生成または手動で入力できます:
自動生成:
[正規表現の自動生成] をクリックします。
[ログサンプル] で、抽出したいログコンテンツを選択します。
[正規表現の生成] をクリックします。

手動入力:ログ形式に基づいて [正規表現の手動入力] を行います。
式を構成した後、[検証] をクリックして、正規表現がログコンテンツを正しく解析できるかテストします。
[抽出されたフィールド]:抽出されたログコンテンツ (値) に対応するフィールド名 (キー) を設定します。
その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。
デリミタベースの解析
デリミタを使用してログコンテンツを構造化し、複数のキーと値のペアに解析できます。単一文字および複数文字のデリミタの両方がサポートされています。
例:
未処理の生ログ | 指定された文字 |
| |
構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
[デリミタ]:ログコンテンツを分割するために使用する文字を指定します。
例:CSV ファイルの場合、[カスタム] を選択し、カンマ (,) を入力します。
[引用符]:フィールド値にセパレータが含まれている場合、誤った分割を避けるためにフィールドを囲む引用符を指定する必要があります。
[抽出されたフィールド]:分割された順序で各列にフィールド名 (キー) を設定します。以下のルールが適用されます:
フィールド名には文字、数字、アンダースコア (_) のみを含めることができます。
名前は文字またはアンダースコア (_) で始まる必要があります。
最大長は 128 バイトです。
その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。
標準 JSON 解析
オブジェクトタイプの JSON ログをキーと値のペアに解析して構造化できます。
例:
未処理の生ログ | 標準 JSON キーと値のペアの自動抽出 |
| |
構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
[元のフィールド]:デフォルト値は `content` です。このフィールドは、解析対象の生ログコンテンツを保存するために使用されます。
その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。
ネストされた JSON 解析
展開深度を指定することで、ネストされた JSON ログをキーと値のペアに解析できます。
例:
未処理の生ログ | 展開深度:0、展開深度をプレフィックスとして使用 | 展開深度:1、展開深度をプレフィックスとして使用 |
| | |
構成手順:[Logtail 構成] ページの [プロセッサー構成] セクションで、[プロセッサーの追加] をクリックし、 を選択します:
[元のフィールド]:展開対象の元のフィールド名 (例:
content)。[JSON 展開深度]:JSON オブジェクトの展開レベル。値 0 はオブジェクトが完全に展開されることを示し、これがデフォルトです。値 1 は現在のレベルのみが展開されることを示します。
[展開されたキーを連結する文字]:JSON 展開中にフィールド名を連結するために使用される文字。デフォルトはアンダースコア (_) です。
[JSON 展開プレフィックス]:JSON 展開後のフィールド名にプレフィックスを指定します。
[配列の展開]:このオプションを有効にすると、配列がインデックス付きのキーと値のペアに展開されます。
例:
{"k":["a","b"]}は{"k[0]":"a","k[1]":"b"}に展開されます。展開されたフィールドの名前を変更する場合 (例:prefix_s_key_k1 を new_field_name に変更)、[フィールド名の変更] プラグインを追加してマッピングを完了できます。
その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。
JSON 配列解析
json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。
例:
未処理の生ログ | JSON 配列構造の抽出 |
| |
手順: [Logtail 設定] ページの [プロセッサ設定] セクションで、[処理モード] を [SPL] に切り替え、[SPL ステートメント] を設定し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。
例:ログフィールド content の JSON 配列から要素を抽出し、結果を新しいフィールド json1 および json2 に保存します。
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')Apache ログ解析
Apache ログ構成ファイルの定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析できます。
例:
未処理の生ログ | Apache Common Log Format |
| |
構成手順:[Logtail 構成] ページの [処理構成] セクションで、[処理プラグインの追加] をクリックし、 を選択します:
ログフォーマット: combined
[Apache 構成フィールド]:システムは [ログフォーマット] に基づいて構成を自動的に入力します。
重要自動入力されたコンテンツが、サーバー上の Apache 構成ファイルで定義された LogFormat と完全に同じであることを確認してください。ファイルは通常 /etc/apache2/apache2.conf にあります。
その他のパラメーターの詳細については、「シナリオ 2:構造化ログ」の一般的な構成パラメーターの説明をご参照ください。
データマスキング
ログ内の機密データをマスキングします。
例:
未処理の生ログ | マスキング結果 |
| |
手順: [Logtail 設定] ページの [プロセッサ設定] セクションで、[プロセッサの追加] をクリックし、 を選択します:
時刻解析
ログ内の時刻フィールドを解析し、解析結果をログの __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) モードを選択して互換性を確認できます。サポートされていない構文を使用すると、プラグインは正しく解析またはマッチングを行いません。
> [マシングループの作成]


