|
Martin Brown
Вы будете удивлены тем, как много информации генерируют ваш компьютер, операционные системы и приложения в ходе выполнения своих повседневных операций. Один из моих относительно спокойных серверов Unix, например, генерирует около 2 Мб информации в системный журнал (syslog) каждую неделю. Но эта информация практически бесполезна до тех пор, пока она не будет конвертирована в поддающиеся интерпретации данные о том, что происходит на сервере. Чтобы добиться этого, мне необходимо знать о любых ошибках, потенциальных проблемах и отказах, которые могут иметь место на компьютере и вызвать его отказ или выход из строя. Другими словами, я должен проанализировать журналы.
Эта статья описывает некоторые основы анализа журналов, особо останавливаясь на тех из них, которые представляются мне наиболее важными, с тем, чтобы вы тоже могли анализировать ваши массивные журналы сервера.
Типы журналов
Журналы делятся на несколько разных категорий, исходя из их формата, источника и типичного содержания. Я не собираюсь приводить здесь их полный список, поскольку это могло бы занять не только остаток этой статьи, но и массу времени, но мы можем обобщить их до нескольких ключевых типов:
- Содержание: В журнале может содержаться информация, предупреждения и извещения или фатальные ошибки. Журналы доступа (access log) в Apache и IIS являются примерами информационных журналов. Извещения, предупреждения и фатальные ошибки обычно объединены в единый журнал "ошибок" (который, по существу, является тем же, что и syslog в Unix) или, возможно, потом разделяются на определенные типы ошибок или источников (в стиле системного журнала Event Log в Windows). В некоторых случаях вся информация журнала собирается в единый файл и содержание этого файла помогает описать, на что ссылается каждая отдельная запись.
- Источник: Журналы происходят из различных мест - от приложений и системы до драйверов и библиотек. Источник используется в качестве метода классификации. Например, подсистемы безопасности могут иметь свой собственный журнал или их журнал может определять, где и как информация обновляется. Системные журналы генерируются и обрабатываются операционной системой; журналы приложений могут создаваться приложениями и находиться в центральном расположении, вместе с системными журналами или в некотором временном расположении;
- Формат: Журналы могут быть представлены либо в текстовом, либо в двоичном формате. Не вызывает удивления, что текстовый формат является более популярным, c точки зрения как разработки, так и чтения, поскольку с ним легче всего работать. Двоичный формат, как правило, невозможно прочесть без некоторого рода предварительной обработки, но информация в двоичном журнале легче форматируется и может использовать специфические и структурированные типы данных для таких элементов, как дата, время и классификация. Это упрощает их анализ (предоставляет в известном формате), поскольку нет необходимости делать сложные допущения или оценку того, что может содержать этот журнал. Даты и время являются примерами двоичных дружественных данных, но в текстовом файле они должны предварительно обрабатываться с тем, чтобы определяться как распознаваемые, пригодные к использованию даты.
Независимо от исходного формата, расположения и содержания, для того, чтобы получить любую полезную информацию из журналов, они должны обрабатываться таким образом, чтобы каждая запись в журнале была идентифицируемой, также как и каждое поле записи, которое содержит информацию.
Зачастую формат журнала является предопределенным. Существуют стандарты для системных журналов, журналов НТТР и многих других. Однако, если вам повезет, вы также можете изменить выходной формат журнала для определенных приложениях. Это позволит вам настраивать компоненты журнала и формат содержания, упрощая последующую обработку содержимого. Например, стандартный формат журнала доступа в Apache 2.0 конфигурируется с помощью следующей строки в конфигурационном файле:
LogFormat "%h %l %u %t \"%r\" %>s %b" common |
Однако, он является полностью настраиваемым, поэтому Apache может создавать выходные данные, подобные XML-файлу, если изменить указанную выше строку на нижеприведенную:
LogFormat "<logitem><host>%h</host> <ident>%l</ident> <user>%u</user> <datetime>%t</datetime> <url>%r</url> <statuscode>%>s</statuscode> <bytes>%b</bytes> </logitem>" \ common |
Обратите внимание на то, что эти строки (и многие другие примеры в этой статье) отформатированы только для наглядности, а должны все быть в одной физической строке. Кстати, вы можете использовать этот текст для получения такого же результата в IIS 6 и Windows Server 2003.
Содержимое журналов
Первым шагом в анализе содержимого ваших файлов журналов для получения информации является получение реальных данных из журнала. Чтобы сделать это, вы должны понимать формат журнала. В текстовых файлах информация обычно форматируется характерным способом с определенными полями, когда в качестве разграничителя используется либо единственный символ (например, пробел или двоеточие), либо поля фиксированной ширины. Кроме того, отдельные поля могут также быть разделены или форматированы в соответствие с их содержимым. Блок, приведенный ниже, является примером, взятым из журнала с Web-сервера Apache:
192.168.1.59 - - [11/Feb/2004:12:21:57 +0000] "GET / HTTP/1.1" 200 11669 192.168.1.59 - - [11/Feb/2004:12:21:59 +0000] "GET /mcslp.css HTTP/1.1" 200 4828 192.168.1.59 - - [11/Feb/2004:12:21:59 +0000] "GET /weather/images/3.gif HTTP/1.1" 200 566 192.168.1.58 - - [11/Feb/2004:12:22:21 +0000] "GET /mail/index.cgi?m=v&mbox=com-mcslp-lbt&id=2532 HTTP/1.1" 200 20656 192.168.1.58 - - [11/Feb/2004:12:22:22 +0000] "GET /mcslp.css HTTP/1.1" 304 0 |
Этот пример показывает смесь текстовых разграничителей для полей в форме пробелов, а также разграничители полей для обозначения даты/времени и компонентов URL журнала. Вот другой пример, на этот раз из системного журнала:
May 16 18:14:30 twinsol sm-mta[22012]: [ID 801593 mail.info] i4GHEQxG022012: from=<lwmeditors-bounces@shetland.sys-con.com>, size=20913, class=-30, nrcpts=1, msgid=<200405161600.i4GG06xf025868@shetland.sys-con.com>, proto=ESMTP, daemon=MTA, relay=postfix@plunder.dreamhost.com [66.33.213.13] May 16 18:14:30 twinsol sm-mta[22017]: [ID 801593 mail.info] i4GHEQxG022012: to=<com-mcslp-lbt@gendarme.mcslp.com>, delay=00:00:01, xdelay=00:00:00, mailer=cyrusv2, pri=194913, relay=localhost, dsn=2.0.0, stat=Sent |
Умение читать и понимать эти журналы помогает сфокусировать ваш подход и обеспечивает базис для анализа этих данных.
Большинство инструментов для анализа журналов обеспечивает определенный набор информации, но наиболее общая добываемая информация - это базовая статистика для информации журнала. Например, из Web журнала вы можете получить список URL посещенных сайтов и количество подключений к ним. Это обеспечивает полезную информацию о популярности отдельно взятой страницы или зоны вашего Web-сайта.
Если ваши журналы предоставляют некоторый набор информации, особенно такой, как дата и время или уведомление, то вы можете также использовать эту информацию для генерации статистики. Можно, например, отследить доступ к отдельно взятой странице или зоне вашего сайта за некоторый период времени, с тем, чтобы определить наиболее популярное время для посещения различных страниц сайта. Через некоторое время вы сможете использовать эту информацию для получения статистики использования сайта, наблюдая рост доступа и популярности различных частей сайта.
Другие журналы предоставляют альтернативные типы информации и статистики. Например, я использую журнал процессора или мой системный журнал для генерирования списка сообщений электронной почты, переданных через определенную машину, записывая при этом дату/время, источник и целевой адреса. При этом меня не столько заботит статистика, как извлечение необходимой информации из журнала.
Преобразование журналов в полезную информацию
Существует множество инструментов для анализа журналов, позволяющих переводить набор информации, основанный на содержании различных журналов, в полезную статистику, но, фактически, относительно проще и удобнее создать свои собственные. Хотя этого можно добиться в любом языке, сценарные решения, основанные на Perl или Python, являются наиболее практичным путем, благодаря их гибкой обработке данных и встроенным типам данных, подобным хэшу в Perl и словарю Python.
Если вы знаете формат журнала, то извлечение информации является относительно простой задачей. Например, вот простейший анализатор (parser), написанный на Perl, для стандартного журнала доступа Apache:
while (<INLOG>) { chomp; ($host,$ident,$user,$time,$url,$success,$bytes) = m/^(\S+)\s+(\S+)\s+(\S+)\s+\ [(.*)\]\s+"(.*)"\s+(\S+)\s+(\S+)[ ]*$/; ($day,$mon,$year,$hour,$min,$sec) = ($time =~ m%(..)/(...)/(....):(..):(..):(..)%); } |
А вот подобное решение на Python:
while 1: line = file.readline() if line: splitline = string.split(line) if len(splitline) < 10: print splitline continue (host,ident,user,time,offset,req, loc,httpver,success,bytes) = splitline |
Теперь, когда у нас есть основные поля, мы можем построить счетчики и системы перекрестных ссылок для отслеживания и составления отчетов по различным элементам. Например, для получения списка уникальных посещаемых URL, мы можем использовать хэш или словарь для их подсчета. В Perl это выглядит так:
В то же время на Python мы должны вставить в него оператор try для задания начального значения:
try: urlaccess[loc] = urlaccess[loc] + 1 except: urlaccess[loc] = 1 |
Можно повторить подобный основной процесс с любым из других значений в этом журнале, получаемым из информации в полях. Когда мы обрабатываем этот журнал, простые выходные данные, обобщающие информацию, генерируются по мере его обработки.
Если вы только хотите извлечь определенные поля информации из журнала для составления отчета на основе их содержания и игнорируете ненужные части, то можно пренебречь статистической информацией и использовать этот анализатор в качестве переформатирующего инструмента. Инструмент для извлечения данных из системного журнала, упомянутый ранее (извлекающий источник и адресата электронного письма), написан на Perl и выглядит следующим образом:
my (%from, %to, $time, @id); open(DATA,"/var/log/syslog"); while(<DATA>) { if (m/mail.info/) { if (m/(\S+\s+\d+\s+[\d:]+).*?mail.info\]\s+(\S+):.*?from=<(.*?)>/) { push @id, $2; $from{$2} = $3; $time{$2} = $1; } if (m/mail.info\]\s+(\S+):.*?to=(.*?),/) { $to{$1} = $2; } } } |
Для получения необходимой информации мы используем регулярное выражение и в этом процессе создаем несколько хэшей, соответствующих уникальным ID для каждого электронного письма с его отправителем, адресатом и датой/временем. Чтобы получить отчет об этой информации, мы обработаем один из хэшей и распечатываем соответствующие данные:
foreach my $id (@id) { if (exists($to{$id})) { $to{$id} =~ s/[<>]//g; my ($pre,$post) = split /@/,$to{$id}; next if ($pre =~ /ESMTP/); next if ($from{$id} =~ /admin\@mcslp.com/); my ($frombat,$fromaat) = split /\@/,$from{$id}; $frombat = substr($frombat,0,8); printf("%s %-40s => %s\n",$time{$id},"$frombat\@$fromaat",$pre); } } |
Этот пример также демонстрируют, как фильтровать информацию или те части журнала, которые нам не требуются. В приведенном выше примере, электронные письма, предназначенные для главной административной учетной записи в данном домене игнорируются, поскольку мы заинтересованы только в электронной почте, связанной с пользователями.
В заключение опять, как и в предыдущем примере, ничто не может запретить вам переформатировать данные источника с тем, чтобы они соответствовали вашим требованиям. В данном случае, мы удаляем информацию о домене в адресе получателя. В Weblog вам может потребоваться фильтровать отчет, работающий только на определенной части сайта или, возможно, игнорировать URL, не связанные с HTML- или CGI-содержанием (например, изображения и фильмы).
Отслеживание, а не анализ
Обобщение журналов и генерирование статистики является относительно простой задачей - если мы говорим только о подсчете информации, основываясь на содержании определенных полей, таких как URL или host. Эта информация полезна, если все что вам нужно - это основные подсчеты и статистика, но этого может оказаться недостаточным для получения всей необходимой вам информации, поскольку порой вам может потребоваться проследить перемещение пользователя, результата или элемента через всю историю журнала.
Например, если вы отслеживаете отдельного пользователя по всей системе, то вам может потребоваться установить, какие страницы он просматривал. Этот тип анализа выходит за рамки основных статистических систем, описанных здесь. Базовая обработка и анализ журнала во внутренних структурах данных остается такой же, но дальнейший анализ этой информации будет отличаться.
Если вы знаете еще что-нибудь об отслеживании и технических приемах более комплексного анализа журналов, свяжитесь со мною и я продолжу обсуждение этих тем в следующей статье. Пожалуйста, предлагайте любые конкретные примеры, решение которых вы хотели бы узнать и описание той информации, которую вам нужно отслеживать и включать в отчет.
|
