Как вы реализовали управление журналами на своих серверах?

Я пытаюсь выяснить, как другие люди внедряют свои системы управления журналами.

У меня 20-30 серверов Linux и несколько окон Windows (большинство из них виртуализированы). Мы используем множество сценариев Perl и Bash для выполнения большинства наших автоматизированных заданий, и я пытаюсь стандартизировать их ведение журналов.

Я просматривал log4perl и log4sh для регистрации сценариев и syslog-ng, чтобы получить все журналы на централизованном сервере журналов. Я также читал о Spunk, хотя звучит так, будто корпоративная версия довольно дорогая, и я могу превысить лимит свободной лицензии на всех своих серверах.

Я видел другие инструменты, такие как swatch и logcheck, но я не совсем уверен, как все эти части сочетаются друг с другом ... Любые рекомендации будут с благодарностью!

У меня около 30 серверов, и я просто использую системный журнал для отправки всех журналов на один сервер регистрации. Для резервного копирования все машины также настроены на локальное хранение собственных журналов в течение нескольких дней, используя logrotate для ротации и удаления старых журналов.

Каждый из моих серверов приложений запускает небольшой скрипт на perl для отправки своих журналов в системный журнал, который затем пересылается на хост-хост (скрипт 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;

Хотя я еще не реализовал это, я планирую переместить все мои машины, генерирующие журналы, на rsyslog и внедрить сервер бастионного типа, который будет функционировать как сборщик системных журналов. Оттуда, я думаю, бесплатная версия Splunk может сделать все, что мне нужно, чтобы извлечь информацию.

Теперь просто реализовать это ...

Я использую центральный хост системного журнала. Каждая пограничная система отправляет * .debug на центральный логхост. Центральный узел системного журнала запускает syslog-ng и имеет правила для разделения журналов, чтобы каждая машина генерировала свои собственные файлы, названные для этого дня. Он также сбрасывает все в один файл, для которого я запускаю потомка logcheck.sh.

Один раз в день я запускаю устройство сжатия журналов, которое архивирует все журналы старше 7 дней и удаляет все, что старше 28 дней. Между ними он дает журналам ожидаемый срок службы 35 дней на сервере, а это означает, что все журналы должны делать это в ежемесячные резервные копии, где они могут быть восстановлены на срок до двух лет.

Это интенсивное хранение, но, кажется, лучший способ обеспечить покрытие.

Для централизованного ведения журнала я очень рекомендую LogZilla . Мы используем его уже больше года, и нам это очень нравится. Пользовательский интерфейс чрезвычайно прост в освоении и использовании, а установка заняла у меня около часа.

Даже если вы этого не сделаете, вы действительно должны попытаться уйти от мониторинга на основе сценариев, поскольку это именно то, что вы получаете ... мониторинг. То, что вы должны попытаться достичь, это управление. Устранение проблем на ведущих собеседниках и т. Д. Значительно уменьшит количество «пожаров», вызванных мониторингом на основе сценариев. Вот очень хорошая статья об управлении системным журналом:

http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html

Мы используем устройство от LogLogic для ведения журнала предприятия. Он основан на системном журнале, поэтому все * nix-боксы не имеют проблем с его использованием; есть небольшое приложение, которое должно быть установлено на серверах Windows. Я могу искать все, что захочу, включая запросы REGEX, и кажется, что он способен справиться с небольшой нагрузкой (одна наша установка в Active Directory генерирует ошеломляющий объем трафика).

Что касается централизованного сервера журналов, вы можете взглянуть на мой проект Octopussy .

В начале работы много, но после вы можете многое сделать с этими журналами!

Вот учебник, который я написал, который охватывает все аспекты централизованного ведения журналов и анализа.

Ссылка: http://crunchtools.com/centralizing-log-files/