To Yuri’s point, the _sender_stat message is the only one without an origin, but I see that as ancillary and not entirely relevant. In my view the format change is simply a bug fix.
Thanks to all! > On Jun 9, 2021, at 09:41, Yuri Bushmelev <[email protected]> wrote: > > Hello! > > Well.. I'm ok to just change string to integer as John requested.. > But my internal perfectionist would like to have "proper & beautiful fix" :-D > My main point here is the sender stats are non-compliant compared to the rest > of metrics. I'd say it should be reimplemented as dynstats internally. Or > maybe just deleted putting an dynstats configuration example in docs instead. > But this is against overall rsyslog policy as I see it. > > Let's just do a quickfix now. One day someone will refactor it maybe.. > > Thank you! > > On Wed, 9 Jun 2021 at 20:35, Rainer Gerhards <[email protected] > <mailto:[email protected]>> wrote: > Yuri, > > would that proposal "just fix it" work for you? > > While I am really going strongly for keeping backwards compatibility, > John's argument sounds convincing. One reason for this thought is that > experience tells me many people will not turn on such a "bug-fixing > option". > > Or maybe "just fix it and add the option if there are real complaints"? > > Rainer > > El mar, 8 jun 2021 a las 13:42, John Chivian (<[email protected] > <mailto:[email protected]>>) escribió: > > > > 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] <mailto:[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] > > > <mailto:[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] <mailto:[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] <mailto:[email protected]>>) > > >>> escribió: > > >>>> > > >>>> Hello! > > >>>> > > >>>> Hmm.. from what I see here you're right: > > >>>> https://github.com/rsyslog/rsyslog/blob/master/runtime/statsobj.c#L500 > > >>>> <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] <mailto:[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 > > >>>>> <http://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 > > >>>>> <https://lists.adiscon.net/mailman/listinfo/rsyslog> > > >>>>> http://www.rsyslog.com/professional-services/ > > >>>>> <http://www.rsyslog.com/professional-services/> > > >>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>>>> <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 > > >>>> <https://lists.adiscon.net/mailman/listinfo/rsyslog> > > >>>> http://www.rsyslog.com/professional-services/ > > >>>> <http://www.rsyslog.com/professional-services/> > > >>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>>> <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 > > > <https://lists.adiscon.net/mailman/listinfo/rsyslog> > > > http://www.rsyslog.com/professional-services/ > > > <http://www.rsyslog.com/professional-services/> > > > What's up with rsyslog? Follow https://twitter.com/rgerhards > > > <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.
