Nms-trapReceiver: Difference between revisions

From I Will Fear No Evil
Jump to navigation Jump to search
No edit summary
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 22: Line 22:
# using an eval (shudder) do our pre-processing now before inserting into the database
# using an eval (shudder) do our pre-processing now before inserting into the database
# insert event into the database
# insert event into the database
# Do any postprocessing now (should not be any TBH)
# Do any post-processing now (should not be any TBH)
# Dump our vars to stdout
# Dump our vars to stdout and syslog


[[Category:NMS]]
 
==Version: 2 follows the rules of the daemons and calls the API for information it needs in working with a trap==
* This has been rewritten, and is now following the normal rule of NEVER talking to the database.
* Functional and stable
* The main functionality is the same
* Pulls API configs from the same file as the daemons
* Uses straight curl class to talk to the API
* independent logging so traps can be better debugged
* Allows for multiple receivers in different networks (poor mans bridge is possible since only 1 port needs opened or filtered)
 
 
[[Category:NMS]][[Category:PHP]]

Latest revision as of 19:07, 17 February 2024

This script: trapReceiver.php is not part of the API spec, and is however part of the overall system. This is what snmptrapd calls for all inbound SNMP events.

Specifically note the absolute path to the php script. Also it is a good idea to pass the path to the php binary itself as well since snmptrapd does not build a full environment.

cat /etc/snmp/snmptrapd.conf | grep -v '^#'
snmpTrapdAddr :162
traphandle .1.* php /opt/nmsApi/traps/trapReceiver.php
disableAuthorization yes

The trap reciever itself is kind of brainless.

  1. receive event
  2. connect to database
  3. begin setting defaults and datestamps
  4. iterate over trap oids and start filtering and building arrays
  5. sanitize the arrays
  6. reindex the arrays so there are no gaps
  7. JSON encode the array
  8. Search for existing database hostname that matches our event
  9. Map our raw oid values to pretty names
  10. using an eval (shudder) do our pre-processing now before inserting into the database
  11. insert event into the database
  12. Do any post-processing now (should not be any TBH)
  13. Dump our vars to stdout and syslog


Version: 2 follows the rules of the daemons and calls the API for information it needs in working with a trap

  • This has been rewritten, and is now following the normal rule of NEVER talking to the database.
  • Functional and stable
  • The main functionality is the same
  • Pulls API configs from the same file as the daemons
  • Uses straight curl class to talk to the API
  • independent logging so traps can be better debugged
  • Allows for multiple receivers in different networks (poor mans bridge is possible since only 1 port needs opened or filtered)