From OpenNMS
Contents |
Introduction
One of the most important tasks involved in keeping openNMS running smoothly is regular maintenance of the events table in the database. This article describes some useful approaches and example SQL queries for keeping the events table in good shape.
Useful Queries
Here are some SQL queries useful in the maintenance of the events table.
Informational
Queries in this section do not make any changes to the database and may be run without fear of damaging the system, although some of them may slow down other database operations while they are running.
Event Histogram
Query:
SELECT eventUEI, COUNT(eventID) AS tally FROM events GROUP BY eventUEI ORDER BY tally DESC LIMIT 10;
Sample output:
eventuei | tally
---------------------------------------------------------+-------
uei.opennms.org/internal/promoteQueueData | 41837
uei.opennms.org/threshold/highThresholdExceeded | 3228
uei.opennms.org/threshold/highThresholdRearmed | 3200
uei.opennms.org/nodes/nodeLostService | 2738
uei.opennms.org/nodes/nodeRegainedService | 2460
uei.opennms.org/internal/authentication/successfulLogin | 1651
uei.opennms.org/internal/capsd/rescanCompleted | 985
uei.opennms.org/nodes/nodeDown | 727
uei.opennms.org/nodes/nodeUp | 652
uei.opennms.org/threshold/lowThresholdExceeded | 359
(10 rows)
What This Query Does
This query might be the single most useful one for getting a quick glance at what your events table looks like. It presents a list, in descending order, of the ten most common types of events in your database.
Interpreting the Results of This Query
If the top event types are remarkably more numerous (by a factor of hundreds or thousands) than any others, then there is a good chance that the PostgreSQL query planner is not performing well due to an artificial skew in the event types present. This situation can lead to poor performance in the web UI, delays in the sending of notifications, and other problems.
Remove unnecessary Events
If the query shows a large number of "uninteresting" events they may be deleted automatically with an entry in vacuumd-configuration.xml:
<statement>
DELETE FROM events
WHERE eventuei='uei.opennms.org/internal/capsd/rescanCompleted'
AND (eventcreatetime < now() - interval '2 days');
</statement>
Be careful, this might take some time depending on the size of the event table. If it leads to performance problems you might choose to submit a batch job at nighttime instead of the entry in vacuumd-configuration.xml to keep the impact small.
Enterprise-Default Event Histogram
Example query:
SELECT
SUBSTRING(eventsnmp FOR POSITION(',' IN eventsnmp) - 1) AS trapOID,
COUNT(eventid) AS tally
FROM events
WHERE eventUEI = 'uei.opennms.org/generic/traps/EnterpriseDefault'
GROUP BY trapOID ORDER BY tally DESC;
Sample output:
trapoid | tally
---------------------------+-------
.1.3.6.1.4.1.1793 | 202
.1.3.6.1.4.1.2036.2.1.4.1 | 53
.1.3.6.1.4.1.7368 | 21
.1.3.6.1.4.1.2036.2.1.4.2 | 16
.1.3.6.1.4.1.2036.2.1.4.3 | 1
(5 rows)
What This Query Does
This query is useful as a follow-on to Event Histogram when the top event types are unformatted events derived from enterprise-specific SNMP traps. It further classifies the unformatted events according to trap-OID of the SNMP trap from which each event was created.
Interpreting the Results of This Query
The string of digits and dots in the trapOID results column is an SNMP object identifier (OID) that identifies the vendor and management information base (MIB) branch associated with the trap. This string should always begin with the sequence .1.3.6.1.4.1, which is shorthand for iso(1).org(3).dod(6).internet(1).private(4).enterprises(1). The seventh number identifies the private enterprise number (PEN) of the vendor whose SNMP agent originated the trap. You can look up private enterprise numbers at IANA. Any digits following the PEN provide additional identifying information specific to the vendor's MIBs.






