On Mon, 10 Sep 2012, Miloslav Trmac wrote:
----- Original Message -----
The new imuxsock stores "pid", "uid" and "gid" into a "trusted"
subobject; shouldn't they go into the root object by default, so that
the JSON data can be used for Lumberjack storage directly without
modification in a template? (This also implies that mmjsonparse would
have to prevent modification of these values by content of the
message.)
That's actually a good question. I see value in both. And with the
flat vs. structured question being discussed again at CEE, I really
don't know. Both makes sense. I have to admit (you may remember my
presentation) that I have become tired by these discussions and
rather code, as many others do (especially those that claim to solve
all problems at once...). I don't object if we put them into the
root directly, but for other use cases that'sprobably not as good
(e.g. for quick access to all trusted properties, which then must be
made on a field-by-field basis, what is especially bad from an
extensibility PoV.
In any case, I plan to make the container configurable. It's easy and
leaves the choice to the user. But I had no time so far. Before
doing that, I'll have to finish the rule engine/variable setting
work.
I totally understand that the specification work is tiresome, and that
the resulting specification may not be great. Let me suggest some
reasons why the field names/placement should follow Lumberjack, even
though the "trusted" subobject is arguably a better design:
1) Consistency: Lumberjack is still very new, and fragmenting it now
weakens the utility of the specification.
The Lumberjack spec is still flexible enough that I think we can make the
case for the 'trusted' subobject there.
2) Namespace issues on input: The "pid" field has a specific purpose,
and applications can be expected to not store data in there; the
"trusted!pid" field is not specified, so it should be available for
applications to use. If imuxsock adds "trusted!pid", there will be no
way to record both the value that was sent by the application and the
value added by imuxsock at the same time. On "output", we can solve the
namespace disagreements by using templates, but on "input", we don't
have a similar structure renaming mechanism (and I don't think we want
one either). Arguably this can be solved by using e.g. a "rsyslog!pid"
namespace, but that's fragmenting the specification even more.
There are actually two PID fields, the field that the application writes
as part of the syslog tag, and the field that is captured by the logging
process via the 'trusted' mechanism. Not all logs are going to have the
trusted tags, and it's better to be able to know which you are using.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
