Централизованный Event Log в Windows 2008 Server
Мне очень понравилась новая возможность по работе с журналами событий в Windows 2008/7/Vista, называемая Event Log forwarding (subscription — или подписка), которая основана на технологии WinRM. Данная функция позволяет вам получить все события со всех журналов с множества серверов без использования сторонних продуктов и настраивается все это в течении всего пары минут. Возможно, именно эта технология позволит вам отказаться от столь любимых многими системными администраторами Kiwi Syslog Viewer и Splunk.
Итак схема такая, у нас есть сервер Windows 2008, запущенный в качестве коллектора логов с одного или нескольких источников. В качестве подготовительной работы нужно выполнить следующие 3 шага:
На коллекторе логов в командной строке с правами администратора запустите следующую команду, которая запустит службу Windows Event Collector Service, измените тип ее запуска в автоматический (Automatically — Delayed Start) и включите канал ForwardedEvents, если он был отключен.
wecutil qc
На каждом из источников нужно активировать WinRM:
winrm quickconfig
По умолчанию сервер-коллектор логов не может просто собирать информацию из журналов событий источников, вам придется добавить учетную запись компьютера-коллектора в локальные администраторы на все сервера-источники логов (в том случае, если сервер-источник работает под управлением 2008 R2, то достаточно добавить учетку коллектора в группу Event Log Readers)
Теперь мы должны создать подписки (Subscriptions) на сервер коллектор. Для чего зайдите на него, откройте консоль MMC Event Viewer, щелкните правой кнопкой мыши по Subscriptions и выберите Create Subscription:
Здесь вы можете выбрать несколько различных настроек.
При каждом добавлении коллектора, неплохо было бы проверить подключение:
Далее вы должны настроить фильтр, указав какие типы событий вы хотите получать (например, Errors и Warnings), также можно собирать события по конкретным номерам Event ID или по словам в описании события. Есть один нюанс: не выбирайте слишком много типов событий в одну подписку, анализировать этот журнал можно будет бесконечно :).
Расширенные настройки (Advanced settings) могут понадобиться, если вы хотите использовать нестандартный порт для WinRM, или захотите работать по протоколу HTTPS, или же оптимизировать сьор логов по медленным каналам WAN.
После нажатия OK подписка будет создана. Здесь вы можете щелкнуть правой кнопкой мыши по подписке и получить статус выполнения (Runtime Status), или перезапустить ее (Retry) если предыдущий запуск был неудачным. Обратите внимание, что даже если ваша подписка имеет зеленый значок, в процедуре сбора логов могут быть ошибки. Поэтому всегда проверяйте Runtime Status.
После начала работы подписки, вы сможете просматривать перенаправленные события. Имейте в виду, что если журналы очень большие, то их первичный сбор может занять некоторое время.
Конфигурацию можно посмотреть на вкладке Properties -> Subscriptions.
В том случае, если сбор логов не работает, сначала на сервере-источнике логов удостоверьтесь, что локальный файрвол настроен корректно и разрешает трафик WinRM.
Один раз, когда я добавил учетную запись сервера-коллектора в группу Event Log Readers, но не добавил ее локальные админы, была такая ошибка;
[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:46:22. Code (0×5): Windows Event Forward Plugin failed to read events. Next retry time: 2010-09-28 16:51:22.Я попробовал добавить учетку сервера в группу локальных админов, в результате появилась такая ошибка:
[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time: 2010-09-28 16:48:18.Оказывается, я выбрал в фильтре слишком много журналов для сбора. Поправив фильтры так, чтобы они собирали чуть меньше информации, я победил эту ошибку.
Information Security Squad
stay tune stay secure
10 сборщиков логов с открытым исходным кодом для централизованного ведения журнала
Точно так же как безопасность, регистрация системных сообщений – другой ключевой компонент веб-приложений (или приложений в целом), который отодвигается на второй план из-за старых привычек и неспособности видеть впереди.
То, что многие считают бесполезными набросками цифровой ленты, – это мощные инструменты, позволяющие заглянуть в ваши приложения, исправить ошибки, улучшить слабые места и порадовать клиентов.
Прежде чем мы перейдем к централизованному ведению журналов, давайте сначала рассмотрим, почему ведение журналов ( логирование ) так важно.
Два типа (уровня) регистрации сообщений журналов
Компьютеры являются детерминированными системами, кроме случаев, когда это не так.
Как безопасник, я сталкивался со многими случаями, когда наблюдаемое поведение приложения ставило всех в тупик целыми днями, но ключ к разгадке всегда был в журналах.
Каждое программное обеспечение, которое мы запускаем, производит (или, по крайней мере, должно генерировать) журналы, которые сообщают нам, через что они проходили, когда возникала проблемная ситуация.
Теперь, как мне кажется, ведение журнала бывает двух типов: автоматически сгенерированные журналы и сгенерированные программистом журналы.
Обращаем ваше внимание, что этих различий и классификации нету в учебниках, и цитирование меня по этой терминологии доставит вам неприятности. ?
Изображение выше показывает то, что можно назвать автоматически сгенерированным журналом.
В данном конкретном случае это система WordPress, регистрирующая непредвиденное состояние (уведомление) при запуске некоторого кода PHP.
Журналы, подобные этим, создаются постоянно – с помощью инструментов баз данных, таких как MySQL, веб-серверов, таких как Apache, языков программирования и сред, мобильных устройств и даже операционных систем.
Они редко содержат большую ценность, и программисты даже не удосуживаются их изучить, кроме случаев, когда что-то идет не так.
В такие моменты они копаются глубоко в коде, пытаясь понять, что пошло не так.
Но автоматически сгенерированные журналы могут помочь только так сильно.
Если несколько человек имеют доступ администратора к сайту, например, и один из них удаляет важную часть информации, невозможно обнаружить виновника с помощью автоматически сгенерированных журналов.
С точки зрения систем, связанных как приложение, это был просто еще один день в работе – кто-то имел необходимые полномочия для выполнения задачи, и поэтому система выполнила ее.
Здесь нужен дополнительный уровень явной, обширной регистрации, которая создает следы для человеческой стороны вещей.
Это то, что я называю созданными программистом журналами, и они составляют основу чувствительных отраслей, таких как банковское дело.
Вот пример того, как может выглядеть такая схема регистрации:
Логгирование это сила
Итак, с учетом этих двух типов журналов в системе, вот как вы можете использовать их и усилить воздействие.
Боевой дух и продуктивность команды
Как я уже говорил, когда ошибки долго не отслеживаются, разработчики в вашей команде разочаровываются и теряют все больше и больше времени, закрывая свои хвосты.
И вот в чем дело с отладкой – она требует свежего, любопытного ума с самого начала.
И что затрудняет отладку?
По моему опыту, отсутствие ведения журнала или отсутствие знаний о ведении журнала.
Для начала вы можете не осознавать, что ваша любимая база данных – это просто еще одна часть программного обеспечения, которая генерирует журналы, или вы не будете интенсивно регистрировать события в своем приложении (см. Журналы, сгенерированные программистом выше).
Я особенно помню случай, когда приложение перестало отвечать на запросы, и никто не знал, почему.
Несколько дней спустя виновником стало ограничение дискового ввода-вывода из-за чрезмерного трафика.
Потому что никто не удосужился посмотреть журналы,и никто не мог понять, почему система упала.
Если вы регулярно посещаете журнал медленных запросов, вы узнаете, какие операции занимают больше всего времени, и, следовательно, обнаружите небольшие, но важные области, требующие работы.
Часто такие небольшие изменения работают лучше, чем удвоение емкости оборудования.
Невозможно сосчитать, сколько способов решения проблем подарит вам хорошая система журналов.
Возможно, лучшим аргументом является то, что это автоматическое действие, которое когда-то настроено, не нуждается в каком-либо мониторинге и однажды спасет вас от разорения.
В связи с этим давайте рассмотрим некоторые из удивительных сборщиков журналов с открытым исходным кодом (унифицированных инструментов ведения журналов).
1 Graylog
2 Logstash
Если вы являетесь поклонником или пользователем стека Elastic, стоит попробовать Logstash (стек ELK )
Как и другие инструменты ведения журнала в этом списке, у Logstash,полностью открытый исходный код, дает вам свободу развертывания и использования по своему усмотрению.
Но не вводите себя в заблуждение: Logstash – это иснтрумент, возможности которого намного превосходят любые скромные средства ведения журналов.
Он способен собирать огромные объемы данных с разных платформ, позволяет определять и выполнять собственные конвейеры данных, понимать неструктурированные дампы журналов и многое другое.
Конечно, единственным ограничением является то, что он работает только с набором продуктов Elastic, но если вы скоро начнете и хотите масштабироваться, Logstash – это то, что вам нужно!
3 Fluentd
Среди централизованных инструментов ведения журналов, которые выполняют роль промежуточного уровня для приема данных, Flutend является первым среди равных.
Обладая превосходной библиотекой плагинов, Fluentd может собирать данные практически из любой производственной системы, перемешивать их в нужной структуре, создавать собственный конвейер и передавать его на свою любимую аналитическую платформу, будь то MongoDB или Elasticsearch.
Fluentd построен на Ruby, является продуктом с полностью открытым исходным кодом и пользуется большой популярностью благодаря своей гибкости и модульности.
С такими крупными компаниями, как Microsoft, Atlassian и Twilio, использующим эту платформу, Fluentd нечего доказывать. ?
4 Flume
Если на самом деле вам нужны действительно большие наборы данных, и вы в конечном итоге захотите объединить все в нечто вроде Hadoop, Flume – один из лучших вариантов.
Это «чистый» проект с открытым исходным кодом, в том смысле, что он поддерживается нашим любимым Apache Foundation, что означает отсутствие корпоративного плана.
Это может быть то, что вы точно ищете. ?
Написанный на Java (который продолжает удивлять меня, когда дело доходит до революционных технологий), исходный код Flume полностью открыт.
Flume лучше всего подойдет вам, если вы ищете распределенную отказоустойчивую платформу для загрузки данных для работы в тяжелых условиях.
5 Octopussy
Я даю ноль из десяти наименованию продукта, но Octopussy может быть хорошим выбором, если ваши потребности просты, и вы задаетесь вопросом о том, что же такое суета, связанная с конвейерами, приемом, агрегацией и т. д
По моему мнению, Octopussy покрывает потребности большинства продуктов (оценочная статистика бесполезна, но, если бы мне пришлось угадывать, я бы сказал, что в реальном мире она учитывает 80% случаев использования)
У Octopussy нет отличного пользовательского интерфейса:
но он компенсирует скорость и отсутствие раздувания.
Исходный код доступен на GitHub, как и ожидалось, и я думаю, что он заслуживает серьезного изучения.
6 LOGalyze
LOGalyze был коммерческим продуктом, который недавно стал инструментом с открытым исходным кодом.
Хотя я не смог реализовать проект на GitHub, они сделали установщик Windows и весь исходный код загружаемым.
Если вы намерены участвовать в сообществе, вы можете найти подробную информацию о списке рассылки здесь.
LOGalyze – это относительно гибкое и мощное предложение, которое отлично подойдет для развертываний в одной системе, которые стремятся объединить ведение журналов из известных источников, таких как Postfix, Apache и т. д. и выводить их в форматах CSV, PDF, HTML или аналогичных.
Да, он не делает все, но поскольку это был коммерческий продукт в свое время, он делает это довольно хорошо.
7 LogPacker
Когда дело доходит до выбора инструмента для работы, у меня есть два критерия: он должен быть целенаправленным и опираться на активную бизнес-модель.
Проблема программного обеспечения с открытым исходным кодом, как правило, заключается в том, что через несколько месяцев / лет вероятность застоя или выхода из строя высока.
Там нет подсчета того, сколько инструментов ведения журнала было запущено,а только можно найти количество на кладбище GitHub.
По этому критерию LogPacker – мой любимый.
8 Logwatch
Я уверен, что среди нас есть те, кто не хочет, чтобы вся церемония была связана с «единой», «централизованной» системой ведения журналов.
Их бизнес базируется на отдельных серверах, и они ищут что-то быстрое и эффективное для просмотра своих файлов журналов.
Ну тогда, скажи привет Logwatch.
После установки LogWatch может сканировать системные журналы и создавать отчеты нужного вам типа.
Это несколько устаревшее программное обеспечение (читай «надежное»), хотя оно было написано на Perl.
Итак, вам понадобится Perl 5.6+ на вашем сервере для его запуска.
У меня нет скриншотов, которыми можно поделиться, потому что это чисто командная строка, демонизированный процесс.
Если вы наркоман CLI и любите стиль старой школы, вам понравится Logwatch!
9 Syslog-ng
Инструмент Syslog-ng был разработан как способ обработки файлов системного журнала (установленный протокол клиент-сервер для регистрации в системе) в режиме реального времени.
Однако со временем он стал поддерживать другие форматы данных: неструктурированные, SQL и NoSQL.
Как работает протокол системного журнала, довольно четко подытожено на следующем рисунке.
syslog-ng – это надежный инструмент для сбора и классификации журналов промышленного уровня, написанный на языке Си и давно известный в отрасли.
Лучшая часть – это расширяемость, позволяющая вам писать плагины на C, Python, Java, Lua или Perl.
10 Inav
От глупой командной строки, не требующих настройки инструментов до полномасштабной обработки данных – все это здесь!
Я что-то пропустил? Конечно, я сделал это!
Пожалуйста, дайте мне знать в комментариях, и я буду рад добавить эту сюда