Simple Log Service:Kubernetes コンテナログの収集

機能

SLS は、Kubernetes コンテナログ収集のために以下の機能を提供します。

• 複数ソースのログに対応

  • さまざまなログタイプの収集：標準出力、標準エラー、コンテナのテキストファイルログ。

• 詳細なコンテナフィルタリング

  • 名前空間名、Pod 名、コンテナ名、コンテナラベル、または環境変数に基づいてコンテナを包含または除外できます。

• 高度なログ処理

  • 複数行ログの収集：Java のスタックトレースなどの複数行エントリを単一のログイベントにマージします。

  • ログの前処理：データフィルタリングプラグインで無効なデータを破棄するか、データマスキングおよび暗号化プラグインとフィールド処理プラグインで機密データをマスキングおよび構造化します。

  • フィールドの解析：データ解析プラグインを使用して、保存前に生ログを構造化します。

• インテリジェントなメタデータ関連付け

  • コンテナ名、イメージ、Pod、名前空間、環境変数などのメタデータをコンテナログに自動的に関連付けます。

• 信頼性

  • チェックポイント メカニズムは、現在の収集位置を記録して、ログの完全性を確保します。

  • さまざまなコンテナランタイムに合わせた戦略で、コンテナ停止時のログを処理します。

制限事項

• コンテナランタイム：Docker と Containerd のみをサポートしています。

  Docker：

  • docker.sock へのアクセス権限が必要です。

  • 標準出力の収集では、json-file ロギングドライバーのみをサポートしています。

  • overlay および overlay2 ストレージドライバーのみをサポートしています。 他のストレージドライバーの場合、ボリュームを使用してログディレクトリをマウントする必要があります。

  Containerd：

  • containerd.sock へのアクセス権限が必要です。

• 複数行ログの制限：

  複数行ログが出力遅延によって分割されるのを防ぐため、最後に収集された行をデフォルトで 3 秒間バッファリングします。 これを調整するには、BeginLineTimeoutMs パラメーターを使用します (最小値：1,000 ms)。

• 標準出力：

  デフォルトの最大ログエントリサイズは 512 KB (524,288 バイト) で、上限は 8 MB (8,388,608 バイト) です。 この制限を増やすには、LoongCollector コンテナで max_read_buffer_size 環境変数を設定します。

  重要

  標準出力と標準エラーの収集を同時に有効にしないでください。 ログエントリが誤ってインターリーブされる可能性があります。

収集ワークフローの概要

1. ログソースの準備：収集する標準出力またはテキストファイルログを特定します。

2. LoongCollector のインストール：コレクターをデプロイして、ログを SLS に送信します。

3. 収集ルールの設定：ログ収集ルールと解析プラグインを定義します。

4. ログのクエリと分析：収集したログデータを使用してサービスを監視します。

主要なプロセス

ログソースとマウントポイントの要件

• 標準出力ログの場合、LoongCollector はコンテナメタデータに基づいてログファイルパスを自動的に検出します。

• コンテナ内のテキストファイルログの場合、LoongCollector はデフォルトでホストのルートディレクトリを /logtail_host にマウントします。 通常、手動でのマウントは不要です。 カスタムマウントポイントを使用する場合は、次の要件を満たしていることを確認してください。

  カスタムマウントポイントの要件

  ログファイルパス：

  • シンボリックリンクを使用しないでください。

    • 誤った設定：/var/log -> /mnt/logs。

    • 正しい設定：物理パス /mnt/logs を直接使用します。

  • マウントパスの一致ルール：アプリケーションコンテナのデータディレクトリがボリュームを使用してマウントされている場合、収集パスはマウントポイントと同じか、そのサブディレクトリである必要があります。

    1マウントポイント：/var/log/service
    2✅ 有効な収集パス：/var/log/service または /var/log/service/subdir
    3❌ 無効な収集パス：/var/log (パスの指定が不十分です)

コレクターのインストール

LoongCollector は、2つのデプロイモードをサポートしています。

デプロイモード：DaemonSet またはサイドカー。

• DaemonSet モード：各ノードに LoongCollector エージェントを自動的にデプロイします。 ほとんどのシナリオに適しています。

  • DaemonSet モードでは、デプロイ方法はクラスターのタイプと SLS アカウントの関係によって異なります。

    • ACK クラスターの場合、loongcollector-ds コンポーネントが事前に統合されています。 ACK コンソールで有効にすると、インストールが完了します。 デフォルトでは、ログはクラスターを所有するアカウントの SLS プロジェクトに保存されます。 インストールと設定。

    • ACK クラスターのログを別の Alibaba Cloud アカウントの SLS プロジェクトに収集するには、LoongCollector を手動でインストールし、宛先アカウントの ID または AccessKey で設定します。 インストールと設定。

    • セルフマネージドクラスターの場合、LoongCollector を手動でインストールし、宛先の Alibaba Cloud アカウントの ID または AccessKey で設定します。 インストールと設定。

    ログ収集を開始する前に、LoongCollector をインストールする必要があります。 CRD (標準出力/ファイル) を使用した Kubernetes クラスターからのコンテナログの収集。

• サイドカーモード：各アプリケーション Pod に LoongCollector コンテナを挿入します。 このモードは、サーバーレスコンテナ、DaemonSet の容量を超える大量の Pod、またはセキュアなコンテナランタイムを持つクラスターで使用します。 Kubernetes Pod テキストログの収集 (サイドカーモード)。

収集ルール

SLS は、収集ルールを定義するための2つの方法をサポートしています。

基本概念

• Kubernetes：コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。

• 標準出力、標準エラー、テキストファイルログ：標準出力は通常のプログラム出力 (ビジネスログ、運用記録) をキャプチャします。 標準エラーはエラーと警告 (スタックトレース、起動失敗) をキャプチャします。 どちらもターミナルに送られ、コンテナエンジンによってキャプチャされます。 コンテナのテキストファイルログは、アプリケーションによってファイルに書き込まれ (例：Nginx の access.log)、ボリュームで永続化されない限り、コンテナが破棄されると削除されます。

• チェックポイントメカニズム：収集位置をファイルに記録し、デフォルトで /tmp/logtail_checkpoint に保存されます。 LoongCollector の再起動やノードの障害後も、信頼性の高い収集を確保します。

• LoongCollector (Logtail)：Alibaba Cloud が開発した高性能なログコレクターで、Kubernetes での DaemonSet およびサイドカーデプロイをサポートしています。 LoongCollector は Logtail の後継であり、完全な下位互換性があります。

• Kubernetes CRD：設定用のカスタムリソースを定義できる CustomResourceDefinition です。 SLS は、CRD タイプとして AliyunPipelineConfig を使用します。

• 収集設定：ログタイプ、収集パス、フィルタリング、解析、保存場所のルールを定義します。 収集設定とは。

• 解析プラグイン：ログコンテンツの構造化、分割、フィルタリング、またはマスキングのための処理プラグイン設定内の処理ユニットです。 正規表現、セパレーター、JSON、複数行モードをサポートしています。

仕組み

1. ユーザーは kubectl を使用してカスタムリソース (CR) を作成し、収集ルールを定義します。

2. loongcollector-operator は、クラスター内の CR への変更を継続的に監視します。

3. 変更が検出されると、Operator は CR を LoongCollector 設定に変換し、Simple Log Service に適用します。

4. LoongCollector エージェントは、定期的に Simple Log Service にハートビートを送信して設定の更新を取得し、最新の収集設定をプルして動的に適用します。

5. loongcollector-ds エージェントは、新しい設定に従ってログを収集し、設定されたエンドポイントを通じて SLS に送信します。

DaemonSet モード

各ノードに LoongCollector エージェントをデプロイして、そのノード上のすべてのコンテナからログを収集します。 簡単な操作、低いリソース消費、柔軟な設定といった利点がありますが、テナント分離の点では弱くなります。

DaemonSet モードの仕組み

• DaemonSet モードでは、Kubernetes は各ノードで LoongCollector コンテナを 1 つだけ実行し、そのノード上のすべてのコンテナからログを収集します。

• Kubernetes は、ノードがクラスターに参加したり離脱したりすると、LoongCollector コンテナを自動的に作成および破棄するため、手動でのインスタンス管理が不要になります。

サイドカーモード

各 Pod のアプリケーションコンテナの横に LoongCollector サイドカーを挿入します。 アプリケーションのログディレクトリは、Kubernetes ボリューム (emptyDir、hostPath、または PVC) を介して共有され、LoongCollector がログファイルを直接読み取ることができます。 強力なテナント分離と高性能を実現しますが、より多くのリソースを消費します。

サイドカーモードの仕組み

• サイドカーモードでは、各 Pod は専用の LoongCollector コンテナを実行します。 ログ収集は Pod 間で分離されます。

• ログファイルにアクセスするには、共有ボリュームをアプリケーションコンテナと LoongCollector コンテナの両方にマウントする必要があります。

• Pod のログ量が DaemonSet の容量を超えた場合、サイドカーモードでは専用のリソースを LoongCollector に割り当てることができます。

• サーバーレス環境にはノードがないため、DaemonSet は適用できません。 サイドカーモードは、サーバーレスアーキテクチャと直接統合します。

コンテナ検出

LoongCollector は、ログを収集する前に、ノード上で実行されているコンテナを識別する必要があります。 このプロセスはコンテナ検出と呼ばれます。

• LoongCollector は、クラスターの kube-apiserver ではなく、ノード上のコンテナランタイムデーモンと直接通信します。 これにより、kube-apiserver への余分な負荷を回避できます。

• LoongCollector は、ホスト上のコンテナランタイムソケット (Docker または Containerd) にアクセスします。 名前空間、Pod 名、Pod ラベル、または環境変数によるコンテナの包含または除外をサポートしています。

標準出力の収集

LoongCollector は、メタデータに基づいて、各コンテナランタイム (Docker、Containerd) に適した API またはロギングドライバーを自動的に識別します。 コンテナのファイルシステムにアクセスすることなく、標準出力ストリームを直接読み取ります。

コンテナのテキストファイルログの収集

• Kubernetes はコンテナのファイルシステムを分離するため、コレクターは他のコンテナ内のファイルに直接アクセスできません。 LoongCollector は、ホストのルートファイルシステムをマウントして、アプリケーションコンテナ内のファイルに間接的にアクセスします。

• デフォルトでは、ホストのルートファイルシステムは /logtail_host にマウントされます。 通常、手動でのマウントは不要です。 たとえば、コンテナログファイルが /log/app.log にあり、そのホストパスが /var/lib/docker/containers/<container-id>/log/app.log である場合、LoongCollector は /logtail_host/var/lib/docker/containers/<container-id>/log/app.log からそれを読み取ります。

複数行ログの解析

LoongCollector は、ユーザー定義の正規表現を使用してログ行の先頭と照合します。

• 一致成功：その行は新しいログエントリの開始として扱います。

• 一致失敗：その行は現在のログエントリに追加します。

別の行が行頭の正規表現に一致すると、現在のログエントリが完了し、新しいエントリが開始されます。

コンテナ停止時のログ処理

Pod が削除された後、Simple Log Service の LogStore に既に収集されているログは影響を受けません。 ログは LogStore の データ保持期間 中保持され、その期間内はクエリ可能です。 保持期間は Simple Log Service コンソールで変更できます。

Pod が削除された後、ラベルベースまたは名前空間ベースの収集設定は、同じラベルを持つ新しい Pod に自動的に適用されます。 Deployment のローリングアップデートで古い Pod が削除され、新しい Pod が作成されると、Simple Log Service は新しい Pod から自動的にログを収集し、収集ルールを再設定する必要はありません。

コンテナメタデータの取得

LoongCollector は、CRI (Container Runtime Interface) API を介して Kubernetes メタデータを直接取得し、収集中に非侵入的でリアルタイムのメタデータタギングを可能にします。

• Docker：LoongCollector は Docker Client を使用して Docker Daemon と通信し、メタデータを取得します。 主な API は次のとおりです。

  • ContainerList：ノードで実行中のコンテナを一覧表示します。

  • ContainerInspect：詳細なコンテナ設定とステータスを返します。

  • Events：コンテナのライフサイクルイベントをリアルタイムでリッスンします。

  Docker Client を介して取得される主要なメタデータフィールド：

  • LogPath：コンテナの標準出力ログファイルのホストパス。

  • GraphDriver.Data：コンテナの rootfs のホストパス。ファイルシステムへのアクセスとトラブルシューティングに使用されます。

• Containerd：LoongCollector は CRI を使用して containerd および CRI-O 環境をサポートし、runc や Kata Containers などの基盤となるランタイムからメタデータを収集します。

  • CRI は標準出力ログファイルのホストパスを提供しますが、コンテナの rootfs パスは提供しません。 LoongCollector は次の方法でこのパスを特定します。

    • ファイルパス検索：コンテナ ID を使用して、ホストファイルシステムでコンテナの rootfs パスを検索します。

    • containerd との直接対話：LoongCollector は CRI をバイパスし、containerd と直接通信して、CRI を介して利用できない rootfs パスやその他のメタデータを取得できます。