Меню

Как настроить syslog сервер

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

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

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

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

Что такое Rsyslog?

Развитие 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/. Вы можете посмотреть существуют ли у вас эти файлы выполнив:

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

В этих файлах могут содержаться дополнительные настройки, например, аутентификация на 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 минут:

Дальше идут глобальные директивы:

В этой строке мы указываем, что нужно использовать стандартный формат хранения времени, в секундах с 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,authpriv и cron. Шаблон mail.none будет означать, что не нужно логировать ни один уровень сообщений. Соответственно конструкция *.info — значит логировать сообщения от всех источников, но только с уровнем info, *.* — это вообще все сообщения, со всеми уровнями.

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

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

  • 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:

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

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

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

Выводы

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

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

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

Источник

Установка и настройка syslog сервера

Думаю, что в жизни каждого сисадмина бывают моменты, когда в его любимой сети начинают происходить необъяснимые вещи. Особенно неприятно, если это происходит с некоторой периодичностью и установить причину каждый раз не удается. Конечно, можно сослаться на магнитные бури, погоду на Марсе и т.д. (нужное подчеркнуть), но все мы с вами прекрасно понимаем, что космос здесь не причем.

Мы не будем себя утруждать перебором всех возможных вариантов, лучше подумаем о том, как можно предупредить, отследить и быстро установить причину возникновения того или иного сбоя. Все сетевые железки (и не только), которые хотя бы частично наделены мозгами, в процессе своей работы генерируют логи происходящих событий. Чаще всего эти логи записываются локально в память железки и уважвющий себя сисадмин их никогда не читает. А зря 🙂 Ибо там и кроется вся истина происходящих событий.

Конечно, если твоя сеть состоит из одного коммутатора или роутера, то отслеживать логи будет не трудно и городить огород здесь не стоит. Другое дело, когда сеть состоит из большого количества разнородных устройств. Что предложите? Тратить по полдня на анализ логов в нашем случае не вариант.

Как ты уже догодался, нам нужно каким-то образом отслеживать все происходящие события централизованно. Возникает вопрос как и чем это делать? Мониторинг сети? Одно такое решение под названием PRTG Network Monitoring мы недавно рассматривали. Однако, не все и не всегда можно отследить с помощью PRTG.
Умные дяди давным давно придумали специальный стандарт для передачи логов — Syslog. Кто особо заинтересовался подробостями этого протокола — велкам в википедию, а остальным мы в краце расскажем что к чему и как это настроить в любимой сети.
Весь принцип работы сводится к тому, что программа syslog, установленная на какой-нибудь сервер, принимает входящие сообщения от сетевых железок. Принятые сообщения записываются в один файл или БД, чтобы ты всегда смог посмотреть какие события и на каком оборудовании происходили в заданый промежуток времени.

Читайте также:  Как настроить субтитры по времени

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

Хороший вариант — установить linux, там syslog в базовом варианте уже встроен изначально, останется только подшаманить с настройкой хранения событий в БД и веб-мордой для удобного просмотра. Но что делать, если нет времени плясать с бубном или нет достаточных знаний в *nix системах? Оказывается, даже из такой ситуации есть выход! Называется он SyslogAppliance. На сайте разработчиков можно скачать уже готовую к применению виртуальную машину vmware с настроенным syslog сервером.Я обнаружил только два ньюанса при развертывании виртуальной машины SyslogAppliance. А именно: виртуалка настроена на получение автоматического IP по DHCP, часовой пояс выставлен хрен знает какой. Если у вас есть DHCP-сервер, то впринципе можно привязать там MAC-адрес syslog сервера и больше не забивать голову всякой ерундой. Но имхо для сервера это не кашерно. Лучше выставить настройки IP-адресации вручную. Делается это следующим образом. Логинимся в syslog сервер по консоли, затем с помощью редактора vim открываем файл сетевых настроек. Команда будет выглядеть так:
vim /etc/network/interfaces

Здесь нам надо заменить строку:
iface eth0 inet auto
и все что под ней на:
iface eth0 inet static
address твой_IP_адрес
netmask маска_подсети
gateway шлюз_по_умолчанию

Для перехода в режим редактирования сначала нажимаем i, затем правим всё как указано выше, затем жмем Esc. Для выода с сохранением нажимаем Shift+z два раза.
Далее нужно вписать DNS. Для этого набираем
vim /etc/resolv.conf
указываем адрес нашего DNS-сервера. Сохраняемся, выходим. Перезагружаемся командой reboot. Если у syslog сервера есть доступ в интернет, то можно выполнить пару команд обновления системы. Сначала набираем apt-get update, затем apt-get upgrade.

Последнее что нужно сделать, это поменять часовой пояс и выставить правильную дату и время. Первое делается командой
dpkg-reconfigure tzdata
а второе командой
date —set=»мм/дд/гггг чч:мм:сс»
После этих манипуляций можно перезагрузить syslog сервер и попробовать зайти на web-интерфейс по адресу http://ip-адрес-сервера/logs
Нас попросят ввести логин/пароль, затем будет показана текущая ситуация по собранным событиям:

Все события разбиваются по источнику, типу сообщения (notice, warning, error, alarm и т.п.), описание, в котором указано что именно произошло. Мы можем отфильтровать таблицу по интересующим нас критериям, для этого просто кликните мышью по нужной надписи. Если надо видеть какие сообщения валятся на syslog сервер в режиме реального времени, то в правой части экрана над шапкой таблицы есть ниспадающий список с вариантами автообновления страницы с разными интервалами времени. Ко всему прочему можно поизучать статистические данные, которые здесь представлены в виде диаграмм. Есть несколько типов графиков.

Теперь собственно то, ради чего мы это затевали. Как заставить всякие железяки отправлять сообщения на наш syslog сервер?
Например, для оборудования cisco в конфиг нужно добавить строчку logging ip-адрес_сервера
В *nix система в конфиг локального syslog’а добавляется строка *.* @ip-адрес_сервера.
Кстати говоря, даже Windows можно заставить передавать события в наш syslog. Сделать это можно с помощью одной небольшой бесплатной утилиты eventlog-to-syslog.

Вот собственно и все примудрости. Остается пожелать тебе и твоей сети поменьше глюков и успехов в освоении syslog’a.

ЗЫ: Как всегда мы будем рады любым комментариям и оценкам данной статьи. Спасибо!

Источник



Установка и настройка Rsyslog в Linux

Логи — критически важный компонент любой программы или операционной системы. Обычно в них хранятся записи о действиях пользователей, системных событиях, сетевой активности и многом другом, в зависимости от предназначения. Rsyslog — одна из наиболее широко распространенных систем ведения логов для Linux.

Rsyslog – это мощная, безопасная и высокопроизводительная система обработки логов, принимающая данные из различных источников (систем и приложений) и выдающая их в разнообразных форматах. Она представляет собой развитие обычного демона syslog до полнофункциональной системы ведения логов корпоративного уровня. Rsyslog работает по модели «клиент-серевер», поэтому ее можно настроить как клиент и/или сервер для централизованного ведения логов других серверов, сетевых устройств и удаленных приложений.
В данном руководстве мы рассмотрим основы работы с rsyslog. В примерах мы будем использовать следующие узлы:

Сервер: 192.168.241.140
Клиент: 172.31.21.58

Установка и настройка сервера Rsyslog

В большинстве дистрибутивов Linux пакет rsyslog предустановлен. Если у вас его нет, установите его при помощи менеджера пакетов:
Для RHEL/CentOS:

Читайте также:  Как настроить стрелку хронографа

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

Главный файл конфигурации rsyslog — /etc/rsyslog.con f. Он загружает модули, определяет глобальные директивы, содержит правила по обработке сообщений логов, а также включает пути ко всем файлам конфигурации в директории /etc/rsyslog.d/ для различных приложений и служб.

По умолчанию rsyslog использует модули imjournal и imusock для импорта структурированных записей логов из журнала systemd и для приема через сокеты Unix сообщений системных логов от приложений, запущенных в локальной системе, соответственно.

Чтобы настроить rsyslog как сетевой централизованный сервер ведения логов, нужно установить протоколы (UDP, TCP или оба), которые будут использоваться для приема удаленных сообщений системных логов, а также прослушиваемые порты.

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

Для использования TCP-соединения (медленнее, но надежнее) найдите и раскомментируйте следующие строки:

В нашем случае мы будем использовать оба протокола.
Далее вам потребуется определить набор правил для обработки удаленных логов в следующем формате:

источник: тип процесса или приложения, от которого исходит сообщение, значение может быть auth, cron, daemon, kernel, local0..local7. Использование звездочки (*) означает все источники.

уровень_важности: тип сообщения логов: emerg-0, alert-1, crit-2, err-3, warn-4, notice-5, info-6, debug-7. Использование звездочки означает все уровни важности, если ничего не указывать, предполагается отсутствие уровня важности.

  • 0, emerg – система не работоспособна
  • 1, alert – система требует немедленного вмешательства
  • 2, crit – состояние системы критическое
  • 3, err – сообщение об ошибке
  • 4, warning – предупреждение о возможной проблеме
  • 5, notice – нормальное, но важное событие
  • 6, info – информационное сообщение
  • 7 , debug – отладочное сообщение
  • место_записи_лога: локальный файл или удаленный сервер rsyslog (определенный в формате IP-адрес:порт).

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

Рассмотрим набор правил более подробно. Первое правило в нем следующее: «$template RemoteLogs,”/var/log/%HOSTNAME%/%PROGRAMNAME%.log”».
Директива $template дает демону rsyslog команду собирать полученные сообщения из источников и записывать их в отдельные логи в директории /var/logs в соответствии с именем узла (машины клиента) и источником (программой/приложением), от которых были получены сообщения, что определено соответствующим шаблоном.

Вторая строка «*.* ?RemoteLogs» означает запись сообщений всех уровней важности от всех источников в соответствии с шаблоном RemoteLogs.

Последняя строка «&

» задает rsyslog прекратить обработку сообщений после их записи в файл. Если не указать «&

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

Далее требуется проверить сетевые сокеты rsyslog. Воспользуйтесь netstat

Если у вас включена служба SELinux, нужно выполнить следующие команды, чтобы разрешить трафик rsyslog:

При включенном брандмауэре нужно открыть TCP и UDP порты 514, чтобы разрешить подключение к серверу rsyslog по обоим протоколам:

Для CentOS (брандмауэр firewalld):

Для Ubuntu (брандмауэр ufw):

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

Проверьте, запущена ли служба rsyslog на клиентской машине, при помощи следующей команды:

Если она не установлена, установите и запустите службу точно так же, как для сервера:
После запуска службы откройте файл конфигурации:

Чтобы демон rsyslog работал как клиент и отправлял все локальные логи на удаленный сервер rsyslog, добавьте следующее правило перенаправления в конце файла, как показано на скриншоте ниже. Номер порта должен соответствовать номеру порта, прописанному в конфигурации сервера:

Приведенное правило будет отправлять сообщения всех уровней важности от всех источников. Для отправки сообщений от конкретного источника, например, auth, воспользуйтесь следующим правилом:

Сохраните и закройте файл, а также перезагрузите службу rsyslog чтобы изменения вступили в силу.

Мониторинг логов на сервере

Последний этап – проверить, действительно ли rsyslog получает сообщения от клиента и сохраняет их в директории /var/log и формате имя_узла/имя_программы.log.
Выполните команду ls, чтобы получить список файлов директории логов и проверьте, есть ли там директории под названием ip-172.31.21.58 (или с соответствующим именем узла вашего клиента).

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

Заключение

Rsyslog – высокопроизводительная система обработки логов с архитектурой «клиент-сервер». В данном руководстве рассмотрена базовая установка и настройка. Более подробную информацию о программе и ее конфигурации можно получить в официальной сетевой документации или man-страницах.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник