Статьи Новости Контакты

19.04.2007
Алексей Журба

Логирование информации

Информация, которая встречается в логах

Часть 2. Информация в логах.

Что встречается в логах*? — В логах встречается все. Если учесть, что логироваться может любая активность, начиная от процесса инсталляции и до активности самой мелкой компоненты программы, то становится понятно, что в случае сбоев или проблем (симптомы могут быть любыми, в том числе и просто подозрительное поведение) первым делом следуют узнать о том, как и что логируется сейчас и как может логироваться в принципе. Следующая информация типична для всех логов:

  1. Дата и время регистрации события. Следует обратить внимание на то, что время может быть как с учетом временной зоны, так и без него (UTC). Иногда это может быть довольно важно для определения точного времени события. Бывают логи, в которых информация о времени не важна в силу специфичности представляемой информации, но обычная практика — это использование времени. Обычно с довольно высокой точностью (как минимум до секунды, но очень часто даже более точно — сотые доли секунды и т. д.). Такая точность нужна из-за того, что многие приложения успевают совершать сотни операций в секунду. Часть из этих операций логируется. Очевидно, что если записывать время с точностью до секунды, то в одну секунду будет попадать несколько событий (MS SQL успевает записать в свою audit-таблицу до 100 сообщений в секунду). Обычно приложение пишет свои логи в упорядоченном по времени виде, то есть каждое следующее событие имеет либо то же самое время регистрации либо большее. Есть приложения, которые могут получать информацию о событиях одновременно от нескольких компьютеров, именно в таком случае может появиться проблема с тем, что данные могут доходить с различной скоростью. К примеру, событие E1 на компьютере C1 произошло раньше, чем E2 на C2, но компьютер C2 гораздо быстрее соединился с сервером и сообщил ему событие E2. В итоге E2 попадет к серверу раньше, чем E1. Для того чтобы решить такую проблему, некоторые приложения записывают не время, когда событие произошло, а время, когда событие было получено сервером. Такой способ хоть и позволяет обойти одну проблему, но добавляет другую – теперь нельзя уверенно сказать о времени, когда произошло событие. Кроме времени регистрации события может использоваться какого-либо вида уникальный индекс, то есть событию соответствует не конкретное время, а уникальный порядковый номер.
  2. Модуль или подпрограмма, в которой произошло событие. Есть, конечно, отдельные продукты, которые совершенно монолитны и все их логи принадлежат единому и единственному модулю, но более распространенная ситуация — это наличие в продукте нескольких модулей, каждый из которых совершенно независимо умеет писать информацию в лог-файл. Часто бывает так, что в этих модулях могут происходить одни и те же события. Для того чтобы различать события, которые произошли в каждом конкретном модуле, в лог-файл добавляется указание модуля, в котором событие произошло. К этой же группе можно отнести и обычную практику Linux Syslog, когда в лог заносится информация как о названии процесса, в котором произошло событие, так и о его PID (process ID). При наличии нескольких копий одного и того же приложения необходимо точно знать, в каком из них произошло событие.
  3. Информация о том, кто является источником события, очень важна
    Информация о пользователе. Большая часть логов, так или иначе, содержит информацию о том, какой пользователь совершил то или иное действие. С точки зрения безопасности такая информация, несомненно, очень важна. Следует учитывать нюанс: логирующая программа не видит того, кто реально является источником события, а может узнать эту информацию одним из нескольких способов: считать информацию о пользователе, с учетной записью которого был выполнен вход в систему; определить пользователя, с чьими правами было запущено приложение, и т. п. Все эти способы сами по себе недостоверны, так как основаны на предположении, что пользователь не поделился с кем-то информацией о своей учетной записи. Часть событий вообще не может быть отнесена к какому-то конкретному пользователю, так как событие происходит до того, как пользователь зарегистрировался (авторизовался) в системе: к примеру, событие bad password attempt, которое не указывает, какой пользователь пытался войти в систему, потому что не знает, что это был за пользователь. Кроме того, следует помнить, что большинство сервисов запускаются не от того пользователя, с чьей учетной записью был выполнен вход в систему, а от имени специального пользователя, который имеет специальные (и часто ограниченные конкретными задачами) права. В таком случае все логирование внутренних операций приложения будет содержать информацию о специальной учетной записи, в отличие от событий, которые вызваны конкретными действиями пользователя, который в данный момент зарегистрирован в системе. Указанный в логах пользователь может быть как объектом, так и субъектом действия, которое указано в логе.

    Единственная сложность, которая возникает с трактовкой пользовательской информации в логах, — это если в логе содержится не полное имя пользователя (с указанием, к примеру, полного имени и принадлежности к конкретному домену или группе), а ID пользователя или только часть имени (к примеру, только фамилия). В первом случае (ID) сложность в том, что бывает довольно трудно понять, где же брать информацию о соответствии определенного ID и реального имени пользователя. Сейчас большая часть приложений легко интегрируется со всяческими базами данных и Directory Services (MS Active Directory, Novell e-Directory и т. п.), поэтому информацию о непонятных ID и именах следует начинать расшифровывать именно оттуда. Единственная сложность — это то, что пользователь может принадлежать какому-то одному из имеющихся хранилищ в сети, а еще такой пользователь может (с незначительной разницей или без нее) присутствовать на нескольких сервисах в сети. В этом случае задача того, кто анализирует логи, — разобраться в том, кто из пользователей реально причастен к конкретному действию. Для описания такой ситуации вводят понятие "пространство имен" (Namespace), которое используется приложением.

  4. Каждое событие имеет свой уникальный идентификатор либо однозначно может быть описано каким-либо еще образом
    Уникальный идентификатор события. Очевидно, что конкретное событие в системе должно уникальным образом (по возможности) описываться в системе. Для этого различные системы логирования используют несколько различных способов (которые, впрочем, сводятся к одной и той же идее). Первый способ — это присвоение каждому уникальному событию его уникального идентификатора, то есть целиком событие определяется конкретным ID. Обычно это или численное обозначение (к примеру, Symantec Antivirus в своих логах использует тег LI_EVENT, который может быть равен численному значению; LI_EVENT = 5 означает то, что антивирус обнаружил вирусное заражение), или какая-либо цифробуквенная аббревиатура. Довольно часто используется и та и другая форма. Это делает информацию более понятной — для события с ID = 5 у Symantec есть еще и вот такое обозначение: GL_EVENT_INFECTION. Сами производители программного обеспечения довольно охотно (за редким исключением) делятся информацией о том, какие события как обозначаются и как логируются. Такая информация обычно присутствует в документах, которые описывают администрирование и/или конфигурирование приложения (впрочем, нередко бывают и отдельные документы с описанием системы логирования). Если вернуться, к примеру, с Symantec Antivirus, то компания Symantec такую информацию предоставляет на форумах поддержки (впервые такого рода информацию опубликовали именно там в качестве ответа на вопросы пользователей) и в официальной документации. Второй способ — это когда конкретных событий в системе нет, а есть набор модулей, которые могут быть субъектом или объектом действия (Object), и есть сами действия (Action). Сочетание объекта и действия дает информацию о том, что в действительности произошло в системе. Такой способ несколько более гибок, но в то же время информация в некоторые моменты может быть противоречивой (к примеру, встречаются сочетания "объект+действие", смысл которых с трудом можно представить, если не знать подробные описания системы логирования). Примером такого способа логирования служит Sun Java System Identity Manager. На самом деле если предположить, что общее количество событий в системе будет равно "количество Object" x "количество Action", то становится понятно, что их все можно описать порядковыми номерами, то есть ID события. Хотя многие такие сочетания не будут иметь особого смысла.
  5. Кто? Куда? И откуда? Три вопроса, на которые важно иметь ответы
    Информация о том, на каком компьютере произошло событие. Такая информация не очень сильно важна в том случае, если компьютер не подсоединен к сети или никак с ней не взаимодействует, но в корпоративной сети цены нет такой информации. Идеальным случаем является полное описание трех компьютеров, которые участвуют в каждом действии в сети (пусть даже в большинстве случаев все три они будут одним и тем же). Следует понимать, что действие могло быть предпринято в отношении совершенно другой машины. Причем действие могло быть предпринято с иного компьютера, то есть имеются:

    • компьютер, на котором произошло действие;
    • собственно компьютер, который был подвержен действию;
    • компьютер, который был инициатором действия.
    Описать ситуацию, когда все три компоненты являются отдельными компьютерами, довольно легко: достаточно вспомнить соединение компьютера к серверу в Интернете через корпоративный шлюз. В этом случае действие происходит на шлюзе, инициирует его клиент в сети, а целью является сервер в Интернете. В силу того что сейчас довольно широко практикуется динамическая раздача сетевых адресов, обычно в логи заносится как имя компьютера, так и его IP-адрес. Это позволяет избежать поисков компьютера, который в такой-то момент имел определенный адрес и на котором произошло определенное событие.
  6. В случае базы данных лог может включать информацию о той транзакции, которая вызвала конкретное событие. Поэтому логи баз данных довольно часто используются для отладки скриптов, которые пишутся для работы с базой. Логирование всех подряд транзакций отрицательно сказывается на скорости работы, особенно в том случае, если сообщение содержит полный код SQL-запроса, который был выполнен.
  7. Информация об объектах и атрибутах, которые были вовлечены в действие. Чаще всего это модификация каких-то данных, файлов, атрибутов, прав доступа и т. п. Объектом действия в системе может быть все что угодно: начиная от файла или его свойств и до специфичных системных объектов, представляющих какие-либо абстрактные данные. Имя объекта, которое присутствует в логе, для человека, который хорошо знает специфику системы и ее внутренности, мгновенно говорит о том воздействии (и целях этого воздействия), которое было оказано на систему. В случае если событие описывает изменение некоего состояния системы, очень важной оказывается информация о состоянии системы до и после выполнения действия.
  8. Информация о статусе (результате) события. Тут все производители практически единодушны: бывает Success (успешное завершение) либо Failure (ошибка). В некоторых случаях может существовать еще пара таких классов, как: Unknown – статус неизвестен; Info – для такого события нельзя определить успешность его выполнения и Warning – статус неизвестен, но следует обратить внимание на это событие. Вообще говоря, встречаются и другие варианты, но все они очень схожи по смыслу. Тонкий момент: успешное (Success) событие не значит, что событие разрешено с точки зрения безопасности, так как, к примеру, успешный доступ к сети пользователя, который не имеет прав на это, — это очень важное событие, которое не должно быть упущено. С точки зрения безопасности оно как раз и не Success, а Failure системы безопасности.

Успешное завершение события далеко не означает его полезности для системы. Берегитесь!
Успешное изучение информации, которая попадает в логи, напрямую зависит от уровня знаний системы, в которой происходят события. Глубокие знания в предметной области, дополненные подробными и информативными логами соответствующих приложений, могут очень серьезно помочь в решении проблем, которые неизбежно возникают при организации работы систем любого уровня. Следует отметить, что стремление производителей ПО к наибольшей информативности логов должно ими же разумно ограничиваться критериями экономии ресурсов, иначе логи могут стать никому ненужным трактатом, который полезен только в качестве украшения.



Скоро на сайте

  • Wordpress

    Серия статей о плагинах к движку WordPrress
  • AJAX

    Проекты и продукты, ориентированные на AJAX
  • Новые сервисы Google

    Обзор новых сервисов Google
 

Copyright © 2003—2018 Все права защищены

При использовании материалов сайта ссылка на hostinfo.ru обязательна

  • хостинг от .masterhost
  • Rambler's Top100