Как отправить syslog сообщение windows
Обновлено: 03.07.2024
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
. либо отключить его командами:
Установка и запуск 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):
Для определенного уровня
Перезапускаем сервис логов:
systemctl restart rsyslog
Возможные уровни логов:
Возможные категории для логов (severity):
Аудит определенного лог-файла
Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.
Настройка клиента
Создаем новый конфигурационный файл:
$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
Создаем новый шаблон для захвата логов:
$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?
Некоторые серверы системного журнала также могут выступать в качестве приемников для ловушки SNMP, которая является еще одним стандартом связи, используемым сетевыми устройствами для отправки предупреждений на сервер. Тем не менее, SNMP ограничен в своем объеме тем, что он будет уведомлять вас только о критических состояниях, в отличие от Syslog, который собирает каждое событие, что делает его более эффективным для более детального мониторинга.
Ограничения стандарта системного журнала
Но этого достаточно. Давайте посмотрим на то, что действительно привело вас сюда. Лучшее программное обеспечение Syslog Server. Как вы можете себе представить, их так много. Поэтому я сделаю вам одолжение и сужу его до пяти лучших.
1. SolarWinds киви Syslog Server бесплатная версия
Сервер системных журналов Kiwi
SolarWinds предлагает различные меры, позволяющие получить доступ к определенным журналам за минимальное время. Например, вы можете открыть несколько экземпляров данных журнала и просматривать их одновременно. Это также позволяет сортировать файлы журнала по времени или уровню приоритета. К сожалению, эта бесплатная версия имеет ограничение в том, что она может поддерживать только 5 устройств.
Поэтому для крупных организаций я бы порекомендовал платную версию, которая включает в себя множество отличных вещей, среди которых веб-консоль, позволяющая удаленно изучать журналы из любой системы. Сервер системного журнала KIWI работает только для операционной системы Windows.
2. WhatsUp Gold Syslog Server
WhatsUp Gold Syslog Server
3. Сервер визуальных системных журналов
Visual Syslog Server
Определенно нет способа пропустить предупреждение с таким количеством доступных опций. Но даже если вы это сделаете, этот сервер может быть настроен на запуск внешних скриптовых программ, действующих от вашего имени в случае предупреждения. Хотя этот сервер работает как приложение, он очень легкий и не занимает слишком много системных ресурсов. Его также можно свернуть в лоток, когда он не используется активно, чтобы не нарушать рабочий процесс. Это все еще продолжит собирать журналы в фоновом режиме.
4. Системный журнал Watcher
После того как сервер соберет журналы, вы можете либо преобразовать их в различные форматы файлов, такие как CSV и XML, либо сохранить их в базе данных с помощью соединителей ODBC. Оказавшись в базе данных, становится очень легко управлять данными, особенно с помощью различных механизмов поиска и сортировки, разрешенных сервером. Сервер также включает уведомления по электронной почте, чтобы предупредить вас в случае важного события.
5. Сервер системного журнала Dude
Dude Syslog Server
Хламник, записная книжка и незабывайка в одном html-е.
29 апр. 2013 г.
Сбор логов на windows-сервере. Часть 1 - syslogd for windows.
Логи - это важно. Если устройств много, в целях удобства и резервного копирования хорошим решением является создание некоего log-сервера, на который серверы и оборудование будут свои логи по сети пересылать.
Syslog for windows - это форк классического unix-демона syslog. Собранный для работы в Windows, умеет регистрироваться и работать как системная служба (конечно, возможен и "ручной" запуск). Также имеется возможность работы в режиме "multi-instance" - регистрируются несколько служб с уникальными названиями. Документация по настройке довольно куцая, однако ее вполне достаточно для написания собственного конфиг-файла, ибо софт написан под выполнение конкретной задачи сбора и хранения логов и умеет только это. Но умеет хорошо.
Для тех, кто знаком с внешниим видом юниксового syslog.conf, многое покажется знакомым - разница лишь в том, что все они пишутся в xml-"обертке". Логика файла проста - в простейшем случае должны быть описаны три сущности: источник (source), назначение (destination) и путь (logpath). У каждой из сущностей есть свой набор настроек, с помощью которых задается их поведение.
В итоге может получиться такой кофигурационный файл:
Пара пояснений по ходу. С таким конфиг-файлом мы можем запустить две службы syslogd:
одна из них зарегистрируется как syslogd_cisco и будет слушать 514/udp, другая - как syslogd_linux на порту 515/udp.
Прямо в описании destination можно задать и опции ротации - с какой периодичностью и глубиной хранить историю (filename переименовывается в filename.1 и так далее до величины backlogs).
Практическая эксплуатация показала надежность этого решения - службы работают стабильно, друг дружке не мешают, никаких подвисаний себе не позволяют. Однако стоит помнить, что при наличии проблем в сети, связанных как с загруженностью каналов, настройкой коммутаторов или с иными причинами, данные могут быть не доставлены - протокол udp не гарантирует доставку пакетов.
Мне понадобилось организовать сервер для сбора логов с удаленных устройств. Это могут быть серверы, сетевое оборудование, либо что-то еще, что поддерживает логирование в формате syslog. Я решил использовать не стандартный для большинства дистрибутивов rsyslog, а установить syslog-ng, потому что мне он показался более удобным и простым в настройке.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
Информации на тему сбора логов с удаленных серверов и интернете достаточно много. Ничего сложного тут нет, я и сам уже описывал подобную настройку в статье про сбор логов с mikrotik. Но решение получилось кривоватое, в комментариях написаны замечания. Я и сам знал о них, но простого и быстрого решения я не смог найти, на тот момент меня устраивал и такой вариант. Сейчас же решил все сделать аккуратно и красиво, чтобы было удобно пользоваться. В процессе поиска информации в интернете решил попробовать syslog-ng. С ним у меня не возникло никаких затруднений, сразу получилось то, что требовалось, поэтому я остановил свой выбор на нем.
Настраивать сервер сбора логов будем на системе CentOS 7. Если у вас еще не подготовлен сервер, то читайте мою информацию по установке и базовой настройке centos. Для небольшого количества устройств, нагрузка на сервер будет незначительная, поэтому имеет смысл размещать сервер на виртуальной машине. Если у вас нет готового гипервизора, можете посмотреть мою информацию на тему настройки linux гипервизора proxmox или бесплатного решения microsoft - Windows Hyper-V Server 2016.
Установка и настройка syslog-ng
С установкой нет ничего сложного. Установить syslog-ng можно одной командой:
Сразу переходим к настройке. Файл конфигурации располагается по адресу /etc/syslog-ng/syslog-ng.conf. Чтобы сервер начал принимать логи с удаленного устройства, его необходимо прописать в конфиг. Делается это просто. В самый конец конфигурационного файла добавляем информацию о новом устройстве:
| d_xs-zabbix | Название назначения для записи лога по адресу /var/log/!remote/xs-zabbix.log |
| f_xs-zabbix | Название фильтра по адресу сервера источника. |
| 10.1.3.29 | Адрес сервера источника логов |
Соответственно для второго сервера нужно добавить еще 3 строки, например так:
И так далее. Добавляете столько серверов, сколько нужно. Не забудьте создать папку для логов. В моем примере это папка /var/log/!remote, сами файлы создавать не надо, служба автоматически их создаст, когда придет информация с удаленных серверов.
Запускаем syslog-ng и добавляем в автозагрузку:
Проверим, запустилась ли служба:
Все в порядке, слушает 514 udp порт. Не забудьте открыть этот порт в iptables, если у вас включен фаерволл. Сервер готов к приему логов.
Отправка логов syslog на удаленный сервер
Теперь идем на добавленные в syslog-ng сервера и настраиваем там отправку логов на наш сервер. Сделать это очень просто. Открываем файл конфигурации rsyslog. В CentOS он живет по адресу /etc/rsyslog.conf и добавляем туда строку:
10.1.3.22 - ip адрес syslog-ng сервера. Перезапустите rsyslog:
и проверяйте логи на сервере syslog-ng в указанной папке. Правило *.* отправит все логи в указанное направление. Это не всегда нужно, можно отредактировать правила. Для этого надо ознакомиться с документацией по syslog. Там нет ничего сложного, мне не хочется на этом сейчас подробно останавливаться. В интернете есть примеры. Приведу пару своих.
В данном случае у меня по local5.notice идет лог самбы по доступу к сетевой шаре. Мне не нужно собирать эту информацию и я ее отключил. Вот еще пример:
Ротация логов syslog-ng
В завершение приведу пример своего правила ротации логов. Рекомендую ротацию настроить сразу, не оставлять на потом. Создаем файл /etc/logrotate.d/syslog-ng
По этому правилу ротация логов происходит раз в день. Старые логи перемещаются в папку /var/log/!remote/old и сжимаются. Хранятся логи за последние 180 дней.
Заключение
Я привел частный случай настройки хранения логов с удаленных устройств. Решение в лоб. В простых случаях этого достаточно. Лично мне удобно смотреть информацию в текстовых файлах. Это требуется редко, сделано на всякий случай для расследования инцидентов, если таковые возникают. Эту же задачу, к примеру, можно решить с помощью заббикс. Я уже показывал, как мониторить с помощью zabbix лог файлы. Приведенное решение легко переделать в хранение логов.
Для более удобного сбора и последующего просмотра информации существуют готовые решения с написанными веб панелями. Я посмотрел на некоторые из них. Что-то мне показалось слишком сложным в настройке, где-то веб интерфейс не понравился. Для себя остановился на приведенном варианте.
Онлайн курс "DevOps практики и инструменты"
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по .Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.Автор Zerox
32 комментария
нет такой команды yum
как только добавляю 3 строки в conf файл, то сервис не стартует.
что я делаю не так ?
● syslog-ng.service - System Logger Daemon
Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit) since Ср 2020-07-29 16:48:53 MSK; 3s ago
Docs: man:syslog-ng(8)
Process: 1989 ExecStart=/usr/sbin/syslog-ng -F -p /var/run/syslogd.pid (code=exited, status=2)
Main PID: 1989 (code=exited, status=2)
Status: "Starting up. (Wed Jul 29 16:48:52 2020"
июл 29 16:48:52 syslog.iceberry.local systemd[1]: syslog-ng.service failed.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: syslog-ng.service holdoff time over, scheduling restart.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: Stopped System Logger Daemon.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: start request repeated too quickly for syslog-ng.service
июл 29 16:48:53 syslog.iceberry.local systemd[1]: Failed to start System Logger Daemon.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: Unit syslog-ng.service entered failed state.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: syslog-ng.service failed.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: start request repeated too quickly for syslog-ng.service
июл 29 16:48:53 syslog.iceberry.local systemd[1]: Failed to start System Logger Daemon.
июл 29 16:48:53 syslog.iceberry.local systemd[1]: syslog-ng.service failed.
как только удаляю эти строки, то все ровно стартует, но логов же я не увижу, правильно ?
подскажите пожалуйста.
строки, которые добавляю: (хочу писать лог контроллера unifi)
А что у вас прописано в директиве source для "net"?
Я не вижу такого. Имеете ввиду что слушать ? там стоит 0.0.0.0 port 514
Здравствуйте.
Второй день ломаю голову, пробовал на обоих хостах использовать штатный в Ubuntu 20.04 rsyslog, и в качестве сервера syslog-ng. В обоих случаях добился того что на сервер прилетают в один файл часть системных логов с собираемого хоста, но не все, не могу заставить передавать логи nginx и его виртуальных хостов.
В идеале хотел получить следующее:
Есть хост сервер логов - host1.
Есть хост с которого хочу получать логи - host2.
Есть хост с которого хочу получать логи - host3.
На хостах host2 и host3 крутятся сервисы на nginx. Как заставить прилетать с этих хостов определённые логи, пути к которым известны, на сервер логов host1. Допустим на host2 и host3 крутится Joomla и нужные мне логи лежит по пути:
/var/log/nginx/access.log
/var/log/nginx/joomla_access.log
/var/log/nginx/joomla_access.log.1
/var/log/nginx/joomla_error.log
/var/log/nginx/joomla_error.log.1
Именно их, в таком виде, хочу получать на сервере логов Host1 по пути /var/log/rsyslog/:
nginx_access.log
nginx_joomla_access.log
nginx_joomla_access.log.1
nginx_joomla_error.log
nginx_joomla_error.log.1
В целом не важно что сам Nginx умеет сам передавать свои логи на удалённый syslog сервер, хотелось бы передавать логи один к одному, тех сервисов которые не умеют напрямую передавать логи на удаленный syslog сервер. Возможно ли указывать какой именно лог файл, указав точный путь на удалённом хосте, и передавать его в определённую папку на syslog сервер в определённый файл? Если всё это возможно, киньте пример что скофигурить на сервере и что на хосте. Смысл в том что бы смотреть логи на одной машине в том виде, в котором они формируются на удалённых хостах, один к одному.
Здравствуйте.
Была бы очень полезна статья как все это потом прикрутить к заббиксу. Спасибо
Что именно вы хотите увидеть в заббиксе? Возможно, у меня есть статьи на эту тему.
Я бы хотел заббиксом собирать эти логи и видеть их в заббиксе
Плохая идея. Zabbix не предназначен для хранения логов. Он все же система мониторинга. Если надо хранить логи, лучше использовать ELK или какие-то другие решения под это дело.
А мне интересно, а где определение source (net)? И все повторяют, и у всех все получается. )))))))))))))))))))))))))
Добрый день. Есть ли какой нибудь относительно простой способ добавить веб-гуи к syslog-ng, с авторизацией? Чтобы можно было зайти из любого места и посмотреть логи.
Добрый день, подскажите пожалуйста, как правильней всего настроить в ELK приём логов по syslog ?
Читать документацию к каждому из сервисов и смотреть, как настроить отправку логов в syslog формате. Если не ошибаюсь, они все это умеют. Единственное сомнение насчет mysql, не настраивал. А все остальное в syslog отправлял.
Feb 15 17:58:27 log.local systemd[1]: Unit syslog-ng.service entered failed state.
Feb 15 17:58:27 log.local systemd[1]: syslog-ng.service failed.
Feb 15 17:58:27 log.local systemd[1]: syslog-ng.service holdoff time over, scheduling restart.
Feb 15 17:58:27 log.local systemd[1]: start request repeated too quickly for syslog-ng.service
Feb 15 17:58:27 log.local systemd[1]: Failed to start System Logger Daemon.
Feb 15 17:58:27 log.local systemd[1]: Unit syslog-ng.service entered failed state.
Feb 15 17:58:27 log.local systemd[1]: syslog-ng.service failed.
Feb 15 17:58:27 log.local systemd[1]: start request repeated too quickly for syslog-ng.service
Feb 15 17:58:27 log.local systemd[1]: Failed to start System Logger Daemon.
Feb 15 17:58:27 log.local systemd[1]: syslog-ng.service failed.
А в /var/log/messages что-то есть на этот счет? Не понятно, в чем ошибка. Обычно в логе есть информация на эту тему.
Читайте также: