Forum Discussion
smp_86112
Cirrostratus
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 co...
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.
