Simple Log Service：使用CloudLens for SLS分析LoongCollector日誌採集延遲問題

問題現象

在CloudLens for SLS的LoongCollector Pipeline監控，查看Pipeline概覽報表，最後一列為Quota報錯次數，表示在查詢時間範圍內，LoongCollector寫入SLS時因為超過服務端限制而失敗的次數。

如果存在LoongCollector被限流的問題，Quota報錯次數會顯示出來，並標紅高亮警示。

問題原因

Log Service包含Project、LogStore、Shard等資源概念，為保證雲上多租戶更可靠的QoS服務品質，每種資源會設定相關的資源流控及解決方案（即Quota），一旦超過資源流控限制，則會導致讀寫資料失敗，請求異常等後果。

在LoongCollector採集資料情境，常見的Quota報錯有兩種：

• WriteQuotaExceed：說明該Project在一定時間內，寫入的資料總量或寫入的次數過大，導致超過Quota限制的請求失敗了。該報錯發生並不一定是單個採集配置導致，而是多個採集配置、多個LogStore共同造成。

• ShardWriteQuotaExceed：說明單個LogStore在一定時間內，寫入的資料總量或次數過大，導致超過Quota限制的請求失敗了。LogStore的寫入能力由Shard決定，具體的說明請參見管理Shard。

LoongCollector採集的資料因Quota超限失敗時，會不斷重試直到發送成功，但是發送的資料總量不會超過Quota允許的範圍，所以會導致積壓的待重試的請求越來越多，每一次請求都需要等待很久才能上報成功，造成採集延遲。

Cloudlens for SLS中LoongCollector Pipeline監控下方的Pipeline發送狀態詳情，可以查看具體是Project寫入超限，還是LogStore Shard寫入超限。

解決方案

• 如果是Project寫入Quota超限，參考管理Shard的管理資源配額，調整project寫入資料傳輸量上限和project寫入次數上限兩項參數，提交配額。

  • 每次申請可以將當前配額提高50%左右。

• 如果是LogStore的shard寫入超限，參考管理Shard的分裂Shard和自動分裂Shard，調整LogStore的Shard數。

  • 每個Shard支援5MB/s或500次/s的資料寫入、10MB/s或100次/s的資料讀取。此限制非硬性限制，超出限制時，Log Service會儘可能提供服務，但是不保證服務品質。

  • 可以通過語句((__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 在對應Project的作業記錄LogStore中計算不同目標LogStore的未經處理資料寫入量，取其中的最大值除以5並增加20%的緩衝，得到預期的Shard數。

警示配置建議

Quota超限是較為嚴重的問題，建議建立警示監控規則。

可以每10分鐘檢查一次自監控資料中是否存在quota報錯的資訊，並對出現報錯的Project/LogStore進行對應處理，避免資料上報風險。

• 監控日誌類型：作業記錄

• 篩選條件：flusher_project_quota_error_total或flusher_shard_write_quota_error_total欄位的值大於0，這兩個欄位分別對應Project Quota超限次數和LogStore shard Quota超限次數。

• 資訊展示：展示一定時間段內出現Quota報錯的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監控，拉到最下方的Pipeline發送狀態詳情，查看發送請求重試率，Project寫入Quota超限次數和LogStore Shard寫入超限次數都為0，則表示沒有Quota相關的報錯，發送請求重試率有資料，則表示重試率較高且說明網路品質存在問題，影響了資料及時上報，導致採集延遲。

問題原因

LoongCollector內部，資料讀取、處理、發送是一條流水線，從檔案中讀取資料後，依次將資料寫入處理隊列、發送隊列。如果因網路品質不佳、資料量過大或其他原因，LoongCollector的發送能力受限，資料無法及時發送到SLS，則會導致SLS查詢資料存在延時，還會導致發送隊列資料堆積，進一步反壓處理隊列、讀取線程，使採集延遲更高。

解決方案

1. 檢查本網品質。如果商務服務器、SLS Project分別屬於中國內地和海外地區，無法使用內網，使用公網傳輸資料可能會出現網路延遲高、傳輸不穩定等問題，您還可以選擇傳輸加速傳輸資料，獲得更好的網路穩定性和效能。

2. LoongCollector可以通過調大發送並發數來加速資料的發送。可以參考設定啟動參數修改LoongCollector的啟動參數，可以著重調整發送並發數send_request_concurrency與最大發送流量max_bytes_per_sec。

警示配置建議

針對發送重試率報錯配置警示。

• 監控日誌類型：作業記錄

• 篩選條件：篩選LoongCollector採集配置的指標。

• 資訊展示：展示一定時間段內出現Quota報錯的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 "發送重試率" group by project, pipeline_name having "發送重試率">0.1 and "發送重試率"<=1 order by "發送重試率" desc limit all 

問題現象

首先需確認SLS服務端寫入未超限，同時LoongCollector發送不存在瓶頸。

• 查看採集瓶頸

  開啟CloudLens for SLS的異常監控，查看採集異常監控中的全量錯誤資訊，篩選警示類型PROCESS_QUEUE_BUSY_ALARM，如果存在該警示且數量較多，則說明存在LoongCollector的處理效能瓶頸，導致了採集延遲。在CloudLens for SLS控制台，選擇報表中心 > 採集監控，單擊異常監控頁簽，在採集異常監控地區查看全量錯誤資訊。若警示類型列出現 PROCESS_QUEUE_BUSY_ALARM，表示Tlog隊列已滿（警示詳情為 logprocess queue is full, put modify event to event queue again）。

• 查看耗時較高的採集配置

  在CloudLens for SLS的LoongCollector Pipeline監控，Pipeline處理耗時佔比可以看到耗時較高的採集配置。

問題原因

LoongCollector有著優秀的採集效能（參見日誌採集 Agent 效能大比拼——LoongCollector 效能深度測評），純原生外掛程式單線程處理速率可以超過100M/s。但是，如果採集配置中使用了擴充外掛程式、使用了複雜正則、存在多個外掛程式串聯的情況，那麼在資料量較大的時候，LoongCollector仍會達到效能瓶頸。此時，應該優先考慮將擴充外掛程式替換為SPL外掛程式或原生外掛程式來提升處理效能。如果仍不能滿足需求，則需要調整LoongCollector內部的處理線程數、cpu限制，來使LoongCollector更高效地處理資料。

解決方案

• 優先將擴充外掛程式全部替換為使用Logtail SPL解析日誌或原生外掛程式，可以大幅提升處理效能。大部分常用的擴充外掛程式，都有對應的原生外掛程式，例如正則解析、json展開等，可以參見處理外掛程式列表。

• 在儘可能將所有擴充外掛程式替換為原生外掛程式後，如果處理效能依舊不能滿足需求，LoongCollector可以通過調大cpu使用限制、增加處理線程來加速資料的處理。可以參考設定啟動參數修改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分鐘。警示的間隔為30s，如果五分鐘內報錯超過5次，說明LoongCollector存在處理能力不足導致的採集延遲問題。

• 參考語句。

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