Risto Vaarandi wrote: > Is the problem you are having mainly caused by the fact that input messages > are having an overly complex structure, and it is impossible to distinguish > them from "normal" messages at first glance? > No it was my mistake, it was actually easy to track down once I had a second glance, but the point about somehow colour coding or bold-ing the matched part of the message would certainly make it more obvious which part of a message first triggered the alert, which would be _really_ nice.
Usually I know which rules and where to find them off the top of my head, but this would make it more obvious to other people, especially for those who receive the alerts but don't have the inside view I have of creating the whole system and all the rules. > If that's the case, I would recommend the use of ()-operator regexp > operators. Surely, there are certain parts in these complex input messages > that establish them as error messages (otherwise, it would be impossible to > recognize them with regular expressions). If you now use ()-operators in your > regexp, you are able to set $<number> variables which can be used for forming > your alert messages. > I do already use these, and expect I will have to modify my build system to utilize them in a way to generate the bolded output. The problem I see with this is that any enclosing capture would alter the numbering of the encompassed captures within the rules which would ruin lots of rules I've written that make heavy use of captures (especially in contexts), so this may inadvertantly require a re-write for any of those complex rules... > I fully agree with you that having $0 or %s on subject lines introduces many > security problems. However, if you need to set the message priority by > certain parts of a matching line, why not extract parts from the input line > with regexp ()-operators? In order to provide you an example, the syslog-ng > daemon can be configured to write the message priority to the log which > regular syslogd does not do. Fortunately, it is easy to extract the message > level and use it in the subject line with the following pattern and action: > > pattern=\[daemon\.(crit|alert)\] sshd\[\d+\]: > action=pipe '$0' /bin/mail -s '$1' root > > Perhaps it is possible to use a similar alert generation style in your > environment? The above example would create a comprehensible subject line > that describes the severity of the alert, while the whole message line is NOT > passed on the subject line, but rather through standard input of /bin/mail > which is much more secure. I did add facility and prioroty information at system creation time as a lot of my rules utilize this information, but there are very few priorities and grouping by priority wouldn't buy much more than my current grouping by area/function does. I think the colour/bolding is nice to have, but I may only apply it to the less complex rules otherwise it would be a significant rewrite. Having a Sec option on output formatting would make this easier as it could be abstracted away a layer higher that the rule matches themselves, hence not interfering with rules themselves. Seems I've come full circle back to my original post. -h -- Hari Sekhon Always open to interesting opportunities http://www.linkedin.com/in/harisekhon ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
