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

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

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

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

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

В 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, ушло больше часа.

Когда в системе происходит та или иная ошибка, нужно выяснить почему она произошла, исправить ее и попытаться сделать так, чтобы такой ошибки больше не было. В этом системным администраторам очень сильно помогает логирование всех ошибок. Например, общие сообщения ядра и программ сохраняются в /var/log/messages.

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

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

Развитие rsyslog началось в 2004 году, в качестве форка используемого тогда сервиса Syslog. Программа очень быстро набрала популярность среди пользователей и сейчас она поставляется по умолчанию во многих дистрибутивах Linux.

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

Вот основные возможности:

• Многопоточность;
• TCP, SSL, TLS, RELP;
• Поддержка MySQL, PostgreSQL, Oracle;
• Фильтрация журналов;
• Полностью настраиваемый формат вывода.

Как происходит логирование?

Все программы Linux ведут лог путем отправки сообщений об ошибках или своем состоянии с помощью сокета syslog или просто записывая все сообщения в файл, который будет находиться в каталоге /var/log/.

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

Например, ядро Linux определяет такие уровни логов, или как мы будем называть их ниже - приоритеты:

• KERN_EMERG - система неработоспособна;
• KERN_ALERT - нужно немедленно принять меры;
• KERN_CRIT - критическая ошибка;
• KERN_ERR - обычная ошибка;
• KERN_WARNING - предупреждение;
• KERN_NOTICE - замечание;
• KERN_INFO - информационное сообщение;
• KERN_DEBUG - сообщения отладки.

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

Настройка Rsyslog в Linux

Все настройки Rsyslog находятся в файле /etc/rsyslog.conf и других конфигурационных файлах из /etc/rsyslog.d. Вы можете посмотреть существуют ли у вас эти файлы выполнив:

rsyslog.conf rsyslog.d/

Основной конфигурационный файл - /etc/rsyslog.conf, в нем подключены все файлы из папки rsyslog.d с помощью директивы IncludeConfig в самом начале файла:

IncludeConfig /etc/rsyslog.d/*.conf

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

Синтаксис конфигурационного файла очень прост:

$ переменная значение

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

ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support
#$ModLoad immark # provides --MARK-- message capability

# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514

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

• Модули ввода - можно рассматривать, как способ сбора информации из различных источников, начинаются с im.
• Модули вывода - позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;
• Модули фильтрации - позволяют фильтровать сообщения по разным параметрам, начинаются с fm;
• Модули парсинга - предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокета, а второй imklog получает сообщения ядра. Следующим загружается модуль mark, который позволяет маркировать соединения, или же выводить сообщения о том, что syslog все еще работает. Например, вы можете попросить rsyslog выводить сообщения каждые 20 минут:

ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

В этой строке мы указываем, что нужно использовать стандартный формат хранения времени, в секундах с 1970 года.

FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

После создания этих файлов их права можно менять, на те, которые вам нужны.

Выше была более общая настройка syslog, ну а теперь самое интересное - правила сортировки логов. Вот набор правил по умолчанию:

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, мы можем отправить больше сообщений в лог системы linux /var/messages:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

В этой строке мы выбираем все сообщения уровня info, кроме mail,authpriv и cron. Шаблон mail.none будет означать, что не нужно логировать ни один уровень сообщений. Соответственно конструкция *.info - значит логировать сообщения от всех источников, но только с уровнем info, *.* - это вообще все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также заметьте, что приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими. В целом, в качестве источников вы можете использовать:

• auth;
• authpriv;
• cron;
• daemon;
• kern;
• mail;
• mark;
• news;
• security (эквивалентно auth);
• syslog;
• user;
• uucp;
• local0 ... local7;

А в качестве приоритетов вы можете применить:

• emerg (раньше panic);
• alert;
• crit;
• error (раньше err);
• warn (раньше warning);
• notice;
• info;
• debug;

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

Вы можете выполнять фильтрацию сообщений с помощью такого синтаксиса:

:поле, сравнение, "значение" путь_к_файлу

В качестве операции сравнения вы можете использовать такие варианты:

• contains - поле содержит указанное значение;
• isequal - поле должно быть идентичным значению;
• startswith - поле должно начинаться со значения;
• regex - сравнивает поле с регулярным выражением.

Например, отфильтруем сообщения только от определенной программы:

:syslogtag, isequal, "giomanager:" /var/log/giomanager.log
& stop

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

if $поле сравнение "значение" then файл

Здесь используются те же самые компоненты, только выглядит немного проще. Например:

if $syslogtag == "giomanager" then /var/log/giomanager.log

Настройка syslog для удаленного логирования

Было бы очень удобно, если бы логи со всех серверов сети собирались на одной машине. Здесь бы были все важные сообщения об ошибках и неполадках. Вы могли бы все это очень быстро проанализировать. Отправить лог на удаленный сервер достаточно просто, для этого достаточно указать @ и ip адрес удаленной машины, на которой запущен rsyslog:

*.info;mail.none;authpriv.none;cron.none @xx.xx.xx.xx:514

Здесь 514 - это порт, на котором слушает rsyslog. Настройка rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp. Далее, все что нужно для того чтобы получить логи с определенной машины, отфильтровать их из общего потока с помощью фильтров:

if $fromhost-ip contains "192.168.1.10" then /var/log/proxyserver.log

Без фильтров, сообщения с разных машин будут писаться в один общий лог системы linux в зависимости от того как вы их распределите.

Выводы

В этой статье мы рассмотрели как выполняется настройка Rsyslog в Linux для сбора логов на локальном компьютере, а также передачи их на удаленный сервер. Изначально все кажется очень сложным, но если разобраться, то и это можно настроить.

Обратите внимание, что при использовании rsyslog в качестве сетевого сервера для хранения логов место на диске будет очень быстро уменьшаться. Поэтому лучше применять в дополнение к программе такую утилиту, как Logrotate.

На завершение видео на английском про настройку Logrotate: