Container Service for Kubernetes:Knative で SLS を有効にする

LoongCollector をインストールする

LoongCollector ベースのデータ収集：LoongCollector は、Simple Log Service が提供する新世代のログ収集エージェントです。LoongCollector は Logtail のアップグレードバージョンです。LoongCollector は、Managed Service for Prometheus ベースのデータ収集や Extended Berkeley Packet Filter (eBPF) テクノロジーベースの非侵入型データ収集など、Application Real-Time Monitoring Service (ARMS) の特定の収集エージェントの機能を統合することが期待されています。

LoongCollector コンポーネントがインストールされると、Simple Log Service は k8s-log-${your_k8s_cluster_id} という名前のプロジェクトと、プロジェクト内のリソースを自動的に生成します。Simple Log Service コンソールにログインして、リソースを表示できます。次の表にリソースを示します。

Logtail をインストールする

Logtail ベースのデータ収集：Logtail は、Simple Log Service が提供するログ収集エージェントです。Logtail を使用すると、Alibaba Cloud Elastic Compute Service (ECS) インスタンス、データセンター内のサーバー、サードパーティ クラウド サービス プロバイダーのサーバーなど、複数のデータソースからログを収集できます。Logtail は、ログファイルに基づく非侵入型のログ収集をサポートしています。アプリケーションコードを変更する必要はなく、ログ収集はアプリケーションの動作に影響を与えません。

Logtail コンポーネントがインストールされると、Simple Log Service は k8s-log-<YOUR_CLUSTER_ID> という名前のプロジェクトと、プロジェクト内のリソースを自動的に生成します。Simple Log Service コンソールにログインして、リソースを表示できます。次の表にリソースを示します。

(推奨) CRD - AliyunPipelineConfig

Logtail 構成を作成する

Logtail 構成を作成するには、AliyunPipelineConfig CRD から CR を作成するだけです。Logtail 構成が作成されると、自動的に適用されます。CR に基づいて作成された Logtail 構成を変更する場合は、CR を変更する必要があります。

1. クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する。

2. 次のコマンドを実行して YAML ファイルを作成します。

   次のコマンドでは、cube.yaml はサンプルファイル名です。ビジネス要件に基づいて別のファイル名を指定できます。

   vim cube.yaml

3. YAML ファイルに次のスクリプトを入力し、ビジネス要件に基づいてパラメーターを構成します。

   重要

   • configName パラメーターの値は、Logtail コンポーネントのインストールに使用する Simple Log Service プロジェクト内で一意である必要があります。

   • Logtail 構成ごとに CR を構成する必要があります。複数の CR が同じ Logtail 構成に関連付けられている場合、最初の CR 以外の CR は有効になりません。

   • AliyunPipelineConfig CRD に関連するパラメーターの詳細については、「(推奨) AliyunPipelineConfig を使用して Logtail 構成を管理する」をご参照ください。この例では、Logtail 構成にテキストログ収集の設定が含まれています。詳細については、「CreateLogtailPipelineConfig」をご参照ください。

   • config.flushers.Logstore パラメーターで指定されたログストアが存在することを確認します。 spec.logstore パラメーターを設定して、ログストアを自動的に作成できます。

   • Endpoint パラメーターと Region パラメーターの値については、「エンドポイント」をご参照ください。Region パラメーターは、cn-hangzhou などのリージョン ID を示します。

   特定のコンテナーから単一行テキストログを収集する

   この例では、example-k8s-file という名前の Logtail 構成を作成して、名前が app を含むコンテナーから単一行テキストログを収集します。ファイルは test.LOG で、パスは /data/logs/app_1 です。

   収集されたログは、k8s-log-test という名前のプロジェクトに属する 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
     # ログを格納するログストアを作成します。
     logstores:
       - name: k8s-file
     # Logtail 構成のパラメーターを構成します。
     config:
       # Logtail 入力プラグインを構成します。
       inputs:
         # input_file プラグインを使用して、コンテナーからテキストログを収集します。
         - Type: input_file
           # コンテナー内のファイルパスを指定します。
           FilePaths:
             - /data/logs/app_1/**/test.LOG
           # コンテナー検出機能を有効にします。
           EnableContainerDiscovery: true
           # 条件を追加してコンテナーをフィルタリングします。複数の条件は論理 AND を使用して評価されます。
           ContainerFilters:
             # 必要なコンテナーが属するポッドの名前空間を指定します。正規表現マッチングがサポートされています。
             K8sNamespaceRegex: default
             # 必要なコンテナーの名前を指定します。正規表現マッチングがサポートされています。
             K8sContainerRegex: ^(.*app.*)$
       # Logtail 出力プラグインを構成します。
       flushers:
         # flusher_sls プラグインを使用して、ログを特定のログストアに送信します。
         - Type: flusher_sls
           # ログストアが存在することを確認します。
           Logstore: k8s-file
           # エンドポイントが有効であることを確認します。Region フィールドには、リージョン ID を入力します。
           Endpoint: cn-hangzhou.log.aliyuncs.com
           Region: cn-hangzhou
           TelemetryType: logs

   すべてのコンテナーから複数行テキストログを収集し、正規表現を使用してログを解析する

   この例では、example-k8s-file という名前の Logtail 構成を作成して、クラスタ内のすべてのコンテナーから複数行テキストログを収集します。ファイルは test.LOG で、パスは /data/logs/app_1 です。収集されたログは JSON モードで解析され、k8s-log-test という名前のプロジェクトに属する k8s-file という名前のログストアに格納されます。

   次の例で提供されているサンプルログは、{"content": "2024-06-19 16:35:00 INFO test log\nline-1\nline-2\nend"} 形式で input_file プラグインによって読み取られます。次に、ログは正規表現に基づいて {"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:
     # リソースの名前を指定します。名前は、現在の Kubernetes クラスタ内で一意である必要があります。名前は、作成される Logtail 構成の名前と同じです。
     name: example-k8s-file
   spec:
     # ログが収集されるプロジェクトを指定します。
     project:
       name: k8s-log-test
     # ログを格納するログストアを作成します。
     logstores:
       - name: k8s-file
     # Logtail 構成のパラメーターを構成します。
     config:
       # サンプルログを指定します。このパラメーターは空のままにすることができます。
       sample: |
         2024-06-19 16:35:00 INFO test log
         line-1
         line-2
         end
       # Logtail 入力プラグインを構成します。
       inputs:
         # input_file プラグインを使用して、コンテナーから複数行テキストログを収集します。
         - Type: input_file
           # コンテナー内のファイルパスを指定します。
           FilePaths:
             - /data/logs/app_1/**/test.LOG
           # コンテナー検出機能を有効にします。
           EnableContainerDiscovery: true
           # 複数行ログ収集を有効にします。
           Multiline:
             # カスタムモードを指定して、正規表現に基づいてログの最初の行の先頭を照合します。
             Mode: custom
             # ログの最初の行の先頭を照合するために使用される正規表現を指定します。
             StartPattern: \d+-\d+-\d+.*
       # Logtail 処理プラグインを指定します。
       processors:
         # processor_parse_regex_native プラグインを使用して、指定された正規表現に基づいてログを解析します。
         - Type: processor_parse_regex_native
           # 入力フィールドの名前を指定します。
           SourceKey: content
           # 解析に使用する正規表現を指定します。キャプチャグループを使用してフィールドを抽出します。
           Regex: (\d+-\d+-\d+\s*\d+:\d+:\d+)\s*(\S+)\s*(.*)
           # 抽出するフィールドを指定します。
           Keys: ["time", "level", "msg"]
       # Logtail 出力プラグインを構成します。
       flushers:
         # flusher_sls プラグインを使用して、ログを特定のログストアに送信します。
         - Type: flusher_sls
           # ログストアが存在することを確認します。
           Logstore: k8s-file
           # エンドポイントが有効であることを確認します。
           Endpoint: cn-hangzhou.log.aliyuncs.com
           Region: cn-hangzhou
           TelemetryType: logs

4. 次のコマンドを実行して、Logtail 構成を適用します。Logtail 構成が適用されると、Logtail は指定されたコンテナーからテキストログの収集を開始し、Simple Log Service にログを送信します。

   次のコマンドでは、cube.yaml はサンプルファイル名です。ビジネス要件に基づいて別のファイル名を指定できます。

   kubectl apply -f cube.yaml

   重要

   ログが収集された後、インデックスを作成する必要があります。その後、Logstore 内のログをクエリおよび分析できます。詳細については、「インデックスを作成する」をご参照ください。

CRD - AliyunLogConfig

Logtail 構成を作成するには、AliyunLogConfig CRD から CR を作成するだけで済みます。Logtail 構成が作成されると、自動的に適用されます。CR に基づいて作成された Logtail 構成を変更する場合は、CR を変更する必要があります。

1. クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する。

2. 次のコマンドを実行して YAML ファイルを作成します。

   次のコマンドでは、cube.yaml はサンプルのファイル名です。ビジネス要件に基づいて別のファイル名を指定できます。

   vim cube.yaml

3. YAML ファイルに次のスクリプトを入力し、ビジネス要件に基づいてパラメーターを構成します。

   重要

   • configName パラメーターの値は、Logtail コンポーネントのインストールに使用する Simple Log Service プロジェクト内で一意である必要があります。

   • 複数の CR が同じ Logtail 構成に関連付けられている場合、CR のいずれかを削除または変更すると、Logtail 構成が影響を受けます。CR が削除または変更されると、他の関連付けられた CR のステータスは、Simple Log Service の Logtail 構成のステータスと一致しなくなります。

   • CR パラメーターの詳細については、「AliyunLogConfig を使用して Logtail 構成を管理する」をご参照ください。この例では、Logtail 構成には、テキストログ収集の設定が含まれています。詳細については、「CreateConfig」をご参照ください。

   特定のコンテナーから単一行テキストログを収集する

   この例では、example-k8s-file という名前の Logtail 構成が作成され、クラスター内で名前が app で始まるすべてのポッドのコンテナーから単一行テキストログが収集されます。ファイルは test.LOG で、パスは /data/logs/app_1 です。収集されたログは、k8s-log-test という名前のプロジェクトに属する k8s-file という名前のログストアに保存されます。

   apiVersion: log.alibabacloud.com/v1alpha1
   kind: AliyunLogConfig
   metadata:
     # リソースの名前を指定します。名前は、現在の Kubernetes クラスター内で一意である必要があります。
     name: example-k8s-file
     namespace: kube-system
   spec:
     # プロジェクトの名前を指定します。このパラメーターを空のままにすると、k8s-log-<your_cluster_id> という名前のプロジェクトが使用されます。
     project: k8s-log-test
     # ログストアの名前を指定します。指定されたログストアが存在しない場合、Simple Log Service は自動的にログストアを作成します。
     logstore: k8s-file
     # Logtail 構成のパラメーターを構成します。
     logtailConfig:
       # データソースのタイプを指定します。テキストログを収集する場合は、値を file に設定します。
       inputType: file
       # Logtail 構成の名前を指定します。
       configName: example-k8s-file
       inputDetail:
         # テキストログを収集するためのシンプルモードを指定します。
         logType: common_reg_log
         # ログファイルのパスを指定します。
         logPath: /data/logs/app_1
         # ログファイル名を指定します。ログファイル名を指定するときに、ワイルドカード文字 (* および ?) を使用できます。例: log_*.log。
         filePattern: test.LOG
         # コンテナーからテキストログを収集する場合は、true に設定します。
         dockerFile: true
         # コンテナーをフィルタリングするための条件を指定します。
         advanced:
           k8s:
             K8sPodRegex: '^(app.*)$'

4. 次のコマンドを実行して、Logtail 構成を適用します。Logtail 構成が適用されると、Logtail は指定されたコンテナーからテキストログの収集を開始し、ログを Simple Log Service に送信します。

   次のコマンドでは、cube.yaml はサンプルのファイル名です。ビジネス要件に基づいて別のファイル名を指定できます。

   kubectl apply -f cube.yaml

   重要

   ログが収集されたら、インデックスを作成する必要があります。その後、ログストア内のログをクエリおよび分析できます。詳細については、「インデックスを作成する」をご参照ください。

コンソール

1. Simple Log Service コンソール にログオンします。

2. [クイックデータインポート] セクションで、[データのインポート] をクリックします。[データのインポート] ダイアログボックスで、[Kubernetes - ファイル] カードをクリックします。

   

3. 必要なプロジェクトとログストアを選択します。次に、[次へ] をクリックします。この例では、Logtail コンポーネントのインストールに使用するプロジェクトと、作成したログストアを選択します。

4. [マシングループの構成] ステップで、次の操作を実行します。詳細については、「マシングループ」をご参照ください。

   1. ビジネス要件に基づいて、次の設定のいずれかを使用します。

      • [Kubernetes クラスター] > [ACK Daemonset]

      • [Kubernetes クラスター] > [DaemonSet モードのセルフマネージドクラスター]

        重要

        後続の設定は、上記の設定によって異なります。

   2. 必要なマシングループが [適用済みサーバーグループ] セクションに追加されていることを確認します。次に、[次へ] をクリックします。Container Service for Kubernetes (ACK) クラスターに Logtail コンポーネントをインストールすると、Simple Log Service によって k8s-group-${your_k8s_cluster_id} という名前のマシングループが自動的に作成されます。このマシングループを直接使用できます。

      重要

      • マシングループを作成するには、[マシングループの作成] をクリックします。表示されるパネルで、パラメーターを構成してマシングループを作成します。詳細については、「ACK クラスターからコンテナーログを収集する」をご参照ください。

      • マシングループのハートビートステータスが [失敗] の場合は、[自動再試行] をクリックします。問題が解決しない場合は、「ホスト環境の Logtail マシングループに関連するエラーのトラブルシューティング方法」をご参照ください。

5. Logtail 構成を作成し、[次へ] をクリックします。Logtail 構成が作成されると、Simple Log Service はログの収集を開始します。

   説明

   Logtail 構成が有効になるまで最大 3 分かかります。

   グローバル構成

   パラメーター	説明
   構成名	Logtail 構成の名前を入力します。名前はプロジェクト内で一意である必要があり、後で変更することはできません。
   ログトピックタイプ	ログトピックを生成する方法を選択します。詳細については、「ログトピック」をご参照ください。 [マシングループトピック]: マシングループのトピックがログトピックとして使用されます。このオプションを選択すると、異なるマシングループからのログを区別できます。 [ファイルパス抽出]: カスタム正規表現を指定します。正規表現に一致するファイルパスの一部がログトピックとして使用されます。このオプションを選択すると、異なるソースからのログを区別できます。 [カスタム]: カスタムログトピックを指定します。
   詳細パラメーター	オプション。グローバル構成に関連する詳細パラメーターを構成します。詳細については、「CreateLogtailPipelineConfig」をご参照ください。

   入力構成

   パラメーター	説明
   [Logtail デプロイメントモード]	Logtail のデプロイメントモードを選択します。この例では、Daemonset が選択されています。
   [ファイルパスの種類]	ログの収集に使用するファイルパスの種類を選択します。有効な値: コンテナー内のパスとホストパス。 hostPath ボリュームがコンテナーにマウントされていて、コンテナーホスト上のマップされたファイルパスに基づいてファイルからログを収集する場合は、このパラメーターを [ホストパス] に設定します。その他のシナリオでは、このパラメーターを [コンテナー内のパス] に設定します。
   [ファイルパス]	必要なコンテナーが Linux ホストで実行されている場合は、スラッシュ (/) で始まるパスを指定します。例: /apsara/nuwa/**/app.Log。 必要なコンテナーが Windows ホストで実行されている場合は、ドライブ文字で始まるパスを指定します。例: C:\Program Files\Intel\**\*.Log。 正確なディレクトリと正確な名前を指定できます。また、ワイルドカードを使用してディレクトリと名前を指定することもできます。詳細については、「ワイルドカードマッチング」をご参照ください。このパラメーターを構成する場合は、ワイルドカードとしてアスタリスク (*) または疑問符 (?) のみを使用してください。 Simple Log Service は、指定されたディレクトリのすべてのレベルをスキャンして、指定された条件に一致するログファイルを検索します。例: /apsara/nuwa/**/*.log を指定すると、Simple Log Service は、/apsara/nuwa ディレクトリとそのディレクトリの再帰的なサブディレクトリにある、名前が .log で終わるログファイルからログを収集します。 /var/logs/app_*/**/*.log を指定すると、Simple Log Service は、次の条件を満たすログファイルからログを収集します。ファイル名は .log で終わります。ファイルは、/var/logs ディレクトリの下のサブディレクトリ、またはそのサブディレクトリの再帰的なサブディレクトリに保存されています。サブディレクトリの名前は app_* パターンに一致します。 /var/log/nginx/**/access* を指定すると、Simple Log Service は /var/log/nginx ディレクトリとそのディレクトリの再帰的なサブディレクトリにある、名前が access で始まるログファイルからログを収集します。
   [ディレクトリ監視の最大深度]	監視するサブディレクトリの最大レベル数を指定します。サブディレクトリは、指定したログファイルディレクトリにあります。このパラメーターは、[ファイルパス] の値に含まれるワイルドカード ** に一致させることができるサブディレクトリのレベルを指定します。値 0 は、指定したログファイルディレクトリのみが監視されることを指定します。 警告 最小要件に基づいてこのパラメーターを構成することをお勧めします。大きな値を指定すると、Logtail がより多くの監視リソースを消費し、収集の遅延が発生する可能性があります。
   [コンテナーメタデータプレビューの有効化]	[コンテナーメタデータプレビューの有効化] をオンにすると、Logtail 構成を作成した後に、一致するコンテナー情報と完全なコンテナー情報を含むコンテナーメタデータを表示できます。
   [コンテナーフィルタリング]	Logtail バージョン Logtail のバージョンが 1.0.34 より前の場合、[環境変数] と [コンテナーラベル] のみを使用してコンテナーをフィルタリングできます。 Logtail のバージョンが 1.0.34 以降の場合は、異なるレベルの Kubernetes 情報を使用してコンテナーをフィルタリングすることをお勧めします。情報には、[K8s ポッド名正規表現マッチング]、[K8s 名前空間正規表現マッチング]、[K8s コンテナー名正規表現マッチング]、[Kubernetes ポッドラベルホワイトリスト] が含まれます。 フィルター条件 重要 コンテナーラベルは、docker inspect コマンドを実行することで取得されます。コンテナーラベルは Kubernetes ラベルとは異なります。詳細については、「ラベルを取得する」をご参照ください。 環境変数は、コンテナーを起動するために構成された環境変数と同じです。詳細については、「環境変数を取得する」をご参照ください。 Kubernetes 名前空間とコンテナー名は、コンテナーラベルにマッピングできます。名前空間のラベルは io.kubernetes.pod.namespace です。コンテナー名のラベルは io.kubernetes.container.name です。これらの 2 つのラベルを使用してコンテナーをフィルタリングすることをお勧めします。たとえば、ポッドの名前空間が backend-prod で、ポッド内のコンテナーの名前が worker-server であるとします。 worker-server コンテナーのログを収集する場合、コンテナーラベルのホワイトリストに io.kubernetes.pod.namespace : backend-prod または io.kubernetes.container.name : worker-server を指定できます。 2 つのラベルがビジネス要件を満たしていない場合は、環境変数ホワイトリストまたは環境変数ブラックリストを使用してコンテナーをフィルタリングできます。 K8s ポッド名正規表現マッチング ポッド名を入力します。ポッド名は、テキストログが収集されるコンテナーを指定します。正規表現マッチングがサポートされています。たとえば、^(nginx-log-demo.*)$ を指定すると、nginx-log-demo で始まる名前のポッド内のすべてのコンテナーが一致となります。 K8s 名前空間の正規表現マッチング 名前空間名を入力します。名前空間名は、テキストログが収集されるコンテナーを指定します。正規表現マッチングがサポートされています。たとえば、^(default|nginx)$ を指定すると、nginx 名前空間と default 名前空間のすべてのコンテナーが一致となります。 K8s コンテナー名正規表現マッチング コンテナー名を入力します。 コンテナー名は、テキストログが収集されるコンテナーを指定します。 正規表現マッチングがサポートされています。 Kubernetes コンテナー名は spec.containers で定義されています。 たとえば、^(container-test)$ を指定すると、名前が container-test であるすべてのコンテナーが一致となります。 コンテナラベルのホワイトリスト コンテナラベルのホワイトリストを設定します。ホワイトリストは、テキストログが収集されるコンテナを指定します。 注記 [ラベル名] パラメーターに重複する値を指定しないでください。重複する値を指定すると、1 つの値のみが有効になります。 [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定されたラベル名を含むコンテナラベルを持つコンテナが一致とみなされます。 [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定された Label Name:Label Value を含むコンテナラベルを持つコンテナが一致とみなされます。 デフォルトでは、[ラベル値] パラメーターの値に対して文字列マッチングが実行されます。コンテナラベルの値が [ラベル値] パラメーターの値と同じ場合にのみ、コンテナは一致とみなされます。キャレット (^) で始まり、ドル記号 ($) で終わる値を [ラベル値] パラメーターに指定すると、正規表現マッチングが実行されます。たとえば、[ラベル名] パラメーターを app に設定し、[ラベル値] パラメーターを ^(test1|test2)$ に設定すると、コンテナラベルに app:test1 または app:test2 が含まれるコンテナが一致とみなされます。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナに、指定されたキーと値のペアのいずれか 1 つで構成されるコンテナラベルがある場合、そのコンテナは一致とみなされます。 コンテナーラベルブラックリスト コンテナーラベルブラックリストを構成します。ブラックリストは、テキストログが収集されないコンテナーを指定します。 注記 [ラベル名] パラメーターに重複する値を指定しないでください。重複する値を指定すると、1つの値のみが有効になります。 [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定されたラベル名を含むコンテナーラベルを持つコンテナーは除外されます。 [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定された Label Name:Label Value を含むコンテナーラベルを持つコンテナーは除外されます。 デフォルトでは、[ラベル値] パラメーターの値に対して文字列マッチングが実行されます。コンテナーラベルの値が [ラベル値] パラメーターの値と同じ場合にのみ、コンテナーは除外されます。キャレット (^) で始まり、ドル記号 ($) で終わる値を [ラベル値] パラメーターに指定すると、正規表現マッチングが実行されます。たとえば、[ラベル名] パラメーターを app に設定し、[ラベル値] パラメーターを ^(test1|test2)$ に設定すると、コンテナーラベルに app:test1 または app:test2 が含まれるコンテナーは除外されます。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナーに、指定されたキーと値のペアのいずれか 1 つで構成されるコンテナーラベルがある場合、そのコンテナーは除外されます。 環境変数ホワイトリスト 環境変数ホワイトリストを設定します。ホワイトリストは、テキストログが収集されるコンテナーを指定します。 [環境変数名] パラメーターの値を指定し、[環境変数値] パラメーターの値を指定しない場合、指定された環境変数名を含む環境変数を持つコンテナーが一致とみなされます。 [環境変数名] パラメーターと [環境変数値] パラメーターの値を指定した場合、指定された環境変数名:環境変数値を含む環境変数を持つコンテナーが一致とみなされます。 デフォルトでは、[環境変数値] パラメーターの値に対して文字列マッチングが実行されます。コンテナーは、環境変数の値が [環境変数値] パラメーターの値と同じ場合にのみ一致します。環境変数値パラメーターに、キャレット (^) で始まりドル記号 ($) で終わる値を指定すると、正規表現マッチングが実行されます。たとえば、[環境変数名] パラメーターを NGINX_SERVICE_PORT に設定し、[環境変数値] パラメーターを ^(80|6379)$ に設定すると、ポート番号が 80 または 6379 のコンテナーが一致とみなされます。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナーに、指定されたキーと値のペアのいずれか 1 つで構成される環境変数が含まれている場合、そのコンテナーは一致とみなされます。 環境変数ブラックリスト 環境変数ブラックリストを構成します。ブラックリストは、テキストログが収集されないコンテナーを指定します。 [環境変数名] パラメーターの値を指定し、[環境変数値] パラメーターの値を指定しない場合、指定された環境変数名を含む環境変数を持つコンテナーは除外されます。 [環境変数名] パラメーターと [環境変数値] パラメーターの値を指定した場合、指定された環境変数名: 環境変数値を含む環境変数を持つコンテナーは除外されます。 デフォルトでは、[環境変数値] パラメーターの値に対して文字列マッチングが実行されます。環境変数の値が [環境変数値] パラメーターの値と同じ場合にのみ、コンテナーは除外されます。キャレット (^) で始まり、ドル記号 ($) で終わる値を環境変数値パラメーターに指定すると、正規表現マッチングが実行されます。たとえば、[環境変数名] パラメーターを NGINX_SERVICE_PORT に設定し、[環境変数値] パラメーターを ^(80|6379)$ に設定すると、ポート番号が 80 または 6379 のコンテナーは除外されます。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナーに、指定されたキーと値のペアのいずれか 1 つで構成される環境変数が含まれている場合、そのコンテナーは除外されます。 Kubernetes ポッドラベルのホワイトリスト Kubernetes ポッドラベルのホワイトリストを設定します。ホワイトリストは、テキストログが収集されるコンテナーを指定します。 [ラベル名] パラメーターの値を指定し、[ラベル値] パラメーターの値を指定しない場合、指定されたラベル名を含むポッドラベルを持つコンテナーが一致とみなされます。 [ラベル名] パラメーターと [ラベル値] パラメーターの値を指定した場合、指定された Label Name:Label Value を含むポッドラベルを持つコンテナーが一致とみなされます。 デフォルトでは、[ラベル値] パラメーターの値に対して文字列マッチングが実行されます。 コンテナーが一致するのは、ポッドラベルの値が [ラベル値] パラメーターの値と同じ場合のみです。 キャレット (^) で始まり、ドル記号 ($) で終わる値を指定すると、正規表現マッチングが実行されます。 たとえば、[ラベル名] パラメーターを environment に設定し、[ラベル値] パラメーターを ^(dev|pre)$ に設定すると、ポッドラベルに environment:dev または environment:pre が含まれるコンテナーが一致となります。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナーが、指定されたキーと値のペアのいずれか 1 つで構成されるポッドラベルを持っている場合、そのコンテナーは一致とみなされます。 Kubernetes ポッドラベルブラックリスト Kubernetes ポッドラベルブラックリストを構成します。ブラックリストは、テキストログが収集されないコンテナーを指定します。 [ラベル名] パラメーターに値を指定し、[ラベル値] パラメーターに値を指定しない場合、指定されたラベル名を含むポッドラベルを持つコンテナーは除外されます。 [ラベル名] パラメーターと [ラベル値] パラメーターに値を指定した場合、指定されたラベル名:ラベル値を含むポッドラベルを持つコンテナーは除外されます。 デフォルトでは、[ラベル値] パラメーターの値に対して文字列マッチングが実行されます。コンテナーは、ポッドラベルの値が [ラベル値] パラメーターの値と同じ場合にのみ除外されます。 (^) で始まり ($) で終わる値をラベル値パラメーターに指定すると、正規表現マッチングが実行されます。たとえば、[ラベル名] パラメーターを environment に設定し、[ラベル値] パラメーターを ^(dev|pre)$ に設定すると、environment:dev または environment:pre を含むポッドラベルを持つコンテナーは除外されます。 キーと値のペアは、OR 演算子を使用して評価されます。コンテナーに、指定されたキーと値のペアのいずれか 1 つで構成されるポッドラベルがある場合、そのコンテナーは除外されます。
   [ログ タグ エンリッチメント]	環境変数とポッドラベルを使用してログタグを指定します。
   ファイルエンコード	ログファイルのエンコード形式を選択します。
   初回収集サイズ	Logtail がログ ファイルから初めてログを収集するときに、Logtail が収集できるデータサイズを指定します。初回収集サイズのデフォルト値は 1024 です。単位：KB。 ファイルサイズが 1,024 KB 未満の場合、Logtail はファイルの先頭からデータを収集します。 ファイルサイズが 1,024 KB を超える場合、Logtail はファイルの最後の 1,024 KB のデータを収集します。 ビジネス要件に基づいて [初回収集サイズ] を指定できます。有効な値：0 ～ 10485760。単位：KB。
   収集ブラックリスト	[収集ブラックリスト] を有効にした場合は、Simple Log Service がログ収集時にスキップするディレクトリまたはファイルを指定するために、ブラックリストを設定する必要があります。正確なディレクトリとファイル名を指定できます。また、ワイルドカード文字を使用してディレクトリとファイル名を指定することもできます。このパラメーターを設定する場合は、ワイルドカード文字としてアスタリスク（*）または疑問符（?）のみを使用してください。 重要 ワイルドカード文字を使用して [ファイルパス] を設定し、指定したディレクトリ内の一部のディレクトリをスキップする場合は、[収集ブラックリスト] を設定し、完全なディレクトリを入力する必要があります。 たとえば、[ファイルパス] を /home/admin/app*/log/*.log に設定し、/home/admin/app1* ディレクトリ内のすべてのサブディレクトリをスキップする場合は、[ディレクトリブラックリスト] を選択し、[ディレクトリ名] フィールドに /home/admin/app1*/** と入力する必要があります。/home/admin/app1* と入力した場合、ブラックリストは有効になりません。 ブラックリストを使用している場合、計算オーバーヘッドが発生します。ブラックリストには最大 10 個のエントリを追加することをお勧めします。 スラッシュ（/）で終わるディレクトリパスを指定することはできません。たとえば、パスを /home/admin/dir1/ に設定した場合、ディレクトリブラックリストは有効になりません。 次の種類のブラックリストがサポートされています。ファイルパスブラックリスト、ファイルブラックリスト、およびディレクトリブラックリスト。 ファイルパスブラックリスト [ファイルパスブラックリスト] を選択し、[ファイルパス名] フィールドに /home/admin/private*.log と入力すると、/home/admin/ ディレクトリ内の private で始まる名前と .log で終わる名前のすべてのファイルがスキップされます。 [ファイルパスブラックリスト] を選択し、[ファイルパス名] フィールドに /home/admin/private*/*_inner.log と入力すると、/home/admin/ ディレクトリ内の private で始まる名前のサブディレクトリ内にある _inner.log で終わる名前のすべてのファイルがスキップされます。たとえば、/home/admin/private/app_inner.log ファイルはスキップされますが、/home/admin/private/app.log ファイルはスキップされません。 ファイルブラックリスト [ファイルブラックリスト] を選択し、[ファイル名] フィールドに app_inner.log と入力すると、名前が app_inner.log であるすべてのファイルがスキップされます。 ディレクトリブラックリスト [ディレクトリブラックリスト] を選択し、[ディレクトリ名] フィールドに /home/admin/dir1 と入力すると、/home/admin/dir1 ディレクトリ内のすべてのファイルがスキップされます。 [ディレクトリブラックリスト] を選択し、[ディレクトリ名] フィールドに /home/admin/dir* と入力すると、/home/admin/ ディレクトリ内の dir で始まる名前のすべてのサブディレクトリ内のファイルがスキップされます。 [ディレクトリブラックリスト] を選択し、[ディレクトリ名] フィールドに /home/admin/*/dir と入力すると、/home/admin/ ディレクトリの各第 2 レベルのサブディレクトリ内の dir サブディレクトリ内のすべてのファイルがスキップされます。たとえば、/home/admin/a/dir ディレクトリ内のファイルはスキップされますが、/home/admin/a/b/dir ディレクトリ内のファイルはスキップされません。
   複数回のファイル収集を許可	デフォルトでは、1 つの Logtail 構成のみを使用してログファイルからログを収集できます。複数の Logtail 構成を使用してログファイルからログを収集するには、[複数回のファイル収集を許可] をオンにします。
   [詳細パラメーター]	Logtail 構成の特定のパラメーターを手動で構成する必要があります。詳細については、「Logtail パイプライン構成を作成する」をご参照ください。

   プロセッサ構成

   パラメーター	説明
   ログサンプル	実際のシナリオから収集されたサンプルログを追加します。 サンプルログを使用すると、ログ処理に関連するパラメーターを簡単に構成できます。 複数のサンプルログを追加できます。 ログの合計の長さが 1,500 文字を超えないようにしてください。 [2023-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happened at TestPrintStackTrace.f(TestPrintStackTrace.java:3) at TestPrintStackTrace.g(TestPrintStackTrace.java:7) at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
   複数行モード	複数行ログのタイプを指定します。 複数行ログは、複数の連続した行にまたがっています。 このパラメーターを構成して、ログファイル内の各複数行ログを識別できます。 [カスタム]: 複数行ログは、[最初の行と一致する正規表現] の値に基づいて識別されます。 [複数行 JSON]: 各 JSON オブジェクトは複数行に展開されます。 例： { "name": "John Doe", "age": 30, "address": { "city": "New York", "country": "USA" } } [分割に失敗した場合の処理方法] を構成します。 Exception in thread "main" java.lang.NullPointerException at com.example.MyClass.methodA(MyClass.java:12) at com.example.MyClass.methodB(MyClass.java:34) at com.example.MyClass.main(MyClass.java:½0) 上記のサンプルログの場合、Simple Log Service は、ログの分割に失敗した場合、ログを破棄するか、各単一行をログとして保持できます。 [破棄]: ログは破棄されます。 [単一行を保持]: ログテキストの各行はログとして保持されます。 合計 4 つのログが保持されます。
   処理方法	必要に応じて プロセッサ を追加します。 データ処理用にネイティブプロセッサと拡張プロセッサを追加できます。 重要 プロセッサの使用制限については、コンソールページのプロンプトを参照してください。 Logtail V2.0 データ処理のためにネイティブプロセッサを任意に組み合わせることができます。 ネイティブプロセッサと拡張プロセッサを組み合わせることができます。 拡張プロセッサは、シーケンス内のネイティブプロセッサの後に続く必要があります。 V2.0 より前の Logtail ネイティブプロセッサと拡張プロセッサを同時に追加することはできません。 ネイティブプロセッサを使用してテキストログのみを収集できます。 追加する際は、次の点に注意してください。 最初に、次の Logtail プロセッサのいずれかを追加する必要があります。 データ解析 (正規表現モード)、データ解析 (区切り文字モード)、データ解析 (JSON モード)、データ解析 (NGINX モード)、データ解析 (Apache モード)、およびデータ解析 (IIS モード)。 最初のプロセッサを追加した後、時間解析プロセッサ、データフィルタリングプロセッサ、および複数のデータマスキングプロセッサを追加できます。 [解析に失敗した場合に元のフィールドを保持する] パラメーターと [解析に成功した場合に元のフィールドを保持する] パラメーターを構成する場合、使用できるパラメーターの組み合わせは次のとおりです。 その他の場合、Simple Log Service は構成効果を保証しません。 解析されたログをアップロードします。 解析に成功した後に取得されたログと、解析に失敗した場合は生のログをアップロードします。 解析後に取得されたログをアップロードします。 解析に成功した場合は生のログフィールドをログに追加し、失敗した場合は生のログを追加します。 たとえば、生のログが "content": "{"request_method":"GET", "request_time":"200"}" で、解析に成功した場合、システムは [元のフィールドの新しい名前] パラメーターで指定された生のログフィールドを追加します。 パラメーターを構成しない場合は、元のフィールド名が使用されます。 フィールド値は {"request_method":"GET", "request_time":"200"} です。

6. [インデックスを作成] し、[データのプレビュー] を行います。次に、[次へ] をクリックします。デフォルトでは、Simple Log Service でフルテキストインデックスが有効になっています。手動モードまたは自動モードで、収集されたログに基づいてフィールドインデックスを設定することもできます。自動モードでフィールドインデックスを設定するには、[自動インデックス生成] をクリックします。このように、Simple Log Service は自動的にフィールドインデックスを作成します。詳細については、「インデックスを作成する」をご参照ください。

   重要

   すべてのフィールドをログでクエリする場合は、フルテキストインデックスを使用することをお勧めします。特定のフィールドのみをクエリする場合は、フィールドインデックスを使用することをお勧めします。これにより、インデックストラフィックを削減できます。フィールドを分析する場合は、フィールドインデックスを作成する必要があります。分析のクエリ文には、SELECT 文を含める必要があります。

7. [クエリログ] をクリックします。次に、Logstore のクエリおよび分析ページにリダイレクトされます。

   インデックスが有効になるまで約 1 分待つ必要があります。その後、[未加工ログ] タブで収集されたログを表示できます。詳細については、「ログクエリと分析のガイド」をご参照ください。

環境変数

1. Knative サービスの作成時に SLS を有効にする

Knative サービスを作成する際に、次の YAML テンプレートに基づいてログ収集を有効にできます。

1. ACK コンソール にログオンします。左側のナビゲーションウィンドウで、[クラスタ] をクリックします。

2. [クラスタ] ページで、管理するクラスタを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、[アプリケーション] > Knative を選択します。

3. [サービス] タブをクリックし、名前空間を選択して、[テンプレートから作成] をクリックします。表示されるページで、[サンプルテンプレート] セクションの [カスタム] を選択します。次の YAML ファイルを使用し、ページの指示に従ってサービスを作成します。

   YAML テンプレートは Kubernetes 構文に準拠しています。env を使用して、[ログ収集構成] と [カスタムタグ] を定義できます。volumeMounts パラメーターと volumes パラメーターも設定する必要があります。次の例は、ポッドで Log Service を構成する方法を示しています。

   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:
           # 環境変数を指定します。
           - name: aliyun_logs_log-stdout
             value: stdout
           - 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
           # ポッドが繰り返し再起動される場合は、ポッドの起動パラメーターにスリープコマンドを追加できます。
           command: ["sh", "-c"]  # シェルでコマンドを実行します。
           args: ["sleep 3600"]   # スリープ時間を 1 時間 (3600 秒) に設定します。
         volumes:
         - name: volumn-sls-mydemo
           emptyDir: {}

   ビジネス要件に基づいて、次の手順を順番に実行します。

   説明

   他のログ収集要件がある場合は、(オプション) 2. 環境変数を使用して詳細設定を構成する を参照してください。

   1. 環境変数を使用して、[ログ収集構成] と [カスタムタグ] を追加します。ログ収集に関連するすべての環境変数は、プレフィックスとして aliyun_logs_ を使用する必要があります。

      • 次の形式で環境変数を追加します。

        - name: aliyun_logs_log-stdout
          value: stdout
        - name: aliyun_logs_log-varlog
          value: /var/demo/*.log                        

        前の例では、aliyun_logs_{key} という形式の 2 つの環境変数がログ収集構成に追加されています。環境変数の {keys} は、log-stdout と log-varlog です。

        • aliyun_logs_log-stdout 環境変数は、コンテナーから収集された stdout を格納するために、Logstore という名前の log-stdout が作成されることを示します。収集構成の名前は log-stdout です。このようにして、コンテナーの stdout は Logstore という名前の log-stdout に収集されます。

        • aliyun_logs_log-varlog 環境変数は、コンテナーから収集された /var/demo/*.log ファイルを格納するために、Logstore という名前の log-varlog が作成されることを示します。収集構成の名前は log-varlog です。このようにして、/var/demo/*.log ファイルは Logstore という名前の log-varlog に収集されます。

      • 次の形式で [カスタムタグ] を追加します。

        - name: aliyun_logs_mytag1_tags
          value: tag1=v1                       

        タグが追加されると、コンテナーから収集されたログデータにタグが自動的に追加されます。mytag1 は アンダースコア (_) を含まないタグ名 を指定します。

   2. stdout 以外のログファイルを収集するためにログパスを指定する場合は、volumeMounts パラメーターを設定する必要があります。

      前の YAML テンプレートでは、volumeMounts の mountPath フィールドは /var/demo に設定されています。これにより、Logtail は /var/demo*.log ファイルからログデータを収集できます。

4. YAML テンプレートを変更した後、[作成] をクリックして構成を送信します。

(Optional) 2. 環境変数を使用して詳細設定を構成する

- name: aliyun_logs_catalina_tags

  value: app=catalina

- name: aliyun_logs_catalina_project

  value: my-k8s-project

- name: aliyun_logs_catalina_logstore

  value: my-logstore

- name: aliyun_logs_catalina_shard

  value: '4'

- name: aliyun_logs_catalina_ttl

  value: '3650'

- name: aliyun_logs_catalina_machinegroup

  value: my-machine-group