Simple Log Service:LoongCollector のログ収集遅延の分析

症状

CloudLens for SLS の [LoongCollector Pipeline Monitoring] ダッシュボードで、[Pipeline Overview] レポートを表示します。最後の列である [Quota error count] には、サーバー側の制限を超えたために、クエリした時間範囲内で LoongCollector が SLS への書き込みに失敗した回数が表示されます。

LoongCollector がスロットリングされると、[Quota error count] が赤色でハイライトされます。

原因

SLS には、Project、LogStore、シャードなどのリソースの概念があります。すべてのテナントに信頼性の高いサービス品質 (QoS) を保証するため、各リソースには関連するリソースのスロットリング制限と解決策があります。これらの制限を超えると、データ読み取り/書き込みの失敗やリクエストの例外につながる可能性があります。

LoongCollector のデータ収集シナリオでは、一般的なクォータエラーが 2 つあります：

• WriteQuotaExceed：このエラーは、特定の期間内に Project へのデータ総量または書き込みリクエスト数がクォータ制限を超え、後続のリクエストが失敗したことを示します。このエラーは、必ずしも単一の収集設定によって引き起こされるものではなく、複数の収集設定と LogStore からのトラフィックが組み合わさった結果である可能性があります。

• ShardWriteQuotaExceed：このエラーは、単一の LogStore へのデータ総量または書き込みリクエスト数がクォータ制限を超えたことを示します。LogStore の書き込み容量は、そのシャードによって決まります。詳細については、「シャードの管理」をご参照ください。

クォータ超過により LoongCollector がデータ送信に失敗すると、データが正常に送信されるまで継続的に再試行します。ただし、送信されるデータ総量はクォータ制限を超えることはできません。これにより、リクエストのバックログが増大します。その結果、各リクエストの送信待機時間が長くなり、収集遅延が発生します。

CloudLens for SLS の [LoongCollector Pipeline Monitoring] ダッシュボードで、[Pipeline Send Status Details] を確認し、Project または LogStore のシャードの制限を超えたかどうかを判断できます。

ソリューション

• Project の書き込みクォータを超えた場合は、「シャードの管理」の「リソースクォータの管理」を参照して、[Project write traffic limit] と [Project write QPS limit] パラメーターを調整します。その後、クォータの引き上げをリクエストします。

  • 一般的なガイドラインとして、毎回現在のクォータを約 50% 引き上げるようにリクエストできます。

• LogStore のシャードの書き込みクォータを超えた場合は、「シャードの管理」の「シャード分割」および「自動シャード分割」セクションを参照して、LogStore のシャード数を調整します。

  • 各シャードは、最大 5 MB/s または 500 リクエスト/秒のデータ書き込み、および最大 10 MB/s または 100 リクエスト/秒のデータ読み取りをサポートします。これらはソフトリミットです。これらを超えた場合、SLS はサービスの提供を継続しますが、サービス品質は保証できません。

  • 対応する Project の運用ログ LogStore で、ステートメント ((__topic__: loongcollector_metric and category: pipeline and source_ip:* and labels.project: * and labels.logstore: *))| select "labels.project" as project, "labels.logstore" as logstore, round(sum(flusher_in_size_bytes)/1024.0/1024.0, 2) as output_size_bytes group by project, logstore order by output_size_bytes desc limit all を実行して、異なる宛先 LogStore の生データ書き込み量を計算できます。期待されるシャード数を取得するには、結果から最大値を取得し、それを 5 で割り、20% のバッファーを追加します。

アラート設定

クォータ超過は重大な問題です。アラート ルールを作成することを推奨します。

自己監視データを 10 分ごとにチェックしてクォータエラーメッセージを確認し、影響を受ける Project または LogStore に対してアクションを実行して、データレポートの問題を防ぐことができます。

• 監視するログタイプ：運用ログ

• フィルター条件：flusher_project_quota_error_total または flusher_shard_write_quota_error_total フィールドの値が 0 より大きいこと。これらのフィールドは、それぞれ Project のクォータ超過回数と LogStore のシャードのクォータ超過回数に対応します。

• 表示フィールド：特定の期間内にクォータエラーが発生した Project (labels.project)、LogStore (labels.logstore)、および収集設定 (labels.pipeline_name) を表示します。

• クエリ間隔: 10分。 アラートは、__topic__ が loongcollector_metric である自己監視データを使用しており、そのレポート間隔は 10分です。

• サンプルクエリ

__topic__: loongcollector_metric and (flusher_project_quota_error_total>0 or flusher_shard_write_quota_error_total>0) | select "labels.project" as project, "labels.logstore" as logstore, split_part("labels.pipeline_name", '$', 2) as pipeline_name, sum(flusher_project_quota_error_total) as project_quota_error_total, sum(flusher_shard_write_quota_error_total) as shard_write_quota_error_total group by project, logstore, pipeline_name having project_quota_error_total>0 or shard_write_quota_error_total>0 order by pipeline_name limit all

症状

CloudLens for SLS の [LoongCollector Pipeline Monitoring] ダッシュボードで、[Pipeline Send Status Details] までスクロールします。[Send Request Retry Rate] が高く、[Project write quota exceeded count] と [LogStore Shard write quota exceeded count] の両方が 0 の場合、クォータ関連のエラーがないことを示します。代わりに、再試行率が高いことは、ネットワーク品質の低下がタイムリーなデータレポートを妨げ、[収集遅延]を引き起こしていることを示唆しています。

原因

内部的に、LoongCollector は、データの読み取り、処理、送信にパイプラインを使用します。ファイルからデータが読み取られると、順次、処理キュー、そして送信キューに渡されます。ネットワーク品質の低下、データ量が多い、またはその他の理由で LoongCollector の送信能力が制限されると、データを迅速に SLS に送信できません。これにより、SLS でのデータクエリが遅れるだけでなく、送信キューにデータが蓄積されます。この蓄積は、処理キューと読み取りスレッドにバックプレッシャーをかけ、収集遅延をさらに増大させます。

ソリューション

1. ローカルネットワークの品質を確認します。ビジネスサーバーと SLS Project が異なるリージョン (たとえば、一方が中国本土、もう一方が海外) にある場合、内部ネットワークは使用できません。パブリックインターネット経由でデータを転送すると、ネットワーク遅延が大きくなり、不安定になる可能性があります。この場合、転送アクセラレーションを使用して、ネットワークの安定性とパフォーマンスを向上させることができます。

2. LoongCollector は、送信同時実行数を増やすことでデータ送信を高速化できます。起動パラメーターを変更するには、「起動パラメーターを設定する」をご参照ください。送信同時実行数 send_request_concurrency と最大送信トラフィック max_bytes_per_sec を重点的に調整できます。

アラート設定

送信リクエストの再試行率が高い場合にアラートを設定します。

• 監視するログタイプ：運用ログ

• フィルター条件：LoongCollector の収集設定に関連するメトリクス

• 表示フィールド：特定の期間内に再試行率が高い Project、LogStore、および収集設定を表示します。

• クエリ間隔：10 分。メトリクスは 10 分ごとにレポートされます。10 分間隔で再試行率が高い場合、LoongCollector が収集遅延を発生している可能性があります。

• サンプルクエリ

((__topic__: loongcollector_metric and category: pipeline and source_ip:* and labels.pipeline_name:* and labels.project: *))| select "labels.project" as project, split_part("labels.pipeline_name", '$', 2) as pipeline_name,  (sum(flusher_send_done_total)-sum(flusher_success_total))*1.0/(sum(flusher_send_done_total)) as "send_retry_rate" group by project, pipeline_name having "send_retry_rate">0.1 and "send_retry_rate"<=1 order by "send_retry_rate" desc limit all 

症状

まず、SLS サーバー側の書き込みクォータを超えておらず、LoongCollector のデータ送信にボトルネックがないことを確認します。

• 収集ボトルネックの確認

  CloudLens for SLS で [例外モニタリング] を開き、[収集例外モニタリング] セクションで [すべてのエラーメッセージ] を表示し、PROCESS_QUEUE_BUSY_ALARM アラートタイプでフィルターします。 これらのアラートが多数存在する場合、LoongCollector の処理パフォーマンスのボトルネックが収集レイテンシーを引き起こしていることを示します。 CloudLens for SLS コンソールで、[レポートセンター] > [収集モニタリング] を選択し、[例外モニタリング] タブをクリックします。 収集例外モニタリングセクションで、すべてのエラーメッセージを表示します。 PROCESS_QUEUE_BUSY_ALARM が [アラートタイプ] 列に表示された場合、ログ処理キューがいっぱいであることを示します (アラート詳細: logprocess queue is full, put modify event to event queue again)。

• 処理時間が長い収集設定の特定

  CloudLens for SLS の [LoongCollector Pipeline Monitoring] ダッシュボードで、[Pipeline Processing Time Percentage] レポートを表示して、処理時間が長い収集設定を特定できます。

原因

LoongCollector は優れた収集パフォーマンスを発揮します。詳細については、「ログ収集エージェントのパフォーマンス比較 — LoongCollector の詳細なパフォーマンスレビュー」をご参照ください。ネイティブプラグインのみを使用する単一のスレッドは、100 MB/s を超える速度でデータを処理できます。ただし、収集設定で拡張プラグイン、複雑な正規表現、または複数のプラグインのチェーンを使用する場合、データ量が多いと LoongCollector は依然としてパフォーマンスのボトルネックに達する可能性があります。この場合、まず拡張プラグインを SPL プラグインまたはネイティブプラグインに置き換えて、処理パフォーマンスを向上させることを検討する必要があります。それでもパフォーマンスが不十分な場合は、LoongCollector の内部処理スレッド数と CPU 使用率の制限を調整して、データをより効率的に処理する必要があります。

ソリューション

• まず、すべての拡張プラグインをネイティブプラグインに置き換えるか、Logtail SPL を使用してログを解析して、処理パフォーマンスを大幅に向上させます。正規表現解析や JSON 展開などの最も一般的に使用される拡張プラグインのほとんどには、対応するネイティブプラグインがあります。詳細については、「プロセッサープラグインリスト」をご参照ください。

• 可能な限り多くの拡張プラグインをネイティブプラグインに置き換えても、処理性能がまだ不十分な場合は、CPU 使用率の上限と処理スレッド数を増やすことで、LoongCollector のデータ処理を高速化できます。起動パラメーターの設定 を参照して LoongCollector の起動パラメーターを変更する際は、cpu_usage_limit と process_thread_count の調整に注目してください。

アラート設定

PROCESS_QUEUE_BUSY_ALARM エラーのアラートを設定してください。なお、時折発生する PROCESS_QUEUE_BUSY_ALARM エラーは、ログファイルへのデータの急激な書き込みによって発生することがありますが、収集の遅延は引き起こしません。継続的なエラーが発生した場合にのみ、LoongCollector の処理能力が不十分であることを示します。

• 監視するログタイプ：運用ログ

• フィルター条件: alarm_type が PROCESS_QUEUE_BUSY_ALARM の場合、処理キューが満杯であることを示します。

• 表示フィールド：特定の期間内に処理遅延が発生している Project、LogStore、および収集設定を表示します。

• クエリ間隔：5 分。アラート間隔は 30 秒です。5 分以内に 5 回を超えるエラーが発生した場合、LoongCollector が処理能力の不足により収集遅延が発生していることを示します。

• サンプルクエリ

__topic__: logtail_alarm and alarm_type: PROCESS_QUEUE_BUSY_ALARM  | SELECT project, logstore, split_part(config_name, '$', 2) as "collection_configuration", count(1) as cnt from log group by project, logstore, config_name  having cnt >5 order by cnt desc limit all