Создание графических отчетов в Exchange 2007 (часть 1)

Создание графических отчетов в Exchange 2007 (часть 1)
Посетителей: 2842 \| Просмотров: 4173 (сегодня 0)	Шрифт:

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

Поскольку Exchange Server 2007 (и все предыдущие версии) не имеют штатной возможности генерирования графических отчетов, есть несколько компаний, которые успешно восполнили этот пробел, создав ПО отчетности для Microsoft Exchange (если вы хотите за него платить).

Что касается Microsoft, было выпущено программное обеспечение в 2005 году под названием SQL Server 2000 Report Pack for Microsoft Exchange, которое представляло собой урезанную версию Exchange Reporter, платной программы, созданной компанией под названием SSW. Должен признать, что никогда не использовал SQL Server 2000 Report Pack для Microsoft Exchange так как, давайте смотреть правде в глаза, требования SQL Server и SQL Server Reporting Services слегка завышены, если не сказать большего.

Однако в Microsoft проделали отличную работу, избрав другой подход. Microsoft Operations Manager (MOM) 2005 с Exchange Server Management Pack оснащен некоторыми мощными возможностями работы с отчетами. К сожалению, Exchange Server Management Pack для следующих версий программ управления от Microsoft, System Center Operations Manager (SCOM) 2007 не имеет некоторых ранее имевшихся отчетов. Хорошая новость заключается в том, что самая последняя версия Microsoft Exchange Server 2007 Management Pack for System Center Operations Manager 2007 R2 (снова) предоставляет более 30 видов отчетов специально для Exchange Server 2007, которые отслеживают доступность и производительность сервера.

Но когда я решил написать эту статью, я не собирался использовать коммерческую (платную) программу, а также не собирался использовать возможности отчетности программ управления системой. Вместо этого я решил обеспечить мощные возможности работы с отчетами для сервера Exchange, используя лишь простые и бесплатные продукты, некоторые программы от Microsoft, некоторые инструменты разработаны Microsoft MVP и просто энтузиастами по всему миру.

Все дело в логах!

Итак, я сказал, что сервер Exchange не имеет штатных средств создания графических отчетов, но это вовсе не означает, что он не генерирует всю информацию, которая вам необходима. Все дело в логах!

Вы знаете, как типы информационных логов доступны в типичной организации Exchange? В таблице 1 перечислены самые распространенные логи. Обратите внимание, что эти логи могут находиться на различных серверах Exchange, поскольку все роли Exchange, как правило, не располагаются на одной машине.

Таблица 1: Распространенные логи Exchange

Лог	Расположение по умолчанию
Логи протокола (SMTP отправка) (Protocol Logs (SMTP Send))	\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend
Логи протокола (SMTP получение) (Protocol Logs (SMTP Receive))	\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive
Логи агентов (Agent Logs)	\Exchange Server\TransportRoles\Logs\AgentLog
IIS Логи	[Windows 2003] \Windows\System32\LogFiles\W3SVC1 [Windows 2008] \Inetpub\Logs\LogFiles\W3SVC1
Логи отслеживания сообщений (Message Tracking Logs)	\Exchange Server\TransportRoles\Logs\MessageTracking
POP3/IMAP логи	\Exchange Server\ClientAccess\PopImap
Логи подключения (Connectivity Logs)	\Exchange Server\TransportRoles\Logs\Connectivity
Логи отслеживания каналов (Pipeline Tracing Logs)	\Exchange Server\Transport Roles\Logs\PipelineTracing
Логи таблицы маршрутизации (Routing Table Logs)	\Exchange Server\TransportRoles\Logs\Routing
MRM логи	\Exchange Server\Logging\Managed Folder Assistant

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

В этой статье мы будем использовать только первые пять логов из вышеприведенной таблицы. Из этих пяти только два лога не включены по умолчанию, и это логи протокола: SMTP отправка и SMTP получение. Уровень записи логов транспортировки SMTP управляется на уровне коннектора Exchange.

Чтобы создать полезный графический отчет Exchange, я бы сказал, что логи протоколов с серверов на границе вашей сети являются особенно важными, поскольку они регистрируют SMTP трансакции о почте, которая входит или исходит из вашей организации. Если у вас установлена роль пограничного транспортного сервера (Edge transport), и используется Edge синхронизация, эти логи можно настроить с внутреннего транспортного сервера- концентратора (Hub Transport) (если вы попытаетесь изменить свойства коннектора с пограничного транспортного сервера, вы получите сообщение об ошибке, как показано на рисунке 1).

Рисунок 1: Сообщение об ошибке изменения уровня записи лога на сервере Edge

Чтобы включить логи протокола SMTP для коннекторов EdgeSync Send Connectors, откройте консоль управления Exchange Management Console, разверните Конфигурацию организации (Organization Configuration), выберите Транспортный сервер-концентратор (Hub Transport), а затем, в правой панели, перейдите в закладку Коннекторы отправки (Send Connectors). Правой клавишей нажмите на каждом из двух коннекторов отправки и выберите Свойства (Properties) (рисунок 2).

В окне свойств коннектора EdgeSync измените значение для Уровень ведения журнала протокола (Protocol logging level) на Подробно (Verbose) (рисунок 3).

Увеличить

Рисунок 2: Настройка коннектора отправки EdgeSync

Рисунок 3: Свойства коннектора отправки EdgeSync

Если вы предпочитаете использовать командную оболочку PowerShell, то выполните следующую команду (для обоих коннекторов), чтобы задать подробный уровень ведения журналов протокола (рисунок 4):

Set-SendConnector "EdgeSync - Inbound to Default-First-Site-Name" -ProtocolLoggingLevel Verbose

Увеличить

Рисунок 4: Смена уровня ведения журнала с помощью PowerShell

После включения логов транспортировки SMTP нам нужно определить количество сохраняемых данных истории. Сервер Exchange позволяет нам контролировать максимальный размер журнала, максимальный размер каталога и максимальный возраст файлов журнала, используя команду Set-TransportServer PowerShell.

Параметры SendProtocolLogMaxDirectorySize и ReceiveProtocolLogMaxDirectorySize указывают максимальный размер каталогов журналов протоколирования коннектора отправки и получения. По достижении максимального размера каталога сервер в первую очередь удаляет самые старые журналы. Минимальное значение составляет 1 МБ, значение по умолчанию составляет 250 МБ.

Поскольку значения по умолчанию в 250МБ не достаточно, давайте изменим максимальное значение размера каталога для коннекторов отправки на 2ГБ, а каталогов журнала для коннектора получения на 4ГБ, используя Exchange Management Shell:

Set-TransportServer -Identity E2K7EDGE -SendProtocolLogMaxDirectorySize 2048MB -ReceiveProtocolLogMaxDirectorySize 4096MB

Теперь, когда наши журналы готовы, пришло время анализировать их.

Следует учитывать, что в зависимости от объема данных, которые вы анализируете, обработка и анализ журналов может занять некоторое время!

Анализатор журналов

Анализатор журналов (Log Parser) представляет собой мощный инструмент, который предоставляет универсальный доступ запроса таких текстовых данных, как файлы журналов, XML файлы и CSV файлы, а также такие ключевые источники данных операционной системы Windows, как журнал регистрации событий (Event Log), системный реестр, файловая система или даже Active Directory. Но помимо анализа информации Log Parser предоставляет возможность самостоятельно форматировать результаты запросов в текстовые файлы, такие как сетки данных, или преобразовывать их в удобные визуальные схемы.

Не знаю, как вы, но, на мой взгляд, это вполне достойный кандидат на создание графических отчетов из этих журналов Exchange. К тому же, Log Parser не нужно устанавливать на сервер Exchange, вам нужно предоставить ему доступ к каталогам журналов в Exchange.

Следуйте этим инструкциям для установки Microsoft Log Parser:

Загрузите и установите Microsoft Logparser 2.2.
Загрузите и установите Office 2003 Add-in: Office Web Components. Эти компоненты необходимы для обеспечения графических возможностей для Log Parser.
Загрузите и установите Microsoft Office 2003 Web Components Service Pack 1 (SP1) для 2007 Microsoft Office System.

Log Parser содержит полномасштабный файл справки и поддержки (рисунок 5), по умолчанию расположенный в C:\Program Files (x86)\Log Parser 2.2, с которым я настоятельно рекомендую тщательно ознакомиться. Здесь также есть несколько примеров в C:\Program Files (x86)\Log Parser 2.2\Samples.

Рисунок 5: Log Parser CHM файл

В следующем разделе я покажу вам некоторые примеры запросов Log Parser, которые генерируют нужные визуальные отчеты. Эти запросы можно выполнять непосредственно из командной строки, или же можно создать различные файлы командных сценариев для каждого из них (рекомендуется).

Отчеты в Log Parser из журналов агентов

Если вы используете агентов антиспама в сервере Exchange, существует несколько отчетов, которые можно получить, проанализировав журналы агентов (Agent Logs). Эти журналы расположены на сервере Exchange Edge, если вы используете его, или на сервере Exchange Hub, если агенты антиспама включены и работают на этой роли сервера.

Чтобы получить картину почты, входящей в вашу организацию, можно начать с организации количества сообщений в соответствии с их уровнем вероятности спама (Spam Confidence Level – SCL) и отобразить их в сетке данных.

Вот как выглядит команда, создающая эти сетки данных (рисунок 6):

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT ReasonData, count(*) AS hits FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\AgentLog\AGENT*.log WHERE ReasonData<>NULL GROUP BY ReasonData ORDER BY hits DESC\" -i:CSV -nSkipLines:4 -o:DATAGRID -dtlines:800 -rtp:-1

Рисунок 6: Причина расширения агента (сетка данных)

Если вы предпочитаете круговую диаграмму предыдущих результатов, это довольно просто. Используя параметр ‘chartType:PieExplode3D в следующей команде, мы получаем отличную диаграмму, показанную на рисунке 7.

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT CASE TO_INT(ReasonData) WHEN NULL THEN 0 ELSE TO_INT(ReasonData) END AS ReasonData2, count(*) AS hits INTO agentreasonspread.gif from C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\AgentLog\AGENT*.log GROUP BY ReasonData2 ORDER BY hits DESC\" -i:CSV -nSkipLines:4 -o:CHART -chartType:PieExploded3D -chartTitle:\"Agent Reason Spread\" -e 200 -dtlines:600

Рисунок 7: Причина расширения агента

Хотя значение SCL варьируется в пределах от 1 до 9, обратите внимание, что на предыдущей круговой диаграмме имеется область для значения 0. Значение 0 объединяет все «отключенные политики» и «обходы фильтрации содержимого» (смотреть предыдущую сетку данных), означая, что эта область представляет почту, вошедшую в вашу организацию.

Если вам нужен более единый вид предыдущей диаграммы, только для принятой или отклоненной почты, этого можно добиться с помощью следующего запроса анализатора журналов. Обратите внимание, что сообщения с SCL рейтингом равным 8 или выше считаются отклоненными, SCL 7 означает, что сообщение помещено в карантин, а все остальные сообщения расцениваются как принятые.

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT CASE TO_INT(ReasonData) WHEN 9 THEN 'REJECTED' WHEN 8 THEN 'REJECTED' WHEN 7 THEN 'QUARANTINED' ELSE 'ACCEPTED' END AS ReasonData2, TO_INT(mul(100.0,PropCount(*))) as Percent, count(*) as hits INTO agentAcceptedRejected.gif FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\AgentLog\AGENT*.log GROUP BY ReasonData2 ORDER BY hits DESC\" -i:CSV -nSkipLines:4 -o:CHART -chartType:PieExploded3D -chartTitle:\"%% Accepted/Rejected mail\" -dtlines:600 -categories:OFF -values:ON -view:ON

Рисунок 8: Процент принятой и отклоненной почты

Отчеты в Log Parser для журналов протокола

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

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

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT QUANTIZE(TO_TIMESTAMP (EXTRACT_PREFIX(TO_STRING(EXTRACT_SUFFIX([#Fields: date-time],0,'T')),0,'.'), 'hh:mm:ss'),3600) AS Hour, COUNT(*) AS Hits INTO radar_traffic.gif FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\ProtocolLog\SmtpReceive\RECV*.LOG WHERE event='+' GROUP BY Hour ORDER BY Hour ASC\" -i:CSV -nSkipLines:4 -o:CHART -charttype:RadarLineFilled -charttitle:\" Global total SMTP inbound simultaneous connections per hours\"

Рисунок 9: Входящие SMTP подключения

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

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT QUANTIZE(TO_TIMESTAMP (EXTRACT_PREFIX(TO_STRING(EXTRACT_SUFFIX([#Fields: date-time],0,'T')),0,'.'), 'hh:mm:ss'),3600) AS Hour, COUNT(*) AS Hits INTO radar_traffic_send.gif FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\ProtocolLog\SmtpSend\SEND*.LOG WHERE event='+' GROUP BY Hour ORDER BY Hour ASC\" -i:CSV -nSkipLines:4 -o:CHART -charttype:RadarLineFilled -charttitle:\" Global total SMTP outbound simultaneous connections per hours\"

Рисунок 10: Одновременные исходящие подключения

Следующая команда анализирует подозрительных отправителей в вашей организации. Чтобы достичь этой цели, нам нужно извлечь из журнала SMTP получения все узлы, которые получили код состояния 500 и выше, например, 504, 535, 550 и т.д.

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

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT EXTRACT_PREFIX(remote-endpoint,0,':') AS Remote-host, count (*) AS hits INTO SuspiciousSenders.xml FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\ProtocolLog\SmtpReceive\RECV*.log WHERE TO_INT(SUBSTR(DATA,0,3)) > 500 AND event = '>' GROUP BY Remote-host ORDER BY hits DESC\" -i:CSV -nSkipLines:4 -o:XML \"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT TOP 10 REVERSEDNS(Remote-host), hits FROM SuspiciousSenders.xml\" -i:XML -o:DATAGRID

Обратите внимание, что внутренний узел в результатах отображен на рисунке 11. Этот конкретный узел, вероятно, является внутренним сервером приложений или авторизированным внутренним ретранслятором почты.

Рисунок 11: Подозрительные узлы, отправляющие почту в вашу организацию

Мы также можем создать сетку данных с ошибками отклонения исходящих сообщений (Top Outbound Rejection Errors), проанализировав журнал протокола отправки SMTP. Эта информация может быть весьма полезной для определения потенциальных исходящих ошибок или просмотра того, не включен ли ваш сервер в какой-нибудь черный список. Вот команда, которая создает сетку данных, как показано на рисунке 12:

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT CASE TO_INT( SUBSTR(DATA,0,3)) when NULL then 0 else TO_INT( SUBSTR(DATA,0,3)) END AS RemoteHostReturnCode, data, count (*) AS hits FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\ProtocolLog\SmtpSend\SEND*.log WHERE RemoteHostReturnCode > 400 AND context <> 'Certificate thumbprint' AND context <> 'sending message' GROUP BY RemoteHostReturnCode, data ORDER BY hits DESC\" -i:CSV -nSkipLines:4 -o:DATAGRID

Рисунок 12: Ошибки отклонения исходящих сообщений

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

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

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT TOP 10 EXTRACT_PREFIX(remote-endpoint,0,':') AS RemoteSendingHost, count(*) AS Hits INTO topsenders.xml FROM C:\Progra~1\Microsoft\Exchan~1\TransportRoles\Logs\ProtocolLog\SmtpReceive\RECV*.LOG WHERE event='+' GROUP BY RemoteSendingHost ORDER BY Hits DESC\" -i:CSV -nSkipLines:4 -o:XML \"C:\Program Files (x86)\Log Parser 2.2\logparser.exe\" \"SELECT TOP 10 REVERSEDNS(RemoteSendinghost), Hits INTO topsenders.gif FROM TopSenders.xml\" -i:XML -o:CHART -chartType:PieExploded3D -chartTitle:\"TOP 10 Senders\" -groupSize:1024x768

Увеличить

Рисунок 13: Узлы, отправляющие самое большое количество сообщений в вашу организацию

Заключение

Если вы когда-либо задавались вопросом, на кой черт вам нужно столько журналов в Exchange, или вы склонны воспринимать все эти «нежелательные» логи как мусор, они внезапно становятся весьма полезными и теперь являются ключевыми элементами для обнаружения любой информации о вашей почтовой инфраструктуре. Пока не выйдет вторая часть этого цикла, вы можете поиграть с этим инструментом Log Parser и готовьтесь к некоторым трудным запросам!

Дополнительные ссылки

Автор: Руи Силва • Иcточник: www.msexchange.ru • Опубликована: 26.11.2009

Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER

Теги:

Оценить статью: