Zabbix 3.0監控網路設備有哪些
- 王林轉載
- 2023-06-04 08:44:502072瀏覽
SNMP簡介
1 SNMP 概述
SNMP發展至今以成為應用最廣的網路管理協議，目前應用的版本主要有SNMP v1、SNMP v2c和SNMP v3。各版本之間主要的差異表現在資訊的定義、通訊協定的操作和安全機制上，同時也出現了SNMP應用的兩個擴展遠端網路監控RMON（Remote Network Monitoring）和RMON2。
從實體層的角度來看，使用SNMP對網路進行管理應該包含：網路管理站（NMS）、代理程式（Agent）、代理伺服器（proxy）。在網路管理中，至少需要一個NMS來發出指令和接收通知訊息。 Agent能夠回應管理節點的請求，也能夠主動產生通知訊息，在網路管理中可以有一個或多個。 Proxy在不同網路間或不同版本間轉送SNMP請求和通知訊息。
從協定層的角度來看，SNMP包含：SMI（Structure of Management Information，管理資訊結構）和MIB（Management InformationBase，管理資訊庫）。 SMI是ASN.1（Abstract SyntaxNotation one，抽象語法標記）的子集，SMI規定了SNMP中可使用ASN.1中的元素、自訂的資料型別和巨集等，由這些元素、資料型別、巨集及其他相關的語法可定義SNMP中的MIB。 MIB是Agent中可被管理物件的抽象描述。在SNMP中，MIB是以樹狀結構組織進行檢視的，樹中的每個節點稱為OID（Object identifier，物件標識），以類似於網址域名的方式組織，以證書表示各個節點，如1.3. 6.4。
SNMP是屬於TCP/IP協定堆疊的應用層協議，類似HTTP、FTP協定。只是SNMP傳輸層使用的是UDP協定。
在SNMP v1中，提供了一種從NMS到Agent的簡單的認證模式----Community，NMS向Agent發送請求時需要提供Community字串，Agent收到字串後需檢查是否和本地的一致。因使用明文傳遞Community，有明顯的安全隱憂。
在1996年IETF發布了SNMP v2c（Community-BasedSNMP v2），該版本在v1的基礎上定義了管理站之間的通信，所有支援分散式網路管理，但是在安全機制方面還是和v1的一樣。
在1998年IETF發布了SNMP v3，在SNMP v2的基礎上擴展了安全性（基於使用者的安全模型及視圖的存取控制模型）和管理機制。在安全性上，v3版本在協定封包中加入了安全性參數，允許對封包進行加密傳輸和強制性驗證，是一種安全的協定。 SNMP v3中使用模組化的想法定義了協定中的各個組成模組，完善了協定的體系結構，最重要的是和SNMP v1和SNMP v2保持相容。
2 SNMP的功能
SNMP中agent主要負責訊息的上傳，NMS除了具有SNMP協定的等級功能外，還具有對已傳送和接收的訊息進行日誌記錄、通知訊息的記錄和管理及配置功能，並能提供圖形化的配置和管理介面。
為了實現這些功能，SNMP中包含一系列的操作指令，主要有：
#讀取指令：Get系列指令，NMS像Agent發出請求收集管理資訊.
設定指令：Set指令，NMs將封包中所攜帶的資料寫入Agent。
警告功能：Trap系列，Agent主動向NMS發送警告/事件訊息的訊息。
圖 13-1
#1、 Get 操作
Get操作是NMS主動發起的操作。在發出的封包中除了攜帶Get請求標誌外，還包括了待請求的OID名稱和值對，並以這種名稱和值對的綁定形式實現管理對象資訊的傳遞。當然，Get操作中OID對應的值為NILL。
2、 Get-Next操作
Get-Next操作和Get功能類似，不同的是查詢的資訊並不是封包中綁定的OID資訊而是該物件的下一個OID的資訊（如果下一個OID資訊是可讀的）。比方說NMS想要收集Agent端的sysName的下一個節點sysLocation的訊息，在請求封包中是sysName.0，而回傳的封包中綁定的是sysLocation.0和值。
3、 Get-Bulk操作
實際上是多個Get-Next作業的集合，這是在SNMP v2中新加入的操作方法。
4、Set操作
Set操作可以對具有可寫入權限的OID進行參數設置，以實現對設備的參數管理、配置和控制等。與Get操作綁定變數不同的是Set中需要綁定對應OID設定的值。
5、Get-Response
Get-Response是對NMS的Get和Set兩類指令的回應，根據指令的不同和指令中的參數不同，對應的回傳變數綁定的訊息及錯誤狀態資訊（表明命令執行成功或失敗）等。
6、Trap系列
Trap是Agent主動向NMS報告重要事件的機制，對於這種報告，NMS無須對Agent進行回應。 Trap訊息中的內容顯示了什麼時間在什麼地點發生了什麼事情。
3 SMI和MIB
1、SMI
SMI是SNMP中以ASN.1語法定義的資訊模組，是ASN.1中的子集。這些模組包含了許多特定於SNMP的巨集、自訂資料類型和規則等。定義這些巨集、資料型態、規則的主要目的有3個：一是表示和定義SNMP應用中特有的資料型態；二是簡化管理對象的定義方法；三是分配SNMP中的對象標識符空間及管理對象編碼的方法。 SNMP正是基於這些定義在RFC文件中的資訊模組，實現了協議的標準化，使得各個組織、企業和個人在定義管理對象時保持一致性。
在SNMP中，實際上定義了兩個版本的SMI，分別是RFC 1151中定義的SMI v1和RFC 2578中定義的SMI v2。 SMI v1中只是簡單的定義了幾種資料型態、規則說明、OBJECT-TYPE巨集等，在SMI v2中則以模組化的定義方式，將所有的相關內容都完整的組織起來了。
SMI v1中定義的基礎資料型別有：
INTEGER：其實是32位元的整數。
OCTET STRING：0個或多個8位元組），即可以表示文字字符，也可以表示物理位址。取值範圍0 到65535。
OBJECT IDENTIFIER：以點分十進位表示的OID。
NULL：只在SMI v1中有定義，在SMI v2中已經不再使用。
SEQUENCE：定義清單。
SEQUENCE OF：定義表格。
在SMI v2中對以上的資料型別進一步明確了範圍上的限制和更新，另外也引進了BITS型別。
SMI v1中自訂資料類型包含：
NetworkAddress（網路位址），可以是除Internet外的網路位址族，
#NetworkAddress ：：= CHOICE {Internet IPAddress }
#32位元的IP位址，用網路位元組順序表示
IPAddress ：：= [APPLICATION 0 ] IMPLICIT OCTET STRING （SIZE （4））
Counter類型值單向增長，達到最大後，回歸到0重新開始計數（Agent重啟後也會重設為0），主要用於統計介面發送和接收的位元組數
Counter ：：= [APPLICATION 1 ] IMPLICIT INTEGER（0 .. 4294967295）
Gauge類型值可增可減，達到最大值時保持在最大值，如路由器中介面的速率可以用該類型表示
Gauge ：：= [ APPLICATION 2 ]IMPLICIT INTEGER（0 .. 4294967295）
TimeTicks使用0.01秒為單位進行計時，表示兩個時間點之間的時間間隔。要求在描述資訊中說明其計時基準。
TimeTicks ：：= [ APPLICATION 3 ] IMPLICIT INTEGER（0 .. 4294967295）
#Opaque將其他ASN.1型別編碼後的值兩次封裝。為了向後相容，SMIv2中也定義了該類型，不建議使用。
Opaque ：：= [APPLICATION 4 ] IMPLICIT OCTET STRING
SMI v2中相對SMI v1有變化的自訂資料類型有：
Gauge32 和Gauge其實是一致的。 Gauge32 and Unsigned32 share the same application type tag, therefore their encoding is essentially identical.。
Gauge32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 4294967295）
Unsigned32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（#Unsigned32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 429496767）
Counter64是更大範圍的Counter，有64為：2^64-1（0 ..18446744073709551615）。只有在計數器不足1小時就歸0時，才會在標準MIB模組中使用Counter32。
Counter64 ：：= [ APPLICATION6 ] IMPLICIT INTEGER（0 ..18446744073709551615）
SMI v2中依然保留了IPAddress類型，且含有沒有變化。不過不適用於IPv6的128為位址。對Counter32更進一步的說明：計數的值只有在有初始值和有記錄變化時，目前的計數值才有明確的意義。
從MIB的角度來看，SMI是直接指導MIB定義的章程，定義了MIB的資料類型和語法，為MIB中的管理物件分配OID空間。
2、MIB
MIB是管理資訊的集合，是根據業務的需求或網路管理標準的要求，依照約定的組織規則、定義語法編寫的結構化的文字檔案。
每個管理資訊庫（MIB）中的管理物件均需明確描述其所有屬性，包括名稱、描述和資料類型等資訊。通訊雙方可以透過物件的唯一識別碼（OID）來識別這些屬性的內容。也就是說，MIB是NMS和Agent相互溝通的橋樑，只有Agent實現了此MIB，且NMS認識該MIB，兩者才能正確配合實現對應的管理功能。將MIB導入NMS後，NMS才能知道待管理物件所有的細節。如果在代理程式中實作了MIB中定義的管理對象，則表示該代理程式支援該MIB。
一個Agent可以實現多個MIB，每個MIB包含的管理物件可多可少，沒有明確的要求。 MIB主要由兩部分組成，一部分是國際標準化組織定義的標準的管理對象，包括MIB-I（RFC1156）和MIB-II（RFC1213）。所有已接入網路的設備均支援常規和基礎的管理對象，這些對像在標準MIB中進行了定義。另一部分是各大廠商、組織或私人自訂的私有MIB，這些私有MIB是廠商根據裝置管理的需求，將標準MIB中沒有的需要管理的物件進行自訂。節點 enterprises（1.3.6.1.4.1）下定義了私有MIB。
標準MIB中將管理物件分為10個群組，也就是MIB樹中的10個分支，它們是：System、Interfaces、AT（Address Translation，狀態為deprecated，表示下一版本不再使用）、IP、ICMP、TCP、UDP、EGP、Transmission、SNMP，它們的父節點是1.3.6.1.2.1（mib-2）。這10個群組中的管理對象時網路管理中最重要的部分之一。
System群組：主要用來描述Agent系統層面資訊。包括sysName、sysLocation、sysDescr、sysServices、sysUpTime、sysContact、sysObjectID等。這些OID提供了設備的名稱、位置、在線時間等信息，在網絡管理中非常重要，在實際環境中這些信息不能得到及時的更新，容易被忽略。
Interfaces群組：此群組用於提供網路設備所有的介面資訊。包括介面類型、介面描述、介面速率、介面狀態等。
AT群組：即位址轉換群組。此組時間為一個表對象，實現網路位址到實體位址的映射對應關係。遍歷該表就能得到IP位址與MAC位址之間的對應關係。
IP群組：定義了IP層相關資訊的管理物件。這些物件包括IP封包、錯誤訊息、位址資訊、路由資訊和位址映射資訊。
ICMP群組：此群組定義了26個描述各種ICMP訊息收發的標量對象，它們都是Counter型別。這些物件可以很容易地提供封包收發速率和ICMP各類封包類型（請求、回應）的速率。
TCP群組：此群組主要包括：用於配置管理的TCP重傳策略、重傳最長、最短時間的對象，用於效能管理的連結被拒絕的請求數、TCP通訊狀態間轉移記錄數、重傳總數、接收錯誤總數等對象，可能用於計費管理的收發TCP資料段技術對象，可能用於安全管理的tcpConnTable表對象，透過分析該表記錄到的遠端IP、連接埠號碼、狀態等訊息，追蹤來自遠端可疑的連結。
UDP群組：此群組包括可用於效能和計費管理的接收和傳送UDP封包的計數對象、錯誤封包數對象及連接埠及IP位址等相關資訊的對象。
EGP（Exterior Gateway Protocol，外部網關協定）群組：EGP是用於在自治系統間（鄰居間）交換路由資訊的協定。此群組包括使用者失效管理的鄰居運作狀態等各類別資訊的egpNeighTable表物件、使用者設定管理的本地自治系統的域號、用於效能管理的進入和離開本地實體EGP訊息的速率及錯誤計數物件。
Transmission群組：此群組的角色在於根據不同的傳輸媒介提供對應的管理資訊。此組較為特殊，MIB-II中並沒有在該分支下定義明確的管理對象，而是當某種傳輸媒介需要接受管理時才把對應的接口類型加入到改組中。
SNMP群組：此群組定義了詳細描述SNMP相關的物件。如可用於故障管理的不同類型錯誤數的統計、可用於設定管理的Trap認證失敗是否產生訊息的物件、可用於效能管理的發送和接收的各種訊息數的統計。
4 OID樹
在SNMP中所有的管理物件都以樹狀結構來組織，管理物件則體現為樹中的節點，而這棵樹則由國際上的相關標準化組織來維護和管理。透過這種結構化和層次化的組織方式，非常便於物件的管理和擴充。這種管理和擴充體現在節點的分配上。
企業、組織或個人均有權向國際組織申請節點，以成為樹狀結構中的一個分支。當成功申請到一個節點後，就可以在該分支下自由的分配其他節點，以滿足其監控或管理業務的需要。
OID數，也稱為MIB數。 MIB實際上是由OID組成的ASN.1的模組，在現實中體現為樹狀結構。 Internet中有很多標準的MIB，SNMP中定義了MIB-I、MIB-II等，還包含企業、組織、個人定義的MIB。如下圖所示。
在OID樹中，只有最頂層的root節點不帶有具體的數字編號，可以看作是一個虛擬的節點，其他的節點都是具有在同一層的唯一編號，以作區分。
位於頂層的下一層節點分別為CCITT（也就是目前的ITU-T）負責管理的ccitt（0）、ISO負責的ISO（1）。
在internet節點下方有很多的子節點，directory（1）保留，未來可能用於OSI目錄服務。 mgmt（2）則由IAB負責，用於定義RFC中的標準管理對象，其實就是MIB-I和MIB-II。 experimental（3）也是由IAB負責管理，用來定義internet實驗性質的管理對象。 Private（4）及下級節點enterprises（1）則由IANA負責分配管理，在enterprises（1）節點下主要用於分配給各企業或組織使用。
OID樹結構如下圖13-2所示。
圖13-2
Zabbix中配置SNMP
1 數據類型
RFC 2578中你會發現SNMP中定義的資料類型，相對於這些資料類型，在Zabbix中配置監控項目選項時，建議Type ofinformation和Store value選項按下表格內容配置。
SNMP 類型 |
##11 述 |
Zabbix#中建議的監控項目選項 |
| 有符號的32為整數 |
|
|
|
||
| Store 值：as is |
|
|
| ##Store value：as is |
| ##Character|
Store 值：as is |
|
|
|
||
| Store 值：delta（speed per second） |
|
|
| Store 值：as is |
|
2 發現OID
在Zabbix中使用SNMP監控設備之前，需要先確定監控項目對應的OID值和資料類型。除了標準的MIB和OID，你需要諮詢設備廠商，透過廠商提供的文件和MIB庫文件，能快速、準確的發現需要監控的OID值。
你可以使用一些圖形化的工具如MG-SOFT MIB Browser，將MIB檔案匯入後，在圖形介面中查詢設備的信息，如下圖13-3所示。
圖13-3
使用圖形化工具可以幫助我們快速的瀏覽、查詢和確定監控項目的OID類型和值，
也可以使用snmpwalk工具直接從裝置查詢。在使用snmpwalk之前，請確保系統已經安裝了軟體。如果未安裝，可以透過下面的命令進行安裝：
# yum install net-snmp-utils
執行snmpwalk查詢裝置資訊。
# snmpwalk -v 2c -c public 10.60.0.19 1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, ME380x Software(ME380x- Cisco IOS Software, ME380x Software(ME380x- Cisco IOS Software,ME380x- UNIVERSALK9-M), Version 15.4(3)S2, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 28-Jan-15 11:43 by prod_rel_team
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1. 1252
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2030697335) 235days, 0:49:33.35
SNMPv2-MIB::sysContact.0 = STRING:
# #SNMPv2-MIB::sysName.0 = STRING: XZX-3800SNMPv2-MIB::sysLocation.0 = STRING:SNMPv2-MIB::sysServices.0 = INTEGER: 6 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00也可以輸出OID對應的數字路徑：# snmpwalk -v 2c -On -c public 10.60.0.19 1.3.6.1.2.1.1.1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, ME380x Software(ME380x-UNIVERSALK9-M), VerIVERSALK9-M), VerIVERSALK9-M), VerIVERSALK9-M), VerIVERSAL 15.4(3)S2, RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2015 by Cisco Systems, Inc. Compiled Wed 28-Jan-15 11:43 by prod_rel_team.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.9.1.1252.1.3.6.1.2.1.1.3.0 = Timeticks: (2030720756) 235 days, 0:53:27.56.1.3.6.1.2.1.1.4.0 = STRING:
.1.3.6.1.2.1.1.4.0 = STRING:
.1.3.6.1.2.1.1.5.0 = STRING: XZX-3800
.1.3.6.1.2.1.1.6.0 = STRING:
#.1.3.6.1.2.1. 1.7.0 = INTEGER: 6
.1.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
當使用不同的參數執行snmpwalk指令時， OID的顯示方式在結果中也會有所不同。無論以何種方式呈現，結果始終由三個部分構成：OID、資料類型和傳回值。例如裝置名稱的顯示如下：
SNMPv2-MIB::sysName.0 = STRING: XZX-3800
.1.3.6.1.2.1.1.5.0= STRING: XZX-3800
#雖然顯示的內容是一樣的，都是sysName的回傳值，但OID的表達方式不同，在Zabbix中定義items時，在SNMP OID設定參數中一些最常用的OID可以使用OID名稱， Zabbix會自動將一些最常用的SNMP OID轉換成數字，例如SNMPv2-MIB::sysName.0會轉換為1.3.6.1.2.1.1.5.0 。但是企業私有MIB的OID只能使用全數位路徑。 Zabbix中可自動轉換的OID如下表13-1所示。
表格13-1
#Special OID |
||
#Identifier |
Description | |
##ifIndex |
1.3.6.1.2.1.2.2.1.1 |
連接埠索引 |
ifDescr |
1.3.6.1.2.1.2.2.1.2 |
連接埠描述 |
#ifType |
1.3.6.1.2.1.2.2.1.3 |
#1.3.6.1.2.1.2.2.1.3 |
#ifMtu |
1.3.6.1.2.1.2.2.1.4 |
|
ifSpeed |
#1.3.6.1.2.1.2.2.1.5 |
|
ifPhysAddress |
#1.3.6.1.2.1.2.2.1.6 |
|
ifAdminStatus |
1.3.6.1.2.1.2.2.1.7 |
|
|
#ifOperStatus #########1.3.6.1. 2.1.2.2.1.8#############連接埠操作狀態##################ifInOctets########################################### #1.3.6.1.2.1.2.2.1.10#############埠接收位元組數#################ifInUcastPkts##### ########1.3.6.1.2.1.2.2.1.11#### |
埠接收非廣播包數 |
|
ifInNUcastPkts |
##1.3.6.1. 2.1.2.2.1.12 | 連接埠接收廣播包數 |
| #1.3.6.1.2.1.2.2.1.13 | 埠接收封包丟棄數 | |
| 1.3.6.1.2.1.2.2.1.14 | 連接埠接收封包錯誤數 | |
| 1.3.6.1.2.1.2.2.1.15 | 連接埠接收未知協定封包數 | |
| #1.3.6.1.2.1.2.2.1.16 | #埠傳送位元組數 | |
| 1.3.6.1.2.1.2.2.1.17 | #埠發送非廣播包數 | |
| 1.3.6.1.2.1.2.2 .1.18 | 埠發送廣播包數 | |
## 1.3.6.1.2.1.2.2.1.19 |
#連接埠傳送封包丟棄數 |
|
| ##ifOutErrors | #1.3.6.1.2.1.2.2.1.20 | 連接埠傳送封包錯誤數 |
| ifOutQLen | 1.3.6.1.2.1.2.2.1.21 | 1.3.6.1.2.1.2.2.1.21 |
3 設定SNMP
Zabbix中開始設定SNMP前，請先確定Zabbix server已經開啟SNMP監控的功能。 Zabbix server啟動時會在日誌檔案中列出Zabbixserver的功能列表，如下所示：
911:20160218:103649.120 Starting Zabbix Server. Za ix 3.0.1 (revision58734).
11 :20160218:103649.160 ****** Enabled features ******911:20160218:103649.160 SNMPmonitor 911:20160218:103649.160 IPMI monitoring: YES 911:20160218:103649.160 Web 649.160 VMware monitoring: YES
# 911:20160218:103649.1## 911:20160218:103649.1## 911:20160218:103649.1##T
911:20160218:103649.160 Jabber notifications: YES
911:20160218:103649.160 ODBC: YES
# 911 :20160218:103649.160 SSH2 support: YES
YES
# 911:20160218:103649.160 TLS support: *****************************
911:20160218:103649.160 using configuration file:/etc/zabbix/zabbix_server .conf
如果沒有發現SNMP monitoring啟用的訊息，那你需要安裝Zabbixserver，如果你使用原始碼編譯安裝，需要使用編譯設定選項--with-net-snmp。
Zabbix中進行SNMP監控時只使用UDP協議，並在一次請求中可以查詢多個值，不論是常規的SNMPitems、dynamic indexes（動態索引）SNMP items，還是SNMPlow-level discovery rules，這在處理大量的SNMP時可以提供效率。透過設定主機的SNMP Interfaces的選項Use bulkrequests允許或停用批次查詢。如下圖13-4所示。
圖13-4在單一介面中具有相同參數的所有SNMP 監控項目會以設定的時間間隔同時查詢，對於常規的SNMPitems和dynamic indexes SNMPitems來說pollers會同時處理128個監控項，而SNMP low-leveldiscovery rules會單獨進行處理，有兩種類型的操作在查詢時完成：收集多個指定的物件和遍歷OID樹。其中收集是指一個GetRequest-PDU可以綁定最多128個變量，遍歷是指在SNMP v1中使用GetNextRequest-PDU，SNMP v2或SNMP v3中使用帶有max-repetitions字段的GetBulkRequest，可以綁定最多128個綁定最多128個變數。 因此，大量處理每個SNMP 監控項目有以下好處：
#常規的SNMP 監控項目收集資料的效能已提升。
Dynamic indexes（動態索引）SNMP監控項目收集資料和遍歷資料的效能得到提升。
- SNMP low-level discovery rules遍歷資料的效能得到提升。
- 但從技術上來講，並不是所有的裝置都能回傳每個要求的128個值，有些裝置能回傳某些回應值，有些裝置回傳錯誤碼tooBig（ 1）或什麼回應都沒有。為了確定對設備查詢物件的最佳數目，Zabbix使用了一些策略，一開始在查詢請求中只查詢一個值，如果成功了在查詢請求中查詢2個值，如果成功了在查詢請求中查詢3個值，並繼續同樣的查詢對象的數量乘以1.5,進行查詢。這些查詢數量依升序排列：1、2、3、4、6、9、13、19、28、42、63、94、128。當設備拒絕回傳正確的回應時（如查詢42個變數），Zabbix或做兩件事：
-
目前批次查詢的item減半，也就是查詢21個變數。如果設備正常的回傳值，那麼在絕大多數情況下應該沒有問題，因為我們知道查詢28個變數是沒有問題的，21要明顯小於28。如果將item減半後仍無法獲得正常的回傳值，那就需要逐一回退查詢的變數數，直到獲得正常的回傳值。
Zabbix在後續的查詢中以上次查詢成功的變數數（我們的例子是28）進行查詢，並繼續增大請求查詢變數的數量（每次加1），直到達到上限。例如，假設最大響應的是32個變數。後續請求將依照29、30、31、32和33進行查詢，最好一個請求會失敗（33個變數），Zabbix將永遠不會再發出綁定33個變數的請求。在這個設備上Zabbix的SNMP 查詢最多綁定32個變數。
當Zabbix server 或proxy server接收到一個不正確的SNMP回應時會在日誌檔案中增加類似下面的內容：
SNMP responsefrom host "gateway" does not contain all of the requested variablebindings
雖然這個資訊並沒有涵蓋所有有問題的情況，但至少有一點就是該主機的SNMP介面中的選項Use bulk requests應該被停用。
4 設定常規SNMP 監控項目
使用SNMP監控設備時，常規的SNMP 監控項目可依下列的步驟設定：
建立主機並在其中新增SNMP介面。可以使用Zabbix中提供的Template SNMP Generic範本自動的新增收集設備基本資訊的監控項目。
2、 確定監控的OID。
透過MIB Browser或snmpwalk找出並確定需要監控的OID，例如我們要監控交換的某個千兆埠的流量，透過snmpwalk找出 GigabitEthernet0/1介面的index是10101。
# snmpwalk -v 2c -c public 10.60.0.19 IF-MIB::ifDescr
GigabitEthernet0/1可以重寫為IF-MIB::ifDescr.10101的字串值
IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2
GigabitEthernet0/3 is identified as IF-MIB::ifDescr.10103.
字串「GigabitEthernet0 /4」是IF-MIB中「ifDescr.10104」的值
IF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5
字串"IF-MIB::ifDescr .10106"對應的是"GigabitEthernet0/6"
IF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7
…
取得GigabitEthernet0/1介面出口介面流量的OID是.1.3.6.1.2.1.2.2.1.16.10101。
# snmpwalk -v 2c -On -c qhdpublic 10.60.0.19IF-MIB::ifOutOctets.10101
##.1.3.6.1.2.1.2.2.1.16.10101 =Counter32: 361925256193、 建立監控項，使用SNMPv2 agent監控方式，SNMP OID為.1.3.6.1.2.1.2.2.1.16.10101。 5 設定動態索引SNMP監控項目在裝置的OID樹中，有些管理物件的OID常會用到index，例如網路接口，使用相同的index關聯到網路介面的不同對像上。就像下面snmpwalk輸出的一樣。 # snmpwalk -v 2c -c public 10.60.0.19 .1.3.6.1.2.1.2.2.1IF-MIB::ifIndex.1 = INTEGER: 1IF-MIB::ifIndex.5001 = INTEGER: 5001IF-MIB::ifIndex.5002 = INTEGER: 5002IF-MIB::ifIndex.5003 = INTEGER: 5003IF-MIB::ifIndex.10101 = INTEGER: 10101IF-MIB::ifIndex.10102 = INTEGER: 10102...## IF-MIB::ifDescr.1 = STRING: Vlan1IF-MIB::ifDescr.5001 = STRING: Port-channel1IF-MIB::ifDescr.5002 = STRING: Port -channel2IF-MIB::ifDescr.5003 = STRING: Port-channel3GigabitEthernet0/1可以重寫為IF-MIB::ifDescr.10101的字串值IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2...IF-MIB::ifType.1 = INTEGER: propVirtual(53)IF-MIB::ifType.5001 = INTEGER: propVirtual(53)IF-MIB::ifType.5002 = INTEGER: propVirtual(53)IF-MIB: :ifType.5003 = INTEGER: propVirtual(53)IF-MIB::ifType.10101 = INTEGER: ethernetCsmacd(6)IF-MIB::ifType.10102 = INTEGER: ethernetCsmacd (6)...IF-MIB::ifMtu.1 = INTEGER: 1500IF-MIB::ifMtu.5001 = INTEGER: 1500IF-MIB::ifMtu.5002 = INTEGER: 1500IF-MIB::ifMtu.5003 = INTEGER: 1500IF-MIB::ifMtu.10101 = INTEGER : 1500IF-MIB::ifMtu.10102 = INTEGER: 1500...IF-MIB::ifSpeed.1 = Gauge32: 1000000000
IF-MIB::ifSpeed.5001 = Gauge32: 2000000000IF-MIB::ifSpeed.5002 = Gauge32: 2000000000IF-MIB::ifSpeed.50:32 = Gauge32 1000000000IF-MIB::ifSpeed.10101 = Gauge32: 1000000000IF-MIB::ifSpeed.10102 = Gauge32: 1000000000#IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0IF-MIB::ifPhysAddress.5001 = STRING: b0:7d:47:be:ea :c2IF-MIB::ifPhysAddress.5002 = STRING: b0:7d:47:be:ea:c3IF-MIB::ifPhysAddress.5003 = STRING: b0:7d :47:be:ea:c4IF-MIB::ifPhysAddress.10101 = STRING: b0:7d:47:be:ea:c2#IF-MIB::ifPhysAddress.10102 = STRING: b0:7d:47:be:ea:c3...IF-MIB::ifAdminStatus.1 = INTEGER: down(2) IF-MIB::ifAdminStatus.5001 = INTEGER: up(1)IF-MIB::ifAdminStatus.5002 = INTEGER: up(1)IF-MIB::ifAdminStatus.5003 = INTEGER: up(1)IF-MIB::ifAdminStatus.10101 = INTEGER: up(1)
IF-MIB::ifAdminStatus.10102 = INTEGER: up(1)
#...
從上面的資料你可以看到每個網路介面都有很多OID，每個OID表示網路介面不同的指標，比如說介面的名稱、類型、實體位址等。你會發現不同的OID都是透過相同的index關聯起來。例如第一個千兆介面的名稱是GigabitEthernet0/1的實體位址是 b0:7d:47:be:ea:c2，狀態是up（1），它的index是10101。
為了監控同一網路介面的不同指標，你可以建立不同的監控項，在SNMP OID欄位中輸入完成的OID。這種方法沒有任何問題，但在實際環境中使用index會有些問題，原因就是index會因為軟體或硬體的升級而發生變化，造成配置的不一致。為了解決這個問題，Zabbix提供了動態索引的方法，即使index值改變也不影響對監控項目的監控。
使用dynamic indexes SNMP OID的語法如下：
["index"," "," "] 語法中各部分的意義如下：
OID of data：item中定義的需要查詢的OID。
Index：處理的方法，目前只支援這一種方法。 Index是指搜尋index並將其追加到OID。
Base OID of index：將會依照該OID來尋找其對應的index值。
string to search for：在尋找時使用該字串進行匹配，區分大小寫。
例如你想監控GigabitEthernet0/1介面的ifInOctets，依照語法可以定義為：
ifInOctets["index","ifDescr","GigabitEthernet0/1" ]
可以理解為在ifDescr中匹配查找GigabitEthernet0/1接口，並或的該接口在ifDescr中index值，然後把收集的index值追加到ifInOctets的後面，從而收集GigabitEthernet0/1接口的ifInOctets值。
當使用dynamic indexes時，Zabbix會接收和快取索引OID的整個SNMP表，透過快取可以很快的發現索引的OID，如果以後其他監控項目查詢相同索引OID時，直接從快取中查找，不需要在去查詢監控主機。
隨後在接收監控項目的資料時會驗證index是否變化，如果index沒有發送變化，會繼續使用該值查詢，如果index發送變化，Zabbix會重建緩存，每個poller會再次遍歷索引OID的SNMP表。
在Zabbix中，每個poller進程都有自己的快取。
6 設定SNMP low-level discovery rules
建立SNMP OIDs 的發現規則時，不像定義檔案系統或網路介面的發現規則，不使用snmp.discovery這個Key，使用SNMP agnet監控方式就可以，在SNMPOID欄位定義需要發現的OIDs，格式為discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,]。
{#MACRO1}、{#MACRO2} … 是所有有效的巨集變數名稱，oid1、oid2 … 用來產生巨集變數的值。在discovery 中系統預設建立了一個名稱為 {#SNMPINDEX}的巨集變量，是用來為discovery OID建立index，發現的結果用{#SNMPINDEX}分組。
透過下面的例子可以幫助你更好的了解。先使用snmpwalk從交換器收集相關數據。
# snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifDescr
IF-MIB::ifDescr.1 = STRING: Vlan1
#GigabitEthernet000 /1可以重寫為IF-MIB::ifDescr.10101的字串值
IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2
#GigabitEthernet0/3 is identified as IF-MIB::ifDescr.10103.
# snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifPhysAddress
#IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0
IF-MIB::ifPhysAddress.10101 = STRING: b0:7d:47:be:ea:c2
#IF-MIB ::ifPhysAddress.10102 = STRING: b0:7d:47:be:ea:c3
IF-MIB::ifPhysAddress.10103 = STRING: b0:7d:47:be:ea:c4
#接著建立發現規則時在SNMP OID欄位輸入：
discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress]
執行發現規則後，得到下列結果：
{
"data": [
{
》( "{#IFDESCR}": " Vlan1",
"{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c0"# # {
"{#SNMPINDEX}": "2",
"{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c2"
# "{#SNMPINDEX}" :"3",
"{#IFDESCR}": " GigabitEthernet0/2",
},
{
或igabitEthernet0/3" ,
為中 "{#IFPHYSADDRESS}":" b0:7d:47:be:ea:c4"
#如果指定的OID沒有回傳值，在發現結果中會忽略對應的macro，如下面的範例。 假設的資料如下：ifDescr.1 "Interface #1"ifDescr.2 "Interface #2"ifDescr.4 "Interface #4"ifAlias.1 "eth0"ifAlias.2 "eth2"ifAlias.3 "eth3"ifAlias.5 "eth5 "然後建立發現規則時在SNMP OID欄位中輸入：discovery[{#IFDESCR},ifDescr, {#IFALIAS}, ifAlias]執行發現規則後，得到以下結果：{ "data": [ {# ## "{#IFDESCR}": "Interface #1", "{#IFALIAS}":#00"##>
"{#SNMPINDEX}": 2,
"{#IFDES)
# }, { "{#SNMPINDEX}": ,#cm#o#o#o#oo>
}, { "{#SNMPINDEX}": 4, }, {# "{#SNMPINDEX}": 5,# ]
}
以下舉個實際的例子，先建立發現規則，如下圖13-5所示。
圖 13-5基於定義好的發現規則建立item原型，如下圖13-6所示。圖 13-6
可以建立多個item原型，如下圖13-7所示。
圖 13-7
以上是Zabbix 3.0監控網路設備有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！