Simple Log Service:コンテナログ (標準出力およびファイル) の収集

1. グローバル設定と入力設定

このステップでは、収集設定の名前、ログソース、および範囲を定義します。

収集されたログの表示

1. ログファイルに新しいコンテンツがあることを確認する：LoongCollector は増分ログのみを収集します。tail -f /path/to/your/log/file を実行し、ビジネス運用をトリガーして、新しいログが書き込まれていることを確認します。

2. ログの検索：対象の Logstore の検索 & 分析ページに移動します。検索と分析 をクリックします。デフォルトの時間範囲は過去 15 分です。新しいログが取り込まれているか確認します。収集された各コンテナテキストログには、デフォルトで以下のフィールドが含まれます：

   パラメーター	説明
   __tag__:__hostname__	コンテナホストの名前。
   __tag__:__path__	コンテナ内のログファイルのパス。
   __tag__:_container_ip_	コンテナの IP アドレス。
   __tag__:_image_name_	コンテナが使用するイメージの名前。
   __tag__:_pod_name_	Pod の名前。
   __tag__:_namespace_	Pod の名前空間。
   __tag__:_pod_uid_	Pod の一意の識別子 (UID)。

Pod の履歴ノードのクエリ

Pod がドリフトまたは再起動した場合、ACK クラスターの Kubernetes イベントログを SLS でクエリして、Pod が以前に実行されていたノードを見つけることができます。

1. SLS コンソールにログインし、プロジェクトリストで k8s-log-{cluster_id} プロジェクトを見つけます。

2. k8s-event LogStore をクリックして、クエリと分析ページに移動します。

3. 検索ボックスに、Pod 名でフィルタリングするクエリ文を入力します。例：pod_name: my-pod、そして [検索 & 分析] をクリックします。

4. 返された結果で、hostname フィールドの値を確認します。この値は、Pod が実行されていたノードのホスト名です。

一般的な問題のトラブルシューティング

複数宛先配信設定の管理

複数宛先配信設定は複数の Logstore に適用されるため、プロジェクトレベルの管理ページから管理します：

1. SLS コンソールにログインし、対象のプロジェクト名をクリックします。

2. 「プロジェクト」ページの左側のナビゲーションウィンドウで、リソースグループ > 設定の管理をクリックします。

   説明

   このページでは、誤って削除された Logstore の設定を含む、プロジェクト内のすべての収集設定を管理します。

ACK ログをクロスアカウントのプロジェクトに送信する

ACK クラスターに LoongCollector (Logtail) コンポーネントを手動でインストールし、対象アカウントの Alibaba Cloud アカウント ID またはアクセス認証情報 (AccessKey) で設定することで、コンテナログを別の Alibaba Cloud アカウントの SLS プロジェクトに送信できます。

シナリオの説明：組織、権限、またはモニタリングの目的で、別のアカウントの SLS プロジェクトにログデータを収集する必要がある場合は、LoongCollector (Logtail) を手動でインストールしてクロスアカウント収集を有効にします。

手順：LoongCollector を手動でインストールするには、以下の手順に従ってください。Logtail のインストール方法については、「Logtail のインストールと設定」をご参照ください。

1. Kubernetes クラスターに接続し、ご利用のリージョンに適したコマンドを実行します：

   中国リージョン

   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.sh

2. loongcollector-custom-k8s-package ディレクトリに移動し、./loongcollector/values.yaml 設定ファイルを変更します。

   # ===================== 必須情報 =====================
   # このクラスターからのログが送信されるプロジェクトの名前。例：k8s-log-custom-sd89ehdq
   projectName: ""
   # プロジェクトが配置されているリージョン。例：cn-shanghai
   region: ""
   # プロジェクトを所有する Alibaba Cloud アカウントの UID。UID は引用符 ("") で囲んでください。例："123456789"
   aliUid: ""
   # ネットワークタイプ。有効な値：Internet および Intranet。デフォルト値：Internet。
   net: Internet
   # Alibaba Cloud アカウントまたは RAM ユーザーの AccessKey ID と AccessKey Secret。アカウントまたは RAM ユーザーには AliyunLogFullAccess システムポリシー権限が必要です。
   accessKeyID: ""
   accessKeySecret: ""
   # カスタムクラスター ID。ID には、大文字、小文字、数字、ハイフン (-) のみを含めることができます。
   clusterID: ""

3. loongcollector-custom-k8s-package ディレクトリで、以下のコマンドを実行して LoongCollector とその依存関係をインストールします：

   bash k8s-custom-install.sh install

4. インストールが完了したら、コンポーネントが実行されていることを確認します。

   Pod の起動に失敗した場合は、values.yaml ファイルの設定を確認し、必要なイメージがプルされていることを確認してください。

   # Pod のステータスを確認
   kubectl get po -n kube-system | grep loongcollector-ds

   SLS はまた、以下のリソースを自動的に作成します。これらは SLS コンソールで確認できます。

   リソースタイプ	リソース名	説明
   プロジェクト	values.yaml ファイルで指定した projectName の値	異なるサービスのログを分離します。 柔軟なログ管理のために、「プロジェクトの作成」をご参照ください。
   マシングループ	k8s-group-${cluster_id}	ログ収集ノードのコレクションです。Kubernetes ノードの IP アドレスはクラスターのスケールインまたはスケールアウトに伴い動的に変更されるため、IP アドレスでマシングループを識別するとハートビートの失敗を引き起こす可能性があります。そのため、Kubernetes シナリオのマシングループではカスタム識別子を使用します。詳細については、「収集設定とマシングループを関連付けるためのガイド」をご参照ください。

   重要

   LoongCollector コンポーネントは config-operation-log という名前の Logstore を作成しません。この Logstore が既に存在する場合、LoongCollector はそこにログを書き込みません。

同じソースに対して複数の設定を使用する

デフォルトでは、データの重複を防ぐため、SLS は各ソースからログを収集するために 1 つの収集設定のみを許可します：

• テキストログファイルは、1 つの Logtail 収集設定にのみ一致できます。

• コンテナの標準出力 (stdout)：

  • 新しいバージョンの標準出力テンプレートを使用する場合、stdout はデフォルトで 1 つの標準出力収集設定によってのみ収集できます。

  • 古いバージョンの標準出力テンプレートを使用する場合、追加の設定は不要で、デフォルトで複数の収集がサポートされます。

1. SLS コンソールにログインし、対象のプロジェクトに移動します。

2. 左側のナビゲーションウィンドウで、[Logstores] を選択し、対象の Logstore を見つけます。

3. その名前の隣にある アイコンをクリックして Logstore を展開します。

4. Logtail構成 をクリックします。設定のリストで、対象の Logtail 構成を見つけ、[操作] 列の Logtail 設定の管理 をクリックします。

5. Logtail 構成ページで、編集 をクリックし、入力設定 セクションまでスクロールします：

   • テキストファイルログを収集するには、ファイルを複数回収集できるようにする を有効にします。

   • コンテナの標準出力を収集するには、標準出力の複数回の収集を許可する を有効にします。

loongcollector のアンインストール時の依存関係エラー

問題： ACK で loongcollector (logtail-ds) コンポーネントをアンインストールしようとすると、コンポーネントの依存関係が満たされていないというエラーが表示されます。

Dependencies of addons are not met: terway-eniip depends on logtail-ds(>0.0) whose version is v3.x.x.x-aliyun or will be v3.x.x.x-aliyun.

原因： terway-eniip ネットワークプラグインでログ収集が有効になっており、これにより loongcollector (logtail-ds) コンポーネントへの依存関係が作成されます。そのため、この依存関係を削除するまで、ACK は loongcollector (logtail-ds) のアンインストールを許可しません。

解決策： 以下の手順に従って依存関係を削除し、コンポーネントをアンインストールします：

1. ACK コンソールにログインします。

2. クラスターリストで、対象クラスターの名前をクリックして詳細ページに移動します。

3. 左側のナビゲーションウィンドウで、アドオン管理 をクリックします。

4. アドオンのリストで、terway-eniip コンポーネントを検索し、ログを閉じる をクリックします。

5. 表示されるダイアログボックスで、OK をクリックします。

6. 設定が有効になった後、loongcollector (logtail-ds) コンポーネントを再度アンインストールしてみてください。

最後のログエントリの遅延または切り捨て

原因： ログの切り捨ては通常、ログファイルの最後の改行が欠落している場合、または例外スタックなどの複数行のログエントリが完全に書き込まれていない場合に発生します。コレクターはログエントリが完了したかどうかを判断できないため、最後のログエントリが分割されたり遅延したりすることがあります。これがどのように処理されるかは、お使いの LoongCollector (Logtail) のバージョンによって異なります：

• 1.8 より前のバージョン：
  ログの最後の行に改行がない場合、または複数行のログブロックが不完全な場合、コレクターは次の書き込み操作が出力をトリガーするのを待ちます。これにより、新しいログが書き込まれるまで最後のログエントリが大幅に遅延する可能性があります。
  
  
  
  

• バージョン 1.8 以降：
  これらのバージョンでは、ログが滞留するのを防ぐためのタイムアウトフラッシュメカニズムが導入されています。不完全なログ行が検出されると、システムはタイマーを開始します。タイムアウト期間が経過すると、現在のコンテンツが自動的に送信され、ログが最終的に収集されることが保証されます。
  
  
  
  

  • デフォルトのタイムアウト：60 秒 (ほとんどのシナリオでデータ整合性を保証)

  • 要件に応じてこの値を調整できます。ただし、0 に設定するとログの切り捨てや部分的なデータ損失が発生する可能性があるため、推奨されません。

解決策：

待機時間を延長して、収集される前に完全なログエントリが書き込まれるようにすることができます：

1. SLS コンソールにログインし、対象のプロジェクトに移動します。

2. 左側のナビゲーションウィンドウで、[Logstores] を選択し、対象の Logstore を見つけます。

3. その名前の隣にある アイコンをクリックして Logstore を展開します。

4. Logtail構成 をクリックします。設定のリストで、対象の Logtail 構成を見つけ、[操作] 列の Logtail 設定の管理 をクリックします。

5. Logtail 構成ページで、編集 をクリックします。

   • 入力設定 > その他の入力設定 > 高度なパラメーター に移動し、以下の JSON 設定を追加してタイムアウト期間をカスタマイズします。

     {
       "FlushTimeoutSecs": 1
     }

     • デフォルト値：default_reader_flush_timeout 起動パラメーターによって決定され、通常は数秒です。

     • 単位：秒。

     • 推奨値：≥ 1 秒。0 に設定するとログの切り捨てや部分的なデータ損失が発生する可能性があるため、推奨されません。

6. 設定完了後、OK をクリックします。

LoongCollector ネットワークのフェールオーバーと回復

LoongCollector (Logtail) が内部ネットワーク接続の問題 (障害やタイムアウトなど) を検出すると、自動的にパブリックネットワークに切り替わります。このフェールオーバーメカニズムにより、信頼性の高いログ収集が保証され、バックログやデータ損失が防止されます。

• LoongCollector：ネットワークが回復すると、自動的に内部ネットワークに切り替わります。

• Logtail：自動的には切り替わりません。内部ネットワーク通信を復元するには、再起動する必要があります。

Logtail構成 ページの 設定の処理 エリアで、処理プラグインを追加して生ログを構造化できます。既存の収集設定に処理プラグインを追加するには、以下の手順に従います：

1. 左側のナビゲーションウィンドウで、[Logstores] を選択し、宛先の Logstore を見つけます。

2. その名前の左にある をクリックして Logstore を展開します。

3. Logtail構成 をクリックします。構成リストで、宛先の Logtail 構成を見つけ、[操作] 列の Logtail 設定の管理 をクリックします。

4. Logtail 構成ページで、編集 をクリックします。

このセクションでは、一般的なログ処理シナリオをカバーする、よく使用される処理プラグインのみを紹介します。その他の機能については、「拡張処理プラグイン」をご参照ください。

デリミタ解析

05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java

ip:10.10.*.*
request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1
size:18204
status:200
time:05/May/2025:13:30:28
user_agent:aliyun-sdk-java

標準 JSON 解析

{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}

ip: 10.200.98.220
request: {"status": "200", "latency" : "18204" }
time: 05/Jan/2025:13:30:28
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1
user-agent:aliyun-sdk-java

ネストされた JSON 解析

{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}

0_s_key_k1_k2_k3_k41:41
0_s_key_k1_k2_k3_k4_k51:51
0_s_key_k1_k2_k3_k4_k52:52

1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

JSON 配列解析

[{"key1":"value1"},{"key2":"value2"}]

json1:{"key1":"value1"}
json2:{"key2":"value2"}

* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

Apache ログ解析

1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36"

http_referer:https://www.example.com/referrer
http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36
remote_addr:192.168.1.10
remote_ident:-
remote_user:-
request_method:GET
request_protocol:HTTP/1.1
request_uri:/index.html
response_size_bytes:1234
status:200
time_local:[08/May/2024:15:30:28 +0800]

データマスキング

ログ内の機密データをマスキングします。

例：

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]

[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

手順： Logtail構成 ページの 設定の処理 セクションで、処理プラグインの追加 をクリックし、ネイティブ処理プラグイン > データマスキング処理 を選択します：

• 元のフィールド：マスキング対象のコンテンツを含むソースフィールド。

• マスキング方法：

  • const：機密コンテンツを指定された文字列に置き換えます。

  • md5：機密コンテンツをその MD5 ハッシュ値に置き換えます。

• 文字列の置き換え：マスキングに使用する文字列。マスキング方法 が const に設定されている場合に必須です。

• 置き換えられたコンテンツより前のコンテンツの式：機密データの直前のコンテンツを特定するための RE2 構文の正規表現。

• 置き換えられたコンテンツの式：置換したい機密データに一致する RE2 構文の正規表現。

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) モードを選択してください。サポートされていない構文を使用すると、プラグインは式の解析またはマッチングに失敗します。

新しい標準出力の主な利点

• 大幅なパフォーマンス向上

• C++ でリファクタリングされた新しいバージョンは、以前の Go 実装に比べて 180% から 300% のパフォーマンス向上を実現します。

• ネイティブプラグインによるデータ処理とマルチスレッド並列処理をサポートし、システムリソースを最大限に活用します。

• ネイティブプラグインと Go プラグインの柔軟な組み合わせをサポートし、複雑なシナリオのニーズに対応します。

• より高い信頼性

• 標準出力ログのローテーションキューをサポートし、ログ収集メカニズムをファイル収集メカニズムと統一することで、標準出力ログが急速にローテーションする場合でも高い信頼性を提供します。

• より低いリソース消費

• CPU 使用率が 20% から 25% 削減されます。

• メモリ使用量が 20% から 25% 削減されます。

• O&M の一貫性向上

• 統一されたパラメーター設定：新しい標準出力収集プラグインの設定パラメーターは、ファイル収集プラグインのものと一貫しています。

• 統一されたメタデータ管理：コンテナメタデータフィールドの命名とタグの保存場所がファイル収集シナリオと統一されているため、コンシューマー側は 1 つの処理ロジックのみを維持します。

新旧バージョンの機能比較

コンテナメタデータフィールドのマッピング

新しいバージョンでは、すべてのメタデータフィールドはログコンテンツに埋め込まれるのではなく、__tag__:<key> 形式でログのタグセクションに保存されます。

新バージョンがユーザーに与える影響

• コンシューマー側の適応：保存場所がコンテンツからタグに変更されるため、ログ消費ロジックをそれに応じて調整する必要があります。例えば、クエリを実行する際には __tag__ を通じてフィールドにアクセスする必要があります。

• SQL 互換性：クエリ SQL は既に両方のバージョンに自動的に互換性があるため、どちらのバージョンのログを処理する場合でもクエリ文を変更する必要はありません。