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

特徴

Simple Log Service は、Kubernetes コンテナログの収集に対して以下のコア機能を提供します：

• マルチソースログ対応

  • コンテナからの標準出力 (stdout)、標準エラー (stderr)、テキストファイルログなど、さまざまなログタイプをサポートします。

• 細かいコンテナフィルタリング

  • 名前空間名、Pod 名、コンテナ名、コンテナラベル、環境変数に基づいて、収集対象のコンテナを含める／除外できます。

• 高度なログ処理

  • マルチラインログの収集：Java 例外スタックトレースなど、複数行にわたるログエントリを 1 つのログイベントとして結合し、誤った分割を防止します。

  • ログの事前処理：ソースで無効なデータを破棄するため、フィルタープラグインを使用します。また、生ログ内の機密データをマスクまたは構造化するため、ログの機密情報除去またはフィールド抽出プラグインを使用します。

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

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

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

• 信頼性

  • チェックポイント機構により、現在の収集位置を記録し、ログの整合性を保証します。

  • コンテナ停止時のログ処理：さまざまなコンテナランタイムに対応した異なる戦略を提供します。

制限事項

• コンテナランタイム：Docker および Containerd のみをサポートします。

  Docker：

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

  • 標準出力の収集には、json-file ロギングドライバーのみがサポートされます。

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

  Containerd：

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

• マルチラインログの制限：

  出力遅延によるマルチラインログの分割を防ぐため、最後に収集された行は短時間バッファーされます。デフォルトのバッファータイムは 3 秒です。BeginLineTimeoutMs パラメーターを設定することで調整可能です。誤った解析を回避するため、値は最低でも 1,000 ミリ秒以上である必要があります。

• 標準出力：

  単一ログエントリのデフォルト最大サイズは 524,288 バイト（512 KB）であり、上限は 8,388,608 バイト（8 MB）です。単一ログエントリが 524,288 バイトを超える場合、LoongCollector コンテナの max_read_buffer_size 環境変数を設定することで、この制限を引き上げることができます。

  重要

  標準出力と標準エラーの収集を同時に有効化しないことを推奨します。これにより、ログエントリが不適切に混在する可能性があります。

収集ワークフローの概要

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

2. LoongCollector 収集エージェントのインストール：LoongCollector を使用してログを収集・転送し、Simple Log Service に送信します。

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（パスが不十分に特定されています）

収集エージェントのインストール

ユースケースに応じてデプロイモードを選択してください。

デプロイモード：Simple Log Service では、DaemonSet モードまたはサイドカーモードによる LoongCollector のインストールがサポートされています。

• DaemonSet デプロイモード：一度の設定後、クラスター内の各ノードに LoongCollector エージェントが自動的にデプロイされます。ほとんどのシナリオに適しています。

  • DaemonSet モードでは、クラスターと Simple Log Service の関係に応じて、適切なデプロイ方法が異なります。

    • Container Service for Kubernetes (ACK) クラスターの場合、loongcollector-ds コンポーネントは事前に統合されています。ACK コンソールで該当コンポーネントを有効化するだけでインストールが完了します。デフォルトでは、この方法では収集エージェントが ACK クラスターを所有する Alibaba Cloud アカウントに紐付けられ、ログはそのアカウントの Simple Log Service Project に格納されます。詳細については、「インストールおよび設定」をご参照ください。

    • ACK クラスターを使用しているものの、組織構造、権限分離、または集中監視などの理由により、別の Alibaba Cloud アカウントの Simple Log Service Project へログを収集する必要がある場合は、LoongCollector コンポーネントを手動でインストールする必要があります。宛先アカウントの Alibaba Cloud アカウント ID または AccessKey を用いて設定し、宛先アカウントに接続します。詳細については、「インストールおよび設定」をご参照ください。

    • セルフマネージドクラスターを使用している場合は、LoongCollector コンポーネントを手動でインストールし、宛先アカウントの Alibaba Cloud アカウント ID または AccessKey を用いて設定し、宛先アカウントに接続する必要があります。詳細については、「インストールおよび設定」をご参照ください。

    ログ収集の前提条件として、LoongCollector のインストールが必要です。インストール手順を含む完全な手順については、「CRD を使用した Kubernetes クラスターからのコンテナログ収集（標準出力／ファイル）」をご参照ください。

• サイドカーデプロイモード：各アプリケーション Pod に LoongCollector サイドカーコンテナが挿入されます。このモードはデプロイおよび保守がより複雑です。サーバーレスコンテナのログ収集、Pod のデータ量が DaemonSet の収集能力を大幅に上回るノード、またはセキュアなコンテナランタイムを使用する Kubernetes 環境でのログ収集にご使用ください。詳細については、「Kubernetes Pod テキストログの収集（サイドカーモード）」をご参照ください。

収集ルール

Simple Log Service では、収集ルールを定義するための以下の 2 つの方法を提供しています：

基本概念

• Kubernetes：Kubernetes（K8s）は、コンテナ化アプリケーションのデプロイ、スケーリング、および管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。現代のクラウドネイティブアプリケーションの開発および運用保守の基盤となるインフラストラクチャです。

• 標準出力、標準エラー、およびテキストファイルログ：標準出力（stdout）は、プログラムの通常実行中に出力される情報であり、ビジネスログや運用記録などが該当します。デフォルトでは端末に出力され、コンテナエンジンによってキャプチャされます。標準エラー（stderr）は、例外スタックトレースや起動失敗など、エラーまたは警告に関する情報であり、コンテナエンジンによってキャプチャされ、stdout と混在する可能性があります。テキストファイルログは、Nginx の access.log やカスタムログファイルなど、アプリケーションがファイルに書き込むログです。これらのログはコンテナのファイルシステムに直接書き込まれますが、コンテナが破棄されると削除されます。ただし、ボリュームを使用することで永続化できます。

• チェックポイント機構：チェックポイントは、Simple Log Service がログを収集したファイル内の正確な位置を記録します。デフォルトでは、/tmp/logtail_checkpoint に保存されます。これにより、LoongCollector の再起動やノード障害などの中断後に、信頼性の高いログ収集が可能になります。

• LoongCollector（Logtail）：LoongCollector は、Alibaba Cloud が開発したパフォーマンス専有型のログ収集エージェントです。Kubernetes における DaemonSet モードおよびサイドカーモードの両方をサポートします。LoongCollector は Logtail の後継製品であり、完全な下位互換性を備えています。

• Kubernetes CRD：CRD（CustomResourceDefinition）は、Kubernetes が提供するカスタムリソースを定義・作成するための仕組みです。Simple Log Service が提供するカスタムリソースタイプは AliyunPipelineConfig です。

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

• 解析プラグイン：解析プラグインは、収集設定の処理プラグイン構成内で使用される処理ユニットであり、ログコンテンツの構造化、分割、フィルタリング、または機密情報除去に使用されます。Simple Log Service では、正規表現、区切り文字、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 クラスターが各ノードに 1 つの LoongCollector コンテナのみを実行させ、そのノード上のすべてのコンテナからログを収集します。

• 新規ノードがクラスターに参加すると、Kubernetes が自動的にそのノードに LoongCollector コンテナを作成します。ノードがクラスターから離脱すると、Kubernetes がそのノード上の LoongCollector コンテナを自動的に破棄します。この自動スケーリングにより、LoongCollector インスタンスを手動で管理する必要はありません。

サイドカーモード

各 Pod に、アプリケーションコンテナとともに LoongCollector サイドカーコンテナが挿入されます。アプリケーションコンテナのログディレクトリは、emptyDir、hostPath、または PVC などの Kubernetes ボリューム機構を用いて共有ボリュームとしてマウントされます。これにより、ログファイルがアプリケーションコンテナとサイドカーコンテナの両方からアクセス可能となり、LoongCollector が直接読み取ることができます。このモードは、マルチテナント環境での強固な隔離性と高いパフォーマンスを提供しますが、リソース消費が多く、構成および保守がより複雑です。

サイドカーモードの動作

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

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

• ノード上の単一 Pod のデータ量が非常に大きく、DaemonSet エージェントの収集能力を上回る場合、サイドカーモードにより LoongCollector に特定のリソースを割り当てることができ、収集パフォーマンスおよび安定性を向上させることができます。

• サーバーレスコンテナ環境ではノードという概念が存在しないため、DaemonSet デプロイモードは適用できません。このような場合、サイドカーモードはサーバーレスアーキテクチャと効果的に統合され、柔軟かつ適応性の高いログ収集プロセスを実現します。

コンテナの検出

他のコンテナのログを収集するには、まず LoongCollector コンテナがノード上で実行中のコンテナを特定する必要があります。このプロセスを「コンテナの検出」といいます。

• コンテナの検出中、LoongCollector コンテナは、Kubernetes クラスターの kube-apiserver を経由せずに、ノード上のコンテナランタイムデーモンと直接通信します。これにより、クラスターの kube-apiserver に追加の負荷をかけることなく、現在のノード上のすべてのコンテナに関する情報を取得できます。

• LoongCollector は、ホスト上のコンテナランタイム（Docker または Containerd）のソケットにアクセスしてコンテナコンテキストを取得します。名前空間名、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 は、ユーザー定義の正規表現を使用してログ行の開始をマッチします。

• マッチ成功：その行は新しいログエントリの開始として扱われます。

• マッチ失敗：その行は現在のログエントリに追加されます。

別の行が行頭正規表現にマッチすると、現在のログエントリが完了し、新しいログエントリが始まります。

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

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

LoongCollector は、標準の CRI（Container Runtime Interface）API を介してコンテナランタイムと直接通信し、Kubernetes メタデータを取得します。これにより、収集時に非侵入型かつ自動的な Kubernetes メタデータのタグ付けが可能になります。この直接通信により、リアルタイムのデータ取得が実現します。

• Docker：LoongCollector は Docker Client を使用して Docker デーモンと通信し、コンテナメタデータを直接取得します。これにより、詳細なモニタリングおよび管理が可能になります。主に使用される API は以下のとおりです：

  • ContainerList：実行中のコンテナの一覧を取得し、ノード上のアクティブなコンテナの概要を提供します。

  • ContainerInspect：各コンテナの詳細情報を提供し、構成およびステータスを含みます。

  • Events：コンテナイベントをリアルタイムでリッスンし、コンテナライフサイクルの動的追跡を可能にします。

  Docker Client を通じてコンテナメタデータを取得する際に特に重要な情報は以下のとおりです：

  • LogPath：コンテナの標準出力ログファイルがホスト上に保存されるパス。ログ収集および分析に不可欠です。

  • GraphDriver.Data：コンテナの rootfs がホスト上に存在するパス。コンテナのファイルシステムストレージを理解するために重要であり、トラブルシューティングおよびパフォーマンス最適化に役立ちます。

• Containerd：CRI を使用することで、LoongCollector は containerd および CRI-O 環境をサポートします。これにより、runc や Kata Containers などのさまざまな基盤ランタイムからメタデータを収集でき、一貫したデータ収集が保証されます。

  • CRI が提供するコンテナメタデータには、ホスト上でのコンテナ標準出力ログファイルのパスが含まれますが、コンテナの rootfs パスは直接提供されません。このパスを特定するための方法は以下のとおりです：

    • ファイルパス検索：LoongCollector は、コンテナ ID などの一意の識別子を用いて、ホストのファイルシステム上でコンテナの rootfs パスを検索します。

    • containerd との直接通信：より包括的な情報を得るために、LoongCollector は CRI をバイパスし、より低レベルで containerd と直接通信できます。これにより、CRI では取得できないコンテナの rootfs パスやその他の重要なメタデータを取得できます。