SNMP MIB notifications

Itential Platform supports SNMP (Simple Network Management Protocol) notifications to integrate with enterprise monitoring and management systems.

SNMP MIB files

Platform includes SNMP MIB (Management Information Base) files that define available notification types and their structures.

MIB file locations

Platform 2023.2 and earlier:

$/opt/pronghorn/current/node_modules/@itential/pronghorn-core/core/mibs/

Platform 6:

$/opt/itential/platform/server/core/mibs/

Available MIB files

$$ cd /opt/itential/platform/server/core/mibs/
$$ ls -l
$-rw-r--r-- 1 itential itential 9252 Feb 15 12:39 ITENTIAL-MIB.txt
$-rw-r--r-- 1 itential itential 1490 Feb 15 12:13 ITENTIAL-SMI-MIB.txt

ITENTIAL-SMI-MIB.txt:

  • Structure of Management Information (SMI) definitions
  • Defines the Itential enterprise OID namespace
  • Root OID: 1.3.6.1.4.1.47688

ITENTIAL-MIB.txt:

  • Notification types and their associated variables
  • Object definitions for trap payloads
  • Severity levels and descriptions

Notification types

Platform sends SNMP notifications (traps) for critical system events, adapter status changes, and application lifecycle events.

System notifications

NotificationOIDDescription
itenProngSystemRestart1.3.6.1.4.1.47688.1.1.1.0.4Platform has restarted
itenProngSysErr1.3.6.1.4.1.47688.1.1.1.0.5Critical error encountered by Platform

Use cases:

  • Alert operations team when Platform restarts unexpectedly
  • Capture critical system errors for root cause analysis
  • Trigger automated remediation workflows
  • Track Platform availability metrics

Application notifications

NotificationOIDDescription
itenProngAppUp1.3.6.1.4.1.47688.1.1.1.0.6Application is online
itenProngAppDown1.3.6.1.4.1.47688.1.1.1.0.7Application is offline
itenProngAppCrash1.3.6.1.4.1.47688.1.1.1.0.8Application crashed unexpectedly

Use cases:

  • Monitor critical application health (Workflow Engine, Operations Manager)
  • Alert when applications become unavailable
  • Track application stability metrics
  • Investigate crash patterns and root causes

Adapter notifications

NotificationOIDDescription
itenSBAdapterUnreach1.3.6.1.4.1.47688.1.1.1.0.1Adapter connection failed
itenSBAdapterEstab1.3.6.1.4.1.47688.1.1.1.0.2Adapter connection established
itenSBAdapterFuncErr1.3.6.1.4.1.47688.1.1.1.0.3Adapter functional error occurred
itenSBAdapterDegraded1.3.6.1.4.1.47688.1.1.1.0.9Adapter connection degraded
itenSBAdapterFixed1.3.6.1.4.1.47688.1.1.1.0.10Adapter connection no longer degraded

Use cases:

  • Alert when adapters cannot reach downstream systems
  • Monitor adapter health and connection stability
  • Track degraded connection states
  • Trigger remediation when adapters fail

Notification objects

Notifications include variable bindings that provide detailed context about the event.

Object definitions

ObjectOIDTypeDescription
itenProngComponentID1.3.6.1.4.1.47688.1.1.2.1StringUnique identifier for application or adapter
itenProngAdapterIP41.3.6.1.4.1.47688.1.1.2.2IPv4 AddressIP address of the adapter instance
itenProngAdapterPort1.3.6.1.4.1.47688.1.1.2.3IntegerPort number of the adapter instance
itenProngAdapterFunction1.3.6.1.4.1.47688.1.1.2.4StringAdapter function/method that encountered error
itenProngAdapterError1.3.6.1.4.1.47688.1.1.2.5StringError message or description
itenProngSystemError1.3.6.1.4.1.47688.1.1.2.6StringSystem error description

Notification payloads

Each notification type includes specific variable bindings:

itenSBAdapterUnreach:

  • itenProngComponentID - Adapter identifier (e.g., “nso-adapter-prod”)
  • itenProngAdapterIP4 - Target IP address (e.g., “10.1.2.3”)
  • itenProngAdapterPort - Target port (e.g., 8888)

itenSBAdapterEstab:

  • itenProngComponentID - Adapter identifier
  • itenProngAdapterIP4 - Target IP address
  • itenProngAdapterPort - Target port

itenSBAdapterFuncErr:

  • itenProngComponentID - Adapter identifier
  • itenProngAdapterFunction - Function name (e.g., “getDeviceConfig”)
  • itenProngAdapterError - Error text (e.g., “Connection timeout”)

itenProngSystemRestart:

  • No additional objects (notification only)

itenProngSysErr:

  • itenProngSystemError - Error description

itenProngAppUp:

  • itenProngComponentID - Application identifier

itenProngAppDown:

  • itenProngComponentID - Application identifier

itenProngAppCrash:

  • itenProngComponentID - Application identifier

itenSBAdapterDegraded:

  • itenProngComponentID - Adapter identifier
  • itenProngAdapterIP4 - Target IP address
  • itenProngAdapterPort - Target port

itenSBAdapterFixed:

  • itenProngComponentID - Adapter identifier
  • itenProngAdapterIP4 - Target IP address
  • itenProngAdapterPort - Target port

Configure SNMP notifications

SNMP notification destinations are configured in the Platform profile or properties file.

Platform 6 configuration

Environment variable (single destination):

$export ITENTIAL_SNMP_ALARM_CONFIGS='[{"host":"nms.example.com","port":162,"community":"public"}]'

Properties file:

1# Single SNMP destination
2snmp_alarm_configs=[{"host":"nms.example.com","port":162,"community":"public"}]

Multiple destinations:

$export ITENTIAL_SNMP_ALARM_CONFIGS='[
> {"host":"nms1.example.com","port":162,"community":"platform-prod"},
> {"host":"nms2.example.com","port":162,"community":"platform-prod"},
> {"host":"backup-nms.example.com","port":162,"community":"platform-backup"}
>]'

Platform 2023.2 configuration

Navigate to Admin Essentials > Profiles and edit the active profile.

Add or modify the snmpProps section:

1{
2 "snmpProps": {
3 "alarms": [
4 {
5 "host": "nms.example.com",
6 "port": 162,
7 "community": "platform-prod"
8 },
9 {
10 "host": "backup-nms.example.com",
11 "port": 162,
12 "community": "platform-backup"
13 }
14 ]
15 }
16}

Configuration parameters

ParameterTypeRequiredDescription
hoststringYesHostname or IP address of SNMP manager/trap receiver
portintegerYesUDP port for SNMP traps (typically 162)
communitystringYesSNMP community string for authentication

Integrate with monitoring systems

Load MIB files

Import Itential MIB files into your SNMP management system.

SolarWinds Network Performance Monitor:

  1. Copy MIB files to C:\ProgramData\SolarWinds\MIBs\
  2. Run MIB Browser and import ITENTIAL-SMI-MIB.txt and ITENTIAL-MIB.txt
  3. Configure trap receivers to accept traps from Platform servers

Cisco Prime Infrastructure:

  1. Navigate to Administration > Settings > MIB Management
  2. Upload ITENTIAL-SMI-MIB.txt and ITENTIAL-MIB.txt
  3. Configure trap destinations in SNMP settings

PRTG Network Monitor:

  1. Copy MIB files to C:\Program Files (x86)\PRTG Network Monitor\snmplibs\
  2. Create SNMP Trap Receiver sensor
  3. Configure trap rules based on Itential OIDs

Nagios:

  1. Place MIB files in /usr/share/snmp/mibs/
  2. Configure SNMPTRAPD to accept traps
  3. Create SNMPTT configuration for Itential traps
  4. Map trap OIDs to Nagios alerts

Example monitoring rules

Critical alert - Application crash:

Trap OID: 1.3.6.1.4.1.47688.1.1.1.0.8 (itenProngAppCrash)
Severity: Critical
Action: Page on-call engineer, create incident ticket

Warning alert - Adapter degraded:

Trap OID: 1.3.6.1.4.1.47688.1.1.1.0.9 (itenSBAdapterDegraded)
Severity: Warning
Action: Email operations team, monitor for recovery

Informational - System restart:

Trap OID: 1.3.6.1.4.1.47688.1.1.1.0.4 (itenProngSystemRestart)
Severity: Informational
Action: Log event, check for unexpected restarts

Verify SNMP configuration

Test SNMP connectivity

From Platform server:

$# Test trap sending (requires net-snmp-utils)
$snmptrap -v 2c -c platform-prod nms.example.com:162 '' \
> 1.3.6.1.4.1.47688.1.1.1.0.4 \
> 1.3.6.1.4.1.47688.1.1.2.1 s "test-adapter"

From SNMP manager:

$# Listen for traps (on SNMP manager)
$snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf

Monitor Platform logs

Check Platform logs for SNMP trap sending:

$grep -i "snmp\|trap" /var/log/itential/pronghorn.log

Example log entries:

[INFO] SNMP trap sent: itenSBAdapterUnreach, adapter=nso-adapter-prod, ip=10.1.2.3, port=8888
[DEBUG] SNMP destination: nms.example.com:162, community=platform-prod

Trigger test notifications

Force Platform to generate test notifications:

Application restart:

$# Restart a service to generate app up/down notifications
$systemctl restart itential-workflow-engine

Adapter connection failure:

Temporarily block adapter connectivity to generate unreachable notification:

$# Block adapter port temporarily
$iptables -A OUTPUT -p tcp --dport 8888 -j DROP
$
$# Wait for adapter to detect failure (check adapter logs)
$
$# Restore connectivity
$iptables -D OUTPUT -p tcp --dport 8888 -j DROP

Troubleshooting

Traps not received

Verify SNMP configuration:

$# Platform 6
$env | grep ITENTIAL_SNMP
$
$# Platform 2023.2
$mongosh --eval "db.iap_profiles.findOne({_id: 'profile-id'}, {snmpProps: 1})"

Check network connectivity:

$# Test UDP connectivity to SNMP manager
$nc -u nms.example.com 162 < /dev/null
$
$# Check firewall rules
$iptables -L -n | grep 162

Verify SNMP manager listening:

$# On SNMP manager, check trap receiver is running
$netstat -uln | grep 162

Incorrect trap data

Verify MIB files loaded:

Ensure monitoring system has latest Itential MIB files loaded.

Check OID resolution:

$# Translate OID to name
$snmptranslate -m +ITENTIAL-MIB 1.3.6.1.4.1.47688.1.1.1.0.4
$# Should output: ITENTIAL-MIB::itenProngSystemRestart

High trap volume

Filter traps:

Configure monitoring system to filter or rate-limit expected notifications:

  • Application restart notifications during maintenance windows
  • Adapter connection flapping during network issues
  • Degraded state oscillations

Adjust adapter health check intervals:

Reduce health check frequency to decrease trap volume:

1service_health_check_interval=60

Best practices

Configuration

  • Use unique community strings per environment (dev, test, prod)
  • Configure multiple SNMP destinations for redundancy
  • Document trap handling procedures for operations team
  • Test SNMP configuration in non-production first
  • Restart Platform after SNMP configuration changes

Monitoring

  • Create monitoring rules for all critical notification types
  • Set appropriate severity levels per notification type
  • Correlate SNMP traps with Platform logs
  • Implement automated remediation for common issues
  • Regularly review trap patterns and volumes

Security

  • Use SNMPv3 with authentication and encryption (if supported)
  • Restrict SNMP trap traffic with firewall rules
  • Use non-default community strings
  • Rotate community strings regularly
  • Monitor for unauthorized SNMP trap sources

Operations

  • Load Itential MIB files into all monitoring systems
  • Create runbooks for common SNMP notifications
  • Configure escalation policies for critical traps
  • Archive trap data for trend analysis
  • Review trap configuration after Platform upgrades

Additional resources

Next steps