On Mon, 2012-10-08 at 16:51 -0700, david(a)lang.hm wrote:
On Mon, 8 Oct 2012, david(a)lang.hm wrote:
> exactly. If we support hierarchical structures, we can use a single tag,
> if we make everything flat, we can reserve a prefix (ideally, a prefix
> that translates to a subtree name so that people who want it flat can
> treat it as if it's flat, people who want hierarchical can treat it as a
> subtree)
>
> I would actually reserve two prefixes/subtree names
>
> The first for the tags that are generated by the logging infrastructure
>
> The second for a place to relocate any tags that are passed to us in a
> reserved space.
>
> for the sake of argument, call these 'trusted.' and 'forged.' If
someone
> submits something with trusted.uid, move it to forged.trusted.uid. If
> someone submits something with forged.uid move it to forged.forged.uid.
>
>> If the prefix is unique there is a very low chance that the resolved
>> fields would be overwritten unintentionally.
>
> exactly.
>
> Now, from the discussion a couple of weeks ago, people have a real hard
> time with 'trusted' (arguments crop up about how much you can really trust
> it), so we need to pick something else.
>
> we could do lumberjack. for trusted and beaver. for forged :-) This is a
> bit long, someone with more creativity can pick a couple of names.
Okay. I see where this is going.
David, sorry for the prior discussion of the "trusted" fields. I now
understand the point you were trying to make.
Generally, there are several groupings of fields:
* Application - the fields & structures added by the application when
the event record is created.
* Log system - the "trusted" fields added by the log service and system
* Other fields added by relays and event consumers
If we look at this, there is a natural nesting that occurs. First the
application data is records, with whatever fields they wish. Then, the
data is wrapped by the log system, similar to the syslog header vs.
content, though we probably want to be more flexible in the "header"
fields. I think this is some of what David was explaining with his
"trusted" fields. They are not "trusted" from the point of security,
but
the fact that they are placed there by a more trusted service and can be
thought of as being more reliable.
Later additions can then wrap the original events.
The only problem with this approach is that the most used information
from the original event ends up buried within this nesting of
Matryoshkas.
Maybe there is another way to solve this problem using a flat(ter)
structure?
using the terminology from the wiki page listed in the subject, these
would be 'objects' instead of 'subtrees' and the character at the end
would be a '!' instead of a '.'
David Lang
_______________________________________________
lumberjack-developers mailing list
lumberjack-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers