Приветствую, читатель моего блога. Давненько я не писал статей. Много жизненных перемен... Сегодняшняя статья будет посвящена 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 - по необходимости. блок_действий - может содержать одно действие (), либо вложенный блок условий. Если блок условий содержит несколько действий, то он заключается в скобки. условие - содержит условие отбора сообщений для блока_действий . В условии можно использовать:

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

Ничего необычно я не увидел.

Feb 15 17:47:23 log-n1 yum: Installed: syslog-ng-3.5.6-3.el7.x86_64
Feb 15 17:47:36 log-n1 systemd: Reloading.

Feb 15 17:47:40 log-n1 syslog-ng: syslog-ng starting up; version=’3.5.6′
Feb 15 17:47:40 log-n1 systemd: Listening on Syslog Socket.
Feb 15 17:47:40 log-n1 systemd: Starting Syslog Socket.
Feb 15 17:47:40 log-n1 systemd: Starting System Logger Daemon…
Feb 15 17:47:40 log-n1 systemd: Started System Logger Daemon.
Feb 15 17:52:41 log-n1 syslog-ng: syslog-ng shutting down; version=’3.5.6′
Feb 15 17:52:41 log-n1 systemd: Stopping System Logger Daemon…


Feb 15 17:52:41 log-n1 systemd: syslog-ng.service holdoff time over, scheduling restart.
Feb 15 17:52:41 log-n1 systemd: Starting System Logger Daemon…
Feb 15 17:52:41 log-n1 systemd: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 15 17:52:41 log-n1 systemd: Failed to start System Logger Daemon.
Feb 15 17:52:41 log-n1 systemd: Unit syslog-ng.service entered failed state.
Feb 15 17:52:41 log-n1 systemd: syslog-ng.service failed.



Feb 15 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, scheduling restart.
Feb 15 17:52:42 log-n1 systemd: Starting System Logger Daemon…
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 15 17:52:42 log-n1 systemd: Failed to start System Logger Daemon.
Feb 15 17:52:42 log-n1 systemd: Unit syslog-ng.service entered failed state.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service failed.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, scheduling restart.
Feb 15 17:52:42 log-n1 systemd: Starting System Logger Daemon…
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 15 17:52:42 log-n1 systemd: Failed to start System Logger Daemon.
Feb 15 17:52:42 log-n1 systemd: Unit syslog-ng.service entered failed state.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service failed.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, scheduling restart.
Feb 15 17:52:42 log-n1 systemd: Failed to start System Logger Daemon.
Feb 15 17:52:42 log-n1 systemd: Unit syslog-ng.service entered failed state.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service failed.
Feb 15 17:52:42 log-n1 systemd: start request repeated too quickly for syslog-ng.service
Feb 15 17:52:42 log-n1 systemd: Failed to start System Logger Daemon.
Feb 15 17:52:42 log-n1 systemd: Unit syslog.socket entered failed state.
Feb 15 17:52:42 log-n1 systemd: syslog-ng.service failed.
Feb 15 17:53:11 log-n1 systemd: Listening on Syslog Socket.

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

Сбор логов 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», указать папку для сохранения и имя файла (рекомендуется оставить по умолчанию) и нажать на кнопку «Сохранить».

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

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

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

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

Самый простой вариант, который на первых порах отлично работал для меня, - использовать облачный сервис. Подобные инструменты активно развиваются, предоставляют поддержку все большего количества технологических стеков и подстраиваются по специфику отдельных 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.

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

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

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