Kubernetes のカスタムリソース定義 (CRD) としてログ収集設定を定義することで、Container Service for Kubernetes (ACK) クラスターおよびセルフマネージドクラスターを含むすべてのクラスターにおける管理を統一できます。このアプローチにより、一貫性に欠け誤りが生じやすい手動プロセスを、kubectl および CI/CD パイプラインによるバージョン管理された自動化に置き換えます。LoongCollector に組み込まれたホットリロード機能により、再起動なしで変更を即座に適用でき、運用効率およびシステムの保守性を直接向上させます。
旧式の AliyunLogConfig CRD は今後メンテナンスされません。代わりに新しい AliyunPipelineConfig CRD をご使用ください。新旧バージョンの比較については、「CRD の種類」をご参照ください。CRD を使用して作成した収集設定は、対応する CRD を更新することでのみ変更可能です。Simple Log Service (SLS) コンソールで行った変更は CRD と同期されず、反映されません。
注意事項
実行環境:
ACK(マネージドおよび専用エディション)およびセルフマネージド Kubernetes クラスターをサポートします。
Kubernetes バージョン 1.16.0 以降(
Mount propagation: HostToContainerをサポート)。コンテナランタイム(Docker および Containerd のみ)
Docker:
docker.sock へのアクセス権限が必要です。
標準出力の収集には JSON ログドライバーのみがサポートされます。
overlay および overlay2 ストレージドライバーのみがサポートされます。その他のタイプの場合、ログディレクトリを手動でマウントする必要があります。
Containerd: containerd.sock へのアクセス権限が必要です。
リソース要件: LoongCollector (Logtail) は `system-cluster-critical` の高優先度で実行されます。クラスターのリソースが不足している場合、ノード上の既存の Pod を追い出す可能性があるため、LoongCollector のデプロイは避けてください。
CPU:最低 0.1 コア を確保してください。
メモリ:収集コンポーネントに最低 150 MB、コントローラーコンポーネントに最低 100 MB を確保してください。
実際の使用量は、収集レート、監視対象のディレクトリおよびファイル数、送信ブロッキングの発生状況によって異なります。実際の使用量は、設定済みの制限値の 80 % を下回るようにしてください。
権限: デプロイに使用する Alibaba Cloud アカウントまたは RAM ユーザーには、
AliyunLogFullAccess権限が必要です。カスタムポリシーを作成する場合は、「AliyunCSManagedLogRolePolicy」システムポリシーをご参照ください。このポリシーから必要な権限をコピーし、対象の RAM ユーザーまたはロールに付与することで、細かい粒度での権限設定が可能です。
収集設定のワークフロー
LoongCollector のインストール: LoongCollector を DaemonSet としてデプロイし、クラスター内の各ノードに収集コンテナを実行させます。これにより、そのノード上のすべてのコンテナからログを一元的に収集できます。
Logstore の作成: Logstore はログデータの保存単位です。1 つのプロジェクト内に複数の Logstore を作成できます。
収集設定 YAML ファイルの作成: kubectl を使用してクラスターに接続します。収集設定ファイルは、以下のいずれかの方法で作成します。
方法 1:収集設定ジェネレーターの使用
SLS コンソールの収集設定ジェネレーターを使用して、パラメーターをビジュアルに指定し、標準的な YAML ファイルを自動生成します。
方法 2:YAML ファイルの手動作成
本トピックのサンプルおよびワークフローに基づいて YAML ファイルを作成します。最小構成から始め、順次処理ロジックおよび高度な機能を追加していきます。
本トピックで取り扱われていない複雑なユースケースや、詳細なカスタマイズが必要なフィールドについては、「AliyunPipelineConfig のパラメーター」をご参照ください。ここでは、すべてのフィールド、値のルール、およびプラグイン機能について記載されています。
完全な収集設定には、通常以下のような要素が含まれます:
最小構成(必須):クラスターから SLS へのデータトンネルを構築します。以下の 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 は、SLS が提供する次世代ログ収集エージェントであり、Logtail のアップグレード版です。両者は共存できません。Logtail のインストールについては、「Logtail のインストールおよび構成」をご参照ください。
本トピックでは、LoongCollector の基本的なインストール手順のみを説明します。詳細なパラメーターについては、「インストールおよび構成」をご参照ください。すでに LoongCollector または Logtail をインストール済みの場合は、この手順をスキップし、収集したログを格納するLogstore の作成に進んでください。
ACK クラスター
Container Service for Kubernetes (ACK) コンソールから LoongCollector をインストールします。デフォルトでは、ログは現在の Alibaba Cloud アカウント下の SLS プロジェクトに送信されます。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリストをクリックします。
クラスターページで、対象のクラスター名をクリックし、その詳細ページを開きます。
左側のナビゲーションウィンドウで、アドオンをクリックします。
ログおよびモニタリングタブで、loongcollector を見つけ、インストールをクリックします。
説明新規クラスターの場合、詳細オプションセクションで、Log Service の有効化を選択します。その後、プロジェクトの作成またはプロジェクトの選択を行います。
インストールが完了すると、SLS は ACK クラスターが存在するリージョンに自動的に関連リソースを作成します。Simple Log Service コンソールにログインして確認してください。
リソースタイプ
リソース名
機能
プロジェクト
k8s-log-${cluster_id}異なるサービスのログを分離するためのリソース管理単位です。
より柔軟なログリソース管理のためにプロジェクトを作成する場合は、「プロジェクトの作成」をご参照ください。
マシングループ
k8s-group-${cluster_id}ログ収集ノードの集合です。
重要LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその 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 アカウントの UID。引用符で囲んでください。例: "123456789" aliUid: "" # ネットワークタイプ。オプション:Internet(パブリックネットワーク)および Intranet(内部ネットワーク)。デフォルト値:Internet。 net: Internet # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID および AccessKey Secret。アカウントまたはユーザーには AliyunLogFullAccess システムポリシーが必要です。 accessKeyID: "" accessKeySecret: "" # カスタムクラスター ID。大文字、小文字、数字、ハイフン (-) のみ使用可能です。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}ログ収集ノードの集合です。
重要LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。
Logstore の作成
すでに Logstore を作成済みの場合は、この手順をスキップし、収集設定の構成に進んでください。
Simple Log Service コンソールにログインし、対象のプロジェクト名をクリックします。
左側のナビゲーションウィンドウで、
を選択し、+ をクリックします。Logstore の作成ページで、以下の主要なパラメーターを設定します:
Logstore 名:プロジェクト内で一意となる名前を設定します。作成後に変更することはできません。
Logstore タイプ:仕様を比較して「標準」または「クエリ」を選択します。
課金モード:
機能別課金:ストレージ、インデックス作成、読み書き操作など、各リソースごとに個別に課金されます。小規模な利用や機能の使用量が不確かな場合に適しています。
取り込みデータ量課金: 取り込まれた生データ量のみで課金されます。30 日間の無料ストレージ期間およびデータ変換・配信などの無料機能が提供されます。コストモデルがシンプルであり、ストレージ期間が約 30 日に近い場合やデータ処理パイプラインが複雑な場合に適しています。
データ保持期間:ログを保持する日数を設定します。1~3650 日の範囲で指定できます。3650 を指定すると永続保存となります。デフォルトは 30 日です。
その他の設定はデフォルトのままにして、OK をクリックします。その他の設定の詳細については、「Logstore の管理」をご参照ください。
最小構成
spec.config 内で、入力 (inputs) および出力 (flushers) プラグインを構成し、ログ収集の基本的なパス(ログのソースおよび送信先)を定義します。
コンテナ標準出力 - 新バージョン
目的:コンソールに直接出力されるコンテナ標準出力ログ(stdout/stderr)を収集します。
収集設定の起点です。ログのソースを定義します。現在は 1 つの入力プラグインのみを設定できます。
| 例 |
|
コンテナテキストファイルの収集
目的:コンテナ内に特定のファイルパス(従来の access.log や app.log など)に書き込まれるログを収集します。
収集設定の起点です。ログのソースを定義します。現在は 1 つの入力プラグインのみを設定できます。
| 例 |
|
一般的な処理設定
最小構成の完了後、生ログに対して構造化解析、マスキング、フィルタリングなどの処理を行うために、処理プラグインを追加します。
基本構成:spec.config 内に processors を追加し、処理プラグインを構成します。複数のプラグインを同時に追加できます。
本トピックでは、一般的なログ処理ユースケースに対応するネイティブ処理プラグインのみについて説明します。その他の機能については、「拡張処理プラグイン」をご参照ください。
Logtail 2.0 以降および LoongCollector コンポーネントでは、以下のプラグイン組み合わせルールに従うことを推奨します:
まずネイティブプラグインを使用します。
ネイティブプラグインで要件を満たせない場合、ネイティブプラグインの後に拡張プラグインを構成します。
ネイティブプラグインは、拡張プラグインの前にのみ使用できます。
構造化された構成
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
Regex ログにマッチさせる正規表現です。 | |
Keys 抽出されたフィールドのリストです。 | |
KeepingSourceWhenParseFail 解析失敗時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析成功時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。 |
デリミタ解析
デリミタを使用してログコンテンツを構造化し、複数のキーと値のペアに解析します。単一文字および複数文字のデリミタをサポートします。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
Separator フィールド区切り文字です。CSV の場合、カンマ (,) を使用します。 | |
Keys 抽出されたフィールドのリストです。 | |
Quote 特殊文字(カンマなど)を含むフィールドコンテンツを囲む引用符です。 | |
AllowingShortenedFields 抽出されたフィールド数がキー数より少ない場合を許容するかどうかを指定します。デフォルト値は | |
OverflowedFieldsTreatment 抽出されたフィールド数がキー数より多い場合の動作を指定します。デフォルト値は
| |
KeepingSourceWhenParseFail 解析失敗時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析成功時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。 |
標準 JSON 解析
オブジェクト型の JSON ログを構造化し、キーと値のペアに解析します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
KeepingSourceWhenParseFail 解析失敗時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析成功時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。 |
ネストされた JSON 解析
展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
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 関数の詳細については、「JSON 関数」をご参照ください。
主なフィールド | 例 |
タイプ プラグインのタイプです。SPL プラグインのタイプは | |
Script SPL スクリプトのコンテンツで、content フィールド内の JSON 配列から要素を抽出します。 | |
TimeoutMilliSeconds スクリプトのタイムアウト期間です。値の範囲は 0~10000 です。単位はミリ秒で、デフォルト値は 1000 です。 |
NGINX ログ解析
log_format 定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析します。デフォルトのコンテンツが要件を満たさない場合は、カスタムフォーマットを使用できます。
主なフィールド | 例 |
タイプ プラグインのタイプです。NGINX ログ解析のプラグインタイプは | |
SourceKey ソースフィールドの名前です。 | |
Regex 正規表現です。 | |
Keys 抽出されたフィールドのリストです。 | |
Extra
| |
KeepingSourceWhenParseFail 解析失敗時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析成功時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。 |
Apache ログ解析
Apache ログ構成ファイルの定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
Regex 正規表現です。 | |
Keys 抽出されたフィールドのリストです。 | |
Extra
| |
KeepingSourceWhenParseFail 解析失敗時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
KeepingSourceWhenParseSucceed 解析成功時にソースフィールドを保持するかどうかを指定します。デフォルト値は | |
RenamedSourceKey ソースフィールドを保持する場合、その保存に使用されるフィールド名です。デフォルトでは名前は変更されません。 |
データマスキング
processor_desensitize_native プラグインを使用して、ログ内の機密データをマスクします。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
Method マスキング方法です。サポートされる値は以下のとおりです:
| |
ReplacingString 機密コンテンツを置き換えるために使用される定数文字列です。 | |
ContentPatternBeforeReplacedString 機密コンテンツの接頭辞にマッチする正規表現です。 | |
ReplacedContentPattern 機密コンテンツにマッチする正規表現です。 | |
ReplacingAll 解析成功時に元のフィールドを保持するかどうかを指定します。デフォルト値は |
コンテンツフィルタリング
processor_filter_regex_native プラグインを構成し、正規表現に基づいてログフィールド値をマッチさせ、条件を満たすログのみを保持します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
FilterRegex ログフィールドにマッチさせる正規表現です。 | |
FilterKey マッチさせるログフィールドの名前です。 |
時刻の解析
processor_parse_timestamp_native プラグインを構成し、ログ内のタイムスタンプフィールドを解析し、その解析結果をログの __time__ フィールドとして設定します。
主なフィールド | 例 |
タイプ プラグインのタイプです。 | |
SourceKey ソースフィールドの名前です。 | |
SourceFormat タイムスタンプフォーマットです。ログ内のタイムスタンプフィールドのフォーマットと正確に一致する必要があります。 | |
SourceTimezone ログのタイムゾーンです。デフォルトでは、マシンのタイムゾーン(LoongCollector プロセスが実行される環境のタイムゾーン)が使用されます。 フォーマット:
|
その他の高度な設定
より高度なユースケースでは、以下の設定を検討してください:
マルチラインログ収集の構成:例外スタックトレースなど、1 つのログエントリが複数行にわたる場合、マルチラインモードを有効化し、ログの開始をマッチさせる正規表現を構成する必要があります。これにより、マルチラインエントリが SLS Logstore 内で 1 つのログとして収集および保存されます。
ログトピックタイプの構成:異なるログストリームに対して異なるトピックを設定し、ログデータを整理および分類します。これにより、関連するログをより適切に管理および取得できます。
収集対象コンテナの指定(フィルタリングおよびブラックリスト):収集対象の特定のコンテナおよびパスを指定します。ホワイトリストおよびブラックリストの構成を含みます。
ログタグの充実化:環境変数および Pod ラベルに関連するメタデータを、拡張フィールドとしてログに追加します。
マルチラインログ収集の構成
Java スタックトレースなど、複数行にわたるログエントリを正しく解析するには、マルチラインモードを有効化する必要があります。これにより、定義された開始パターンに基づいて関連する行が 1 つのログエントリとしてグループ化されます。
基本構成:spec.config.inputs 構成内に Multiline パラメーターを追加します。
主なフィールド | 例 |
Multiline マルチラインログ収集を有効化します。
| |
ログトピックタイプの構成
基本構成:spec.config 内で global パラメーターを追加し、トピックを設定します。
主なフィールド | 例 |
TopicType トピックタイプです。オプションの値は以下のとおりです:
| マシングループトピックファイルパス抽出カスタム |
TopicFormat トピックフォーマットです。TopicType が filepath または custom に設定されている場合に必須です。 |
収集対象コンテナの指定(フィルタリングおよびブラックリスト)
フィルタリング
指定された条件を満たすコンテナからのみログを収集します。複数の条件は論理積(AND)で結合されます。空の条件は無視されます。条件には正規表現が使用できます。
基本構成:spec.config.inputs 内で、コンテナフィルタリングのための ContainerFilters パラメーターを構成します。
主なフィールド | 例 |
ContainerFilters コンテナフィルタリング
すべての正規表現は Go の RE2 正規表現エンジンに基づいており、PCRE などのエンジンと比較していくつかの制限があります。正規表現の記述については、付録: コンテナフィルタリングにおける正規表現の制限をご参照ください。 | |
ブラックリスト
指定された条件を満たすファイルを除外するには、YAML ファイルの config.inputs 下で必要に応じて以下のパラメーターを使用します。
主要フィールドの詳細 | 例 |
ExcludeFilePaths ファイルパスブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があり、* ワイルドカード文字をサポートします。 | |
ExcludeFiles ファイル名ブラックリスト。指定された条件を満たすファイルを除外します。* ワイルドカード文字をサポートします。 | |
ExcludeDirs ディレクトリブラックリスト。指定された条件を満たすファイルを除外します。パスは絶対パスである必要があり、* ワイルドカード文字をサポートします。 |
ログタグの充実化
基本構成:spec.config.inputs 内で ExternalEnvTag および ExternalK8sLabelTag を構成することで、コンテナ環境変数および Pod ラベルに関連するタグをログに追加します。
主なフィールド | 例 |
ExternalEnvTag 指定された環境変数の値をタグフィールドにマッピングします。フォーマット: | |
ExternalK8sLabelTag Kubernetes Pod ラベルの値をタグフィールドにマッピングします。フォーマット: |
構成例
NGINX アクセスログを収集し、構造化フィールドに解析
NGINX ログを解析し、log_format の定義に基づいてログコンテンツを複数のキーと値のペアに構造化します。
マルチラインログの収集と処理
マルチラインモードを有効にすることで、定義された開始パターンに基づいて関連する行が 1 つのログエントリにグループ化されます。以下に例を示します。
よくある質問
ACK クラスターから別の Alibaba Cloud アカウントのプロジェクトにログを送信するにはどうすればよいですか?
ACK クラスターに LoongCollector (Logtail) を手動でインストールし、対象の Alibaba Cloud アカウント ID または AccessKey を設定します。これにより、コンテナログを別の Alibaba Cloud アカウントの SLS プロジェクトに送信できます。
ユースケース:組織構造、権限の分離、または一元的なモニタリングなどの理由により、ACK クラスターから別の Alibaba Cloud アカウントの SLS プロジェクトにログデータを収集します。クロスアカウント構成のために 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 アカウントの UID。引用符で囲んでください。例: "123456789" aliUid: "" # ネットワークタイプ。オプション:Internet(パブリックネットワーク)および Intranet(内部ネットワーク)。デフォルト値:Internet。 net: Internet # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID および AccessKey Secret。アカウントまたはユーザーには AliyunLogFullAccess システムポリシーが必要です。 accessKeyID: "" accessKeySecret: "" # カスタムクラスター 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}ログ収集ノードの集合です。
重要LoongCollector は、名前が config-operation-log の Logstore を作成しません。すでに同名の Logstore が存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。
同じログファイルまたはコンテナ標準出力を複数の収集設定で同時に収集するにはどうすればよいですか?
デフォルトでは、データ重複を防ぐため、各ログソースは 1 回のみ収集されます。複数の設定で同じソースから収集を許可するには、Logtail 構成設定で対応するオプションを有効にしてください。
Simple Log Service コンソールにログインし、対象のプロジェクトに移動します。
ナビゲーションウィンドウで、
Logstore を選択し、対象の Logstore を見つけます。その名前の前の
アイコンをクリックして Logstore を展開します。Logtail 構成をクリックします。構成リストで、対象の Logtail 構成を見つけ、[操作] 列の Logtail 構成の管理をクリックします。
Logtail 構成ページで、編集をクリックし、入力構成セクションまでスクロールダウンします:
テキストログファイルを収集する場合:ファイルの複数回収集を許可を有効にします。
コンテナ標準出力を収集する場合:異なる Logtail 構成による収集を許可を有効にします。
付録:コンテナフィルタリングにおける正規表現の制限
コンテナフィルタリングに使用する正規表現は、Go 言語の RE2 エンジンに基づいています。このエンジンは、PCRE などの他の正規表現エンジンと比較して、構文上の制限がいくつか存在します。正規表現を作成する際は、以下の制限事項にご注意ください。
1. 名前付きグループの構文の違い
Go 言語では、名前付きグループに (?P<name>...) 構文を使用します。(?<name>...) のような PCRE で使用される構文はサポートされていません。
正しい例:
(?P<year>\d{4})不適切な構文:
(?<year>\d{4})
2. サポートされていない正規表現の特徴
以下に示す一般的かつ複雑な正規表現の特徴は、RE2 では利用できません。
アサーション:
(?=...)、(?!...)、(?<=...)、(?<!...)条件式:
(?(condition)true|false)再帰的マッチング:
(?R)、(?0)サブプログラム参照:
(?&name)、(?P>name)アトミックグループ:
(?>...)
3. 推奨事項
Regex101 などのツールで正規表現のデバッグを行う場合、互換性を確保するために「Golang (RE2)」モードを選択してください。サポートされていない構文を使用すると、プラグインが式を正しく解析またはマッチできない可能性があります。