Æóðíàëû

Какие журналы ведутся на сервере и каково их назначение?

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

·	SMTP.LOG - здесь записываются события, происходящие в SMTP сессиях. SMTP используется почтовыми клиентами и другими серверами для отправки почты

·	Session.LOG - здесь записывается содержание сессий, для которых установлена опция записи "Запись сессий" ("Log Sessions") в разделе "Опции > Журналы" ("Options > Logs") на закладке "Параметры" ("Parameters").

·	Control.LOG - здесь записываются события, происходящие в сессиях управляющего протокола. Управляющий протокол используется Конфигуратором для настройки сервера.

·	PCP.LOG - здесь записываются события, происходящие в PCP сессиях. PCP (Password Change Protocol) используется для изменения пароля пользователя. Это протокол поддерживается почтовым клиентом The Bat.

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

·	DrvErr.LOG - здесь записываются события, связанные с ошибками в работе драйвера доступа к данным. Они также требуют пристального внимания, так как скорее всего связаны с ошибками в драйвере доступа к данным или с повреждением баз.

·	Dialup.LOG - здесь записываются события, связанные с работой dial-up ("звонилки"). Если для доступа к Интернету используется телефонная линия, то здесь будут события связанные с установлением и разрывом телефонного соединения.

Для чего нужны журналы исключительных ситуаций?

Исключительная ситуация чаще всего сигнализирует об ошибке в какой-то из компонент сервера. При возникновении исключительной ситуации создается журнал вида

Так, например, если исключение возникло в модуле BatPost.exe, то будет создан журнал

Искать эти журналы для большинства компонент нужно в папке

Для драйвера доступа к данным этот журнал будет в папке

Значение переменной %allusersprofile% зависит от системы. Так, например, в Windows XP она обычно имеет значение

Для того, чтобы узнать ее значение в вашей системе, нужно выдать с командной строки:

Эти журналы позволяют разработчикам более точно понять причину и место возникновения ошибки. Поэтому, сообщая разработчикам об ошибке, очень важно приложить к обращению соответствующий журнал.

Журналы очень быстро увеличиваются в размерах. Что с этим можно сделать?

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

Для того, чтобы избежать этих ситуаций, сервер поддерживает автоматическое разбиение и чистку журналов. Настраивается это в разделе "Опции > Журналы" ("Options > Logs") на закладке "Разбиение/Очистка" ("Splitting/Purging"). При разбиении создается отдельный файл в имени которого присутствует дата к которой он относится. Так, например, при разбиении POP.LOG может быть создан файл

который относится к 2008 году 06 месяцу (июнь) и 02 дню. Такой порядок указания даты позволяет при сортировке по имени файлов получить список файлов, упорядоченный по дате к которой они относятся.

Журналы можно разбивать на части: ежедневно, еженедельно или при достижении заданного размера. Если журнал растет не слишком быстро, то вполне подойдет еженедельное разбиение, для быстрорастущих журналов (например, SMTP.LOG) больше подойдет ежедневное разбиение.

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

Какой программой лучше просматривать журналы?

Монитор можно использовать для просмотра последних записей в основных журналах. Этого достаточно для оценки текущей работы сервера, но для более серьезной работы нужно работать напрямую с файлами журналов. Для этого подойдет любая программа умеющая быстро просматривать большие файлы и имеющая функцию поиска строк. Такую возможность предоставляют многие файловые менеджеры (Far, Total Commander), а также некоторые текстовые редакторы. Файловый менеджер в этом плане более предпочтителен, так как позволяет видеть все файлы журналов, искать в нескольких файлах и исполнять команды из командной строки.

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

Прежде всего нужно определиться с ключевой фразой, которая поможет нам найти нужное. Так, например, если мы ищем нечто связанное с пользователем "user@example.com", то это и будет нашей ключевой фразой.

Далее нужно определиться к какой дате относится разыскиваемое событие. Если используется разбиение журналов, то можно будет сосредоточиться на журналах, относящихся к этой дате. Иногда бывает, что точная дате неизвестна - в этом случаем мы можем воспользоваться поиском по нескольким файлам. Например, мы можем искать в папке "Logs" указав файловую маску "*.*", чтобы искать по всем файлам или указать маску "SMTP*.*", чтобы искать только в файлах относящихся к SMTP протоколу.

Когда ключевая фраза найдена, нас обычно интересуют события относящиеся к той же сессии. Вот как выглядит типовая POP сессия:

+ 03 Jun 2008 17:38:01 [gURXxDAAAgA] User test <test@test.com> logged on (Plain-text)

* 03 Jun 2008 17:38:01 [gURXxDAAAgA] Session finished with localhost [127.0.0.1]

Можно заметить, что все записи имеют одинаковый уникальный идентификатор (ID) сессии. В данном случае это "gURXxDAAAgA". Этот идентификатор можно использовать как путеводитель для поиска записей данной сессии. В простых случаях это можно сделать визуально, в случае же когда записи разных сессий сильно перемешаны можно выполнить из командной строки команду:

для вывода строк сессии "gURXxDAAAgA" прямо на экран, либо команду:

Замечание. По умолчанию утилита grep может отсутствовать в Вашей системе. Изначально она была создана для UNIX и в Windows отсутствует. Однако ее можно скачать в составе пакета UnxUtils с сайта http://unxutils.sourceforge.net

Пакет распространяется в виде zip-архива, который нужно разархивировать в какую-то папку на вашем диске (например, C:\UnxUtils). После этого эту папку желательно добавить в переменную окружения PATH, чтобы доступ к утилитам был возможен из любого места.

Как проследить прохождение письма через сервер?

При попадании на сервер каждому письму присваивается уникальный идентификатор (ID). Не следует путать его с уникальным идентификатором сессии, специально для этого они имеют различный вид. Этот идентификатор можно увидеть в журналах везде где происходит обращение к сообщению. Вот как это может выглядеть в журнале SMTP.LOG:

> 02 Jun 2008 17:05:45 [g0Q9fIAAAAA] Message 4843FD8700000001 (4438 bytes) received

здесь 4843FD8700000001 - это уникальный идентификатор присвоенный принятому сообщению.

А вот как это может выглядеть в журнале POP.LOG при прочтении и удалении того же сообщения:

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) was read

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) marked as deleted

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) permanently deleted

Также этот идентификатор прописывается в заголовке самого сообщения в поле Received:

Поле Received обычно прописывается каждым сервером, через который проходило письмо, поэтому нужно найти среди них то, которое было прописано сервером BatPost.

Поскольку уникальный идентификатор прописывается в журналах при каждом действии с данным письмом, можно проследить жизненный цикл письма на сервере. Так в журнале SMTP.LOG можно найти запись о том, как письмо было принято на сервер, а в журнале POP.LOG (или IMAP.LOG) - запись о том как оно было прочитано пользователем и, возможно, удалено.

Если из поля Received в заголовке письма известен идентификатор сообщения, то можно произвести поиск по всем журналам, чтобы найти все записи относящиеся к данному сообщению и получить полное представление о том, что происходило с данным сообщением на сервере.