Cacti整合SNMP Trap　設備告警自訂分類不漏接

安裝之後，再點選綠色箭頭圖示，將其啟用，如圖8所示。

▲圖8 執行CaMM。

緊接著，點選功能列中的camm標籤，進行後續設定，如圖9所示。

▲圖9 點選camm標籤。

此時可能會出現CSRF錯誤訊息（CSRF指的是Cross-site Request Forgery，之前Cacti有CSRF的Security Issue，因此有新增相關檢查機制）。在此例中，僅在內部使用，因此修改「/usr/share/cacti/site/include/csrf/csrf-magic.php」檔案，找到「$GLOBALS['csrf']['defer'] = false;」這一行將之修改為true即可。錯誤訊息如圖10所示（此步驟在RHEL 6.3無須執行）。

▲圖10 出現「CSRF check failed」的錯誤訊息。

點選camm時，若無錯誤訊息，代表可正常運作，接著要設定CaMM存取snmptrap log的方式。點選Console，找到Configuration裡的Settings，再點選camm，接著找到Use SNMPTT，將之修改為true，如圖11所示。

▲圖11 設定CaMM使用SNMPTT進行資料解析。

接著要讓CaMM能定時更新資料庫，在「/etc/cron.d/cacti」檔案內新增以下指令，讓CaMM每分鐘去讀取「/var/log/snmptt」裡的檔案，並將之匯入資料庫內：

最後再回到Cacti，並點選功能列中的camm標籤，可看到SNMP Traps中已有設備IP及SNMP Trap的訊息，如圖12所示。

▲圖12 CaMM已可讀取SNMP Trap訊息。

再點選Unknown Traps，在Format Line欄位中可看到許多無法辨識的SNMP Trap，如圖13所示。

▲圖13 出現無法辨識的SNMP Trap。

簡單來說，這些無法辨識的SNMP Traps都是人類無法判讀的OID，OID由數字組成，因此無法讓管理員和使用者輕易看出其代表的含意，必須結合snmptt，將這些難以判讀的OID轉換為可識別的MIB值。

使用SNMPTT轉譯OID

如前所述，許多Unknown Trap無法判讀，因此要透過工具程式將之轉換為MIB。在此例中，將使用snmptt中的snmpttconvertmib進行轉譯的動作，它的運作方式是將MIB檔讀入後，把轉換時須對應的格式記錄在snmptt.conf檔案內，之後當新的Trap進來時，就可以比對該格式找出對應的MIB名稱，並寫入snmptt的Log檔中。

針對這些Unknown Traps按兩下滑鼠左鍵，可以看到更詳細的說明，如圖14所示。一般而言，需要的會是Trapoid和Enterprise這兩個欄位的數值。

▲圖14 檢視Unknown Trap詳細資訊。

圖14中的Trapoid是.1.3.6.1.4.1.9.0.1，可以將其作為關鍵字進行搜尋，將會發現它屬於CISCO-GENERAL-TRAPS.my這個檔案，將它下載之後，執行下列指令（假設已將此MIS檔下載至「/etc/snmp」目錄中）：

先將它輸出至test.conf這個檔案內，目的是要查看有無錯誤訊息，在此可以看出在執行過程中缺少了許多Module，如圖15所示。

▲圖15 執行snmpttcovertmib時出現錯誤訊息。

有許多網站都可以透過OID找到相關MIB檔的內容，有些還可以下載該MIB檔。一般而言，檔案裡會有一些關鍵字，例如TRAP-TYPE（針對SNMP第一版）、NOTIFICATION-TYPE（針對SNMP第二版），如果檔案中有這些關鍵字，可大致判定是這裡所需的檔案。

這些找尋不到Module的訊息，是因為在預設目錄中找不到對應的MIB檔之故，可以使用下列指令將缺少的MIB檔補齊：

這些指令可以補齊符合SNMP協定並且已公開的MIB檔。但對於各家網路設備商的MIB檔，則必須手動補齊。

接著再執行一次以下指令，查看是否還有缺少的MIB檔：

必須設法將缺少的MIB下載並存放至「/usr/share/snmp/mibs」，並重複執行上述指令，直至無錯誤訊息。在此例中，缺少的都是Cisco OLD開頭的檔案，可以透過下列指令一次補齊：