.
В процессе составления планов миграции и при проектировании инфраструктуры Exchange Server полезно иметь информацию о том, как пользователи сети используют систему Exchange. В статье "Обсчет систем Exchange 2003" в шестом номере Windows IT Pro /RE за 2005, я рассказывал о приемах и концепциях, связанных с классификацией пользователей, - а именно, о разделении их на малоактивных, умеренно активных и весьма активных пользователей электронной почты. Один из начальных подходов к классификации пользователей состоит в анализе статистических данных работы того или иного пользователя: скажем, сколько сообщений он отправил и получил или сколько байтов данных было им отправлено и получено. Превосходным источником такой информации являются файлы трассировки сообщений Exchange. Давайте рассмотрим базовый формат этих файлов трассировки, а также вопросы о том, на какие элементы содержимого упомянутых файлов нужно обращать внимание и как интерпретировать эти данные для целей классификации пользователей по активности использования ими средств электронной почты.
Краткие сведения о файлах трассировки сообщений
Предположим, что функция трассировки сообщений Exchange активизирована. Это значит, что всякий раз, когда какой-либо компонент системы Exchange, например, Information Store, Message Transfer Agent (MTA), шлюз или коннектор будет передавать или получать сообщение, Exchange внесет соответствующую запись в относящийся ко дню наступления данного события раздел журнала трассировки. Журнал трассировки включает в себя от 15 до 20 полей данных (их количество зависит от версии эксплуатируемой вами системы Exchange). В них заносится код события, указывающий на то, какое действие было совершено, а также такие сведения, как имена отправителя и получателей, размер сообщения и его идентификатор. В каждой новой версии Exchange разработчики вносят изменения как в формат полей журнала, так и в коды событий. Информационный Internet-ресурс TechNet содержит несколько статей с разъяснением особенностей формата регистрационного файла и кодов событий для каждой версии (см. врезку «Дополнительные ресурсы»).
Файлы трассировки сообщений - это текстовые файлы, где в качестве разделителей используются символы табуляции. Как правило, они слишком велики по размерам и содержат слишком много информации, чтобы администратор мог оценить их в формате файлов Excel или WordPad. К примеру, когда файл трассировки загружается в Excel, система обычно выдает сообщение о том, что файл не может быть загружен в полном объеме; а если так, то он не может быть полностью проанализирован. Однако такие приложения могут быть полезными инструментами при исследовании особенностей форматирования файла и его полей, а также при формировании первоначальных оценок. Чтобы проанализировать большие объемы данных, необходимо написать сценарий, с помощью которого будет выявляться нужная информация, или загрузить анализируемые файлы в базу данных и извлекать требуемые сведения с помощью запросов. Существует и другая возможность - использовать для оценки журналов трассировки средства подготовки отчетов от независимых поставщиков, таких, как Quest Software или PROMODAG.
В примерах записей журналов трассировки систем Exchange Server 5.5 и Exchange 2000 Server, представленных, соответственно, на Рисунке 1 и 2, для разделения полей данных используются символы табуляции. Эти символы я обозначил стрелками, чтобы читателям было видно, где заканчивается одно поле и начинается другое. Кроме того, для удобства чтения я разбивал длинные строки на несколько коротких.
C=US;A= ;P=HP;L=X07-050313202134Z-74→9→2005.3.13 20:21:34→→/O=HP/OU=US/CN=CONFIGURATION /CN=SERVERS/CN=X07/CN=MICROSOFT PRIVATE MDB→→ /o=HP/ou=US/cn=RECIPIENTS/cn=NEUBAUER →0→4374→0→0→→3 /o=HP/ou=US/cn=RECIPIENTS/cn=EMILY→→ /o=HP/ou=US/cn=RECIPIENTS/cn=ANDREW→→ /o=HP/ou=US/cn=Recipients/cn=JAKE→→
Рис. 1: Записи в журнале трассировки Exchange 5.5
2005-3-13>21:40:6 GMT→-→-→-→SRV2→-→/O=HP /OU=FIRST ADMINISTRATIVE ROUP/CN=RECIPIENTS/CN= Jake→1027→13412E852684D54294809C0A684A233A027810 @srv2.HP.net→0→0→763→2→2005-3-13 21:40:6 GMT →0→-→c=us;a= ;p=HP;l=SRV2-050313214006Z-4→Meeting Info→EX:/O=HP/OU=FIRST ADMINISTRATIVE GROUP /CN=RECIPIENTS/CN=EMMA 2005-3-13→21:40:6 GMT>-→-→-→SRV2→-→/O=HP /OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN= Ben>1027>13412E852684D54294809C0A684A233A027810 @srv2.HP.net>0>0>763>2>2005-3-13 21:40:6 GMT →0→-→c=us;a= ;p=HP;l=SRV2-050313214006Z-4→ Meeting Info →EX:/O=HP/OU=FIRST ADMINISTRATIVE GROUP /CN=RECIPIENTS/CN=EMMA
Рис. 2: Записи в журнале трассировки Exchange 2000
Генерировать журнальные записи могут различные компоненты Exchange. То, что представляется нам одним актом - скажем, Бен направляет Эндрю письмо, - на деле является серией отдельно регистрируемых событий. Чтобы установить соотношение между двумя записями, необходимо использовать данные, содержащиеся в каждой из них, например, Message ID (Exchange 5.5) или Linked Message ID (Exchange 2000). Внимания заслуживает и то обстоятельство, что журналы трассировки не включают в себя данные по всем событиям. В них фиксируются лишь локальные события, имевшие место именно на данном сервере. Если Бен и Эндрю приписаны к разным серверам, в журнал на сервере Бена будет внесена запись о передаче сообщения и зарегистрировано событие "передача во внешнюю среду" по протоколу SMTP или MTA. На сервере Эндрю появится запись о получении данных "из внешней среды" по протоколу SMTP или MTA, а также зарегистрировано событие доставки сообщения.
Наконец, еще одно важное замечание относительно форматов журналов трассировки; оно касается того, как фиксируются в каждом событии имена получателей. В системе Exchange 5.5 используется довольно неупорядоченный и не слишком удобный для понимания формат, в котором каждая регистрационная запись занимает несколько строк. В первой строке каждой регистрационной записи о событии размещаются поля с 1 по 12 (как это описано в подготовленной специалистами Microsoft статье "XADM: Tracking Log Field Descriptions", опубликованной по адресу http://www.supportmicrosoft.com/?kbid=173280). Поля с 13 по 15 записываются на одной или нескольких последующих строках - по одной на каждого получателя. В зафиксированном на Рис. 1 событии сообщение имело трех получателей, поэтому в регистрационном файле имеется четыре строки. В тексте на этом рисунке обратите внимание на строки, начинающиеся с символов "/o=HP". В журналах трассировки систем Exchange Server 2003 и Exchange 2000 отдельные события не занимают больше одной строки, но для каждого получателя предусматривается особая запись. На Рис. 2 показаны две полные записи для этих двух получателей. Преимущество регистрационного формата Exchange 5.5 в том, что такие данные, как имя отправителя и размер сообщения записываются однократно; недостаток же заключается в том, что при размещении данных "запись за записью" анализировать этот журнал гораздо сложнее, чем журналы систем Exchange 2003 или Exchange 2000.
В журнале можно регистрировать от 30 до 50 различных событий (это зависит от версии Exchange). При проведении диагностики могут пригодиться почти все из этих событий, однако в процессе классификации пользователей я обычно пользуюсь лишь двумя или тремя из них. Если вы эксплуатируете Exchange версии 5.5, используйте событие 4 - предъявление сообщения, событие 9 - доставка сообщения и событие 1000 - локальная доставка; пользователям систем Exchange 2003 и Exchange 2000 нужно оценивать только события 1027 -Message submitted to Store Driver и 1028- Message Delivery to Local Store.
Счетчики отправленных сообщений
Когда сообщение предъявляется для последующей передачи, его маршрутизация может осуществляться по одной из двух принципиальных схем: передача сообщения на другой (удаленный) сервер или локальная его доставка. В системе Exchange 5.5 характер регистрируемого в журнале события зависит от того, к каким категориям (локальной или удаленной) относятся его получатели. Если все получатели - локальные пользователи, регистрируется только событие 1000. Это единственное событие представляет как предъявление сообщения, так и его доставку. Если среди получателей имеются удаленные, регистрируется событие 4. А если сообщение предназначено как для локальных, так и для удаленных получателей, регистрируются события 4 и 1000, причем каждое событие включает получателей, ассоциируемых с соответствующим типом доставки. К примеру, если сообщение имеет девять получателей (четыре локальных и пять удаленных), четыре получателя регистрируются с событием 1000, а пять - с событием 4.
Чтобы определить, сколько сообщений было предъявлено для передачи, нужно отыскать все экземпляры событий 4 и 1000. Но простое суммирование всех регистрационных записей с событиями 4 и 1000 не будет отражать подлинного числа предъявленных для передачи сообщений. Ведь некоторые сообщения могут быть предназначены как для локальных, так и для удаленных получателей. Поэтому для того чтобы избежать двойного учета, нужно собрать эти события в пары, относящиеся к одному и тому же сообщению. Для решения этой проблемы используются отображаемые в поле 1 идентификаторы сообщений, которые всегда являются уникальными. Так, на Рис. 3 показаны записи, содержащие три уникальных идентификатора сообщений (идентификаторы сообщений выделены) и один дублирующий идентификатор сообщения; это означает, что были отправлены только три сообщения, хотя в журнале имеются четыре записи. На рисунке все регистрационные записи представлены только первыми строками. Чтобы собрать статистические данные по конкретным пользователям - а это необходимо для их классификации, - следует дополнительно обратить внимание и на поле 7 (выделенное полужирным шрифтом), где значится имя создателя сообщения. Из содержимого Рис. 3 явствует, что имеется два уникальных отправителя, Бен и Эндрю. Идентификаторы переданных отправителем Эндрю сообщений уникальны, а значит число переданных им сообщений равно двум. В записях, имеющих отношение к отправителю Бену, мы видим события 4 и 1000, но только один идентификатор сообщения; значит, число переданных им сообщений равно 1, а не 2.
C=US;A= ;P=HP;L=X07-050313202134Z-74→4→2005.3.13 20:28:32→→/O=HP/OU=US/CN=CONFIGURATION/CN= SERVERS/CN=X07/CN=MICROSOFT PRIVATE MDB→→ /o=HP/ou=US/cn=RECIPIENTS/cn=BEN→0→2096→0→0→→3 c=US;a= ;p=HP;l=X07-050313202134Z-74→1000→2005.3.13 20:28:32→/o=HP/ou=US/cn=Configuration/cn=Servers/cn=X→7 /cn=Microsoft Private MDB→/o=HP/ou=US/cn=Configuration /cn=Servers/cn=X07/cn=Microsoft Private MDB→→/O=HP /OU=US/CN=RECIPIENTS/CN=BEN→0→819→0→1→→4 C=US;A= ;P=HP;L=X07-050313202630Z-76→4→2005.3.13 20:26:30→→/O=HP/OU=US/CN=CONFIGURATION/CN= SERVERS/CN=X07/CN=MICROSOFT PRIVATE MDB→→/o=HP/ou=US/cn=RECIPIENTS/cn=ANDREW →0→1620→0→0→→2 C=US;A= ;P=HP;L=X07-050313202832Z-77→1000 →2005.3.13 20:28:32→/o=HP/ou=US/cn=Configuration /cn=Servers/cn=X07/cn=Microsoft Private MDB→/o=HP /ou=US /cn=Configuration/cn=Servers/cn=X07 /cn=Microsoft Private DB→→/O=HP/OU=US/CN=RECIPIENTS /CN=ANDREW→0→819→0→1→4
Рис. 3: Подсчет количества предъявленных для передачи сообщений в Exchange 5.5
Регистрируя акт предъявления сообщения для передачи, Exchange 2003 и Exchange 2000 не делают различий между локальными и удаленными получателями. В этих версиях системы Exchange для каждого получателя вводится запись с событием 1027, как это показано на Рис. 4. В результате задача выявления общего числа сообщений, предъявленных для передачи, существенно облегчается, поскольку искать приходится лишь одно событие. Но поскольку событие может регистрироваться неоднократно - для каждого получателя, - в этих системах тоже приходится отфильтровывать дубликаты, то есть связывать представляющие одно и то же сообщение события, используя уникальный идентификатор этого сообщения. В журналах трассировки систем Exchange 2003 и Exchange 2000 имеется по два поля идентификаторов сообщений: поле 10, MSGID, и поле 18, Linked-MSGID. Значение поля 10 генерируется тем компонентом системы, который осуществляет запись в журнал; в разных записях это поле может иметь разные значения. Скажем, поле MSGID будет иметь одно значение, когда запись в журнал генерирует Information Store, и другое - когда эту операцию выполняет Categorizer, хотя эти компоненты обрабатывают одно и то же сообщение. Поле 10 используется, когда требуется объединить все события для отдельного компонента. Значения поля 18 Linked-MSGID представляют особый интерес, поскольку они объединяют все соответствующие записи в журнале. Запись в поле 18 аналогична идентификатору сообщения, который отображается в окне Message программы Outlook на странице general Properties.
2005-3-13→21:34:52 GMT→-→-→-→SRV2→-→/O=HP /OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN= Edward→1027→13412E852684D54294809C0A684A233A02780E @srv2.HP.net→0→0→1530→3→2005-3-13 21:34:52 GMT→0 →-→c=us;a= ;p=HP;l=SRV2-050313213452Z-2→Second Message →EX:/O=HP/OU=FIRST ADMINISTRATIVE GROUP /CN=RECIPIENTS/CN=EMMA 2005-3-13→21:34:52 GMT→-→-→-→SRV2→-→/O=HP /OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS /CN= Ben→1027→13412E852684D54294809C0A684A233A02780E @srv2.HP.net→0→0→1530→3→2005-3-13 21:34:52 GMT →0→-→c=us;a= ;p=HP;l=SRV2-050313213452Z-2→Second Message→EX:/O=HP/OU=FIRST ADMINISTRATIVE GROUP /CN=RECIPIENTS/CN=EMMA 2005-3-13→21:34:52 GMT→-→-→-→SRV2→-→/O=HP/OU= FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=Andrew →1027→13412E852684D54294809C0A684A233A02780E @srv2.HP.net→0→0→1530→3→2005-3-13 21:34:52 GMT→0 →-→c=us;a= ;p=HP;l=SRV2-050313213452Z-2→Second Message→EX:/O=HP/OU=FIRST ADMINISTRATIVE GROUP /CN=RECIPIENTS/CN=EMMA
Рис. 4: Подсчет предъявленных для передачи сообщений в Exchange 2003 и Exchange 2000
Счетчики полученных сообщений
Число полученных пользователем сообщений определяется так же, как и количество отправленных сообщений. Как уже отмечалось, если отправитель и получатель приписаны к одному серверу, в системе Exchange 5.5 и предъявление сообщения к отправке, и его доставка обозначается с помощью события 1000. Когда же отправитель и получатель находятся на разных серверах, на сервере получателя регистрируется событие 9. Для определения счетчиков полученных сообщений нужно выявить все события 9 и 1000. Отфильтровывать дубликаты в этом случае нет необходимости, так как на сервере для каждого конкретного сообщения фиксируется лишь одно из двух упомянутых событий. При сборе информации по конкретным пользователям анализируйте содержимое поля 13, где регистрируется имя получателя.
Каждое из этих событий может обозначать доставку сообщения нескольким получателям, поэтому событие следует сопоставлять со счетчиком полученных сообщений для каждого внесенного в список пользователя. К примеру, событие, представленное на Рис. 1, отображает доставку сообщения, а в поле 13 перечисляются три получателя: Эмили, Эндрю и Джейк. Счетчик полученных сообщений у каждого получателя увеличивается на единицу, хотя в журнале зарегистрировано лишь одно событие доставки. Определять количество сообщений, полученных тем или иным пользователем, намного проще в системах Exchange 2003 и Exchange 2000, где каждая запись в журнале регистрации применяется лишь к одному получателю. Выявите все зарегистрированные в журнале события 1028 и исследуйте поле 8, Recipient-Address. Таким образом вы узнаете, счетчик какого получателя нужно увеличить на единицу.
Размер сообщения
Другая категория статистических данных, которая может быть полезной при классификации пользователей по интенсивности использования ими электронной почты, это общая сумма байтов в отправленных и полученных сообщениях. В системе Exchange 5.5 размер сообщений фиксируется в поле 9, а в системах Exchange 2003 и Exchange 2000 - в поле 18. Идентифицировав отправленное или полученное сообщение, администратор может извлечь из соответствующего поля данные о размере сообщения, рассчитать промежуточную сумму и определить средние значения. В случаях, когда прохождение сообщения фиксируется в нескольких событиях, его размер можно устанавливать по любому из этих событий, ибо во всех событиях регистрируется одно и то же значение. Но при подсчете общей суммы будьте внимательны: из каждой группы событий берите только одно. Не суммируйте данные из всех событий!
Размеры сообщений, фиксируемых в журналах трассировки сообщений систем Exchange 2003 и Exchange 2000, в точности соответствуют размерам тех же сообщений, регистрируемых хранилищем Information Store. Скажем, если Information Store извещает, что размер сообщения составляет 4233 байт, в поле 13 журнала трассировки указывается значение 4233 байт. К сожалению, значения размера сообщения, зарегистрированные в хранилище Information Store системы Exchange 5.5 с одной стороны, и в журнале трассировки - с другой, не совпадают. Скажем, если Information Store сообщает, что размер сообщения составляет 2316 байт, то в поле 9 файла трассировки может содержаться другое значение - 3397. Различие объясняется прежде всего непроизводительными расходами, связанными с транспортировкой сообщения, а кроме того - форматированием и содержимым сообщения. По моим оценкам, размеры сообщений, регистрируемые журналами трассировки системы Exchange 5.5, на 30 - 46 процентов превосходят те же размеры, указываемые в Information Store. Помните об этих различиях, если вы оцениваете размеры сообщений с помощью журналов трассировки Exchange 5.5.
Оценка результатов
Собрав статистические данные по индивидуальным пользователям, вы можете приступить к их классификации по интенсивности использования электронной почты. Начинать следует с таких метрик, как число сообщений и количество байт, отправленных пользователем, ибо они напрямую коррелируются с действиями самого пользователя. Например, решение отправить сообщение принимается самим человеком, тогда как решение о том, сколько сообщений будет получено, полностью или почти полностью находится вне зоны его контроля. Вполне вероятно, что сотрудник, получающий большое число сообщений, - это не квалифицированный пользователь, а человек, в ящик которого попадают значительные объемы "почтового мусора". Количество отправленных сообщений можно также уподобить опубликованным метрикам, таким, как Messaging API (MAPI) Messaging Benchmark (MMB3). Мне не удалось обнаружить добротных статистических данных, согласно которым число получаемых сообщений или размер этих сообщений разделялись бы на категории "высокий", "средний" или "низкий" уровень активности, но я полагаю, что счетчики полученных сообщений не следует сбрасывать со счетов, поскольку эти сообщения оказывают влияние на ресурсы системы.
Конечная цель вашего анализа состоит в том, чтобы определить, какое число учетных записей можно разместить на одном сервере. Исходить из того, что все пользователи сети весьма активно работают с электронной почтой и рассчитывать количество необходимых серверов на основе этой посылки - весьма сомнительный подход. В итоге будет израсходовано слишком много средств, а серверы будут функционировать с огромными недогрузками. Если же администратор недооценит интенсивность использования электронной почты, серверы окажутся перегруженными, а пользователи будут постоянно жаловаться на низкое быстродействие. Точно оценить ситуацию сложно, поскольку понятие активности среднего пользователя - понятие зыбкое и субъективное. Проблема осложняется еще и тем, что "средний уровень" изменяется со временем - по мере того, как изменяются возможности систем, а также методы работы пользователей и методы использования ими этих систем.
Если в качестве первоначальной точки отсчета использовать эталонные значения MMB3, можно прийти к заключению, что человек со средним уровнем интенсивности использования средств электронной почты ежедневно отправляет порядка 9 Мбайт данных и от 48 до 78 сообщений. Недавно я проводил оценку сети, в которой работают порядка 5400 пользователей. Я обнаружил, что если судить по показателю числа сообщений, отсылаемых пользователем за день, примерно 3 процента из них следует считать весьма активными пользователями средств электронной почты, 8 процентов - довольно активными пользователями, а остальные 89 процентов относятся к категории малоактивных пользователей. Сообщений, поступающих на данный узел, было примерно в три раза больше, чем исходящих сообщений, так что построить точную классификацию пользователей основываясь только на анализе отправляемых ими сообщений было невозможно. Исходя из того, что уровни нагрузки на систему при отправке и при получении одного сообщения примерно одинаковы, я объединил показатели отправленных и полученных сообщений с помощью интегральной формулы, согласно которой N (нормализованная сумма) равняется квадратному корню числа ((S**2 + R**2)/2), где S - это число отправленных сообщений, а R - число поступивших сообщений. С учетом вновь полученных данных я повторно провел классификацию, по-прежнему используя показатель от 48 до 78 ежедневно отправляемых сообщений в качестве критерия, определяющего пользователя со средним уровнем интенсивности использования средств электронной почты. При этом соотношение весьма активных, умеренно активных и малоактивных пользователей в общем числе пользователей электронной почты изменилось; теперь на эти категории приходилось, соответственно, 12 процентов, 19 процентов и 69 процентов пользователей.
Оперируйте фактическими данными
Как я отметил в статье "Обсчет систем Exchange 2003", при масштабировании системы необходимо принимать во внимание не только количество отправленных и полученных сообщений. Наряду с этим следует учитывать и то, как именно люди используют систему. Если система Exchange применяется в качестве электронной картотеки для хранения часто истребуемых файлов и данных, нагрузка на систему превышает значение, получаемое при расчете на основе количества полученных и отправленных сообщений или байтов.
Некоторые из упомянутых метрик можно почерпнуть из журналов трассировки и из показаний счетчиков быстродействия; для получения других нужно проводить исследования и наблюдать за поведением пользователей системы. Классификация лишь отчасти является наукой. Отчасти это - область субъективных оценок, но когда в распоряжении администратора имеются конкретные данные, он подходит чуть ближе к пониманию реальных процессов работы пользователей с электронной почтой. Ему уже не приходится действовать наугад, и он получает возможность строить более совершенные системы.
Джозеф Нойбауэр (jneubauer@windowsitpro.com) - старший технический консультант HP, специалист по Windows и Microsoft Exchange Server.
Дополнительные ресурсы
Формат журналов трассировки Exchange Server 5.5
"XADM: Tracking Log Field Descriptions"
http://www.support.microsoft.com/?kbid=173280
Номера событий в журналах трассировки Exchange 5.5
"XADM: Exchange 5.0 and 5.5 Tracking Log Event Numbers"
http://www.support.microsoft.com/?kbid=173364
Формат журналов трассировки систем Exchange Server 2003 и Exchange 2000 Server
"XADM: Message Tracking Logs Field Descriptions in Exchange 2000 Server"
http://www.support.microsoft.com/?kbid=246965
Номера событий в журналах трассировки Exchange 2000
"Tracking log event numbers for Exchange 2000 Server"
http://www.support.microsoft.com/?kbid=311739
Номера событий в журналах трассировки Exchange 2003
"Tracking Log Event Numbers for Exchange Server 2003"
http://www.support.microsoft.com/?kbid=822930