Page MenuHomePhabricator

rsyslog ratelimit / mediawiki log producers ratelimit
Open, Needs TriagePublic

Description

Rsyslog has introduced ratelimit in version 8.2602.0 (available in forky)

This has potential to be a drop-in improvement to the long standing issue where an error/bug/etc will spike log volume on the mw-k8s topic and cause log ingest to lag across all mediawiki channels and levels.

With this we could start setting rate limits before logs are produced to Kafka, based on combinations of log fields. e.g. each unique [channel]+[level] combination should not exceed N logs per M minutes.

Rough todo

  • backport >= 8.2602.0 package to trixie
  • update rsyslog in container
  • draft/test POC ratelimit configuration
  • establish sensible log rate limit scheme
  • set up metrics/monitoring as related to ratelimit, consider alerting/logging/etc when enforced etc.
  • deploy initial ratelimit config

Event Timeline

Mentioned in SAL (#wikimedia-operations) [2026-09-28T20:47:47Z] <herron> uploaded rsyslog 8.2608.0-4~wmf13+1 to trixie-wikimedia T438375

Change #1345655 had a related patch set uploaded (by Herron; author: Herron):

[operations/docker-images/production-images@master] upgrade rsyslog to 8.2608.0-4

https://gerrit.wikimedia.org/r/1345655

@herron The new rsyslog deb breaks the installation of new trixie hosts. The failure in rsyslog.service isn't very informative, but you can have a closer look at it at testvm2001.codfw.wmnet:

Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Scheduled restart job, restart counter is at 5.
Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Start request repeated too quickly.
Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Failed with result 'exit-code'.
Sep 29 12:54:36 testvm2001 systemd[1]: Failed to start rsyslog.service - System Logging Service.

@herron The new rsyslog deb breaks the installation of new trixie hosts. The failure in rsyslog.service isn't very informative, but you can have a closer look at it at testvm2001.codfw.wmnet:

Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Scheduled restart job, restart counter is at 5.
Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Start request repeated too quickly.
Sep 29 12:54:36 testvm2001 systemd[1]: rsyslog.service: Failed with result 'exit-code'.
Sep 29 12:54:36 testvm2001 systemd[1]: Failed to start rsyslog.service - System Logging Service.

Thanks, this is a straight ahead backport from forky but seems package dependencies weren't installed. Installing libestr0 libfastjson4 and librdkafka1 get the service up and running. Will have a closer look at dependencies

Indeed, it links against those, but doesn't have any Depends: for them:

jmm@testvm2001:~$ ldd /usr/sbin/rsyslogd

linux-vdso.so.1 (0x00007f3e6e3ed000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3e6e2c9000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f3e6e1ff000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3e6e10f000)
libestr.so.0 => /lib/x86_64-linux-gnu/libestr.so.0 (0x00007f3e6e10a000)
libfastjson.so.4 => /lib/x86_64-linux-gnu/libfastjson.so.4 (0x00007f3e6e0fa000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f3e6dfe4000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f3e6dfda000)
libyaml-0.so.2 => /lib/x86_64-linux-gnu/libyaml-0.so.2 (0x00007f3e6dfb9000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3e6dfa7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e6ddb3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3e6e3ef000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f3e6dda5000)

jmm@testvm2001:~$

There only seems to be a binary deb uploaded to apt.wikimedia.org? Please always include the full changes files with source.

The reason the Depends aren't auto-generated is likely because you are missing

Depends: ${misc:Depends},  ${shlibs:Depends}

in debian/control. The latter will auto-create Depends: based on the shlibs inforrmation from the library packages.

Fwiw it was imported like this:

apt1002:~/rsyslog/WMF_BUILD_DIR$ sudo -E reprepro -C main include trixie-wikimedia rsyslog_8.2608.0-4~wmf13+1_amd64.changes

Here's where I'm at currently: https://gitlab.wikimedia.org/repos/sre/rsyslog/-/commits/trixie-wikimedia which looks much better

WMF_BUILD_DIR$ dpkg-deb -f rsyslog_8.2608.0-4~wmf13+1_amd64.deb Depends
libc6 (>= 2.38), libestr0 (>= 0.1.9), libfastjson4 (>= 0.99.8), liblognorm5 (>= 2.0.3), libsystemd0 (>= 256~rc1), libuuid1 (>= 2.16), libyaml-0-2, libzstd1 (>= 1.5.5), zlib1g (>= 1:1.1.4)

Just bumped the changelog and rebuilding, would you like to have a look at the updated deb there before uploading? Should be finished in a minute https://gitlab.wikimedia.org/repos/sre/rsyslog/-/jobs/978140

Went ahead and uploaded rsyslog 8.2608.0-4~wmf13+1.1 to fix fresh installs on trixie. Happy to take suggestions to generate/upload source packages, but so far have been following the rationale in https://wikitech.wikimedia.org/wiki/Debian_packaging_with_dgit_and_CI#Rationale_/_Further_Details

Change #1345655 merged by Herron:

[operations/docker-images/production-images@master] upgrade rsyslog to 8.2608.0-4

https://gerrit.wikimedia.org/r/1345655

Change #1346712 had a related patch set uploaded (by Herron; author: Herron):

[operations/deployment-charts@master] Test new rsyslog image on mw-experimental and mw-web canary

https://gerrit.wikimedia.org/r/1346712

Porting over the incident follow-up tracking: this was noted as part of 2025-03-12_ExternalStorage_Database_Cluster_Overload

Change #1352121 had a related patch set uploaded (by Herron; author: Herron):

[operations/deployment-charts@master] Test new rsyslog image on mw-experimental

https://gerrit.wikimedia.org/r/1352121

Change #1352121 merged by jenkins-bot:

[operations/deployment-charts@master] Test new rsyslog image on mw-experimental

https://gerrit.wikimedia.org/r/1352121