Приветствую, читатель моего блога. Давненько я не писал статей. Много жизненных перемен... Сегодняшняя статья будет посвящена syslog , а точнее rsyslog , который активным образом внедряется вместо старенького syslogd (он же sysklogd) в последних версиях дистрибутивов (например, , и др.). Базовое описание работоспособности я приводил в соответствующей статье. Поэтому перед прочтением нижеописанного я очень советую прочитать . На текущий момент для меня стоит задача собирать системные журналы syslog с сетевого оборудования в количестве ~100 хостов с последующим увеличением их количества. Реализацией данного функционала я и постараюсь заняться в данной статье, предварительно описав и . Все это дело будет описано на базе Debian 6, в других дистрибутивах, при наличии опыта, с минимумом движений напильником, думаю что тоже не составит большого труда настроить. Итак, начнем...

Введение rsyslog

Как я уже сказал, rsyslog стал дефолтным пакетом в большинстве дистрибутивов Linux (возможно, во всех). Rsyslog полностью соответствует протоколу syslog , описанному в , а так же содержит некоторые дополнительные фичи. Такие как TCP транспорт, фильтрацию и сортировку сообщений, хранение сообщения в СУБД, шифрование и мн.др. В статье я постараюсь рассмотреть описание , описание управления демоном rsyslogd и .

Установка rsyslogd

Установка rsyslog (если по какой-то причине он не установлен по умолчанию) сводится к одной команде:

Aptitude install rsyslog # в красной шляпе возможен вариант yum install rsyslog

Конфигурационные директивы (Configuration Directives)

Конфигурационные директивы иногда называют глобальными директивами, они задают общие параметры работы демона rsyslogd . Директива имеет формат $Директива параметр

########################### #### GLOBAL DIRECTIVES #### ########################### # Задает использование классического timestamp формата (Мес ДД ЧЧ:ММ:СС). # Для включения unix-формата timestamps, необходимо закомментировать строку. $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Устанавливает по умолчанию для лог-файлов. $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Задает размещение spool и статических файлов (для хранения таких файлов, как очередь сообщений) $WorkDirectory /var/spool/rsyslog # # Инклюдит все конфиги в формате *.conf из каталога /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf

С наиболее полным списком глобальных директив можно ознакомиться .

Шаблоны (Templates) rsyslog

Очень важной и ключевой особенностью rsyslogd является возможность использования шаблонов. Template позволяет: 1. задавать формат выводимой информации, 2. использовать динамические имена файлов логов на основании какого-либо правила. На самом деле, все выходные сообщения в rsyslogd формируются на основе шаблонов. Тут может возникнуть соответствующий вопрос - как же вывод формируется, если не указать никаких шаблонов в rsyslog.conf (ведь по умолчанию не указано никаких шаблонов)? Все просто. Имеются некоторые шаблоны (взятые из совместимые со и статично прописанные в исходники rsyslog). Подтверждение этого дела можно найти в файле исходного кода syslogd.c , поиском по строке "template_" (наткнетесь на /* hardcoded standard templates (used for defaults) */). Шаблоны должны быть заданы до использования в правилах.

Cинтаксис template

В целом, структуру шаблона можно представить в следующем виде синтаксисе:

$template имя_шаблона ,описание_шаблона [,опции (по_необходимости)]

Давайте разберем каждый пункт. $template - указывает, что далее пойдет описание шаблона. имя_шаблона - произвольное значение понятно описывающее, что за шаблон и для чего (имя будет использоваться в для обращения к шаблону). опции - может принимать значение sql и sqlstd, это заставляет отформатировать конечный результат выполнения шаблона в вид, пригодный для MySQL или стандартный SQL соответственно (фактически - заменяет некоторые спецсимволы в syslog сообщении в формат, поддерживаемый SQL-сервером). Опции применяются только для шаблонов для вывода в sql.

описание_шаблона заключается в кавычки. В шаблонах в кавычках любой текст воспринимается буквально (как есть), кроме того текста, который заключен в знаки процентов (%текст% ). Такой текст является переменной и позволяет "получить доступ" к внутреннему содержимому пришедшего сообщения и тем самым добиться всяких веселых фич по модификации). Так же, в кавычках может использоваться т.н. escape-последовательности в виде обратной косой черты и некоего символа за чертой (например, \n - новая строка, \7 - ...).

Применение переменных в шаблонах rsyslog

Давайте разгребем структуру значений, указываемых в %процентах%.

%имя_proper [:начало_строки :конец_строки :опции [:fieldname]]%

имя_proper (оно же имя_свойства , оно же имя_переменной ) - задает имя свойства (свойство в данном контексте можно рассматривать как некоторое свойство\поле syslog сообщения, проходящего сквозь демона), вот некоторые наиболее используемые свойства rsyslog :

msg - тело сообщения
hostname - имя хоста\ip из сообщения
fromhost - имя хоста, от которого пришло сообщение
fromhost-ip - адрес хоста, от которого пришло сообщения (127.0.0.1 для локальных сообщений)
syslogtag - имя и номер процесса (" rsyslogd:"), который выдал сообщение (извлекается из сообщения)
programname - имя процесса, который выдал сообщение (извлекается из сообщения)
pri - источник и приоритет, в виде числа
pri-text - декодированные источник и приоритет (facility .priority , например syslog.emer)
syslogfacility - только источник в виде числа
syslogfacility-text - только декодированный источник ("local0")
syslogseverity - только приоритет в виде числа
syslogseverity-text - только декодированный уровень ("debug")
timegenerated - время получения (с высоким разрешением)
timereported - время, извлечённое из сообщения
inputname - имя входного модуля
$hour, $minute - текущее время
$myhostname - имя хоста обработки

Как видно, некоторые свойства начинаются с знака доллара - они считаются локальными\системными.

Далее - опции . Опции позволяют модифицировать переменную в границе от знака процента до знака процента. Можно применять одновременно несколько опций, через запятую. Если указать несколько противоречащих (например uppercase, lowercase), то будет применена последняя указанная (lowercase). Вот некоторые опции:

uppercase - преобразование к верхнему регистру
lowercase - преобразование к нижнему регистру
date-mysql - преобразовать в формат даты MySQL
space-cc - заменить управляющие символы пробелами
drop-cc - удалить управляющие символы

fieldname - данное поле доступно с версии 6.3.9+ и имеет очень специфичный характер. Можно ее забыть...

Как видно из приведенного выше шаблона переменной, значения из фигурных скобок указываются по желанию, то есть можно указать просто, например %hostname%. Но если будут применяться опции , то необходимо указать и предыдущие пустые поля, например %hostname:::lowercase%. Между двоеточиями пропущены поля начало_строки и конец_строки . При этом, fieldname почему-то в качестве пустого - не указывается.

Шаблоны, которые хардово запрограммированы в rsyslog (но которые можно изменить директивой $ActionFileDefaultTemplate ):

RSYSLOG_SyslogProtocol23Format - формат, определённый в проекте стандарта IETF ietf-syslog-protocol-23, соответствует шаблону:

"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n\"

RSYSLOG_FileFormat - традиционный формат журнала, с добавлением долей секунды и зоны, соответствует шаблону:

"%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"

RSYSLOG_TraditionalFileFormat - традиционный формат журнала для записи в файл, соответствует следующему шаблону:

"%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"

RSYSLOG_ForwardFormat - традиционный формат журнала для передачи с добавлением долей секунды и зоны, соответствует шаблону:

"<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

RSYSLOG_TraditionalForwardFormat - традиционный формат журнала для передачи на удалённый сервер

"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

Правила сортировки rsyslog (Rule line)

Каждая строка правил сортировки имеет классический формат, как и в обычном сислоге. Для понимания, что и как, необходимо почитать статью . Кратко: правило состоит из селекотора и действия , разделенных пробелом или табулятором. Селектор в свою очередь состоит из источника и приоритета . Каждое сообщение сверяется с селектором из каждого правила последовательно, если селектор сообщения и правила совпадает, то выполняется указанное действие. При этом, после первого совпадения - обработка не останавливается. Перед действием , мессадж преобразуется в соответствии с шаблоном (шаблон по умолчанию, заданный в соответствующей директиве (заменяющий шаблон по умолчанию), заданный в данном действии шаблон - один из трех).

К стандартным возможностям селекторов syslog добавились некоторые дополнительные возможности (напомню, что классически селектор - это источник.приоритет , он же facility .priority ). В rsyslog в качестве селектора можно использовать значения . В rsyslog применение переменных в селекторе называется Filters (фильтры) . Выше в статье, а так же в описан классический подход к фильтрации на основе источник.приоритет (т.н."traditional" severity and facility based selectors ). Кроме традиционной фильтрации существует следующие виды фильтрации : RainerScript-based filters (фильтрация на основе языка RainerScript - фактически обычный if - then - else), property-based filters (фильтрация на основе свойств сообщения (как в )). Давайте рассмотрим оба:

Фильтрация RainerScript (RainerScript-based filters)

Как я уже сказал, RainerScript - это классический язык на основе if then else. В rsyslog RainerScript поддерживает вложенность условий, арифметические, логические и строковые операции. В целом, синтаксис следующий:

if условие then блок_действий else блок_действий

Соответственно, if, then - это обязательные операторы, определяющие конструкцию условия, else - по необходимости. блок_действий - может содержать одно действие (), либо вложенный блок условий. Если блок условий содержит несколько действий, то он заключается в скобки. условие - содержит условие отбора сообщений для блока_действий . В условии можно использовать:

логические выражения (and, or, not), а так же группировку данных выражений в виде: not условие0 and (условие1 and условие2) .
переменные (properties) - переменные указываются в виде $имя_переменной (например $hostname или $msg)
операции сравнения (== - равно, != - не равно, > - больше, < - меньше, <= - меньше или равно, >= - больше или равно, (!)contains - (не)содержит, (!)startswith - (не)начинается с)
комментарии /* комментарии */ (сомнительный пункт...нужно ли его экранировать как в bash ???)

Cisco

as53xx231#conf t Enter configuration commands, one per line. End with CNTL/Z. as53xx231(config)#logging 10.0.0.1 as53xx231(config)#exit

VMware ESXi

Для старенького гипервизора:

В /etc/syslog.conf необходимо добавить следующее:

*.* @10.0.0.1 # в файерволе необходимо разрешить syslog и сохранить это: esxcfg-firewall -o 514,udp,out,syslog esxcfg-firewall -l # перезапускаем syslog service syslog restart

В последних версиях гипервизора все делается через гуишного клиента. В настройках гипервизора Advansed -> Syslog -> remote указать адрес rsyslog сервера.

Хранение журнала rsyslog в СУБД MySQL

В Debian настройка хранения в базе данных мега простая (почти как в вендовозе)). В целом, достаточно установить пакет rsyslog-mysql. При этом, установщик кладет модуль ommysql.so в каталог /usr/lib/rsysloul/spang/ и запускает мастер настройки, который запрашивает пароль администратора MySQL, создает отдельного пользователя и просит указать для него пароль. Создает соответствующую базу из скрипта /usr/share/dbconfig-common/data/rsyslog-mysql/install/mysql. Получившиеся настройки кладет в /etc/rsyslog.d/mysql.conf. Конфиг получается из 2х строчек::

# подключение модуля: $ModLoad ommysql # отправлять все сообщения в MySQL (вспомните выше Действия (actions)) *.* :ommysql:адрес_сервера,имя_базы,имя_пользователя,пароль

Веб интерфейс для rsyslog

В качестве веб-интерфейса будем настраивать Loganalizer от adiscon. Установка веб интерфейса довольно проста. Заключается в скачивании архива, распаковке в каталог веб сервера и запуск графического мастера настройки. Итак, отсюда (http://loganalyzer.adiscon.com/downloads) качаем архив с файлами (Например: http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz). Перед настройкой, конечно же должен быть установлен Web сервер и модуль php5 (aptitude install apache2 libapache2-mod-php5). А да, еще php5-gd для отображения отчетов.

~ # # Скачиваем архив: ~ # wget http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz ~ # # распаковываем архив: ~ # tar xf loganalyzer-3.5.6.tar.gz

В текущем каталоге появится каталог loganalyzer-3.5.6, который содержит некоторую информацию, достойную прочтения:

~ # ls -l итого 12 drwxr-xr-x 3 root root 4096 Сен 20 22:51 . drwx------ 13 root root 4096 Сен 20 23:01 .. drwxrwxr-x 5 root root 4096 Сен 10 17:26 loganalyzer-3.5.6 ~ # ls -l loganalyzer-3.5.6/ итого 112 -rw-rw-r-- 1 root root 41186 Сен 10 17:26 ChangeLog drwxrwxr-x 2 root root 4096 Сен 20 23:01 contrib -rw-rw-r-- 1 root root 35497 Сен 10 17:26 COPYING drwxrwxr-x 2 root root 4096 Сен 10 17:34 doc -rw-rw-r-- 1 root root 8449 Сен 10 17:26 INSTALL drwxrwxr-x 14 root root 4096 Сен 10 17:34 src ~ # # из каталога src нам необходимо скопировать содержимое в /var/www/loganalyzer: ~ # mkdir /var/www/loganalyzer ~ # cp -r loganalyzer-3.5.6/src/* /var/www/loganalyzer ~ # # далее,необходимо создать пустой файл конфигурации, ~ # # который будет заполнен автоматически - установщиком ~ # touch /var/www/loganalyzer/config.php ~ # # зададим права на запись (после установки эти права можно убрать) ~ # chmod 666 /var/www/loganalyzer/config.php

жмахаем here

Видим, для чего мы давали права 666, нажимаем Next

Здесь выбираем желаемые настройки. Отдельного внимания требует параметр Enable User Database. Если выбрать его, то будет создана отдельная база для хранения настроек Веб-интерфейса. Так же, будет доступна возможность создавать пользователей и группы. Жмем next.

Есть маленькое дополнение - веб сервер не имеет доступа к обычным файлам в каталоге /var/log/. Поэтому, журнал может не отображаться. Чтобы решить данную проблему, необходимо добавить пользователя www-data в группу adm:

~ # usermod -G adm www-data

Кроме Loganalyzer существует так же - Logzilla, обладающая тем же функционалом. Ее тоже стоит попробовать установить, если есть желание.

Некоторые типсы и триксы для rsyslog

Иногда, когда rsyslog является сетевым сервисом для сбора удаленных логов, хранение сообщений по имени хоста неудобно или непроизводительно или может еще что-то. Чтобы отключить резолвинг ip адресов в хостнеймы, необходимо добавить параметр -x:

~ # cat /etc/default/rsyslog RSYSLOGD_OPTIONS="-c5 -x"

Для того чтобы разрешить в прохождение udp пакетов, необходимо использовать команду:

~ # iptables -A INPUT -p udp -s подсеть_источник --dport 514 -i интерфейс -j ACCEPT

Некоторые примеры правил с комментариями:

# если создаете селектор вот такого типа: if $fromhost-ip startswith "10.0.1." then /что/то # стоит обратить внимание на последнюю точку в адресе, # иначе под правило подпадут адреса из подсети 10.0.111.0, 10.0.12.0 и другие

Для централизованного сервера сбора логов с сетевых устройств, можно на сетевых устройствах установить источник (facility) в какое-либо значение из local0-local7. Это позволит удобно сортировать сообщения, пример:

# cisco: net-device-cisco#conf t Enter configuration commands, one per line. End with CNTL/Z. <...> net-device-cisco(config)#logging facility local2 <...> # rsyslog-server local2.* /var/log/remote-cisco.log & ~

Таким образом, можно удобно фильтровать локальные сообщения от удаленных.

Вот некоторый конфиг, который позволяет отправлять почтовые уведомления о событиях (!!! почтовый сервер должен принимать сообщения без аутентификации):

$ModLoad ommail $ActionMailSMTPServer адрес_smtp $ActionMailSMTPPort 25 $ActionMailFrom адрес@отправителя $ActionMailTo адрес@получателя $template mail_subject,"On host %hostname%, Error-level by serverity" $template mail_body,"Facility.Serverity: %syslogfacility%.%syslogpriority% at %timegenerated% on host: %HOSTNAME%\r\n %msg%" $ActionMailSubject mail_subject # интервал времени (пауза между письмами) $ActionExecOnlyOnceEveryInterval 10 # фильтр отбора и действие if not ($msg contains "что_то"\ or $msg contains "еще_что_то"\ or $msg contains "может_еще_что_то")\ and ($syslogseverity-text =="err"\ or $syslogseverity-text =="crit"\ or $syslogseverity-text =="alert"\ or $syslogseverity-text =="emerg")\ then:ommail:;mail_body

Траблешуттинг

Для диагностики работы syslog отлично помогает , пример команды для мониторинга:

~ # tcpdump -vvv -nn -i интерфейс udp port 514

Ну и, конечно же сам /var/log/syslog.

1. Установим rsyslog и настроим его на прием логов.

Установка:

# provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 #Devices $template RemoteHost,"/var/log/devices/%HOSTNAME%/%HOSTNAME%.log" *.* ?RemoteHost

и перезапустим rsyslog

apt-get install rsyslog

в файл /etc/rsyslog.conf добавляем строчки

logging 10.10.10.10

пересылка логов началась на 10.10.10.10

3. Настройка отправки логов с серверов Windows.

Пересылка логов осуществляется с помощью утилиты Evtsys — Eventlog to Syslog Utility .
Ищем. Качаем. Перемещаем файлы evtsys.dll и evtsys.exe в %SystemRoot%\System32 (для Windows 2008 R2 путь будет %WinDir%\sysWOW64). Запустив консоль с правами администратора, переходим в каталог %SystemRoot%\System32 (%WinDir%\sysWOW64) и набираем команду:

net start evtsys

для Windows Server 2008 R2
Заходим в реестр и меняем указанные ветки для параметра ImagePath:
Имя раздела: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\EvtSys ;
Имя раздела: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\services\EvtSys ;
Параметр: ImagePath
Тип: REG_EXPAND_SZ
Значение: %windir%\sysWOW64\evtsys.exe

4. Настройка logrotat e
Добавляем в файл /etc/logrotate.conf строчки:

00 1 * * * root logrotate /etc/logrotate.conf

Поздравляю, централизованный сборщик логов настроен!

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

Сбор логов https с помощью FiddlerCap

Установка FiddlerCap

Необходимо скачать и запустить приложение .

В открывшемся окне нажать на кнопку «Install». В строке Destination Folder будет указан путь до папки, в которую установится FiddlerCap. По умолчанию там указывается Рабочий стол.

Дождаться окончания установки и нажать кнопку «Close».

Сбор логов с помощью FiddlerCap

Найти папку FiddlerCap в той директории, которая была выбрана на этапе установки. По умолчанию FiddlerCap устанавливается на Рабочий стол. В папке FiddlerCap запустить файл «FiddlerCap.exe».

В пункте «Настройки захвата» установить три галки:

сохранять двоичные данные,
расшифровать HTTPS трафик,
хранить куки и POST формы.

Если появится предупреждение об установке сертификата, то в нем следует нажать кнопку «Да». При необходимости, сертификат будет предложено удалить при сохранении логов.

Закрыть все браузеры, открытые на компьютере. Нажать на кнопку «Начать захват». Открыть программу, при работе с которой появляется ошибка (например, Контур.Экстерн), и воспроизвести ошибку.

После того, как ошибка будет воспроизведена, необходимо нажать на кнопку «Остановить захват» в окне программы FiddlerCap. Логирование завершится.

Выбрать папку для сохранения.

Файл с логами будет сохранен в выбранной папке.

При сохранении логов появится окно с вопросом об удалении сертификата из корневого хранилища. На усмотрение пользователя можно выбрать любой вариант.

Запись сетевого трафика в Internet Explorer

Для записи сетевого трафика в Internet Explorer необходимо открыть необходимую страницу в Internet Explorer. В Internet Explorer перейти в меню «Сервис» > «Средства разработчика F12» ("Tools" > «Developer Tools F12") F12 .

Если меню «Сервис» не отображается, то нажать клавишу «Alt» на клавиатуре .

Перейти на вкладку «Сеть (Network)» > «Ctrl+4». Включить сбор сетевого трафика: в Internet Explorer 9 нажать «Начать сбор». В Internet Explorer 11 нажать на кнопку с зеленым треугольником.

Воспроизвести ошибку (например, обновить страницу, либо перейти по нужной ссылке). Сохранить собранный лог, нажав на изображение дискеты.

В ыбрать папку для сохранения, ввести имя файла, нажа ть «Сохранить». Файл будет создан в xml формате. Создание лога завершено.

Запись сетевого трафика в Mozilla Firefox

Для записи сетевого трафика в Mozilla Firefox необходимо открыть необходимую страницу в Mozilla Firefox. В IMozilla Firefox перейти в меню «Сервис» > «Разработка» > «Средства разработчика (Ctrl + Shift + I) либо нажать на клавиатуре клавишу F12 .

Перейти на вкладку «Сеть» и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Выделите любую запись из лога — нажмите по нему правой кнопкой мыши и нажмите на «Сохранить все как HAR».

Запись сетевого трафика в Google Chrome

Для записи сетевого трафика в Google Chrome необходимо открыть необходимую страницу в Google Chrome. В Google Chrome перейти в меню «Сервис» > «Дополнительные инструменты» >«Средства разработчика (Ctrl +Shift +I) либо нажать на клавиатуре клавишу F12 .

Передите в раздел Network и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Если запись логов не началась автоматически, нажмите на кнопку «Record Network Log».

Выделите любую запись из лога, нажмите по нему правой кнопкой мыши и нажмите на «Save as HAR with content».

Выберите папку для сохранения, введите имя файла, нажмите на сохранить. Файл будет сохранен в формате har.

Установка

Необходимо скач ать и запустить приложение . На предложение начать установку следует ответить утвердительно, нажав на кнопку «Да».

В открывшемся окне нажать на кнопку «Next».

В следующем окне необходимо установить переключатель «I accept the terms in the Licence Agreement» и кликнуть по кнопке «Next».

Выбрать тип установки «Typical».

Отметить пункт «Create shortcut for Microsoft Network Monitor on the desktop» (Создать ярлык на рабочем столе) и нажать на кнопку «Install».

Нажать на кнопку «Finish» для завершения установки.

После окончания установки необходимо дождаться окончания автоматической настройки компонента Microsoft Network Monitior 3.4 Parsers.

Запуск логирования

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов). Запустить программу с помощью ярлыка на рабочем столе.

В главном окне программы выбрать меню «File» > «New» > «Capture».

Нажать на кнопку «Start», после чего свернуть программу и воспроизвести ошибку.

Воспроизвести ошибку, нажать на кнопку «Stop».

В ыбрать меню «File» > «Save As», указать каталог для сохранения и имя файла и нажать на кнопку «Сохранить». Создание лога завершено.

Process Monitor

Чтобы начать логирование при помощи программы Process Monitor, необходимо выполнить следующие шаги:

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов), скач ать и запустить приложение .

После запуска программы выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «Edit» > «Clear Display». Автоматически записанный лог будет удален. Программа готова к работе.

Выбрать меню «File» > «Capture Events». Логирование будет запущено. Свернуть приложение и воспроизвести ошибку.

Восстановить приложение и выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «File» > «Save». Установить переключатель «All Events».

Кликнуть по кнопке с тремя точками справа от поля «Path», указать папку для сохранения и имя файла (рекомендуется оставить по умолчанию) и нажать на кнопку «Сохранить».

В окне параметров сохранения файла нажать на кнопку «Сохранить». Создание лога завершено.

В Badoo несколько десятков «самописных» демонов. Большинство из них написаны на Си, остался один на С++ и пять или шесть на Go. Они работают примерно на сотне серверов в четырех дата-центрах.

В Badoo проверка работоспособности и обнаружение проблем с демонами лежат на плечах отдела мониторинга. Коллеги с помощью Zabbix и скриптов проверяют, запущен ли сервис, отвечает ли он на запросы, а также следят за версиями. Кроме того, в отделе анализируется статистика демонов и скриптов, работающих с ними, на предмет аномалий, резких скачков и т.п.

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

Выбор инструментов

Мы с самого начала отмели «облачные» системы, т.к. в Badoo принято не отдавать свои данные наружу, если это возможно. Проанализировав популярные инструменты, мы пришли к выводу, что, скорее всего, нам подойдет одна из трех систем:

Splunk

В первую очередь мы попробовали Splunk. Splunk - это система под ключ, закрытое и платное решение, стоимость которого напрямую зависит от трафика, приходящего в систему. Мы ее уже используем для данных в отделе биллинга. Коллеги очень довольны.

Мы воспользовались их инсталляцией для тестов и почти сразу же столкнулись с тем, что наш трафик превышал имеющиеся и оплаченные лимиты.

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

По технической части Splunk, судя по всему, нас полностью устраивал. Но его стоимость, закрытость и неудобный интерфейс заставили нас искать дальше.

ELK: Elastic Search + Logstash + Kibana

Следующей в списке оказалась ELK. ELK - это, наверное, самая популярная на сегодняшний день система для сбора и анализа логов. И хочу сказать, что это неудивительно, т.к. она бесплатная, простая, гибкая и мощная.

ELK состоит из трех компонентов:

Elastic Search. Система хранения и поиска данных, основанная на «движке» Lucene;
Logstash. «Труба» с кучей фич, через которую данные (возможно, обработанные) попадают в Elastic Search;
Kibana. Веб-интерфейс для поиска и визуализации данных из Elastic Search.

Начать работать с ELK очень просто: достаточно скачать с официального сайта три архива, разархивировать и запустить несколько бинарников. Эта простота позволила за считаные дни протестировать систему и понять, насколько она нам подходит.

И в целом она подошла. Технически мы могли реализовать все, что нам нужно, при необходимости написать свои решения и встроить их в общую инфраструктуру.

Несмотря на то, что ELK нас полностью устраивала, был и третий претендент.

Graylog 2

В общем и целом Graylog 2 очень похожа на ELK: открытый код, легко устанавливать, тоже используется Elastic Search и может использоваться Logstash. Основное отличие в том, что Graylog 2 - система, готовая к использованию и «заточенная» конкретно на сбор логов. Своей готовностью для конечного пользователя она очень напоминаем Splunk. Здесь есть и удобный графический интерфейс с возможностью настраивать разбор строчек прямо в браузере, и ограничение доступа, и уведомления.

Но мы пришли к выводу, что ELK позволит нам сделать гораздо более гибкую систему, настроенную под наши нужды; позволит расширяться, менять компоненты. Как конструктор. Не понравилась одна часть - заменили на другую. Не хотели платить за watcher - сделали свою систему. Если в ELK все части легко можно снять и заменить, в Graylog 2 было ощущение, что какие-то части придется выдирать с корнем, а какие-то просто не получится внедрить.

Решено. Будем делать на ELK.

Доставка логов

На самом раннем этапе мы поставили обязательное требование, что логи должны и попадать в наш сборщик, и оставаться на диске. Система сбора и анализа логов - это хорошо, но любая система дает некоторую задержку, может выйти из строя и ничто не заменит тех возможностей, которые дают стандартные unix-утилиты типа grep, AWK, sort и т.д. У программиста должна остаться возможность зайти на сервер и посмотреть своими глазами, что там происходит.

Доставлять логи в Logstash мы могли следующим образом:

использовать имеющиеся утилиты из набора ELK (logstash-forwarder, а теперь уже beats). Они представляют из себя отдельный демон, который следит за файлом на диске и заливает его в Logstash;
использовать собственную разработку под именем LSD, которая у нас доставляет PHP-логи. По сути, это тоже отдельный демон, который следит за файлами с логами в файловой системе и заливает их куда-то. С одной стороны, в LSD были учтены и решены все проблемы, которые могут произойти при заливке огромного количества логов с огромного количества серверов, но система слишком «заточена» на PHP-скрипты. Нам бы пришлось ее доделывать;
параллельно с записью на диск записывать логи в стандартный для мира UNIX syslog.

Несмотря на недостатки последнего, этот подход был очень прост, и мы решили попробовать именно его.

Архитектура

Сервера и rsyslogd

Вместе с системными администраторами мы набросали архитектуру, которая показалась нам разумной: ставим один rsyslogd-демон на каждом сервере, один главный rsyslogd-демон на площадку, по одному Logstash на площадку и один кластер Elastic Search поближе к нам, к Москве, т.е. в пражский дата-центр.

В картинках один из серверов выглядел примерно так:

Т.к. в Badoo кое-где используется docker, то мы планировали прокинуть сокет /dev/log внутрь контейнера встроенными средствами.

Итоговая схема была примерно такая:

Придуманная выше схема выглядела для начала достаточно устойчивой к потере данных: каждый из rsyslogd-демонов, при невозможности передавать сообщения дальше, сохранит их на диск и отправит тогда, когда это «дальше» заработает.

Единственная потеря данных была возможна в случае, если бы не работал самый первый rsyslog-демон. Но мы не стали в тот момент уделять слишком много внимания этой проблеме. Все-таки логи - не настолько важная информация, чтобы с самого начала тратить на это много времени.

Формат строчки лога и Logstash

Logstash - это труба для данных, в которую отправляются строчки. Внутри они парсятся и уходят в Elastic Search в виде готовых для индексирования полей и тегов.

Практически все наши сервисы построены с использованием собственной библиотеки libangel, а это значит, что формат логов у них одинаковый и выглядит следующим образом:

Mar 04 04:00:14.609331 <16367> storage_file.c:1212 storage___update_dump_data(): starting dump (threaded, update)

Формат состоит из общей части, которая неизменна, и части, которую программист задает сам, когда вызывает одну из функций для логирования.

В общей части мы видим дату, время с микросекундами, уровень лога, метку, PID, имя файла и номер строки в исходниках, имя функции. Самые обычные вещи.

Syslog к этому сообщению добавляет информацию от себя: время, PID, hostname сервера и так называемый ident. Обычно это просто название программы, но туда можно передать все что угодно.

Мы этот ident стандартизовали и передаем туда имя, вторичное имя и версию демона. К примеру meetmaker-ru.mlan-1.0.0 . Таким образом мы можем отличить логи от разных демонов, от разных типов одного демона (например, страна, реплика) и иметь информацию о запущенной версии демона.

Разбор такого сообщения довольно прямолинеен. Я не буду в статье приводить куски из конфигурационного файла, но все сводится с постепенному «выкусыванию» и парсингу частей строки с использованием обычных регулярных выражений.

Если какой-то этап парсинга был неуспешен, мы добавляем к сообщению специальный тег, который в дальнейшем позволяет находить такие сообщения и мониторить их количество.

Упомяну про разбор времени. Мы постарались учесть разные варианты, и временем сообщения по умолчанию будет время из libangel-сообщения, т.е. по сути время, когда это сообщение было сгенерировано. Если по какой-то причине это время не было найдено, мы возьмем время от syslog, т.е. время, когда сообщение ушло в первый локальный syslog-демон. Если по какой-то причине и это время недоступно, временем сообщения будет время приема этого сообщения в Logstash.

Получившиеся поля идут в Elastic Search для индексации.

ElasticSearch

Elastic Search поддерживает работу в режиме кластера, когда несколько узлов объединяются в одну сеть и работают сообща. За счет того, что можно для каждого из индексов настроить репликацию на другой узел, кластер сохраняет работоспособность в случае выхода из строя некоторых узлов.

Минимальное количество узлов в отказоустойчивом кластере - три, первое нечетное число, которое больше единицы. Это связано с тем, что для работы внутренних алгоритмов необходимо, чтобы при разбиении кластера на части возможно было выделить большинство. Четное количество узлов для этого не подходит.

Мы выделили три сервера для кластера Elastic Search и настроили его так, чтобы каждый индекс имел одну реплику, как на схеме.

В такой архитектуре выход из строя любого из узлов кластера не фатален и не приводит к недоступности кластера.

Кроме собственно отказоустойчивости, при такой схеме удобно делать обновление самого Elastic Search: останавливаем один из узлов, обновляем его, запускаем, обновляем другой.

То, что мы храним в Elastic Search именно логи, позволяет нам легко поделить все данные на индексы по дням. Такое разбиение дает несколько преимуществ:

в случае, если на серверах кончается место на диске, очень легко удалить старые данные. Это быстрая операция, и более того, для удаления старых данных есть готовый инструмент Curator;
во время поиска в интервале больше одного дня поиск можно вести параллельно. Более того, его можно вести параллельно как на одном сервере, так и на нескольких.

Как уже было сказано, мы настроили Curator , чтобы автоматически удалять старые индексы при нехватке места на диске.

В настройке Elastic Search много тонкостей, связанных как с Java, так и просто с тем, что внутри используется Lucene. Но все эти тонкости описаны и в официальной документации, и в многочисленных статьях, поэтому я не буду углубляться. Кратко только упомяну, что на сервере Elastic Search нужно не забыть выделить память как под Java Heap, так и вне Heap (ее будет использовать Lucene), а также прописать «маппинги» конкретно для ваших полей в индексах, чтобы ускорить работу и уменьшить потребление места на диске.

Kibana

Тут говорить вообще не о чем:-) Поставили и работает. К счастью, в последней версии разработчики добавили возможность менять часовой пояс в настройках. Раньше по умолчанию брался локальный часовой пояс пользователя, что очень неудобно, т.к. у нас на серверах везде и всегда UTC, и мы привыкли общаться именно по нему.

Система уведомлений

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

В мире ELK нашлись два похожих готовых продукта:

Watcher от самой компании Elastic;

Watcher - закрытый продукт от компании Elastic, требующий активную подписку. Elastalert - продукт open source, написаный на Python. Watcher мы отмели почти сразу по той же причине, что и раньше - закрытость и сложность расширения и адаптации под нас. Elastalert же по тестам показал себя классным продуктом, но и в нем было несколько минусов (впрочем, не очень критичных):

он написан на Python. Мы любим Python в качестве языка для написания быстрых «наколеночных» скриптов, но не очень хотим его видеть на продакшене в качестве конечного продукта;
возможности построения писем, которые система посылает в ответ на событие, совсем рудиментарны. А красота и удобство письма - это очень важно, если мы хотим, чтобы у других было желание пользоваться системой.

Поигравшись с Еlastalert и изучив его исходный код, мы решили написать продукт на PHP силами отдела платформы. В итоге Денис Карасик Battlecat за 2 недели написал «заточенный» под нас продукт: он интегрирован в backoffice и имеет только нужный функционал.

Для каждого правила система автоматически создает базовый dashboard в Kibana, ссылка на который будет в письме. При нажатии на ссылку вы увидите сообщения и график ровно за указанный в уведомлении промежуток времени.

«Грабли»

На этом этапе первый релиз системы был готов, работал и им можно было пользоваться. Но, как мы обещали, «грабли» не заставили себя ждать.

Проблема 1 (syslog + docker)

Стандартный способ общения между syslog-демоном и программой является unix socket /dev/log. Как говорилось выше, мы его пробросили внутрь контейнера стандартными средствами docker. Эта связка отлично работала до тех пор, пока нам не понадобилось перегрузить syslog-демон.

Судя по всему, если перебрасывается конкретный файл, а не директория, то при удалении или пересоздании файла на хост-системе он уже не будет доступен внутри контейнера. Получается, что любая перезагрузка syslog-демона ведет к прекращению заливки логов из docker-контейнеров.

Если пробрасывать директорию целиком, то внутри без проблем может быть unix-сокет, и перезагрузка демона не нарушит ничего. Но тогда усложняется настройка всего этого богатства, ведь libc ожидает, что сокет находится в /dev/log.

Второй вариант, который мы рассматривали - использовать UDP или TCP для отправки логов наружу. Но тут такая же проблема, как и в предыдущем случае: libc умеет писать только в /dev/log. Нам бы пришлось писать свой syslog-клиент, а на данном этапе не хотелось этого делать.

В конце концов мы решили запустить по одному syslog-демону в каждом контейнере и продолжать писать в /dev/log стандартными libc функциями openlog()/syslog().

Это не было большой проблемой, т.к. наши системные администраторы все равно в каждом контейнере используют init-систему, а не запускают только один демон.

Проблема 2 (блокирующий syslog)

На devel-кластере мы заметили, что один из демонов периодически зависает. Включив внутренний watchdog демона, мы получили несколько backtrace, которые показывали, что демон зависает в syslog() -> write().

WATCHDOG ==== tag: IPC_SNAPSHOT_SYNC_STATE start: 3991952 sec 50629335 nsec now: 3991953 sec 50661797 nsec Backtrace: /lib64/libc.so.6(__send+0x79) /lib64/libc.so.6(__vsyslog_chk+0x3ba) /lib64/libc.so.6(syslog+0x8f) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(zlog1+0x225) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(storage_save_sync_done+0x68) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(ipc_game_loop+0x7f9) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(game+0x25b) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(service_late_init+0x193) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running(main+0x40a) /lib64/libc.so.6(__libc_start_main+0xf5) /local/meetmaker/bin/meetmaker-3.1.0_2782 | shard1: running ==== WATCHDOG ====

Быстренько скачав исходники libc и посмотрев на реализацию syslog-клиента, мы поняли, что функция syslog() синхронна и любые задержки на стороне rsyslog скажутся на демонах.

Что-то с этим нужно было делать, и чем скорее, тем лучше. Но мы не успели…

Через пару дней мы наступили на самые неприятные грабли современных архитектур - каскадный отказ.

Rsyslog по умолчанию настроен так, что если внутренняя очередь по какой-то причине заполняется, он начинает «троттлить» (англ. throttle), т.е. тормозить «запись в себя» новых сообщений.

У нас получилось так, что по недосмотру программиста один из тестовых серверов начал посылать в лог огромное количество сообщений. Logstash не справлялся с таким потоком, очередь главного rsyslog переполнилась и он очень медленно вычитывал сообщения от других rsyslog. Из-за этого очереди других rsyslog тоже переполнились и они очень медленно вычитывали сообщения от демонов.

А демоны, как я говорил выше, пишут в /dev/log синхронно и без какого-либо таймаута.
Результат предсказуем: из-за одного флудящего тестового демона тормозить начали все демоны, которые пишут в syslog хоть с какой-то значимой частотой.

Еще одной ошибкой стало то, что мы не сказали о потенциальной проблеме системным администраторам, и на то чтобы, выяснить причину и отключить rsyslog, ушло больше часа.

Есть у меня одна слабость - я люблю разные системы мониторинга. То есть для меня идеальна ситуация, когда можно посмотреть состояние каждого компонента системы в любой момент времени. С реалтаймом все более-менее понятно: можно агрегировать данные и выводить их на красивый дашборд. Сложнее обстоят дела с тем, что было в прошлом, когда нужно узнать разные события в определенный момент и связать их между собой.

Задачка на самом деле не такая уж тривиальная. Во-первых, нужно агрегировать логи с совершенно разных систем, которые зачастую не имеют ничего общего между собой. Во-вторых, нужно привязывать их к одной временной шкале, чтобы события можно было между собой коррелировать. И в-третьих, нужно эффективно устроить хранение и поиск по этому огромному массиву данных. Впрочем, как это обычно бывает, о сложной части уже позаботились до нас. Я пробую несколько разных вариантов и поэтому сделаю мини-обзор того, с чем уже успел поработать.

Онлайн-сервисы

Самый простой вариант, который на первых порах отлично работал для меня, - использовать облачный сервис. Подобные инструменты активно развиваются, предоставляют поддержку все большего количества технологических стеков и подстраиваются по специфику отдельных IaaS/PaaS’ов вроде AWS и Heroku.

Splunk

Про этот сервис писал в колонке и я, и недавно Алексей Синцов. Вообще говоря, это не просто агрегатор логов, а мощная система аналитики с многолетней историей. Поэтому задачка собрать логи и агрегировать их для дальнейшей обработки и поиска - для него плевое дело. Существует более 400 различных приложений, в том числе более ста в области IT Operations Management, которые позволяют собирать информацию с твоих серверов и приложений.

loggly

Этот сервис уже специально заточен для анализа журналов и позволяет агрегировать любые виды текстовых логов. Ruby, Java, Python, C/C++, JavaScript, PHP, Apache, Tomcat, MySQL, syslog-ng, rsyslog, nxlog, Snare, роутеры и свитчи - неважно. Бесплатно можно собирать до 200 Мб в день (что немало), а ближайший платный тариф начинается от 49 долларов. Работает очень здорово.

Отличный сервис, который агрегирует логи приложений, любые текстовые журналы, syslog и прочее. Что интересно: с агрегированными данными можно работать через браузер, командную строку или API. Поиск осуществляется простыми запросами вроде «3pm yesterday» (получить данные со всех систем в три часа ночи за вчерашний день). Все связанные события будут сгруппированы. Для любого условия можно сделать алерт, чтобы вовремя получить предупреждения (изменились настройки в конфигах). Для хранения логов можно использовать S3. В первый месяц дают 5 Гб бонусом, дальше бесплатно предоставляется только 100 Мб в месяц.

Еще один неплохой сервис для сбора данных, позволяющий собирать до гигабайта логов в месяц бесплатно. А возможности все те же: мощный поиск, tail в режиме реального времени (выводится все, что «прилетает» из логов на текущий момент), хранение данных в AWS, мониторинг PaaS, IaaS и популярных фреймворков, языков. На бесплатном тарифе можно хранить данные за семь дней.

NewRelic

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

Развернуть все у себя

Мои эксперименты с онлайн-сервисами закончились, когда данных стало так много, что за их агрегацию пришлось бы платить трехзначные суммы. Впрочем, оказалось, что развернуть подобное решение можно и самому. Тут два основных варианта.

logstash

Это открытая система для сбора событий и логов, которая хорошо себя зарекомендовала в сообществе. Развернуть ее, конечно, несложно - но это уже и не готовый сервис из коробки. Поэтому будь готов к багам в скупой документации, глюкам модулей и подобному. Но со своей задачей logstash справляется: логи собираются, а поиск осуществляется через веб-интерфейс.

Fluentd

Если выбирать standalone-решение, то Fluentd мне понравился больше. В отличие от logstash, которая написана на JRuby и поэтому требует JVM (которую я не люблю), она реализована на CRuby и критические по производительности участки написаны на C. Система опять же открытая и позволяет собирать большие потоки логов, используя более 1500 различных плагинов. Она хорошо документирована и предельно понятна. Текущий вариант сборщика логов у меня развернут именно на Fluentd.

Покажи эту статью друзьям.