By default traps are received by the Trap-Receiver that runs in the Event-Processing-Manager for Alert-Consolidation, the traps are then sent to Event-Log-Processor and go trough the configurations in the rules directory to get parsed and formatted into SRM events. You will probably need to create a custom rule for the source of the events that you want to add. You can look at the existing rules for examples and refer to the APG-Event-Log-Processor.pdf for more details on functionality.
I'm very close to success now, after configure I can see my trap listed in "processing-0-18.log", but while use filter "*" to print out it to log file, I still see: "PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype',DURABLE,PROP.'severity',PROP.'severity',PROP.'value'"
May I know why it is not converted?
Another question, may I know the rule to filter out trap event from report, which attribute and keyword should be used?
The PROP. cant be translated as traps do not contain these properties; these properties are are only available for time series (metrics that we can poll at a regular interval and graph). Events such as traps have their own set of properties; you can look at the "Alert consolidation notification trap" alert (right click from the "Alerts definition" list and choose edit) for a listing of properties.
For reporting on events we different properties such as severity, source and variable; variable is a database name so that we automatically exclude all time series data and only display events. You can look at the reports under the All>>Operations>>Alerts branch for examples.
I copied the "Trap Content" definition from "Alert Consolidation Trap Notification", this also not work.
I can see trap info in "processing-*-*.log", but both "eventSource is ImpactAnalysis-GenericEvent" and "eventSource is not ImpactAnalysis-GenericEvent" cannot filter it out. As my understanding, when trap arrive, it will be converted according to the XML under "Event-Processing\Trap-Receiver\Default\conf\rules", then goto "alert definitions" to trigger action.
May I know how to check which step get problem, then debug the root cause?
I tried change the SNMP community string to wrong one, "processing-*-*.log" still show the trap message at INFO log level, so I believe this only mean trap is received, but not really converted to event.
Without seeing the full logs it is hard to say what's going on. It does look like the event processing manager is receiving traps and the issue could be that it is not being converted correctly by the rules.
At this point it would probably be a good idea to open a case with support.
isakats
141 Posts
2043
0
Posted March 23rd, 2017 06:00
Hi Jianping.Wang,
By default traps are received by the Trap-Receiver that runs in the Event-Processing-Manager for Alert-Consolidation, the traps are then sent to Event-Log-Processor and go trough the configurations in the rules directory to get parsed and formatted into SRM events. You will probably need to create a custom rule for the source of the events that you want to add. You can look at the existing rules for examples and refer to the APG-Event-Log-Processor.pdf for more details on functionality.
hth,
Regards,
Isaka