以前做 SIEM 建置時，有時候業務帶案子進來，先說的是「這個案子很急，要先開規格」。

但再問下去，要收哪些設備、資料量有多大，卻還沒有完整資訊。
我可能會自己直接聯繫客戶，才確認真正的收集範圍，有些原本以為要處理的項目，其實不需要收。

所以談到容量，我會先想起這件事：要先知道準備收什麼，後面的數字才有依據。

這篇整理的是我過去建置與 POC 的經驗回憶，也補上這次寫文章時重新釐清的計算觀念。
文中的算例是示意，不是特定客戶的實測結果。

先把 POC 要做的事情問清楚

我以前會在 POC 會前會跟客戶確認收集細項、測試標準，以及需要開通的防火牆port或網址。

收集範圍也要問得具體一點。例如防火牆是只收外網的那台，還是其他防火牆也要納入？是否收 Mirror 流量？Agent 要不要安裝，要測試哪些項目？

Mirror 的範圍通常由客戶決定，也請客戶設定。客戶不會設定時，才由我們協助。

這也是我覺得技術人員應該參加 POC 會前會的原因。前面能把範圍說清楚，後面就比較不會花時間處理尚未確認的需求。

如果要把這些經驗整理成公版，我會放進收集設備、收集方式、測試項目、預估資料量、保存天數，以及還沒確認的事情。這是我認為值得建立的環節，技術人員比較有依據，業務也比較知道範圍該怎麼抓。

資料還沒收進來，要怎麼估？

如果客戶知道每日資料量，我會先用他們提供的數字討論。如果只有 EPS，就參考網路上的公式換算。

兩者都不知道時，我會詢問主機數量，先用當時原廠提供的「每台主機每天約 500 MB」估算。

例如，假設有 100 台主機：

100 × 500 MB ＝ 50,000 MB，約 50 GB／天。

這只是用參考值算出的起點。500 MB 指的是每天送進平台的資料量，不能當成所有環境都適用的固定值，也不能直接代表磁碟實際會增加多少。

我以前會先把接收量當作儲存占用來抓，沒有先扣掉壓縮，希望留一些餘裕。
不過，這次整理才更仔細區分：壓縮可能讓資料變小，索引、額外欄位或副本也可能占用空間，因此這樣抓並不保證一定足夠。

EPS 是筆數，還需要知道每筆多大

EPS 是 Events Per Second，也就是每秒事件數。

假設一天的平均值是 1,000 EPS：

1,000 × 86,400 秒 ＝ 86,400,000 筆。

這就是標題中的一天 8,640 萬筆事件。但知道筆數，還沒辦法直接算出容量，還要乘上平均每筆事件的大小。

每日資料量 ≈ 平均 EPS × 86,400 × 平均每筆事件大小。

以下採十進位單位換算，僅作示意：

同樣的 EPS，每筆大小差一倍，每日資料量也會差一倍。而且這裡用的是全天平均 EPS，不能把短時間的尖峰直接當成全天平均。

我以前使用的每筆事件大小，也是查網路後採用的參考值，並沒有先量測客戶的每筆 Log。客戶提供的 EPS 涵蓋哪些設備，我當時也沒有特別逐一確認，主要把它當成前期參考。

所以到了 POC 結案，我會改用實際測試期間收進來的量來說明。

POC 結案時，我會拿每日 GB 來談

報告裡，我會呈現測試期間的平均每日收集量，以及最高單日收集量，單位用 GB／天。

防火牆收了多少，其他資料來源收了多少，只要平台能顯示，我也會一起提供。

平均量可以作為一般情況的估算起點，最高量則讓客戶知道測試期間曾經收到多少。這些數字仍然只代表當時的測試範圍與期間；之後增加設備或調整收集範圍，就需要重新評估。

對我來說，這比只拿一個前期估算值放進結案報告，更有依據。但平台顯示的每日接收量，還是要跟實際磁碟占用分開看。

16 TB 可以放多久？

以前使用的原廠設備，有 16 TB 可以用來儲存資料。我自己估算時，會先抓 14.5 TB 作為界線，再看能不能保存到 90 天。

14.5 TB 是我估算時預留空間的做法，並不是在平台設定「到這裡就清除」的門檻，也不是原廠規定。

如果先用十進位單位粗算：

14,500 GB ÷ 90 天 ≈ 161 GB／天。

這代表，假設每天實際新增的儲存占用約為 161 GB，90 天就會接近 14.5 TB。若拿每日接收量代入，則仍是粗估，需要再看實際磁碟用量。

90 天是評估目標，不代表每個環境都能保存這麼久。我過去一般會先抓 30～45 天，再觀察實際資料量。只有量太大時，才會先跟客戶討論，縮短占用較多的資料類型，例如網路封包相關資料或 Syslog，可能調整到 14 天。

保存時間縮短，能回頭查詢的時間也會跟著縮短，所以這部分需要先跟客戶說清楚。

Hot Data、Warm Data、Cold Data 差在哪裡？

談保存天數時，也要說清楚資料會放在哪裡，以及需要時怎麼查。

下面用我當時對使用環境的理解來說明；尤其是 Hot Data 轉成 Warm Data 的流程，是我的使用回憶，實際設定仍要對照當時的版本與資料保存政策。

對我當時使用的設備來說，Hot Data 與 Warm Data 都能在平台上查，但仍受這台設備 16 TB 可用空間的限制。轉成 Warm Data，不代表本機就多出一份容量。

如果資料量大，又希望留得更久，就要另外規劃外部儲存。我當時接觸的是透過 S3 儲存桶保存的方式。官方文件另外也列有 Azure、NFS 等外部儲存選項，適用功能與設定要依版本確認，不能把我用過的方式當成唯一選項。Stellar Cyber：External Storage Options

Cold Data 也不是期限到了就一定自動保存好，必須先完成相應設定。官方對 Cold Storage 的說明提到，封存資料可以匯入工作中的 Data Processor，或專門用於調查的 Data Processor，再進行分析。
Stellar Cyber：Glossary－Cold Storage

存下來之後，也要試著取回來

我曾經在測試資料匯回功能時碰到一個狀況。

當時 A 機器還持續接收新資料，我在上面匯回舊資料。過程中感覺開機變慢，進到平台後，畫面沒有資料，或者一直轉圈，無法正常顯示。

後來我先重新啟動 A 機器，讓它繼續收集，再找一台同規格、還沒開始收新資料的 B 機器進行匯入，這次很快就成功了。

當時沒有釐清確切原因，所以不能直接說是同時收資料造成，也不能因為畫面沒有顯示，就認定資料已經被刪除。

但這次測試讓我注意到，規劃 Cold Data 時，除了儲存位置與容量，還要實際確認匯回後能否正常查詢。
官方支援匯回是一回事，自己使用的環境能不能順利完成，還是要測過。

容量規劃裡我最常用到的，仍然是跟客戶確認範圍，以及觀察實際收集量。
EPS 和每台主機的參考值，讓資訊不足時有個起點；POC 收進來的資料，才讓後續討論更具體。

我自己評估時都習慣抓一點空間做一個保險，所以在評估時針對空間就會大一點點