Skip to main content

InterSystems IRIS MIB Structure

InterSystems IRIS MIB Structure

All of the managed object data available through the InterSystems IRIS SNMP interface is defined in the InterSystems IRIS MIB file, ISC-IRIS.mib, which is located in the install-dir\SNMP directory. Typically an SNMP management application must load the MIB file for the managed application to understand and appropriately display the information. Since this procedure varies among applications, consult your management application documentation for the appropriate way to load the InterSystems IRIS MIB.

The specific data defined in the InterSystems IRIS MIB is documented in the file itself and, therefore, is not repeated here. However, it may be valuable to understand the overall structure of the InterSystems IRIS MIB tree, especially as it relates to multiple instances on the same system.

Note:

The best way to view the MIB tree is to load the MIB into a management application or MIB browser. These tools display the MIB as a tree with object IDs (OIDs), matching text representations of the objects, and descriptions of the objects.

SNMP defines the Structure of Management Information (SMI), a specific, hierarchical tree structure for all managed objects, which is detailed in RFC 1155Opens in a new tab. Each managed object is named by a unique object identifier (OID), which is written as a sequence of integers separated by periods, for example: 1.3.6.1.2.1.1.1. The MIB translates this dotted integer identifier into a text name.

The standard SNMP MIB defines many standard managed objects. To define application-specific extensions to the standard MIB, as InterSystems IRIS does, an application uses the enterprise branch which is defined as:

iso.org.dod.internet.private.enterprises (1.3.6.1.4.1)

The Internet Assigned Numbers Authority (IANA) assigns each organization a private enterprise number as the next level in the hierarchy. For InterSystems IRIS this is 16563, which represents intersystems.

Below this, InterSystems IRIS implements its enterprise private subtree as follows:

  • The level below intersystems is the “product” or application ID level. For InterSystems IRIS this is .4 (iscIris). This serves as the MIB module identity.

  • The next level is the “object” level, which separates data objects from notifications. For InterSystems IRIS, these are .1 (irisObjects) and .2 (irisTraps). By convention, the intersystems tree uses a brief lowercase prefix added to all data objects and notification names. For InterSystems IRIS this is iris.

  • The next level is the “table” or group level. All data objects are organized into tables, even if there is only one instance or “row” to the table. This serves to organize the management data objects into groups. This is also necessary to support multiple InterSystems IRIS instances on one machine. All tables use the InterSystems IRIS instance name as the first index of the table. The tables may also have one or more additional indexes.

  • The next level, which is always .1, is the “conceptual row” for the table (as required by the SNMP SMI).

  • Finally, the individual data objects contained in that table, including any that are designated as indexes.

  • The notifications (traps) are defined as individual entries at the same hierarchical level as the “table”. For more information, see InterSystems IRIS SNMP Traps.

  • InterSystems IRIS-specific auxiliary objects sent via notifications (traps) are defined as individual entries at the same hierarchical level as the “table”. For more information, see InterSystems IRIS SNMP Traps.

For example, encode the size of a database as:

1.3.6.1.4.1.16563.4.1.3.1.6.4.84.69.83.84.1

This translates to:

iso.org.dod.internet.private.enterprises.intersystems.isciris.irisObjects
irisDBTab.irisDBRow.irisDBSize.TEST(instname).1(DBindex)

Extending the InterSystems IRIS MIB

Application programmers can add managed object definitions and extend the MIB for which the InterSystems IRIS subagent provides data. This is not intended to be a complete MIB editor or SNMP toolkit; rather, it is a way to add simple application metrics that you can browse or query through SNMP.

Note:

The objects must follow the basic InterSystems IRIS SNMP structure, there is limited support for SNMP table structures (only integer-valued indexes are supported), and SNMP traps are not created (see the %Monitor.AlertOpens in a new tab class). A basic understanding of SNMP structure of management information is helpful.

To create these objects do the following:

  1. Create InterSystems IRIS object definitions in classes that inherit from the %Monitor.AdaptorOpens in a new tab class. See the InterSystems Class Reference for details about adding managed objects to the %Monitor package.

  2. Execute an SNMP class method to enable these managed objects in SNMP and create a MIB definition file for management applications to use. The method to accomplish this is MonitorTools.SNMP.CreateMIB().

See the MonitorTools.SNMPOpens in a new tab class documentation for details of the CreateMIB() method parameters.

The method creates a branch of the private enterprise MIB tree for a specific application defined in the %Monitor database. In addition to creating the actual MIB file for the application, the method also creates an internal outline of the MIB tree. The InterSystems IRIS subagent uses this to register the MIB subtree, walk the tree for GETNEXT requests, and reference specific objects methods for gathering the instance data in GET requests.

All the managed object definitions use the same general organization as the InterSystems IRIS enterprise MIB tree, that is: application.objects.table.row.item.indices. The first index for all tables is the InterSystems IRIS application ID. All applications must register with the IANA to obtain their own private enterprise number, which is one of the parameters in the CreateMIB() method.

To disable the application in SNMP, use the MonitorTools.SNMP.DeleteMIB() method. This deletes the internal outline of the application MIB, so the InterSystems IRIS subagent no longer registers or answers requests for that private enterprise MIB subtree.

For an example of defining a user Monitor class, see Sample User-Defined SNMP Monitor Class.

InterSystems IRIS SNMP Traps

In addition to the object data and metrics available through SNMP queries, InterSystems IRIS can send asynchronous alerts or SNMP traps. The following table describes the InterSystems IRIS-specific SNMP traps.

InterSystems IRIS SNMP Notification Objects (Traps)
Trap Name (Number) Description
irisStart (1) The InterSystems IRIS instance has been started.
irisStop (2) The InterSystems IRIS instance is in the process of shutting down.
irisDBExpand (3) An InterSystems IRIS database has expanded successfully.
irisDBOutOfSpace (4) Future expansion of an InterSystems IRIS database may be limited; there is not enough free space on the file system for 10 more expansions or there is less than 50 MB of free space.
irisDBStatusChange (5) The read/write status of an InterSystems IRIS database has been changed.
irisDBWriteFail (6) A write to an InterSystems IRIS database has failed. It includes the InterSystems IRIS error code for the failed write.
irisWDStop (7) The write daemon for an InterSystems IRIS instance has stalled.
irisWDPanic (8) The write daemon for an InterSystems IRIS instance has entered “panic” mode; that is, the write daemon is out of buffers and must write database blocks directly to disk without first committing them to the Write Image Journal (WIJ) file.
irisLockTableFull (9) The lock table for an InterSystems IRIS instance is full, which causes subsequent Locks to fail.
irisProcessFail (10) A process has exited InterSystems IRIS abnormally (due to an access violation). For detailed information, see the messages.log file.
irisECPTroubleDSrv (11) A connection to this ECP Data Server for an InterSystems IRIS database has encountered a serious communication problem. For detailed information, see the messages.log file.
irisECPTroubleASrv (12) A connection from this ECP Application Server to a remote InterSystems IRIS database has encountered a serious communication problem. For detailed information, see the messages.log file.
irisAuditLost (13) InterSystems IRIS has failed to record an Audit event. The most likely cause is a problem with space for the Audit database, which requires operator assistance.
irisLoggedError (14) A “severe ” error has been logged in the messages.log file. This trap includes the error message defined in irisSysErrorMsg.
irisLicenseExceed (15) A request for a license has exceeded the number of licenses currently available or allowed.
irisEventLogPost (16) An entry posted in the Interoperability Event Log.
irisAppAlert (100) This is a generic trap that can be used by InterSystems IRIS applications to generate alerts via SNMP. For detailed information about how this trap can be used, see the %Monitor.Alert.External class method.

The following table describes the InterSystems IRIS-specific auxiliary objects that can be sent in the traps described in the preceding table.

InterSystems IRIS-specific Auxiliary Objects Sent in Traps
Auxiliary Object Name (Number) Description
irisDBWriteError (1) The InterSystems IRIS-specific error code for a failed database write. Possible values are: <DATABASE>, <DISKHARD>, <BLOCKNUMBER>, <FILEFULL> or <DATABASE MAP LABEL>.
irisApp (2) A short text string (maximum of 20 characters) that identifies the application that generated (or was the source of) an irisAppAlert trap.
irisAppSeverity (3) A code that indicates the severity of the problem for a irisAppAlert trap. The code can be 0 (info), 1 (warning), 2 (severe), or 3 (fatal).
irisApptext (4) A text string description (maximum of 1024 characters) of the problem, error, or event that caused the irisAppAlert trap.
FeedbackOpens in a new tab