在Cacti建立設備相關繪圖非常便利，但手動作業有點麻煩，且當大批設備有繪求需求時，將會應接不暇。本文嘗試以SNMP Query Index來建立設備記憶體使用量的繪圖，不必逐一建立，可減輕網管人員的工作負擔。
在Cacti上建立設備相關繪圖相當便利，除了設備內建的範例外，亦可在網路上找到別人分享的範例並匯入使用。此外，可以手動建立RRD檔，再撰寫程式使其定期更新，最後在Cacti一併繪圖。
並且，能夠針對個別需求，使用Shell Script或SNMP Query的方式建立其Data Template，再加入同一張圖中。針對特殊需求，也能夠將不同資料來源在同一張圖呈現其結果。
但人力有限，手動的作業會耗費大量時間。若大批設備有繪求需求，且其數量或種類有所不同，例如當有多台Juniper的設備想要針對每台設備的卡板溫度繪圖，但每台設備的卡板數量不同，就無法使用已寫好的程式來處理每一種特殊情形。
為此，本文將介紹如何使用Cacti的SNMP Query Index方式，在SNMP Index為連續數值的狀況下抓取設備的資料進行繪圖，以克服這一類的問題。
了解相關概念
若要透過SNMP Query Index抓取連續資料，必須了解其作業方式，在此採用Interface - Traffic舉例來做說明。
Interface - Traffic指的是介面的流量，在建立流量圖時，Cacti會查詢有哪些網路介面，接著提供其Index、Status、Description、Name、Alias、Type、Speed、High Speed、Hardware Address及IP Address以茲識別，如圖1所示，最後提供勾選的欄位。若勾選後再送出，就進行繪圖。
 |
| ▲圖1 Cacti查詢現有的網路介面。 |
在這個例子中，可以發現Index以降的欄位，都是Cacti自己抓到的，不需要手動輸入。而繪圖時所需的數值（流量），則是Cacti在查詢設備時得到的輸出，由於是設備自行輸出的，因此也不須做任何的處理。
再觀察一下Index的部分，可以看出其為一連續的數字。換言之，若設備可透過SNMP取得連續的Index、Description（或者Name及其他欄位，但至少要有一個可供識別的欄位），則可使用SNMP Query Index的方式進行批次的作業，減少人力的負擔。
因此可以得到一個結論，在使用SNMP Index大量繪圖時，需要的資料有Index、輸入及輸出。Index部分作為設備索引之用，Cacti亦需要先定義其輸入和輸出，輸入部分就是在建檔時可以看到的相關註解或說明，而輸出部分則是實際取出數值用來繪圖的資料。
因此，在Cacti中必定有儲存的機制，並且能使用該機制查詢輸入與輸出資料的功能才能完成上述作業。目前Cacti採取的是查詢XML檔案的方式，在這個XML檔案中，需要記錄輸入和輸出的相關欄位，以供日後查詢時使用。
以Cisco Memory使用量進行實作
接著，使用Cisco Memory進行一個簡單的實作。在Cacti中，預設未提供Cisco Memory使用量相關的Template。在此次的實作中，要幫它增加抓取Processor與I/O記憶體使用量的功能。
在此要特別說明的是，由於Cisco Router本來就有提供此查詢功能（可使用CLI進行查詢），因此推測Cisco Router應該有提供針對SNMP查詢時回覆這些數值的功能，才選定這個功能做測試。如果有其他的需求，必須先查詢相關的說明，確認可支援再進行實作。
在此對OID和MIB做簡易的說明，OID就像是IP，是給機器識別的獨立位址，而MIB就像是Domain Name，讓人可以一眼就猜出其功能或者可理解其意義。
當NMP Client則使用SNMP協定查詢設備的OID或MIB以得到某數值，而SNMP Client取得的數值則是由設備定期抓取，並存放在記憶體內。若是SNMP Client來查詢時，則透過SNMP Daemon去記憶體中抓取其對應值並回應之。
Cisco Memory Pool MIB的說明與OID的對照，可參考連結「http://www.oidview.com/mibs/9/CISCO-MEMORY-POOL-MIB.html」。在此僅節錄有使用的部分，如圖2所示。
 |
| ▲圖2 Cisco Memory Pool MIB說明與OID對照。 |
接著，以實作的方式來驗證這些資料究竟是否正確。在此先假設已備妥執行SNMP Client的環境，若執行時出現「Cannot adopt OID in XXX-MIB」的錯誤訊息，以Ubuntu為例，可執行以下指令修正相關問題：