How about this: we support a new flag in impstats which allows
json-formatted stats-line to optionally use
encapsulated/wrapped-layout?
impstats(format="json" ...) generates
{"name":"msg_per_host","origin":"dynstats.bucket","z-scribe1r-b":80,"SWEB10":67}
however,
impstats(format="json/w" ...) generates {"header":
{"name":"msg_per_host","origin":"dynstats.bucket"}, "counters" :
{"z-scribe1r-b":80,"SWEB10":67}}
This is relevant, the serilization format we use right now mixes
pre-defined keys with counter-names and it can affect regular static
counters too.
Thoughts?
On Tue, Mar 22, 2016 at 8:46 PM, David Lang <[email protected]> wrote:
> On Tue, 22 Mar 2016, Rainer Gerhards wrote:
>
>> 2016-03-22 15:57 GMT+01:00 David Lang <[email protected]>:
>>>
>>> On Tue, 22 Mar 2016, Rainer Gerhards wrote:
>>>
>>>> 2016-03-21 22:27 GMT+01:00 David Lang <[email protected]>:
>>>>>
>>>>>
>>>>> The json produced by dynastats needs some work, currently it looks
>>>>> like:
>>>>>
>>>>>
>>>>>
>>>>> {"name":"msg_per_host","origin":"dynstats.bucket","z-scribe1r-b":80,"SWEB10":67}
>>>>>
>>>>> This is not something that can readily be handled, and since the
>>>>> hostname
>>>>> is
>>>>> at the same level as name or origin, it's just begging for abuse.
>>>>>
>>>>> It would be far better to put these into an array that could then be
>>>>> handled
>>>>> via foreach
>>>>>
>>>>> something like:
>>>>>
>>>>>
>>>>> {"name":"msg_per_host","origin":"dynstats.bucket",items:["z-scribe1r-b":80,"SWEB10":67]}
>>>>>
>>>>> Yes, this has hit a stable release, but the docs still haven't made it
>>>>> to
>>>>> the website (which is still showing 8.16) and so I don't think anyone
>>>>> is
>>>>> depending on this syntax yet, so I think we can get away with changing
>>>>> it.
>>>>
>>>>
>>>>
>>>> Two things: first of all, the doc tarball went out and probably is
>>>> included in some distros. Also, this *is* the released version. So I
>>>> think it would be a bad thing to change this without mentioning it. If
>>>
>>>
>>>
>>> I agree it should be mentioned, probably in the release announcement
>>>
>>>> there is agreement to change, I agree it's not a big deal at this
>>>> stage. While seldom, we have made some breaking changes of such a
>>>> small magnitude in the past as well.
>>>
>>>
>>>
>>> So do people agree or disagree with my suggested change?
>>
>>
>> I am neutral, as I don't see any use case for me and my customers for
>> this functionality. I also don't think it breaks any rsyslog concept
>> (that's why I merged in the frist place).
>
>
> I've been delivering logs to sec and having it write per-minute summary data
> out, I'm running into the case where the sec process is maxing out (hitting
> 100% cpu and single-threaded), so I'm experimenting with doing this in
> rsyslog and having rsyslog spit out the data to a monitoring system.
>
> I'm also going to be looking at the functionality that I think I saw go in
> recently to trigger if a source hasn't reported in too long a timeframe.
> That's also something I'm starting to have as a bottleneck. I expect that
> when I try to do that I'll be trying to do more than rsyslog is setup to do,
> but we'll see.
>
> David Lang
>
>
>> Conceptionally, I am leaning towards your argument, but I don't want
>> to put any effort into a patch or strong discussion TBH.
>>
>> Rainer
>>>
>>>
>>>> Secondly, the website update failed due to a merge conflict inside a
>>>> script that wasn't properly detected. This is fixed now. So the
>>>> correct version will hopefully show up soon on the site (but IMHO
>>>> without affecting anything else, as said in the first paragraph).
>>>
>>>
>>>
>>> Glad to hear this.
>>>
>>>
>>> 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
>>> 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.
>>
> _______________________________________________
> 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.
--
Regards,
Janmejay
http://codehunk.wordpress.com
_______________________________________________
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.
