Simple Log Service:Kubernetes クラスターからコンテナログを収集するためのガイドライン

特徴

Simple Log Service は、Kubernetes コンテナログ収集のために以下の主要な機能を提供します。

• 複数のログソース

  • ログタイプ：標準出力 (stdout)、標準エラー (stderr)、およびコンテナのテキストファイルログ。

• きめ細かなコンテナフィルタリング

  • 名前空間、Pod 名、コンテナ名、コンテナのラベル、または環境変数に基づいて、収集対象のコンテナを指定または除外します。

• 複雑なログ処理

  • 複数行ログの収集：Java の例外スタックトレースなど、複数行にまたがるログエントリを認識し、単一のログイベントとして処理します。これにより、ログが改行によって誤って分割されるのを防ぎます。

  • ログの前処理：フィルタープラグインなどのプラグインを使用して、コレクター側で無効なデータをフィルタリングします。ログマスキングやフィールド抽出プラグインを使用して、生ログが公開されるのを防ぎます。

  • フィールドの解析と構造化：正規表現、JSON、または区切り文字用の解析プラグインを使用して、保存前に生ログを解析します。

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

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

• 信頼性の保証

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

  • SLS は、コンテナランタイムに基づいてコンテナ停止時のログを処理するためのさまざまな戦略を提供します。

制限事項

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

  Docker：

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

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

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

  Containerd：

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

• 複数行ログの制限：

  出力の遅延によって複数行のログエントリが分割されるのを防ぐため、最後に収集されたログ行は指定された期間キャッシュされます。デフォルトのキャッシュ時間は 3 秒です。この時間は BeginLineTimeoutMs パラメーターを使用して変更できます。誤った分割を防ぐため、値は 1000 ミリ秒以上である必要があります。

• 標準出力：

  単一ログエントリの最大サイズ：デフォルトは 524288 バイト (512 KB) で、最大は 8388608 バイト (8 MB) です。単一のログエントリが 524288 バイトを超える場合は、LoongCollector コンテナに max_read_buffer_size 環境変数を追加することで制限を変更できます。

  重要

  標準出力と標準エラーを同時に有効にしないでください。ログ収集の順序が乱れる原因となります。

収集プロセスの概要

1. クラスターへのログインとログソースの準備：収集対象の標準出力ログまたはテキストファイルログを準備します。

2. LoongCollector コレクターのインストール：SLS がログの収集と転送に使用する LoongCollector をインストールします。

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 (パスが短すぎます)

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

シナリオに基づいてデプロイモードを選択します。

デプロイモード：SLS は、DaemonSet または Sidecar モードでの LoongCollector のインストールをサポートしています。

• DaemonSet デプロイモード：一度設定するだけで、クラスター内の各ノードに LoongCollector が自動的にデプロイされます。これは、ほとんどのシナリオで推奨されるモードです。

  • DaemonSet モードを使用する場合、クラスターと SLS の関係に基づいてデプロイ方法を選択します。

    • Container Service for Kubernetes (ACK) クラスターを使用する場合、loongcollector-ds コンポーネントはすでに統合されています。インストールを完了するには、ACK コンソールでコンポーネントを有効にします。デフォルトでは、この方法はコレクターを ACK クラスターを所有する Alibaba Cloud アカウントにバインドし、そのアカウントの SLS インスタンスにログを保存します。詳細については、「LoongCollector のインストール (Kubernetes)」をご参照ください。

    • ACK クラスターを使用しているが、組織構造、権限の分離、または統合監視などの理由で、別の Alibaba Cloud アカウントに属する SLS プロジェクトにログを収集する必要がある場合は、LoongCollector コンポーネントを手動でインストールする必要があります。その後、宛先アカウントの ID またはアクセス認証情報 (AccessKey) をコンポーネントに設定して関連付けを確立します。詳細については、「LoongCollector のインストール (Kubernetes)」をご参照ください。

    • セルフマネージドクラスターを使用する場合、LoongCollector コンポーネントを手動でインストールする必要があります。その後、宛先アカウントの ID またはアクセス認証情報 (AccessKey) をコンポーネントに設定して関連付けを確立します。詳細については、「LoongCollector のインストール (Kubernetes)」をご参照ください。

    LoongCollector のインストールはログ収集の前提条件です。LoongCollector のインストールを含む完全な収集プロセスについては、「CRD を使用して Kubernetes クラスターからコンテナログを収集する (標準出力/ファイル)」をご参照ください。

• Sidecar デプロイモード：LoongCollector の Sidecar コンテナが、アプリケーションコンテナと一緒に各 Pod に注入されます。このモードは、デプロイと運用保守 (O&M) がより複雑になります。このモードは、サーバーレスコンテナのログ収集、単一ノード上の Pod のデータ量が DaemonSet の収集制限を超える場合、またはセキュアコンテナランタイムを持つ Kubernetes からのログ収集に使用します。詳細については、「Kubernetes Pod からテキストログを収集する (Sidecar モード)」をご参照ください。

収集ルールの設定

SLS は、収集設定ルールを定義するための 2 つの方法を提供します。

基本概念

• Kubernetes：Kubernetes (K8s) は、オープンソースのコンテナオーケストレーションプラットフォームです。コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化します。現代のクラウドネイティブアプリケーション開発および運用保守 (O&M) の中核となるインフラストラクチャです。

• 標準出力、標準エラー、テキストファイルログ：標準出力 (stdout) は、ビジネスログや操作記録など、プログラムが通常の操作中に表示する情報です。デフォルトでターミナルに出力され、コンテナエンジンによってキャプチャされて保存されます。標準エラー (stderr) は、例外スタックトレースや起動失敗の理由など、プログラムからのエラーまたは警告情報です。これもコンテナエンジンによってキャプチャされ、stdout と混在することがあります。テキストファイルログは、Nginx の access.log やカスタムログファイルなど、アプリケーションがファイルに書き込むログです。これらのログはコンテナの内部ファイルシステムに直接書き込まれ、コンテナが破棄されると破棄されます。永続化のためにボリュームを使用できます。

• チェックポイントメカニズム：チェックポイントは、ファイル内の最後に収集された位置を記録します。デフォルトでは、チェックポイントは /tmp/logtail_checkpoint に保存されます。このメカニズムは、LoongCollector の再起動やノード障害が発生した場合のログ収集の信頼性を保証します。

• LoongCollector (Logtail)：Alibaba Cloud が開発したハイパフォーマンスなログコレクターです。Kubernetes での DaemonSet および Sidecar デプロイモードをサポートしています。LoongCollector は Logtail のアップグレード版であり、すべての Logtail 機能と互換性があります。

• Kubernetes CRD：カスタムリソース定義 (CRD) は、ユーザーがカスタムリソースを定義し、設定用のインスタンスを作成できる Kubernetes のメカニズムです。SLS が提供するカスタムリソースタイプは AliyunPipelineConfig です。

• 収集設定：ログタイプ、収集パス、ログフィルタリング、コンテンツ解析、Simple Log Service での保存場所など、ログ収集のルールを定義します。詳細については、「LoongCollector 収集設定とは」をご参照ください。

• 解析プラグイン：収集設定のプロセッサープラグイン設定で使用されます。SLS は、ログコンテンツを構造化、分割、フィルタリング、マスキングするための複数の処理ユニットを提供します。これらのユニットは、正規表現、区切り文字、JSON、複数行など、さまざまな処理モードをサポートしています。

ログ収集の仕組み

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

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

3. CR の変更が検出されると、オペレーターはそれを特定の設定に変換し、SLS に送信します。

4. LoongCollector は定期的にハートビートを SLS に送信して、設定の更新を取得します。最新の収集設定をプルし、ホットリロードします。

5. loongcollector-ds は、最新の設定に基づいてログを収集し、設定されたエンドポイントを介して SLS に送信します。

DaemonSet モードの仕組み

クラスターの各ノードに LoongCollector がデプロイされ、そのノード上のすべてのコンテナからログを収集します。このモードは、運用保守が簡単で、リソース消費が少なく、設定が柔軟であるという特徴があります。ただし、分離性は弱いです。

DaemonSet モードの仕組み

• DaemonSet モードでは、Kubernetes クラスターは各ノードで 1 つの LoongCollector コンテナのみが実行されることを保証します。このコンテナは、同じノード上の他のすべてのコンテナからログを収集します。

• 新しいノードがクラスターに参加すると、Kubernetes はそのノードに LoongCollector コンテナを自動的に作成します。ノードがクラスターから離脱すると、Kubernetes はそのノード上の LoongCollector コンテナを自動的に破棄します。DaemonSet のオートスケーリングメカニズムと ID ベースのマシングループにより、LoongCollector インスタンスを手動で管理する必要がなくなります。

Sidecar モードの仕組み

LoongCollector の Sidecar コンテナが、アプリケーションコンテナと一緒に各 Pod に注入されます。アプリケーションコンテナのログディレクトリは、emptyDir、hostPath、または永続ボリューム (PV) などの Kubernetes ボリュームを使用して共有ボリュームとしてマウントされます。これにより、ログファイルはアプリケーションコンテナと Sidecar コンテナの両方のマウントパスで利用可能になり、LoongCollector が直接読み取ることができます。このモードは、優れたマルチテナントデータ分離とパフォーマンスを特徴とします。ただし、より多くのリソースを消費し、設定とメンテナンスがより複雑になります。

Sidecar モードの仕組み

• Sidecar モードでは、各 Pod 内で LoongCollector コンテナが実行され、その Pod 内の他のすべてのコンテナからログを収集します。異なる Pod のログ収集は分離されます。

• 同じ Pod 内の他のコンテナからログファイルを収集するには、共有ボリュームを使用できます。同じボリュームをアプリケーションコンテナと LoongCollector コンテナの両方にマウントする必要があります。

• ノード上の Pod のデータ量が非常に大きく、DaemonSet モードの収集パフォーマンス制限を超える場合は、Sidecar モードを使用して LoongCollector に特定のリソースを割り当てることができます。これにより、ログ収集のパフォーマンスと安定性が向上します。

• サーバーレスコンテナにはノードの概念がないため、従来の DaemonSet デプロイモードは使用できません。このシナリオでは、Sidecar モードをサーバーレスアーキテクチャと組み合わせて、柔軟で適応性のあるログ収集プロセスを確保できます。

コンテナ検出の仕組み

LoongCollector コンテナが他のコンテナからログを収集するためには、どのコンテナが実行されているかを検出して識別する必要があります。このプロセスはコンテナ検出と呼ばれます。

• コンテナ検出フェーズ中、LoongCollector コンテナは Kubernetes クラスターの kube-apiserver とは通信しません。代わりに、ノード上のコンテナランタイムデーモンと直接通信して、そのノード上のすべてのコンテナに関する情報を取得します。これにより、クラスターの kube-apiserver に負荷がかかるのを防ぎます。

• LoongCollector は、ホスト上の Docker Engine や Containerd などのコンテナランタイムの sock ファイルにアクセスすることで、コンテナのコンテキスト情報を取得できます。名前空間名、Pod 名、Pod ラベル、コンテナの環境変数などの基準に基づいて、ログ収集対象のコンテナを指定または除外することをサポートしています。

標準出力の収集

LoongCollector は、コンテナのメタデータに基づいて、Docker や Containerd などのさまざまなコンテナランタイムの API またはロギングドライバーを自動的に識別します。手動での設定は不要です。内部ファイルシステムにアクセスすることなく、すべてのコンテナの標準出力ストリームを直接読み取ります。

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

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

• デフォルトでは、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 は標準の Container Runtime Interface (CRI) API に基づいてコンテナランタイムと直接対話します。これにより、LoongCollector は Kubernetes 内のさまざまなタイプのメタデータを取得し、収集中に非侵入型で Kubernetes メタデータ AutoTagging 機能を実装できます。ランタイムとの直接対話というこのメカニズムは、リアルタイムのデータ取得を強化し、コンテナの状態を管理する能力を向上させます。

• Docker：Docker クライアントは Docker デーモンと通信して、コンテナメタデータを直接取得します。これにより、コンテナの詳細な監視と管理が可能になります。使用される主なインターフェイスは次のとおりです。

  • ContainerList：現在実行中のコンテナのリストを取得して、現在のノードでどのコンテナが実行されているかを迅速に特定します。

  • ContainerInspect：設定や状態などの重要な情報を含む、各コンテナの詳細情報を提供します。

  • Events：コンテナの変更イベントをリアルタイムでリッスンして、コンテナのライフサイクルを動的に追跡し、関連する処理ロジックを迅速に更新します。

  Docker クライアントを通じてコンテナメタデータを取得する際、以下の情報が重要です。

  • LogPath：これは、ホスト上のコンテナの標準出力ログファイルのストレージパスです。ログの収集と分析を容易にします。

  • GraphDriver.Data：これは、ホストノード上のコンテナの rootfs のパスを提供します。このパスは、コンテナのファイルシステムのストレージ方法を理解するための鍵であり、エラー診断とパフォーマンス最適化に役立ちます。

• Containerd：CRI を通じて、LoongCollector は containerd および cri-o ランタイム環境を使用するさまざまなシナリオを完全にサポートします。基盤となるランタイムが runc であっても Kata Containers であっても、コンテナメタデータを効率的に収集および取得できます。これにより、コンテナが実行されている環境に関係なく、正確で統一されたログデータ収集が保証され、リアルタイムでのログデータの監視と分析に役立ちます。

  • CRI によって提供されるコンテナメタデータには、ホストノード上のコンテナの標準出力ログファイルのパスのみが含まれます。コンテナの Rootfs パスは直接取得できません。この問題を解決するには、次のいずれかのソリューションを使用できます。

    • ファイルパス検索：ホストのファイルシステムを検索して、コンテナの Rootfs パスを特定します。この方法では、ホスト上のファイルディレクトリを走査し、コンテナ ID などのコンテナの一意の識別子を使用して関連付けと検索を行います。これにより、コンテナのファイルシステムを取得できます。この動的検索メカニズムは、パス情報の欠落による問題を克服し、その後のログ収集と監視をサポートします。

    • CRI をバイパスして containerd と直接対話する：containerd と直接通信して、より包括的で正確なコンテナ情報を取得します。これにより、LoongCollector は CRI の制限をバイパスして、コンテナの Rootfs パスやその他の重要なメタデータを取得できます。