ログ収集設定を Kubernetes CRD として定義することで、バージョン管理、環境固有のデプロイ、および kubectl または CI/CD パイプラインを使用した Container Service for Kubernetes (ACK) クラスターおよび自己管理型クラスター間での自動リリースが可能になります。LoongCollector は、再起動なしで設定変更をホットリロードします。
レガシーの AliyunLogConfig CRD は非推奨です。代わりに AliyunPipelineConfig を使用してください。比較については、CRD タイプをご参照ください。CRD ベースの収集設定は、CRD を更新することによってのみ変更できます。Simple Log Service (SLS) コンソールで行われた変更は同期されず、有効になりません。
適用範囲
動作環境
ACK クラスター (マネージド版および専用版) および自己管理型 Kubernetes クラスター。
Kubernetes のバージョンは 1.16.0 以降であり、
Mount propagation: HostToContainerをサポートしている必要があります。コンテナランタイム (Docker および Containerd のみ)
Docker:
docker.sock へのアクセスが必要です。
標準出力収集は、JSON-file ログドライバーのみをサポートします。
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 を使用してクラスターに接続します。収集設定ファイルは、次の 2 つの方法のいずれかで作成できます。
方法 1:収集設定ジェネレーターの使用
Log Service コンソールの収集設定ジェネレーターを使用して、パラメーターを視覚的に設定し、標準の YAML ファイルを自動的に生成します。
方法 2:YAML ファイルの手動作成
このドキュメントの例に基づいて YAML ファイルを手動で作成します。最小構成から始めて、処理ロジックを追加し、次に高度な機能を有効にするというように、段階的に構築します。
このドキュメントでカバーされていない複雑なシナリオや、詳細なカスタマイズが必要なフィールドについては、フィールドの完全なリスト、値のルール、およびプラグイン機能の詳細について、AliyunPipelineConfig パラメーターリファレンスをご参照ください。
完全な収集設定は、通常、次の部分で構成されます。
最小構成 (必須):この構成は、クラスターから 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 は SLS の次世代ログ収集エージェントであり、Logtail のアップグレード版です。両者は共存できません。代わりに Logtail をインストールするには、Logtail のインストールと設定をご参照ください。
基本的な LoongCollector のインストールについては、以下の手順に従ってください。詳細なパラメーターについては、インストールと設定をご参照ください。LoongCollector または Logtail がすでにインストールされている場合は、logstore の作成に進んでください。
ACK クラスター
LoongCollector は ACK コンソールからインストールできます。デフォルトでは、ログは現在の Alibaba Cloud アカウント配下の SLS プロジェクトに送信されます。
-
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、対象のクラスターの名前をクリックしてその詳細ページを開きます。
左側のナビゲーションウィンドウで、アドオン管理 をクリックします。
ログとモニタリング タブで loongcollector を見つけ、インストール をクリックします。
説明クラスターを作成する際、コンポーネント設定 ページで、Log Service の使用 チェックボックスをオンにします。その後、プロジェクトの作成 または プロジェクトの選択 を選択できます。
インストールが完了すると、SLS は ACK クラスターのリージョンに関連リソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。
リソースタイプ
リソース名
説明
プロジェクト
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 # AliyunLogFullAccess ポリシーを持つ Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID とシークレット。 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 はまた、以下のリソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。
リソースタイプ
リソース名
説明
プロジェクト
values.yaml ファイルで指定した
projectNameの値異なるサービスからのログを分離します。
マシングループ
k8s-group-${cluster_id}ログ収集ノードのグループ。
重要LoongCollector は config-operation-log という名前の Logstore を作成しません。この名前の Logstore が既に存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。
Logstore の作成
すでに Logstore を作成している場合は、このステップをスキップして収集設定に進んでください。
Log Service コンソールにログインし、ターゲットのプロジェクトをクリックします。
左側のナビゲーションウィンドウで、
を選択し、[+] をクリックします。Logstore の作成ページで、次のコアパラメーターを設定します。
Logstore 名:プロジェクト内で一意の名前を入力します。この名前は作成後に変更できません。
Logstore タイプ:仕様に基づいて標準ストレージまたはクエリを選択します。
課金モード:
使用機能に基づく課金:ストレージ、インデックス、読み取り/書き込み操作など、各リソースに対して個別に課金されます。小規模なユースケースや、機能の使用量が不確かな場合に適しています。
書き込みデータ量課金:取り込まれた生データの量に対してのみ課金されます。このモードでは、30 日間の無料ストレージ期間と、データ変換や配信などの無料機能が提供されます。このシンプルなコストモデルは、ストレージ期間が 30 日に近い場合や、データ処理パイプラインが複雑な場合に最適です。
Data Retention Period:ログを保持する日数を設定します。値の範囲は 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> では、入力プラグインと出力プラグインを設定して、ログソースとログの送信先を定義します。
コンテナ標準出力
目的:コンソールに直接出力されるコンテナ標準出力ログ (stdout/stderr) を収集します。
ログソースを定義します。現在、1 つの入力プラグインのみを設定できます。
| 例 |
収集されたログをプロジェクト内の指定された Logstore に送信します。最大 5 つの出力プラグインを設定できます。
|
コンテナテキストファイル
目的:コンテナ内の特定のファイルパスに書き込まれたログ (access.log や app.log など) を収集します。
ログソースを定義します。現在、1 つの入力プラグインのみを設定できます。
| 例 |
収集されたログをプロジェクト内の指定された Logstore に送信します。最大 5 つの出力プラグインを設定できます。
|
一般的な設定
最小構成を完了した後、processor プラグインを追加して、生ログを解析、マスキング、またはフィルタリングします。
コア構成: 処理プラグインを構成するには、<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> に processors を追加します。これにより、複数のプラグインを同時に有効にすることができます。
このトピックでは、一般的なログ処理のユースケースを処理するネイティブ処理プラグインのみを扱います。その他の機能については、拡張処理プラグインをご参照ください。
Logtail 2.0+ および LoongCollector の場合、以下のプラグインの順序ガイドラインに従ってください。
ネイティブプラグインを優先します。
ネイティブプラグインがニーズを満たさない場合は、それらの後に実行されるように拡張プラグインを設定します。
ネイティブプラグインは、拡張プラグインの前にのみ実行できます。
構造化設定
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
Regex ログを解析するための正規表現。 | |
Keys 抽出されたフィールドのキーのリスト。 | |
KeepingSourceWhenParseFail 解析に失敗した場合にソースフィールドを保持するかどうか。デフォルト: | |
KeepingSourceWhenParseSucceed 解析が成功した場合にソースフィールドを保持するかどうか。デフォルト: | |
RenamedSourceKey 保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。 |
デリミタ解析
単一または複数文字のデリミタを使用して、ログをキーと値のペアに解析します。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
Separator フィールドのデリミタ。たとえば、CSV ファイルはカンマ (,) を使用します。 | |
Keys 抽出されたフィールドのキーのリスト。 | |
Quote デリミタなどの特殊文字を含むフィールドを囲むために使用される引用符。 | |
AllowingShortenedFields Keys よりも少ない抽出フィールドを許可するかどうか。デフォルト: | |
OverflowedFieldsTreatment Keys よりも多くのフィールドが抽出された場合の動作。デフォルト:
| |
KeepingSourceWhenParseFail 解析に失敗した場合にソースフィールドを保持するかどうか。デフォルト: | |
KeepingSourceWhenParseSucceed 解析が成功した場合にソースフィールドを保持するかどうか。デフォルト: | |
RenamedSourceKey 保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。 |
標準 JSON 解析
ログフィールドから JSON オブジェクトをキーと値のペアに解析します。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
KeepingSourceWhenParseFail 解析に失敗した場合にソースフィールドを保持するかどうか。デフォルト: | |
KeepingSourceWhenParseSucceed 解析が成功した場合にソースフィールドを保持するかどうか。デフォルト: | |
RenamedSourceKey 保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。 |
CRD YAML のパラメーター名は camelCase (例:RenamedSourceKey) を使用します。snake_case (例:renamed_source_key) の名前は無効です。
ネストされた JSON 解析
ネストされた JSON オブジェクトをキーと値のペアにフラット化し、展開の深さを指定できます。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
ExpandDepth ネストされた JSON オブジェクトの最大展開深度。デフォルト:0。
| |
ExpandConnector ネストされた JSON オブジェクトをフラット化する際にキーの間で使用されるコネクタ。デフォルト:アンダースコア (_)。 | |
Prefix すべての展開されたフィールド名に追加するプレフィックス。 | |
IgnoreFirstConnector 最上位フィールドの前のコネクタを省略するかどうか。デフォルト: | |
ExpandArray 配列タイプを展開するかどうか。デフォルト:
説明 このパラメーターは Logtail 1.8.0 以降でサポートされています。 | |
KeepSource 解析されたログに元のフィールドを保持するかどうか。デフォルト:
| |
NoKeyError 指定されたソースフィールドが見つからない場合にエラーを報告するかどうか。デフォルト:
| |
UseSourceKeyAsPrefix true に設定すると、すべての展開されたフィールド名のプレフィックスとしてソースフィールド名を使用します。 | |
KeepSourceIfParseError 解析に失敗した場合に生ログを保持するかどうか。デフォルト:
|
JSON 配列解析
json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。JSON 関数。
パラメーター | 例 |
Type プラグインタイプ。SPL プラグインタイプは | |
Script content フィールドの JSON 配列から要素を抽出するために使用される SPL スクリプト。 | |
TimeoutMilliSeconds スクリプト実行のタイムアウト (ミリ秒)。値は 0〜10,000 の間でなければなりません。デフォルト値:1,000。 |
NGINX ログ解析
log_format 定義に基づいて、NGINX ログをキーと値のペアに解析します。デフォルトのフォーマットが要件を満たさない場合は、カスタムフォーマットを使用できます。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
Regex NGINX ログを解析するための正規表現。 | |
Keys 抽出されたフィールドのキーのリスト。 | |
Extra
| |
KeepingSourceWhenParseFail 解析に失敗した場合に元のフィールドを保持するかどうか。デフォルト: | |
KeepingSourceWhenParseSucceed 解析が成功した場合に元のフィールドを保持するかどうか。デフォルト: | |
RenamedSourceKey 保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。 |
Apache ログ解析
Apache 設定ファイルで定義されたフォーマットに基づいて、Apache ログをキーと値のペアに解析します。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
Regex Apache ログを解析するための正規表現。 | |
Keys 抽出されたフィールドのキーのリスト。 | |
Extra
| |
KeepingSourceWhenParseFail 解析に失敗した場合に元のフィールドを保持するかどうか。デフォルト: | |
KeepingSourceWhenParseSucceed 解析が成功した場合に元のフィールドを保持するかどうか。デフォルト: | |
RenamedSourceKey 保持される場合のソースフィールドの新しい名前。省略した場合、ソースフィールドは名前変更されません。 |
データマスキング
processor_desensitize_native プラグインを使用して、ログ内の機密データをマスキングします。
パラメーター | 例 |
Type
| |
SourceKey ソースフィールドの名前。 | |
Method マスキング方法。サポートされている値:
| |
ReplacingString 機密データを置き換える定数文字列。このパラメーターは、 | |
ContentPatternBeforeReplacedString 機密データの前にあるコンテンツの正規表現。 | |
ReplacedContentPattern 機密データに一致する正規表現。 | |
ReplacingAll すべての一致を置き換えるかどうか。デフォルト: |
コンテンツフィルタリング
processor_filter_regex_native プラグインを設定して、ログフィールドの値を正規表現と照合し、一致するログのみを保持します。
パラメーター | 例 |
Type プラグインタイプ。この値は | |
FilterRegex ログフィールドの値に一致させるための正規表現のリスト。 | |
FilterKey FilterRegex パターンを適用するログフィールド名のリスト。 |
時刻解析
ログの時刻フィールドを解析し、その結果をログの __time__ フィールドとして使用します。
キーフィールド | 例 |
Type プラグインタイプ。 | |
SourceKey ソースフィールド名。 | |
SourceFormat 時刻フォーマット。これはログの時刻フォーマットと完全に一致する必要があります。 | |
SourceTimezone ソースタイムスタンプのタイムゾーン。デフォルト:LoongCollector を実行しているマシンのタイムゾーン。 フォーマット:
|
高度な設定
最小構成を完了した後、これらの高度な設定を使用して、より詳細な収集を行います。
複数行ログ収集の設定:開始パターンの正規表現で複数行モードを有効にし、複数行にまたがるエントリ (スタックトレースなど) を単一のログレコードとして収集します。
ログトピックタイプの設定:ログストリームにトピックを割り当てて、整理と取得を容易にします。
収集対象コンテナの指定 (フィルタリングとブラックリスト登録):ホワイトリストとブラックリストを使用して、特定のコンテナとパスからのみログを収集します。
タグによるログのエンリッチ:環境変数と Pod ラベルからのメタデータをログにタグとして追加します。
複数行ログ収集の設定
デフォルトでは、SLS はログを 1 行ずつ分割し、スタックトレースのような複数行のエントリを別々のレコードに分割します。
複数行モードを有効にし、開始パターンの正規表現を設定して、複数行のエントリを単一のログレコードにグループ化します。
キー設定:<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 トピックフォーマット。このパラメーターは、 |
コンテナのフィルタリングとブラックリスト登録
フィルタリング
指定された条件に一致するコンテナからのみログを収集します。複数の条件は論理 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 (Perl 互換正規表現) などのエンジンと比較して特定の制限があります。正規表現は、付録:コンテナフィルタリングの正規表現の制限のガイドラインに従って記述してください。 | |
ブラックリスト登録
指定された基準に一致するファイルを除外します。これを行うには、必要に応じて 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:複数行ログの処理
デフォルトでは、SLS は各行を個別のログエントリとして扱い、スタックトレースのような複数行のログを複数のレコードに分割します。
開始パターンの正規表現で複数行モードを有効にして、複数行ログのすべての行を単一のエントリにグループ化します。
よくある質問
複数ターゲットへの配信の管理
複数ターゲットへの配信設定は複数の Logstore に関連付けられており、プロジェクトレベルの管理ページで管理する必要があります。
SLS コンソールにログインし、ターゲットプロジェクトの名前をクリックします。
「プロジェクト」ページの左側のナビゲーションウィンドウで、
をクリックします。説明このページには、誤って削除された Logstore の残りの設定を含む、プロジェクト内のすべての収集設定がリストされます。
ACK ログをアカウントをまたいだプロジェクトに送信する
ACK クラスターに LoongCollector (Logtail) を手動でインストールし、ターゲットアカウントの認証情報で設定して、別の Alibaba Cloud アカウントのプロジェクトにログを送信します。
利用シーン:組織構造、権限隔離、または統一されたモニタリングのために、ACK クラスターから別のアカウントのプロジェクトにログを収集します。
操作手順:この手順では、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 # AliyunLogFullAccess ポリシーを持つ Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID とシークレット。 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 はまた、以下のリソースを自動的に作成します。これらのリソースは SLS コンソールで表示できます。
リソースタイプ
リソース名
説明
プロジェクト
values.yaml ファイルで指定した
projectNameの値異なるサービスからのログを分離します。
マシングループ
k8s-group-${cluster_id}ログ収集ノードのグループ。
重要LoongCollector は config-operation-log という名前の Logstore を作成しません。この名前の Logstore が既に存在する場合、LoongCollector はその Logstore へのログ書き込みを停止します。
単一ソースに対する複数収集
デフォルトでは、SLS は重複を防ぐために、各ログソースを単一の収集設定に制限します。
テキストログファイルは、1 つの Logtail 収集設定にのみ一致できます。
コンテナの標準出力 (stdout) は、1 つの標準出力収集設定にのみ一致できます。
SLS コンソールにログインし、ターゲットプロジェクトに移動します。
左側のナビゲーションウィンドウで、
Logstore を選択し、ターゲットの 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) モードを選択してください。サポートされていない構文を使用すると、プラグインが正しく解析またはマッチングできなくなります。