Share Notes

chundev

View the Project on GitHub latteouka/share-notes

Carbon Black EDR 中控磁碟空間管理實戰指南

日期：2026-04-14 環境：Carbon Black EDR 6.x+（建議 7.8.1+）/ CentOS / RHEL

TL;DR

CB EDR Server 的磁碟空間會被 Solr cbevents（Process Search 事件資料）持續吃滿。短期靠清理 JVM heap dump 和舊 log 緩解；根本解法是調整 cb.conf 的資料保留參數（MaxEventStoreDays、MaxEventStoreSizeInPercent）；長期應搭配 Event Forwarder 把事件卸載到 SIEM 做長期保留。

背景

EDR（Endpoint Detection and Response）中控伺服器會持續接收所有端點 sensor 回報的 process 執行、檔案修改、網路連線等事件，儲存在 Solr 搜尋引擎的 cbevents core 中，供管理員做 Process Search 和告警分析。隨著端點數量增加和時間推移，事件資料會持續增長，最終導致磁碟爆滿、服務無法啟動。

問題症狀

# 磁碟使用率超過 90%
df -h /var/cb/data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       500G  475G   25G  95% /var/cb/data

# 或者 Solr 服務無法啟動
systemctl status cb-enterprise
# → cb-solr failed to start

其他常見症狀：

快速診斷：空間被誰吃掉

# 檢查各目錄大小
du -sh /var/cb/data/solr5/cbevents/    # ← 通常最大宗
du -sh /var/cb/data/solr*/cbmodules/   # binary metadata（不可刪）
du -sh /var/cb/data/modulestore/       # binary 檔案
du -sh /var/cb/data/pgsql/             # PostgreSQL
du -sh /var/log/cb/                    # 各服務 log

# 列出所有 Solr core 及大小
ls -lhS /var/cb/data/solr5/cbevents/
路徑 內容 可否清理
/var/cb/data/solr5/cbevents/ 事件資料（Process Search） ✅ 可 purge 舊 core
/var/cb/data/solr*/cbmodules/ Binary metadata ❌ 絕對不可刪
/var/cb/data/modulestore/ Binary 檔案 ⚠️ 可刪 60 天以上的 .zip
/var/cb/data/pgsql/ 管理資料庫 ⚠️ 需 vacuum，不可直接刪
/var/log/cb/ 各服務 log ✅ 可刪舊 log

解法一：立即緩解 — 安全清理磁碟

以下指令皆出自官方 KB（KB 285712）。

低風險：直接清理

# 1. JVM heap dump（隱形炸彈，單檔可達數 GB）
find /var/log/cb -type f -iname "*.hprof*" -delete

# 2. 超過 7 天的舊 log
find /var/log/cb/ -mindepth 1 -type f -mtime +7 -delete

# 3. 舊的 support diagnostics
find / -type f -iname "cbdiag_[0-9]_*.zip" -delete

# 4. 已刪除但仍佔空間的檔案（open file descriptor）
for i in $(find /proc/*/fd -ls 2>/dev/null | awk '/deleted/ {print $11}'); do
  truncate -s 0 $i
done

中風險：審查後清理

# Module Store 超過 60 天的 binary（刪後 binary 下載會 404）
find /var/cb/data/modulestore/ -type f -mtime +60 -iname "*.zip*" -delete

解法二：手動 Purge 最舊的 Solr Core

⚠️ 不可逆 — 刪除後對應時段的 Process Search 和 Alerts 將永久消失。

出自官方 KB（KB 290576）。

# Step 1: 列出所有 core，找出最舊的
curl "http://127.0.0.1:8080/solr/admin/cores?action=STATUS&wt=json&indexInfo=false&indent=true" \
  | grep name

# Step 2: Unload 最舊的 core
curl "http://localhost:8080/solr/admin/cores?action=UNLOAD&core=<core_name>"

# Step 3: 驗證 unload 成功（應無輸出）
curl "http://localhost:8080/solr/admin/cores?action=STATUS&indexInfo=true&indent=true&wt=json" \
  | grep <core_name>

# Step 4: 刪除檔案
rm -rf /var/cb/data/solr5/cbevents/<core_name>

cbevents 預設以 3 天為一個 rollover core。

解法三：調整 cb.conf 資料保留策略

這是根本解法。設定檔位於 /etc/cb/cb.conf。

出自官方 KB（KB 291107）。

核心參數

參數 預設值 說明
MaxEventStoreDays 30 超過此天數，最舊 core 自動移除
MaxEventStoreSizeInPercent 90 磁碟使用率安全閥
SolrTimePartitioningMinutes 8640 (6天) 每個 partition 接收寫入的時間長度
SolrTimePartitioningActivePartitions 10 保持活躍的 partition 數量
SolrTimePartitioningMaxSizeMB 500000 單一 core 最大大小
AlwaysDeleteColdPartitions — True=直接刪除；False=保留為 cold storage

自動 Purge 機制

伺服器每 15 分鐘檢查，任一條件觸發即移除最舊 core：

  1. 資料超過 MaxEventStoreDays
  2. 磁碟使用率超過 MaxEventStoreSizeInPercent
  3. Active partition 數超過 SolrTimePartitioningActivePartitions

預設結構：10 個 core × 每個 3 天 = 30 天保留。

範例：縮短至 14 天保留

# /etc/cb/cb.conf
MaxEventStoreDays=14
MaxEventStoreSizeInPercent=85
SolrTimePartitioningMinutes=8640
SolrTimePartitioningActivePartitions=3

修改後重啟：

sudo /usr/share/cb/cbservice cb-enterprise restart

⚠️ 常見地雷：SolrTimePartitioningMaxSizeMB

出自官方 KB（KB 287767）。

症狀：搜尋超過 3 天前的事件回 404，/var/cb/data/solr5/cbevents/ 下同一天出現大量帶時間戳的 shard 目錄。

根因：SolrTimePartitioningMaxSizeMB 被設成 5000（5 GB），而非正確的 500000（500 GB）。core 很快就達到上限被 rollover，導致資料保留極短且碎片化。

修復：改回 SolrTimePartitioningMaxSizeMB=500000 並重啟。

解法四：擴充磁碟（加碟）

出自官方 KB（KB 287632）。

# 1. 掛載新磁碟
mount /dev/sdb1 /cbdata

# 2. 建立 symlink（名稱必須以 cbevents 開頭、以數字結尾）
ln -s /cbdata /var/cb/data/solr/cbevents2

# 3. 設定權限
chown cb:cb /var/cb/data/solr/cbevents2
chmod 755 /var/cb/data/solr/cbevents2

# 4. 驗證
ls -latr /var/cb/data/solr

磁碟需求：SSD on RAID 5，16,000 IOPS (250 MiB/s)。2 TB 以上需至少五顆 SAS SSD。

❌ 不支援 NAS 或 NFS。

解法五：Event Forwarder → SIEM 長期保留

官方推薦的架構：EDR Server 只保留近期資料，長期保留交給 SIEM。

EDR Server ──Event Forwarder──→ SIEM（Splunk / QRadar / ELK）
    │                                │
    └─ 保留 14-30 天（即時搜尋）      └─ 保留 90-365 天（合規/調查）

啟用方式

# /etc/cb/cb.conf
EventForwarderEnabled=True
EnableRawSensorDataBroadcast=True

設定檔：/etc/cb/integrations/event-forwarder/cb-event-forwarder.conf 驗證：/usr/share/cb/integrations/event-forwarder/cb-event-forwarder -check

支援輸出到：檔案系統、UDP/TCP 網路服務、AWS S3。格式支援 JSON 和 LEEF（7.9.0+，QRadar 相容）。

解法六：從源頭減少事件量

在 EDR Console > Sensors > Sensor Groups 中，可關閉不必要的事件類型：

對特別 noisy 的 process（如防毒軟體、備份軟體）設定 event filter 可顯著減少事件量。

容量估算

事件總量 = 端點數 × 每端點每日 Process Documents × Document 大小 × 保留天數

每端點每日 Process Document 數

OS 中位數 75th 90th
Windows 7,800 10,750 16,000
macOS 12,000 18,750 25,500
Linux 59,750 125,000 195,750

Process Document 大小中位數：3,600 bytes。

估算範例

學到的事

參考資料