Дейв Тейлор - Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание

Одним из усовершенствований сценария мог бы стать пропуск URL ссылающихся доменов, которые, вероятнее всего, не являются поисковыми системами. Для этого просто закомментируйте ветку else .

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

for URL in $(awk '{ if (length($11) > 4) { print $11 } }' "$1" | \

··grep $2)

do

··args="$(echo $URL | cut −d\? -f2 | tr '&' '\n' | \

······grep −E '(^q=|^sid=|^p=|query=|item=|ask=|name=|topic=)' | \

······cut −d= −f2)"

··echo $args | sed −e 's/+/ /g' −e 's/"//g' >> $temp

··count="$(($count + 1))"

done

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

Так же как сценарий № 73 извлекает интересную и полезную статистическую информацию из файла журнала access_log веб-сервера Apache или совместимого с ним, этот сценарий извлекает чрезвычайно важные сведения из файла журнала error_log .

В случае с веб-серверами, которые не разбивают автоматически свои журналы на отдельные компоненты access_log и error_log , иногда есть возможность разделить централизованный журнал на эти составляющие, выполнив фильтрацию по коду результата (содержимому поля 8):

awk '{if (substr($9,0,1) <= "3") { print $0 } }' apache.log > access_log

awk '{if (substr($9,0,1) > "3") { print $0 } }' apache.log > error_log

Коды, начинающиеся с 4 или 5, сообщают об ошибке (коды 400–499 соответствуют ошибкам на стороне клиента, а коды 500–599 — на стороне сервера). Коды, начинающиеся с 2 или 3, сообщают об успешной обработке запроса (коды 200–299 соответствуют успешной обработке запросов, а коды 300–399 — успешной переадресации).

Другие серверы, поддерживающие единый файл журнала и фиксирующие в нем одновременно отчеты об успехе и об ошибках, снабжают записи с информацией об ошибках полем [error]. В этом случае с помощью команды grep '[error]' можно создать аналог журнала error_log , а с помощью команды grep −v '[error]' — аналог журнала access_log .

Независимо от того, создает ли ваш сервер журнал error_log автоматически или вы должны выделить его вручную, отыскав записи со строкой '[error]', структура записей в error_log практически всегда отличается от структуры записей в access_log , включая способ представления даты:

$ head -1 error_log

[Mon Jun 06 08:08:35 2016] [error] [client 54.204.131.75] File does not exist:

/var/www/vhosts/default/htdocs/clientaccesspolicy.xml

В access_log даты указываются в виде компактного значения, занимающего одно поле, без пробелов; в error_log дата занимает пять полей. Кроме того, в отличие от единообразной схемы access_log , в которой позиция поля со словом/строкой в записи четко определяется пробелами, записи в error_log включают содержательные описания ошибок, различающиеся по длине. Исследование одних только описаний показывает удивительное разнообразие, как демонстрируется ниже:

$ awk '{print $9" "$10" "$11" "$12 }' error_log | sort −u

File does not exist:

Invalid error redirection directive:

Premature end of script

execution failure for parameter

premature EOF in parsed

script not found or

malformed header from script

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

Сценарий в листинге 10.5 решает только самые основные проблемы — в частности, отыскивает ошибки File does not exist («Файл не найден») — и просто выводит список всех остальных записей в error_log , которые не относятся к хорошо известным ситуациям.

Листинг 10.5.Сценарий weberrors

··#!/bin/bash

··# weberrors — Сканирует файл error_log журнала сервера Apache, сообщает

··#·· о наиболее важных ошибках и выводит все остальные, неопознанные записи.

··temp="/tmp/$(basename $0).$$"

··# Для надежной работы этого сценария настройте следующие три переменные