In message <5097c518.7000...@seb.ee>,
Risto Vaarandi writes:
>On 11/04/2012 11:58 PM, da...@lang.hm wrote:
>> On Sun, 4 Nov 2012, da...@lang.hm wrote:
>>> On Sun, 4 Nov 2012, Risto Vaarandi wrote:
>>>> 2012/10/20<da...@lang.hm>:
>>>>> On Sat, 20 Oct 2012, Risto Vaarandi wrote:
>>>> I have completed some work on the alpha version of the next release,
>>>> and it supports returning hashes from PerlFunc patterns. If the user
>>>> defines a custom parsing scheme inside PerlFunc pattern, keyword=value
>>>> pairs can now be returned as named match variables with a single hash.
>>>> However, there are still few things I'd like to clarify. Perl regexp
>>>> named captures assume that a name consist of alphanumerals and
>>>> underscores (i.e., each name character must match \w) which is also
>>>> the case for LumberJack. Nevertheless, Perl also assumes that named
>>>> capture never begins with a number. Does LumberJack impose a similar
>>>> restriction? This restriction allows for one nice optimization --
>>>> internally, named and numbered match variables can be stored in one
>>>> hash table (for the latter, numbers are used as keywords).
>>>> As a separator, I think it is quite easy to allow the use of ! inside
>>>> variable names.
>>> Lumberjack hasn't specified this, but since this is a very common
>>> limitation for variable names, I think it's a very reasonable
>>> thing to do.
>>>
>>> Nothing that Lumberjack has specified would violate this.
>>>
>>> I'll post to that list?
>>
>> The initial reaction I'm gettig back is that this wasn't discussed, but
>> they have are very strongly in favor of prohibiting leading numbers in
>> field names.
>
>It is good to know that. The only point of potential clash is the SEC's
>internal variable $+{_inputsrc} which holds the filename where the event
>came from. When introducing this variable, I had an idea of having _
>prefix reserved for future special variables set by SEC.
>
>Another issue is the use of delimiting characters in variable names. I
>am thinking of allowing !, but if support for referencing cached
>variables is added, a "cache_entry.varname" type of syntax would be
>required. For delimiting entry and variable names, I was thinking of
>colon and dot, but are there any other suggestions? I'd like to have a
>delimiter which wouldn't be conflicting with some other structured log
>delimiter in the future.
>Any proposals or ideas?
Well who knows what form future structured logging will take, so maybe
some escape mechaninis is needed? So if a log fields have the name:
host.domain=example.com
host.name=foo
have SEC represent them as:
%+{cache_entry.host..name} = example.com
%+{cache_entry.host..name} = foo
where a literal . is represented by two dots in a row. So a field name of:
host..domain -> host....domain
etc. Not a great solution but escaping the real data allowing it to be
passed through is a tried and true technique for adapting to these
issues. Maybe the current SEC escape mechanism '{...}' could be used?
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
