Is more of a purpose to the alarm function than just printing to the alarm.log file?
.Seth
Is more of a purpose to the alarm function than just printing to the alarm.log file?
Originally it was the interface to syslog. This has now been factored out
into alarm_hook, which alarm will invoke if it's present. In principle
we could get rid of it by replacing it with explicit calls to alarm_hook
(if it's defined). I don't view this as a priority, though.
Vern
I may just remove the call to alarm then. The notice code has the notice_functions which are a set of synchronously called functions when notices are created. It's basically the same thing but completely implemented in a Bro script and you can have multiple functions instead of just one. It should open up the extension options a bit more and help prevent scripts that want to hook into the notice pipeline synchronously avoid stepping on each others toes.
I can implement the alarm.log as a filter on the notice.log with the logging framework, but I'm not completely sure what benefits come from keeping a separate file since there is a field in the notice.log that indicates if it was alarmed on.
Speaking of syslog, I just updated my syslog analyzer branch to be mergeable with master today. Bro can produce and consume (off the wire) syslog now. 
.Seth
I can implement the alarm.log as a filter on the notice.log with the logging framework, but I'm not completely sure what benefits come from keeping a separate file since there is a field in the notice.log that indicates if it was alarmed on.
One benefit is that alarm.log is often much smaller than notice.log
(a factor of 10,000 smaller for my ICSI config). Sure, one can figure
out how to grep the notice.log file for the particular needles in the
haystack, but it can be nice to just have them sitting there directly.
Vern
- From an operational perspective, I find the alarm file quite helpful (in
spite of it's redundancy).
scott
I would personally prefer having alarms go in a separate file
(alarm.log):
1) Saves me to set up a post-process to extract NOTICE_ALARM from notice logs
2) Get alarm.log emailed periodically and saving NOTICE_EMAIL for really crucial notices.
3) Allows me to write a little generic rules with NOTICE_FILE since I
don't much worry about bloated notice log
Aashish
Sounds good. I'll put a filter in the notice script that filters alarms into a file named alarm.log.
.Seth