| Анализ журналов |
|
С точки зрения системного администратора никакое обсуждение вопросов обработки текста не может считаться законченным без обсуждения проблемы анализа файлов журналов, поэтому здесь мы рассмотрим эту проблему. Мы заложили основу знаний, которые позволят вам открыть файл журнала, прочитать его построчно и при этом извлекать данные тем способом, который вы сочтете наиболее подходящим. Прежде чем приступить к реализации очередного примера, нам необходимо ответить на вопрос: «Что нам необходимо получить в результате чтения файла журнала?». Ответ достаточно прост: прочитать журнал обращений к веб-серверу Apache и определить количество байтов, полученных каждым отдельным клиентом. Согласно описанию http://httpd.apache.org/docs/L3/logs.html «комбинированный» формат записи в файле журнала имеет следующий вид:
И это соответствует данным в нашем файле журнала веб-сервера Apache. В каждой строке журнала интерес для нас будут представлять две вещи: IP-адрес клиента и число переданных байтов. IP-адрес клиента находится в первом поле записи, в данном случае - это адрес 127.0.0.1. Количество переданных байтов содержится в третьем поле с конца, в данном случае было передано 2326 байтов. Как же нам получить эти поля? Взгляните на пример 3.24. Пример 3.24. Сценарий анализа файла журнала веб-сервера Apache -разбиение по пробелам
Этот пример чрезвычайно прост. В разделе__ main_ выполняется всего несколько действий.
Во-первых, осуществляется минимально необхо Функция generate_log_report() создает словарь, который играет роль Функция dictify_logline() просто разбивает строку по пробелам, извлекает определенные элементы из полученного списка и возвращает словарь с данными, извлеченными из строки. Будет ли работать такой сценарий? Проверим это с помощью модульного теста из примера 3.25. Пример 3.25. Модульный тест сценария анализа файла журнала веб-сервера Apache - разбиение по пробелам
Этот сценарий работает с комбинированным и общим форматами записей в журнале, но небольшое изменение в строке приводит к тому, что тест завершается неудачей. Ниже приводятся результаты тестирования:
Вследствие того, что в поле адреса появились два лишних пробела, все последующие поля в этой записи сместились на две позиции вправо. Здоровая подозрительность - хорошее качество. Основываясь на спецификациях форматов записей в журнале, можно достаточно уверенно извлекать адреса удаленных хостов и число переданных байтов, опираясь на способ выделения полей по пробелам. Пример 3.26 представляет реализацию того же самого сценария, выполненную с применением регулярных выражений. Пример 3.26. Сценарий анализа файла журнала веб-сервера Apache
Единственная функция, которая изменилась по сравнению с примером, основанным на «разбиении по пробелам», - это функция dicti-fy_logline(). При этом подразумевается, что тип значения, возвращаемого этой функцией, остался прежним и в примере, основанном на применении регулярных выражений. Вместо того, чтобы разбивать строку из журнала по пробелам, мы воспользовались объектом скомпилированного регулярного выражения, log_line_re, для выявления соответствий с помощью метода match(). Если соответствие обнаружено, с помощью метода groupdict() извлекаются практически готовые к возврату данные, где значение bytes_sent устанавливается равным 0, если поле содержит прочерк (-) (потому что прочерк означает «нисколько»). Если соответствие не было найдено, возвращается словарь с теми же самыми ключами, но со значениями элементов, равными None и 0. Действительно ли версия сценария, основанная на использовании регулярных выражений, работает лучше, чем предыдущая? Да, это так. Ниже приводится модульный тест для новой версии сценария анализа файлов журнала веб-сервера Apache:
И ниже - результаты модульного тестирования:
Related Articles
Set as favorite
Bookmark
Email This
Hits: 409 Комментарии (0)RSS feed CommentsНаписать комментарий |