IT @ Jason Tools v3.68.13

LibreNMS 容量計算機

估算 RRD 容量與保存跨度，可匯入實測結果校正

設備清單

0

點一張卡片就加進清單。介面數與感測器數量都由範本帶入：感測器那幾欄是樣本中位數（虛線框），知道實際數量的話直接改成你自己的。

載入範例：

服務檢查（Services）

LibreNMS 的服務檢查是你自己加的，預設一個都沒有。加了才填：每一個檢查各佔一個 RRD 檔。

檢查類型 幾個 每個 DS 數 說明

DS 數是在一座實際運作的 LibreNMS 上逐檔跑 rrdtool info 量到的（227 個服務檢查）。想用自己環境的值就直接改那一欄。

匯入實測盤點（最準的做法）

上面那些欄位都是估算。如果你手上就有一座 LibreNMS，在它上面跑一支唯讀腳本盤點 rrd 目錄，把結果貼進來：那是事實，不是估算。腳本只讀檔案大小，不連網路、不改任何東西。

1. 把腳本放到 LibreNMS 主機上，跑一次（唯讀） 
python3 collect-librenms-capacity.py \
  --rrd-dir /opt/librenms/rrd \
  --output /tmp/librenms-inventory.json \
  --mode sizes
應用程式（app-*）

LibreNMS 的應用程式監控要自己裝 agent 或 SNMP extend，預設一個都沒有。裝了才填：一台上的一個應用程式會產生好幾個 RRD 檔。

應用程式 幾台有裝 每台 RRD 數 每檔 DS 數 依據

這一塊只能算粗估：同一個應用程式底下的子項目，每個檔案的 DS 數不一定一樣，而本站只用一個代表值去乘。要準就把自己環境的數字填進來。

規劃條件

預設是 5 分鐘輪詢、原始碼快照的 RRA 方案、保留 20%。三個 RRA 方案的來源與可信度不一樣，展開就看得到。

%

保留空間是除法：需求 = 預期 ÷（1 − 保留比例）。80 GiB 配 20% 保留要 100 GiB，不是 96 GiB。

GiB

擴充既有環境時填這一格。它是量到的事實，只會被加上去，不會再乘一次現有設備。

排程與 Fast Ping

Fast Ping 只檢查上下線，不會把 SNMP 改成一分鐘，也不量測封包遺失或延遲。兩條排程各算各的。

秒
台

設備清單是空的時候才是未知。本站不拿介面數或 RRD 目錄數代入：那是別的量，會算出一個看起來很精確的錯數字。

條件已變更，請重新計算
貼上實測的 RRA 設定

把 rrdtool info 或 PHP 設定裡的 RRA 貼進來，就用你環境裡的實際結構算。只解析字串，不執行 PHP。

匯出規劃

匯出的內容一定含模型版本、來源出處、估算或實測的標示，以及沒有納入計算的項目。

模型依據與邊界
保存跨度不可以相加 每一層 RRA 是不同解析度的循環陣列，時間互相重疊。把 7 天、30 天、120 天、1440 天加起來會得到一個不存在的數字；1440 天那一層存的是「日」層級，不是四年的五分鐘明細。
提高頻率不等於容量變大 只改 step、資料筆數不動的話，檔案大小完全一樣，變的是每一層只涵蓋到原本的五分之一時間。要維持保存天數才需要加筆數：那時候容量才會變大。兩件事分開選，這一頁不會把它們混在一起講。
沒量到的東西不會變成 0 資料庫、RRD 標頭、系統效能指標、PoE、備份與快照都不在這個估算裡，畫面上會列出來。rrdcached 是合併寫入不是壓縮，勾了它也不會讓 RRD 變小。
來源是master 分支的快照（分支會一直往前走） 介面的 15 個 DS 與內建的 RRA 方案取自原始碼快照，不是某一個發行版本的保證。你環境裡的實際檔案優先於任何範本：貼上實測的 RRA 就會用你的。
這一版沒有做的 每層自訂解析度（引擎算得出來，但畫面上還沒有入口）、heartbeat 與 xff 的呈現、Services 排程、圖形匯出、resize 指令與逐 volume 的備份與轉換空間。沒有做的就寫出來，不會在畫面上假裝已經算過。