Чем парсить логи windows

Обновлено: 05.07.2024

Есть у меня одна слабость — я люблю разные системы мониторинга. То есть для меня идеальна ситуация, когда можно посмотреть состояние каждого компонента системы в любой момент времени. С реалтаймом все более-менее понятно: можно агрегировать данные и выводить их на красивый дашборд. Сложнее обстоят дела с тем, что было в прошлом, когда нужно узнать разные события в определенный момент и связать их между собой.

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

Самый простой вариант, который на первых порах отлично работал для меня, — использовать облачный сервис. Подобные инструменты активно развиваются, предоставляют поддержку все большего количества технологических стеков и подстраиваются по специфику отдельных IaaS/PaaS’ов вроде AWS и Heroku.

Splunk

Про этот сервис писал в колонке и я, и недавно Алексей Синцов. Вообще говоря, это не просто агрегатор логов, а мощная система аналитики с многолетней историей. Поэтому задачка собрать логи и агрегировать их для дальнейшей обработки и поиска — для него плевое дело. Существует более 400 различных приложений, в том числе более ста в области IT Operations Management, которые позволяют собирать информацию с твоих серверов и приложений.

loggly

Этот сервис уже специально заточен для анализа журналов и позволяет агрегировать любые виды текстовых логов. Ruby, Java, Python, C/C++, JavaScript, PHP, Apache, Tomcat, MySQL, syslog-ng, rsyslog, nxlog, Snare, роутеры и свитчи — неважно. Бесплатно можно собирать до 200 Мб в день (что немало), а ближайший платный тариф начинается от 49 долларов. Работает очень здорово.

windows-loggly

windows-loggly

Реверс малвари

PaperTrail

Отличный сервис, который агрегирует логи приложений, любые текстовые журналы, syslog и прочее. Что интересно: с агрегированными данными можно работать через браузер, командную строку или API. Поиск осуществляется простыми запросами вроде «3pm yesterday» (получить данные со всех систем в три часа ночи за вчерашний день). Все связанные события будут сгруппированы. Для любого условия можно сделать алерт, чтобы вовремя получить предупреждения (изменились настройки в конфигах). Для хранения логов можно использовать S3. В первый месяц дают 5 Гб бонусом, дальше бесплатно предоставляется только 100 Мб в месяц.

Logentries

Еще один неплохой сервис для сбора данных, позволяющий собирать до гигабайта логов в месяц бесплатно. А возможности все те же: мощный поиск, tail в режиме реального времени (выводится все, что «прилетает» из логов на текущий момент), хранение данных в AWS, мониторинг PaaS, IaaS и популярных фреймворков, языков. На бесплатном тарифе можно хранить данные за семь дней.

NewRelic

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

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

logstash

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

Fluentd

Если выбирать standalone-решение, то Fluentd мне понравился больше. В отличие от logstash, которая написана на JRuby и поэтому требует JVM (которую я не люблю), она реализована на CRuby и критические по производительности участки написаны на C. Система опять же открытая и позволяет собирать большие потоки логов, используя более 1500 различных плагинов. Она хорошо документирована и предельно понятна. Текущий вариант сборщика логов у меня развернут именно на Fluentd.

Степа Ильин

Главный редактор «Хакера» с 2012 по начало 2014 года. Сейчас с командой единомышленников строит компанию Wallarm, разрабатывающую решения для защиты веб-приложений от хакерских атак и обнаружения в них уязвимостей.

Как работает LogParser

Администраторам, знакомым с операторами SQL SELECT, не составит труда освоить команды LogParser. В команде LogParser можно указать поля журнала, которые должны войти в генерируемый инструментом файл, полезные и ненужные записи о событиях (по результатам сравнения полей, заданных пользователем) и метод сортировки выходных записей. Но в действительности возможности LogParser гораздо шире. В механизме данных реализованы новейшие функции запросов, в частности подсчета записей, средних значений и определения 10 наиболее частых событий. Работая с текстовыми полями и производя вычисления над датами и числами, можно настраивать выходные данные и уточнять критерии выбора.

После того как механизм данных обработает информацию и выдаст набор результатов, в действие вступает выходной процессор, который преобразует набор результатов в выходную таблицу. Выходной процессор, как и входной, совместим со многими типами файлов, и выходную таблицу можно представить по-разному — от простых текстовых файлов до базы данных SQL или XML-файлов.

Простой запрос

Чтобы оценить возможности LogParser, начнем с примера команды и ее выходных данных. Следующая команда запрашивает журнал Security на локальной системе и генерирует отчет обо всех блокированных учетных записях:

Выходные данные приведены на экране 1. Здесь указаны лишь SID блокированных учетных записей пользователей; в дальнейшем я поясню, как преобразовать SID в имена пользователей. Как видно, LogParser — мощный инструмент с простым синтаксисом. Единственный обязательный агрумент — оператор SELECT, который необходимо заключить в кавычки. LogParser чувствителен к регистру символов при чтении большей части входной информации, поэтому, например, «eventid» отличается от «EventID». В зависимости от типа исследуемого журнала иногда необходимо указать параметры входных журналов или формат выходных файлов.

Формулировка запросов

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

Оператор SELECT состоит из двух обязательных (SELECT и FROM) и нескольких необязательных операторов:

Оператор SELECT указывает поля, которые войдут в каждую запись набора результатов запроса. Оператор FROM указывает, какой журнал или журналы следует использовать в качестве входных. Оператор TO задает место назначения для выходного файла. Оператор WHERE определяет критерии фильтрации входящих и выходящих записей запроса. Операторы GROUP BY и HAVING представляют собой мощные средства анализа групп аналогичных записей, общих вычислений над этими группами и задания критериев фильтрации групп на входе и выходе запроса. Оператор ORDER BY сортирует набор результатов по заданным полям. Рассмотрим операторы FROM, SELECT и WHERE более подробно.

FROM security

SELECT. Следующий шаг после выбора опрашиваемого журнала при построении команды LogParser — подготовка предложения SELECT. Данный оператор задает список полей входного журнала, разделенных запятыми, которые войдут в выходной файл запроса. Благодаря встроенным функциям для работы с журналами событий Windows, LogParser автоматически распознает имена полей журнала (EventLog, RecordNumber, TimeGenerated, TimeWritten, Event-ID, EventType, EventTypeName, EventCategory, SourceName, Strings, ComputerName, SID и Message); во врезке «Поля журналов событий» кратко описано каждое поле. LogParser распознает имена полей журналов IIS. Для входных файлов других форматов LogParser может определить имена полей из первой строки журнального файла, если она представляет собой заголовок. В противном случае LogParser отмечает каждое входное поле как Field1, Field2 и т. д. В случае сомнений относительно имен полей их можно определить с помощью оператора SELECT * FROM filename LogParser выдает все поля из входного файла. После того как LogParser выдаст несколько записей, следует остановить запрос и просмотреть записи, чтобы определить назначение каждого поля, а затем сопоставить каждое поле имени, назначенному ему программой LogParser.

Оператор SELECT позволяет задавать выражения наряду с простыми именами полей. Пользователь может манипулировать строками и выполнять арифметические действия над числовыми полями и датами при генерации выходной таблицы. Например, выходную таблицу можно дополнить элементарным описанием каждого события, без всех строк, следующих за таким описанием. В журнале Security элементарное описание каждого события — первая информация, отображаемая в поле Message записи о событии; описание заканчивается двоеточием (:). Таким образом, LogParser должен исследовать поле Message, отыскать первое двоеточие и выдать текст, расположенный перед ним:

В этой команде используются две функции манипулирования строками, реализованные в LogParser: SUBSTR и INDEX_OF. Найти начало поля Message (до первого двоеточия) можно с помощью функции SUBSTR. Первый параметр этой функции указывает исходную строку, которую предстоит разделить, — в данном случае Message. Второй параметр указывает позицию внутри исходной строки, с которой следует начать, например первый символ (позиция 0). Третий параметр указывает конечную позицию внутри исходной строки — двоеточие. Но чтобы получить позицию двоеточия, необходимо использовать функцию INDEX_OF, которая возвращает первую позицию символа «двоеточие» в поле Message. LogParser располагает множеством функций для манипуляций со строками, числами и датами; более подробную информацию об этих функциях можно найти в файле LogParser.doc в папке установки LogParser.

Чтобы дать выражению в запросе имя, следует использовать ключевое слово AS с последующим именем поля, которое будет отображаться в выходной таблице, например Description. Ключевое слово AS может потребоваться для именованных выражений в операторе SELECT или переименования поля в операторе SELECT. Ниже, в рассказе о подчиненных запросах, будет приведен пример использования AS для переименования полей.

Нередко LogParser выдает дублированные записи, так как несколько записей располагают одинаковыми значениями в наборе полей, указанных в операторе SELECT. Например, команда

logparser «SELECT EventID FROM security»

logparser «SELECT DISTINCT EventID FROM security»

выдает список уникальных идентификаторов событий, представляющий перечень всех событий с уникальными ID, встречающихся в журнале хотя бы один раз. Ключевое слово DISTINCT применяется только к полям, указанным в операторе SELECT, но не к полям, указанным в других операторах, таких как WHERE, ORDER BY, GROUP BY или HAVING.

WHERE. После того как указан журнал или журналы, к которым нужно послать запросы, и поля, откуда требуется извлечь информацию, следует задать критерий фильтрации. Оператор WHERE задает выражение, имеющее значение TRUE или FALSE. Это выражение может быть простым:

Данное выражение извлекает все экземпляры события с ID 529 (неудачная попытка регистрации: неправильное имя пользователя или пароль), которые произошли между 21 декабря 2003 г. и 24 декабря 2004 г. (MM — месяц; mm — минуты). Несколько простых выражений внутри сложного выражения связаны оператором AND. Можно также использовать операторы OR, NOT и скобки, как в SQL или другом языке программирования.

Стандартные операторы сравнения SQL (табл. 1) можно задействовать в операторе WHERE для сравнения полей со значениями и выражениями. В частности, оператор LIKE очень полезен для сравнения с применением универсальных символов. Например, команда

использует оператор LIKE для генерации списка всех событий, запущенных пользователями, в именах которых есть символы «smith» (например, Smith, Naismith, Smithe). Заменив «%smith%» на «Wri*», можно получить такие имена, как Wright и Wrigley; «%son» возвращает такие имена, как Johnson и Albertson. В этом примере команды использован еще один полезный параметр LogParser: -resolveSIDs. SID сам по себе довольно неудобен для восприятия, поэтому с помощью —resolveSIDs можно автоматически преобразовать SID в имена соответствующих учетных записей пользователей. Чтобы задействовать этот параметр, достаточно вставить перед оператором SELECT следующую запись:

-i:EVT -resolveSIDs ON

logparser -i:EVT -resolveSIDs
ON «SELECT DISTINCT SID FROM security»

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

возвращает каждый уникальный SID и соответствующее имя пользователя (экран 3).

Обычно выходные данные фильтруются по значению поля относительно другого значения. Так, можно выяснить, совпадает ли ID события текущей записи с числом 529 или значение TimeGenerated превышает либо равно определенной дате. Но иногда необходимо узнать, существует ли в списке то или иное поле. В таких случаях применяется оператор сравнения IN. Например, оператор

WHERE EventID IN (529, 530, 531,
532, 533, 534, 535, 537, 539)

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

Однако у оператора IN есть еще одно важное применение. Можно составить оператор WHERE, в котором LogParser использует значения одного или нескольких полей текущей строки для создания подчиненных запросов, результаты выполнения которых помогут определить, следует ли добавить текущую строку в выходные данные. Для этого можно встроить подзапрос в скобки, следующие за IN. Например, можно получить список всех пользователей, чьи учетные записи были блокированы и у кого впоследствии были сброшены пароли. Для этого нужно найти каждое событие блокирования учетной записи (ID 644), затем определить, был ли для этой записи сброшен пароль после даты и времени события блокирования. Для выполнения этих задач следует сначала составить простой запрос:

В результате будут получены имена пользователей всех когда-либо блокированных учетных записей. Затем нужно добавить следующее выражение IN:

Добавив параметр -resolve SIDs, чтобы получить читаемые имена пользователей, и применив параметр AS для переименования папок, получаем команду:

При запуске этой команды LogParser отыскивает все события с ID 644, затем находит все события с ID 642 с таким же именем пользователя, произошедшие после блокирования пользователя. Оператор SELECT в подзапросе должен возвращать лишь одно поле, в противном случае программе LogParser будет неизвестно, с каким полем из набора результатов подзапроса нужно проводить сравнение. В данном примере LogParser проверяет содержимое поля username в записях, полученных в результате работы подзапроса. Параметр AS мы использовали для переименования полей в обоих операторах SELECT, чтобы избежать двусмысленности при сравнении поля имени пользователя (username) в родительском запросе с полем имени пользователя (subUserName) в подчиненном запросе.

Таким образом, LogParser представляет собой мощный инструмент, с помощью которого можно составлять SQL-подобные запросы для поиска в журналах любого типа. Это позволяет находить нужную информацию, не просматривая тысячи записей журнала. Наряду с описанными в статье функциями LogParser располагает и другими возможностями для манипулирования строками, датами и числовыми полями. С помощью одного запроса можно проверить несколько журналов и даже выдать результаты в различные файлы. Кроме того, LogParser поддерживает функции агрегирования, которые позволяют выполнять высокоуровневый анализ с учетом временных интервалов, средних значений, минимумов и максимумов и 10 наиболее часто встречающихся записей для данного критерия. В одной из следующих статей я расскажу о том, как использовать такие функции для анализа данных и кодов в поле Strings в описании событий системы безопасности.

Поля журналов событий

Имена полей в журналах событий (.evt) Windows 2000 и более поздних версий следующие: EventLog, RecordNumber, TimeGenerated, TimeWritten, EventID, EventType, EventTypeName, SourceName, EventCategory, Strings, Message, ComputerName и SID. Каким образом используются эти поля, когда LogParser обрабатывает события журнала Security?

Поле EventID содержит ID события в Windows. Например, Windows идентифицирует события блокирования учетных записей как ID 644, успешные попытки регистрации как ID 528. EventType и EventTypeName указывают, было ли событие успешным. Например, событие с ID 529 (неудачная попытка регистрации: неправильное имя пользователя или пароль) имеет EventType 16, а EventTypeName — Failure Audit event; тогда как событие с ID 528 (успешная регистрация) имеет EventType 8, а EventTypeName — Success Audit event. Поле EventType журнала Security может иметь значение 8 или 16; в журналах System и Application используются другие значения для информационных событий, предупреждений и ошибок.

SourceName и EventCategory соответствуют полям Source и Category в Event Viewer (экран A). Поле SourceName не особенно полезно, так как все события имеют одинаковый источник: Security. Но EventCategory может пригодиться для сортировки и фильтрации событий в соответствии с категориями политик аудита Windows. В Windows 2000 и более поздних версиях имеется девять категорий политик аудита, которые можно увидеть, открыв интерфейс Administrative Tools, Local Security Policy и перейдя к Security SettingsLocal PoliciesAudit Policy.

EventCategory — числовое значение; в табл. A показаны значения EventCategory и соответствующие имена категорий (как имя категории политики аудита, так и имя в поле Event Viewer Category).

Поля Strings и Message относятся к многострочному тексту в разделе Description записи события. Для совместимости с различными языками служба Windows Event Log настроена так, что разработчики могут отдельно создавать статические и динамические элементы описания. Например, в разделе Description записи с ID 576 (экран B) имена полей User Name и Domain представляют собой статические элементы, а значения этих полей (LOCAL SERVICE и NT AUTHORITY) — динамические элементы, которые изменяются от одного экземпляра события к другому. Динамические элементы называются строками (string). Поэтому поле Strings в LogParser содержит все динамические элементы текущего события. Это поле используется, если нужно отфильтровать события по динамическим элементам для заданного ID — например, чтобы увидеть все экземпляры события с ID 528 (успешная регистрация) с Logon Type 2 (интерактивная). В следующих статьях будет показано, как извлекать определенные элементы из таких текстовых полей, как Strings, с помощью функций LogParser для манипулирования строками. Поле Message содержит полное описание события, т. е. и статические, и динамические элементы.

Поле SID содержит SID учетных записей пользователей, связанных с событием. Для большинства событий SID соответствует учетной записи, вызвавшей событие, но некоторые события генерируются системными учетными записями, а не пользователями. В табл. B перечислены SID и учетные записи, которые генерировали эти события. Одна из функций LogParser преобразует SID в имена учетных записей пользователей, как описано в основной части статьи.


Обзоры

Прежде чем мы перейдем к централизованному ведению журналов, давайте сначала рассмотрим, почему ведение журналов ( логирование ) так важно.

Компьютеры являются детерминированными системами, кроме случаев, когда это не так.

Как безопасник, я сталкивался со многими случаями, когда наблюдаемое поведение приложения ставило всех в тупик целыми днями, но ключ к разгадке всегда был в журналах.

Каждое программное обеспечение, которое мы запускаем, производит (или, по крайней мере, должно генерировать) журналы, которые сообщают нам, через что они проходили, когда возникала проблемная ситуация.

Теперь, как мне кажется, ведение журнала бывает двух типов: автоматически сгенерированные журналы и сгенерированные программистом журналы.

Обращаем ваше внимание, что этих различий и классификации нету в учебниках, и цитирование меня по этой терминологии доставит вам неприятности. ?


Изображение выше показывает то, что можно назвать автоматически сгенерированным журналом.

В данном конкретном случае это система WordPress, регистрирующая непредвиденное состояние (уведомление) при запуске некоторого кода PHP.

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

В такие моменты они копаются глубоко в коде, пытаясь понять, что пошло не так.

Но автоматически сгенерированные журналы могут помочь только так сильно.

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

Здесь нужен дополнительный уровень явной, обширной регистрации, которая создает следы для человеческой стороны вещей.

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

Вот пример того, как может выглядеть такая схема регистрации:

Логгирование это сила

Итак, с учетом этих двух типов журналов в системе, вот как вы можете использовать их и усилить воздействие.

Боевой дух и продуктивность команды

Как я уже говорил, когда ошибки долго не отслеживаются, разработчики в вашей команде разочаровываются и теряют все больше и больше времени, закрывая свои хвосты.

И что затрудняет отладку?

По моему опыту, отсутствие ведения журнала или отсутствие знаний о ведении журнала.

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

Несколько дней спустя виновником стало ограничение дискового ввода-вывода из-за чрезмерного трафика.

Потому что никто не удосужился посмотреть журналы,и никто не мог понять, почему система упала.

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

Часто такие небольшие изменения работают лучше, чем удвоение емкости оборудования.

Невозможно сосчитать, сколько способов решения проблем подарит вам хорошая система журналов.

Возможно, лучшим аргументом является то, что это автоматическое действие, которое когда-то настроено, не нуждается в каком-либо мониторинге и однажды спасет вас от разорения.

В связи с этим давайте рассмотрим некоторые из удивительных сборщиков журналов с открытым исходным кодом (унифицированных инструментов ведения журналов).

1 Graylog

2 Logstash

Если вы являетесь поклонником или пользователем стека Elastic, стоит попробовать Logstash (стек ELK )

Как и другие инструменты ведения журнала в этом списке, у Logstash,полностью открытый исходный код, дает вам свободу развертывания и использования по своему усмотрению.

Он способен собирать огромные объемы данных с разных платформ, позволяет определять и выполнять собственные конвейеры данных, понимать неструктурированные дампы журналов и многое другое.

3 Fluentd

Среди централизованных инструментов ведения журналов, которые выполняют роль промежуточного уровня для приема данных, Flutend является первым среди равных.

Обладая превосходной библиотекой плагинов, Fluentd может собирать данные практически из любой производственной системы, перемешивать их в нужной структуре, создавать собственный конвейер и передавать его на свою любимую аналитическую платформу, будь то MongoDB или Elasticsearch.

Fluentd построен на Ruby, является продуктом с полностью открытым исходным кодом и пользуется большой популярностью благодаря своей гибкости и модульности.

С такими крупными компаниями, как Microsoft, Atlassian и Twilio, использующим эту платформу, Fluentd нечего доказывать. ?

4 Flume

Это «чистый» проект с открытым исходным кодом, в том смысле, что он поддерживается нашим любимым Apache Foundation, что означает отсутствие корпоративного плана.

Это может быть то, что вы точно ищете. ?

Написанный на Java (который продолжает удивлять меня, когда дело доходит до революционных технологий), исходный код Flume полностью открыт.

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

5 Octopussy

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

По моему мнению, Octopussy покрывает потребности большинства продуктов (оценочная статистика бесполезна, но, если бы мне пришлось угадывать, я бы сказал, что в реальном мире она учитывает 80% случаев использования)

У Octopussy нет отличного пользовательского интерфейса:


но он компенсирует скорость и отсутствие раздувания.

Исходный код доступен на GitHub, как и ожидалось, и я думаю, что он заслуживает серьезного изучения.

6 LOGalyze

LOGalyze был коммерческим продуктом, который недавно стал инструментом с открытым исходным кодом.

Хотя я не смог реализовать проект на GitHub, они сделали установщик Windows и весь исходный код загружаемым.

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


Да, он не делает все, но поскольку это был коммерческий продукт в свое время, он делает это довольно хорошо.

7 LogPacker

Когда дело доходит до выбора инструмента для работы, у меня есть два критерия: он должен быть целенаправленным и опираться на активную бизнес-модель.

Проблема программного обеспечения с открытым исходным кодом, как правило, заключается в том, что через несколько месяцев / лет вероятность застоя или выхода из строя высока.

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

8 Logwatch

Я уверен, что среди нас есть те, кто не хочет, чтобы вся церемония была связана с «единой», «централизованной» системой ведения журналов.

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

Ну тогда, скажи привет Logwatch.

После установки LogWatch может сканировать системные журналы и создавать отчеты нужного вам типа.

Это несколько устаревшее программное обеспечение (читай «надежное»), хотя оно было написано на Perl.

Итак, вам понадобится Perl 5.6+ на вашем сервере для его запуска.

У меня нет скриншотов, которыми можно поделиться, потому что это чисто командная строка, демонизированный процесс.

Если вы наркоман CLI и любите стиль старой школы, вам понравится Logwatch!

9 Syslog-ng

Инструмент Syslog-ng был разработан как способ обработки файлов системного журнала (установленный протокол клиент-сервер для регистрации в системе) в режиме реального времени.

Однако со временем он стал поддерживать другие форматы данных: неструктурированные, SQL и NoSQL.

Как работает протокол системного журнала, довольно четко подытожено на следующем рисунке.

10 Inav

Я что-то пропустил? Конечно, я сделал это!

Пожалуйста, дайте мне знать в комментариях, и я буду рад добавить эту сюда

"О нас"

Анализ журнала — это очень мощный и универсальный инструмент, дающий универсальный доступ к текстовым данным, таким как файлы журнала, XML-файлы и CSV-файлы, а также основные источники данных в операционной системе Microsoft Windows, такие как журнал событий, реестр, файловая система и служба каталогов Active Directory. Щелкните
здесь, чтобы скачать средство. В этой версии с помощью средства анализа журнала можно легко и легко проапрысировать следующие файлы:

Я не буду обсуждать использование средства "Анализ журнала", потому что документация вполне хорошая, а папка установки также содержит папку "Samples\Queries", которая содержит довольно много примеров.

Поэтому, когда я немного развернусь в средстве анализа журнала, я вернусь к сценариям, о которые я говорил.

Сценарий 1. Размыкание больших текстовых файлов для определенного текста

Небольшой фон проблемы

Ответ. Откройте окно команды "Журнал" и воспользуйтесь следующей командой:

LOGPARSER "Select Text from C:\Filemon.log where Text like '%Access Denied%'" -i:TEXTLINE -q:OffWhat we are telling the Log Parser is to parse through each line (Text) from the given file (C:\Filemon.log), where the line contains 'Access Denied'. Переключатель командной строки -i:TEXTLINE определяет формат ввода, а переключатель -q:Off — подробный (-q[:ON| ВЫКЛЮЧ]:тихий режим;). Если включить переключатель командной строки -q, показанная статистика и имя поля (текст) в выходных данных будут отсутствовать.

Пример выходных данных

Текст7447 1:49:24 explorer.exe:1200 КАТАЛОГ C:\ Обработка записей об отказе в статистике: результат 640444:

1 время выполнения: 12,75 секунд: как избежать нажатия нескольких нажатий ввод, если количество записей, возвращенных запросом, превышает

Ответ. Используйте в запросах параметр -rtp:-1!

Использование файлов запросов

Другой способ получить те же результаты — создать файл запроса. Таким образом вы можете легко настроить файл запроса и запустить его из командной строки средства анализа журнала. Кроме того, вы можете легко создать его по вкусу. Он загружает сохраненный SQL и выполняет его с помощью средства анализа журналов.

Если вы хотите достичь того же эффекта (как в сценарии 1) от SQL запросов, можно предоставить следующую команду:

LOGPARSER -i:TEXTLINE-файл:C:\LPQ\SearchAnyTextfile.sql -q:offC:\LPQ\SearchAnyTextFile.sql содержит следующую информацию: Примечание: Создание папки

LPQ в C:\ чтобы использовать образцы, показанные в этом столбце.

Если вы заметили, что запрос выглядит намного более понятно и понятно. Это позволит создавать более сложные и крупные запросы, и все, что вам нужно, будет умещаться в командной строке. SQL файл, а не весь запрос. В командной строке невозможно вместить больше 260 знаков!

Сохраняя преимущества использования файлов запросов, я буду использовать этот метод в следующих сценариях. Все мои запросы сохранены в C:\LPQ с расширением SQL (вы можете использовать собственный).

Сценарий 2. Поиск 10 самых крупных файлов из определенной папки, включая ее вложенные папки

Небольшой фон проблемы

У вас есть папка, в ней очень много вложенных папок и файлов. Вы хотите найти 10 самых крупных файлов в этой папке, включая ее вложенные папки.

Я знаю, что для определенной папки вы можете просто изменить представление (в меню "Вид" нажать кнопку "Подробности") в проводнике и отсортировать его по размеру. Но проблема в этом заключается в том, что вам также необходимо учесть содержимое вемеской ведерки.

Ответ. Откройте окно команды средства "Журнал анализа журнала" и воспользуйтесь следующей командой:

LOGPARSER -i:FS-файл:C:\LPQ\Top10Files.sql -q:off -Recurse:-1Top10Files.sql содержит следующие данные:

Здесь I:FS означает, что мы запрашиваем файловую систему. Вы можете просмотреть полный список полей формата ввода FS в документации и обрамить запрос.

-Recurse:-1 подразумевается, что мы хотим включить в нее все ведерки. Если вам не нужны все ведерки или вы хотите ограничить рекурсию, используйте 0, 1, 2 и т. д. Число подразумевает глубину, в которая будет входить анализщик. 0 означает, что рекурсия не повторяется, 2 — повторение анализера до глубины 2 и т. д.

Пример выходных данных

Обработка статистических данных: результат 1000
элементов: 10 время
выполнения: 0,42 секунды

Сценарий 3. Поиск 20 самых медленных страниц на веб-сайте

Небольшой фон проблемы

Ответ. Откройте окно команды "Журнал" и воспользуйтесь следующей командой:

LOGPARSER -i:IISW3C-файл:C:\LPQ\Slowest20FilesInIIS.sql -o:DataGrid -q:offSlowest20FilesInIIS.sql содержит следующий пример кода:

Здесь i:IISW3C означает, что мы запрашиваем журналы W3C IIS. Вы можете просмотреть полный список полей формата ввода IISW3C в документации и обрамить запрос.

query, you should be using IISW3C Logging and have enabled Advanced Loggingproperties. (Откройте свойства веб-сайта, откройте вкладку "Веб-сайт", выберите "Включить ведение журнала", а затем закройте формат W3C Extended Log File. Щелкните "Свойства",перейдите на
вкладку "Дополнительные параметры" и выберите все параметры.)

Сценарий 4. Поиск 20 часто используемых ASPX-страниц на веб-сайте

Небольшой фон проблемы

Ответ. Откройте окно команды средства "Журнал анализа журнала" и воспользуйтесь следующей командой:

LOGPARSER -i:IISW3C-файл:C:\LPQ\Popular20FilesInIIS.sql -chartType:Bar3D -groupSize:640x480 -view:onPopular20FilesInIIS.sql содержит следующий пример кода:

В данном случае -chartType:Bar3D сообщает средству анализа журнала, какой тип диаграммы требуется подготовить. Параметр -groupSize определяет ширину и высоту конечного изображения в пикселях. Набор доступных типов диаграмм зависит от версии диаграммы веб-компоненты Microsoft Office установленной на локальном компьютере.

Ресурсы

Новые возможности в log Parser 2.2

Как работает log Parser 2.2

Microsoft Log Parser набор средств — книга по log Parser!

Как всегда, вы можете отправлять идеи по темам, которые вы хотите решить, в будущих столбцах или в базе знаний с помощью формы
Ask For It.

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

Читайте также: