настройка syslog сервера windows

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

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

Источник

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

Visual Syslog Сервер для Windows

После установки Visual Syslog Сервер для Windows сразу готов к работе: настройка не требуется. По умолчанию ожидает сообщений на портах 514 UDP и 514 TCP. Программа установки добавляет исключения брандмауэра для Visual Syslog Сервер.

Компиляция из исходного кода

Для компиляции Syslog Сервера из исходных кодов используйте CodeGear RAD Studio C++Builder 2007
Файл проекта visualsyslog.cbproj
Требуются дополнительные компоненты: Indy.Sockets (VCL) version 10

Для компиляции программы установки используйте Inno Setup Compiler 5.5.1(a)
Файл проекта программы установки visualsyslog.iss

Ваши вопросы и предложения по улучшению программы шлите по адресу

Настройка цветового выделения сообщений

Основные параметры настройки

Настройка файлов для сохранения сообщений и разбивка их на части

Отправка сообщений электронной почты через SMTP сервер

Источник

Настройка syslog-ng для централизованного сбора логов

Мне понадобилось организовать сервер для сбора логов с удаленных устройств. Это могут быть серверы, сетевое оборудование, либо что-то еще, что поддерживает логирование в формате syslog. Я решил использовать не стандартный для большинства дистрибутивов rsyslog, а установить syslog-ng, потому что мне он показался более удобным и простым в настройке.

Введение

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

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

С установкой нет ничего сложного. Установить syslog-ng можно одной командой:

Сразу переходим к настройке. Файл конфигурации располагается по адресу /etc/syslog-ng/syslog-ng.conf. Чтобы сервер начал принимать логи с удаленного устройства, его необходимо прописать в конфиг. Делается это просто. В самый конец конфигурационного файла добавляем информацию о новом устройстве:

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

И так далее. Добавляете столько серверов, сколько нужно. Не забудьте создать папку для логов. В моем примере это папка /var/log/!remote, сами файлы создавать не надо, служба автоматически их создаст, когда придет информация с удаленных серверов.

Запускаем syslog-ng и добавляем в автозагрузку:

Проверим, запустилась ли служба:

Все в порядке, слушает 514 udp порт. Не забудьте открыть этот порт в iptables, если у вас включен фаерволл. Сервер готов к приему логов.

Отправка логов syslog на удаленный сервер

Теперь идем на добавленные в syslog-ng сервера и настраиваем там отправку логов на наш сервер. Сделать это очень просто. Открываем файл конфигурации rsyslog. В CentOS он живет по адресу /etc/rsyslog.conf и добавляем туда строку:

и проверяйте логи на сервере syslog-ng в указанной папке. Правило *.* отправит все логи в указанное направление. Это не всегда нужно, можно отредактировать правила. Для этого надо ознакомиться с документацией по syslog. Там нет ничего сложного, мне не хочется на этом сейчас подробно останавливаться. В интернете есть примеры. Приведу пару своих.

В данном случае у меня по local5.notice идет лог самбы по доступу к сетевой шаре. Мне не нужно собирать эту информацию и я ее отключил. Вот еще пример:

С этого сервера сыпалось много лишней информации уровня debug. Я ограничил отправляемые сообщения уровнем info. И так далее.

Ротация логов syslog-ng

В завершение приведу пример своего правила ротации логов. Рекомендую ротацию настроить сразу, не оставлять на потом. Создаем файл /etc/logrotate.d/syslog-ng

По этому правилу ротация логов происходит раз в день. Старые логи перемещаются в папку /var/log/!remote/old и сжимаются. Хранятся логи за последние 180 дней.

Заключение

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

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

Онлайн курсы по Mikrotik

Помогла статья? Подписывайся на telegram канал автора

Автор Zerox

32 комментария

нет такой команды yum

июл 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»?

Здравствуйте.
Второй день ломаю голову, пробовал на обоих хостах использовать штатный в Ubuntu 20.04 rsyslog, и в качестве сервера syslog-ng. В обоих случаях добился того что на сервер прилетают в один файл часть системных логов с собираемого хоста, но не все, не могу заставить передавать логи nginx и его виртуальных хостов.

В идеале хотел получить следующее:

На хостах 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 stack — https://serveradmin.ru/ustanovka-i-nastroyka-elasticsearch-logstash-kibana-elk-stack/
Я сейчас для сбора логов в основном им пользуюсь.

Читать документацию к каждому из сервисов и смотреть, как настроить отправку логов в syslog формате. Если не ошибаюсь, они все это умеют. Единственное сомнение насчет mysql, не настраивал. А все остальное в syslog отправлял.

Здравствуйте! Спасибо за совет (ответ 🙂 ) настроил отправку логов nginx и apache, как вы уже сказали все они умеют отправить логи на syslog, mysql-а Я не смог настроить. В Интернете больше всего есть статьи по этой теме где syslog тправляет и сохроняет свои логи в mysql 🙂

хорошее описание. Но я бы предпочел более «старый «способ, описанный в http://www.linux-magazin.de/ausgaben/2009/06/zentrale-kontrolle/

Спасибо за материал! Очень интересно и хорошо изложено.
И да, в syslog-ng.conf нужно раскомментировать строку:
#udp(ip(0.0.0.0) port(514));
перед тем как запускать syslog-ng.

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 что-то есть на этот счет? Не понятно, в чем ошибка. Обычно в логе есть информация на эту тему.

Источник

Перенаправление событий Windows (Event Log) на сервер syslog Linux

Вступление

Это статья предназначена для системных администраторов, которые знакомы с Linux и используют семейство этих систем в смешанной среде прекрасно осознавая что разные ОС хороши в разных задачах. Так же она будет интересна всем администраторам, даже тем, кто не знаком с линуксом, своей теоретической частью.

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

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

Описание

Каждый работающий с серверами знает и ежедневно пользуется системой логов на своих машинах и каждый знает как они устроены — syslog на Linux и Event Log на винде.

До эры Windows Server 2008 Event Log был странной системой созданной как-будто не для серверов — каждый компьютер писал и хранил свои события локально и удобных механизмов для передачи их по сети для централизованного просмотра или хотя бы хранения не было вообще. Ну, впрочем, всем это известно. Просмотр логов для серверов напоминал квест в MMORPG — исследуй несколько локаций и собери несколько предметов в каждой. Начиная с Windows Vista был сделан шаг навстречу людям и создана система форварда локальных событий на другие Windows >Vista компьютеры. Это хорошо и прогрессивно и это именно то чего не хватало, но реальность такова что на данный момент осталось и не устарело много серверов с Windows 2003 для которых таких механизмов так и нет или они есть, но отталкивают своей монстроузной реализацией.

С другой стороны существует простая и надежная система syslog для Linux которая изначально разработана для распределённой передачи и приёма логов и содержит в себе всё что для этого необходимо. Она настолько хорошо делает своё дело что возможность отправлять логи по этому протоколу встраивают и в хардварные роутеры и в кучу разных других устройств и вполне реально сделать в сети сервер который будет собирать все логи со всех устройств в сети: серверов, роутеров, коммутаторов, принт-серверов, кофеварок, кулеров, ой что-то я разошелся… Кроме Windows. Врядли найдётся человек которому не приходила в голову мысль что если бы Windows мог отправлять свои логи в syslog это было бы идеальным решением для централизации логохранилища. Как удобно было бы все иметь в одном месте — можно было бы и хранить годами, архивируя текстовые файлы (они отлично ужимаются), и обрабатывать, разбирая один текстовый файл от нескольких серверов вылавливая одно критическое событие сразу для нескольких машин.

Задался таким вопросом и я. Задался я им несколько лет назад и потерпел неприятное фиаско — утилит позволяющих это сделать-то довольно много, но выглядят они все как кошмар профессионального администратора — какие-то ужасные утилиты иногда на C# размеров в 100 мегабайт с тысячей кнопочек и чекбоксов и что самое неприятно — _все платные_. Не знаю в чем прикол, но несколько лет назад Google был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

Добавлю от себя что во-первых вот уже полгода как эта программа на 8-ми моих серверах и 2003 и 2008 просто работает, после установки я _ни разу_ ни на одном из них не проверял, не перезапускал обвалившийся, не ковырял, не изменял и даже не смотрел в сторону этого сервиса, который так же никак не повлиял ни на одно другое приложение, он просто делает своё дело после установки — безустанно шлёт эвенты туда куда ему сказали. А во-вторых что программа очень динамично развивалась не так давно набирая функционал, после чего стабилизировалась и теперь достаточно регулярно, но не слишком часто, выходят билды которые причесывают функционал и фиксят мелкие редковоспроизводимые баги.

Перейдём к ещё большей конкретике.

Настройка

Затем вам наверняка не очень понравится если логи линуксов, роутеров и винды будут смешиваться в одном файле и превращаться в трудновоспринимаемую кашу. Для этого в системе syslog есть несколько разделов (facility) и приходящие на отдельные facility сообщения можно писать в разные файлы. Так как логи от винды не особо подходят ни под kernel, ни под mail, специально для этого в syslog есть несколько “безличных” facility которые называются local. Чтобы вынести например local1 в отдельный файл надо добавить в /etc/syslog.conf строку:

ну и запомнить что это local под номером 1. точно так же можно разделить остальные local от local0 до local7.
Обращаю ваше внимание что это простейшая конфигурация syslog которая позволит просто складывать логи от винды в отдельный файл, тонкая конфигурация syslog позволяет довольно замысловато распределить сообщения приходящие к демону, но всё это описано в мануале к syslog и скорее всего известно любому знакомому с линуксом администратору.
Установка evtsys на Windows.

Параметры evtsys.exe:
-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений
0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт
(0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)

Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%\System32\evtsys.cfg и забить в него события которые вас не интересуют в формате EventSource:EventID. Например строка “Security-Auditing:*” полностью отключит отправку раздела Security на Windows >Vista, строка “Security-Auditing:4624” отключит отправку только события с кодом 4624 (интерактивный доступ из сети к компьютеру, браузинг его кем-то из сети). Грустная ирония такова что при разработке нового Event Log’а для нового поколения серверных ОС Микрософт полностью сменила названия разделов и коды, а так же переписала и стандартные сообщения и вообще все события, так что на поколении Windows 2003 и поколении Windows 2008 названия разделов и номера событий будут кардинально различаться. Впрочем зачастую у них будет одинаковый смысл. Какое событие что значит и какие у них названия и номера удобно узнавать с сайта http://www.eventid.net/.

После чего можно открывать список сервисов Windows и запускать сервис под названием “Eventlog to Syslog” и логи начнут появляться в файле на сервере с syslogd примерно в таком виде:

Заключение

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

Для себя я написал на perl зацикленный парсер идущего лога который из всё-таки не совсем удобочитаемой простыни лога:
а) выкусывает события которые меня не интересуют: например всё те же обращения к компьютеру из сети (любой браузинг в сети одного компа вызывает на всех компах которые он у себя в сетевом окружении увидит сообщение об этом, а это реально большая куча сообщений на серверах, особенно если сразу с нескольких). У меня ушёл всего один день на то чтобы создать список таких “не интересующих меня” событий.
б) подкрашивает события которые меня интересуют и переводит их из технического вида в человеческий, например логин на сервер по RDP окрашивается синим и пишется не полная строка из лога, навроде той что я привёл выше из которой ещё надо понять кто на ком стоял, а в виде “Remote login by ‘xxx’ (ip: x.x.x.x) to ‘XXX’”.

В результате чего я получил консольную утилиту в которой то что меня интересует всегда выделенно, а всё что произошло кроме этого будет написано так что это реально разобрать, понять и быстро отреагировать. Можно просто изредка посматривать на протяжении дня на консоль в которой довольно редко появляется текст, зато если что-то пойдёт — это сразу можно поймать. Например недавно у меня начал подходить к концу пул DHCP, и я сразу узнал об этом увидев в консоли сообщение от DHCP (стоящем на домен контроллере) о том что DHCP-pool is 90% full, а не придя на работу через два-три дня и узнав что кто-то не может попасть в сеть.

Кроме того, утилита позволяет записывать в базу те события которые я хочу хранить и как-то обрабатывать.
Например недавно тут (на хабре) была статья о том как сделать статистику того, кто что распечатал, с дикой чехардой по SNMP. В моем же случае эта незначительная проблема входящая в общую решаемую задачу централизированного логирования, если принтер подключен к серверу и расшарен, и на нём включено логирование того что напечатано, не просто решается, а решается более чем полно. Ведь в логи кроме количества страниц и ip адреса, пишется:

— кто распечатал (логин)
— имя документа

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

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

Источник