Zabbix 3.0監控網絡設備有哪些

這篇文章主要講解了“Zabbix 3.0監控網絡設備有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Zabbix 3.0監控網絡設備有哪些”吧！

SNMP簡介

1 SNMP 概述

SNMP發展至今以成為應用最廣的網絡管理協議，目前應用的版本主要有SNMP v1、SNMP v2c和SNMP v3。各版本之間主要的差異表現在信息的定義、通信協議的操作和安全機制上，同時也出現了SNMP應用的兩個擴展遠程網絡監控RMON（Remote Network Monitoring）和RMON2。

從物理層的角度看，使用SNMP對網絡進行管理應該包含：網絡管理站（NMS）、代理（Agent）、代理服務器（proxy）。NMS能夠發生命令，接收通知信息，在網絡管理中至少要有一個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與Unsigned32共用一個應用類型標簽號，所以他們的編碼實際上是一致的。

Gauge32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 4294967295）

Unsigned32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 4294967295）

• Counter64是更大范圍的Counter，有64為：2^64-1（0 ..18446744073709551615）。在標準MIB模塊中，只有在使用Counter32時計數器不到1小時就歸0的情況下使用。

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才能知道待管理對象所有的細節。在Agent中實現了MIB中定義的管理對象后說明該Agent支持該MIB。

一個Agent可以實現多個MIB，每個MIB包含的管理對象可多可少，沒有明確的要求。MIB主要由兩部分組成，一部分是國際標準化組織定義的標準的管理對象，包括MIB-I（RFC1156）和MIB-II（RFC1213）。標準的MIB中定義了一些常規和基礎的管理對象，所有入網設備都支持。另一部分是各大廠商、組織或私人自定義的私有MIB，這些私有MIB是廠商根據設備管理的需求，將標準MIB中沒有的需要管理的對象進行自定義。私有MIB定義在節點enterprises（1.3.6.1.4.1）下。

標準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選項按下表內容配置。

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-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-3800

SNMPv2-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), 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

.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.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

3 配置SNMP

Zabbix中開始配置SNMP前，請先確定Zabbix server已經打開SNMP監控的功能。Zabbix server啟動時會在日志文件中列出Zabbixserver的功能列表，如下所示：

  911:20160218:103649.120 Starting Zabbix Server. Zabbix 3.0.1 (revision58734).

  911:20160218:103649.160 ****** Enabled features ******

   911:20160218:103649.160 SNMPmonitoring:                   YES

  911:20160218:103649.160 IPMI monitoring:             YES

  911:20160218:103649.160 Web monitoring:             YES

  911:20160218:103649.160 VMware monitoring:                  YES

  911:20160218:103649.160 SMTP authentication:                 YES

  911:20160218:103649.160 Jabber notifications:                   YES

  911:20160218:103649.160 Ez Texting notifications:                    YES

  911:20160218:103649.160 ODBC:                                                    YES

  911:20160218:103649.160 SSH2 support:                  YES

  911:20160218:103649.160 IPv6 support:                   YES

  911:20160218:103649.160 TLS support:               YES

  911:20160218:103649.160 ******************************

  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個變量。

因此，批量處理每個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 監控項可按下面的步驟配置：

1、  創建主機并添加SNMP Interfaces。可以使用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

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

IF-MIB::ifDescr.10103 = STRING: GigabitEthernet0/3

IF-MIB::ifDescr.10104 = STRING: GigabitEthernet0/4

IF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5

IF-MIB::ifDescr.10106 = STRING: 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: 3619738552

3、  創建監控項，使用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.1

IF-MIB::ifIndex.1 = INTEGER: 1

IF-MIB::ifIndex.5001 = INTEGER: 5001

IF-MIB::ifIndex.5002 = INTEGER: 5002

IF-MIB::ifIndex.5003 = INTEGER: 5003

IF-MIB::ifIndex.10101 = INTEGER: 10101

IF-MIB::ifIndex.10102 = INTEGER: 10102

...

IF-MIB::ifDescr.1 = STRING: Vlan1

IF-MIB::ifDescr.5001 = STRING: Port-channel1

IF-MIB::ifDescr.5002 = STRING: Port-channel2

IF-MIB::ifDescr.5003 = STRING: Port-channel3

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

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: 1500

IF-MIB::ifMtu.5001 = INTEGER: 1500

IF-MIB::ifMtu.5002 = INTEGER: 1500

IF-MIB::ifMtu.5003 = INTEGER: 1500

IF-MIB::ifMtu.10101 = INTEGER: 1500

IF-MIB::ifMtu.10102 = INTEGER: 1500

...

IF-MIB::ifSpeed.1 = Gauge32: 1000000000

IF-MIB::ifSpeed.5001 = Gauge32: 2000000000

IF-MIB::ifSpeed.5002 = Gauge32: 2000000000

IF-MIB::ifSpeed.5003 = Gauge32: 1000000000

IF-MIB::ifSpeed.10101 = Gauge32: 1000000000

IF-MIB::ifSpeed.10102 = Gauge32: 1000000000

...

IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0

IF-MIB::ifPhysAddress.5001 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.5002 = STRING: b0:7d:47:be:ea:c3

IF-MIB::ifPhysAddress.5003 = STRING: b0:7d:47:be:ea:c4

IF-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的語法如下：

<OID ofdata>["index","<base OID ofindex>","<string to search for>"]

語法中各部分的含義如下：

• 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

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

IF-MIB::ifDescr.10103 = STRING: GigabitEthernet0/3

# 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": [

        {

            "{#SNMPINDEX}":"1",

           "{#IFDESCR}": " Vlan1",

           "{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c0"

        },

        {

           "{#SNMPINDEX}": "2",

           "{#IFDESCR}": " GigabitEthernet0/1",

           "{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c2"

        },

       {

            "{#SNMPINDEX}":"3",

            "{#IFDESCR}": " GigabitEthernet0/2",

            "{#IFPHYSADDRESS}":" b0:7d:47:be:ea:c3"

        },

        {

            "{#SNMPINDEX}":"4",

            "{#IFDESCR}": " GigabitEthernet0/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": [

        {

           "{#SNMPINDEX}": 1,

           "{#IFDESCR}": "Interface #1",

           "{#IFALIAS}": "eth0"

        },

        {

           "{#SNMPINDEX}": 2,

           "{#IFDESCR}": "Interface #2",

           "{#IFALIAS}": "eth2"

        },

        {

           "{#SNMPINDEX}": 3,

           "{#IFALIAS}": "eth3"

        },

        {

           "{#SNMPINDEX}": 4,

            "{#IFDESCR}":"Interface #4"

        },

        {

           "{#SNMPINDEX}": 5,

           "{#IFALIAS}": "eth5"

        }

    ]

} 

下面舉個實際的例子，首先創建發現規則，如下圖13-5所示。

圖 13-5

基于定義好的發現規則創建item原型，如下圖13-6所示。

圖 13-6

可以創建多個item原型，如下圖13-7所示。

圖 13-7

感謝各位的閱讀，以上就是“Zabbix 3.0監控網絡設備有哪些”的內容了，經過本文的學習后，相信大家對Zabbix 3.0監控網絡設備有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！