Назад | Перейти на главную страницу

Централизованное ведение журнала - хорошая идея?

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

Является ли централизация всех журналов на конкретном компьютере (с помощью rsyslog или чего-то подобного) хорошей идеей? Разве я не променяю простоту на суетливость? Существуют ли хорошие средства просмотра журналов для такого большого объема использования?

Между прочим, мы настоящий магазин Microsoft.

Спасибо за любые ответы!

Одно БОЛЬШОЕ преимущество централизованного ведения журнала заключается в следующем:

  • Если одна из ваших машин будет взломана, и журналы изменены, чтобы скрыть этот факт, у вас по-прежнему будет сохраненная копия на центральном сервере регистрации.

Другой:

  • В моем случае у меня также есть специальный монитор на моей рабочей станции, работающий с центральным сервером журналов, который отображает все журналы с приоритетом «Предупреждение» или выше в реальном времени, так что я могу решать любые проблемы сразу же по мере их возникновения. (надеюсь, до того, как конечный пользователь заметит :)). Без централизованного сервера это сделать сложно.

Я бы посоветовал вам взглянуть на Splunk.

В настоящее время он у меня в производстве, с 30+ сетевыми устройствами, ведущими на него журналы - действительно полезно иметь журналы в одном месте, для которых я могу писать свои собственные запросы, запускать стандартные отчеты и т.

Взгляните также на eventsentry, не очень дорого для нескольких лицензий, можно настроить хорошие фильтры, предупреждения и т. Д.

Централизованное ведение журнала - всегда хорошая идея, если ваш сервер журнала находится в безопасном месте.

Вы смотрели Splunk и / или Spiceworks?

www.splunk.com www.spiceworks.com

Наши журналы безопасности AD DC обрабатывают от 3 до 5 ГБ журналов в день в часы пик, и на Земле просто невозможно что-либо сделать с ними с помощью собственных инструментов. Чтобы разобраться в них, нужен какой-то лог-парсер. Я написал его с нуля в PowerShell, а недавно мы посмотрели на Splunk. Splunk может не отставать от наводнения, а также не отставать от данных системного журнала сетевых устройств (почти такой же большой объем). Все в одной базе данных. Чтобы справиться с такой загрузкой данных, потребуется мощный сервер, но это решаемая проблема. В настоящее время мы ждем завершения правильных Темных обрядов, чтобы мы могли получить финансирование для централизованной среды ведения журнала.

Наличие «единого окна» для обзора данных - это хорошо. Чего вы не получите, так это обновленного текстового файла, который затем можно будет отслеживать в стиле системного журнала. Вы получите интерфейс с богатой системой запросов и (я верю) API для написания собственных веб-интерфейсов для ваших собственных гнусных нужд.

Когда дело доходит до данных журнала событий Windows, Splunk не извлекает XML-версию этих событий, он извлекает текстовую версию «подробного просмотра» каждого события и анализирует ее. У меня были некоторые серьезные опасения по поводу масштаба, но я был приятно удивлен, когда, несмотря на это, он смог выдержать нашу нагрузку на лесозаготовки; Мне пришлось использовать XML с моим сценарием PowerShell, потому что анализ текста занимал слишком много времени.