Комментарии 23
Добавьте ссылку на сам WinLogCheck. Спасибо.
Такой вопрос. Произошла нештатная ситуация, в расследовании которой могли бы помочь логи с конкретного сервера (цена вопроса может весьма высока). Но они в силу тех или иных причин утеряны. Аппаратный сбой, уничтожены злоумешленником, еще что-то. Почему бы не оттолкнуться от классической схемы syslog-коллектора, на который события сваливаются по сети по мере их возникновения? А там уже хоть перлом, хоть еще чем — парсить, агрегировать, статистику выцеплять любую, рассылать.
Я практиковал такой подход на более полусотни виндовых серверов. И через WAN-каналы в том числе.
Я практиковал такой подход на более полусотни виндовых серверов. И через WAN-каналы в том числе.
НЛО прилетело и опубликовало эту надпись здесь
Даже если изобрести — это хорошая практика по программированию и администрированию. Сам сейчас подумываю про написание своей системы мониторинга.
Речь не об изобретении чего-либо, а о подходе. В данном случае — забирать данные с сервера по расписанию или что бы сервер сам их скидывал в рилтайме по мере возникновения событий. На счет же изобретений — зачастую функционал подобного софта бывает избыточным. Или неоправданно высокие требования к платформе, требования к наличию СУБД, специфических библиотек и прочего. В очень многих случаях все, что людям надо — это просто иметь логи в одном месте и делать из них несложные, но специфичные выборки. На счет же суперспецифичности. Это тоже бывает и чаще, чем можно себе представить. И как ни странно, реализуется не такой уж большой кровью, как может показаться. А вот в каком-нибудь монстриозном продукте, который вроде по заявлениям умеет все и вся, может запросто оказаться, что добиться нужного поведения — проблема. За свою практику сталкивался с этим множество раз. И билинги допиливать приходилось, и мониторинг, и много еще чего. Иногда два десятка строк на перле — то что доктор прописал, чем рыться в монстриозном проекте, да еще и безрезультатно зачастую.
Получить копию логов в любом случае? — Это просто другая задача. Для критических сервисов/приложений использовать надо другие решения.
Когда-то я рассматривал один из вариантов по консолидации логов, но система просмотра и фильтрации не понравилась. Кроме того, такие системы требуют специально предназначенный для этого сервер.
Когда-то я рассматривал один из вариантов по консолидации логов, но система просмотра и фильтрации не понравилась. Кроме того, такие системы требуют специально предназначенный для этого сервер.
Любой более менее серьезный сервис требует выделенного либо физического либо виртуального сервера — хоть то БД, хоть то мониторинг, хоть то аналитика логов. мало того, некоторые из них требуют серверные OS.
Ну то, что сервер нужен — это понятно. Вы тут упоминали сбор с десятка систем, странно, что при десятке серверов нельзя поднять хоть на чем-то сислог-сервер (не обязательно на никсах). На счет критичности — да как бы при определенном подходе к администрированию для любых серверных систем их (логи) хочется иметь в любом случае и в одном месте. Тем более, что это до крайности просто.
Наверное, нужно дать развернутый ответ.
Исторически сложилось так, что запросить деньги на централизованный софт по сбору/анализу/отчету для EventLog невозможно (и причина не том, что денег нет). Среди просмотренных бесплатных систем за эти годы ничего путного не нашлось. Хотя я уже пару лет ничего не искал — может что-нибудь появилось.
Централизованный коллектор логов тоже есть. Пусть это будет Syslog-сервер (но это неважно)
— Отчеты на e-mail у меня будут? — Нет.
Можно было бы написать систему отчетов для Syslog или воспользоваться готовыми (например, тем же logcheck). Но мое-то решение может работать и без наличия Syslog-сервера.
Т.е. моим решением может воспользоваться:
и администратор одного-двух серверов в небольшой компании, которому совершенно не нужен централизованный сбор логов;
и администратор нескольких серверов, который использует для централизованного сбора логов какое-либо простое решение.
Исторически сложилось так, что запросить деньги на централизованный софт по сбору/анализу/отчету для EventLog невозможно (и причина не том, что денег нет). Среди просмотренных бесплатных систем за эти годы ничего путного не нашлось. Хотя я уже пару лет ничего не искал — может что-нибудь появилось.
Централизованный коллектор логов тоже есть. Пусть это будет Syslog-сервер (но это неважно)
— Отчеты на e-mail у меня будут? — Нет.
Можно было бы написать систему отчетов для Syslog или воспользоваться готовыми (например, тем же logcheck). Но мое-то решение может работать и без наличия Syslog-сервера.
Т.е. моим решением может воспользоваться:
и администратор одного-двух серверов в небольшой компании, которому совершенно не нужен централизованный сбор логов;
и администратор нескольких серверов, который использует для централизованного сбора логов какое-либо простое решение.
Начинал писать похожий велосипед на павершеле, но запал кончился. После Вашей статьи, пожалуй, продолжу работу :)
А что писали то?
Возможно, проблема будет в следующем: очень похоже, что подсистемы Windows пишут в eventlog как минимум двумя способами. Поэтому, понятный текст Message для любых сообщений мне удалось получить только с использованием запросов WMI.
При использовании родных классов .NET некоторые виды сообщения выглядели как набор кодов. Вероятно, Powershell использует именно такой способ. Если так — попробуйте C#.
При использовании родных классов .NET некоторые виды сообщения выглядели как набор кодов. Вероятно, Powershell использует именно такой способ. Если так — попробуйте C#.
На самом деле 2008 сервера сами по событию умеют отправлять почту, никто не мешает этим воспользоваться
Смотрите самое начало статьи.
Вопрос в том, как вы определите весь список событий, за которыми нужно следить? Я на этот вопрос ответить не смог.
Поэтому получилось такое решение. Я с ним работаю так:
— ставлю на свежеустановленный сервер, не включая фильтров
— получая каждый день отчет, я добавляю фильтры — вначале общие (входят в комплект программы), потом конкретные для данного сервера
— через несколько дней ко мне начинает приходить отчет, в котором все по нулям, т.е. все сообщения, которые ежедневно появляются в журнале событий — отфильтрованы.
И вот когда спустя какое-то время в отчете программы зафиксировано неопознанное фильтрами событие — это значит, что нужно обратить внимание, даже если событие типа «Info».
Я использую эту утилиту много лет, чаще всего она мне помогала в двух случаях: обнаружение «умирающего» жесткого диска и потеря связи между контроллерами доменов в W2003.
Вопрос в том, как вы определите весь список событий, за которыми нужно следить? Я на этот вопрос ответить не смог.
Поэтому получилось такое решение. Я с ним работаю так:
— ставлю на свежеустановленный сервер, не включая фильтров
— получая каждый день отчет, я добавляю фильтры — вначале общие (входят в комплект программы), потом конкретные для данного сервера
— через несколько дней ко мне начинает приходить отчет, в котором все по нулям, т.е. все сообщения, которые ежедневно появляются в журнале событий — отфильтрованы.
И вот когда спустя какое-то время в отчете программы зафиксировано неопознанное фильтрами событие — это значит, что нужно обратить внимание, даже если событие типа «Info».
Я использую эту утилиту много лет, чаще всего она мне помогала в двух случаях: обнаружение «умирающего» жесткого диска и потеря связи между контроллерами доменов в W2003.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание регулярного отчета по журналу событий Windows