Forum Discussion
CirrostratusGeneric log levels in alertd.conf (v11)
I was hoping someone could help me understand where these directives in the /etc/alertd/alertd.conf come from. It seems that they do what I would expect, which is send trap on every message of the corresponding syslog level. But I'm unclear about where these strings come from. They aren't referenced in any of the _maps.h files, and I can't find any documentation about them. All the other directives in the alertd.conf file have explicit references in the _maps.h files, but the ones below don't.
alert BIGIP_LOG_EMERG "^[0-9a-f]{8}:0: (.*)" {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.29"
}
alert BIGIP_LOG_ALERT "^[0-9a-f]{8}:1: (.*)" {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.30"
}
alert BIGIP_LOG_CRIT "^[0-9a-f]{8}:2: (.*)" {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.31"
}
alert BIGIP_LOG_ERR "^[0-9a-f]{8}:3: (.*)" {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.32"
}
alert BIGIP_LOG_WARNING "^[0-9a-f]{8}:4: (.*)" {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.33"
}
15 Replies
smp_86112Edit: meant to reference the strings explicitly. I am referring to the strings "BIGIP_LOG_EMERG", "BIGIP_LOG_ALERT", etc... I Can't edit my original post for some reason.Hmm. Never really looked at the exact regex in the alert. My guess is that the trap looks for any map number of priority x as denoted after the :x: and as designated as the standard syslog log levels. So for the 1st example:
"^[0-9a-f]{8}:0: (.*)"
Would be log level 0 which is Emergency.
Log levels are listed in the .map files and the F5 device will log this as a log level number after the colon. For example:
err tmm3[9818]: 01010221:3:
is log level Error as denoted by :3:
- smp_86112Thanks for the response. On one hand, I agree this might be how it works. But if what you are saying is true, then it seems the string I'm asking about ("BIGIP_LOG_EMERG" for example) would be irrelevant, wouldn't it? But I know those strings mean something, in some cases at least. Today I had to customize /config/user_alert.conf to send an email during a sync. There is no regex string to perform a match, and it works. So while I do understand and agree with your thought process, this can't be the whole story.
- smp_86112Here's what I put in our user_alert.conf - it works. alert BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE { email toaddress="me@mydomain.com"; }
- I believe the BIGIP_LOG_* traps in alert.conf are commented out. They were meant to be used as a catch all for alerts that were not defined. So I think they are irrelevant. The alerts defined in user_alert.conf have a higher priority than alert.conf. I am a little surprised that the map name would match the log. Perhaps the map number has a direct relationship with the string. But if this works for you and is your intent, then the map name should be good enough.
nitass_89166Noctilucent
Here's what I put in our user_alert.conf - it works.
alert BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE { email toaddress="me@mydomain.com"; }
i understand it works because BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE is predefined.
[root@ve11a:Active:In Sync] config grep BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE /var/run/bigip_error_maps.dat 0 LOG_NOTICE 010714a0 BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE "Sync of device group %s to commit id %llu %llu %s %llu from device %s complete."- smp_86112> i understand it works because BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE is predefined. Yes, so do I. But what I don't understand is why BIGIP_LOG_EMERG also works when that is not predefined.
- nitass
Employee
Here's what I put in our user_alert.conf - it works.
alert BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE { email toaddress="me@mydomain.com"; }
i understand it works because BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE is predefined.
[root@ve11a:Active:In Sync] config grep BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE /var/run/bigip_error_maps.dat 0 LOG_NOTICE 010714a0 BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE "Sync of device group %s to commit id %llu %llu %s %llu from device %s complete."- smp_86112> i understand it works because BIGIP_MCPD_MCPDINFO_SYNC_DEVICEGROUP_COMPLETE is predefined. Yes, so do I. But what I don't understand is why BIGIP_LOG_EMERG also works when that is not predefined.
- nitass
But what I don't understand is why BIGIP_LOG_EMERG also works when that is not predefined.
isn't it predefined in /etc/alertd/alert.conf?
[root@ve11a:Active:In Sync] config grep BIGIP_LOG_EMERG /etc/alertd/alert.conf alert BIGIP_LOG_EMERG "^[0-9a-f]{8}:0: (.*)" {The first line of an alert definition may also optionally contain the match string, as in this example, which uses a regular expression to catch all local authentication failure log messages: alert BIGIP_AUTH_FAIL "FAILED LOGIN (.*) FROM (.*) FOR (.*), Authentication failure" { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.27" } If, as in our original example, the match string is not defined in the alert definition itself, you can find it in the /var/tmpfs/run/bigip_error_maps.dat by searching for the alert name with this command: grep BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS /var/tmpfs/run/bigip_error_maps.datCustom SNMP Traps by Deb Allen
https://devcentral.f5.com/articles/custom-snmp-traps.U1UeC1dhcdU- smp_86112> isn't it predefined in /etc/alertd/alert.conf? Yes it is, but obviously I'm not making myself clear. Maybe this will help. Can you explain why this returns something: 'grep BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS /var/run/bigip_error_maps.dat` but this does not: `grep BIGIP_LOG_EMERG /var/run/bigip_error_maps.dat`
- nitassi understand matching string can be defined in either /etc/alertd/*.h or /etc/alertd/alert.conf file. BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS is defined in /etc/alertd/bigip_mcpd_error_maps.h) but BIGIP_LOG_EMERG is defined in /etc/alertd/alert.conf. i do not know the underlying reason why they all are not defined in maps file (/etc/alertd/*.h).
- nitass_89166
But what I don't understand is why BIGIP_LOG_EMERG also works when that is not predefined.
isn't it predefined in /etc/alertd/alert.conf?
[root@ve11a:Active:In Sync] config grep BIGIP_LOG_EMERG /etc/alertd/alert.conf alert BIGIP_LOG_EMERG "^[0-9a-f]{8}:0: (.*)" {The first line of an alert definition may also optionally contain the match string, as in this example, which uses a regular expression to catch all local authentication failure log messages: alert BIGIP_AUTH_FAIL "FAILED LOGIN (.*) FROM (.*) FOR (.*), Authentication failure" { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.27" } If, as in our original example, the match string is not defined in the alert definition itself, you can find it in the /var/tmpfs/run/bigip_error_maps.dat by searching for the alert name with this command: grep BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS /var/tmpfs/run/bigip_error_maps.datCustom SNMP Traps by Deb Allen
https://devcentral.f5.com/articles/custom-snmp-traps.U1UeC1dhcdU- smp_86112> isn't it predefined in /etc/alertd/alert.conf? Yes it is, but obviously I'm not making myself clear. Maybe this will help. Can you explain why this returns something: 'grep BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS /var/run/bigip_error_maps.dat` but this does not: `grep BIGIP_LOG_EMERG /var/run/bigip_error_maps.dat`
- nitass_89166i understand matching string can be defined in either /etc/alertd/*.h or /etc/alertd/alert.conf file. BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS is defined in /etc/alertd/bigip_mcpd_error_maps.h) but BIGIP_LOG_EMERG is defined in /etc/alertd/alert.conf. i do not know the underlying reason why they all are not defined in maps file (/etc/alertd/*.h).
