On Thu, 18 Feb 2016, Risto Vaarandi wrote:
>
> hi all,
>
> currently, sec supports couple of builtin action list variables: %s that
> holds the value of the rule 'desc' field, %t that holds the textual
> timestamp, and %u that holds seconds since epoch.
>
> During recent discussions in the mailing list an idea came up to add
> support for new builtin action list variables. On one hand, some actions
> might benefit from specific parts of the timestamp: for example, creating
> files with 'write' action with YYYY-MM-DD extension, or sending messages to
> remote syslog servers with 'udpsock' that requires the generation of valid
> BSD syslog timestamps.
>
> Also, in some cases actions would benefit from builtin action list
> variables that would hold special characters, such as newline and carriage
> return.
>
> During some preliminary code development, I've added support for the
> following additional builtin variables, and I'd like to ask for user
> opinions whether this variable set looks OK to you.
>
> Firstly, in the alpha code there are variables for some commonly used
> special characters:
>
> %.nl = newline
> %.cr = carriage return
> %.tab = tab
>
> (It is quite easy to extend this set with all special characters ASCII 0-31
> by a simple naming convention %.asc<N>, but I am not sure if there is any
> practical need for this.)
I think we may as well add them in. I know I've run across a few oddities and
it
seems better to add them all than to play wack-a-mole on them over time.
As for the other variables, they seem to cover things, but I wish there was a
good way to not have three versions of everything. But I guess that would
require having a function to cast them from one class to another :-(
David Lang
> Then there are variables for raw values returned by perl localtime()
> function. For instance, if the current time is Monday, February 1, 12:00:01
> 2016, these variables would be set as:
>
> %.secraw = 1
> %.minraw = 0
> %.hourraw = 12
> %.mdayraw = 1
> %.monraw = 1 (0 corresponds to January)
> %.yearraw = 116 (offset from 1900)
> %.wdayraw = 1 (0 corresponds to Sunday)
>
> Time-related variables %.sec, %.min, %.hour, %.mday, %.mon, %.year -- these
> variables consist of 2 digits (apart from %.year which has 4 digits) and
> are zero padded on the left. If the current time is Monday, February 1,
> 12:00:01 2016, these variables would be set as:
>
> %.sec = 01
> %.min = 00
> %.hour = 12
> %.mday = 01
> %.mon = 02
> %.year = 2016
>
> In addition, there would be few variables with 'str' suffix for string
> representation of some fields:
>
> %.mdaystr = " 1" (date with space padding on the left)
> %.monstr = "Feb" (string abbreviation for the month, as returned by
> strftime("%b"))
> %.wdaystr = "Mon" (string abbreviation for the weekday, as returned by
> strftime("%a"))
> %.tzstr = "UTC" (string abbreviation for the timezone, as returned by
> strftime("%Z"))
>
> Since timezone offset would also be handy for generating ISO8601
> timestamps, there is a variable %.tzoffset which holds the result of
> strftime("%z") (for example, "+0000" or "-0500"). Nevertheless, since in
> some cases a colon is required between minutes and hours, there is also
> %.tzoffset2 variable which supports this format (e.g., "+00:00").
>
> When these variables are around, the following actions become easier to
> implement:
>
> # produces a separate log file for each day, for example
> # /var/log/mylog-2016-02-18
> write /var/log/mylog-%{.year}-%{.mon}-%{.mday} "received event: $0"
>
> # send an event to remote BSD syslog server with daemon.info priority
> udpsock server:514 <30>%{.monstr} %{.daystr} %{.hour}:%{.min}:%{.sec}
> myhost test: This is a test
>
> Adding support for these variables involves minimal overhead, since %.nl,
> %.cr and %.tab can be created once when sec starts up (or restart at HUP
> signal), and time-related variables need updating just once a second.
>
> In the Perl documentation, there is a warning about possible portability
> issues with strftime("%z"), since %z specifier is not part of the ansi c
> standard, and some windows platforms might not support it. Nevertheless,
> currently strftime seems the best option for obtaining timezone information
> without introducing dependencies on perl modules which are not part of the
> perl core.
>
> Any opinions on these variables?
>
> kind regards,
> risto
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
