In message
<ca+pmdhkbk9j94rchwafonh9w07v-ktyky2uahbq5q+kudbm...@mail.gmail.com> ,
Edward Gleeck writes:

>Is there a way for sec to handle dynamically generated log files in a
>directory. Our application would often move a log file from a directory and
>create new ones (sort of the way log rotate can be configured to run). I
>was thinking more like sec --input=/dir/*.log which monitor the directory

That is a valid input specification, but it only evaluates the *.log
on startup or via a restart signal (SIGHUP or SIGABRT, see the man
page for details).

>for new files that are being generated. If SEC does not support this, how
>can you use SEC in this scenario?

>From an intro coursebook I wrote a few years back:

============

Some processes create multiple log files that are date stamped or
otherwise uniquely named. SEC however wants a static name to be able
to follow the log file. The following rule allows you to have SEC
follow files where the most recent log file has a unique name.

This will work only if the period between creating new files is longer
than 2 minutes. The basic idea is:

  * have sec follow a single input file (called current)
  * identify newest of the log files
  * see if the inode of that file is the same as current file
  * if different, hard link file to current
  * use a Calendar rule that fires every minute to check/create link

This rule identifies the most recent file in the log directory and
hard links it to the file named current in the working directory of
the SEC process. The directory holding the file current is writable by
the user running the SEC process while the parent directory is not
writable to the SEC user.

#****v* calendar/relink_current
# SYNOPSIS
# relink_current - created hard link to newest log file in the parent directory
# DESCRIPTION
# Every minute find the most recently written log file in the parent directory
# and obtain its inode number.  Obtain the inode number of the file current
# (which must exist). If they have the same inode number, exit status 0. If
# they don't force current to be linked to the most recently written log file.
#******
type = calendar
time = * * * * * 
desc = relink current file
action = shellcmd (/bin/sh -c 'lastfile=`ls -tr .. | grep '\\.log\$'  | tail -n 
1`; [ `stat --printf "%i" current` -eq `stat --printf "%i" ../$lastfile` ] || 
ln -f ../$lastfile current')

The shellcmd identifies the last log file by listing the parent
directory with the files sorted by date. The grep limits the file list
to log files. The tail then selects just the last file. The test
command uses stat to see if the inodes for the current and last file
are the same. If they are not, the current file is forcibly replaced
with a link to the newest log file.

Since SEC follows the current file until there is no more input it
will process the old log file to the end. Then when there is no more
data, it detects that the current file has changed and starts
processing it from the beginning. No events should be lost, but the
processing of data in the new log file can be delayed by up to a
minute.

========================

IIRC if you use a symbolic link in place of the hard link and the
target file disapears, and then the link is changed, sec takes longer
to recognize the change, so the hard link is your best bet.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

Reply via email to