Opened bugreport https://github.com/rsyslog/rsyslog/issues/4364 will post updates there.
Peter On Sat, Jul 18, 2020 at 11:48 AM Rainer Gerhards <[email protected]> wrote: > thx - looks like I need to dig a bit deeper, I am sure there is a > valid explanation - which then should be reflected by some name > mangling. > > Rainer > > El vie., 17 jul. 2020 a las 20:21, Peter Viskup > (<[email protected]>) escribió: > > > > Not related to IPv4 vs. IPv6 nor rulesets > > > > On server with IPv6 disabled with only one public iface and IP > > root@server:~# sysctl -a |grep .disable_ipv6 > > net.ipv6.conf.all.disable_ipv6 = 1 > > net.ipv6.conf.default.disable_ipv6 = 1 > > net.ipv6.conf.ens192.disable_ipv6 = 1 > > net.ipv6.conf.lo.disable_ipv6 = 1 > > > > Related configuration > > root@server:~# cat /chroot/net/etc/rsyslog.d/host/net/listeners/*.conf > > input(type="imptcp" port="1514" KeepAlive="on") > > input(type="imudp" port="1514") > > root@server:~# cat /chroot/net/etc/rsyslog.d/global/03-modules.conf > > module(load="imudp") > > module(load="imptcp") > > root@server:~# cat /chroot/net/etc/rsyslog.d/global/00-stats.conf > > module(load="impstats" > > interval="15" > > severity="7" > > ResetCounters="on" > > log.syslog="off" > > # need to turn log stream logging off! > > log.file="/var/spool/rsyslog/rsyslog.stats") > > > > We do see similar "doubled" stats: > > Fri Jul 17 18:06:46 2020: imudp(*:1514): origin=imudp submitted=1216 > disallowed=0 > > Fri Jul 17 18:06:46 2020: imudp(*:1514): origin=imudp submitted=0 > disallowed=0 > > > > Running rsyslog 8.1901.0-1 from Debian 10 stable. > > > > With input name configured, the output shows same name in both lines > > root@server:~# cat /etc/rsyslog-eset/host/net/listeners/input-udp.conf > > input(type="imudp" port="1514" name="udp1514") > > > > Fri Jul 17 18:17:27 2020: udp1514(*:1514): origin=imudp submitted=1354 > disallowed=0 > > Fri Jul 17 18:17:27 2020: udp1514(*:1514): origin=imudp submitted=0 > disallowed=0 > > > > Looks like a bug being here with us for a long time. :-) > > > > Peter > > > > > > On Fri, Jul 17, 2020 at 9:19 AM Rainer Gerhards < > [email protected]> wrote: > >> > >> El jue., 16 jul. 2020 a las 9:00, Peter Viskup (<[email protected]>) > escribió: > >> > > >> > Just discovered the same on our infra. > >> > Will test by disabling IPV6 and confirm if Ángel will not answer > sooner. > >> > >> Thx - I guess if it is that way, it would make sense to automatically > >> append"ipv4" or "v6" to the configured name. > >> > >> Rainer > >> > > >> > Peter > >> > > >> > On Tue, Jul 14, 2020 at 4:02 PM Rainer Gerhards < > [email protected]> wrote: > >> >> > >> >> Sorry for being late to the discussion. > >> >> > >> >> I would need to check, but I guess this is ipv4 and ipv6, which > >> >> possibly are not clearly indicated. Could this be the case? > >> >> > >> >> Rainer > >> >> > >> >> El mar., 14 jul. 2020 a las 15:49, Peter Viskup via rsyslog > >> >> (<[email protected]>) escribió: > >> >> > > >> >> > Hi Ángel, > >> >> > might be related to the ruleset in input configuration. > >> >> > Use the Name and Name.appendPort options to specify the name of > that input > >> >> > for your ruleset. > >> >> > > https://www.rsyslog.com/doc/v8-stable/configuration/modules/imudp.html#name > >> >> > > >> >> > The other input reporting stats could be initialized by default > ruleset > >> >> > which is always defined. > >> >> > https://www.rsyslog.com/doc/v8-stable/concepts/multi_ruleset.html > >> >> > > >> >> > According to the docu > >> >> > < > https://www.rsyslog.com/doc/v8-stable/concepts/multi_ruleset.html#what-does-to-bind-to-a-ruleset-mean > > > >> >> > - is the ruleset already defined when input is being initialised? > >> >> > That might lead to this behaviour. > >> >> > > >> >> > Peter > >> >> > > >> >> > On Thu, Jul 9, 2020 at 1:43 PM Ángel L. Mateo via rsyslog < > >> >> > [email protected]> wrote: > >> >> > > >> >> > > Hi, > >> >> > > > >> >> > > I have activated the stats in rsyslog to log to syslog > stats > >> >> > > entries. > >> >> > > My problem is that udp stats are doubled twice. > >> >> > > > >> >> > > My configuration is: > >> >> > > > >> >> > > module(load="impstats" > >> >> > > interval="60" > >> >> > > format="json" > >> >> > > > >> >> > > ) > >> >> > > module(load="imudp") > >> >> > > input(type="imudp" > >> >> > > address="*" > >> >> > > port="514" > >> >> > > ruleset="remote_udp" > >> >> > > ) > >> >> > > ... > >> >> > > > >> >> > > I don't have any other udp input. > >> >> > > > >> >> > > With this configuration, anytime that stats are recorded > I get: > >> >> > > > >> >> > > Jul 9 13:35:56 pitufo41 rsyslogd-pstats: { "name": > "imudp(*:514)", > >> >> > > "origin": "imudp", "submitted": 64559362, "disallowed": 0 } > >> >> > > Jul 9 13:35:56 pitufo41 rsyslogd-pstats: { "name": > "imudp(*:514)", > >> >> > > "origin": "imudp", "submitted": 0, "disallowed": 0 } > >> >> > > Jul 9 13:35:56 pitufo41 rsyslogd-pstats: { "name": "imudp(w0)", > >> >> > > "origin": "imudp", "called.recvmmsg": 42316004, > "called.recvmsg": 0, > >> >> > > "msgs.received": 64559362 } > >> >> > > > >> >> > > The imupd(w0) is correctly documented in > >> >> > > > >> >> > > > https://www.rsyslog.com/doc/v8-stable/configuration/modules/imudp.html#imudp-statistic-counter > >> >> > > as the worker statistics. > >> >> > > > >> >> > > But I don't know I'm getting two records for input > imudp(*:514). > >> >> > > For > >> >> > > other inputs like tcp or relp (I'm using too) I don't have such > >> >> > > duplicity. For example: > >> >> > > > >> >> > > Jul 9 13:39:58 pitufo31 rsyslogd-pstats: { "name": > "imrelp(20514)", > >> >> > > "origin": "imrelp", "submitted": 35531697 } > >> >> > > Jul 9 13:39:58 pitufo31 rsyslogd-pstats: { "name": "imtcp(514)", > >> >> > > "origin": "imtcp", "submitted": 0 } > >> >> > > Jul 9 13:40:58 pitufo31 rsyslogd-pstats: { "name": > "imrelp(20514)", > >> >> > > "origin": "imrelp", "submitted": 35619726 } > >> >> > > Jul 9 13:40:58 pitufo31 rsyslogd-pstats: { "name": "imtcp(514)", > >> >> > > "origin": "imtcp", "submitted": 0 } > >> >> > > > >> >> > > I'm running rsyslog 8.2006.0-0adiscon2bionic1. > >> >> > > > >> >> > > Any idea of why this? > >> >> > > > >> >> > > -- > >> >> > > Angel L. Mateo Martínez > >> >> > > Sección de Telemática > >> >> > > Área de Tecnologías de la Información > >> >> > > y las Comunicaciones Aplicadas (ATICA) > >> >> > > http://www.um.es/atica > >> >> > > Tfo: 868889150 > >> >> > > Fax: 868888337 > >> >> > > _______________________________________________ > >> >> > > 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. > _______________________________________________ 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.
