Linux: logwatch (8) является слишком шумным. Как я могу управлять уровнем шума?
Я знаю, что Вы говорите о SQL 2005, но если можно обновить до SQL 2008, Вы могли telnet в к подсказке powershell и использовать сценарии PS для управления sql...
Иначе osql и sqlcmd (как ранее упомянуто) являются, вероятно, Вашими лучшими выборами. Необходимо будет все еще выполнить сервер telnet на сервере, хотя войти.
В целом, доступная документация для Logwatch испытывает недостаток в соответствующем объяснении и часто слишком неопределенна. Я соединил некоторые полезные примеры и уменьшил шум Logwatch на более чем 95%.
Вот то, что я нашел.
Следует иметь в виду, что можно найти некоторую документацию Logwatch в /usr/share/doc/logwatch-*/HOWTO-Customize-LogWatch, и это содержит несколько полезных примеров.
На RHEL/CentOS/SL значение по умолчанию logwatch конфигурация находится под
/usr/share/logwatch/default.conf/logwatch.confЭти настройки могут быть переопределены путем размещения локальной конфигурации под
/etc/logwatch/conf/logwatch.conf. Поместите следующее в тот файл, чтобы сказать logwatch полностью игнорировать услуги как 'httpd' и ежедневные проверки использования диска:# Don't spam about the following Services Service = "-http" Service = "-zz-disk_space"Иногда я не хочу полностью отключать logwatch для определенного сервиса, я просто хочу точно настроить результаты для создания их менее шумными.
/usr/share/logwatch/default.conf/services/*.confсодержит конфигурацию по умолчанию для сервисов. Эти параметры могут быть переопределены путем размещения локальной конфигурации под/etc/logwatch/conf/services/$SERVICE.conf. К сожалению, способность logwatch здесь ограничена, и многие logwatch исполняемые файлы полны недокументированного Perl. Ваш выбор состоит в том, чтобы заменить исполняемый файл чем-то еще или попытаться переопределить некоторое использование настроек/etc/logwatch/conf/services.Например, у меня есть сканер безопасности, который выполняет сканирования по сети. Как тестовый прогон, сканер безопасности генерирует много сообщений об ошибках в журналах приложения. Я хотел бы, чтобы logwatch проигнорировал ошибки от моих сканеров безопасности, но все еще уведомил меня относительно нападений от других хостов. Это покрыто более подробно в Logwatch: Проигнорировать определенного дюйм/с для проверок SSH & PAM?. Чтобы сделать это, я помещаю следующее под
/etc/logwatch/conf/services/sshd.conf:# Ignore these hosts *Remove = 192.168.100.1 *Remove = X.Y.123.123 # Ignore these usernames *Remove = testuser # Ignore other noise. Note that we need to escape the () *Remove = "pam_succeed_if\(sshd:auth\): error retrieving information about user netscan.*"
logwatch также позволяет Вам разделять произведенный из logwatch электронных писем путем размещения регулярных выражений в
/etc/logwatch/conf/ignore.conf. HOWTO-Customize-LogWatch говорит:ignore.conf: Этот файл указывает регулярные выражения, которые при соответствии выводом logwatch подавят согласующий отрезок длинной линии, независимо от которого выполняется сервис.
Однако у меня не было большой удачи с этим. Для моих требований нужен условный оператор, который является чем-то как, 'Если существуют предупреждения системы безопасности из-за моего сканера безопасности, то не печатайте вывод. Но если существуют предупреждения системы безопасности от моего сканера безопасности и от некоторых плохих парней, то печатают полезные части - заголовок, в котором говорятся "Отказавшие логины от": дюйм/с плохих хостов, но не дюйм/с сканеров'.
Прищемите его в источнике (Как предложено @user48838). Эти сообщения генерируются некоторым приложением, и затем Logwatch счастливо извергает результаты Вам. В этих случаях можно изменить приложение для входа меньше.
Это не всегда желательно, потому что иногда Вы хотите, чтобы полные журналы были отправлены куда-нибудь (на Центральный сервер системного журнала, центральный сервер IDS, Splunk, Nagios, и т.д.), но Вы не хотите, чтобы logwatch послал Вам по электронной почте об этом с каждого сервера каждый день.
Да - logwatch является часто слишком шумным. Вы уже упомянули, что отключили проверки полностью.
Если Вы не хотите делать это, необходимо предотвратить определенные события для появления. Например - не интересно, если nagios соединяется через ssh с системой демилитаризованной зоны. Но, интересно, если существуют другие логины через ssh.
Мы используем rsyslog вместо ksyslogd (сначала устанавливают rsyslog, затем удаляют ksyslogd). С rsyslog можно подстроить то, что переходит к журналам и что не (например, создают выражение, которое отбрасывает сообщения от sshd cointaining "nagios соединенный"). Тот путь logwatch сообщит полезную информацию только.
Другой случай мог бы быть xinetd - я не хочу быть информированным об успешных подключениях - это может быть настроено в xinetd itselv - не отключая logwatch-проверку на xinetd.
Вы рассмотрели образование воронок почтовых сообщений о состоянии к listserver, возможно, тот, который может предоставить обзоры на основе программируемых атрибутов размера и/или продолжительности/возраста? Подход не уменьшает объем входа быть отправленным по электронной почте, но может управлять суммой отдельных электронных писем путем пакетной обработки для сокращения частоты пользования электронной почтой.
Один из вариантов - ограничение скорости с использованием чего-то вроде http://www.iis.net/downloads/microsoft/dynamic-ip-restrictions , которое может быть установлен, чтобы блокировать нарушающий IP-адрес на установленный период времени.
Вы, конечно, хотели бы определить базовые параметры типичных запросов / секунду / IP, прежде чем вводить что-то подобное в производство, но это должно помешать одному пользователю сделать что-то подобное снова.
Разница в том, что вы можете использовать * Remove сколько угодно раз, но с * OnlyContains вы должны использовать его один раз, если вы хотите что-то или что-то еще, или что-то еще. . Итак, для нескольких значений вы делаете * OnlyContains = "testuser | testuser2 | testuser3"
Недавно мне потребовалось отключить вывод службы sshd. Некоторые разделы были довольно длинными, и их нельзя было контролировать с помощью установки уровня детализации.
Это не идеальное решение, но я переопределил сценарий sshd , скопировав его отсюда: / usr / share / logwatch / scripts / services / sshd сюда: / etc / logwatch / scripts / services / sshd
Конечно, теперь вам нужно следить за любыми обновлениями этого файла сценария. , но он дает вам очень точный контроль над тем, что выводится. В качестве альтернативы, я полагаю, вы могли бы передать вывод logwatch через инструмент вроде awk или sed , чтобы вырезать то, что вам не нужно, но это казалось сложнее мне.
У меня был тот же вопрос о UNIX & Linux Stackexchange , и вот ответ, который я исправил для себя:
Вы можете указать logwatch, чтобы он смотрел на 7 дней вместо 1 день, изменив параметр Range в вашем logwatch.conf :
Range = between -7 days and -1 days
. Вы можете указать logwatch работать еженедельно, а не ежедневно, переместив его из еженедельного каталога cron в ежедневный cron каталог:
mv /etc/cron.daily/00logwatch /etc/cron.weekly/
Спасибо @JeffSchaller