すべてのプロダクト
Search

このプロダクト

    Simple Log Service:データ収集のための Logtail インストールの開始

    ドキュメントセンター

    Simple Log Service:データ収集のための Logtail インストールの開始

    最終更新日:Apr 28, 2025

    Logtail の操作は、収集シナリオによって異なります。このトピックでは、ホストシナリオ、Kubernetes クラスタシナリオ、およびコンテナシナリオで Logtail を使用してログを収集する方法について説明します。

    ホストシナリオ Logtail インストールガイド

    ホストテキストログを収集する場合、Simple Log Service は、ホストの所有権に基づいて、ワンクリック自動インストールと手動インストールの両方をサポートしています。

    ワンクリック自動インストール

    次の条件が満たされている場合、コンソールでワンクリックで Logtail を自動的にインストールできます。Simple Log Service は Operation Orchestration Service (OOS) を使用して、ECS インスタンスに Logtail を自動的にインストールします。詳細については、「ホストテキストログの収集（自動インストール）」をご参照ください。

    • ホストタイプが ECS である。

    • ホストと Simple Log Service プロジェクトが同じアカウントに属し、同じリージョンにある。

    手動インストール

    次のいずれかの条件が存在する場合は、ホストに Logtail を手動でインストールする必要があります。詳細については、「ホストテキストログの収集（手動インストール）」をご参照ください。

    • ホストタイプが ECS ではない。

    • ホストタイプは ECS ですが、Simple Log Service と同じアカウントに属していません。

    • ホストタイプは ECS で、Simple Log Service プロジェクトと同じアカウントに属していますが、同じリージョンにありません。

    Kubernetes クラスタシナリオ Logtail インストールガイド

    コンテナ Kubernetes ログの収集は、トラブルシューティング、パフォーマンスの最適化、セキュリティ監査、およびリソース使用率分析に使用できます。Simple Log Service は、DaemonSet モードと Sidecar モードで Kubernetes クラスタコンテナログの収集をサポートしています。

    Daemonset モード

    • DaemonSet モードでは、Kubernetes クラスタのノードで 1 つの Logtail コンテナのみが実行されます。Logtail を使用して、ノード上のすべてのコンテナからログを収集できます。

    • Kubernetes クラスタにノードが追加されると、クラスタは新しいノードに Logtail コンテナを自動的に作成します。Kubernetes クラスタからノードが削除されると、クラスタは現在のノードの Logtail コンテナを自動的に破棄します。DaemonSet の自動スケーリングメカニズムと ID ベースのマシングループにより、Logtail インスタンスを手動で管理する必要はありません。

    Sidecar モード

    • Sidecar モードでは、各ポッドは Logtail コンテナを実行します。Logtail を使用して、ポッド内のすべてのコンテナからログを収集できます。この場合、各ポッドからのログ収集は分離されます。

    • Logtail がポッド内の他のコンテナからログを収集できるようにするには、Logtail コンテナとアプリケーションコンテナが同じボリュームを共有していることを確認してください。Sidecar モードでのコンテナログの収集の詳細については、「Sidecar ロギングの概要」および「Sidecar モードの例」を参照してください。ボリュームの詳細については、「ストレージの基本」をご参照ください。

    収集方法

    シナリオ

    メリット

    デメリット

    DaemonSet

    通常は DaemonSet を使用することをお勧めします

    シンプルな O&M、低リソース使用量、柔軟な構成を提供します。コンテナの stdout および stderr ログを収集できます。また、コンテナのテキストログも収集できます。

    Logtail は DaemonSet 固有のノード上のすべてのコンテナからログを収集します。ただし、このモードでは、Logtail でパフォーマンスボトルネックの問題が発生する可能性があり、コンテナの分離が緩やかになります。

    Sidecar

    各ポッドが収集に個別の Logtail インスタンスを使用する必要がある状況（serverless Kubernetes (ASK) クラスタはデフォルトで sidecar モードを使用して Logtail をデプロイします）。

    ログを収集する必要がある各コンテナに Sidecar コンテナを作成し、優れたマルチテナントデータ分離を実現します。

    リソース消費量が多く、構成とメンテナンスがより複雑になります。

    コンテナディスカバリ

    • Logtail コンテナが他のコンテナからログを収集する前に、Logtail コンテナはどのコンテナが実行されているかを識別して判断する必要があります。このプロセスはコンテナディスカバリと呼ばれます。コンテナディスカバリフェーズでは、Logtail コンテナは Kubernetes クラスタの kube-apiserver と通信しません。代わりに、ノード上のコンテナランタイムデーモンプロセスと直接通信して、現在のノード上のすべてのコンテナに関する情報を取得し、クラスタ kube-apiserver への負荷を回避します。

    • Logtail は、名前空間名、ポッド名、ポッドラベル、コンテナ環境変数などの条件によって、対応するコンテナからのログ収集を指定または除外することをサポートしています。

    コンテナファイルパスマッピング

    Kubernetes クラスタでは、ポッド間のリソースが分離されているため、Logtail コンテナは他のポッドのコンテナ内のファイルに直接アクセスできません。ただし、コンテナのファイルシステムは、コンテナホストのファイルシステムをコンテナにマウントすることによって作成されます。Logtail コンテナは、コンテナホストのルートディレクトリを含むファイルシステムが Logtail コンテナにマウントされた後にのみ、コンテナホスト上の任意のファイルにアクセスできます。このようにして、Logtail コンテナはファイルシステム内のファイルからログを収集できます。コンテナ内のファイルパスとコンテナホスト上のファイルパスの関係は、ファイルパスマッピングと呼ばれます。

    現在のコンテナ内のログファイルのパスが /log/app.log で、マッピングされたホストパスが /var/lib/docker/containers/<container-id>/log/app.log であるとします。Logtail は、デフォルトでホストのルートディレクトリを含むファイルシステムを Logtail の /logtail_host ディレクトリにマウントします。したがって、Logtail が収集する実際のファイルパスは /logtail_host/var/lib/docker/containers/<container-id>/log/app.log です。

    考慮事項

    コンテナランタイムのサポート

    • サポートされているエンジン:

      • Docker

      • Containerd

    • ストレージドライバの制限（Docker のみ）:

      • Overlay と Overlay2 のみがサポートされています。

      • その他のドライバー: Overlay 以外のドライバーを使用する場合は、ボリュームを使用してログディレクトリを一時ディレクトリとしてマウントする必要があります。

    ボリュームマウント方法

    NAS が PVC としてデータディレクトリにマウントされている場合。

    • 使用しないでください: DaemonSet を使用して Logtail をデプロイします。

    • 推奨:

    ログファイルパスの仕様

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

      • 誤った構成: /var/log/app -> /mnt/nas/logs.

      • 正しい構成: 物理パスを直接使用します /mnt/nas/logs.

    • マウントパスのマッチングルール:

      アプリケーションコンテナのデータディレクトリがボリュームを介してマウントされている場合、収集パスはマウントポイントパス以上である必要があります。

      例:

      1マウントポイント: /var/log/service
2✅ 有効な収集パス: /var/log/service または /var/log/service/subdir
3❌ 無効な収集パス: /var/log (パスが短すぎる)

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

    ランタイム

    ログの整合性

    コンテナ破棄の遅延リスク

    最適化の提案

    Docker

    コンテナが停止する前に、ネットワーク遅延やリソースの過剰消費などの問題により収集の遅延が発生した場合、コンテナが停止する前に収集された一部のログが失われる可能性があります。

    コンテナが停止すると、Logtail はすぐにコンテナファイルハンドルを解放し、コンテナが正常に終了できるようにします。

    ログ送信頻度を増やします（flush_interval を減らします）。

    Containerd

    コンテナが停止すると、Logtail はすべてのログファイルの内容が送信されるまで、コンテナのファイルハンドルを保持し続けます（ログファイルをオープンしたままにします）。

    ネットワーク遅延やリソースの過剰消費などの問題により収集の遅延が発生した場合、アプリケーションコンテナがタイムリーに破棄されない可能性があります。

    max_hold_buffer_size を構成してメモリ使用量を制限します。

    Docker コンテナシナリオ logtail インストールガイド

    サーバーに Docker をデプロイした後、ログを収集できます。Docker ログは、標準出力とファイルログの 2 つのタイプに分けられます。ファイルログは、コンテナ内で生成され、サーバー上の指定されたファイルディレクトリに書き込まれるログを指し、標準出力は、コンテナ自体のリアルタイム出力ストリームを指します。