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

特徴

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

• 複数のログソース

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

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

  • 名前空間、ポッド、コンテナ名、コンテナラベル、または環境変数によって、収集対象のコンテナを指定または除外できます。

• 複雑なログ処理

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

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

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

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

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

• 信頼性の保証

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

  • 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 Mount target: /var/log/service
    2 ✅ Valid collection path: /var/log/service or /var/log/service/subdir
    3 ❌ Invalid collection path: /var/log (Path is too short)

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

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

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

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

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

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

収集ルールの構成

SLS は、収集構成ルールを定義する 2 つの方法を提供します:

主要な概念

• Kubernetes: Kubernetes (K8s) は、オープンソースのコンテナーオーケストレーションプラットフォームです。コンテナー化されたアプリケーションのデプロイメント、スケーリング、管理を自動化します。これは、最新のクラウドネイティブアプリケーション開発および O&M のためのコアインフラストラクチャです。

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

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

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

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

• 収集構成: ログタイプ、収集パス、有効なログのフィルタリング、ログコンテンツの解析、SLS でのストレージ場所など、ログ収集のルールを定義します。詳細については、「LoongCollector 収集構成とは」をご参照ください。

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

ログ収集の仕組み

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

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

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

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

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

DaemonSet モードの仕組み

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

DaemonSet モードの仕組み

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

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

Sidecar モードの仕組み

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

Sidecar モードの仕組み

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

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

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

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

コンテナー検出の仕組み

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

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

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

標準出力の収集

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

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

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

  • ContainerInspect: 構成やステータスなどの重要な情報を含む、各コンテナーの詳細情報を提供します。

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

  Docker Client を介してコンテナメタデータを取得する場合、次の情報が重要です。

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

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

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

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

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

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