Simple Log Service：穩定性說明與使用限制

穩定項

說明

可用性

可用性較高。

如果Log Service出錯，無法讀取資料，OSS投遞任務會在內部至少重試10次。如果仍然失敗，任務執行會報錯，然後任務重啟。

穩定項

說明

並發度

按照Log ServiceShard進行分區並建立投遞執行個體，支援快速擴容。

如果Log Service源Logstore進行Shard分裂，可以在數秒以內完成投遞執行個體的擴容，加快資料匯出速度。

資料不丟失

OSS投遞任務基於消費組進行擴充，提供一致性保證。投遞完成後，才會提交offset，因此可以保證資料寫入OSS之前，offset不被提交，即保證投遞資料不丟失。

穩定項

說明

監控警示

資料投遞有完善的監控，可即時追蹤投遞任務的延遲、流量等指標。您可以根據業務需求，配置自訂警示，及時發現投遞問題（例如匯出執行個體不足、網路Quota限制等）。具體操作，請參見為OSS投遞任務（新版）設定警示。

限制項

說明

網路類型

通過阿里雲內網傳輸資料，網路穩定性和速度具有保障。

限制項

說明

授權

涉及OSS投遞操作許可權和資料存取權限。更多資訊，請參見準備許可權。

服務端加密

如果開啟了服務端加密，需要為RAM角色添加額外的許可權。更多資訊，請參見OSS配置文檔。

限制項

說明

讀流量

單個Project以及單個Shard存在最高流量限制。更多資訊，請參見資料讀寫。

如果超過最高流量限制，請分裂Shard或者申請擴容Project讀流量限制。超過限制，會導致OSS投遞任務讀取資料失敗，並在內部至少重試10次，如果仍然失敗，任務執行會報錯，然後任務重啟。

限制項

說明

並發執行個體

並發執行個體數量與Shard數量相同（包括讀寫Shard和唯讀Shard）。

投遞限制

• 通過每個Shard的投遞大小控制OSS Object大小（以未壓縮計算），取值範圍為5~256 MB。

• 每個Shard的投遞周期取值範圍為300～900秒。

• 每個並發執行個體的每次投遞，都會產生一個單獨的OSS檔案。

  重要

  建立OSS投遞任務後，每個Shard都會根據投遞大小、投遞時間決定投遞的頻率，當任一條件滿足時，即會執行一次投遞。

時間分區

OSS投遞是攢批進行，每次寫一個檔案，檔案內包括一批資料，檔案路徑由該批資料中最小的receive_time（資料到達Log Service的時間）決定。

檔案格式

資料被投遞到OSS後，支援儲存為CSV、JSON、Parquet、ORC四種檔案格式。更多資訊，請參見JSON格式、CSV格式、Parquet格式和ORC格式。

壓縮方式

支援snappy、gzip、zstd三種壓縮方式以及不壓縮。

OSS Bucket

• 只支援投遞給已存在且未開啟WORM的Bucket，且該Bucket與Log ServiceProject位於相同地區。關於WORM的更多資訊，請參見保留原則。

• 支援投遞到標準、低訪問、歸檔、冷歸檔四種儲存類型的Bucket中。投遞後，產生的OSS Object的儲存類型預設與Bucket一致。更多資訊，請參見儲存類型介紹。

• 非標準儲存的Bucket存在最低儲存時間和最小計量單位限制，請根據需求合理設定目標Bucket儲存類型。更多資訊，請參見儲存類型對比。

限制項

說明

延遲投遞

延遲投遞配置項中設定的時間不能超過當前Logstore的資料儲存時間。

建議預留一段緩衝時間，否則可能會導致資料丟失。例如Logstore的資料儲存時間為30天，則延遲投遞的時間最好不要超過25天。

限制項

說明

暫停投遞任務

投遞任務會記錄上次投遞的日誌Cursor，恢複運行時從屬記錄的Cursor開始繼續投遞。因此暫停投遞任務時存在如下機制。

• 暫停任務一段時間且沒有超過資料的儲存時間，則再運行任務時，系統從上次暫停位置繼續開始投遞，不會遺失資料。

• 暫停任務一段時間但超過了資料的儲存時間，則再運行任務時，系統從離上次暫停位置最近的一條資料開始投遞。