ログ収集設定を Kubernetes カスタムリソース定義 (CRD) として定義することで、Container Service for Kubernetes (ACK) や自己管理クラスターを含むすべてのクラスターで管理を統一できます。このアプローチは、一貫性がなくエラーが発生しやすい手動プロセスを、kubectl または CI/CD パイプラインによるバージョン管理された自動化に置き換えます。LoongCollector のホットリロード機能と組み合わせることで、構成の変更は収集コンポーネントを再起動することなく即座に有効になります。これにより、運用保守 (O&M) の効率とシステムの保守性が向上します。
従来の AliyunLogConfig CRD はメンテナンスされなくなりました。代わりに新しい AliyunPipelineConfig CRD を使用してください。新旧バージョンの比較については、「CRD タイプ」をご参照ください。CRD を使用して作成された収集構成は、対応する CRD を更新することによってのみ変更できます。Simple Log Service コンソールで行われた変更は CRD に同期されず、有効になりません。
適用性
動作環境:
ACK (マネージド版および専用版) および自己管理 Kubernetes クラスターをサポートします。
Mount propagation: HostToContainerをサポートする Kubernetes バージョン 1.16.0 以降。コンテナーランタイム (Docker および Containerd のみ)
Docker:
docker.sock へのアクセス権が必要です。
標準出力の収集は、JSON ログドライバーのみをサポートします。
overlay および overlay2 ストレージドライバーのみをサポートします。他のタイプの場合、ログディレクトリを手動でマウントする必要があります。
Containerd: containerd.sock へのアクセス権が必要です。
リソース要件: LoongCollector (Logtail) は system-cluster-critical の高い優先度で実行されます。クラスターリソースが不十分な場合、ノード上の既存の Pod を退去させる可能性があるため、デプロイしないでください。
CPU: 少なくとも 0.1 コアを予約してください。
メモリ: 収集コンポーネントには少なくとも 150 MB、コントローラーコンポーネントには少なくとも 100 MB が必要です。
実際の使用量は、収集レート、監視対象のディレクトリとファイルの数、および送信のブロッキングによって異なります。実際の使用量が構成された制限の 80% 未満に留まるようにしてください。
権限要件: デプロイに使用する Alibaba Cloud アカウントまたは RAM ユーザーは、
AliyunLogFullAccess権限を持っている必要があります。カスタム権限ポリシーを作成するには、「AliyunCSManagedLogRolePolicy」システムポリシーをご参照ください。このポリシーから権限をコピーし、ターゲットの RAM ユーザーまたはロールに付与して、詳細な権限を構成します。
収集構成の作成フロー
LoongCollector のインストール: LoongCollector を DaemonSet としてデプロイし、クラスター内の各ノードで収集コンテナーが実行されるようにします。これにより、そのノード上のすべてのコンテナーからログを統一的に収集できます。
Logstore の作成: Logstore はログデータのストレージユニットです。1 つのプロジェクトに複数の Logstore を作成できます。
収集構成 YAML ファイルの作成: 「kubectl を使用してクラスターに接続する」をご参照ください。次のいずれかの方法で収集構成ファイルを作成します。
方法 1: 収集構成ジェネレーターを使用する
Simple Log Service コンソールの 収集構成ジェネレーターを使用して、グラフィカルユーザーインターフェイスでパラメーターを入力し、標準の YAML ファイルを自動的に生成します。
方法 2: YAML ファイルを手動で記述する
このトピックの例とワークフローに基づいて YAML ファイルを記述します。最小構成から始めて、徐々に処理ロジックと高度な機能を追加していきます。
このトピックでカバーされていない複雑なユースケースや、詳細なカスタマイズが必要なフィールドについては、「AliyunPipelineConfig パラメーター」をご参照ください。フィールド、値のルール、およびプラグイン機能の完全なリストが記載されています。
完全な収集構成は、通常、次の部分で構成されます。
最小構成 (必須): クラスターから Simple Log Service へのデータトンネルを構築します。これには 2 つの部分が含まれます。
入力
(inputs): ログのソースを定義します。コンテナーログには、次の 2 つのログソースが含まれます。MySQL クエリ結果など、他の種類のログを収集するには、「入力プラグイン」をご参照ください。コンテナー標準出力 (stdout および stderr): コンテナープログラムがコンソールに出力するログコンテンツ。
テキストログファイル: コンテナー内の指定されたパスに書き込まれるログファイル。
出力
(flushers): ログの宛先を定義します。収集されたログを指定された Logstore に送信します。宛先プロジェクトまたは Logstore が存在しない場合、システムは自動的に作成します。事前に プロジェクトと Logstore を手動で作成することもできます。
一般的な処理構成 (オプション):
processorsフィールドを定義して、生ログに対して構造化解析 (正規表現やデリミタ解析など)、マスキング、またはフィルタリングを実行します。このトピックでは、一般的なログ処理のユースケースをカバーするネイティブ処理プラグインのみを説明します。その他の機能については、「拡張処理プラグイン」をご参照ください。
その他の詳細設定 (オプション): 複数行ログ収集やログタグのエンリッチメントなどの機能を実装して、より詳細な収集要件を満たします。
構造の例:
apiVersion: telemetry.alibabacloud.com/v1alpha1 # デフォルト値を使用します。変更しないでください。 kind: ClusterAliyunPipelineConfig # デフォルト値を使用します。変更しないでください。 metadata: name: test-config # リソース名を設定します。Kubernetes クラスター内で一意である必要があります。 spec: project: # 宛先プロジェクトの名前を設定します。 name: k8s-your-project config: # Logtail 収集構成を設定します。 inputs: # Logtail 収集構成の入力プラグインを設定します。 ... processors: # Logtail 収集構成の処理プラグインを設定します。 ... flushers: # Logtail 収集構成の出力プラグインを設定します。 ...構成の適用
kubectl apply -f <your_yaml>
LoongCollector (Logtail) のインストール
LoongCollector は、Simple Log Service (SLS) の次世代ログ収集エージェントであり、Logtail のアップグレード版です。LoongCollector と Logtail は同時にインストールできません。Logtail をインストールするには、「Logtail のインストールと構成」をご参照ください。
このトピックでは、LoongCollector の基本的なインストール手順のみを説明します。詳細なパラメーターについては、「LoongCollector のインストール (Kubernetes)」をご参照ください。すでに LoongCollector または Logtail をインストールしている場合は、このステップをスキップして、収集したログを保存するための Logstore の作成に進んでください。
ACK クラスター
Container Service for Kubernetes (ACK) コンソールから LoongCollector をインストールします。デフォルトでは、ログは現在の Alibaba Cloud アカウントに属する Simple Log Service (SLS) プロジェクトに送信されます。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、ターゲットクラスターの名前をクリックして詳細ページを開きます。
左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[ログとモニタリング] タブで、loongcollector を見つけて [インストール] をクリックします。
説明新しいクラスターの場合、[コンポーネント構成] ページで [Log Service を有効にする] を選択します。次に、[新しいプロジェクトを作成] または [既存のプロジェクトを使用] を選択します。
インストールが完了すると、SLS は ACK クラスターが配置されているリージョンに関連リソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます。
リソースタイプ
リソース名
機能
プロジェクト
k8s-log-${cluster_id}異なるサービスのログを分離するためのリソース管理ユニット。
より柔軟なログリソース管理のためにプロジェクトを作成するには、「プロジェクトの作成」をご参照ください。
マシングループ
k8s-group-${cluster_id}ログ収集ノードのコレクション。
Logstore
config-operation-log重要この Logstore は削除しないでください。
loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目」をご参照ください。この Logstore に収集構成を作成しないでください。
自己管理クラスター
Kubernetes クラスターに接続し、お使いのリージョンに対応するコマンドを実行して、LoongCollector とその依存コンポーネントをダウンロードします。
中国国内のリージョン:
wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh中国国外のリージョン:
wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.shloongcollector-custom-k8s-packageディレクトリに移動し、./loongcollector/values.yaml構成ファイルを変更します。# ===================== 必須パラメーター ===================== # 収集されたログを管理するプロジェクトの名前。例: k8s-log-custom-sd89ehdq。 projectName: "" # プロジェクトが配置されているリージョン。上海の例: cn-shanghai region: "" # プロジェクトを所有する Alibaba Cloud アカウントの ID。ID を引用符で囲みます。例: "123456789" aliUid: "" # ネットワークタイプ。有効な値: Internet および Intranet。デフォルト値: Internet。 net: Internet # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID と AccessKey Secret。アカウントまたはユーザーは AliyunLogFullAccess システムポリシーを持っている必要があります。 accessKeyID: "" accessKeySecret: "" # カスタムクラスター ID。ID には、大文字、小文字、数字、ハイフン (-) のみを含めることができます。 clusterID: ""loongcollector-custom-k8s-packageディレクトリで、次のコマンドを実行して LoongCollector とその他の依存コンポーネントをインストールします。bash k8s-custom-install.sh installインストールが完了したら、コンポーネントの実行状態を確認します。
Pod の起動に失敗した場合は、values.yaml の構成が正しいか、関連するイメージが正常にプルされたかを確認してください。
# Pod の状態を確認します。 kubectl get po -n kube-system | grep loongcollector-dsSLS はまた、以下のリソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます。
リソースタイプ
リソース名
機能
プロジェクト
values.yaml ファイルで指定した
projectNameの値異なるサービスのログを分離するためのリソース管理ユニット。
マシングループ
k8s-group-${cluster_id}ログ収集ノードのコレクション。
Logstore
config-operation-log重要この Logstore は削除しないでください。
loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目」をご参照ください。この Logstore に収集構成を作成しないでください。
Logstore の作成
すでに Logstore を作成している場合は、このステップをスキップして 収集の構成に進んでください。
Simple Log Service コンソールにログインし、ターゲットプロジェクトの名前をクリックします。
左側のナビゲーションウィンドウで、
を選択し、[+] アイコンをクリックします。Logstore の作成ページで、次のコア構成を完了します。
[Logstore 名]: プロジェクト内で一意の名前を設定します。この名前は作成後に変更できません。
[Logstore タイプ]: 仕様の比較に基づいて、標準またはクエリを選択します。
[課金方法]:
[機能別課金]: ストレージ、インデックス、読み取り/書き込み操作など、各リソースに対して個別に課金されます。小規模なユースケースや、機能の使用量が不確かな場合に適しています。
[取り込みデータ量に応じた課金]: 取り込まれた生データの量によってのみ課金されます。30 日間の無料ストレージ期間と、データ変換や配信などの無料機能を提供します。コストモデルはシンプルで、ストレージ期間が 30 日に近い場合や、データ処理パイプラインが複雑な場合に適しています。
[データ保持期間]: ログを保持する日数を設定します。値の範囲は 1 日から 3650 日です。3650 の値は永続的なストレージを示します。デフォルトは 30 日です。
他の構成はデフォルト設定のままにして、[OK] をクリックします。他の構成の詳細については、「Logstore の管理」をご参照ください。
最小構成
<a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="2ba88d5208b3d">spec.config</a> では、入力 (inputs) と出力 (flushers) プラグインを構成します。これらのプラグインは、ログのソースと宛先を含む、コアのログ収集パスを定義します。
コンテナー標準出力 - 新バージョン
目的: コンソールに直接出力されるコンテナーの標準出力ログ (stdout/stderr) を収集します。
収集構成の開始点。ログソースを定義します。現在、1 つの入力プラグインのみを構成できます。
| 例 |
|
コンテナーのテキストファイルを収集する
目的: コンテナー内の特定のファイルパスに書き込まれたログ (従来の access.log や app.log ファイルなど) を収集します。
収集構成の開始点。ログソースを定義します。現在、1 つの入力プラグインのみを構成できます。
| 例 |
|
一般的な処理構成
最小構成を完了した後、processors プラグインを追加して、生ログに対して構造化解析、マスキング、またはフィルタリングを実行できます。
コア構成: processors を <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="49324d8ed176z">spec.config</a> に追加して、処理プラグインを構成します。複数のプラグインを同時に有効にすることができます。
このトピックでは、一般的なログ処理のユースケースをカバーするネイティブ処理プラグインのみを説明します。追加機能については、「拡張処理プラグイン」をご参照ください。
Logtail 2.0 以降のバージョンおよび LoongCollector コンポーネントについては、次のプラグインの組み合わせルールに従ってください。
まずネイティブプラグインを使用します。
ネイティブプラグインがニーズを満たせない場合は、ネイティブプラグインの後に拡張プラグインを構成します。
ネイティブプラグインは、拡張プラグインの前にのみ使用できます。
構造化構成
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。
キーフィールド | 例 |
Type プラグインのタイプ。これを | |
SourceKey ソースフィールドの名前。 | |
Regex ログに一致する正規表現。 | |
Keys 抽出されたフィールドのリスト。 | |
KeepingSourceWhenParseFail 解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey _ ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。 |
デリミタ解析
デリミタを使用してログコンテンツを構造化し、コンテンツをキーと値のペアに解析します。このメソッドは、単一文字および複数文字のデリミタをサポートします。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。これを | |
SourceKey ソースフィールドの名前。 | |
Separator フィールドセパレーター。たとえば、CSV ファイルはカンマ (,) を使用します。 | |
Keys 抽出されたフィールドのリスト。 | |
Quote 引用符文字。カンマなどの特殊文字を含むフィールドコンテンツをラップするために使用します。 | |
AllowingShortenedFields 抽出されたフィールドの数がキーの数より少なくてもよいかどうかを指定します。デフォルト値は | |
OverflowedFieldsTreatment 抽出されたフィールドの数がキーの数より多い場合に実行するアクションを指定します。デフォルト値は
| |
KeepingSourceWhenParseFail 解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。 |
標準 JSON 解析
オブジェクトタイプの JSON ログを構造化し、キーと値のペアに解析します。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。これを | |
SourceKey ソースフィールドの名前。 | |
KeepingSourceWhenParseFail 解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。 |
ネストされた JSON 解析
展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。これを | |
SourceKey ソースフィールドの名前。 | |
ExpandDepth JSON の展開深度。デフォルト値は 0 です。
| |
ExpandConnector JSON 展開中のフィールド名に使用されるコネクタ。デフォルト値はアンダースコア (_) です。 | |
Prefix 展開された JSON フィールドの名前のプレフィックス。 | |
IgnoreFirstConnector 最初のコネクタを無視するかどうかを指定します。これにより、トップレベルのフィールド名の前にコネクタが追加されるかどうかが決まります。デフォルト値は | |
ExpandArray 配列タイプを展開するかどうかを指定します。デフォルト値は
説明 このパラメーターは Logtail 1.8.0 以降でサポートされています。 | |
KeepSource 解析されたログにソースフィールドを保持するかどうかを指定します。デフォルト値は
| |
NoKeyError 指定されたソースフィールドが生ログに見つからない場合にエラーを報告するかどうかを指定します。デフォルト値は
| |
UseSourceKeyAsPrefix すべての展開された JSON フィールド名のプレフィックスとしてソースフィールド名を使用するかどうかを指定します。 | |
KeepSourceIfParseError 解析に失敗した場合に生ログデータを保持するかどうかを指定します。デフォルト値は
|
JSON 配列解析
json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。詳細については、「JSON 関数」をご参照ください。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。構造化プロセス言語 (SPL) プラグインの場合、これを | |
Script SPL スクリプトのコンテンツ。このスクリプトは、content フィールドの JSON 配列から要素を抽出するために使用されます。 | |
TimeoutMilliSeconds スクリプトのタイムアウト期間 (ミリ秒)。値は 0 から 10,000 の範囲である必要があります。デフォルト値は 1,000 です。 |
NGINX ログ解析
log_format の定義に基づいて、ログコンテンツをキーと値のペアに構造化します。デフォルトのフォーマットが要件を満たさない場合は、カスタムフォーマットを使用できます。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。NGINX ログ解析の場合、これを | |
SourceKey ソースフィールドの名前。 | |
Regex 正規表現。 | |
Keys 抽出されたフィールドのリスト。 | |
Extra
| |
KeepingSourceWhenParseFail 解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。 |
Apache ログ解析
Apache ログ構成ファイルの定義に基づいて、ログコンテンツをキーと値のペアに構造化します。
キーフィールドの詳細 | 例 |
Type プラグインのタイプ。これを | |
SourceKey ソースフィールドの名前。 | |
Regex 正規表現。 | |
Keys 抽出されたフィールドのリスト。 | |
Extra
| |
KeepingSourceWhenParseFail 解析に失敗したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析に成功したときにソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドが保持される場合、このパラメーターはフィールドの新しい名前を指定します。デフォルトでは、フィールドは名前変更されません。 |
データマスキング
processor_desensitize_native プラグインを使用して、ログ内の機密データをマスキングします。
キーフィールド | 例 |
Type プラグインのタイプ。値を | |
SourceKey ソースフィールド名。 | |
Method マスキング方法。有効な値:
| |
ReplacingString 機密コンテンツを置き換えるために使用される定数文字列。このパラメーターは、 | |
ContentPatternBeforeReplacedString 機密コンテンツのプレフィックスの正規表現。 | |
ReplacedContentPattern 機密コンテンツの正規表現。 | |
ReplacingAll 解析が成功した後に元のフィールドを保持するかどうかを指定します。デフォルトは |
コンテンツフィルタリング
processor_filter_regex_native プラグインを構成して、正規表現に基づいてログフィールドの値を照合し、条件を満たすログのみを保持します。
キーフィールド | 例 |
Type プラグインのタイプ。値は | |
FilterRegex ログフィールドに一致する正規表現。 | |
FilterKey 一致させるログフィールドの名前。 |
時間解析
`processor_parse_timestamp_native` プラグインを構成して、ログ内の時間フィールドを解析し、解析結果をログの __time__ フィールドとして設定します。
キーフィールド | 例 |
Type プラグインのタイプ。 | |
SourceKey ソースフィールド名。 | |
SourceFormat 「時間形式」をご参照ください。この形式は、ログ内の時間フィールドの形式と完全に一致する必要があります。 | |
SourceTimezone ログ時間のタイムゾーン。デフォルトでは、マシンのタイムゾーンが使用されます。これは、LoongCollector プロセスが配置されている環境のタイムゾーンです。 フォーマット:
|
その他の詳細設定
最小構成を完了した後、次の操作を実行して、複数行ログの収集、ログトピックタイプの構成、およびより詳細なログ収集の構成を行うことができます。以下は、一般的な詳細設定とその機能です。
複数行ログ収集の構成: 例外スタックトレースなど、単一のログエントリが複数行にまたがる場合、複数行モードを有効にし、行の開始を示す正規表現を構成してログの開始に一致させる必要があります。これにより、複数行のエントリが単一のログとして収集され、SLS Logstore に保存されることが保証されます。
ログトピックタイプの構成: 異なるログストリームに異なるトピックを設定して、ログデータを整理および分類します。これにより、関連するログをより適切に管理および取得できます。
収集対象コンテナーの指定 (フィルタリングとブラックリスト): ホワイトリストとブラックリストの構成を含め、収集対象の特定のコンテナーとパスを指定します。
ログタグのエンリッチ: 環境変数と Pod ラベルに関連するメタデータを拡張フィールドとしてログに追加します。
複数行ログ収集の構成
デフォルトでは、Simple Log Service は単一行モードを使用し、ログを行ごとに分割して保存します。これにより、スタックトレース情報を含む複数行のログが分割され、各行が独立したログとして保存および表示されるため、分析には不向きです。
この問題に対処するために、複数行モードを有効にして、Simple Log Service がログを分割する方法を変更できます。ログエントリの開始に一致する正規表現を構成することで、生ログが行の開始ルールに従って分割および保存されることを保証できます。
コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="f3ede8f0e8rnz">spec.config.inputs</a> 構成に、Multiline パラメーターを追加します。
キーフィールド | 例 |
Multiline 複数行ログ収集を有効にします。
| |
ログトピックタイプの構成
コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="bd8af01817orq">spec.config</a> に、global パラメーターを追加してトピックを設定します。
キーフィールド | 例 |
TopicType トピックタイプ。オプションの値:
| マシングループトピックファイルパス抽出カスタム |
TopicFormat トピック形式。これは、TopicType が filepath または custom に設定されている場合に必須です。 |
収集対象コンテナーの指定 (フィルタリングとブラックリスト)
フィルタリング
指定された条件を満たすコンテナーからのみログを収集します。複数の条件は論理 AND で結合されます。空の条件は無視されます。条件は正規表現をサポートします。
コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="aa519613f0gdu">spec.config.inputs</a> で、コンテナーフィルタリングのための ContainerFilters パラメーターを構成します。
キーフィールドの詳細 | 例 |
ContainerFilters コンテナーフィルタリング
すべての正規表現マッチングは、Go の RE2 エンジンを使用します。このエンジンは、PCRE などのエンジンよりも機能が少ないです。「付録: 正規表現の制限 (コンテナーフィルタリング)」で説明されている制限に従って正規表現を記述してください。 | |
ブラックリスト
指定された条件を満たすファイルを除外するには、必要に応じて YAML ファイルの config.inputs の下にある次のパラメーターを使用します。
キーフィールドの詳細 | 例 |
ExcludeFilePaths ファイルパスのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があります。アスタリスク (*) ワイルドカード文字がサポートされています。 | |
ExcludeFiles ファイル名のブラックリスト。指定された条件を満たすファイルを除外します。アスタリスク (*) ワイルドカード文字がサポートされています。 | |
ExcludeDirs ディレクトリのブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があります。アスタリスク (*) ワイルドカード文字がサポートされています。 |
ログタグのエンリッチ
コア構成: <a baseurl="t3010624_v1_5_0.xdita" data-node="6128095" data-root="16376" data-tag="xref" href="t3145878.xdita#c801b53fd5xu4" id="c7eb12a5deg0j">spec.config.inputs</a> で ExternalEnvTag と ExternalK8sLabelTag を構成することで、コンテナーの環境変数と Pod ラベルに関連するタグをログに追加できます。
キーフィールド | 例 |
ExternalEnvTag 指定された環境変数の値をタグフィールドにマッピングします。フォーマット: | |
ExternalK8sLabelTag Kubernetes Pod ラベルの値をタグフィールドにマッピングします。フォーマット: |
構成例
シナリオ 1: NGINX アクセスログを収集し、構造化フィールドに解析する
NGINX ログを解析し、log_format の定義に基づいてログコンテンツを複数のキーと値のペアに構造化します。
シナリオ 2: 複数行ログの収集と処理
デフォルトでは、Simple Log Service は単一行モードを使用し、ログを行ごとに分割して保存します。これにより、スタックトレース情報を含む複数行のログが分割され、各行が独立したログとして保存および表示されるため、分析には不向きです。
この問題に対処するために、複数行モードを有効にして、Simple Log Service がログを分割する方法を変更できます。ログエントリの開始に一致する正規表現を構成することで、生ログが行の開始ルールに従って分割および保存されることを保証できます。以下に例を示します。
よくある質問
ACK クラスターから別の Alibaba Cloud アカウントのプロジェクトにログを送信するにはどうすればよいですか?
ACK クラスターに Simple Log Service LoongCollector (Logtail) コンポーネントを手動でインストールし、宛先アカウントの Alibaba Cloud アカウント ID またはアクセス資格情報 (AccessKey) で構成します。これにより、コンテナーログを別の Alibaba Cloud アカウントの Simple Log Service プロジェクトに送信できます。
シナリオ: 組織構造、権限の分離、または統一された監視などの理由で、ACK クラスターから別の Alibaba Cloud アカウントの Simple Log Service プロジェクトにログデータを収集する必要があります。これを行うには、クロスアカウント構成のために LoongCollector (Logtail) を手動でインストールします。
手順: このセクションでは、LoongCollector の手動インストールを例として使用します。Logtail のインストール方法については、「Logtail のインストールと構成」をご参照ください。
Kubernetes クラスターに接続し、お使いのリージョンに対応するコマンドを実行して、LoongCollector とその依存コンポーネントをダウンロードします。
中国国内のリージョン:
wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh中国国外のリージョン:
wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.shloongcollector-custom-k8s-packageディレクトリに移動し、./loongcollector/values.yaml構成ファイルを変更します。# ===================== 必須パラメーター ===================== # 収集されたログを管理するプロジェクトの名前。例: k8s-log-custom-sd89ehdq。 projectName: "" # プロジェクトが配置されているリージョン。上海の例: cn-shanghai region: "" # プロジェクトを所有する Alibaba Cloud アカウントの ID。ID を引用符で囲みます。例: "123456789" aliUid: "" # ネットワークタイプ。有効な値: Internet および Intranet。デフォルト値: Internet。 net: Internet # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID と AccessKey Secret。アカウントまたはユーザーは AliyunLogFullAccess システムポリシーを持っている必要があります。 accessKeyID: "" accessKeySecret: "" # カスタムクラスター ID。ID には、大文字、小文字、数字、ハイフン (-) のみを含めることができます。 clusterID: ""loongcollector-custom-k8s-packageディレクトリで、次のコマンドを実行して LoongCollector とその他の依存コンポーネントをインストールします。bash k8s-custom-install.sh installインストールが完了したら、コンポーネントの実行状態を確認します。
Pod の起動に失敗した場合は、values.yaml の構成が正しいか、関連するイメージが正常にプルされたかを確認してください。
# Pod の状態を確認します。 kubectl get po -n kube-system | grep loongcollector-dsSLS はまた、以下のリソースを自動的に作成します。Simple Log Service コンソールにログインして表示できます。
リソースタイプ
リソース名
機能
プロジェクト
values.yaml ファイルで指定した
projectNameの値異なるサービスのログを分離するためのリソース管理ユニット。
マシングループ
k8s-group-${cluster_id}ログ収集ノードのコレクション。
Logstore
config-operation-log重要この Logstore は削除しないでください。
loongcollector-operator コンポーネントのログを保存します。その課金方法は通常の Logstore と同じです。詳細については、「取り込みデータ量に応じた課金モードの課金項目」をご参照ください。この Logstore に収集構成を作成しないでください。
単一のログファイルまたはコンテナーの標準出力から複数の収集構成でログを収集するにはどうすればよいですか?
デフォルトでは、データの重複を防ぐため、Simple Log Service は各ログソースを単一の収集構成に制限しています。
テキストログファイルは、1 つの Logtail 収集構成にのみ一致できます。
コンテナーの標準出力 (stdout) は、1 つの標準出力収集構成によってのみ収集できます。
Simple Log Service コンソールにログインし、ターゲットプロジェクトに移動します。
ナビゲーションウィンドウで、
[Logstores] を選択し、ターゲット Logstore を見つけます。その名前の横にある
アイコンをクリックして、Logstore を展開します。[Logtail 構成] をクリックします。構成リストで、ターゲットの Logtail 構成を見つけ、[操作] 列の [Logtail 構成の管理] をクリックします。
Logtail 構成ページで、[編集] をクリックし、[入力構成] セクションまでスクロールします。
テキストファイルからログを収集する場合: [ファイルを複数回収集することを許可] を有効にします。
コンテナーの標準出力を収集する場合: [標準出力を複数回収集することを許可] を有効にします。
付録: 正規表現の使用制限 (コンテナーフィルタリング)
コンテナーフィルタリングに使用される正規表現は、Go の RE2 エンジンに基づいており、PCRE などの他のエンジンと比較して構文に制限があります。正規表現を記述する際には、以下の点に注意してください。
1. 名前付きグループ構文の違い
Go は (?P<name>...) 構文を使用して名前付きグループを定義します。PCRE の (?<name>...) 構文はサポートしていません。
正しい例:
(?P<year>\d{4})誤った例:
(?<year>\d{4})
2. サポートされていない正規表現機能
以下の一般的で複雑な正規表現機能は RE2 では利用できません。これらは使用しないでください。
アサーション:
(?=...),(?!...),(?<=...), および(?<!...)条件式:
(?(condition)true|false)再帰的マッチング:
(?R)および(?0)サブルーチン参照:
(?&name)および(?P>name)アトミックグループ:
(?>...)
3. 推奨事項
Regex101 などのツールで正規表現をデバッグする際は、互換性を確保するために Golang (RE2) モードを選択して検証してください。サポートされていない構文を使用すると、プラグインは式を正しく解析または照合できません。