OpManager 中的裝置範本,包含預定義的規則，根據該預定義的規則,對裝置進行分類，並在探索後,立即將相關監視器關聯。為新裝置類型定義自訂範本,或修改現有範本,以在同一範本中適應另一種裝置類型的能力，為管理員提供了極大的靈活性。
也就是說，作為管理員，如果充分利用其潛力，您將能夠將此功能發揮其最大作用。例如，有些人可能最終會為每種裝置類型的變體定義一個範本，而不是建立一個可以包含所有變體的範本。
理想情況下，在啟動探索之前定義裝置範本，有助於正確分類。有 650 多個立即可用的裝置範本。如果在受監視裝置上啟用了 SNMP，並且 OpManager 中設定了正確的認證，則大多數裝置將分類至正確的類別。修改現有範本或根據需要建立一個新範本。
1. 什麼時候應該修改/更新現有範本？
假設您已經購買了新的 Cisco 805 路由器，並且您想使用 OpManager 進行監視。OpManager 已經有 Cisco 800 系列路由器的裝置範本，在範本中更新了這些系列中的少量 sysOID。您只需編輯此範本以包含 Cisco 805 路由器的 sysOID（如果尚未包含）。
2. 什麼時候應該建立新範本？
情節 1
現在讓我們假設您已經購買了 Cisco 11000 系列內容服務交換器。OpManager 還沒有範本（以組建編號 8721 為例！）。現在是時候建立一個新範本了。
情節 2
假設您有一套全新且可管理的環境感應器（支援 SNMP）。這些裝置不能被分類在任何預設類別下，例如伺服器、路由器、交換器等，且有資格得到一個單獨的類別。這種新裝置類型的管理參數也有所不同。這是定義新類別視圖（例如：感應器）的理想情況，同時定義新的裝置範本。您可以在範本中使用同一廠商不同型號的感應器，甚至可以將多個廠商的感應器結合在同一範本中。您在這裡需遵循的步驟如下所示：
3. 如何檢查 SNMP sysOID 的回應
即使在您繼續新增或修改範本,以適應新的裝置類型之前，請確保裝置已啟用 SNMP，並且它會回應 OpManager 的查詢。叫用與 OpManager 配套的 MibBrowser 公用程式以檢查回應。讓我告訴您如何檢查 SNMP 回應。
1.從 OpManager/bin 中，按兩下以執行 MibBrowser.bat。
2.在 MibBrowser GUI 中，輸入裝置名稱、SNMP 連接埠和讀取社群字串（預設為 PUBLIC）。
3.RFC1213 mib 在預設情況下載入。將 mib 擴展到 org->dod->internet->mgmt->mib2 ->系統，並從此表格中選取 sysObjectID。
4.在上面的工具列中，按一下「獲取 SNMP 變數」圖示（左側第 7 個圖示），在右側的文字本區域查看回應。
監視基本的 CPU、記憶體和磁碟使用率,可以很好地指出問題出在哪裡，但是除了資源使用率，您還需監視更多，才可實際確定應用程式緩慢的原因。 多個系統資源參數甚至單個參數都可能會影響應用程式的效能。我們來看看「磁碟 I/O- 導致應用程式效能相關問題的關鍵參數之一。
為什麼監視磁碟 I/O？
硬碟是伺服器上速度最慢的元件之一。硬碟驅動程式頻寬比記憶體慢大約 300 倍，而且記憶體延遲非常低 - 如果進行數學計算，記憶體執行速度將比硬碟快大約 2000 倍。查看 http://nathanaeljones.com/153/performance-killer-disk-io/以獲取簡潔說明。
因此，監視磁碟 I/O 並保持健康級別可以防止很多應用程式效能問題。
我的伺服器是否有磁碟 I/O 問題？
根據您的伺服器，有不同的方法來查找磁碟 I/O 的問題。請參考http://www.performancewiki.com/diskio-tuning.html 以獲取各種伺服器的磁碟 I/O 命令。
另一種簡單的方法，同時也是我們推薦的方法，就是使用 OpManager。OpManager 可立即監視 Windows 伺服器的磁碟 I/O（請參考下面的銀幕擷取畫面）並使用 一些自訂服務 以用於基於 Unix 的裝置
此問題可能由於以下原因：
1）OpManager 中 WMI 未正確設定（OpManager 使用 WMI 認證監視 AD 伺服器）。
2）所需的監視器未與 OpManager 中的裝置關聯。
3）WMI 可能沒有回應 OpManager WMI 要求
4）WMI 在裝置本身上無法正常工作
1）OpManager 中 WMI 未正確設定（OpManager 使用 WMI 認證監視 AD 伺服器）。
一次為多個裝置設定 WMI：
1. 移至「管理員」-->「認證設定」
2. 按一下「新增」
3. 設定以下參數並按一下「新增」以新增認證：
認證類型：Windows
名稱：設定認證的名稱並提供說明。
設定網域名稱的 ID 和密碼（例如： - TestDomainTestUser Testpassword）> 按一下「新增」。
A使用快速設定精靈將上述認證關聯到多個裝置：
1.在「管理員」索引標籤中，選取「快速設定精靈」。
2.選取「將認證關聯到多個裝置」選項，然後按一下「下一步」。
3.將列出所有可用的認證。選取認證（您在上面所建立的認證）。
4.從左側的欄中選取要向其指派認證的裝置，並將它們移動到右側。
5.按一下「結束」。認證已關聯至所選裝置。
使用裝置快照頁面（單個裝置）設定 WMI 認證：
進入裝置快照頁面 > 按一下「密碼」旁邊的「按一下此處以變更」選項，> 選取「為裝置使用以下認證」選項 > 輸入使用者名稱（例如：domainnameuame）和密碼 > 按一下測試認證（確保其通過），然後按一下「確定」以儲存。
如果 OpManager 本身託管在 AD 伺服器上，請將使用者名稱和密碼留空並按一下「確定」，因為本機主機無需認證。
2）所需的監視器未與 OpManager 中的裝置關聯。
解決方案: 為 AD 監視器新增監視器：
確保將類別選取為網域控制器,以使 AD 監視器自動關聯到裝置。
如果監視器缺失， 請移至裝置快照頁面的 Active Directory 監視器部分，並新增所需的 AD 監視器（網路監視器、資料庫監視器、NTFRS process監視器、系統監視器、效能計數器監視器和 LSASS process監視器）。
3）WMI 可能沒有回應 OpManager WMI 要求
解決方案：使用 wmiadap 公用程式更新效能庫中的 WMI 效能類。執行 wmiadap 會更新所有效能類。以下命令中的 /f 交換器會強制更新效能庫中的 WMI 類。
步驟 1:
1.移至受監視裝置。
2.按一下「開始」->「執行」，
對於 Windows 2000，執行 「winmgmt/resyncperf」命令。
對於 Windows XP 和 2003，執行 「wmiadap /f」命令。
3.執行此命令大約 4 次後，等待一小時，然後檢查 AD 監視器是否顯示資料。
步驟: 2
1.移至受監視裝置。
2.按一下「開始」-->「執行」-->services.msc
3.重新啟動 WMI 服務
4）WMI 在受監視裝置上無法正常工作。
解決方案: 如果您沒有看到計數器值，請驗證 OpManager 伺服器是否能夠透過執行以下查詢來提取 AD 計數器資訊。如果您能夠為以下查詢提取資訊，OpManager 應該能夠顯示儀表板中的資訊。
如果以下查詢有些可獲得輸出，而有一些不可以，則與不工作的類相關的計數器資訊將不會顯示在儀表板上。
1.從 OpManager 命令提示移至 <OpManagerconfapplicationscripts>
2.執行以下命令並確保從裝置獲得輸出。
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_PerfNet_Server"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_Processor"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_PerfOS_System"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_PerfOS_Memory"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_NTDS_NTDS"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_PerfProc_Process"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_OperatingSystem"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_LogicalDisk"
cscript wmiget.vbs devicename domainnameuame password "ROOTCIMV2" "SELECT * from Win32_PerfRawData_PerfOS_Processor"
如果針對上述查詢，您收到「無效類」錯誤訊息，則相應的 wmi 類在 AD 伺服器上不存在或已損壞。
請參考以下連結以重新註冊或重建 WMI 類。
http://windowsxp.mvps.org/repairwmi.htm
此問題可能由於以下原因：
1）OpManager 中 WMI 未正確設定（OpManager 使用 WMI 認證監視 MSSQL 伺服器）。
2）所需的監視器未與 OpManager 中的裝置關聯。
3）WMI 可能沒有回應 OpManager WMI 要求
4）WMI 在裝置本身上無法正常工作
1）OpManager 中 WMI 未正確設定（OpManager 使用 WMI 認證監視 MSSQL 伺服器）。
解決方案: 一次為多個裝置設定 WMI：
1. 移至「管理員」-->「認證設定」
2. 按一下「新增」
3. 設定以下參數並按一下「新增」以新增認證：
使用快速設定精靈將上述認證關聯到多個裝置：-
1.在「管理員」索引標籤中，選取「快速設定精靈」。
2.選取「將認證關聯到多個裝置」選項，然後按一下「下一步」。
3.將列出所有可用的認證。選取認證（您在上面所建立的認證）。
4.從左側的欄中選取要向其指派認證的裝置，並將它們移動到右側。
5.按一下「結束」。認證已關聯至所選裝置。
使用裝置快照頁面（單個裝置）設定 WMI 認證：
進入裝置快照頁面 > 按一下「密碼」旁邊的「按一下此處以變更」選項，> 選取「為裝置使用以下認證」選項 > 輸入使用者名稱（例如：domainnameuame）和密碼 > 按一下測試認證（確保其通過），然後按一下「確定」以儲存。
如果 OpManager 本身將成為 MSSQL 伺服器，請將使用者名稱和密碼留空並按一下「確定」，因為本機主機無需認證。
2）所需的監視器未與 OpManager 中的裝置關聯。
解決方案: 為 MSSQL 監視器新增監視器：
以下是將 MSSQL 監視器關聯到裝置的步驟：
1. 移至裝置的快照頁面。
2. 向下捲動並選取「監視器」選項卡。
3. 按一下「效能監視器」。監視器將列示在右側。
4. 按一下右側的「新增監視器」按鈕。將顯示監視器清單。
5. 按一下此清單頂部的「MSSQL 監視器」按鈕。顯示所有 MSSQL 參數的監視器。
6. 從該清單中選取所需的 MSSQL 監視器，然後按一下「新增」> MSSQL 資料庫清單將列出您想要關聯的監視器
7.檢查所有需要的資料庫並按一下「確定」，現在您將得到 MSSQL 的儀表板，並且在一段時間后將填充資料。
3）WMI 可能沒有回應 OpManager WMI 要求
解決方案：使用 wmiadap 公用程式,更新效能庫中的 WMI 效能類。執行 wmiadap 會更新所有效能類。以下命令中的 /f 交換器,會強制更新效能庫中的 WMI 類。
步驟 1:
1.移至受監視裝置。
2.按一下「開始」->「執行」，
對於 Windows 2000，執行 「winmgmt/resyncperf」命令。
對於 Windows XP 和 2003，執行 「wmiadap /f」命令。
3.執行此命令大約 4 次後，等待一小時，然後檢查 MSSQL 監視器是否顯示資料。
步驟: 2
1.移至受監視裝置。
2.按一下「開始」-->「執行」-->services.msc
3.重新啟動 WMI 服務
4）裝置中的 WMI 無法正常工作。
解決方案: 如果您沒有看到計數器值，請驗證 OpManager 伺服器是否能夠透過執行以下查詢,來提取 MSSQL 計數器資訊。如果您能夠為以下查詢提取資訊，OpManager 應該能夠顯示儀表板中的資訊。
如果以下查詢有些可獲得輸出，而有一些不可以，則與不工作的類相關的計數器資訊將不會顯示在儀表板上。
1.從 OpManager 命令提示移至 <OpManagerconfapplicationscripts> 2.執行以下命令並確保從裝置獲得輸出。
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerBufferManager "
Example:OpManagerconfapplicationscripts>cscript wmiget.vbs MSSQLSERVER1 TestUame Password ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerBufferManager "
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerCacheManager "
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerPlanCache "
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerDatabases"
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerGeneralStatistics "
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerReplicationAgents "
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerLocks"
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "select * from Win32_PerfRawData_MSSQLSERVER_SQLServerMemoryManager"
cscript wmiget.vbs <Devicename or IP> <DomainnameUame> <Password> ROOTCIMV2 "Select * from Win32_PerfRawData_MSSQLSERVER_SQLServerGeneralStatistics"
如果針對上述查詢，您收到「無效類」錯誤訊息，則相應的 wmi 類在 MSSQL 伺服器上不存在或已損壞。
請參考以下連結以重新註冊或重建 WMI 類。
http://windowsxp.mvps.org/repairwmi.htm
在 Windows 2003 伺服器中，SNMP 服務可用，且僅支援 SNMP v1 和 v2c。如果您想新增 SNMPv3 支援，你需要安裝 snmpv3 支援的代理程式。下載 Net-Snmp 代理程式以進行支援。
請按照以下步驟安裝 snmpv3 代理程式。
1.首先從以下連結下載 Active Perl
http://downloads.activestate.com/ActivePerl/Windows/5.10/ActivePerl-5.10.0.1002-MSWin32-x86-283697.msi
2.先安裝 Active perl。您還需安裝 OpenSSL。
3.從以下連結下載 NetSnmp 代理程式的 exe 檔案
http://sourceforge.net/project/showfiles.php?group_id=12694&package_id=162885
4.安裝 Net-Snmp 代理程式。
5. 安裝 netsnmp 代程式後。在此，我附上了 conffile，請將 snmp.conf.txt 重新命名為 snmpd.conf，將 snmpd.conf.txt 重新命名為
snmpd.conf。複製目錄 c:utcsnmp 下的 snmpd.conf 和 snmp.conf
6.然後透過執行 registeragent.bat 檔案註冊代理程式並在命令行中執行以下命令來開始代理程式。
net start "net-snmp agent"
7.現在代理程式在連接埠 8001 上啟動。
相關連結：
http://www.netadmintools.com/art487.html
在 ESX Server V3.5 上啟用 SNMP：
1.以 root 身份登入
2.編輯 snmpd.conf 檔案並新增「rocommunity xxxx」，其中 xxxx 是您的唯讀社群字串。該檔案通常位於 /etc/snmpd 中。
3.在編輯 snmpd.conf 檔案時，還需新增 「dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so
4.重新啟動 SNMP 精靈 - /etc/init.d/snmpd restart
在某些情況下，您可能還需要編輯 ESX 伺服器上的防火牆設定以允許 SNMP 流量通過。要執行此操作：
以 root 身份登入並發出以下命令：
2. esxcfg-firewall -e snmpd
3. chkconfig snmpd on
4. service snmpd start
有關更多資訊，請造訪 ESX 伺服器上的 關於如何設定 SNMP 的 VMWare 頁面。
您可以將 OpManager 作為 Unix 服務執行。
按照以下步驟將 OpManager 作為服務安裝在 Linux 機器上。
1.將以下藍色內容複製到一個文字檔案中，並將其作為 opmanager 儲存到 /etc/init.d 目錄。
#!/bin/bash
#
# Startup script for the pmagent
#
# chkconfig: 345 99 02
# description: 執行 OpManager 5 程序
INITLOG_ARGS=""
prog="opmanager"
progname="AdventNet ManageEngine OpManager"
RETVAL=0
# Edit the following to indicate the 'bin' directory for your installation
MDIR=/usr/local/OpManager/bin
PRG=$MDIR/opmanager
if [ ! -d "$MDIR" ]
then
echo "Invalid directory $MDIR"
exit 1
fi
start()
{
mv -f /var/log/opmanager.log /var/log/opmanager1.log
echo "Starting $progname"
cd $MDIR
nohup sh StartOpManagerServer.sh >/var/log/opmanager.log 2>&1 &
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/OpManager
}
stop()
{
echo "Stopping $progname"
cd $MDIR
sh ShutDownOpManager.sh admin admin >>/var/log/opmanager.log 2>&1
}
case "$1" in
start)
start
;;
stop)
stop
;;
*)
echo "Usage: $prog {start|stop}"
exit 1
;;
esac
exit $RETVAL
mv /etc/init.d/opmanager.txt /etc/init.d/opmanager
2.在該檔案中編輯應指向 OpManager 安裝目錄中 bin 資料夾的 MDIR 變數。通常，Linux 機器上的預設安裝資料夾將是/root/ManageEngine/OpManager/bin因此，MDIR 的值將會是
MDIR=/opt/ManageEngine/OpManager/bin
3.使用以下命令提供此指令碼的可執行權限
chmod 755 /etc/init.d/opmanager
4.使用 chkconfig 命令將 opmanager 新增為服務
chkconfig --add opmanager
您可以在 nohup 模式下啟動 OpManager，以便在關閉主控台時不必擔心服務被終止。該服務將繼續在後台執行。在 OpManager 的開始和停止指令碼檔案中進行這些變更：
在開始檔案中
nohup /opt/ManageEngine/OpManager/bin/StartOpManagerServer.sh
在停止檔案中
nohup /opt/ManageEngine/OpManager/bin/ShutDownOpManager.sh
您可能會遇到如「未找到命令」之類的錯誤。可能有少數相關的程式庫檔,在您嘗試安裝 OpManager 的系統上不可用。安裝封裝並繼續安裝 OpManager。例如，如果您在 Ubuntu 中遇到此類問題，那麼您需要執行以下操作：
$ apt-get install libnewt0.51
$ ln -s /usr/lib/libnewt.so.0.51 /usr/lib/libnewt.so.0.50
$ wget http://www.tuxx-home.at/projects/chkconfig-for-debian/chkconfig_1.2.24d-1_i386.deb
$ dpkg --force-all -i chkconfig_1.2.24d-1_i386.deb
源: http://ubuntuforums.org/archive/index.php/t-20583.html
1.在用戶端視窗中，按一下功能表列上的「註冊」連結。
2.瀏覽並選取為您提供的註冊授權檔案 (AdventNetLicense.xml)，然後按一下「註冊」。
3.驗證頁面中顯示的授權詳細資料，然後按一下「關閉」。
如果您在試用授權到期後申請註冊授權，請執行以下操作：
1. 啟動伺服器。您會看到訊息「試用期已過期」。
2.按一下「確定」以輸入授權詳細資料。
3.瀏覽並選取為您提供的註冊授權檔案 (AdventNetLicense.xml)，然後重複上述步驟。
您需要從 Manageengine 購買延長的試用授權。這純完全是出於謹慎。傳送電子郵件要求至 sales@manageengine.com
它是 Package for Patch Manager 的縮寫，與 Perl 無關。副檔名為 .ppm 的檔案已知可與 AdventNet 產品配套的更新管理器工具一起使用。這個工具有助於在升級到新版本時保持資料不變。在 OpManager 中，您可以使用「開始」->「程序」->「ManageEngine OpManager->「更新管理器」存取此工具。或者，您也可以從 /opmanager/bin/UpdateManager.bat/sh 叫用該工具。
OpManager WAN RTT 監視器使用Cisco's IP-SLA監視兩個位置之間的延遲, 因此其中一個位置需要啟用帶 IPSLA 代理程式的 Cisco 路由器，該代理將充當源，目標可以是另一位置的任何 IP（無需是 cisco 路由器）。
只有 MSSQL 帳戶具有 DBOwner 權限，OpManager 才能建立資料庫及其表格。 它使用 SQL 使用者名稱和密碼連線到 MSSQL 伺服器。 所以必須啟用 SQL 驗證。
對於預設的 MSSQL 執行個體，連接埠號將是 1433。
http://msdn.microsoft.com/en-us/library/ms177440.aspx
http://support.microsoft.com/kb/823938
對於命名執行個體，應當輸入 hostnameinstancename 作為資料庫主機
要檢視 Netflow Analyzer 的詳細流量報表，必要條件有，
如果裝置已成功新增，但未在虛擬機器地圖下顯示，請搜尋該裝置。移至其快照頁面,並查找裝置類型。如果它被分類為「未知」，則可能提供了錯誤的認證，或者在探索期間無法存取。提供正確的認證,並按一下快照頁面的「動作」索引標籤下的「立即重新探索」，以將其作為 ESX 主機探索。
OpManager 在已安裝的 VMware 工具的幫助下，識別 VM 的 IP 位址,並將其對應到主機。如果未安裝 VMware 工具，則 OpManager 使用 VM 的實體名稱,對其進行探索。您可以在主機快照頁面（其銀幕擷取畫面如下）中為這些 VM 指派 IP 位址。按一下對應於 VM 的「無 IP 位址」連結為該 VM 指派 IP 位址。同樣，您可以按一下指派的 IP 位址以選擇另一個 IP 位址作為該特定 VM 的主要 IP。
CIDR 是 Classless Inter-Domain Routing（無類別網域間路由）的縮寫，取代了自 1981 年以來一直使用的舊版分類別網路定址基礎結構。CIDR 於 1993 年推出，用於解決 IP 位址短缺的問題。
CIDR 方法,將內部網路通訊協定 V4 (IPv4) 的位址空間劃分為五個位址類別。每個類別使用位址的前四個位元進行編碼，定義了不同的網路大小，即用於單一位址（A、B、C 類）或多點傳送網路（D 類）的主機數量。第五類 (E) 位址範圍保留用於將來或實驗目的。現在，IPv6 正在快速取代 IPv4，允許網際網路上的更多使用者和裝置進行大規模擴展。
種子裝置,是網路中的核心交換器。交換器必須啟用 SNMP，以便 OpManager 能夠自動查詢裝置並繪製連結，顯示網路上所有裝置的連線性。由於網路頻繁發生變更，OpManager 可讓您設定時間間隔（以天為單位）重新繪製地圖。例如，如果一周內發生一次變更，則可以設定 OpManager 每七天重新繪製一次地圖。
在 L2 探索和對應之後，無論何時按一下地圖上的連結，都會彈出錯誤「OpManager 中不存在與此連結關聯的介面」。
兩個網路裝置之間連線的介面連結,不能新增到 OpManager 中。因此彈出訊息。 例如，假設路由器 1 透過路由器 1 的介面 Ethernet0/0 連線到路由器 2。 如果在路由器 1 中未新增 Ethernet0/0 介面，則會遇到上述錯誤。透過重新探索介面,並嘗試繪製地圖，在路由器 1 中新增介面後，您將在彈出訊息中獲得介面流量詳細資料。
為 L2 對應設定種子檔案時遇到此錯誤。
為了獲得網路地圖，交換器應該支援 SNMP 通訊協定。用於查找網路裝置之間連線的 mib 如下所示，
i) BRIDGE-MIB
ii) RFC-1213-MIB
iii) CISCO-CDP-MIB.
大多數其他廠商交換器支援 Bridge MIB。所以對於非 Cisco 裝置，我們可以從這個 mib 獲得連線詳細資訊。如果您仍然遇到錯誤，那是由於 OpManager 使用 RFC1213 和 ipRouteTable 來建立對應。此 RFC 已被取代，並已被 RFC2096 和 ipCidrRouteTable 取代。這可以透過 Mib 瀏覽器進行複寫。嘗試查看您的裝置是否符合 RFC1213 或 RFC2096。應該很快會有一個來自團隊的修補檔案，以確保所有裝置正確對應。
以下是在路由器上設定 SNMPv3 的步驟：讓我們設定一個名為 Henry 的特權使用者，並在下面提供相關的詳細資料。
使用以下命令在路由器中設定使用者，
1.首先 telnet 路由器。
2.使用以下命令檢查 engineID 是否已設定
show snmp engineID
如果它顯示 engineID 的詳細資料，則無需發出以下命令。如果上述命令給出空結果，則請發出以下命令。
snmp-server engineID local 8000063000100a1ac151003
3.建立讀/寫/通知視圖。
snmp-server view readview internet included
snmp-server view writeview internet included
snmp-server view notifyview internet included
4.建立使用者
snmp-server user Henry privGroup v3 auth md5 authUser priv des56 privUser
5.將使用者與組對應。
snmp-server group privGroup v3 priv read readview write writeview notify notifyview
結束。Snmp V3 在該路由器中正確設定。
現在使用以下命令檢查它是否可以正確執行 snmpwalk
snmpwalk -d -v 3 -a MD5 -A authUser -l authPriv -u Henry -x DES -X privUser <TargestHostName>:<TargetPort> system
範例： snmpwalk -d -v 3 -a MD5 -A authUser -l authPriv -u Henry -x DES -X privUser proto-test3:161 system
如果您可以在命令列中看到一些回复，那麼它真工作正常
有關在路由器上進行 SNMP v3 設定的詳細資料，請查看以下連結
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html
現在在 OpManager 下的「管理員」- > 「認證設定」中新增新的認證及這些相關詳細資料，並新增新的裝置到 OpManage，然後檢查其是否有幫助。請讓我知道它是如何工作的。
某些使用者在基礎結構視圖中檢視時,遇到「介面缺失」問題。了解如何在 OpManager 中探索介面將有助於了解其原因。
OpManager 使用 OpManager 中為該裝置設定的 SNMP 參數，查詢 RFC1213-MIB 的 ifTable 和 ipAddrTable。對於 ifTable 中的 ifIndexes(OID: .1.3.6.1.2.1.2.2.1.1)，如果 ipAddrTable 中有 ipAdEntAddr(OID: .1.3.6.1.2.1.4.20.1.1)，則將其作為 SnmpInterface 表格中的介面新增，隨附其速度、索引、描述、phyMedia、phyAddress 和父系裝置等屬性。如果位址是可 ping 的，那麼該介面將是一個受控介面，否則將新增為非受控介面。如果 ifType 是回送的，或者 ipAdEntAddr 是 127.0.0.1，則將不會新增該介面。在 OpManager 中，將採用 ifTable 中的索引數目。如果介面沒有 IpAddress，則 OpManager 將它們以 IF-<primary ip address of Router>-index 的格式新增，隨附其屬性。如果裝置有兩個以上的介面，且 ipForwarding(OID: .1.3.6.1.2.1.4.1) 被啟用，那麼它將被歸類為路由器。
但是，對於路由器以外的裝置，不會新增無編號的介面，以及具有 ifIndexe 但在 ipAddrTable 中沒有 ipAddrEntAddr 的介面。
如果路由器設定錯誤，比如兩個位址 ipAddrTable 中具有相同索引，則后一個將被新增，而第一個將不會被新增，因此不會出現在路由器視圖中。這個限制是因為對於我們來說，索引是一個金鑰，因此不會有重複。
要解決此問題，請檢查路由器 IOS 是否存在任何問題，如果存在索引重複，並解決這些問題。 之後，刪除並重新新增裝置。
| 管理員 | 操作性 | 狀態 | 色彩編碼 |
|---|---|---|---|
| 向下 | 上/下 | 嚴重 | 紅色 |
| 執行 | 執行 | 清除 | 綠色 |
| 執行 | 向下 | 疑難 | 橙色 |
| 執行 | 休眠（準備接收/傳輸封包） | 清除 | 綠色 |
| 執行 | 不存在/未知/測試 | 注意 | 黃色 |
如果管理和操作狀態為「執行」，並且介面中有任何監視器出現臨界值違規，則連接埠將移動至故障狀態（橙色）。
如果 SNMP 代理程式回應來自 Cisco-ENVMON MIB 的 Temparture OID，則可以監視 OpManager 中的 Cisco 路由器溫度
首先，我們需要確保要監視的路由位於路由器的路由表中。要檢查此情況，請在特權模式下執行顯示 IP 路由。
例如：
cisco2811#show ip route
最終求助閘道為 192.168.118.2 到網路 0.0.0.0
C 192.168.118.0/24 已直接連線 FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.118.2
如上所示，網路位址 192.168.118.0 的路由存在於路由表中（在這種情況下，它將直線連線）
如果網路位址 192.168.118.0 的下一Hop位址是已知的，我們可以監視此路由。
在預設 RFC-1213MIB 中，我們有 OID IPRouteNextHop (.1.3.6.1.2.1.4.21.1.7)，這將提供全部路由表資訊。
ipRouteNextHop.0.0.0.0:-->192.168.118.2
ipRouteNextHop.192.168.118.0:-->192.168.118.23
如以上輸出所示，下一Hop位址為 192.168.118.23，這是預期行為。
為了監視此特定的 192.168.118.0 路由，我們可以在網路位址中新增上述 OID，即 1.3.6.1.2.1.4.21.1.7.192.168.118.0
因此，對於此 OID (.1.3.6.1.2.1.4.21.1.7.192.168.118.0)， MIB 中的輸出將是下一Hop的 IP。
找到指定路由的 OID 後，可以透過新增自訂 SNMP 監視器來輕鬆監視路由。
透過取消選中數字方塊來將 IP 位址新增為字串 OID。
如果下一Hop不包含此 IP 位址 (192.168.118.0)，可以將其設定為臨界值，您將得到警告。如果它包含此 IP 位址 (192.168.118.0)，則可以在沒有警告或警告已清除的情況下，將其設定為重設值。
現在將監視器關聯至裝置。
| 序列號 | SNMP 監視器 | Trap |
|---|---|---|
| 1 | Pull 模式：OpManager SNMP 要求傳送至在被監視裝置上執行的 SNMP 代理程式並接收回應。 | Push 模式：受監視裝置（SNMP 代理程式）以Trap形式向Trap目的地 (OpManager) 傳送訊息 |
| 2 | 通訊：雙向 (UDP 161) | 單向。僅從裝置到Trap目的地 (UDP 162) |
| 3 | 可以使用監視時間間隔來排程 SNMP 要求。 | Trap是自發的。它們一旦生成就會到達目的地。 |
| 4 | 可以為非預設指標建立自訂 SNMP 監視器。這些監視器將原始 SNMP 回應轉換為有意義的指標。 | 可以為新的Trap訊息建立自訂 SNMPTrap處理器。他們處理Trap資訊並將其轉化為有意義的警告。 如果沒有Trap處理器，Trap將被放置在「警告」->「未經要求的Trap」下。 |
| 5 | 要獲取 SNMP 回應，必須提供 SNMP 社群字串 | 要接收Trap訊息，不強制要求社群字串。 |
交換器連接埠對應程式不會完全顯示 MAC 位址和 IP 位址。
路由器輸入可能未指定，或者 ARP 快取可能未更新。
1.路由器輸入未指定。輸入路由器名稱以將 MAC 位址對應到 IP 位址。路由器應該與連線到交換器的裝置位於同一子網路中。
2.如果沒有給出路由器輸入，則將從交換器的 ARP 快取中獲取資訊。快取檔案也在本地維護以存儲此資訊。執行子網路的 ping 掃描以更新快取，然後執行交換器連接埠對應。這將改善 MAC 到 IP 解析。
如果以上內容是正確的，請按照以下步驟操作
1. 從 <OpManager>\\Bin 資料夾開啟 MIB 瀏覽器
2. 主機名稱（交換器名稱）
3. 提供該裝置的社群字串
4. 按一下「載入 MIB」並載入 BRIDGE.MIB
5.現在嘗試查詢這些值 BRIDGE.MIB -->> mib2-->>.iso -->> org -->> dod -->> internet-->> mgmt-->> mib-2 -->> dot1dBridge -->>dot1dTp -->>dot1dTpFdbTable -->> dot1dTpFdbEntry -->>dot1dTpFdbAddress
嘗試查詢這些值。如果您在收到 MAC 位址的同時還收到回复，則值將顯示在交換器連接埠對應程式中。
Trap 是 SNMP 裝置中發生錯誤的隱藏訊息。SNMPTrap,是受控裝置上的代理程式生成的警示。這些Trap生成 5 種類型的資料：
由於某些監視系統嘗試使用錯誤的社群字串存取裝置，導致驗證失敗警告。可能是由於 opmanager 或安裝在您網路中的其他監視系統,使用錯誤的社群字串傳送 snmp 查詢引起的。
設定正確的社群字串。它位於 Opmanager 中得到「設定」->「密碼」下。同時檢查 opmanager 或第三方監視應用程式的其他安裝中,是否存在錯誤社群字串。
如果您需要了解有關此問題的詳細資料，如哪個裝置傳送了錯誤的 SNMP 社群字串，請在傳送驗證Trap和擷取封包的裝置上,安裝 packet sniffer 軟體 (www.ethereal.com) 。透過分析擷取封包，您可以找到使用錯誤社群字串傳送 SNMP 查詢的裝置。將擷取封包與 OpManager 伺服器和您收到驗證Trap的裝置的 IP 位址,一起傳送給我們，以進行分析。
重設值是確定監視器還原到正常狀態的值。例如，記憶體監視器的臨界值狀態選取為大於 [>]，且臨界值設定為 75。該裝置的受監視記憶體值為 80。那麼，現在將發出警示，且該監視器處於違規狀態。在下次輪詢時，監視值為 72。則將生成恢復正常狀態的警示。在下次輪詢時，監視值變為 80。將再次生成臨界值違規警示。為了避免這種情況，請輸入重設值。只有當監視值達到重設值時，監視器才會進入正常狀態並發出正常警示。註：如果選取臨界值條件更大，則重設值應小於臨界值，反之亦然。
請根據以下步驟,檢查未收到Trap的原因,及相應解決方案。
1.Trap連接埠可能被 opmanager 伺服器佔領。--->確保 OpManager 的Trap連接埠未被作業系統 (ie) 的Trap服務佔領。連接埠 162 應當空閒。如果不空閒，則釋放它，然後重新啟動 opmanager。
2.裝置可能在 OpManager 中不受監視。-->應在 OpManager 中新增裝置以接收來自該裝置的Trap。
3.Trap目的地可能錯誤 - > OpManager 伺服器應該是傳送Trap的裝置的Trap目的地。
如果問題仍然存在，請按照以下步驟檢查 OpManager 伺服器上是否正確接收到Trap。
1.停止 OpManager。確保連接埠 162 未被佔領。
2.開啟位於 \OpManager\conf 資料夾下的檔案 MibBrowser.bat。
3.移至「檢視」->「Trap檢視器」，並檢查Trap是否被正確接收。
4.如果Trap接收器中未收到Trap，則Trap未到達 OpManager 伺服器，您可以解決該問題，以使 OpManager 收到Trap。
5.如果您在Trap處理器而不是 OpManager 上收到Trap，請連絡支援部門。
編輯 /OpManager-Home/conf 下的檔案「trapport.conf」。將連接埠從 162 變更為您想要的連接埠。 重新啟動 OpManager 以使變更生效。
不，L2 地圖也適用於非 Cisco 裝置。在嘗試為非 Cisco 裝置繪製網路地圖時，您可能有時會遇到錯誤「找不到此裝置的交換器連結。請選取其他種子裝置」。要獲取其他廠商交換器的 L2 地圖，它必須符合以下條件：
如果您仍然遇到錯誤，那是由於 OpManager 使用 RFC1213 和 ipRouteTable 來建立對應。此 RFC 已被取代，並已被 RFC2096 和 ipCidrRouteTable 取代。這可以透過 Mib 瀏覽器進行複寫。嘗試查看您的裝置是否符合 RFC1213 或 RFC2096。應該很快會有一個來自團隊的修補檔案，以確保所有裝置正確對應。
有很多機制可以找到網路連線。OpManager 使用一般演算法,找出使用 SNMP 的交換器、路由器和網路裝置之間的連線。L2 網路連線屬於以下提到的類別。
i）路由器到路由器的連線。
ii）交換器到交換器的連線。
iii）交換器到網路裝置（如路由器、防火牆、存取點）的連線。
i）路由器到子網路的連線。
v）連線到交換器的終端裝置。
路由器到路由器的連線/路由器到子網路的連線：
所有路由器上都設定了路由演算法，透過查詢 RFC1213-MIB 的 ipRouteTable 可以從路由器,擷取路由表格的詳細資料。ipRoutable 表格包含路由器中存在的每個路由的項目。
我們查詢的 oids 是，
此路由表,包含來自特定裝置的直接和間接路由路徑。這意味著路由器介面,直接連線到另一個路由器介面，無需中繼交換器或中樞。
ipRouteDest - 此路由路徑的目的地 IP 位址可能是網路位址或路由器 IP 位址。
ipRouteIndex - 一個介面，此路由路徑應透過此介面到達下一Hop。
ipRouteNextHop - 此路由路徑下一Hop的 ipaddress。它包含源 ipaddress（如果它連線至網路，則為網路 IP 位址）或所連線的路由器 IP 位址。
ipRouteType - 此路由路徑的類型（直接、間接、無效等）。
如果路由類型為直接， 則意味著我們可以透過此介面到達 ipRouteDest 中指定的子網路，且下一Hop包含此路由器的相同 IP 位址。該介面可以由路由索引值標識。所以我們將獲取路由器至子網路的連線作為交換器連結物件。交換器連結物件包括源->目的地以及所連線的介面。
如果路由類型為間接，意味著該路由器連線至另一個路由器。 我們有源路由器和遠端路由器 IP 位址（在下一Hop節點中獲得）以及介面索引。因此，我們將確定路由器到路由器的連線。
例如，路由器 192.168.112.7 的 iproutingTable 輸出，
路由器 192.168.112.7 透過 192.168.112.7 的介面 2 連線至 192.168.116.12。 此外，透過此路由器達到子網路 192.168.112.0。
交換器到交換器的連線
查找交換器連線所需的管理資訊庫 (MIB) 物件如下所示：
OpManager 實施拓撲探索演算法，這在使用 SNMP 的 IP 網路拓撲探索」中進行了解釋（按一下連結）。OpManager 使用上表中的值,以查找交換器到交換器的連線。Bridge mib dot1dTpFdbTable 包含可透過此交換器到達的裝置的 MACAddress ,以及連接埠和狀態資訊。dot1dTpFdbStatus 可以處於五種狀態之一 - 其他 (1)、無效 (2)、已知 (3)、自我 (4)、管理 (5)。已知類型指活動裝置連線。OpManager 僅考慮此類型來找出連線。該表格含有帶連接埠關係的 macaddress，其相應的 ifIndex 透過查詢 dot1BasePortTable 獲取。 這只給出裝置的 MAC 位址，因此裝置的 ipaddress 透過查詢 RFC1213-MIB 的 ipNetToMediaTable 獲取。
主要演算法是
1.交換器組 = 篩選支援 Bridge MIB 的 L2、L3、L4 和 L7 交換器
2.交換器對組 = 將交換器進行配對；如果有 n 個交換器，則會有 n2 組
3.對於每個交換器對組，如：{ Si, Sj}
a) 從 ifPhyaddress 獲取 Si 的 MAC 組，即 {Mia..Mil}
b) 從 ifPhyaddress 獲取 Sj 的 MAC 組，即 {Mja..Mjk}
c) 如果 Si 和 Sj 的其中一個 dot1dBasePortEntry（Pi 和 Pj）的 AFT 具有彼此的至少一個 MAC 地址 Mil 和 Mjk
那麼
i) 獲取 Pi 和 Pj
ifIndex Ifi 和 Ifj 的對應
ii) 為介面 Ifi 和 Ifj 設定 Si 和 Sj 的連線性
iii) 將連線性資訊存儲在資料庫中。
使用 CDP 的交換器至網路連線
Cisco 探索通訊協定 (CDP) 是由 Cisco 系統開發的調解性資料連結層通訊協定。它用於共用有關直接連線的 Cisco 裝置的資訊。可透過查詢以下表格獲取以上詳細資料：
當查詢上述表格時，OpManager 構成了 Cisco 裝置和所連線裝置之間的交換器連結。這是因為該表格具有所連線裝置的 IP 位址以及其連線所通過的介面的詳細資料。
有時，在 OpManager 伺服器上執行的防毒程式,可能會導致資料庫損壞（儘管還有其他原因會導致資料庫損壞，如執行 Symantec 等第三方公用程式進行備份等）。 要解決此問題，請嘗試暫時停止防毒程式或備份公用程式，然後驗證其狀態。您也可以嘗試從防毒程式中排除 OpManager，以防止引發問題。
執行 Mcafee、Trend Micro 等防毒程式,還可能封鎖探索或阻止 OpManager 啟動。 如果 OpManager 不開始，您需要從防毒程式的存取保護設定 中,移除連接埠封鎖或解除鎖定 java.exe。對於一些防毒程式應用程式，從掃描中排除檔案/資料夾將會起作用。
您需要啟用 UDP jitter。
UDP jitter 操作與 RTP VoIP 操作對比
UDP Jitter 是傳送專門用於效能測量的 UDP 測試封包流的操作。還有另一種稱為「RTP VoIP」的操作。兩者之間有根本的區別：
RTP VoIP 傳送實際 RTP 資料流，而 UDP Jitter 傳送模擬資料流。兩者從外部看起來一樣，但 RTP VoIP 封包包含實際 RTP 資料流。
RTP VoIP 使用並需要至少一個硬體轉碼器才可執行。它需要執行於 DSP 資源和語音介面之上。
RTP VoIP 將根據延遲和丟失的 DSP 幀數來計算 MOS 分數。UDP Jitter 提供基於 IP 的指標，而 RTP VoIP 提供基於 DSP 的指標。
RTP VoIP 是非常特定於 VoIP 的操作，UDP Jitter 更通用。
RTP VoIP 並非設計用於大規模部署，而 UDP Jitter 則是。
建議盡可能使用 UDP Jitter，對於大多數情況來說，這已經足夠了。當需要更詳細的資訊或出於疑難排解目的時，可以在特定時間和位置按需觸發 RTP VoIP 操作。RTP VoIP 並非用來取代 UDP Jitter。
如需更多資訊：請查看此處連結：
http://docwiki.cisco.com/wiki/IOS_IP_SLAs_UDP_Jitter_Operation_Technical_Analysis
OpManager 使用 IP SLA UDP jitter 操作來確定連線 jitter、來回行程時間、封包丟失和延遲。因此，它使用此綜合流量來模擬接近即時流量的流量，且不會對其進行即時監視。IPSLA 的功能是透過模擬即時環境來主動識別質量問題。
將舉例來說明使用綜合流量的需求。讓我們假設在某個特定日子的下午 3 點，為您的 CEO 與潛在客戶排程了通話。出於某種原因，VoIP 連線在下午 2 點 30 分左右斷開，而相關人員不知情。 想像一下，您或 CEO 在通話開始時發現問題！這是 VoIP 管理員害怕會遇到的情況。在這種情況下，透過即時流量流動的同一 WAN 連結傳送綜合流量的方法有所幫助。您可以更早地發現封包丟棄，並且可能更早地解決瓶頸問題。
OpManager 主要依靠 Cisco 的 IP-SLA 監視兩個位置之間的 VoIP QoS 指標，因此這兩個位置都應該啟用具有 IPSLA 代理程式的 Cisco 路由器。從 IOS V12.3(14)T 開始，所有 Cisco 路由器都支援 VoIP QoS 指標的監視
如果要測試從辦公室到另一個位置的連結，則需要在每端都啟用具有 IPSLA 代理程式（IOS V12.4 或更高版本）的 Cisco 路由器。
是的，只要沒有連接埠衝突，兩者可以安裝在同一個系統上。您可以按以下方式變更 OpManager 連接埠：
1.在 \OpManager\conf 資料夾下開啟檔案 Ports.properties。
2.TOMCAT_SHUTDOWNPORT 變更為 8015。
3.儲存並啟動 OpManager。
如果 OpManager 所需的連接埠已被佔用，則可能會發生此問題。因此，請按照以下步驟操作並變更 Tomcat 關閉連接埠，然後檢查是否有幫助。
1.在 \OpManager\conf 資料夾下開啟檔案 Ports.properties。
2. TOMCAT_SHUTDOWNPORT 變更為 8015。
3.儲存並啟動 OpManager。
可以，OpManager 擁有大量磁碟監視器，並具有以下圖形報表：
OpManager 透過 API 獲取詳細資料，因此請確保正確設定 VMware 認證。您可以從主機快照頁面,存取監視器詳細資料，並且還可以查看,基於每個 VM 的報表。以下是銀幕擷取畫面以供參考：
首先，了解 OpManager 如何將裝置分類到伺服器、路由器、交換器等非常重要。OpManager 依靠 SNMP、CLI 和 WMI 等行業標準通訊協定來「識別」裝置。SNMP 是所有裝置類別的標準通訊協定，CLI 特定於基於 Unix 的伺服器，而 WMI 特定於 Windows 環境。
由於以下原因，裝置被分組在「未知」裝置視圖下：
分類為「未知」類別的裝置
因此，即使 OpManager 能夠 ping 並成功探索裝置，它不知道該將該裝置防止在何處，因此將其分類為「未知」！如果您發現相關類別地圖中,任何伺服器或其他基礎結構裝置缺失，請選取「地圖」->「未知類別視圖」，並檢查它是否存於此處。您可以將此類裝置移動到相關類別，或在啟用 SNMP/CLI/WMI 通訊協定和 設定認證后對其進行重新探索。
以下是可用性狀態資訊：
1. ACTIVE = 1對應於執行狀態的裝置。
2.DOWN = 2 對應於關閉狀態的裝置。
3. DEPENDENT_UNAVAILABLE = 3 對應於相依裝置>的關閉狀態。
4.ON_HOLD = 4 對應於裝置為非受控時的狀態（如透過「動作」->「非受控」)
5.ON_MAINTENANCE = 5 對應於當裝置是處於process中的停機期間排程的一部分時的狀態
6.PARENT_DOWN = 6 對應於當父級（介面所存在於的裝置）關閉時的介面狀態
7.PARENT_UNMANAGED = 7 對應於當父級（介面所存在於的裝置）為非受控時的介面狀態
在資料庫中，此狀態欄顯示於 ManagedObject 資料庫表格中
轉碼器（編碼器/解碼器）用於編碼語音/視訊資料以便跨 IP 網路傳輸。編解碼器的壓縮能力有助於節省網路頻寬，因此您需要為 IP 網路選取正確的編解碼器、。以下是轉碼器及其相應封包大小和頻寬使用情況的快速參考：
| 轉碼器和位元率 (Kbps) | 操作頻率 | 預設封包數目 | 語音裝載大小 | 頻寬 MP 或 FRF.12 (Kbps) |
頻寬 w/cRTP MP 或 FRF.12 (Kbps) |
頻寬 乙太網路 (Kbps) |
| G.711a/u (64 kbps) |
預設為 60 毫秒。您可以 0 - 604800 範圍內指定 | 1000 | 160 + 12 RTP 位元組 | 82.8 kbps | 67.6 | 87.2 |
| G.729 (8 kbps) |
1000 | 20 + 12 RTP 位元組 | 26.8 kbps | 11.6 | 31.2 |
為了監視兩個位置之間的 VoIP，需要使用 OpManager 指定要監視的連結，即指定源和目標。首先必須在 OpManager 中探索源路由器（啟用了 IP SLA 代理程式的 Cisco 路由器）。只有在 OpManager 中探索該路由器並設定了有效的 SNMO 讀取和寫入社群字串後，您才會看到路由器被列為源裝置，您將可以選取它以便成功新增 VoIP 監視器。
請按照以下步驟在 OpManager 中探索源路由器
1.移至源路由器 telnet 會話並啟用 snmp 讀取和寫入社群。
2.移至「管理員」 -- 「認證設定」 -- 「新增」
輸入在源裝置中啟用的有效讀寫社群。
3.移至「管理員」--「新增裝置」
輸入源裝置的名稱或 IP 位址，選取新增認證，然後按一下「新增裝置」。
4.移至「VoIP 監視器」 -- 「設定」
選取新增的源路由器並繼續進行設定。
透過 vSphere 用戶端連線到該 ESX 主機,並重新整理資料存儲。透過建立 cronjob，您可以實現自動重新整理，每 5/10 分鐘執行一次。OpManager 使用者在我們的論壇中引用了一個很好的解決方法：
1. 使用 SSH 或 Telnet 連線到 ESXi
2. 使用 vi 編輯器在 crontabs 目錄中開啟根檔案：
vi var/spool/cron/crontabs/root
3. 編輯檔案並在其中放入以下行：
*/5 * * * * /bin/vim-cmd /hostsvc/datastore/refresh <your_datastore_name>
4. 儲存檔案
5. 重新啟動 cron 精靈
6. 歡呼吧
現在，您在 <your_datastore_name> 中設定的資料存儲將每 5 分鐘重新整理一次。
嘗試使用「介面啟用/禁用」按鈕開啟和關閉介面時會遇到此訊息（深入到介面級別）。要執行此動作，OpManager 需要為 OpManager 中的裝置啟用寫入社群。無論何時在 OpManager 中啟用或禁用裝置的任何介面，都將使用寫入社群將其寫入路由器或交換器。
因此，請檢查您是否在 OpManager 的裝置上,設定了正確的寫入社群，然後再次嘗試。
嘗試刪除 WAN RTT 監視器時，遇到以下錯誤：
[Exception in:/webclient/common/jsp/PageNavigation.jsp] null
嘗試刪除 WAN RTT 監視器時，Cisco RTT MON MIB 的可能損壞可能會導致此錯誤。
此 MIB 複製到 \OpManager\mibs 資料夾，取代原始檔案，然後重新啟動 OpManager 服務。您現在一定能夠刪除監視器了。
OpManager 只接受具有資料庫所有者和資料庫建立者權限的 SQL 驗證認證。
預設情況下，OpManager 使用以下連接埠來監視裝置。
SNMP-161
SNMP Traps - 162.
WMI - 135 & 445
Telnet - 23
SSH - 22
ICMP ping
32 位元計數器：
Ref mib: RFC-1213-MIB
參考表格：ifraw（未經處理資料）、ifhourlysum（加總每小時收集的未經處理資料並存儲在其中）、ifhourlyrate、ifdailysum、ifdailyrate
輸入流(bps) : InOctets*8*1000/deltatime ()
輸出流量(bps): OutOctets*8*1000/deltatime
每秒輸入封包數: (INUCAST+INDISCARDS+INERRORS+INUNKNOWNPROTOS+INNUCAST)*1000/deltatime
每秒輸出封包數: (OUTUCAST+OUTNUCAST)*1000/(DELTATIME)
輸入位元組數: INOCTETS
輸出位元組數: OUTOCTETS
輸入使用率(%) : (InTraffic/Inspeed)*100 = (InOctets*8*1000*100/deltatime*inspeed)
輸出使用率(%):(OutTraffic/OutSpeed)*100 = (OutOctets*8*1000*100/deltatime*Outspeed)
總使用率(%): (Inutil+outUtil)/2
64 位元計數器：
Ref mib: RFC-1213-MIB,IFMIB
參考表格：ifhcraw（未經處理資料）、ifhchourlysum（加總每小時收集的未經處理資料並存儲在其中）、ifhchourlyrate、ifhcdailysum、ifhcdailyrate
輸入流量 (bps)：: InOctets*8*1000/deltatime
註：我們將輪詢 .1.3.6.1.2.1.31.1.1.1.6.ifIndex 以獲取輸入流量。有時代理程式可能為介面部分實施 64 位元計數器。在此情況下，對 .1.3.6.1.2.1.31.1.1.1.6.ifIndex oid 的查詢將給出零值。此時我們將獲取 32 位元計數器值。我們將查詢 .1.3.6.1.2.1.2.2.1.10.ifIndex
輸出流量 (bps)：: OutOctets*8*1000/deltatime
註：我們將輪詢 .1.3.6.1.2.1.31.1.1.1.10.ifIndex 以獲取流量。有時代理程式可能為介面部分實施 64 位元計數器。在此情況下，對 .1.3.6.1.2.1.31.1.1.1.10.ifIndex oid 的查詢將給出零值。此時我們將獲取 32 位元計數器值。我們將查詢 .1.3.6.1.2.1.2.2.1.16.ifIndex
每秒輸入封包數：(INUCAST+INDISCARDS+INERRORS+INUNKNOWNPROTOS+HCINMCAST+HCINBCAST)*1000/deltatime
每秒輸出封包數：(OUTUCAST+HCOUTMCAST+HCOUTBCAST)*1000/(DELTATIME)
輸入位元組數：INOCTETS
輸出位元組數：OUTOCTETS
In Util(%) :(InTraffic/Inspeed)*100 = (InOctets*8*1000*100/deltatime*inspeed)
輸出使用率 (%)：(OutTraffic/OutSpeed)*100 = (OutOctets*8*1000*100/deltatime*Outspeed)
總使用率 (%)：(Inutil+outUtil)/2
如果資料庫中存在某些問題，則可能會遇到此問題。請嘗試重新啟動 OpManager 並檢查是否有用。如果沒有，則傳送電子郵件支援資訊檔案以供分析。
Opmanager 可能會在 IP 位址中存在點 (.) 時出現此錯誤。如果情況並非如此，請將確切的 IP 和網路遮罩以電子郵件傳送給我們的支援人員以幫助再次生成和解決錯誤。
基於 WMI 的磁碟佇列長度的內建監視器適用於所有磁碟（即「_Total」）。如果您想要其用於特定磁碟，請使用自訂的 WMI 監視器。
效能監視器 - 新增監視器---> WMI 監視器
這將會列出所有可用類別。選取磁碟佇列長度時，您可以將分區看作執行個體。選取分區並新增監視器。請注意，磁碟佇列長度監視器位於基於 WMI 的磁碟監視器下。
這取決於指令碼執行的工作。使用「測試指令碼」選項來確定大致的逾時時間段。如果指令碼執行非常基本的操作，則 10 秒就足夠了。
每次，指令碼內容都寫入磁碟中的檔案，這需要一些時間。監視時間間隔還取決於所關聯的指令碼監視器數量。（雖然我們還沒有確定確切的數字！）。 我們建議您為本機指令碼設定 10 分鐘的監視時間間隔，並為遠端機器上執行的指令碼設定 15 分鐘的監視時間間隔。
查詢範例：
(SELECT al.*,si.ifalias,si.ifcircuitid FROM IntferrorThreshold idt INNER JOIN ManagedObject mo ON idt.id=mo.moid INNER JOIN SNMPInterface si ON mo.name=si.name INNER JOIN Alert al ON al.entity=CONCAT("IF_ERROR_",idt.id))
UNION
(SELECT al.*,si.ifalias,si.ifcircuitid FROM IntfdiscThreshold idt INNER JOIN ManagedObject mo ON idt.id=mo.moid INNER JOIN SNMPInterface si ON mo.name=si.name INNER JOIN Alert al ON al.entity=CONCAT("IF_DISCARD_",idt.id))
這些錯誤是由於資料庫中這些裝置的離散項目來自其之前的探索。這可透過清理相關表格中的項目來解決。以下是執行步驟：
- 將附帶的 Zip 檔案解壓縮到 OpManager 安裝目錄。這將建立一個新資料夾「RemoveDBEntires」，並將 4 個檔案儲存在該資料夾下。
- 使用 IP 位址和裝置名稱執行指令碼 RemoveDBEntries.bat（如果是 Linux，則為 RemoveDBEntries.sh）。在執行指令碼時，請確保伺服器正在執行。該指令碼將從資料庫中刪除部分新增的項目。
- RemoveDBEntries 指令碼接受裝置名稱和 IP 位址作為引數。
cmd> cd [OpManager Home]/RemoveDBEntries
cmd> RemoveDBEntries.bat IPaddress
cmd> RemoveDBEntries.bat <devicename>
範例:
\\OpManager\\RemoveDBEntries>RemoveDBEntries.bat 192.168.12.34
\\OpManager\\RemoveDBEntries>RemoveDBEntries.bat opman.zohocorp.com
該指令碼將從資料庫中刪除部分新增的項目。
- 執行指令碼後，請重新啟動 OpManager 服務並新增裝置。
註：檢視新增的裝置可能需要幾分鐘的時間。
作業系統：Windows 2000 及以上版本 / R.H.Linux 7.2 及以上版本。
附件：用於 V7 及以上版本的 RemoveDBEntries.zip
用於 V6 的 2006_11_8_12_34_26_RemoveDBEntries.zip
用於 OpManager 8030 及以上版本（直至組建編號 8052）的 RemoveDBEntriesNew.zip
用於 OpManager 組建編號 8700 及以上版本的 RemoveDBEntriesNew-8720.zip
備註 1：RemoveDBEntriesNew.zip 僅適用於 OpManager 組建編號 8030 及更高版本（直到組建編號 8052），在解壓縮時，此處的 zip 檔案將建立名為 RemoveDBEntriesNew 而不是 RemoveDBEntries 的資料夾。從 cmd> cd [OpManager Home]/RemoveDBEntriesNew 目錄而不是 cmd> cd [OpManager Home]/RemoveDBEntries 中執行上述步驟。
備註 2：RemoveDBEntriesNew-8720.zip 僅適用於 OpManager 組建編號 8700 及更高版本，在解壓縮時，此處的 zip 檔案將建立名為 RemoveDBEntriesNew 而不是 RemoveDBEntries 的資料夾。從 cmd> cd [OpManager Home]/RemoveDBEntriesNew 目錄而不是 cmd> cd [OpManager Home]/RemoveDBEntries 中執行上述步驟。
附加檔案
2006_11_8_12_34_26_RemoveDBEntries.zip
如果相依 mib 缺失，則可能會發生這種情況。請下載附件，將其放在 OpManager\mibs 資料夾下，然後重試。
管理員->監視時間間隔=>使用 ping 進行裝置可用性監視。按照此處設定的時間間隔執行。
監視特定時間間隔=>僅針對該指標 (WMI/SNMP/CLI) 的資料收集時間間隔。無論裝置可用性監視時間間隔如何，都會按照此處指定的時間間隔和監視級別，監視特定效能參數。
兩者對於整體裝置健康狀況監視都是必需的。
讓我們假設您已經手動將裝置分類到 Windows2008 類別，然後繼續將 Win2008 範本套用至裝置以關聯監視器。由於以下原因，範本無法正確套用：
1.如果您在 Linux 上執行 OpManager，且該範本具有基於 WMI 的監視器。
2.如果您已安裝在 Windows 上，但尚未設定受監視裝置的 WMI 驗證認證（在本例中為 win 2008 裝置）
3.如果裝置具有 SNMP 且您尚未提供該裝置的 SNMP 認證。
設定認證（針對裝置），然後繼續套用範本。
OpManager 有一個內建的 MySQL 和 TOMCAT，需要進行很多變更,才能以非 root 使用者身份執行。所以我們沒有提供此選項。我們所有的 ManageEngine 產品都是如此。
OpManager 具有四種不同的警告嚴重性等級。 已經預定義裝置關閉警告的嚴重性級別（可用性監視）
以下是嚴重性清單以及觸發這些嚴重性警告的事件
1)服務關閉：當服務關閉和 URL 監視器關閉時
2)注意：在某一次可用性輪詢時服務關閉
3)故障：在連續 3 次可用性輪詢時服務關閉
4)危險：在連續 5 次可用性輪詢時服務關閉這是 OpManager 中的最高嚴重性。
5)清除：在任何階段，警告被清除時。
如您所見，基於錯失輪詢次數的服務,關閉警告的嚴重性會自動變更。
與裝置關閉警告類似，也預定義了介面關閉警告嚴重性（故障）。
但對於其他告警，如臨界值違規、Trap和事件記錄檔，使用者可以設定任何嚴重性（注意或故障或危險），即使警告重複，其嚴重性也會相同。
表格詳細資料如下：
OpManager 7 中的效能資料表格分佈相當廣泛，可以提供更好的報告。以下是您製作自訂報告所需表格的即時摘要
1. ElementsAvailabilityHourly - 從此表格獲取每天裝置可用性報表。
2. ElementsAvailabilityDaily - 此表格用於查詢一周的可用性報表。資料每 24 小時封存一次。
3. IfRaw_<date> - 此表格含有介面流量、錯誤、捨棄等資料
4. IfHourly_<date> - 此表格每小時封存一次所有介面資料的值
5. IfDaily_<date> - 此表格每 24 小時候封存一次值
OpManager 在計數超過約 250,000 列後封存上述效能表格。因此，想知道要查詢的表格的日期，請查詢 METATABLE 表格。這將列出所有效能表格。當前效能表格（具有上述名稱的表格）的 ENDTIME 欄位值為 -1。
每個元素/裝置中都是一個受控物件，並具有一個唯一 ID，您可以使用 ManagedObject 表格中的 MOID 欄位擷取該 ID。此 MOID 的值與上表中 ElementID 欄位相同。因此，您可以在這兩個表格之間使用連接來建立自訂報表。
除了上述表格之外，CPU、記憶體等主機資源資料將儲存于以下表格中：
1. Statsdata<current date>: 這存儲當前或未經處理資料。即，和收集時一樣的資料。此表格每 24 小時建立一次。新表格在午夜 12.00 建立。
2. Statsdata_hourly: 每個小時都封存一次值。每小時資料的預設存儲時間為 15 天，最長可設定為 90 天。
3. Statsdata_daily: 每 24 小時封存一次值。每日資料的預設存儲時間段為 1 年，最常可以設定為存儲 10 年。
有關更多資訊，請參考位於 OpManager/conf 資料夾下的 DatabaseSchema.conf