Thanks for the feedback. Some comments inline... 2014-10-10 15:30 GMT+02:00 Dave Caplinger <[email protected]>:
> On Oct 10, 2014, at 6:25 AM, Rainer Gerhards <[email protected]> > wrote: > > > ... In v8-devel, I could envision something along these lines: > > > > template(name="testTemplate3" type="list" format="jsonf") { > > property(outname="@timestamp" name="timereported" dateFormat="rfc3339") > > property(outname="host" name="hostname") > > property(outname="severity" name="syslogseverity-text") > > property(outname="facility" name="syslogfacility-text") > > property(outname="tag" name="syslogtag") > > property(outname="message" name="msg") > > } > > > > Would that be better? If so, do you think that would be worth the effort > > implementing it (given the long list of other feature requests)? > > I do like this structure better, but think using the term 'label' rather > than 'outname' might be a better fit. I agree that "outname" is not as good as "label". However, as we already have "outname", would it really make sense to alias it? > Also, is it safe to assume that by setting the 'format="jsonf" at the > template level, all enclosed properties will inherit that formatting, and > therefore if you don't specify an 'outname' (or 'label') it will just use > the property name? The idea is that I would propagate the format down to all property definitions. And, yes, if if do not set "outname", the property name is used. That is exactly what happens today when you select "jsonf" format at the property level. > Here's a slightly different proposed config: > > template(name="testJsonTemplate" type="list" format="jsonf") { > property(name="timereported" dateFormat="rfc3339" label="@timestamp") > # => "@timestamp":"1996-12-19T16:39:57-08:00", > property(name="hostname") > # => "hostname":"logbox", > property(name=... > } > > which helps highlight the 'label' option as an optional change, like > "Print out the timereported property in rfc3339 format, but call it > @timestamp instead." > That's exactly what happens today (when "jsonf" is used at the property level). I set the "outname", because the original sample used different field names/labels for all properties. > In my own experience at least, the property names in rsyslog frequently > don't match the key names I want in the JSON output, so I think use of this > functionality will be more common over time. > > On a related topic -- I'm not sure I understand why we need 'jsonr' and > 'jsonrf' on top of 'json' and 'jsonf' formats. Shouldn't 'json' format > just be fixed to do what 'jsonr' does because 'json' generates invalid > string encoding in some cases (and similar for 'jsonf')? The doc suggests > that the only difference is that jsonr "avoids double escaping the value > but makes it safe for a json field." Wouldn't you always want that? > Well, two answers. First of all, if we remove some of the options, we break backward compatibility, and do so without a hard need. In other words, it would no longer be safe to upgrade. The rsyslog project tries hard to avoid these problems. And thinking about escaping, there is a subtle difference. Let's say you have a message that just says "a\nb". By default, this gets converted "a\\nb", so in a proper receiver, the string will again be "a\nb" (4 chars). No message modification happens. In the jsonr case, we try to find C escape sequences in the property in question and try to unescape them. So "a\nb" (4 chars) becomes "a<LF>b" (3 chars), what then is json-encoded into "a\nb" and the proper receiver will decode it as "a<LF>b" (3 chars). As such, the receiver actually does see a DIFFERENT message than the one the original sender emitted. This may be the desired result, even in many cases, but in other cases it may just be plainly wrong. For example, if a message hash was taken, that hash would of course become invalid by changing "\n" to the single LF character. Does that explain why there are the different options? Rainer > > - Dave > _______________________________________________ > 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 > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ 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 NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
