Что такое код syslog


Содержание

Установка и настройка 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.

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

Bog BOS: syslog — сетевой системный журнал

Протокол syslog и программные средства поддержки обеспечивают запись информации о событиях в системный журнал (журналы, системную консоль), а также передачу их на сервер журнализации по сети, сортировку и обработку в зависимости от источника и важности сообщений. В статье описывается протокол syslog, его реализация в Solaris и Linux (syslogd), Cisco IOS, а также вспомогательные средства: logrotate, logwatch. Первый стандарт (RFC 3164) был сформулирован через 10 лет практического использования.

Компонентами системы являются генератор сообщений (устройство или процесс, device), протокол обмена, коллектор сообщений (collector, syslog server), релей (relay, принимает сообщения от одного или нескольких генераторов и передает одному или нескольким коллекторам или следующим релеям). Генератор (или релей при передаче) не знает является ли приемник релеем или коллектором, может передавать одно сообщение нескольким приемникам, может обрабатывать сообщение самостоятельно (например, записывая в файл).

Протокол syslog (RFC 3164) не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Локальная сеть должна быть защищена экраном (IOS ACL, iptables) от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

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

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

Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет — сообщения будут удаляться (или записываться в чужой журнал ;).

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

RFC 3195 (2001 год) предлагает новый протокол над TCP (порт 601 — syslog-conn), обеспечивающий гарантированную доставку в правильной последовательности. Чудовищная смесь XML, команд и кодов возврата в стиле SMTP и заголовков MIME (BEEP), в которую заворачиваются сообщения стандартного формата syslog. Используется два режима — RAW (аналог нынешнего UDP протокола) и COOKED (сообщения структурированы по полям). BEEP позволяет обеспечить аутентификацию, целостность и конфиденциальность (SASL, TLS).

Проект RFC syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP. Используется SHA1, OpenPGP DSA.

В 2009 году вышел RFC 5424 (The Syslog Protocol, UTF-8, структурированные данные, время) и его дополнения:

  • RFC 5425 (использование TLS, TCP/6514)
  • RFC 5426 (использование UDP, UDP/514)
  • RFC 5427 (кодировка источника и важности в формате MIB)

В том же 2009 году вышли RFC, привязывающие syslog к SNMP:

  • RFC 5674 (Alarms in Syslog)
  • RFC 5675 (Mapping SNMP Notifications to SYSLOG Messages)
  • RFC 5676 (Definitions of Managed Objects for Mapping SYSLOG Messages to SNMP Notifications)

В 2010 вышли RFC, усиливающие безопасность передачи:

  • RFC 5848 (Signed Syslog Messages); цифровая подпись, упорядоченность, обнаружение пропавших сообщений
  • RFC 6012 (Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog)

В 2012 отчаявшись перевести всех на RFC 5424/RFC 5425 была описана сложившаяся практика использования TCP без TLS в виде RFC 6587.

Для приема сообщений используется порт 514/UDP. Рекомендуется также использовать исходный порт 514 для передачи сообщений. Сообщение представляет собой текстовую строку и не может иметь длину более 1024 байт, в противном случае его разрешается обрезать или даже выбрасывать. Даже неправильно сформированное сообщение, посланное на 514 порт, должно рассматриваться как сообщение syslog. Однако, если релей передает сообщение дальше, то он должен добавить к нему стандартные заголовки (при этом, возможно обрезав его до 1024 байт) — USER, NOTICE, свое локальное время и простое имя источника сообщения.

Сообщение начинается с поля PRI, которое в закодированном виде содержит информацию об источнике сообщения (facility) и уровне серьезности (Severity level) сообщения. Сразу за ним идёт заголовок (HEADER), содержащий время (TIMESTAMP), пробел, имя или IP адрес хоста в десятичной записи (HOSTNAME). За заголовком идёт пробел и тело сообщения (MSG), произвольный текст в US-ASCII (0x20 — 0x7e).

Источник сообщения кодируется числом от 0 до 23:

  • 0 — KERN (сообщения ядра)
  • 1 — USER (сообщения пользовательских программ)
  • 2 — MAIL (почтовая система)
  • 3 — DAEMON (прочие демоны)
  • 4 — AUTH (безопасность/права доступа)
  • 5 — SYSLOG (генерируемые самим syslog)
  • 6 — LPR (подсистема печати)
  • 7 — NEWS (Netnews, USENET)
  • 8 — UUCP
  • 9 — CRON (clock daemon)
  • 10 — AUTHPRIV (безопасность/права доступа — защищенный режим)
  • 11 — FTP
  • 12 — NTP (существует не везде)
  • 13 — security, log audit (существует не везде)
  • 14 — console, log alert (существует не везде)
  • 15 — solaris-cron, clock daemon (существует не везде)
  • с 16 по 23 зарезервированы для локального использования (LOCAL0 — LOCAL7)

Уровень серьезности кодируется числом от 0 до 7:

  • 0 — EMERG (система неработоспособна, старое название PANIC)
  • 1 — ALERT (требуется немедленное вмешательство)
  • 2 — CRIT (критическое состояние)
  • 3 — ERR (ошибка, старое название ERROR)
  • 4 — WARNING (предупреждение, старое название WARN)
  • 5 — NOTICE (все нормально, но важно)
  • 6 — INFO (информационное сообщение)
  • 7 — DEBUG (отладочная печать)

Номер источника умножается на 8 и складывается с уровнем серьезности, получившееся число в ASCII заключается в угловые скобки и образует поле PRI.

Время (местное!) записывается в формате: Feb 13 21:12:06. Если номер дня является однозначным числом, то перед ним ставится дополнительный пробел (не 0!) . Заметьте отсутствие года и зоны в дате, что необходимо учесть при долговременном хранении. Для того, чтобы время в сообщении было правильным, устройство должно быть синхронизовано (например, по NTP).

Имя хоста (простое по STD 13 (RFC 1034 и RFC 1035), не FQDN!) записывается так, как оно известно генератору сообщения. Если устройство имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.

Текст сообщения (MSG) обычно содержит этикетку (TAG), указывающую на программу или процесс, выдавшую это сообщение и тело сообщения (CONTENT) в ASCII-7. Этикетка может содержать латинские буквы и цифры. Начало тела сообщения определяется по первому специальному символу — обычно двоеточие или открывающая квадратная скобка. Например, Cisco IOS в качестве этикетки использует последовательный номер сообщения и двоеточие, а Unix — простое имя программы (тело сообщения начинается с номера процесса в квадратных скобках и двоеточия).

Релей не должен прверять достоверность заголовка (время и хост).

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

Релей должен добавлять PRI равный 13 и заголовок в пересылаемое сообщение, если не обнаружил PRI во входящем сообщении.2

Год рекомендуется заносить в содержимое сообщения.

FQDN и IP рекомендуется заносить в содержимое сообщения.

RFC 3195 использует ту же архитектуру, что и RFC 3164 (источники, релеи, коллекторы) и фреймворк протоколов BEEP (Blocks Extensible Exchange Protocol) для описания асинхронных соединений (TCP/601, syslog-conn), профили:

  • RAW — аналог UDP протокола из RFC 3164, упорядоченная надёжная поставка в рамках каждого канала, MIME Content-Type типа application/octet-stream; слушатель ждёт соединения, инициатор открывает соединение, слушатель сообщает о готовности («RPY 0 0 . 0 201») и ожидаемом формате (текст в XML), инициатор сообщает о готовности и используемом формате (MIME+XML, затем пронумерованные сообщения в формате похожем на RFC 3164, но не совсем ;) — многострочность, «END»
  • COOKED — MIME Content-Type типа application/beep+xml; представление источника (iam: тип — device, relay или collector; FQDN имя; IP адрес) с подтверждением; структурированные сообщения (entry: facility, severity, timestamp, hostname, tag, deviceFQDN, deviceIP) с подтверждением, маршрут прохождения сообщения (path: fromFQDN, fromIP, toFQDN, toIP, pathID, linkprops (сильная и слабая приватность, пользователь аутентифицирован с помощью SASL или TLS, использован слой аутентификации, защита от повторных сообщений, защита от модификации, защита от потери)) позволяет отлавливать циклы


Возможно использование алгоритма DNS SRV для автоматического получения адреса коллектора (сервис syslog, протокол tcp).

RFC 5424 замещает RFC 3164. Отдельно описывает формат сообщений, отдельно — механизм транспортировки. Стандарт поделён на слои:

  • содержимое сообщения
  • транспортировка сообщений
  • приложения: создание, интерпретация, маршрутизация, хранение

В дополнение к генератору сообщений (originator), коллектору (collector) и релею (relay) определяются транспортный отправитель (transport sender) и транспортный получатель (transport receiver), которые передают (получают) сообщения в транспортный протокол.

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

Защиты от повторного проигрывания не предусмотрена.

Защита цельности сообщений не предусмотрена, всё на откуп транспортому механизму.

Защита приватности не предусмотрена, всё на откуп транспортому механизму.

Защита от ошибок настройки, в частности, от циклов маршрутизации не предусмотрена.

Сообщение состоит из заголовка (HEADER), пробела, структурированных данных, пробела и тела сообщения (MSG).

Максимальная длина определяется транспортным механизмом, но не менее 480 октетов. Слишком длинные сообщения обрезаются или отбрасываются.

Заголовок состоит из

  • поля PRI (см. RFC 3164); RFC 5427 определяет MIB модуль для Facility и Severity (syslogTCMIB как < mib-2 173 >)
  • версии (до 3 цифр), «1» для RFC 5424
  • пробела
  • отметки времени (TIMESTAMP)
  • пробела
  • имени хоста генератора сообщения (HOSTNAME, FQDN, строка US-ASCII или «-«), может содержать IP адрес, простое имя
  • пробела
  • имени приложения или устройства (APP-NAME — строка US-ASCII или «-«)
  • пробела
  • идентификатор процесса (PROCID — строка US-ASCII или «-«), позволяет отслеживать перезапуски приложения
  • пробела
  • идентификатора типа сообщения (MSGID — строка US-ASCII или «-«)

Отметка времени — «-» или «ГОД-МЕСЯЦ-ДЕНЬ»||»T»||»ЧАС:МИНУТА:СЕКУНДА»||».»||»МИКРОСЕКУНД»||»СМЕЩЕНИЕ» (где ГОД — 4 цифры, МЕСЯЦ — 2 цифры, ДЕНЬ — 2 цифры, микросекунды — до 6 цифр — опциональны, СМЕЩЕНИЕ — «Z» (UTC) или «<+|->ЧАСОВ:МИНУТ»).

Стуктурированные данные — «-» или последовательность SD элементов (без пробелов!), где SD элемент — это ‘[ИМЯ-SD ИМЯ-ПАРАМЕТРА=»ЗНАЧЕНИЕ» . ]’, где ЗНАЧЕНИЕ — это строка UTF-8. SD делятся на

  • пользовательские содержат «@» в имени
  • предопределённые
    • timeQuality — параметры
      • tzKnown=»1″
      • isSynced=»1″
      • syncAccuracy=»микросекунд»
    • origin (источник сообщения) — параметры
      • ip (возможен список)
      • enterpriseId (SMI Network Management Private Enterprise Code — iso.org.dod.internet.private.enterprise
      • software (требуется enterpriseId)
      • swVersion
    • meta
      • sequenceId — последовательный номер
      • sysUpTime (см. RFC 3418)
      • language (см. RFC 4646, BCP 47)

Тело сообщения — BOM (0xEFBBBF) и строка UTF-8 или произвольная последовательность октетов (байт).

Транспортные протоколы описываются отдельными RFC:

  • RFC 5425 — TLS 1.2 (RFC 5246) с TLS_RSA_WITH_AES_128_CBC_SHA, по умолчанию, порт TCP/6514 (syslog-tls); для взаимной аутентификации могут использоваться сертификаты (RFC 5280): проверка цепочки сертификатов (PKI) или проверка отпечатка (fingerprints, что сводит шифрование к ситуации «с известным ключом»); сообщение получается из сообщения RFC 5424 добавлением в начало длины (строка) и пробела; транспорт TLS обеспечивает приватность и достоверность данных; подтверждений и полной упорядоченности не обеспечивается
  • RFC 5426 — UDP, привычный по RFC 3164, порт UDP/514; каждое сообщение в отдельном пакете и ничего более; приёмник должен принимать сообщения длиной 480 октетов для IPv4; отправителю не рекомендуется создавать пакеты более 576 октетов; не разрешается отключать создание контролльных сумм; подтверждений нет, приватность, достоверность, упорядоченность не обеспечиваются;
  • RFC 6587 — TCP, по традиции используется порт TCP/514, хотя официально он используется для других целей!; десятилетия, потраченные на попытки стандартизовать syslog, были потрачены зря! люди продолжают пользоваться стихийно сложишимся протоколом, описанным в RFC 3164, просто заворачивая его в TCP; но ничего! мы их железной рукой. ; устройства (генераторы сообщений) делятся на устаревшие (legacy) и соответствующие стандарту (RFC 5424, standardized); подтверждений нет; приватность, достоверность, упорядоченность не обеспечиваются, кроме как средствами TCP; кодировка US-ASCII с использованием NVT (Network Virtual Terminal, RFC 5198), но коллектор д.б. готов принять сообщения в различной кодировке от одного и того же релея; TCP приёмник слушает порт, TCP отправитель начинает сессию, TCP приёмник не посылает данные, в случае проблем просто закрывает соединение; TCP отправитель посылает поток сообщений по одному в TCP кадре одним из способов (можно отличить по первому символу — цифра или » до 19 )
  • -d (отладочный режим)
  • -f имя-конфигурационного-файла (по умолчанию, /etc/syslog.conf)
  • -h (изменить обычное поведение, при котором сообщения, принятые от удаленных хостов, не передаются дальше для записи на удаленном хосте во избежание зацикливания)
  • -l список-хостов (список хостов, имена которых должны записываться в простом виде, а не FQDN; разделяются двоеточием)
  • -m минут (интервал для регулярных временных записей; по умолчанию — 20; если 0, то не делать вообще)
  • -n (не уходить в фоновый режим; необходим для запуска из init)
  • -p прослушиваемый-сокет (по умолчанию: /dev/log)
  • -r (разрешить принимать сообщения от удаленных хостов; firewall д.б. приоткрыт; в /etc/services д.б. определен syslog для 514/udp)
  • -s список-доменов (обрезать из имен хостов имена указанных доменов; разделяются двоеточием; по умолчанию обрезается домен, совпадающий с доменом сервера syslog)
  • -v (показать версию и закончить работу)
  • -x (запретить определять имя хоста по его адресу, предотвращает deadlock при работе на одном хосте с сервером DNS)

Используемые файлы:

  • /etc/syslog.conf — конфигурационный файл (изменяется при запуске параметром -f)
  • /dev/log — сокет, с которого читаются локальные сообщения (изменяется при запуске параметром -p)
  • /var/run/syslogd.pid — идентификатор процесса

Реакция на сигналы:

  • SIGHUP — реинициализация (закрывает все файлы, читает заново файл конфигурации)
  • SIGTERM — завершение работы
  • SIGINT, SIGQUIT — завершение работы, если выключена отладка
  • SIGUSR1 — включить/выключить отладку (только при использовании ключа -d)

Запускается с правами root. Не меняет права доступа к файлам. Если вынужден создавать файл, то делает его с правами 644. При необходимости ограничить доступ к журналу, соответствующий файл надо создать вручную (или поменять права доступа). Особые проблемы создает logrotate.

Представляет собой набор правил маршрутизации сообщений. Комментарии начинаются с символа ‘#’. Обратная косая черта в конце строки означает продолжение правила на следующей строке. Каждое правило состоит из селектора и действия, которые разделяются табуляциями (в старых системах — Solaris 5) или пробелами (Linux). Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то выполняется указанное в правиле действие. Для одного сообщения м.б. выполнено произвольное количество действий (т.е. обработка сообщения не прекращается при первом успехе).

Селектор состоит из двух частей, разделенных точкой: источник сообщения и уровень серьезности. Прописные и строчные буквы не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме определенных в syslog(3) источников, можно указывать mark (регулярные временные метки), security (устаревший синоним для auth ). Кроме определенных в syslog.h уровней серьезности можно использовать warn (синоним для warning ), error (синоним для err ), panic (синоним для emerg ). Сообщения с уровнем, равным или выше указанного в селекторе, и источником, равным указанному в селекторе, считается подходящим. Звездочка перед точкой соответствует любому источнику ( кроме daemon и syslog! ), после точки — любому уровню. Слово none после точки — никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую). В этом случае приоритет можно указывать только для последнего источника. В одной строке можно указывать несколько селекторов через ‘;’. Семантика не ясна: если использовать позитивные селекторы, то выполняется логическое ИЛИ, если негативные (none и восклицательный знак), то логическое И.

В новом syslogd (linux) перед уровнем можно поставить знак равенства — селектору будут соответствовать только сообщения с указанным уровнем (но не с высшим); восклицательный знак — не будут соответствовать сообщения с уровнем равным или большим; восклицательный знак и равенство — не будут соответствовать сообщения с уровнем, равным указанному.

В качестве действия можно указывать:

  • имя обычного файла (полный путь от корня), минус перед именем отключает синхронизацию записи (ускорение на порядок и более!)
  • поименованные каналы — fifo (перед именем ставится вертикальная черта), сам канал д.б. создан перед запуском syslogd командой mkfifo
  • терминал или консоль (/dev/console)
  • @имя-хоста (передать сообщений для удаленной журнализации)
  • список пользователей (через запятую), на терминалы которых будет послано сообщение
  • звездочка для посылки сообщения на все терминалы (wall)

Включен в состав пакета sysklogd (RH 6.2: sysklogd-1.3.31-16, RH 7.0: sysklogd-1.3.33-8, RH 7.2: sysklogd-1.4.1-4). Также в этот пакет входит klogd.

Процедура запуска, остановки, перезапуска (syslogd и klogd): /etc/rc.d/init.d/syslog (символьные ссылки на нее из директорий /etc/rc.d/rc?.d/). Ключи запуска считывает из файла /etc/sysconfig/syslog (начиная с RH 7.2). Статус определяется по наличию файла /var/lock/subsys/syslog. Номер процесса хранится в /var/run/syslogd.pid.

При разборе файла конфигурации syslogd сравнивает адрес loghost (определяется в /etc/hosts, не через DNS) с адресом своего компьютера и при совпадении определяет переменную LOGHOST. После этого syslog.conf пропускается через макропроцесссор m4(1). В основном, это используется для того, чтобы один и тот же конфигурационный файл можно было использовать на клиентских и серверном (с точки зрения syslog) хостах.

Процедура запуска и остановки: /etc/init.d/syslog (ссылки на нее из директорий /etc/rc?.d). Номер процесса хранится в /etc/syslog.pid.

klogd читает сообщения ядра (либо через /proc/kmsg, либо с помощью системных вызовов), определяет уровень, преобразует адреса команд в имена программ и передает сообщение syslogd.

Параметры запуска:

  • -c уровень (сообщения данного уровня и менее серьезные будут передаваться syslog, а более серьезные — выводиться на консоль; по умолчанию — 7; 0 указывать нельзя)
  • -d (отладочный режим)
  • -f имя-файла (журнализовать в указанный файл вместо syslog)
  • -i (перезагрузить символы модулей в уже работающем klogd, необходимо использовать при каждой загрузке или выгрузке модуля; надеюсь, что текущие версии insmod, rmmod и modprobe делают это самостоятельно)
  • -I (перезагрузить символы ядра и модулей в уже работающем klogd)
  • -k имя-файла (использовать указанный файл как таблицу символов ядра вместо /boot/System.map)
  • -n (не уходить в фоновый режим; необходим для запуска из init)
  • -o (одноразовый режим — журнализовать все сообщения, скопившиеся в буфере ядра и завершить работу)
  • -p (на всякий случай перезагружать таблицу символов модулей в момент преобразования адресов — ядро может оказаться не в состоянии сделать это)
  • -s (использовать только системные вызовы и не обращаться к /proc/kmsg для получения исходных сообщений)
  • -v (показать версию и закончить работу)
  • -x (не преобразовывать адреса в имена)
  • -2 (сообщения аварийного завершения ядра — Oops! -выдаются дважды: до преобразования адресов в имена — для ksymoops — и после)

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

  • KERN_EMERG — 0 (system is unusable)
  • KERN_ALERT — 1 (action must be taken immediately)
  • KERN_CRIT — 2 (critical conditions)
  • KERN_ERR — 3 (error conditions)
  • KERN_WARNING — 4 (warning conditions)
  • KERN_NOTICE — 5 (normal but significant condition)
  • KERN_INFO — 6 (informational)
  • KERN_DEBUG — 7 (debug-level messages)


Реакция на сигналы:

  • SIGINT, SIGKILL, SIGTERM and SIGHUP — завершение работы
  • SIGTSTP — остановить журнализацию
  • SIGCONT — возобновить, возможно выбрав другой источник сообщений (/proc/kmsg или системные вызовы)
  • SIGUSR1 — перезагрузить символы модулей
  • SIGUSR2 — перезагрузить символы ядра и модулей
Илон Маск рекомендует:  Хостинг или VPS Как работает, что выбрать, когда переходить на VPS

Номер процесса хранится в /var/run/klogd.pid.

Слит в sysklog. Заменён в rsyslog.

logger — запись сообщения в журнал из командной строки (sh, bash и др.). Входит в состав пакета util-linux. Параметры:

  • [-i] (включать номер процесса в сообщение)
  • [-s] (дублировать сообщение на stderr)
  • [-f имя-файла] (сохранять сообщение в указанном файле)
  • [-p facility.level] (по умолчанию: user.notice; kern преобразуется в user)
  • [-t tag] (задать поле TAG)
  • [-u socket] (записывать в указанный сокет, вместо обращения к syslogd)
  • текст сообщения

Инициализация записи в журнал: openlog — указывается стандартный префикс, добавляемый ко всем последующим сообщениям (обычно имя программы, номер процесса в квадратных скобках и двоеточие); источник и опции. closelog — завершить запись в журнал. syslog — запись в журнал (указывается источник, уровень серьезности и формат строки как в printf).

logrotate (версия 3.2-1/3.3.2-1/3.5.9/3.6.9/3.7.1/3.8.6) — борьба с растущими журналами: ротация (создание версий), сжатие, удаление и отправка по почте. Запускается ежедневно cron-ом (/etc/cron.daily/logrotate) и позволяет обрабатывать журналы, если они превысили указанный размер или с указанным временным интервалом. Позволяет обрабатывать не только журналы syslog, но и любых других программ. Параметры:

  • -?
  • —verbose ( без этого ключа не выводятся сообщения об ошибках )
  • -d (отладочный режим, реальных изменений не производится)
  • -f (производить изменения, даже если logrotate не видит необходимости — используется при изменениях в списке обрабатываемых журналов)
  • -s имя-файла-состояния (текущее состояние журналов хранится в этом файле между запусками, по умолчанию — /var/lib/logrotate.status или /var/lib/logrotate/logrotate.status)
  • -m имя-почтовой-программы («/bin/mail -s»; на вход ей подаётся текст письма, первый параметр — тема письма, второй — получатель)
  • имена-конфигурационных-файлов (имена через пробел; порядок имеет значение; если указано имя каталога, то каждый файл в ней считается конфигурационным; владельцем файла д.б. root в RH используется файл /etc/logrotate.conf и каталог /etc/logrotate.d)

Конфигурационный файл определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Для каждой серии обрабатываемых журналов задаются локальные параметры: указывается базовое имя файла, а затем в фигурных скобках локальные параметры по одному на строке. Имя файла может быть заключено в кавычки по правилам shell, если оно содержит пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа «#» являются комментариями. Параметры, указанные в следующем конфигурационном файле перекрывают значение параметров, указанных в предыдущем файле. Локальные параметры имеют приоритет над глобальными. Порядок файлов в конфигурационной директории не определен.

Параметры:

  • compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
  • compresscmd (задает программу сжатия, по умолчанию — gzip)
  • uncompresscmd (задает программу разжатия, по умолчанию — ungzip)
  • compressext (задает суффикс для сжатых файлов, «.gz»)
  • compressoptions (задает параметры программы сжатия; по умолчанию — «-6», т.е. максимальное сжатие для gzip)
  • copy | nocopy (копировать журнал не трогая исходный)
  • copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель? )
  • create [[права-доступа] владелецгруппа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами — права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
  • createolddir права-доступавладелецгруппа | nocreateolddir
  • daily (смена версий в серии происходит ежедневно)
  • delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
  • dateext | nodateext (старые версии получают суффикс в виде «-YYYYMMDD» вместо номера)
  • dateformat формат-суффикса (позволяет задать формат в стиле strftime(3), но только %Y %m %d %H и %s; по умолчанию «-%Y%m%d» или «-%Y%m%d%H»; формат должен обеспечивать правильную сортировку файлов)
  • dateyesterday (использовать вчерашнюю дату в dateext)
  • errors email (кому направлять сообщения об ошибках; удалён в версии ? )
  • extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия — mylog.1.foo.gz вместо mylog.foo.1.gz)
  • hourly (ежечасно, подсистема cron daily к этому не готова)
  • ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
  • include имя-файла | имя-rfnfkjuf (текстуально подставить файл или все файлы из указанного каталога; не включаются подкаталоги, специальные файлы и файлы с суффиксами из списка исключений tabooext; нельзя использовать внутри секции)
  • mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
  • mailfirst (посылать не удаляемую версию журнала, а первую)
  • maillast (посылать удаляемую версию журнала; действует по умолчанию)
  • maxage дней (удалять файлы старше указанного)
  • maxsize байт (смена версии происходит, если размер журнала превысил указанное число или подошло время; можно использовать суффиксы «k» — килобайт — и «M» — мегабайт)
  • minsize байт (смена версии происходит, если размер журнала превысил указанное число и подошло время; можно использовать суффиксы «k» — килобайт — и «M» — мегабайт)
  • missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
  • monthly (смена версий происходит ежемесячно)
  • olddir каталог | noolddir (во время смены версий журнал перемещается в указанный каталог; д.б. на том же физическом устройстве, если не исполльзуется режимы copy, copytruncate или renamecopy)
  • postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии; абсолютный путь к журналу передаётся как первый параметр скрипта)
  • prerotate (все дальнейшие строчки до строки endscript исполняются как команды shell перед процессом смены версии; абсолютный путь к журналу передаётся как первый параметр скрипта)
  • firstaction (все дальнейшие строчки до строки endscript исполняются как команды shell перед процессом смены версии первого файла в группе; шаблон группы файлов передаётся как первый параметр скрипта)
  • lastaction (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии последнего файла в группе; шаблон группы файлов передаётся как первый параметр скрипта)
  • preremove (все дальнейшие строчки до строки endscript исполняются как команды shell перед удалением журнала; абсолютный путь к журналу передаётся как первый параметр скрипта)
  • rotate число (сколько старых версий хранить; если 0, то ни одной)
  • size байт (смена версии происходит, если размер журнала превысил указанное число и наступило его время; можно использовать суффиксы «k» — килобайт — и «M» — мегабайт)
  • sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
  • shred | noshred (использовать для удаления файла утилиту shred вместо unlink)
  • shredcycles число
  • start число (начинать нумерацию поколений с указанного числа; количество версий отсчитывать от него же)
  • su имя-пользователягруппа (работать от имени указанного пользователя)
  • tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак «плюс», то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, .disabled, .dpkg-old, .dpkg-dist, .dpkg-new, .cfsaved, .ucf-old, .ucf-dist, .ucf-new, «,v», .swp, .cfsaved, .rhn-cfg-tmp-* и «

«)

  • weekly [день] (смена версий происходит еженедельно; день 0 — воскресенье)
  • yearly (смена версий происходит ежегодно)
  • В поставке RH /etc/logrotate.conf описывает глобальные параметры и параметры для /var/log/wtmp и /var/log/lastlog и ссылается на директорию /etc/logrotate.d, в которую каждый пакет записывает локальные параметры для своих журналов.

    Пример для центрального сервера syslog (текущий журнал в /var/log/syslog/current, архив в /var/log/syslog/old):

    logwatch представляет собой платформу (framework) для написания программ (называемых фильтрами) извлечения полезной информации из многочисленных, больших и разноформатных журналов (не только syslog) и формирования отчётов с указанной детализацией за указанный период времени, посылаемых по email.

    Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает perl 5.8 и новее. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout. Перед вызовом фильтра устанавливаются переменные окружения: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Основная программа также написана на perl: /usr/share/logwatch/scripts/logwatch.pl (ранее — до версии 7 — /etc/log.d/scripts/logwatch.pl, /etc/log.d/logwatch и /usr/sbin/logwatch и /etc/cron.daily/0logwatch (или /etc/cron.daily/00-logwatch) — это символьные ссылки на нее).

    Каталог /usr/share/logwatch/default.conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит конфигурационные файлы групп журналов, в которых хранятся записи обслуживаемых сервисов. Каждая группа журналов описывается отдельным файлом имя-группы.conf, в котором задаются:

    • LogFile = имя файла, содержащего журнал, или шаблон имен; можно задавать несколько имен или шаблонов; имена м.б. относительно LogDir
    • Archive = имя файла, созданного logrotate архивной версии журнала, или шаблон имен; можно задавать несколько имен или шаблонов; можно использовать суффиксы сжатых файлов; имена м.б. относительно LogDir
    • имена фильтров ( только по одному разу, хотя в показано другое! ) из /usr/share/logwatch/scripts/shared/ в виде
      *имя-фильтра = параметры, например, чтобы отфильтровать журнал по дате, если она записана в стандартном формате syslog, надо использовать строку:
      *ApplyStdDate =

    Каталог /usr/share/logwatch/dist.conf/logfiles/ содержит изменения настроек групп журналов для дистрибутива (пусто в RHEL7).

    Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек групп журналов.

    Каталог /usr/share/logwatch/default.conf/services/ (ранее /etc/log.d/conf/services/) содержит конфигурационные файлы сервисов, чьи записи в журналах logwatch будет обрабатывать. Каждый сервис описывается отдельным файлом имя-сервиса.conf, в котором задаются:

    • # комментарий
    • LogFile = имя группы журналов
    • имена фильтров из /usr/share/logwatch/scripts/shared/ в виде
      *имя-фильтра = параметры, запускаемых до фильтра сервиса
    • $имя-переменной окружения = значение
    • Detail=уровень

    Каталог /usr/share/logwatch/dist.conf/services/ содержит изменения настроек сервисов для дистрибутива (пусто в RHEL7).

    Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек сервисов.

    Каталог /usr/share/logwatch/scripts/logfiles/ (ранее /etc/log.d/scripts/logfiles/) содержит фильтры обработки групп журналов: при обработке группы журналов все файлы в каталоге /usr/share/logwatch/scripts/logfiles/имя-группы используются как фильтры.

    Каталог /usr/share/logwatch/scripts/services/ содержит фильтры обработки записей конкретных сервисов.

    Каталог /usr/share/logwatch/scripts/shared/ содержит общие фильтры, используемые в конфигурационных файлах групп журналов:

    • applystddate — фильтрует журнал по требуемой дате, если он записан в формате syslog (здесь и в приватных фильтрах по дате навставлять LANG= перед вызовом date, а то Mar никак не совпадает с Мар ;)
    • expandrepeat — превращает строки «last message repeated» в соответствующее число строк с текстом сообщения из предыдущей строки
    • onlycontains — оставляет только те строки журнала, которые содержат указанную строку (я поставил кавычки вокруг «$*»)
    • onlyservice — выделяет из журнала в формате syslog строки, относящиеся к указанному сервису (имя сервиса передается как параметр)
    • remove — оставляет только те строки журнала в формате syslog, которые не содержат указанную строку ( я поставил кавычки вокруг «$*» и наделал remove1, remove2 и т.д. так как не понял как указать несколько подшаблонов для egrep в одной строке ; кстати, параметры подставляются в shell, так что спецсимволы тоже нельзя использовать)
    • removeheaders — удаление стандартных полей (дата, время, имя хоста, этикетка сервиса и номер процесса)
    • removeservice — выделяет из журнала в формате syslog строки, не относящиеся к указанному сервису (имя сервиса передается как параметр)

    Параметры по умолчанию хранятся в файле /usr/share/logwatch/default.conf/logwatch.conf (параметры от разработчика), /usr/share/logwatch/dist.conf (параметры дистрибутива, пусто в RHEL) и /etc/logwatch/conf/logwatch.conf (локальные параметры, ранее /etc/log.d/conf/logwatch.conf, /etc/log.d/logwatch.conf есть символьная ссылка на него):

    • LogDir — каталог, относительно которого рассматриваются имена файлов
    • MailTo — кому отправлять отчет
    • Print — вместо посылки отчета по почте выдать его на stdout
    • Save — вместо посылки отчета по почте сохранит его в указанном файле
    • Archives — использовать версии журналов, созданных logrotate
    • Range — рассматриваемый временной интервал: All, Today, Yesterday (вчерашние календарные сутки)
    • Detail — уровень подробности отчета: от 0 до 10 или Low, Med, High
    • Service — All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров)
    • LogFile — All или имя группы журналов (можно указывать несколько групп)

    В дополнение к logwatch.conf каждый из 3 каталогов содержит подкаталоги services и logfiles, которые позволяют задать параметры для конкретных групп файлов (имя-группы-журналов.conf) и сервисов (имя-сервиса.conf), а также ignore.conf (содержит регулярные выражения, описывающие строки, которые не должны появиться в отчётах) и override.conf.

    Ключи запуска:

    • —-help
    • —detail уровень (уровень продробности отчета: high (10), med (5) или low (0))
    • —logfile группа-журналов (обрабатывать только журналы данной группы; группа задается символическим именем в конфигурационном файле; можно задавать несколько групп)
    • —service имя-сервиса (обрабатывать только те записи в журналах, которые относятся к данному сервису; сервис задается символическим именем в конфигурационном файле; можно задавать несколько сервисов; имя All вызывает обработку записей для всех сервисов)
    • —output<stdout|mail|file> (по умолчанию, stdout)
    • —format<text|html> (по умолчанию, text)
    • —print (выдавать отчет на stdout; отсутствует с версии ? )
    • —save имя-файла (записать отчет в указанный файл; отсутствует с версии ? )
    • —mailto адрес (послать отчет по указанному адресу)
    • —filename имя-файла (сохранить отчёт в файл)
    • —range интервал-дат (обрабатывать только те записи в журналах, которые относятся к данному интервалу времени, даты в формате Date::Manip (по умолчанию ‘Yesterday’), период задаёт размер интервала (по умолчанию ‘for that day’): Yesterday, Today, All, дата[ период], between дата1 and дата2[ период], since дата[ период], Help — рассказывает о синтаксисе)
    • —archives (обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии)
    • —hostlimit имя-хоста[. ] (ограничиться информацией с указанных хостов)
    • —hostname имя-хоста (указать имя хоста в журнале)
    • —html_wrap число (число символов в строке для вывода в формате HTML)
    • —numeric (не преобразовывать IP в доменные имена)
    • —debug уровень (от 0 до 100)
    • —logdir каталог
    • —no-oldfiles-log (не информировать о старых дурналах во временном каталоге)

    Основной способ использования состоит во включении файла 00-logwatch или 0logwatch (начинается с «00», чтобы выполняться до logrotate) в каталог /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию.

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

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

    Соответствие между формальным именем источника и реальным устройством или программой:

    • local0 — Cisco и прочие железки
    • local1 — bind и DNS
    • local3 — ftp/snort (есть специальное имя источника, но Solaris 2.5 его не знает)
    • local4 — squid
    • local5 — POP3/IMAP
    • local6 — tac_plus
    • local7 — загрузка Linux

    На сервере должен быть открыт экран для порта 514/udp (можно ограничить исходные адреса пакетов, но это поможет только от случайностей). Запуск syslogd (параметры в /etc/rc.d/init.d/syslog или /etc/sysconfig/syslog) должен быть с ключами «-r -m 0» (и еще «-x», если на этом же компьютере работает сервер DNS). Запуск klogd с ключами «-2 -c 1». Настройка syslog.conf:

    • *.crit — сообщения уровня серьезности CRIT и выше выдавать на терминалы и записывать в отдельный файл (chmod 600), свои сообщения посылать на запасной сервер; sendmail считает критическими сообщения о проблемах с приемом письма
    • kern — создать файл kern для сообщений всех уровней (chmod 600)
    • mail — создать файл mail для сообщений всех уровней (без синхронизации)
    • auth, authpriv — создать файл secure для сообщений всех уровней (chmod 600)
    • news — в директории news создать для каждого уровня серьезности отдельный файл (debug без синхронизации)
    • cron — создать файл cron для сообщений всех уровней (cron в RH 6.2 и Solaris 2.5 не умеют использовать syslog)
    • local0 — в директории cisco создать для каждого уровня серьезности отдельный файл (err и ниже без синхронизации)
    • local1 — в директории bind создать для каждого уровня серьезности отдельный файл (err и ниже без синхронизации)
    • local3 — в директории ftp создать для каждого уровня серьезности отдельный файл (info и debug без синхронизации)
    • local5 — создать файл imap.log для сообщений всех уровней
    • local6 — создать файл tac_plus.log для сообщений всех уровней
    • local7 — файл boot.log (сообщения при загрузке системы и запуске или остановке syslogd и klogd)
    • все сообщения уровня INFO и выше, не попавшие в один из определенных выше файлов, записывать в файл messages (chmod 600)

    На клиентских компьютерах настраиваем syslog так, чтобы все сообщения передавались на сервер syslog, сообщения об ошибках дублировались в /var/log/syslog, сообщения о критическом состоянии дублировались на консоль, терминалы пользователей. На компьютерах с linux также сбрасывать в локальный файл сообщения о загрузке (local7, boot.log). Запасной сервер syslog должен принимать сообщения критического уровня из сети и записывать их в файл (дырка в экране, ключ запуска «-r»).

    logrotate: хранить вечно, менять версии по возможности реже (ежемесячно, кроме squid), сбрасывать в отдельные директории (кроме squid) и сжимать (в отложенном режиме, кроме ftpd, linuxconf, sendfax), [ошибки и удаляемые файлы посылать мне]. Привести в соответствие параметры для файла syslog.


    Настроить /etc/logwatch/scripts и /usr/share/logwatch/.

    Источники данных Syslog в Azure Monitor Syslog data sources in Azure Monitor

    Системный журнал (Syslog) — это протокол ведения журнала событий, который обычно используется в Linux. Syslog is an event logging protocol that is common to Linux. Приложения отправляют сообщения, которые могут храниться на локальном компьютере или передаваться в сборщик системного журнала. Applications will send messages that may be stored on the local machine or delivered to a Syslog collector. При установке агента Log Analytics для Linux он настраивает локальную управляющую программу Syslog для пересылки сообщений в агент. When the Log Analytics agent for Linux is installed, it configures the local Syslog daemon to forward messages to the agent. Затем агент отправляет сообщение в Azure Monitor, где создается соответствующая запись. The agent then sends the message to Azure Monitor where a corresponding record is created.

    Azure Monitor поддерживает коллекцию сообщений, отправленных rsyslog или syslog-ng, где rsyslog является управляющей программой по умолчанию. Azure Monitor supports collection of messages sent by rsyslog or syslog-ng, where rsyslog is the default daemon. Управляющая программа syslog по умолчанию не поддерживается для сбора событий системного журнала в Red Hat Enterprise Linux версии 5, CentOS и Oracle Linux (sysklog). The default syslog daemon on version 5 of Red Hat Enterprise Linux, CentOS, and Oracle Linux version (sysklog) is not supported for syslog event collection. Чтобы собирать данные системного журнала из дистрибутивов этих версий, требуется установить и настроить управляющую программу rsyslog , которая заменит sysklog. To collect syslog data from this version of these distributions, the rsyslog daemon should be installed and configured to replace sysklog.

    С сборщиком syslog поддерживаются следующие возможности. The following facilities are supported with the Syslog collector:

    • кернинг kern
    • user user
    • mail mail
    • daemon daemon
    • auth auth
    • syslog syslog
    • LPR lpr
    • news news
    • uucp uucp
    • cron cron
    • аусприв authpriv
    • ftp ftp
    • local0-local7 local0-local7

    Для любого другого средства настройте источник данных пользовательских журналов в Azure Monitor. For any other facility, configure a Custom Logs data source in Azure Monitor.

    Настройка системного журнала Configuring Syslog

    Агент Log Analytics для Linux будет собирать события только с тех устройств и только с тем уровнем серьезности, которые заданы в его конфигурации. The Log Analytics agent for Linux will only collect events with the facilities and severities that are specified in its configuration. Системный журнал можно настроить на портале Azure или с помощью управления файлами конфигурации на агентах Linux. You can configure Syslog through the Azure portal or by managing configuration files on your Linux agents.

    Настройка системного журнала на портале Azure Configure Syslog in the Azure portal

    Настройте системный журнал в меню «Данные» раздела «Расширенные параметры». Configure Syslog from the Data menu in Advanced Settings. Эта конфигурация передается в файл конфигурации на каждом агенте Linux. This configuration is delivered to the configuration file on each Linux agent.

    Можно добавить новое устройство, введя его имя и нажав кнопку + . You can add a new facility by typing in its name and clicking +. Для каждого устройства будут собираться сообщения только с выбранным уровнем серьезности. For each facility, only messages with the selected severities will be collected. Укажите уровни серьезности сообщений, которые хотите получать от соответствующего устройства. Check the severities for the particular facility that you want to collect. Дополнительные критерии для фильтрации сообщений задавать нельзя. You cannot provide any additional criteria to filter messages.

    По умолчанию все изменения конфигурации автоматически отправляются во все агенты. By default, all configuration changes are automatically pushed to all agents. Если вы хотите настроить syslog вручную на каждом агенте Linux, снимите флажок Применить к моим компьютерам следующую конфигурацию. If you want to configure Syslog manually on each Linux agent, then uncheck the box Apply below configuration to my machines.

    Настройка системного журнала на агенте Linux Configure Syslog on Linux agent

    При установке агента Log Analytics на клиент Linuxон устанавливает файл конфигурации системного журнала по умолчанию, который определяет устройства и уровень серьезности для собираемых сообщений. When the Log Analytics agent is installed on a Linux client, it installs a default syslog configuration file that defines the facility and severity of the messages that are collected. Можно изменить этот файл, чтобы внести изменения в конфигурацию. You can modify this file to change the configuration. Файл конфигурации отличается в зависимости от того, какую управляющая программу системного журнала установил клиент. The configuration file is different depending on the Syslog daemon that the client has installed.

    При изменении конфигурации системного журнала требуется перезапустить управляющую программу syslog, чтобы изменения вступили в силу. If you edit the syslog configuration, you must restart the syslog daemon for the changes to take effect.

    rsyslog rsyslog

    Файл конфигурации для rsyslog находится в расположении /etc/rsyslog.d/95-omsagent.conf. The configuration file for rsyslog is located at /etc/rsyslog.d/95-omsagent.conf. Его содержимое по умолчанию приведено ниже. Its default contents are shown below. В данном случае собираются сообщения системного журнала, отправленные из локального агента для всех устройств и имеющие уровень серьезности «предупреждение» или выше. This collects syslog messages sent from the local agent for all facilities with a level of warning or higher.

    Устройство можно удалить, выполнив удаление соответствующего раздела в файле конфигурации. You can remove a facility by removing its section of the configuration file. Можно ограничить уровни серьезности для сообщений, собираемых с конкретного устройства, изменив соответствующую запись устройства. You can limit the severities that are collected for a particular facility by modifying that facility’s entry. Например, чтобы ограничить сообщения с пользовательского устройства уровнем серьезности «ошибка» или выше, необходимо изменить соответствующую строку в файле конфигурации таким образом: For example, to limit the user facility to messages with a severity of error or higher you would modify that line of the configuration file to the following:

    syslog-ng syslog-ng

    Файл конфигурации для syslog-ng находится в расположении /etc/syslog-ng/syslog-ng.conf. The configuration file for syslog-ng is location at /etc/syslog-ng/syslog-ng.conf. Его содержимое по умолчанию приведено ниже. Its default contents are shown below. В данном случае собираются сообщения системного журнала, отправленные из локального агента для всех устройств и всех уровней серьезности. This collects syslog messages sent from the local agent for all facilities and all severities.

    Устройство можно удалить, выполнив удаление соответствующего раздела в файле конфигурации. You can remove a facility by removing its section of the configuration file. Можно ограничить уровни серьезности для сообщений, собираемых с конкретного устройства, удалив их из его списка. You can limit the severities that are collected for a particular facility by removing them from its list. Например, чтобы ограничить сообщения с пользовательского устройства только уровнями серьезности «оповещение» и «критический», необходимо изменить соответствующий раздел в файле конфигурации таким образом: For example, to limit the user facility to just alert and critical messages, you would modify that section of the configuration file to the following:

    Сбор данных из дополнительных портов системного журнала Collecting data from additional Syslog ports

    Агент Log Analytics прослушивает сообщения Syslog на локальном клиенте через порт 25224. The Log Analytics agent listens for Syslog messages on the local client on port 25224. При установке агента применяется конфигурация системного журнала по умолчанию. Файл конфигурации расположен в следующем расположении: When the agent is installed, a default syslog configuration is applied and found in the following location:

    • rsyslog: /etc/rsyslog.d/95-omsagent.conf ; Rsyslog: /etc/rsyslog.d/95-omsagent.conf
    • syslog-ng: /etc/syslog-ng/syslog-ng.conf . Syslog-ng: /etc/syslog-ng/syslog-ng.conf

    Номер порта можно изменить, создав два файла конфигурации: FluentD и rsyslog-or-syslog-ng (в зависимости от установленной управляющей программы системного журнала). You can change the port number by creating two configuration files: a FluentD config file and a rsyslog-or-syslog-ng file depending on the Syslog daemon you have installed.

    Файл конфигурации FluentD должен быть новым и располагаться в папке /etc/opt/microsoft/omsagent/conf/omsagent.d . Замените значение записи port собственным номером порта. The FluentD config file should be a new file located in: /etc/opt/microsoft/omsagent/conf/omsagent.d and replace the value in the port entry with your custom port number.

    Для rsyslog в папке /etc/rsyslog.d/ необходимо создать файл конфигурации. Замените значение %SYSLOG_PORT% собственным номером порта. For rsyslog, you should create a new configuration file located in: /etc/rsyslog.d/ and replace the value %SYSLOG_PORT% with your custom port number.

    Если изменить это значение в файле конфигурации 95-omsagent.conf , он перезаписывается, когда агент применяет конфигурацию по умолчанию. If you modify this value in the configuration file 95-omsagent.conf , it will be overwritten when the agent applies a default configuration.

    Конфигурацию syslog-ng следует изменить. Для этого скопируйте пример конфигурации ниже и добавьте измененные параметры в конец файла конфигурации в папке /etc/syslog-ng/ . The syslog-ng config should be modified by copying the example configuration shown below and adding the custom modified settings to the end of the syslog-ng.conf configuration file located in /etc/syslog-ng/ . Не используйте метку %WORKSPACE_ID%_oms или %WORKSPACE_ID_OMS по умолчанию. Чтобы различить изменения, определите собственную метку. Do not use the default label %WORKSPACE_ID%_oms or %WORKSPACE_ID_OMS, define a custom label to help distinguish your changes.

    Если изменить эти значения по умолчанию в файле конфигурации, он перезаписывается, когда агент применяет конфигурацию по умолчанию. If you modify the default values in the configuration file, they will be overwritten when the agent applies a default configuration.

    После внесения изменений Syslog и службу агента Log Analytics следует перезапустить, чтобы изменения конфигурации вступили в силу. After completing the changes, the Syslog and the Log Analytics agent service needs to be restarted to ensure the configuration changes take effect.

    Свойства записей системного журнала Syslog record properties

    Записи системного журнала имеют тип Syslog и свойства, описанные в приведенной ниже таблице. Syslog records have a type of Syslog and have the properties in the following table.

    Свойство Property Описание Description
    Компьютер Computer Компьютер, с которого было получено событие. Computer that the event was collected from.
    Facility Facility Определяет часть системы, которая создала сообщение. Defines the part of the system that generated the message.
    HostIP HostIP IP-адрес системы, отправившей сообщение. IP address of the system sending the message.
    HostName HostName Имя системы, отправившей сообщение. Name of the system sending the message.
    SeverityLevel SeverityLevel Уровень серьезности события. Severity level of the event.
    SyslogMessage SyslogMessage Текст сообщения. Text of the message.
    ProcessID ProcessID Идентификатор процесса, создавшего сообщение. ID of the process that generated the message.
    EventTime EventTime Дата и время создания события. Date and time that the event was generated.

    Запросы к журналу для получения записей системного журнала Log queries with Syslog records

    В следующей таблице представлены различные примеры запросов к журналу, извлекающих записи из системного журнала. The following table provides different examples of log queries that retrieve Syslog records.

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

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

    Подготовка сервера

    На сервере нужно, предварительно, выполнить следующие настройки.

    Время

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


    Сначала задаем правильный часовой пояс:

    \cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

    * в данном примере мы использовали московское время.

    Затем устанавливаем и запускаем chrony.

    а) на системе CentOS / Red Hat:

    yum install chrony

    systemctl enable chronyd

    systemctl start chronyd

    б) на системе Ubuntu / Debian:

    apt-get install chrony

    systemctl enable chrony

    systemctl start chrony

    Брандмауэр

    Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.

    а) с помощью firewalld:

    firewall-cmd —permanent —add-port=514/

    б) с помощью iptables:

    iptables -A INPUT -p tcp —dport 514 -j ACCEPT

    iptables -A INPUT -p udp —dport 514 -j ACCEPT

    в) с помощью ufw:

    ufw allow 514/tcp

    ufw allow 514/udp

    SELinux

    Проверяем, работает ли в нашей системе SELinux:

    Если мы получаем в ответ:

    . необходимо либо настроить SELinux:

    semanage port -m -t syslogd_port_t -p tcp 514

    semanage port -m -t syslogd_port_t -p udp 514

    . либо отключить его командами:

    sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

    Установка и запуск rsyslog

    Установить rsyslog необходимо как на сервер, так и клиентские компьютеры. В зависимости от операционной системы сама установка будет выполняться одной из команд.

    а) для систем на базе RPM (Red Hat / CentOS):

    yum install rsyslog

    б) для систем на базе deb (Debian / Ubuntu):

    apt-get install rsyslog

    После установки разрешаем автозапуск службы и стартуем ее:

    systemctl enable rsyslog

    systemctl start rsyslog

    Настройка сервера

    Открываем конфигурационный файл:

    Снимаем комментарии со следующих строк:

    $ModLoad imudp
    $UDPServerRun 514

    $ModLoad imtcp
    $InputTCPServerRun 514

    * в данном примере мы разрешили запуск сервера для соединений TCP и UDP на портах 514. На самом деле, можно оставить только один протокол, например, более безопасный и медленный TCP.

    После добавляем в конфигурационный файл строки:


    $template RemoteLogs,»/var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log»
    *.* ?RemoteLogs
    &

    * в данном примере мы создаем шаблон с названием RemoteLogs, который принимает логи всех категорий, любого уровня (про категории и уровни читайте ниже); логи, полученный по данному шаблону будут сохраняться в каталоге по маске /var/log/rsyslog/ / .log; конструкция &

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

    Перезапускаем службу логов:

    systemctl restart rsyslog

    Настройка клиента

    Устанавливаем и запускаем rsyslog по инструкции, описанной выше. После приступаем к настройке клиента.

    Все логи

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

    * где 192.168.0.15 — IP-адрес сервера логов. *.* — перенаправлять любой лог.

    systemctl restart rsyslog

    Для определенных категорий

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

    Перезапускаем сервис логов:

    systemctl restart rsyslog

    Возможные категории для логов (facility):

    Категория Описание
    kern Сообщения, отправляемые ядром
    1 user Пользовательские программы
    2 mail Почта
    3 daemon Сервисы (демоны)
    4 auth Безопасность/вход в систему/аутентификация
    5 syslog Сообщения от syslog
    6 lpr Логи печати
    7 news Новостные группы (usenet)
    8 uucp Unix-to-Unix CoPy (копирование файлов между компьютерами)
    9 cron Планировщик заданий
    10 authpriv Безопасность/вход в систему/аутентификация — защищенный режим
    11 ftp Логи при передачи данных по FTP
    12 ntp Лог службы синхронизации времени (существует не везде)
    13 security, log audit Журнал аудита (существует не везде)
    14 console, log alert Сообщения, отправляемые в консоль (существует не везде)
    15 solaris-cron, clock daemon Cron в solaris (существует не везде)
    16-23 local0 — local7 Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7.

    Для определенного уровня

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

    Перезапускаем сервис логов:

    systemctl restart rsyslog

    Возможные уровни логов:

    Возможные категории для логов (severity):

    Уровень Расшифровка
    emerg Система не работает (PANIC)
    1 alert Серьезная проблема, требующая внимания
    2 crit Критическая ошибка
    3 err Ошибка (ERROR)
    4 warning Предупреждение (WARN)
    5 notice Важное информационное сообщение
    6 info Информационное сообщение
    7 debug Отладочная информация

    Аудит определенного лог-файла

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

    Настройка клиента

    Создаем новый конфигурационный файл:

    $ModLoad imfile
    $InputFileName /var/log/audit/audit.log
    $InputFileTag tag_audit_log:
    $InputFileStateFile audit_log
    $InputFileSeverity info
    $InputFileFacility local6
    $InputRunFileMonitor

    * в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.

    Перезапускаем сервис на клиенте:

    systemctl restart rsyslog

    Настройка сервера (фильтрация сообщений)

    На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл rsyslog:

    Создаем новый шаблон для захвата логов:

    $template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
    local6.* ?HostAudit

    * в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/ /audit.log.

    systemctl restart rsyslog

    Лог определенного приложения

    Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):

    Добавляем или редактируем соответствующие настройки для логов:

    .
    access_log syslog:server=192.168.0.15:514 info;
    error_log syslog:server=192.168.0.15:514 warn;
    error_log /var/log/nginx/error.log warn;
    .

    * в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.

    Проверяем корректность конфигурационного файла nginx:

    systemctl restart nginx

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


    В нашем примере сервер настроен на хранение логов по маске /var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log. Это значит, что в каталоге /var/log/rsyslog должны появляться папки с именами компьютеров, которые отправляют на сервер свои логи. Посмотреть список данных папок можно командой:

    Чтение логов выполняется обычной командой cat или tail, например:

    * здесь мы прочитаем лог для cron на компьютере comp1.

    В чем разница между syslog, rsyslog и syslog-ng?

    Я немного запутался в syslog, rsyslog и syslog-ng.

    Откуда я могу получить исходный код для syslog() ?

    Есть ли разница между rsyslog и rsyslogd?

    4 ответа

    В принципе, они все одинаковы, так как все они позволяют регистрировать данные из разных типов систем в центральном репозитории.

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

    Проект Syslog был самым первым проектом. Это началось в 1980 году. Это корневой проект для Syslog протокола. В это время Syslog — очень простой протокол. Вначале он поддерживает только UDP для транспорта, поэтому он не гарантирует доставку сообщений.

    В 1998 году появился syslog-ng . Он расширяет базовый syslog протокол с новыми функциями, такими как:

    • фильтрация содержимого
    • Вход в базу данных
    • TCP для транспорта
    • Шифрование TLS

    Далее появился Rsyslog в 2004 году. Он расширяет протокол syslog с новыми функциями, такими как:

    • Поддержка протокола RELP.
    • Поддержка буферной операции

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

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

    это 3 разных типа менеджеров журналов: он позволяет вашей системе собирать фильтр и передавать /хранить журналы.

      Syslog (демона, также называемого sysklogd ) является стандартным LM в распространенных дистрибутивах Linux. Легкий, но не очень гибкий, вы можете перенаправить поток журналов, отсортированный по объектам и степени тяжести для файлов и сети (TCP, UDP).

    rsyslog — это «расширенная» версия sysklogd , где файл конфигурации остается неизменным (вы можете скопировать файл syslog.conf напрямую в rsyslog.conf , и он работает); но у вас есть много новых интересных вещей, следующих с ним:

    • Вы можете прослушивать соединения TCP /UDP /. с ограничениями (порты, исходные IP-адреса)
    • Вы можете загрузить много модулей.
    • Вы можете различать фильтрацию журнала программой, источником, сообщением, pid и т. д. (например, каждое сообщение, помеченное сообщением «connexion closed» для файла closed.log)
    • Вы можете отменить сообщение после одного или нескольких правил Посетите http://www.rsyslog.com , который очень хорош.

    Syslog-ng является «Next-Gen». Я думаю, что это лучший способ управлять журналами: все это объект (источник, место назначения, фильтр и правило самой пересылки), и синтаксис ясен. Я сомневаюсь в функциональности, что rsyslog и syslog-ng отличаются.

    Откуда я могу получить исходный код для syslog ()

    Это обеспечивается glibc или реализациями libc на другие ароматы Unix. Этот вызов в основном отправляет ваше сообщение в syslog unix domain socket /dev /log. Этот сокет обычно создается системным регистратором (например, rsyslog, syslog-ng, nxlog и т. Д.).

    Это все демоны syslog, где rsyslog и syslog-ng — это более быстрые и многофункциональные замены для традиционного syslogd (в основном без поддержки). syslog-ng начал с нуля (с другим конфигурационным форматом), в то время как rsyslog был изначально fork syslogd, поддерживая и расширяя его синтаксис. В последние годы rsyslog начал поддерживать новый формат конфигурации. К настоящему времени очень сложно сравнивать эти два, не вникая в самую специфику и начинать пламенные войны.

    Система Syslog и журналы логов в Linux

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

    Как устроена система регистрации событий?

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

    Основным инструментом регистрации событий в UNIX и Linu до сих пор остаётся демон syslogd системы Syslog. Но следует иметь в виду также и то, что на протяжении длительного времени из-за многообразия всевозможных ответвлений UNIX и версий Linux множество программных пакетов, служебных скриптов, сетевых демонов используют свои собственные журналы, порой отличающимся экзотическим форматом.

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

    Журналы регистрации легко просматривать, поскольку они являются обычными текстовыми файлами. Для эффективной работы с журналами используются самые стандартные инструменты из базовой поставки любого дистрибутива — команды cat и grep. Если нужно «ворошить» очень большие и сложные по формату журналы, то можно (и даже нужно) вместо утилиты grep использовать другой, гораздо более производительный и гибкий в подобных задачах инструмент — утилиту awk. Язык обработки текста Perl также очень хорошо подходит для этого.

    Типичная запись системного журнала системы Syslog обычно выглядит следующим образом:

    В данном случае можно видеть, что в одном из журналов Syslog собраны события из нескольких источников: программы sbathd, pingem, pop-proxy. Также можно видеть, что события регистрируются для нескольких хостов, взаимодействующих с данной системой: backup, system, office и service.

    log файлы и их расположение в Linux

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

    Как правило, доступ для чтения файлов в указанных каталогах предоставляется только суперпользователю, однако нет ничего страшного, если для часто просматриваемых журналов, в которых также нет важной системной информации настроить более «демократический» режим доступа. Обычно к такому варианту также прибегают для удобства и экономии времени, когда нужно часто и регулярно изучать некоторые журналы, например для веб-сервера Apache, которые обычно находятся в /var/log/apache2 или /var/log/httpd.

    Стоит также помнить и о том, что бывают случаи, когда (особенно на сбойных конфигурациях) общий объём файлов журналов резко увеличивается, при этом велик риск «уложить» систему. Для удобства контроля за свободным пространством на устройствах хранения, а также для надёжности каталог /var часто выносят в отдельную файловую систему на отдельном разделе.

    Некоторые специальные файлы журналов

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

    Файл Программа Место Частота Системы Назначение
    acpid acpid Ф 64к RZ События, связанные с системой питания
    auth.log sudo и прочие S М U Информация об авторизации
    apache2/* httpd или apache2 Ф Д ZU Журналы веб-сервера Apache
    apt* APT Ф М U Установщики пакетов
    boot.log Сценарии запуска


    системы

    Ф М R Логи сценариев запуска
    boot.msg Ядро В Z Образ буфера сообщений ядра
    cron,

    cron/log

    cron S Н RAH Логи и сведения о работе демона cron
    cups/* CUPS Ф Н ZRU Сообщения, связанные с системой печати

    (CUPS)

    daemon.log Разное S Н U Сообщения средств демонов
    debug Разное S Д U Сообщения для отладки
    dmesg Ядро В RU Образ буфера сообщений ядра
    dpkg.log dpkg Ф М U Установщики пакетов
    faillog login Н Н RZU Информация о неудачных попытках авторизации
    apache2/* Httpd или apache2 Ф Д R Журналы веб-сервера Apache для каталога /etc
    kern.log login В RZ Все сообщения средств ядра
    lastlog login В RZ Время последней регистрации в системе каждого пользователя (этот файл бинарный)
    mail* Программы электронной почты S Н Все Сообщения средств электронной

    почты

    messages Разное S Н RZUS Основной системный журнальный файл
    rpmpkgs cron.daily В Д R Список установленных RPM-пакетов
    samba/* smbd и прочие Ф Н Сведения о работе сервера Samba
    secure sshd и прочие S М R Конфиденциальные авторизационные сообщения
    sulog su Ф SAH Сведения об удачных и неудачных попыток использования команды su
    syslog* Разное S H SUH Основной системный журнальный файл
    warn wpar S H Z События уровня системных предупреждений/ошибок
    wpars/* wpar Ф А Сведения о событиях загрузочных разделов
    wtmp login В M Все Сообщения о регистрации в системе (бинарный файл)
    xen/* Xen Ф 1m RZU Информация от монитора виртуальных машин Xen
    Xorg.n.log Xorg Ф Н RS Сообщения об ошибках сервера X Windows
    yum.log yum Ф М R Журнал управления пакетом

    Для данной таблицы действуют следующие обозначения: S — Syslog, В — встроенное имя, Ф — конфигурационный файл, Д — ежедневно, Н — еженедельно, М — ежемесячно, NN[km] — размер в килобайтах или мегабайтах, Z — SUSE, R — Red Hat и CentOS, S — Solaris, H — HP-UX, A — AIX. В столбце «Частота» указывается частота, с которой удаляется устаревшая информация, связанная со временем или с объёмом файла. В столбце «Программа» указывается программа, создающая файл.

    Следует отметить также, что большая часть сообщений для представленных в таблице файлов направляется в систему Syslog. Уровень критичности и программа, создающая файл задаются в конфигурационном файле /etc/initlog.conf. — так работает система Syslog. Файл faillog является двоичным, и поэтому может быть прочтён утилитой failog.

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

    Что такое код syslog

    Rsyslog имеет модульную архитектуру. Это позволяет удобно расширять функциональность. Модули подразделяются на группы, например некоторые из них:

    • модули ввода — применяются для использования различных источников сообщений, имена начинаются на im (imfile, etc)
    • модули вывода — используются для записи сообщений в различные места (файл, сокет , СУБД. ), имена начинаются на om (omsnmp, ommysql, etc)
    • модули парсинга (анализа содержимого) — используются для анализа содержимого, имена начинаются на pm (pmrfc5424, etc)
    • фильтрационные модули — позволяют фильтровать сообщения в соответствии со специальными правилами, имена начинаются на fm

    #################
    #### MODULES ####
    #################
    $ModLoad imuxsock # обеспечивает поддержку локальной системы логирования (читай — из /dev/log)
    $ModLoad imklog # обеспечивает поддержку журналирования ядра
    #$ModLoad immark # обеспечивает возможности маркирования сообщений —MARK—
    # обеспечивает получение сислог-сообщений через сеть по UDP
    $ModLoad imudp
    $UDPServerRun 514
    # обеспечивает получение по TCP
    $ModLoad imtcp
    $InputTCPServerRun 514
    Модули постоянно добавляются разработчиками и могут быть написаны любым желающим, со списком основных модулей можно ознакомиться на официальном сайте >здесь.

    Конфигурационные директивы (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
    #
    #includ все конфиги в формате *.conf из каталога /etc/rsyslog.d/
    $IncludeConfig /etc/rsyslog.d/*.conf

    Шаблоны (Templates) rsyslog

    http://www.rsyslog.com/doc/v8-stable/configuration/templates.html
    http://www.rsyslog.com/doc/rsyslog_conf_examples.html
    http://www.rsyslog.com/how-to-bind-a-template/
    Важной и ключевой особенностью rsyslogd является возможность использования шаблонов. Template позволяет:

    • 1. задавать формат выводимой информации,
    • 2. использовать динамические имена файлов логов на основании какого-либо правила.

    На самом деле, все выходные сообщения в rsyslogd формируются на основе шаблонов. Тут может возникнуть соответствующий вопрос — как же вывод формируется, если не указать никаких шаблонов в rsyslog.conf (ведь по умолчанию не указано никаких шаблонов)? Все просто. Имеются некоторые шаблоны (взятые из совместимые со старой версии syslog и статично прописанные в исходники 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[12125]:»), который выдал сообщение (извлекается из сообщения)
    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, соответствует шаблону:
    » 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 — традиционный формат журнала для передачи с добавлением долей секунды и зоны, соответствует шаблону:
    » %TIMESTAMP. date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg. sp-if-no-1st-sp%%msg%\»
    RSYSLOG_TraditionalForwardFormat — традиционный формат журнала для передачи на удалённый сервер соответствует шаблону:
    » %TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg. sp-if-no-1st-sp%%msg%\»

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

    Каждая строка правил сортировки имеет классический формат, как и в обычном syslog. Для понимания, что и как, необходимо почитать статью syslog. Кратко: правило состоит из селекотора и действия, разделенных пробелом или табулятором. Селектор в свою очередь состоит из источника и приоритета. Каждое сообщение сверяется с селектором из каждого правила последовательно, если селектор сообщения и правила совпадает, то выполняется указанное действие. При этом, после первого совпадения — обработка не останавливается. Перед действием, мессадж преобразуется в соответствии с шаблоном (шаблон по умолчанию, заданный в соответствующей директиве (заменяющий шаблон по умолчанию), заданный в данном действии шаблон — один из трех).
    К стандартным возможностям селекторов syslog добавились некоторые дополнительные возможности (напомню, что классически селектор — это источник.приоритет, он же facility.priority). В rsyslog в качестве селектора можно использовать значения переменных. В rsyslog применение переменных в селекторе называется Filters (фильтры). Выше в статье, а так же в первой статье о syslog описан классический подход к фильтрации на основе источник.приоритет (т.н.»traditional» severity and facility based selectors). Кроме традиционной фильтрации существует следующие виды фильтрации: RainerScript-based filters (фильтрация на основе языка RainerScript — фактически обычный if — then — else), property-based filters (фильтрация на основе свойств сообщения (как в template)). Давайте рассмотрим оба:
    Фильтрация RainerScript (RainerScript-based filters)
    RainerScript — это классический язык на основе if then else. В rsyslog RainerScript поддерживает вложенность условий, арифметические, логические и строковые операции. В целом, синтаксис следующий:
    if условие then блок_действий else блок_действий
    Соответственно, if, then — это обязательные операторы, определяющие конструкцию условия, else — по необходимости. блок_действий — может содержать одно действие (action), либо вложенный блок условий. Если блок условий содержит несколько действий, то он заключается в скобки. условие — содержит условие отбора сообщений для блока_действий. В условии можно использовать:
    логические выражения (and, or, not), а так же группировку данных выражений в виде: not условие0 and (условие 1 and условие 2).
    переменные (properties) — переменные указываются в виде $имя_переменной (например $hostname или $msg)
    операции сравнения (== — равно, != — не равно, > — больше, = — больше или равно, (!)contains — (не)содержит, (!)startswith — (не)начинается с)
    комментарии /* комментарии */ (сомнительный пункт . нужно ли его экранировать как в bash . )
    Описание языка есть на сайте. Маленький пример фильтра на основе RainerScript:
    if $syslogfacility-text == ‘local7’ and $msg startswith ‘CISCO’ and ($msg contains ‘warn’ or $msg contains ’emer’) then /var/log/cisco-alarm

    фильтрация на основе свойств сообщения (property-based filters)
    Давайте рассмотрим данный вид фильтрации.
    :переменная, [!]операция_сравнения, «искомое_значение» действие
    Что у нас тут есть: переменная — в соответствии с переменными,(в данном случае — без % или $), действие выполняемое над сообщением. операция_сравнения — может быть:
    contains — проверяет соответствие искомое_значение с любой частью строки в переменная
    isequal — проверяет, совпадает (целиком) ли искомое_значение с переменной
    isempty — проверяет, является ли переменная пустой (доступна с 6.6.2)
    startswith — проверяет, начинается ли переменная с искомое_значение
    regex или ereregex — сравнивает содержимое переменной, заданному в искомое_значение регулярному выражению в соответствии с regular и Extended Regular Expression соответственно
    Например: :msg, contains, «syslog» будет искать слово syslog в теле.
    Существует так же, специальный символ &, который повторяет выполнение прошлого фильтра и запускает действие, указанное после данного символа. Это очень удобно для фильтрации или экономии системных ресурсов, например: # экономим ресурсы:
    *.=crit /var/log/somefile
    & root
    & /var/log/criticalmessages
    # фильтруем сообщения
    *.* /var/log/allmsgs-incl-informational.log
    :msg, contains, «informational»

    *.* /var/log/allmsgs-no-informational.log
    то есть в первом варианте, rsyslogd нет необходимости несколько раз сравнивать селектор. Сообщение просто выполняет 3 действия.
    Действия (actions)
    Действия rsyslog полностью совместимы с действиями syslog. Так же, стоит учитывать, что в действии rsyslog, кроме стандартный значений syslog, добавились дополнительные (выделены цветом):
    /путь/к/файлу — отправить сообщения в простой файл (по умолчанию, rsyslogd умеет сам создавать новые файлы)
    ?имя_шаблона — вместо классического действия (/путь/к/файлу) в rsyslog можно указывать шаблон, в соответствии с которым будет динамически формироваться новый файл по заданному в шаблоне правилу.
    ?имя_шаблона;шаблон_фильтра — дополнительно, к шаблону имени файла (?имя_шаблона) возможно преобразовать сообщения поступающие в эти файлы в соответствии с заданным шаблоном фильтра (шаблон_фильтра).
    |/путь/к/fifo — отправить в именованный канал
    /dev/терминал или /dev/консоль — отправить на указанную консоль\терминал
    @имя-хоста-udp[:порт] — отправить на удаленный хост по UDP
    @@[модификаторы]имя-хоста-tcp[:порт]- отправить на удаленный хост по TCP, модификаторы указывают:
    zцифра — задает gzip сжатие отправляемых пакетов с уровнем сжатия заданным цифрой от 0-9 (9-максимальное)
    список пользователей через запятую — отправить на терминал сообщение указанным пользователям
    * — отправить всем пользователям (аналог команды wall)
    :имя_модуля_вывода:параметры_модуля[:имя_шаблона] — отправляет сообщение в модуль вывода с заданными параметрами и заданным шаблоном (по желанию)

    (тильда) — после данного символа сообщение будет удалено и дальнейшая обработка не продолжится
    ^имя_программы[;имя_шаблона] — можно написать свой обработчик сообщений, ему на stdin будет отправлено содержимое в соответствии с шаблоном
    =======================================================================

    Настройка сервера rsyslog в Debian

    для корректной работы rsyslogd необходимо разрешить получение syslog сообщения из сети, подключив соответствующий модуль и задав правило, т.к. по умолчанию, UDP и TCP транспорт на сервере отключен.
    *************************************************************
    $ cat /etc/rsyslog.conf
    # /etc/rsyslog.conf Configuration file for rsyslog.
    #
    # For more information see
    # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
    #
    # Default logging rules can be found in /etc/rsyslog.d/50-default.conf

    #################
    #### MODULES ####
    #################
    $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

    # Enable non-kernel facility klog messages
    $KLogPermitNonKernelFacility on

    ###########################
    #### GLOBAL DIRECTIVES ####
    ###########################
    #
    # Use traditional timestamp format.
    # To enable high precision timestamps, comment out the following line.
    #
    $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

    # Filter duplicated messages
    $RepeatedMsgReduction on

    #
    # Set the default permissions for all log files.
    #
    $FileOwner syslog
    $FileGroup adm
    $FileCreateMode 0640
    $DirCreateMode 0755
    $Umask 0022
    $PrivDropToUser syslog
    $PrivDropToGroup syslog

    #
    # Where to place spool and state files
    #
    $WorkDirectory /var/spool/rsyslog

    #
    # Include all config files in /etc/rsyslog.d/
    #
    $IncludeConfig /etc/rsyslog.d/*.conf
    *****************************************************************
    После задания указанных параметров, необходимо перезапустить\перечитать конфигурационный файл
    #service rsyslog restart
    # netstat -nap | grep 514
    При этом, netstat нам должен показать, что сислог стал слушать соответствующие поры.
    # netstat -nap | grep 514
    tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 9121/rsyslogd
    tcp6 0 0 . 514 . * LISTEN 9121/rsyslogd
    udp 0 0 0.0.0.0:514 0.0.0.0:* 9121/rsyslogd
    udp6 0 0 . 514 . * 9121/rsyslogd
    Настройка клиентов syslog

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

    #apt-get install rsyslog-mysql
    При этом, установщик кладет модуль ommysql.so в каталог /usr/lib/rsysloul/spang/ и запускает мастер настройки, который запрашивает пароль администратора MySQL, создает отдельного пользователя и просит указать для него пароль. Создает соответствующую базу из скрипта /usr/share/dbconfig-common/data/rsyslog-mysql/install/mysql. Получившиеся настройки кладет в /etc/rsyslog.d/mysql.conf. В результате получается следующий конфиг:
    ———————————————————
    ### Configuration file for rsyslog-mysql
    ### Changes are preserved

    $ModLoad ommysql
    *.* :ommysql:localhost,Syslog,rsyslog,1

    Syslog в Linux (управление логированием)

    Функция системного журналирования (т.н. «логи» или логирование) — это основной источник информации о работе системы и ошибках. Журналирование может осуществляться на локальной системе, а так же сообщения журналирования могут пересылаться на удаленную систему, кроме того, в конфигурационном файле /etc/syslog.conf (в некоторых новых дистрибутивах заменен на /etc/rsyslog.conf) возможна тонкая регулировка уровня журналирования. Журналирование осуществляется при помощи демона syslogd (rsyslogd — в некоторых новых дистрибутивах), который обычно получает входную информацию при помощи сокета /dev/log (локально) или с udp-порта 514 (с удаленных машин).

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

    Управление типом и подробностью журналируемой информации

    Конфигурационный файл syslog.conf

    Файл syslog.conf является главным конфигурационным файлом для демона syslogd. Конфигурационный файл syslog.conf представляет собой набор правил. Каждое правило есть — строка, состоящая из селектора и действия, разделенных пробелом или табуляцией. Селектор представляет собой запись в виде источник.приоритет. (источник иногда именуют — категорией) Селектор может состоять из нескольких записей источник.приоритет, разделенных символом «;» . Можно указывать несколько источников в одном селекторе (через запятую). Поле действие — устанавливает журналируемое действие для селектора.

    Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то выполняется указанное в правиле действие. Для одного сообщения м.б. выполнено произвольное количество действий (т.е. обработка сообщения не прекращается при первом успехе).

    Сообщения с уровнем, равным или выше указанного в селекторе, и источником, равным указанному в селекторе, считается подходящим. Звездочка перед точкой соответствует любому источнику, после точки — любому уровню. Слово none после точки — никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую).

    Источник (он же категория) может быть следующим:


    • 0 — kern — Сообщения ядра
    • 1 — user — Сообщения пользовательских программ
    • 2 — mail — Сообщения от почтовой системы.
    • 3 — daemon — Сообщения от тех системных демонов, которые в отличие от FTP или LPR не имеют выделенных специально для них категорий.
    • 4 — auth — Все что связано с авторизацией пользователей, вроде login и su (безопасность/права доступа)
    • 5 — syslog — Система протоколирования может протоколировать сообщения от самой себя.
    • 6 — lpr — Сообщения от системы печати.
    • 7 — news — Сообщения от сервера новостей. (в настоящее время не используется)
    • 8 — uucp — Сообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она вам никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP).
    • 9 — cron — Сообщения от системного планировщика.
    • 10 — authpriv — То же самое, что и auth, однако сообщения этой категории записываются в файл, который могут читать лишь некоторые пользователи (возможно, эта категория выделена потому, что принадлежащие ей сообщения могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и следовательно файлы протоколов должны иметь соответствующие права доступа).
    • 11 — ftp — При помощи этой категории вы сможете сконфигурировать ваш FTP сервер, что бы он записывал свои действия.
    • 12 — NTP — сообщения сервера времени
    • 13 — log audit
    • 14 — log alert
    • 15 — clock daemon — сообщения демона времени
    • с 16 по 23 local0 — local7 Зарезервированные категории для использования администратором системы. Категория local7 обычно используется для сообщений, генерируемых на этапе загрузки системы.
    • mark (не имеющая цифрового эквивалента) — присваивается отдельным сообщениям, формируемым самим демоном syslogd

    Под приоритет (степени важности) сообщений заданы 8 уровней важности, которые кодируются числами от 0 до 7:

    • 0 — emerg (старое название PANIC) — Чрезвычайная ситуация. Система неработоспособна.
    • 1 — alert — Тревога! Требуется немедленное вмешательство.
    • 2 — crit — Критическая ошибка (критическое состояние).
    • 3 — err (старое название ERROR) — Сообщение об ошибке.
    • 4 — warning (старое название WARN) — Предупреждение.
    • 5 — notice — Информация о каком-то нормальном, но важном событии.
    • 6 — info — Информационное сообщение.
    • 7 — debug — Сообщения, формируемые в процессе отладки.

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

    Обычный файл

    Задается полным путем, начиная со слеша (/). Поставьте перед ним дефис (-), чтобы отменить синхронизацию файла после каждой записи. Это может привести к потере информации, но повысить производительность.

    Размещение перед именем файла символа канала (|) позволит использовать fifo (first in — first out, первый пришел — первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.

    Терминал и консоль

    Терминал, такой как /dev/console.

    Удаленная машина

    Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp, и открыт UTP-порт 514)

    Список пользователей

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

    Все зарегистрированные пользователи

    Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).

    Пример несложного syslog.conf:

    Как и во многих конфигурационных файлах, синтаксис следующий:

    • Строки, начинающиеся с #, и пустые строки игнорируются.
    • Символ * может использоваться для указания всех категорий или всех приоритетов.
    • Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
    • Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.

    В синтаксисе конфигурационного файла можно поставить перед приоритетом знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Подобным образом, перед приоритетом можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

    Запуск демона syslogd

    Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).

    Вот некоторые возможные параметры запуска демона syslogd:

    • -a /folder/socket — указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
    • -d — отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
    • -fимя-конфигурационного-файла. Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
    • -l список-хостов — задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN — Full Qwalified Domain Name);
    • -m минут — запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
    • -p socket — задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
    • -r — разрешение принимать сообщения от удаленных хостов;
    • -x — запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
    • -v — показать версию и закончить работу

    После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

    С помощью команды
    kill -SIGNAL `cat /var/run/syslogd.pid`

    можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.

    Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd. Оба демона входят в состав пакета sysklogd.

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

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

    Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

    Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

    Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

    Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

    В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.

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

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

    В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

    Параметры, задаваемые в конфигурационном файле logrotate.conf:

    • compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
    • compresscmd (задает программу сжатия, по умолчанию — gzip)
    • uncompresscmd (задает программу разжатия, по умолчанию — ungzip)
    • compressext (задает суффикс для сжатых файлов)
    • compressoptions (задает параметры программы сжатия; по умолчанию — «-9», т.е. максимальное сжатие для gzip)
    • copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
    • create [права-доступа владелец группа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами — права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
    • daily (смена версий в серии происходит ежедневно)
    • delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
    • errorsemail (кому направлять сообщения об ошибках)
    • extensionсуффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
    • ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
    • includeимя-файла | имя-директории (текстуально подставить файл или все файлы из указанной директории; не включаются поддиректории, специальные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
    • mailадрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
    • mailfirst (посылать не удаляемую версию журнала, а первую)
    • maillast (посылать удаляемую версию журнала; действует по умолчанию)
    • missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
    • monthly (смена версий происходит ежемесячно)
    • olddirдиректория | noolddir (во время смены версий журнал перемещается в указанную директорию; д.б. на том же физическом устройстве)
    • postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии)
    • prerotate (все дальнейшие строчки до строки endscript исполняются перед процессом смены версии)
    • rotateчисло (сколько старых версий хранить; если 0, то ни одной)
    • sizeбайт (смена версии происходит, если размер журнала превысил указанное число; можно использовать суффиксы «k» — килобайт — и «M» — мегабайт)
    • sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
    • tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак «плюс», то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, «,v», .swp и «

    »)

  • weekly (смена версий происходит еженедельно)

  • Изучение и мониторинг журналов

    Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less, искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep:

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

    Далее в файле протокола можно обнаружить версию ядра, параметры его запуска, информацию о типе процессора и объеме ОЗУ:

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

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

    Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл /var/log/dmesg, который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы /var/log/lastlog, /var/log/wtmp, /var/log/btmp, имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

    На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

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

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

    Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет — сообщения будут удаляться (или записываться в чужой журнал).

    Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP.

    Подведем небольшой итог:

    В линукс есть единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP — 514, а так же от «помощника» — демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном syslogd через правила в файле /etc/syslog.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически «обрезаются». Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком — cron.

    На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

    Команда syslog в коде C

    Вышеупомянутая команда syslog не регистрируется в syslog. Поэтому я попробовал,

    Это не позволяет ничего регистрировать, и я получаю следующую ошибку:

    Эта строка неверна:

    «» должно быть целым числом:

    Целое число должно быть любой из этих констант ORed вместе:

    Попробуйте еще раз:

    Обратите внимание, что ваша конфигурация syslogd не может быть настроена для сохранения сообщений уровня журнала LOG_INFO . Попробуйте LOG_ALERT или что-то для отладки этой проблемы — если оно работает, вернитесь к LOG_INFO и настройте syslogd , чтобы сохранить сообщения журнала, которые вы хотите сохранить. Добавление строки, например:

    Русский перевод статьи о использовании syslogd

    По-русски описана настройка syslogd. На сайте есть другие переводы статей взятых на http://www.oreillynet.com/

    Re: Русский перевод статьи о использовании syslogd

    В двух словах, статья понравилась. Кратко и дельно. Советую всем прочитать, кто еще не знает как общаться с syslogd

    Re: Русский перевод статьи о использовании syslogd

    Вопрос професионалам: когда у меня есть лог-сервер на котором крутится syslogd и собираются логи с серверов в локалке, какую строчку мне нужно прописать в конфиге на лог-сервере, чтобы например логи с www-сервера писались в /var/log/www-server и так далее для каждого из серваков? а какую строчку нужно прописать чтобы логи с cisco routera писать в файл /var/log/cisco?

    Заранее спасибо, Владимир Храмков

    Re: Русский перевод статьи о использовании syslogd

    Владимир, обратите внимание на syslog-ng. для сбора логов с нескольки машин — самое то.

    фичи: 1. умеет имена лог-файлов делать сам, согласно шаблону, в который может входить имя хоста, его IP, дата\время. при этом может сам создать директорию, если ему разрешить. например файлы раскидываются так: . / / / .

    2. раскладка в файлы не просто по facility/level, но ещё по match, например (вхождение подстроки в строке сообщения), program (имя программы)

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

    в общем то syslogd наша контора уже не использует. пишите — anton@izh.com

    Re: Русский перевод статьи о использовании syslogd

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

    Re: Русский перевод статьи о использовании syslogd

    Надо ли syslogd говорить чтобы он принимал сообщения от другого сервера? А то вроде прописал все верно а не палит сволочь :(

    Re: Re: Русский перевод статьи о использовании syslogd

    Re: Русский перевод статьи о использовании syslogd

    Спасибо ;) я только что дошел до этого места и теперь все работает на ура

    А если разделить лог файлы для каждого сервака свой, то нужно использовать команду -l ?

    Re: Русский перевод статьи о использовании syslogd

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL