During one of my last customer assignments, I migrated the NetEye Event Handler Trap rules to Tornado. Since many customers use the event handler in a similar way, I’d like to explain here the creation of these rules in Tornado. In the following I’ll briefly explain the following use case:
Passive service checks have been created in NetEye, which should change the status through incoming traps.
We’ll now implement this functionality through the use of Tornado. In the following picture you’ll see the various definitions which I’m going to configure.
1st Step
I created a general filter called snmptrap, which matches all incoming SNMP traps. Usually I define the following filter:
{
"type": "AND",
"operators":
[
{
"type": "equals",
"first": "${event.type}",
"second": "snmptrapd"
}
]
}
2nd Step
Now I just create a “rule set” for this snmptrap filter by clicking on “Add rule set”. Several rules can be stored in a rule set.
As you can see in this screenshot, I’ve created several rules.
The first archive_all rule writes all incoming traps in JSON format to a log file, which can be defined in the file /neteye/share/tornado/conf/archive_executor.toml. If nothing is defined, all logs are written to the file /neteye/shared/tornado/data/archive/all/one_events.log.
In this rule only the following action needs to be defined:
[
{
"id": "archive",
"payload": {
"archive_type": "snmptrapd",
"event": "${event}",
"hostname": "${event.payload.src_ip}"
}
}
]
3rd Step
I created a rule so that the following filters are only executed for two specific IPs.
This rule is called filter_rapidcore_ip, and I defined theWHERE condition below. Since the following rule is a “negation”, “Continue after” must be deactivated in the property of the rule.
{
"type": "NOT",
"operator": {
"type": "regex",
"regex": "10.10.30.15|10.10.30.10",
"target": "${event.payload.src_ip}"
}
}
4th Step
The following rules change the passive service check status, so I’m making an example rule.
The passive service Hardware_Alert on the host with one of the IPs (10.10.30.15 | 10.10.30.10) should be set to CRITICAL as soon as one of the following is found in the TRAP for the OID “SNMPv2-MIB :: sysDescr.0.content” Elements “. * Test Event. * |. * Device Failed. * |. * Failed. * |. * RaidSet Degraded. * |. * DRAM. * |. * Over Temperature. * |. * Fan Failed. * |. * Lost Rebuilding. * “.
The definition of the rule follows:
WHERE Definition:
{
"type": "AND",
"operators": [
{
"type": "regex",
"regex": ".Test Event.|.Device Failed.|.Failed.|.RaidSet Degraded.|.DRAM.|.Over Temperature.|.Fan Failed.|.Lost Rebuilding.",
"target": "${event.payload.oids.\"SNMPv2-MIB::sysDescr.0\".content}"
}
]
}
ACTION Definition:
[
{
"id": "icinga2",
"payload": {
"icinga2_action_name": "process-check-result",
"icinga2_action_payload": {
"exit_status": "2",
"filter": "service.name==\"Hardware_Alert\" && host.address == \"${event.payload.src_ip}\"",
"plugin_output": "CRITICAL - ${event.payload.oids.\"SNMPv2-MIB::sysDescr.0\".content}",
"type": "Service"
}
}
}
]
For further traps, additional rules can be created by changing the description in the 4th step for the requirements that arise.
Tobias Goller
NetEye Solution Architect at Würth Phoenix
I started my professional career as a system administrator.
Over the years, my area of responsibility changed from administrative work to the architectural planning of systems.
During my activities at Würth Phoenix, the focus of my area of responsibility changed to the installation and consulting of the IT system management solution WÜRTHPHOENIX NetEye.
In the meantime, I take care of the implementation and planning of customer projects in the area of our unified monitoring solution.
Author
Latest posts by Tobias Goller
25. 10. 2024
Log-SIEM
Enhancing Cybersecurity with Elastic Defend: A Technical Consultant’s Perspective
28. 08. 2024
Unified Monitoring
ntopng Updates
06. 05. 2024
Unified Monitoring
QUIC, What’s That?
05. 03. 2024
Unified Monitoring
nBox Mini