為什麼 SNMP 代理需要 MIB 文件？

在閱讀了 SNMP 和一些問題後，我認為將代理角色理解為設備的 SNMP 服務（如 SQL，它是儲存的 API）。

當您執行 SQL 查詢時，SQL 引擎會完成所有工作並返回結果 - 您無需了解儲存方式和儲存位置。

但是 MIB 不是實際的儲存，那麼我的代理的作用是什麼？

如果代理只像我在本教程中所遵循的那樣註冊 MIB ，那麼它根本不用作處理程序，這意味著有一個 pyhiscal 儲存，您可以在不繞過處理程序的情況下設置並到達那裡。在本教程中，您都這樣做：

netsnmp_register_int_instance("my example int variable",
                                 my_registration_oid,
                                 OID_LENGTH(my_registration_oid),
                                 &example1, NULL);

處理程序無需處理呼叫。

假設我想監視我的應用程序的待處理請求隊列，所以我想要一個代理，它會為它觸發所有對 application_pending_request 的 SNMP 請求，它會返回隊列深度。當我需要輪詢我的應用程序隊列以獲得結果時，為什麼我需要一個實際的 MIB？

您對 SNMP 的工作原理有一個基本的誤解。快速和骯髒的比較：SNMP MIB 類似於主機名。MIB 將 OID 映射到一個友好的名稱——例如

.1.3.6.1.2.1.1.1.0=> SNMPv2-MIB::sysDescr.0=> Host Description（uname 輸出）。

為了從 SNMP 伺服器（代理）檢索資訊，該資訊必須以特定的 OID 發布。

為了讓 SNMP 守護程序發布資訊，它需要（通常）兩件事：

1. 獲取該資訊的一種方式（腳本、程序等）
2. 放置該資訊的位置（OID）

（某些 SNMP 守護程序可能還需要映射 OID 的 MIB 文件）

為了檢索資訊，您必須知道 OID - 這可以是數字 OID，也可以是SNMP 客戶端上 MIB 文件中的“友好”名稱。

SNMP“瀏覽器”通常需要一個 MIB 文件，因為沒有一個 MIB 文件，它們可以呈現給您的只是一個無意義的數字列表。

所以你的問題的答案是“你不需要MIB文件，它們只是對需要與 SNMP 互動的人有幫助”。

---

以您的範例（報告隊列長度）為例，這聽起來像是您喜歡使用的教程net-snmp（UCD-SNMP）。

net-snmp包括用於這類事情的內置工具——通讀手冊頁和範例配置文件（特別注意exec執行外部腳本的指令：通常你會執行一個列印隊列長度的腳本，並在您的監控軟體/SNMP 客戶端）

引用自：https://serverfault.com/questions/422027