Hi Rainer: I would prefer the existing format, not the dynstats format or methodology as you are correct, that is not so friendly to not advanced users.
From my perspective, changing the messages field to be emitted as an integer will not break anything. That information is fed into a modern SIEM which is intelligent enough handle the string correctly. It requires conversion to an integer for use (which is why I brought it up), but that’s just an extra step not a heavy lift. I would vote for simply correcting the existing output format as this doesn’t fundamentally change the behavior or configuration of the application. Regards, > On Jun 8, 2021, at 06:28, Yuri Bushmelev via rsyslog > <[email protected]> wrote: > > Hello! > > I just found I was never using `senders.keepTrack` before.. though it's a 5 > years old feature.. I was always using dynstats for this :-D > > I'd vote for a global option to have sender stats in old format or in > dynstats-like format. > Something like "senders.reportFormat = [old/dynstats]" with "old" as a > default value. > This way we can keep compatibility and do not create yet another format to > deal with. > > Thank you! > > On Tue, 8 Jun 2021 at 19:13, Rainer Gerhards <[email protected]> > wrote: > >> I forgot: I would not like to refactor this into dynstats, as this is >> IMHO harder to use for non-pro users. >> >> Rainer >> >> El mar, 8 jun 2021 a las 13:11, Rainer Gerhards >> (<[email protected]>) escribió: >>> >>> mhhh... this is a bit unfortunate: I obviously did not spot it with >>> the initial commit. >>> >>> Question now: will we break existing scripts when we fix this? Do we >>> need to add an option to impstats to export numbers as, well, numbers? >>> ;-) >>> >>> Opinions? >>> >>> Rainer >>> >>> El mar, 8 jun 2021 a las 6:21, Yuri Bushmelev via rsyslog >>> (<[email protected]>) escribió: >>>> >>>> Hello! >>>> >>>> Hmm.. from what I see here you're right: >>>> https://github.com/rsyslog/rsyslog/blob/master/runtime/statsobj.c#L500 >>>> >>>> Number is formatted as a string.. And there is no "origin" field as >> well. >>>> I'd prefer to export this data in the same form as `dynstats` counters >> are. >>>> E.g.: >>>> >>>> { "name": "_sender_stats", "origin": "runtime", "values": { >>>> "192.168.10.18": 1, "192.168.10.19": 12 } } >>>> >>>> This way it's much easier to reuse existing parsers. >>>> >>>> Or... Ideally we don't need this kind of stats at all because a user >> can >>>> register a dynstats counter for this (I guess).. but I may miss some >>>> internal details here.. >>>> >>>> P.S. I have personal interest here as I made the rsyslog_exporter in >> Python >>>> :) >>>> >>>> >>>> On Tue, 8 Jun 2021 at 03:41, John Chivian via rsyslog < >>>> [email protected]> wrote: >>>> >>>>> In version 8.2102 the impstats _sender_stat messages field is being >>>>> reported as a string value, not an integer. >>>>> >>>>> >>>>> {"name":"_sender_stat", "sender":"192.168.10.18", "messages":"0"} >>>>> >>>>> >>>>> This is in contrast to essentially everything else that is reported >> as >>>>> integers. >>>>> >>>>> >>>>> {"name": "udp-15144-out queue", "origin": "core.queue", "size": 0, >>>>> "enqueued": 0, "full": 0, "discarded.full": 0, "discarded.nf": 0, >>>>> "maxqsize": 4 } >>>>> >>>>> >>>>> Config is generated from blow directive… >>>>> >>>>> >>>>> module(load="impstats" >>>>> interval="60" >>>>> resetCounters="on" >>>>> format="json" >>>>> severity="7" >>>>> log.file="/var/log/impstats/impstats.json” >>>>> ) >>>>> >>>>> >>>>> I rather doubt this is intended, and it’s trivial to work around, >> but the >>>>> maintainers would need to say for sure. I can enter an issue if >> desired. >>>>> >>>>> Thanks, >>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> https://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. >>>> >>>> >>>> >>>> -- >>>> Yury Bushmelev >>>> _______________________________________________ >>>> rsyslog mailing list >>>> https://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. >> > > > -- > Yury Bushmelev > _______________________________________________ > rsyslog mailing list > https://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 https://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.
