Я пытаюсь понять, как другие люди реализуют свои системы управления журналами.
У меня 20-30 серверов Linux и несколько окон Windows (большинство из них виртуализированы). Мы используем множество сценариев Perl и Bash для выполнения большинства наших автоматизированных задач, и я пытаюсь стандартизировать их ведение журнала.
Я искал log4perl и log4sh для регистрации скриптов и syslog-ng, чтобы получить все журналы на централизованном сервере регистрации. Я также читал о splunk, хотя похоже, что корпоративная версия довольно дорогая, и я могу превысить лимит бесплатной лицензии для всех моих серверов.
Я видел другие инструменты, такие как swatch и logcheck, но я не совсем уверен, как все эти части сочетаются друг с другом ... Будем признательны за любые рекомендации!
У меня около 30 серверов, и я просто использую прямой системный журнал для отправки всех журналов на один сервер журналов. Для резервного копирования все машины также настроены на хранение своих собственных журналов локально в течение нескольких дней с использованием logrotate для ротации и удаления старых журналов.
Каждый из моих серверов приложений запускает небольшой сценарий Perl для отправки своих журналов в syslog, который затем пересылается на хост (сценарий Perl ниже).
Затем на loghost у нас есть несколько настраиваемых скриптов, похожих на logcheck, которые в основном отслеживают входящие журналы на предмет чего-либо подозрительного.
У нас также есть вся электронная почта с каждого хоста, отправляемая в одно место, поэтому, если какая-либо программа жалуется таким образом, мы получаем все сообщения. Теоретически он может попасть в единственный почтовый ящик, который программа может обработать и проанализировать.
Вот мой сценарий Perl для ведения журнала. Он работает, передавая вывод программы по конвейеру, а затем он записывает вывод в системные журналы и выплевывает его обратно, чтобы вы могли отправить его в другое место (я отправляю в multilog). Вы также можете указать ему параметр -q, чтобы просто перейти в системный журнал.
#!/usr/bin/perl
use Sys::Syslog;
use Getopt::Long;
$SERVER_NAME = `hostname`;
chomp $SERVER_NAME;
$FACILITY = 'local0';
$PRIORITY = 'info';
GetOptions ('s=s' => \$SERVER_NAME, 'f=s' => \$FACILITY, 'p=s' => \$PRIORITY, 'q+' => \$quiet);
#print "$SERVER_NAME\n$FACILITY\n$PRIORITY\n";
#Sys::Syslog::setlogsock('unix');
openlog ($SERVER_NAME,'ndelay',$FACILITY);
if (!($quiet)) {syslog($PRIORITY,"Logging Started -- Logger version 1.1");}
$| = 1;
while (<>) {
if (!($quiet)) {print $_ unless $_ =~ /^\s+$/};
chomp;
syslog($PRIORITY,$_) if $_;
}
closelog;
$| = 0;
Я использую центральный хост системного журнала. Каждая пограничная система отправляет * .debug на центральный хост. Центральный хост syslog запускает syslog-ng и имеет правила для разделения журналов, чтобы каждая машина создавала свои собственные файлы, названные для этого дня. Он также сбрасывает все в один файл, с которым я запускаю потомок logcheck.sh.
Раз в день я запускаю компактер журналов, который архивирует все журналы старше 7 дней и удаляет все, что старше 28 дней. Между ними ожидаемый срок службы журналов на сервере составляет 35 дней, а это означает, что все журналы должны попадать в ежемесячные резервные копии, где их можно восстанавливать на срок до двух лет.
Это требует много места для хранения, но кажется, что это лучший способ обеспечить покрытие.
Хотя я еще не реализовал это, я планирую переместить все мои машины, генерирующие журналы, на rsyslog и реализовать сервер типа бастиона, который будет функционировать как сборщик системных журналов. Оттуда, я думаю, бесплатная версия Splunk может делать все, что мне нужно, чтобы получать информацию.
Теперь просто реализуем это ...
Для централизованного ведения журнала я очень рекомендую LogZilla. Мы используем его уже больше года и нам он очень нравится. Пользовательский интерфейс чрезвычайно прост в освоении и использовании, установка заняла у меня около часа.
Даже если вы этого не сделаете, вам действительно стоит попытаться уйти от мониторинга на основе сценариев, поскольку это именно то, что вы получаете ... мониторинг. Вы должны попытаться достичь Управления. Устранение проблем с Top Talkers и т. Д. Значительно сократит количество "пожаров", вызванных мониторингом на основе скриптов. Вот очень хорошая статья об управлении системным журналом:
http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html
Мы используем устройство LogLogic для ведения журналов на нашем предприятии. Он основан на системном журнале, поэтому у всех устройств * nix нет проблем с его использованием; есть небольшое приложение, которое необходимо установить на серверах Windows. Я могу искать все, что захочу, включая запросы REGEX, и, похоже, он способен справиться с довольно большой нагрузкой (одна только наша установка Active Directory генерирует ошеломляющий объем трафика).
Для централизованного сервера журналов вы можете взглянуть на мой Осьминог проект.
Вначале это большая работа, но после вы можете многое сделать с этими журналами!
Вот написанное мною руководство, охватывающее все аспекты централизованного ведения журнала и анализа.
Ссылка на сайт: http://crunchtools.com/centralizing-log-files/