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.
