Page History
Wiki Markup
The following symptoms in the Uptime Infrastructure Monitor MIBBrowser are signs that there is an issue with the order that custom MIBs are being loaded from the <uptime_dir>/mibs/ directory: \\
- MIB
...
- Tree
...
- is
...
- not
...
- fully
...
- populated
...
- compared
...
- to the iReasoning MIB Browser.
- Invalid OID errors received when trying to select an OID from the MIB itself.
To verify that this is the issue (and to identify the offending MIB), look in the thirdparty.log file located in the the [<span style="color: #0052cc">iReasoning MIB Browser</span>|http://ireasoning.com/mibbrowser.shtml]. Invalid OID errors received when trying to select an OID from the MIB itself. \\ To verify that this is the issue (and to identify the offending MIB), look in the *thirdparty.log* file located in the <uptime_dir>/logs directory and look for errors such as: \\ _2012
| Code Block | ||
|---|---|---|
| ||
2021-06-11 |
...
|
...
11:35:21,833 |
...
|
...
ERROR |
...
|
...
[Webserver-32 |
...
|
...
- |
...
|
...
/uptime/snmp/getMibTree |
...
] |
...
|
...
(Log4jImpl:36) |
...
|
...
- |
...
|
...
MIB |
...
|
...
loaded |
...
|
...
from |
...
|
...
reader |
...
|
...
contains |
...
|
...
unknown |
...
|
...
mib imports: ibDHCPOne. |
...
|
...
The corresponding MIB needs to be loaded beforehand or it should be in the same directory as current MIB |
...
|
...
2021-06-11 |
...
|
...
11:35:21,852 |
...
|
...
ERROR |
...
|
...
[Webserver-32 |
...
|
...
- |
...
|
...
/uptime/snmp/getMibTree |
...
] |
...
|
...
(Log4jImpl:36) |
...
|
...
- |
...
|
...
MIB |
...
|
...
loaded |
...
|
...
from |
...
|
...
reader |
...
|
...
contains |
...
|
...
unknown |
...
|
...
mib imports: ibDHCPServ. |
_ The sample errors listed above indicate that the ibDCHPOne & ibDHCPServ MIBs MIBs failed to load because they were missing some of their imports. !worddav48b349cb6b49ea9a5426b008b97e0c8e.png|height=16,width=16! <span style="color: #333333"><strong>Info</strong></span> <span style="color: #333333">You may see some warnings in the thirdparty.log file similar to the messages below but these are not cause for concern:</span> <span style="color: #333333"><em>2012-06-12</em></span> <span style="color: #333333"><em>14:35:35,699</em></span> <span style="color: #333333"><em>ERROR</em></span> <span style="color: #333333"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="65a6ecc5-29b5-450d-b196-d701b845129a"><ac:plain-text-body><![CDATA[_\[Webserver-23_imports.
| Info |
|---|
You may see some warnings in the thirdparty.log file similar to the messages below but these are not cause for concern: 2021-06-12 14:35:35,699 ERROR [Webserver-23 - /uptime/snmp/getMibTree] (Log4jImpl:36) - Unknown snmp data type: |
...
[APPLICATION. |
...
|
\\ \\ To resolve the errors ({_}MIB _ _ loaded _ _ from _ _ reader _ _ contains _ _ unknown _ _ mib _ _ imports{_}), open the MIB that failed to load from the <uptime_dir>/mibs/ directory and look at the imports section near the top. For For example, from the ibDHCPOne sample in the error above: \\ IMPORTS OBJECT
IMPORTS OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, enterprises FROM SNMPv2-SMI TEXTUAL TEXTUAL-CONVENTION FROM SNMPv2-TC Counter64 Counter64, Unsigned32 FROM SNMPv2-SMI Counter Counter FROM RFC1155-SMI ibDHCPOne ibDHCPOne, IbString, IbIpAddr FROM IB-SMI-MIB;
\\ In this example, IB-SMI-MIB is a non-bundled MIB and the source of the import issues because it was not properly loaded before the ibDHCPOne tried to import values from it.
Now that we have identified which MIB contains the missing import values, we need to re-name the file in the <uptime_dir>/mibs/ directory so that Uptime Infrastructure Monitor UIM will load that one before the others. The The MIB files are loaded in alphanumeric order (i.e. 0 - 9 then A - Z then a - z). So So, using the examples above, they were originally named:
IB-DHCPONE-MIB.mibIB-SMI-MIB.mib
\\ Re-named to: \\
03000-IB-SMI-MIB.mib03001-IB-DHCPONE-MIB.mib
\\ After re-naming the files, restart the uptime_core/data collector services on the monitoring station, which will cause Uptime Infrastructure Monitor to clear it's cached MIBs from memory. Then Then set up a new SNMP Poller monitor, and click the Add OID button, which will reload the MIBs into memory in the new order. Once Once these are loaded into memory again, you should also now be able to fully drill down to the OID in question in the MIB browser. Checking Checking the thirdparty.log file again should also no longer have errors about missing imports for the MIB.]]>