Log Serviceを使用してKubernetes環境からログを収集する方法前編(Alibaba Cloud)

2023年3月17日掲載

ご覧いただきありがとうございます。ソフトバンクの小柳です。

今回はAlibaba CloudのLog Serviceを使用して、Kubernetes環境からログを収集する2つの方法を紹介します。
Alibaba Cloudでは、Alibaba Cloud Container Service for Kubernetes (ACK)という製品でKubernetes環境を構築することが出来ますが、このACKからどうやってログを収集すればよいのかわからない、ログを集約して見たいといった相談をもらうことがあるため、Alibaba Cloudコンソールの操作画像付きで、前編と後編に分けて説明します。

Log Serviceとは

初めにログの収集先となるLog Serviceとは何かについて、簡単に説明します。

Log Serviceは、Alibaba Cloud上やオンプレのリソースから出力されるログを一元管理することができるフルマネージドサービスです。
クラウド上のフルマネージドなSyslogサーバと考えていただくと良いかと思いますが、単なるSyslogサーバではなく可視化やアラート、分析まで行うことができます。

他クラウドの類似製品としては、Amazon Cloudwatch logs/Cloudwatch logs insights、Azure Monitor Logs/Log Analytics、Google Cloud Logging/Log Analyticsなどが挙げられます。

今回は手順説明のため詳細は省略しますが、興味がある方は、公式ドキュメントをご覧ください。

Log Serviceを使って、Kubernetes環境からログを収集する２つの方法

本記事の執筆時点では、Log Serviceを使用してKubernetes環境からログデータを収集する方法は2つあります。
どちらの方法もLog Serviceのエージェントの役割を果たすLogtailを使用しますが、Logtailのモードに違いがあります。

1つは、LogtailのDaemonSetモードを使用する方法です。
DaemonSetモードは、小規模から中規模のクラスタのログを収集する際に推奨されるモードです。
DaemonSetモードでは、各ノードで１つのエージェントが実行されるので、次に紹介するSidecarモードよりもリソースの消費が少なくて済みますが、収集性能が低かったり、500を超えない程度で収集対象となるログの設定数に上限の目安があります。

もう1つは、LogtailのSidecarモードを使用する方法です。

Sidecarモードは、大規模なクラスタのログを収集する際に推奨されるモードです。
Sidecarモードでは、ポッドごとにエージェントが実行されるため、DaemonSetモードよりもリソースを多く使用しますが、その分DaemonSetモードよりも収集性能が高く、収集上限もありません。

簡単にそれぞれのメリット・デメリットを表形式でまとめますが、まず環境の規模から判断し、収集上限と必要リソースを天秤にかけて選ぶとよいと思います。

・Logtailの2つのモードの比較表

収集方法	規模	メリット	デメリット
DaemonSetモード	小規模～中規模	・標準出力、標準エラー出力、ファイルが収集可能。・リソースが消費少なくてすむ。	・ログ収集設定に上限の目安がある。(500以下) ・設定に柔軟性が無い。
Sidecarモード	大規模	・Pod毎に設定が変更できる。・ログ収集設定に上限がない。	・収集はファイルのみ。・リソース消費が多い。

事前準備

これからLog ServiceにKubernetes環境のログを取得する具体的な手順を紹介していきますが、本記事のデモでは、下図のようなLog ServiceとKubernetes環境を想定しています。

ACKの環境以外に、収集先となるLog Serviceのプロジェクトを作成します。ログストアは後で設定しますので、事前準備では作成しません。

Log Serviceについて新しい用語が出てきましたが、Log Serviceのプロジェクトとは、異なるリソースを分離して管理するために使用されるリソースの一番大きな管理単位です。
Log Serviceのログストアは、ログの収集、保存、およびクエリに使用されます。各ログストアには、ログ収集方法を定義するために、少なくとも1つのLogtail構成があります。

参考リンク

Log Service プロジェクト
 Log Service ログストア

まずは、Log Serviceのプロジェクトを作成するところまで画像付きで紹介します。
もし、既存の環境でACKクラスタ作成時にプロジェクトが作成されている場合は、事前準備でプロジェクトを作成する必要はありません。

日本リージョンで新規プロジェクトを作成します。

「Create Project」ボタンをクリックすると、プロジェクトの作成画面が、画面の右に表示されます。
ドロップダウンリストから対象リージョンを選択し、プロジェクト名を入力します。
「Create」ボタンをクリックして操作を実行します。

すぐに新しいプロジェクトが作成され、ログストアを作成するかどうかについてポップアップが表示されます。

Log Serviceの機能を利用して、ウィザードからLogtailの設定を行うこともできますが、今回はACKクラスタ内の「CRD(Custom Resource Definition)」で設定しますので、「Disable」ボタンをクリックし、ログストアの設定ウィザードに入らないようにします。

これで、必要なLog Serviceのプロジェクトが準備できました。

同様に日本リージョンに ACK クラスタを作成します。

クラスタを作成する際にスペックを選ぶことが出来ますが、主にACK Standardクラスタは個人開発者向け、ACK Proクラスタは企業向けのスペックです。
ここではデモ用にStandard クラスタを作成します。

「Create Kubernetes Cluster」ボタンをクリックし、クラスタを作成するための画面に遷移します。
必要に応じてクラスタ構成を完成させ、リージョンがLog Serviceプロジェクトと同じであることを確認します。
「Next: Node Pool Configuration」ボタンをクリックして、次のステップに進みます。
「Node Pool Configuration」を要件に応じて設定します。今回はデモ用のクラスタなので、ノードの数を2個に設定します。
「Next: Component Configuration」ボタンをクリックして、次のステップに進みます。
Componentの設定を行います。
「Log Service configuration」が有効になっており、先ほど作成したプロジェクトに設定されていることを確認します。

「Log Collection for control Plane Components」を有効にするかしないかを設定できます。ここでは、ログ収集機能を表示するために、Enabledにします。
こちらを有効にすると、kube-apiserver、 kube-scheduler、 kube-controller-manager、cloud controller managerのログがLog Serviceのプロジェクト内に各ログストアが作成する形でログが収集されます。
「Confirm Order」ボタンをクリックして次のステップに進みます。
設定情報を確認したら、「Create Cluster」ボタンをクリックして操作を実行します。
作成過程のログが表示されます。クラスタの準備が整うまで10分ほどかかります。

クラスタの作成時に「Log Service configuration」と「Log Collection for control Plane Components」を有効に設定したので、対象のLog Serviceプロジェクトに関連するログストアが構成されます。

クラスタの準備が終わったら、Log Serviceのプロジェクトページで関連ログを確認することができます。
以下は、apiserver作成時のログのサンプルです。他のログストアも確認することができ、関連するログがあればそちらも表示されます。

クラスタ側ではLog Serviceに関連する設定は、「Cluster Information」ページの「Cluster Resources」タブに表示されます。
これを実現するために、ACKクラスタでは「logtail-ds」という名前のコンポーネントをインストールしています。詳細な情報は Operation > Add-ons のページで確認できます。

既存のクラスタでは、ここでコンポーネントをインストールして、ログ収集機能を有効にすることができます。コンポーネントをインストールすると、クラスタIDを持つ新しいLog Serviceのプロジェクトが作成されます。

また、Workload > Custer Resources ページに「AliyunLogConfig」という名前の「Custom Resource Definition (CRD)」が作成されます。
DaemonSetモードとSidecarモードでログを収集する際に、このCRDを使用します。

参考リンク

Log Serviceによるコンテナからのログデータ収集

アプリケーションを作成する際に、コンテナからログデータを収集するように Log Service を設定することができます。アプリケーションの作成には、コンソールのウィザードまたは YAML テンプレートを使用することができます。

デフォルトでは、Log Serviceはログデータを行単位で収集し、ログデータの解析は行いません。ログ収集モードを変更して、ログデータを解析したい場合は、以下の手順でDaemonSetモードとSidecarモードを使用する必要があります。

参考リンク

アプリケーション作成時にLog Serviceを設定する

DaemonSetモードを利用して標準出力を収集する手順

それでは、DaemonSet モードでコンテナの標準出力を収集するための Logtailの設定方法を紹介します。
以下のドキュメントと図に従って、Log Serviceコンソールで直接設定を作成することもできます。

参考リンク

DaemonSetモードでコンテナの標準出力と標準エラー出力を収集するには、Log Serviceコンソールを使用します
※「Custom Resource Definition (CRD)」を使用して、ターゲットとなるLogtailの設定を作成することがより推奨されます。

DaemonSetモードでコンテナログを収集するためにCRDを使用します

CRDの設定用YAMLを以下のように用意し、コンソールで対象のリソースを作成します。
サンプルでは、リソース名を「simple-stdout-example」とし、ターゲット Logstore 名を「k8s-stdout」としました。環境に応じて更新してください。

apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
  name: simple-stdout-example
spec:
  logstore: k8s-stdout
  logtailConfig:
    inputType: plugin
    configName: k8s-stdout-example
    inputDetail:
      plugin:
        inputs:
          -
            type: service_docker_stdout
            detail:
              Stdout: true
              Stderr: true