基礎設施估算

保留 30 天日誌需要多少空間？

使用工具

日誌磁碟快滿，要估三十天容量。每行很短忽略事件成長，只看未壓縮量也可能高估。應拆事件數、單筆位元組、保留天數、壓縮後比例和總儲存副本。

此介面區間為一天，無壓縮、總一份

events per day: 100000
bytes per event: 500
days: 30
compression ratio: 1
stored copies: 1

結果 1,500,000,000byte，每日五千萬乘三十，為 1.5GB 或約 1.397GiB。不要把 GiB 數字當 GB。

目前公開設定中每區間事件數按每日。每秒百筆先換 100×86,400=8,640,000 筆/日，直接填百就誤成每日百筆。先統一統計間隔。

改 0.5 得 750,000,000byte，0.25 得 375,000,000。欄位為壓後/壓前倍率，不是填 50 的百分比。1 無削減，減少 25% 應剩 0.75 非 0.25。

比例依賴內容方式，重複紀錄與含已壓縮加密資料不應假定同率。無代表量測就比較 1、0.5 等情境，別稱已測。工具不上傳日誌測壓縮。

0.5 壓縮、總兩份即 1,500,000,000byte。主一份加複一份填二；若服務 replica=1 僅指額外一份，直接抄一會少算。

先定是否含備份、異地。倍率假設同大小，保留或壓縮不同的目的地宜分別算再合。份數增加不證明備份可復原。

若儲存時間、層級、請求 ID、JSON 鍵分隔符，均應含平均大小。可見字元不等 UTF-8 位元組，中文日文表情尤其如此，可用字元位元組計數核對短例。

一行不總等一事件，堆疊多行或收集器合併。計數單位與平均尺寸單位須相同，用樣本總位元組除對應事件數可明確平均基準。

同條件九十日 4,500,000,000byte，固定每日模型保留三倍容量三倍。若事件成長需改日假設，新功能日誌層級也可改單筆大小。

故障突增使長期平均不能說明峰值，應分正常成長情境並看實儲存。工具不預測峰值也不讀取歷史分析趨勢。

索引、中繼資料、工作空間、檔案系統餘量不自動含在基礎本文估計。產品不同，不能憑空統一倍率稱量測，應參考官方與代表量測另記附加量。

到期與實際釋放空間不一定同步，穩態模型不模擬刪除延遲或切換峰值。別直接把結果當磁碟上限，應明確包含排除範圍。

每天十萬與每秒十萬完全不同。此畫面按日，持續每秒 100 件應乘 86400，得日 864 萬。但把某一秒峰值延伸全天是假設持續峰值。應區分平均、繁忙日和故障日，計算不會把假設變成實測。

故障不僅增加頻率，堆疊也可能使單筆變長。件數和平均大小都翻倍會變四倍，而非僅兩倍。記錄改變了哪些變數才能解釋成長。畫面不自動保存情境歷史，需要比較時應主動保留條件與結果。

保留期還應考慮後續調查需要。刪關鍵欄位可能無法追蹤事件，容量足夠也不證明應保存不必要秘密或本文。工具只呈現件數、大小、天數的容量後果，不決定蒐集策略、權限或保留義務。