rsyslogd сильно вантажить процесор (rsyslogd High cpu usage)

Rsyslog є покращеною версією демона syslogd і з назви зрозуміло, що він займається збором зведеної інформації про стан системних демонів з подальшим записом в файли. Буває rsyslogd довго займає процесор від 20% і вище.

Деяким допомагає переустановка або оновлення rsyslogd, а в деяких випадках rsyslogd воліють видаляти з наступною заміною на інший демон збору системної інформації, але в корені все це проблеми не вирішує!

Про видалення rsyslogd і мови бути не може имхо його видалення позбавить нас можливості збору і аналізу інформації про стан системи! Хоча в будь-якому випадку з вище перерахованих заходів нам не завадить оновлення і оновлюватися ми будемо з оригінального сховища до самої свіжої і актуальної версії (поточна 7.2.6):

cd / etc /yum.repos.d / wget http: // rpms.adiscon.com /rsyslogall.repo vi rsyslogall.repo # add this line in section "[rsyslog-v7-stable]" if use yum-priorities priority = 1 sh-4.1 # yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning repos: atomic base epel extras nginx rsyslog-v7-stable updates Cleaning up Everything Cleaning up list of fastest mirrors sh-4.1 # yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors epel / metalink | 18 kB 00:00 * atomic: www7.atomicorp.com * base: centos-mirror.rbc.ru * epel: fedora-mirror01.rbc.ru * extras: centos-mirror.rbc.ru * updates: centos-mirror. rbc.ru atomic | 1.9 kB 00:00 atomic / primary_db | 520 kB 00:01 base | 3.7 kB 00:00 base / primary_db | 4.4 MB 00:03 epel | 4.2 kB 00:00 epel / primary_db | 5.0 MB 00:04 extras | 3.5 kB 00:00 extras / primary_db | 19 kB 00:00 nginx | 1.3 kB 00:00 nginx / primary | 5.2 kB 00:00 nginx 37/37 rsyslog-v7-stable | 2.5 kB 00:00 rsyslog-v7-stable / primary_db | 55 kB 00:00 updates | 3.5 kB 00:00 updates / primary_db | 1.4 MB 00:01 239 packages excluded due to repository priority protections Setting up Update Process Resolving Dependencies -> Running transaction check ---> Package rsyslog.x86_64 0: 5.8.10- 6.el6 will be updated ---> Package rsyslog.x86_64 0: 7.2.6- 3.el6 will be an update -> Processing Dependency: liblognorm.so.0 () (64bit) for package: rsyslog-7.2.6- 3 .el6.x86_64 -> Processing Dependency: libjson.so.0 () (64bit) for package: rsyslog-7.2.6- 3.el 6 .x86_64 -> Processing Dependency: libestr.so.0 () (64bit) for package: rsyslog-7.2. 6 3.el 6 .x86_64 -> Processing Dependency: libee.so.0 () (64bit) for package: rsyslog-7.2.6- 3.el6. x86_64 -> Running transaction check ---> Package json-c.x86_64 0: 0.9 -4 .el6 will be installed ---> Package libee.x86_64 0: 0.4.1- 1.el6 will be installed --- > Package libestr.x86_64 0: 0.1.5- 1.el6 will be installed ---> Package liblognorm.x86_64 0: 0.3.6- 1.el6 will be installed -> Finished Dependency Resolution Dependencies Resolved ===== ================================================== ========================= Package Arch Version Repository Size ==================== ================================================== ========== Updating: rsyslog x86_64 7.2.6- 3.el6 rsyslog-v7-stable 768 k Installing for dependencies: json-c x86_64 0.9 -4 .el6 rsyslog-v7-stable 36 k libee x86_64 0.4.1- 1.el6 rsyslog-v7-stable 21 k libestr x86_64 0.1.5- 1.el6 rsyslog-v7-stable 7.9 k liblognorm x86_64 0.3.6- 1.el6 rsyslog-v7-stable 26 k Transaction Summary == ================================================== ============================ Install 4 Package (s) Upgrade 1 Package (s) Total downlo ad size: 860 k Is this ok [y / N]: y Downloading Packages: (1/5): json-c- 0.9 -4 .el6.x86_64.rpm | 36 kB 00:00 (2/5): libee-0.4.1- 1.el6.x86_64.rpm | 21 kB 00:00 (3/5): libestr-0.1.5- 1.el6.x86_64.rpm | 7.9 kB 00:00 (4/5): liblognorm-0.3.6- 1.el6.x86_64.rpm | 26 kB 00:00 (5/5): rsyslog-7.2.6- 3.el6.x86_64.rpm | 768 kB 00:02 --------------------------------------------- ----------------------------------- Total 222 kB / s | 860 kB 00:03 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing: libestr-0.1.5- 1.el6.x86_64 1/6 Installing: libee-0.4.1- 1.el6.x86_64 2/6 Installing: liblognorm -0.3.6- 1.el6.x86_64 3/6 Installing: json-c- 0.9 -4 .el6.x86_64 4/6 Updating: rsyslog-7.2.6- 3.el6.x86_64 5/6 warning: / etc / sysconfig / rsyslog created as / etc / sysconfig /rsyslog.rpmnew Cleanup: rsyslog-5.8.10- 6.el6.x86_64 6/6 Verifying: libee-0.4.1- 1.el6.x86_64 1/6 Verifying: json-c - 0.9 -4 .el6.x86_64 2/6 Verifying: libestr-0.1.5- 1.el6.x86_64 3/6 Verifying: rsyslog-7.2.6- 3.el6.x86_64 4/6 Verifying: liblognorm-0.3.6 - 1.el6.x86_64 5/6 Verifying: rsyslog-5.8.10- 6.el6.x86_64 6/6 Dependency Installed: json-c.x86_64 0: 0.9 -4 .el6 libee.x86_64 0: 0.4.1- 1 .el6 libestr.x86_64 0: 0.1.5- 1.el6 liblognorm.x86_64 0: 0.3.6- 1.el6 Updated: rsyslog.x86_64 0: 7.2.6- 3.el6 Complete! sh-4.1 # service rsyslog stop Shutting down system logger: [OK] sh-4.1 # service rsyslog start Starting system logger: rsyslogd: error: option -c is no longer supported - igno red [OK] vi / etc / sysconfig / rsyslog #SYSLOGD_OPTIONS = "- c5" service rsyslog restart

Отже ... Обновилися з версії 5.8.10 до 7.2.6 �� що? Допомогло? Нефига не допомогло! rsyslogd продовжує пожирати час CPU ...

Значить тепер йдемо в / var / log і моніторимо файли, дивимося на розмір файлів журналу і ось воно ... - / var / log / messages займає більше 15 ГБ!; (Чекаємо ще 5-10 хв, перевіряємо, і тепер / var / log / messages вже важить більше 16 ГБ! Читати його не намагаємося имхо зависнемо!

Видаляємо rm / var / log / messages перезапускаємо сісьлог service rsyslog restart і відразу ж читаємо less / var / log / messages:

Apr 5 5:45:04 myhost kernel: [FW SYN DROP]: IN = eth0 OUT = MAC = 00: 50: 56: a8 7 8: f9: 00: 04: 23: b7: d0: d2: 08: 00 SRC = 80.89.192.62 DST = 93.170.129.132 LEN = 48 TOS = 0x00 PREC = 0x20 TTL = 116 ID = 31712 DF PROTO = TCP SPT = 55251 DPT = 80 WINDOW = 8192 RES = 0x00 S YN URGP = 0 ... ............ Apr 5 6:22:08 myhost kernel: [FW SYN DROP]: IN = eth0 OUT = MAC = 00: 50: 56: a8 7 8: f9: 00: 04: 23: b7: d0: d2: 08: 00 SRC = 95.32.239.199 DST = 93.170.129.132 LEN = 48 TOS = 0x0 0 PREC = 0x00 TTL = 119 ID = 6373 DF PROTO = TCP SPT = 24617 DPT = 80 WINDOW = 65535 RES = 0x00 SYN URGP = 0

В 5:45:04, тобто за 1 сек., я нарахував 100-300 і більше SYN-пакетів, а це вже явна ознака присутності SYN-Флудерастам. Відрубавши 80.89.192.62 на арену вийшов 95.32.239.199, який був менш активний, але теж з ознаками аномальність.

Незважаючи на те, що система обмежувала одночасні SYN-підключення та містила ряд інших антіДДОС налаштувань, вузьким місцем виявилося логирование перевищення ліміту на одночасні SYN-підключення з одного ІП, а отже звідси і підвищене споживання ресурсів CPU демоном rsyslogd, якому доводилося за одну секунду реєструвати 200-300 і більше подій.

Звідси висновок: або вимкнути реєстрацію подій про перевищення ліміту на одночасні SYN-підключення або ж частіше аналізувати події, а також вживати своєчасних і адекватних заходів.

Але як завжди є одне "АЛЕ" - відключення логування перевищення ліміту на одночасні SYN-підключення не дозволить виявити легітимні ІП пошукових роботів, які можуть регулярно змінюватися! Тобто для діапазонів ІП належать пошуковим роботам ми знімаємо будь-які обмеження або ставимо м'якші обмеження, а їх ІП (діапазони) можуть змінюватися або доповнюватися!

про автора

Ще статті автора