### Reason code by trap (info from the trap → reason code)
The reason code is **derived from the trap type** (the trap OID / `snmpTrapOID` that comes in the trap). Netcool does not read a “reason code” varbind; it maps each trap OID to a fixed reason code. Use this table when enriching events (e.g. set reason code in event/incident info from `snmpTrapOID`).
**Note:** Trap OID in the trap is usually `1.3.6.1.4.1.2544.1.14.0.X` (ALM) or `1.3.6.1.4.1.2544.1.15.0.X` (SCALM). Netcool matches `.14.6.X` / `.15.6.X` (same trap number X). Traps not listed (e.g. .14.0.62 authenticationNotification) are not handled in the Netcool rules and are discarded; if you handle them elsewhere, you can assign e.g. **MON.I.FIB.00002** for authenticationNotification to align with auth summary.
- **Deduplicate duplicate receptions:** Same key → update existing event instead of creating a new one.
- **Implement in event rules:** In ServiceNow (or the probe), compute this string from `additional_info` / varbinds and set **message_key** so that event management can deduplicate and correlate correctly.
### Netcool incidents: how this aligns with real incidents
Imported incidents from Netcool (e.g. `incident (business_service.name=FIBER MONITORING NLNL).xml`) show the following:
**What Netcool sends into ServiceNow (per incident):**
- **Node / CI:** Hostname of the trap sender after the Netcool rule (e.g. **INFRAMON-CCAN**, **INFRAMON-N**, **INFRAMON-Z**) — from `@Node` after stripping `.nl.eu.abnamro.com`.
- **Summary / short_description:** The Netcool `@Summary` format, e.g.
- **Alert ID:** Netcool’s own identifier (e.g. **Alert1778303**, **Alert1621700**). One incident corresponds to one Netcool Alert; close_notes reference “Closed the task associated with alert: Alert1778303”.
- **Reason code:**`MON.I.FIB.00001` / `MON.I.FIB.00002` (from the Fiber Guardian rules).
- **Trap type name:** alarmThresCrossedFast, alarmThresCrossedSlow, alarmLinkBudgetExceeded, etc. (from the rule branch).
- **No event log index** is present in the incident — Netcool does not forward that to ServiceNow; it uses its own Alert ID for correlation.
**Conclusion:**
1. **Event (em_event) message_key** — The key **entityName|snmpTrapOID|eventLogIndex** is for **raw trap events**. It uses data that exists in the trap varbinds (and in your test trap). It is the right key for deduplicating **incoming traps** at the event layer. Netcool incidents don’t contain event log index because Netcool correlates by Alert ID internally; that doesn’t change the validity of the message_key for events built from raw traps.
2. **Incident-level correlation** — For **creating or updating incidents** from events (so that “same alarm on same port” maps to one incident), the Netcool data shows the effective uniqueness is **Node + trap type + port (portAidString)**. So a good **incident correlation key** when you don’t have Netcool Alert ID is:
Example: `aab_inframon-ccan|alarmThresCrossedFast|MCH-1-10`. That matches how each Netcool incident is effectively “one alert per node + alarm type + port.” For traps without a port (e.g. authenticationNotification), use Node and trap type only.
3. **Mapping entity to Node** — In traps, “entity” is often the unit name (e.g. MCH-1-1) from the event log varbind; in incidents, “Node” is the hostname (e.g. INFRAMON-CCAN). They can differ (one device may host multiple units). When building incident correlation from raw traps, use the **trap source hostname** (or resolved CI) as Node, and keep **entityName** from the varbind for context in the event; the incident key should use the same Node concept as Netcool (sending host) plus trap type and port when present.
So: the **message_key** we defined is appropriate for **events**; for **incidents**, use **Node|trapTypeName|portAidString** (with port omitted when not applicable) to mirror Netcool’s one-incident-per-alert-per-port behavior.
---
## 5. Cross-reference: ServiceNow vs Netcool vs MIB
gitea
1 week ago