Knative サービスは各ノードでログを生成しますが、収集エージェントが存在しない場合、Pod のスケールダウンまたは再起動時にこれらのログは失われます。ACK は Simple Log Service (SLS) と統合されており、アプリケーションコードを変更することなく、Knative サービスのコンテナテキストログを収集できます。ログ収集コンポーネントをインストールすると、各ノードに DaemonSet エージェントが実行され、そのノード上のすべてのコンテナからログを SLS へ転送してクエリおよび分析を行います。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
クラスターに Knative がデプロイされています。詳細については、「Knative のデプロイと管理」をご参照ください。
Knative サービスが作成済みであること。詳細については、「Knative アプリケーションの迅速なデプロイ」をご参照ください。
手順 1:ログ収集コンポーネントのインストール
ACK では、LoongCollector および Logtail の 2 種類のログ収集コンポーネントをサポートしています。クラスターごとに 1 つのコンポーネントのみをインストールできます。両方を同時に実行することはできません。
| コンポーネント | ステータス | 使用タイミング |
|---|---|---|
| LoongCollector | カナリアリリース | サポートされているリージョン |
| Logtail (logtail-ds) | 一般提供 | 既存のクラスター、または LoongCollector が未対応のリージョン |
LoongCollector のインストール
LoongCollector は、SLS が提供する次世代のログ収集エージェントであり、Logtail のアップグレード版です。Application Real-Time Monitoring Service (ARMS) の機能を統合することが予定されており、これには Managed Service for Prometheus をベースとしたデータ収集および Extended Berkeley Packet Filter (eBPF) をベースとした非侵入型のデータ収集が含まれます。詳細については、「LoongCollector ベースのデータ収集」をご参照ください。
loongcollector と logtail-ds を同時にインストールすることはできません。すでにクラスターに logtail-ds がインストールされている場合、直接 loongcollector へアップグレードすることはできません。今後、アップグレードソリューションが提供される予定です。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理対象のクラスターをクリックします。左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。
[ログとモニタリング] タブで、loongcollector コンポーネントを見つけ、[インストール] をクリックします。
インストール後、SLS は自動的に k8s-log-${your_k8s_cluster_id} という名前のプロジェクトおよび以下のリソースを作成します。
| リソースタイプ | リソース名 | 説明 | 例 |
|---|---|---|---|
| マシングループ | k8s-group-${your_k8s_cluster_id} | loongcollector-ds 用のマシングループ。ログ収集に使用されます。 | k8s-group-my-cluster-123 |
| マシングループ | k8s-group-${your_k8s_cluster_id}-cluster | loongcollector-cluster 用のマシングループ。メトリック収集に使用されます。 | k8s-group-my-cluster-123-cluster |
| マシングループ | k8s-group-${your_k8s_cluster_id}-singleton | 単一インスタンス用のマシングループ。LoongCollector 構成の作成に使用されます。 | k8s-group-my-cluster-123-singleton |
| Logstore | config-operation-log | loongcollector-operator のログを格納します。この Logstore を削除しないでください。 | config-operation-log |
Logtail のインストール
Logtail は、SLS が提供するログ収集エージェントで、アプリケーションコードを変更することなく、ECS インスタンス、オンプレミスサーバー、およびサードパーティのクラウドサーバーなど、複数のデータソースからログを収集します。詳細については、「Logtail を使用したデータ収集」をご参照ください。
既存の ACK クラスターへの Logtail のインストール
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理対象のクラスターを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。
[ログとモニタリング] タブで、logtail-ds コンポーネントを見つけ、[インストール] をクリックします。
ACK クラスター作成時の Logtail のインストール
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、[Kubernetes クラスターの作成] をクリックします。コンポーネント設定 ステップで、[Log Service の有効化] を選択します。このトピックでは、SLS 関連の設定のみについて説明します。その他のクラスター設定については、「ACK マネージドクラスターの作成」をご参照ください。Log Service の有効化 を選択した後、SLS プロジェクトの作成方法を選択します:
[プロジェクトの選択]:既存のプロジェクトを使用して収集されたコンテナログを管理します。

[プロジェクトの作成]:SLS が自動的にプロジェクトを作成します。プロジェクト名には新規クラスターの
ClusterIDが含まれます。
重要「コンポーネント設定」ステップでは、「コントロールプレーンコンポーネントのログ」に対してデフォルトで「有効」が選択されています。有効にすると、システムはクラスターのコントロールプレーンコンポーネントから自動的にログを収集し、従量課金の課金方法に基づいて料金を請求します。要件に応じて、この機能を有効にするかどうかを決定してください。詳細については、「ACK マネージドクラスターのコントロールプレーンコンポーネントのログを収集する」をご参照ください。

インストール後、SLS は自動的に k8s-log-<YOUR_CLUSTER_ID> という名前のプロジェクトおよび以下のリソースを作成します。
| リソースタイプ | リソース名 | 説明 | 例 |
|---|---|---|---|
| マシングループ | k8s-group-<YOUR_CLUSTER_ID> | logtail-daemonset 用のマシングループ。ログ収集に使用されます。 | k8s-group-my-cluster-123 |
| マシングループ | k8s-group-<YOUR_CLUSTER_ID>-statefulset | logtail-statefulset 用のマシングループ。メトリック収集に使用されます。 | k8s-group-my-cluster-123-statefulset |
| マシングループ | k8s-group-<YOUR_CLUSTER_ID>-singleton | 単一インスタンス用のマシングループ。Logtail 構成の作成に使用されます。 | k8s-group-my-cluster-123-singleton |
| Logstore | config-operation-log | 取り込みデータ量課金の課金項目alibaba-log-controller コンポーネントのログを格納します。この Logstore に対して Logtail 構成を作成しないことを推奨します。この Logstore を削除しても問題ありません。削除後、運用ログの収集は停止します。通常の Logstore と同様に課金されます。詳細については、「」をご参照ください。 | — |
手順 2:収集設定の作成
以下のいずれかの方法で収集設定を作成します。設定ごとに 1 つの方法のみを使用してください。
| 方法 | 推奨用途 |
|---|---|
| CRD - AliyunPipelineConfig(推奨) | 複雑な収集および処理;Logtail 構成と ACK クラスター内の Logtail コンテナ間のバージョン整合性。logtail-ds のバージョンが V1.8.10 より新しい必要があります。 |
| SLS コンソール | GUI を使用したシンプルな設定;一部の高度な機能およびカスタム設定は利用できません。 |
| 環境変数 | シンプルな設定のみ;1 行テキストログ;複雑な処理は不要。複数のアプリケーションから同一または異なる Logstore への収集をサポートします。 |
| CRD - AliyunLogConfig | 旧式 CRD を使用するレガシーなシナリオ。拡張性および安定性の向上のため、AliyunPipelineConfig への移行を推奨します。 |
CRD - AliyunPipelineConfig(推奨)
新規設定にはこの方法をご利用ください。AliyunPipelineConfig は AliyunLogConfig よりも高い拡張性および安定性を備えており、複雑な収集および処理パイプラインをサポートします。AliyunPipelineConfig を使用するには Logtail のバージョンが V0.5.1 以降である必要があります。
AliyunPipelineConfig カスタムリソース定義 (CRD) からカスタムリソース (CR) を作成します。CR の作成時に設定が自動的に適用されます。設定を変更する場合は、CR を更新します。
主な制約事項:
configNameの値は、SLS プロジェクト内で一意である必要があります。Logtail 構成ごとに 1 つの CR を作成します。複数の CR が同一の構成を参照している場合、最初に作成された CR のみが有効になります。
手順:
YAML ファイルを作成します。
vim cube.yaml以下の例を参考に、YAML ファイルに構成を追加します。
構成を適用します。
kubectl apply -f cube.yamlLogtail は指定されたコンテナからログを収集し、SLS へ送信を開始します。
ログ収集が開始されたら、ログをクエリおよび分析できるように、Logstore にインデックスを作成してください。詳細については、「インデックスの作成」をご参照ください。
特定のコンテナから 1 行テキストログを収集
この例では、example-k8s-file という名前の Logtail 構成を作成し、名前に app を含むコンテナから 1 行テキストログを収集します。ログファイルは、パス /data/logs/app_1 下の test.LOG です。ログはプロジェクト k8s-log-test 内の Logstore k8s-file に格納されます。
apiVersion: telemetry.alibabacloud.com/v1alpha1
# ClusterAliyunPipelineConfig CRD から CR を作成します。
kind: ClusterAliyunPipelineConfig
metadata:
# 名前は Kubernetes クラスター内で一意である必要があります。また、Logtail 構成名としても使用されます。
name: example-k8s-file
spec:
# ログを収集するプロジェクトを指定します。
project:
name: k8s-log-test
# ログを格納する Logstore を作成します。
logstores:
- name: k8s-file
config:
inputs:
# input_file を使用してコンテナからのテキストログを収集します。
- Type: input_file
# コンテナ内のログファイルパス。
FilePaths:
- /data/logs/app_1/**/test.LOG
# コンテナの自動検出を有効化します。
EnableContainerDiscovery: true
# コンテナをフィルターします。複数の条件は論理 AND で結合されます。
ContainerFilters:
# default 名前空間内のコンテナに一致させます。
K8sNamespaceRegex: default
# 名前に "app" を含むコンテナに一致させます。
K8sContainerRegex: ^(.*app.*)$
flushers:
# flusher_sls を使用してログを Logstore へ送信します。
- Type: flusher_sls
Logstore: k8s-file
# 有効なエンドポイントおよびリージョンの値については、https://www.alibabacloud.com/help/ja/sls/developer-reference/service-entrance をご参照ください。
Endpoint: cn-hangzhou.log.aliyuncs.com
Region: cn-hangzhou
TelemetryType: logsすべての AliyunPipelineConfig パラメーターについては、「(推奨) AliyunPipelineConfig を使用して Logtail 構成を管理する」および「CreateLogtailPipelineConfig」をご参照ください。
すべてのコンテナから複数行テキストログを収集
この例では、example-k8s-file という名前の Logtail 構成を作成し、クラスター内のすべてのコンテナから複数行テキストログを収集します。ログファイルは、パス /data/logs/app_1 下の test.LOG です。ログは正規表現で解析され、プロジェクト k8s-log-test 内の Logstore k8s-file に格納されます。
input_file プラグインは、{"content": "2024-06-19 16:35:00 INFO test log\nline-1\nline-2\nend"} の形式のログを読み込み、processor_parse_regex_native プラグインはこれを {"time": "2024-06-19 16:35:00", "level": "INFO", "msg": "test log\nline-1\nline-2\nend"} に解析します。
apiVersion: telemetry.alibabacloud.com/v1alpha1
# ClusterAliyunPipelineConfig CRD から CR を作成します。
kind: ClusterAliyunPipelineConfig
metadata:
name: example-k8s-file
spec:
project:
name: k8s-log-test
logstores:
- name: k8s-file
config:
# 参考用にサンプルログを追加(任意)。
sample: |
2024-06-19 16:35:00 INFO test log
line-1
line-2
end
inputs:
- Type: input_file
FilePaths:
- /data/logs/app_1/**/test.LOG
EnableContainerDiscovery: true
# 複数行ログ収集を有効化します。
Multiline:
# 各ログエントリの先頭行を識別するためのカスタム正規表現を使用します。
Mode: custom
StartPattern: \d+-\d+-\d+.*
processors:
# 正規表現を使用してログを解析します。キャプチャグループは抽出されたフィールドを定義します。
- Type: processor_parse_regex_native
SourceKey: content
Regex: (\d+-\d+-\d+\s*\d+:\d+:\d+)\s*(\S+)\s*(.*)
Keys: ["time", "level", "msg"]
flushers:
- Type: flusher_sls
Logstore: k8s-file
Endpoint: cn-hangzhou.log.aliyuncs.com
Region: cn-hangzhou
TelemetryType: logsCRD - AliyunLogConfig
AliyunLogConfig CRD からカスタムリソース (CR) を作成します。構成は自動的に適用されます。変更する場合は、CR を更新します。
複数の CR が同一の Logtail 構成を参照している場合、1 つの CR を削除または変更すると、他のすべての CR にも影響が及びます。これにより、SLS 内の構成と CR の状態が不整合になります。
手順:
YAML ファイルを作成します。
vim cube.yaml以下の例を参考に、構成を追加します。
configNameの値は、SLS プロジェクト内で一意である必要があります。構成を適用します。
kubectl apply -f cube.yaml
ログ収集が開始されたら、ログをクエリおよび分析できるようにインデックスを作成してください。詳細については、「インデックスを作成する」をご参照ください。
特定のコンテナから 1 行テキストログを収集
この例では、example-k8s-file という名前の構成を作成し、名前が app で始まる Pod から 1 行テキストログを収集します。ログファイルは、パス /data/logs/app_1 下の test.LOG です。ログはプロジェクト k8s-log-test 内の Logstore k8s-file に格納されます。
apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
name: example-k8s-file
namespace: kube-system
spec:
# 空欄の場合は、k8s-log-<your_cluster_id> という名前のプロジェクトが使用されます。
project: k8s-log-test
# 指定した Logstore が存在しない場合、SLS が自動的に作成します。
logstore: k8s-file
logtailConfig:
# テキストログの場合は "file" を設定します。
inputType: file
configName: example-k8s-file
inputDetail:
# テキストログのシンプルモード。
logType: common_reg_log
logPath: /data/logs/app_1
# ワイルドカード文字 (* および ?) をサポートします。例:log_*.log
filePattern: test.LOG
# コンテナログ収集には必須です。
dockerFile: true
advanced:
k8s:
K8sPodRegex: '^(app.*)$'すべての CR パラメーターについては、「AliyunLogConfig を使用した Logtail 構成の管理」および「CreateConfig」をご参照ください。
SLS コンソール
Simple Log Service コンソールにログインします。
[クイックデータインポート] セクションで、[データのインポート] をクリックします。[データのインポート] ダイアログボックスで、[Kubernetes - ファイル] カードをクリックします。

使用するプロジェクトおよび Logstore を選択し、[次へ] をクリックします。Logtail コンポーネントのインストール時に作成されたプロジェクトを選択します。
[マシングループの構成] ステップで、以下の設定を行います。
設定に応じてマシングループのオプションを選択します。
Kubernetes クラスタ > ACK デーモンセット
Kubernetes クラスター > DaemonSet モードのセルフマネージドクラスター
重要選択したオプションによって、その後の設定が異なります。
[適用済みサーバーグループ] セクションに必要なマシングループが表示されていることを確認し、[次へ] をクリックします。ACK クラスターに Logtail をインストールした後、SLS は自動的に
k8s-group-${your_k8s_cluster_id}という名前のマシングループを作成します。このマシングループをそのまま使用できます。重要新しいマシングループを作成するには、[マシングループの作成] をクリックし、パラメーターを設定します。詳細については、「ACK クラスターからのコンテナログ収集」をご参照ください。
マシングループのハートビートステータスが [FAIL] の場合は、[自動再試行] をクリックします。問題が解決しない場合は、「Logtail マシングループに関するエラーをトラブルシューティングする」をご参照ください。
Logtail 構成を作成し、[次へ] をクリックします。構成が作成されると、SLS はログ収集を開始します。[コンテナフィルターのオプション] 以下のフィルターオプションは、Logtail 1.0.34 以降で利用可能です。それより前のバージョンでは、環境変数およびコンテナラベルのみを使用できます。
[K8s Pod 名の正規表現マッチング]:Pod 名を正規表現でマッチさせることでコンテナをフィルターします。例:
^(nginx-log-demo.*)$は、名前がnginx-log-demoで始まるすべての Pod 内のコンテナにマッチします。[K8s 名前空間の正規表現マッチング]:名前空間でコンテナをフィルターします。例:
^(default|nginx)$は、nginxおよびdefault名前空間内のコンテナにマッチします。[K8s コンテナ名の正規表現マッチング]:
spec.containersで定義されたコンテナ名でコンテナをフィルターします。例:^(container-test)$は、container-testという名前のコンテナにマッチします。[コンテナラベルのホワイトリスト/ブラックリスト]:コンテナラベル(キーと値のペア)でコンテナをフィルターします。Kubernetes 名前空間およびコンテナ名は、ラベル
io.kubernetes.pod.namespaceおよびio.kubernetes.container.nameにマップされます。キーと値のペアは OR 論理で評価されます。文字列マッチングがデフォルトですが、正規表現マッチングを行うには、先頭に^を、末尾に$を付与します。[環境変数のホワイトリスト/ブラックリスト]:環境変数のキーと値のペアでコンテナをフィルターします。OR 論理が適用されます。例:[環境変数名] を
NGINX_SERVICE_PORTに、[環境変数値] を^(80|6379)$に設定すると、ポート 80 または 6379 を使用するコンテナにマッチします。[Kubernetes Pod ラベルのホワイトリスト/ブラックリスト]:Kubernetes Pod ラベル(コンテナラベルとは異なる)でコンテナをフィルターします。OR 論理が適用されます。例:[ラベル名] を
environmentに、[ラベル値] を^(dev|pre)$に設定すると、environment:devまたはenvironment:preという Pod ラベルを持つコンテナにマッチします。
説明 Logtail 構成の有効化には最大 3 分かかります。[グローバル構成]
パラメーター 説明 構成名 プロジェクト内で一意となる構成名を入力します。この名前は後で変更できません。 ログトピックタイプ ログトピックの生成方法を選択します。オプション: マシングループトピック(異なるグループからのログを区別するためにマシングループトピックを使用)、ファイルパス抽出(正規表現を使用してファイルパスの一部をトピックとして抽出)、カスタム(カスタムトピックを指定)。詳細については、「ログトピック」をご参照ください。 高度なパラメーター 任意。高度なグローバルパラメーターを設定します。詳細については、「CreateLogtailPipelineConfig」をご参照ください。 [入力構成]
パラメーター 説明 Logtail デプロイモード 本ユースケースでは、[Daemonset] を選択します。 ファイルパスタイプ ほとんどの場合、[コンテナ内のパス] を選択します。[ホストパス] を選択するのは、hostPath ボリュームがマウントされており、コンテナホスト上のマップされたパスに基づいてログを収集したい場合のみです。 ファイルパス ログファイルのパスを指定します。Linux のパスは /で始まります(例:/apsara/nuwa//app.Log`). Windows のパスはドライブ文字で始まります(例: `C:\Program Files\Intel\\*.Log)。ワイルドカードとして*および?のみを使用します。例:/apsara/nuwa/**/*.logは、/apsara/nuwaの下にあるすべての.logファイルを再帰的に収集します。/var/logs/app_*/**/*.logは、/var/logsの下でapp_*に一致するサブディレクトリ内の.logファイルを収集します。/var/log/nginx/**/access*は、/var/log/nginxの下でaccessで始まるファイルを再帰的に収集します。最大ディレクトリ監視深度 ファイルパス内の **ワイルドカードに対するサブディレクトリレベルの最大監視数を設定します。値が0の場合、指定されたディレクトリのみが監視されます。この値は必要最小限に保つことを推奨します。値が大きいと、監視リソースの消費が増加し、収集遅延が発生する可能性があります。コンテナメタデータのプレビューを有効化 有効化すると、構成作成後に一致したコンテナ情報および完全なコンテナメタデータが表示されます。 コンテナフィルター ログ収集対象のコンテナをフィルターします。フィルター動作は Logtail のバージョンによって異なります:Logtail が 1.0.34 より前の場合、環境変数およびコンテナラベルのみを使用できます。Logtail が 1.0.34 以降の場合、Kubernetes レベルのフィルター(K8s Pod 名、名前空間、コンテナ名、Pod ラベル)を使用できます。以下にコンテナフィルターのオプションを示します。 ログタグのエンリッチメント 環境変数および Pod ラベルからログタグを追加します。 ファイルエンコーディング ログファイルのエンコード形式を選択します。 初回収集サイズ Logtail がファイルから初回収集するデータ量。デフォルト:1,024 KB。範囲:0–10,485,760 KB。ファイルサイズが 1,024 KB より小さい場合、Logtail はファイルの先頭から収集を開始します。ファイルサイズが 1,024 KB より大きい場合、Logtail は最後の 1,024 KB を収集します。 収集ブラックリスト 正確なパスまたはワイルドカード ( *および?) を使用して、収集から除外する特定のディレクトリまたはファイルを指定します。推奨上限:10 エントリ。パスの末尾に/を付与することはできません。ファイルパスブラックリスト、ファイルブラックリスト、ディレクトリブラックリストをサポートします。ファイルを複数回収集することを許可 デフォルトでは、1 つの Logtail 構成のみが特定のファイルからログを収集できます。このオプションを有効化すると、複数の構成が同一ファイルからログを収集できるようになります。 高度なパラメーター 追加パラメーターを手動で設定します。詳細については、「Logtail パイプライン構成の作成」をご参照ください。 [プロセッサ構成]
パラメーター 説明 ログサンプル 実際のシナリオからサンプルログを追加して、処理構成を支援します。総文字数の上限:1,500 文字。 複数行モード 複数行ログエントリを識別します。オプション:[カスタム]([先頭行をマッチさせる正規表現] を使用してログ境界を識別)、[複数行 JSON](各 JSON オブジェクトが複数行にわたる)。[分割失敗時の処理方法] を設定します:[破棄](マッチしなかったログを破棄)または [1 行として保持](各行を個別のログエントリとして保持)。 処理方法 プロセッサデータ処理のためにを追加します。Logtail V2.0 では、ネイティブプロセッサと拡張プロセッサを自由に組み合わせることができます(拡張プロセッサはネイティブプロセッサの後に配置する必要があります)。それより前のバージョンでは、ネイティブプロセッサと拡張プロセッサを混在させることはできません。 インデックスの作成およびデータのプレビューを行い、次に[次へ]をクリックします。全文インデックスはデフォルトで有効になっています。フィールドインデックスを自動的に作成するには、[自動インデックス生成]をクリックします。詳細については、「インデックスの作成」をご参照ください。
重要すべてのフィールドをクエリするにはフルテキストインデックスを使用します。特定のフィールドをクエリし、インデックストラフィックを削減するにはフィールドインデックスを使用します。ログ分析にはフィールドインデックスが必要です(クエリには SELECT 文を含める必要があります)。
[クエリログ] をクリックして、お使いの Logstore のクエリと分析ページに移動します。インデックスが有効になるまで約 1 分待機します。その後、[生ログ] タブで収集されたログを表示できます。詳細については、「ログのクエリと分析ガイド」をご参照ください。
環境変数
環境変数を使用して、Knative サービスの YAML に直接ログ収集を構成します。ログ収集に使用するすべての環境変数名は、aliyun_logs_ プレフィックスで始める必要があります。{key} の部分には、小文字、数字、およびハイフン (-) のみを使用できます。
環境変数ベースの構成は、エッジコンピューティングのシナリオではサポートされていません。
Knative サービス作成時の SLS の有効化
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理対象のクラスターを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、[アプリケーション] > [Knative] を選択します。
[サービス] タブをクリックし、名前空間を選択して、[テンプレートから作成] をクリックします。[カスタム] を [サンプルテンプレート] セクションで選択し、以下の YAML を使用します。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go-log
spec:
template:
spec:
containers:
- name: my-demo-app
image: 'registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest'
env:
# stdout を Logstore "log-stdout" に収集します。
- name: aliyun_logs_log-stdout
value: stdout
# /var/demo/*.log ファイルを Logstore "log-varlog" に収集します。
- name: aliyun_logs_log-varlog
value: /var/demo/*.log
# このコンテナから収集されるすべてのログにカスタムタグを追加します。
- name: aliyun_logs_mytag1_tags
value: tag1=v1
volumeMounts:
- name: volumn-sls-mydemo
mountPath: /var/demo
# オプション:Pod が繰り返し再起動する場合、sleep コマンドを追加できます。
command: ["sh", "-c"]
args: ["sleep 3600"]
volumes:
- name: volumn-sls-mydemo
emptyDir: {}環境変数の動作方法:
aliyun_logs_{key}:{key}は Logstore 名および構成名になります。valueをstdoutに設定するとコンテナの stdout を収集し、ファイルパスに設定するとログファイルを収集します。aliyun_logs_log-stdout: stdoutは Logstorelog-stdoutを作成し、コンテナの stdout を収集します。aliyun_logs_log-varlog: /var/demo/*.logは Logstorelog-varlogを作成し、該当するファイルを収集します。
aliyun_logs_{key}_tags:コンテナから収集されるすべてのログにタグを追加します。フォーマット:{tag-key}={tag-value}。{key}はタグ名(アンダースコアなし)です。volumeMounts:stdout 以外のログファイルを収集する場合に必須です。mountPathは、ログパス変数内のディレクトリと一致する必要があります。
[作成] をクリックして構成を送信します。
(オプション)高度な環境変数設定
| 変数 | 必須 | 説明 | 例 | 備考 |
|---|---|---|---|---|
aliyun_logs_{key} | はい | ログソースを指定します。stdout またはログファイルパスを設定します。{key} という名前の Logstore を作成します(aliyun_logs_{key}_logstore が設定されていない場合)。 | value: stdout または value: /var/log/nginx/access.log | デフォルトではシンプルモードでログが収集されます。解析を行う場合は、SLS コンソールまたは CRD を使用してください。 |
aliyun_logs_{key}_tags | いいえ | ログにタグを追加します。フォーマット:{tag-key}={tag-value}。 | value: app=catalina | — |
aliyun_logs_{key}_project | いいえ | SLS プロジェクトを指定します。デフォルトでは、Logtail インストール時に作成されたプロジェクトが使用されます。 | value: my-k8s-project | プロジェクトは Logtail と同じリージョンにある必要があります。 |
aliyun_logs_{key}_logstore | いいえ | Logstore 名を指定します。デフォルトは {key} です。 | value: my-logstore | — |
aliyun_logs_{key}_shard | いいえ | Logstore のシャード数。有効な値:1~10。デフォルト:2。 | value: '4' | Logstore が既に存在する場合、この設定は無効です。 |
aliyun_logs_{key}_ttl | いいえ | ログの保持期間(日数)。有効な値:1~3650。永続保存の場合は 3650 を設定します。デフォルト:90 日。 | value: '3650' | Logstore が既に存在する場合、この設定は無効です。 |
aliyun_logs_{key}_machinegroup | いいえ | アプリケーションがデプロイされているマシングループ。デフォルトでは Logtail のマシングループが使用されます。 | value: my-machine-group | 「ACK クラスターからのコンテナログ収集」をご参照ください。 |
aliyun_logs_{key}_logstoremode | いいえ | Logstore のタイプ。デフォルト:standard。オプション:standard(ログ分析、リアルタイムモニタリング、インタラクティブな分析をサポート)、query(高性能クエリ;インデックス料金は standard の約半分;SQL 分析不可;大量データまたは長期保持(分析を行わない場合)に適しています — ログを数週間または数か月保存する場合、ログの保持期間は長期と見なされます)。 | value: standard または value: query | logtail-ds イメージのバージョンが v1.3.1 以降である必要があります。Logstore が既に存在する場合、この設定は無効です。 |
手順 3:ログのクエリおよび分析
Simple Log Service コンソールにログインします。
[プロジェクト] セクションで、プロジェクトをクリックして詳細ページを開きます。

左側のナビゲーションウィンドウで、Logstore の横にある
アイコンをクリックし、ドロップダウンリストから [検索と分析] を選択します。
インデックスが有効になるまで約 1 分待ち、その後 [生ログ] タブでログを表示できます。詳細については、「ログのクエリと分析ガイド」をご参照ください。
コンテナテキストログのデフォルトフィールド
各コンテナテキストログには、以下のフィールドがデフォルトで含まれています。
| フィールド | 説明 |
|---|---|
__tag__:__hostname__ | コンテナホストの名前 |
__tag__:__path__ | コンテナ内のログファイルパス |
__tag__:_container_ip_ | コンテナの IP アドレス |
__tag__:_image_name_ | コンテナで使用されるイメージの名前 |
__tag__:_pod_name_ | Pod の名前 |
__tag__:_namespace_ | Pod の名前空間 |
__tag__:_pod_uid_ | Pod の UID |
次のステップ
ログ収集エラーのトラブルシューティングを行うには、詳細については、「Logtail のログ収集エラーを確認する方法は?」と「コンテナからログを収集する際にエラーが発生した場合はどうすればよいですか?」をご参照ください。
DaemonSet を使用して ACK クラスターからのテキストログを収集するための Logtail のデプロイについては、「ACK クラスターからのコンテナログ収集」をご参照ください。
Knative モニタリングダッシュボードの表示については、「Knative モニタリングダッシュボードの表示」をご参照ください。
Knative サービスのモニタリングアラートの設定については、「Knative サービスのアラート機能の設定」をご参照ください。