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
