Отслеживание сообщений в логах Exchange 2013 - быстро и легко!

Отслеживание сообщений в логах Exchange 2013 - быстро и легко!

Огромная масштабируемость системы Exchange кроме всех своих преимуществ, несет в себе и большие минусы. Один из таких минусов - сложность в отслеживании почтовых сообщений в логах. Ведь имея несколько транспортных серверов (не дай Бог еще и объединенных в DAG), мы получаем ситуацию, когда письмо проходит через все сервера и оставляет свой след в логах на каждом.

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

Принципиальную схему пути сообщения (Exchange 2013 Mail Flow / Transport Pipeline) описывает данный рисунок:

 Exchange 2013 Mail flow and Transport pipeline

Отслеживание писем в Exchange 2013

Мой подход к отслеживанию сообщений в Exchange вот такой:

  1. Получаем ID нужного письма с помощью Get-MessageTrackingLog.
  2. С помощью Log Parser 2.2 получаем детальный лог по конкретному письму.

Почему нельзя использовать только Get-MessageTrackingLog (ведь он умеет достаточно быстро искать по логам сразу на нескольких серверах)? У Get-MessageTrackingLog есть только одна неприятная особенность: в результатах он отдает записи из логов с некоторой временной меткой (TimeStamp), так вот коммандлет отдает эту метку с точностью до секунды, хотя в текстовых логах хранится время с точностью до тысячной секунды. Так вот многие операции происходят в течение одной единственной секунды, и из-за этого невозможно выстроить хронологию событий.

Именно поэтому мы будем обрабатывать логи через Log Parser 2.2. Это унивесальный парсер логов от Microsoft, который работает с языком SQL в качестве запросов.

Ищем письма с помощью Get-MessageTrackingLog

В составе Exchange 2013 есть замечательный коммандлет Get-MessageTrackingLog. Он позволяет найти нужное сообщение с использованием параметров в качестве фильтра. Самое подробное описание фильтрующих параметров смотрите вот тут: https://technet.microsoft.com/en-us/library/aa997573(v=exchg.150).aspx.

Вот пример, как использовать Get-MessageTrackingLog для поиска MessageId:

Использование Get-MessageTrackingLog для поиска MessageId

Скопируем MessageId и двигаемся дальше.

Пользуемся Log Parser 2.2 и Log Parser Studio

Во-первых нам нужно установить Log Parser 2.2 и Log Parser Studio (GUI для Log Parser 2.2). Вот ссылки:

Устанавливаем обе программы и запускаем Log Parser Studio - LPS.exe.

Указываем пути, откуда брать логи (полезная статья на эту тему: Перемещаем логи Exchange 2013 из папок по умолчанию с помощью Powershell):

Настройка Log Parser Studio

Обратите внимание: указываем логи сразу с двух серверов (если их два)!

Далее создаем новый запрос и устанавливаем тип лог-файлов - EELLOG. Сортировка - по времени.

SELECT * 
FROM '[LOGFILEPATH]'
WHERE message-id = '<MessageId>'
ORDER BY [#Fields: date-time]

Выполняем запрос и получаем результат:

Анализ логов Exchange 2013 в Log Parser Studio

Анализ лога

Теперь вы можете просмотреть, какой путь прошло письмо, и возможно, найдете причину сбоев. В большинстве случаев вам понадобятся следующие поля:

  • client-ip
  • client-hostname
  • server-ip
  • server-hostname
  • connector-id
  • source
  • event-id

Последние два упомянутых поля source и event-id - говорят о том, какие действия выполнялись с письмом. Помощь в анализе этих полей вы можете получить в этой статье:

https://technet.microsoft.com/en-us/library/bb124375(v=exchg.150).aspx 

https://technet.microsoft.com/ru-ru/library/bb124375(v=exchg.160).aspx (по-русски)

Для вашего и своего удобства привожу самые полезные сведения тут.

Возможные значения поля event-id

Имя событияОписание

AGENTINFO

Это событие используется агентами транспорта для журналирования пользовательских данных.

BADMAIL

Сообщение отправлено каталогом раскладки или каталогом преобразования и не может быть доставлено и возвращено.

CLIENTSUBMISSION

Сообщение было отправлено из папки "Исходящие" почтового ящика.

DEFER

Доставка сообщения отложена.

DELIVER

Сообщение было доставлено в локальный почтовый ящик.

DSN

Создано уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).

DROP

Сообщение было отклонено без уведомления о доставке (также называемого сообщением возврата или отчетом о недоставке). Например:

  • сообщения о выполненных запросах для утверждения;

  • нежелательные сообщения, удаленные автоматически без отчета о недоставке.

DUPLICATEDELIVER

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

DUPLICATEEXPAND

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

DUPLICATEREDIRECT

Альтернативный получатель сообщения уже являлся получателем.

EXPAND

Была расширена группа рассылки.

FAIL

Не удается доставить сообщение. Источники: SMTP, DNS, QUEUE и ROUTING.

HADISCARD

Теневое сообщение было отвергнуто, после того как основная копия была доставлена на следующий узел. Подробнее см. в разделе Теневая избыточность.

HARECEIVE

Теневое сообщение было получено сервером в локальной группе обеспечения доступности баз данных или на сайте Active Directory.

HAREDIRECT

Создано теневое сообщение.

HAREDIRECTFAIL

Не удалось создать теневое сообщение. Сведения сохранены в поле source-context.

INITMESSAGECREATED

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

LOAD

Сообщение успешно загружено при загрузке.

MODERATIONEXPIRE

Модератор контролируемого получателя не утвердил и не отклонил сообщение, поэтому для него истек срок ожидания. Дополнительные сведения о контролируемых получателях см. в разделе Управление утверждением сообщений.

MODERATORAPPROVE

Модератор контролируемого получателя утвердил сообщение, поэтому оно было доставлено контролируемому получателю.

MODERATORREJECT

Модератор контролируемого получателя отклонил сообщение, поэтому оно не было доставлено контролируемому получателю.

MODERATORSALLNDR

Все запросы для утверждения, отправленные всем модераторам контролируемого получателя, не могли быть доставлены и привели к отправке отчетов о недоставке (также называемых сообщениями возврата).

NOTIFYMAPI

Сообщение было обнаружено в папке "Исходящие" почтового ящика на локальном сервере.

NOTIFYSHADOW

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

POISONMESSAGE

Сообщение помещено в очередь сообщений о сбое или удалено из нее.

PROCESS

Сообщение успешно обработано.

RECEIVE

Сообщение было получено компонентом получения протокола SMTP службы транспорта или из каталога раскладки или каталога преобразования (источник: SMTP), или сообщение было отправлено из почтового ящика в службу отправки почтовых ящиков (источник: STOREDRIVER).

REDIRECT

Сообщение было перенаправлено другому получателю в результате поиска в Active Directory.

RESOLVE

В результате поиска в Active Directory для получателей сообщения был найден другой адрес электронной почты.

RESUBMIT

Сообщение было автоматически повторно отправлено из сети безопасности. Подробнее см. в разделе Система безопасности.

RESUBMITDEFER

Сообщение, повторно отправленное из сети безопасности, было отложено.

RESUBMITFAIL

Сообщение, повторно отправленное из сети безопасности, не удалось отправить.

SEND

Сообщение было отправлено протоколом SMTP между службами транспорта.

SUBMIT

Служба отправки почтовых ящиков успешно передала сообщение службе транспорта. Для событий SUBMIT свойство source-context содержит следующие данные:

  • MDB   GUID базы данных почтовых ящиков.

  • Mailbox   GUID почтового ящика.

  • Event   Порядковый номер события.

  • MessageClass   Тип сообщения. Например, IPM.Note.

  • CreationTime   Дата и время отправки сообщения.

  • ClientType. Примеры: User, OWA и ActiveSync.

SUBMITDEFER

Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта была отложена.

SUBMITFAIL

Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта не была выполнена.

SUPPRESSED

Передача сообщения была отменена.

THROTTLE

Сообщение было отрегулировано.

TRANSFER

В результате преобразования содержимого, ограничения числа получателей или работы агентов получатели были перемещены в сообщение с ветвлением. Источники: ROUTING или QUEUE.

 

Возможные значения поля source

Значение источникаОписание

ADMIN

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

AGENT

Источником события был агент транспорта.

APPROVAL

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

BOOTLOADER

Источником события были необработанные сообщения, которые присутствовали на сервере на момент загрузки. Это относится к типу событий LOAD.

DNS

Источником события было DNS.

DSN

Источником события было уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).

GATEWAY

Источником события был внешний соединитель. Подробнее см. в разделе Внешние соединители.

MAILBOXRULE

Источником события было правило для папки "Входящие". Дополнительные сведения см. в статье Правила для папки "Входящие" в Outlook Web App.

MEETINGMESSAGEPROCESSOR

Источником события был обработчик сообщения о собрании, который обновляет календари в соответствии с обновлениями собрания.

ORAR

Источником события был альтернативный получатель, запрошенный отправителем (ORAR). Вы можете включить или отключить поддержку ORAR на получающих соединителях, используя параметр OrarEnabled в командлете New-ReceiveConnector или Set-ReceiveConnector.

PICKUP

Источником события был каталог раскладки. Подробнее см. в разделе Каталог раскладки и каталог преобразования.

POISONMESSAGE

Источником события был идентификатор сообщения о сбое. Дополнительные сведения о сообщениях о сбое и очереди сообщений о сбое см. в разделе Queues and messages in queues

PUBLICFOLDER

Источником события была общедоступная папка, поддерживающая почту.

QUEUE

Источником события была очередь.

REDUNDANCY

Источником события было избыточное теневое копирование. Подробнее см. в разделе Теневая избыточность.

ROUTING

Источником события был компонент разрешения маршрутизации классификатора в службе транспорта.

SAFETYNET

Источником события была сеть безопасности. Подробнее см. в разделе Система безопасности.

SMTP

Сообщение было отправлено компонентом отправки или получения SMTP службы транспорта.

STOREDRIVER

Источником события была MAPI-отправка из почтового ящика на локальном сервере.

 

 

exchange (ru), exchange 2013 (ru)

  • Просмотров: 54625
Добавить комментарий

Комментарии  
Вопрос
#
Здравствуйте, классная статья!
Я думал что строка "STOREDRIVER-DELIVER" - по своей сути окончательна в пути письма и означает что письмо доставлено до Почтовой транспортной службы и будет записано в БД.
Но после идет строка: "SMTP -SEND" и судя по коннектору, это отправляющий соединитель SMTP Intra-Organization в Транспортной службе.
Можете пожалуйста пояснить что происходит после STOREDRIVER - DELIVER и почему после него идет SMTP - SEND?
Проводил подобный анализ на своем Exchange, у меня схожий лог и таже последовательность...
Ответить | Ответить с цитатой | Цитировать
RE: Отслеживание сообщений в логах Exchange 2013 - быстро и легко!
#
Привет (давайте "на ты :-)")!

К сожалению, уже не могу на 100% точно сказать, т.к. уже не работаю в компании, где был Exchange :).

Но на 99.999% - это особенность работы отказоустойчивости транспортных серверов. К сожалению, у меня на скриншоте замазаны поля client-ip и server-ip, но практически уверен, что там указаны ip-адреса двух моих (или ваших:)) mailbox-серверов.

Кстати, если обратите внимание, то время событий SMTP -SEND и STOREDRIVER-DELIVER одинаковое с точностью до милисекунды.
Ответить | Ответить с цитатой | Цитировать
Обновить список комментариев

Related Articles