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

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

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

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

Логирование информации
Часть 1. Типы логов*. Конфигурирование логирования информации.

Естественной потребностью системного администратора или специалиста по безопасности является некий анализ того, что происходит как на конкретном компьютере конкретного пользователя, так и в локальной сети. Технически задача выполнима, ибо разработчики множества приложений, которыми мы пользуемся, заложили в свои продукты функцию логирования информации*. Информация, которую хранят логи* конкретного компьютера в сети, может сказать много тому, кто, с некоторым знанием предмета, рискнет заглянуть внутрь. Нельзя сказать, что чтение логов* является тайной дисциплиной, которая доступна только просвященным гуру, впрочем, для того, чтобы легко ориентироваться и четко сопоставлять информацию, которая встречается в логах* различных приложений, надо действительно иметь представление о том, что и как, почему и зачем пишется в логи*, а кроме того, четко представлять предметную область изучаемого ПО. Дело в том, что запись информации в логи* (вероятно, в силу некой меньшей приоритетности, чем работа самого приложения) страдает хаотичными веяниями различных производителей. Соответственно, и интерпретировать такую информацию надо с учетом специфики и, может быть, каких-то рекомендаций производителя.

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

Типы логов* (механизмы логирования информации*)

  1. Текстовые логи* самые простые для понимания
    Самый простой и потому самый распространенный способ — это логирование в текстовый файл. Способ, при котором отдельное событие представляет собой отдельную строку. Используется очень часто. Например, известный Symantec Antivirus или Linux Syslog. Способ хорош как с точки зрения реализации – довольно легко наладить такое логирование в коде большинства языков программирования, — так и со стороны использования – читать такой лог можно любым текстовым редактором.
  2. Чуть более сложный случай – логи*, в которых отдельное событие представляет собой не одну строку, а несколько. С некоторым допущением к этому же типу относятся логи*, которые пишутся в формате XML (либо сходных с ним форматах данных). Такой лог гораздо более сложен для анализа, потому что каждое событие может представлять собой набор более мелких записей. Для чтения таких логов чаще всего используется какое-то специально ПО, так как лог, в котором каждое событие растянуто на несколько строк, а еще и сами события зависят друг от друга, довольно тяжело интерпретировать.
  3. Бинарный лог* представляет собой самый нечитаемый тип логов. Для того чтобы с ними работать, нужна специальная программа (обычно от того же производителя, что и приложение, которое пишет такой лог), с помощью которой бинарный лог и анализируется. Обычно бинарный лог — это последовательно сбрасываемые в файл структуры, которые разделяются символом-разделителем. Обрабатывать такой лог очень тяжело, впрочем, довольно часто в технической информации, которую предоставляет производитель, есть описание структуры такого лога. Довольно показательный пример — это бинарные логи HP Tru64 UNIX (Audit Logs). Каждый такой лог — это набор полей различной длины (как фиксированной, так и произвольной, что серьезно усложняет работу). Перед началом каждого поля стоит тег, который идентифицирует информацию, которая содержится в данном поле, за тегом следует некоторое количество байт информации, потом следующий тег и так далее.

    Отдельное событие в бинарном логе

    Тег AB означает начало отдельной записи-события, за ним следуют четыре байта, которые обозначают тип события (A5 00 00 00). Точно таким же образом обозначается и конец записи. Если говорить о логах HP Tru64 UNIX, то их бинарный формат довольно сложен, так как последовательность "тег, а за ним четыре байта информации" выполняется только для самых основных полей, таких как ID события, UID пользователя, который совершил событие, и т. п. А вот поля, в которых размер данных слабо предсказуем, имеют произвольную длину, то есть их формат — "тег, а за ним несколько байтов информации". Информация — это обычно полное имя пользователя, имя компьютера и текстовое описание события, то есть информация, которая может быть произвольной и непредсказуемой длины.

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

  4. Приложения, которые используют базы данных либо сами являются СУБД, довольно часто используют базу данных в качестве хранилища логов*. В большинстве своем это отдельная таблица базы данных, каждая строка которой является отдельным событием. Такое логирование часто может отрицательно сказаться на общей производительности базы данных, так как логирование в базу данных может быть довольно интенсивным (к примеру, MS SQL Server 2000/2005 успевает в C2 Audit логи писать несколько десятков записей в секунду). Естественно, что все зависит от того, как сконфигурировано приложение. Впрочем, некоторые производители предупреждают о возможных проблемах вне зависимости от конфигурации, обычно это предупреждение является перестраховкой, так как всегда есть возможность подобрать конфигурацию системы аудита, которая будет не слишком обременительной. Кстати, использование базы данных для логирования информации*, касающейся транзакций и безопасности, ничуть не отменяет того, что остальные сервисы, входящие в СУБД, могут иметь файловые логи.

Конфигурирование логирования

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

Интенсивное логирование может серьезно повлиять на производительность системы
Довольно часто либо логирование выключено полностью, либо инсталляционная программа потребует точных указаний о том, что делать с логированием. Если есть подозрение, что логирование будет довольно интенсивным, то следует заранее задуматься о том воздействии, которое логирование будет оказывать на систему. Кроме самого простейшего случая, когда логирование может быть или включено, или выключено, приложения часто предоставляют куда более настраиваемые и удобные средства управления. Типичные функции таковы.
  1. Имя файла, директория или полный путь к тому файлу, в который пишется лог*. Это очень полезно, если логирование необходимо и есть возможность или необходимость организовать запись логов на отдельный жесткий диск, сетевой диск и т. п. Такой способ удобен, если логи будут интерпретироваться сторонним приложением, которое находится на отдельном компьютере и каким-либо образом может повлиять на работу основной системы.
  2. Критерий замены лога (Log Rotation). Рано или поздно логи становятся большими или их становится слишком много. Чтобы избежать проблем, которые с этим связаны (постоянная работа с огромным файлом отрицательно сказывается на производительности системы), программы, осуществляющие логирование, обычно используют что-нибудь из следующего списка возможностей управления логами:
    • Каждый день (неделю, месяц и т. д.) система использует новый лог*-файл. Обычно если смена лог-файлов связана с каким-либо исчислением времени (каждый день, каждый год и т. п.), то в имени используется время (дата и время или только дата, иногда какая-нибудь производная) создания или финального закрытия (финализации) данного лог-файла. Если система использует уникальное имя (а имя с датой, временем или их производной можно считать уникальным, так как время монотонно возрастает), то такие логи обычно не очищаются системой. К примеру, Symantec Antivirus или Tivoli Access Manager for e-Business используют лог-файлы, которые хранят в своем имени время смены лог-файла. В множестве таких логов, которые, к примеру, скопились за долгое время, очень удобно искать информацию, относящуюся к конкретному промежутку времени. Кроме того, выработав критерий длительности хранения старых логов, довольно легко очищать уже устаревшие логи.
    • Смена файла происходит по достижении им определенного размера. Старый файл обычно сохраняется определенное время. Может быть, удаление старых файлов оставлено на решение пользователя, то есть в случае с файлами, которые хранят в своем имени дату и время, они могут храниться вечно, так как система не заботится о них, но пользователь в любой момент может решить, что старые файлы ему не нужны, и удалить их. В этом, кстати, дополнительное удобство — в имени файла хранится дата его создания, то есть всегда легко понять, нужен такой файл или нет. Имя файла может содержать порядковый номер этого лога, то есть каждая последующая смена увеличивает счетчик на единицу. Количество таких файлов тоже может быть произвольно, кроме того, они могут быть дополнительно заархивированы, что экономит некоторое место при длительном хранении. Типичным примером является Linux (UNIX) Syslog, который позволяет настраивать как размер файла, так и количество используемых файлов.
    • Смена файла происходит одновременно с перезапуском сервиса, который пишет лог*. Случай представляет собой некоторую опасность, так как в некоторых случаях сервис может не перезапускаться месяцами, а то и годами. Это приводит (точно-точно, такие случае не очень часты, но все равно бывают) к тому, что в определенный момент становится понятно, что лог-файл уже занимает огромное место на жестком диске, которое рациональнее использовать для чего-либо иного. Используется, к примеру, HP Tru64 UNIX (вообще говоря, HP Tru64 имеет некое ограничение на размер Audit Log, которые пишутся между перезапуском сервисов, но это ограничение довольно велико – около 300 Mб).
    • Частота сброса информации в файл. Такой параметр редко предоставляется для открытой модификации, но довольно часто он все же присутствует (к примеру, Tivoli Access Manager for e-Business). Он хорош тем, что при грамотной настройке несколько уменьшает число обращений к жесткому диску от логирующей программы, а плох тем, что, модифицировав его, довольно легко серьезно снизить производительность сервера.
  3. Набор событий, которые логируются, почти всегда можно настраивать. Это решает часть проблем с производительностью
    Набор событий, которые будут логироваться. Довольно часто важно иметь возможность настроить логирование только тех событий, которые реально необходимы. К примеру, часто нет необходимости логировать информацию обо всех транзакциях в базе данных, особенно если это куча select-запросов, которые, вероятно, не содержат угрозы с точки зрения безопасности. В таком случае можно изрядно снизить нагрузку на сервер, выключив логирование транзакций, но оставив учет только реально необходимых событий: попыток авторизации, попыток доступа к файлам, изменения системных настроек и т. п. Обычно производитель предоставляет свои профили логирования: от полного выключения и до полного логирования всего происходящего. Довольно часто есть возможность указать даже не профиль, а настройки логирования для каждого конкретного события (например, такая возможность есть в MS SQL Server C2 Audit). Такие настройки позволяют сделать очень гибкое логирование информации*, которая нужна в конкретном случае. Увы, но настройка логируемых событий встречается далеко не во всех программах.

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




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

  • Wordpress

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

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

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

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

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

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