Forum Discussion
smp_86112
Cirrostratus
CirrostratusCustom SNMP Traps - clarify "match string" usage
Reference the article posted by deb a few days ago:
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=256
After reading this article, I'm still a bit confused on how the "match string" is used. The way I understand this process is syslog-ng sends a message with an alert code. Alertd receives that code and maps it to an alert definition in /var/tmpfs/run/bigip_error_maps.dat. Then it performs the action in /config/user_alert.conf based on the definition.
If my understanding is accurate...I have a couple of questions:
1) If alertd relies on the alert code from syslog-ng and not the match string, can someone please clarify the role of the match string? For example, using deb's article, why would I create a definition like this:
alert BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS_SERVERX "Pool member 10.0.0.154:80 monitor status (.*?)." {
snmptrap OID=".1.3.6.1.4.1.3375.1.1.110.200"
}
and not this (without the match string):
alert BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS_SERVERX {
snmptrap OID=".1.3.6.1.4.1.3375.1.1.110.200"
}
2) Is it possible to customize the message string sent by an alert?
5 Replies
- The alert code is used to find a match string that is maintained in the bigip_error_maps.dat file. This is the method used by F5 development to maintain most of the alert match strings to build the running configuration @ runtime using the background process described in the article.
Alternatively, the match string may be specified in the alert.conf or user_alert.conf file. When creating custom traps, you will not create an error map, rather you will always define the match string in the user_alert.conf file.
The system receives both alert code and message, and attempts to match against the running alertd configuration, which includes both definitions, and will trigger the alert action for all definitions that match. (I clarified the beginning of the article, thanks for the feedback.)
Syslog-ng passes along the message string it received unmodified, and there is no way to customize the message.
Does that help?
/d 
smp_86112I'm still not sure I have this right. Let me restate to confirm.
alertd receives a message from syslog-ng which contains both an alert code and a message string. alertd looks in bigip_error_maps.dat to find an alert definition which matches the alert code or message string. Once a map is found, it performs the action matching the definition in the user_alert.conf (or alertd.conf).
Is that right?
If it is, then I still don't understand why a match string can/should be specified in user_alert.conf, since the mapping is done with the bigip_error_maps.dat file and not user_alert.conf.
To illustrate what I'm getting at, take the example in the article.
syslog-ng sends an alert with a matching message string "FAILED LOGIN admin FROM 192.168.1.1 FOR console, Authentication Failure" (I don't know what this alert really looks like). alertd finds the map between "FAILED LOGIN (.*) FROM (.*) FOR (.*), Authentication failure" and "BIGIP_AUTH_FAIL" alert in bigip_error_maps.dat, and sends the trap matching that definition in user_alert.conf:alert BIGIP_AUTH_FAIL "FAILED LOGIN (.*) FROM (.*) FOR (.*), Authentication failure" { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.27" }
Why can/should the message string be specified in user_alert.conf? Hasn't alertd already found the approprate alert definition by the time it needs to use it?
In addition, what controls the message string sent by syslog-ng?- The example you give is from the pre-configured alert.conf file, and there is no need to duplicate it in the user_alert.conf. I think the different uses of the 2 conf files might be what is confusing you.
alertd receives a message from syslog-ng which contains both an alert code and a message string. alertd looks in bigip_error_maps.dat to find an alert definition which matches the alert code or message string. Once a map is found, it performs the action matching the definition in the user_alert.conf (or alertd.conf).
Is that right?
Not exactly. alertd looks in bigip_error_maps.dat to find the alert code, and if found, uses the corresponding alert name to map back to the alert definition in alert.conf. This is the way many pre-configured alerts are defined. The system will also match on any match strings explicitly defined in either conf file and execute the defined alert action.
The error map files are not intended to be modified or supplemented in any way, though, so custom traps are instead always defined in user_alert.conf, including the match string.
The message string sent by syslog-ng is the same one it received -- whatever the system sent to be logged.
hth
/deb - smp_86112I think I understand the what the two conf files are used for. And I think I understand this which is stated very clearly:
alertd looks in bigip_error_maps.dat to find the alert code, and if found, uses the corresponding alert name to map back to the alert definition in alert.conf.
What I am having difficulty grasping is this:
The system will also match on any match strings explicitly defined in either conf file and execute the defined alert action.
Let me try a different approach to my question: does alertd look for a match string in the bigip_error_maps.dat file when it receives a message from syslog-ng? - Only if there is a matching alert code.
When I said "either conf file", I was refering to alert.conf & user_alert.conf, not the bigip_error_maps.dat file.
HTH
/deb
