Одна из самых важных особенностей диагностики Exchange заключается в следующем: наиболее ценные диагностические данные часто являются временными.
Когда возникает серьезная проблема, администраторы редко начинают сбор логов немедленно.
На практике обычно происходит следующее:
К сожалению, к этому моменту многие Exchange-логи уже могут быть:
Особенно это актуально в средах с:
Диагностика часто начинается удаленно
Еще одна важная практическая особенность заключается в том, что расследование проблем часто выполняется удаленно.
В рамках обращений в поддержку инженеры обычно не имеют прямого доступа к продуктивной среде.
Вместо этого:
Поэтому критически важными становятся две задачи:
Идеальная ситуация выглядит так: собрать достаточно данных до того, как они будут потеряны.
ExchangeLogCollector
Для стандартизации и упрощения этого процесса инженеры поддержки Microsoft разработали специальный скрипт:
ExchangeLogCollector (CSS-Exchange)
ExchangeLogCollector - Microsoft - CSS-Exchange
Скрипт входит в состав проекта CSS-Exchange и предназначен специально для сбора диагностических данных Exchange.
Его основные задачи:
Какие данные может собирать скрипт ?
ExchangeLogCollector способен собирать широкий спектр диагностической информации, включая:
Это значительно снижает риск забыть собрать важную информацию во время аварийных ситуаций.
Фильтрация по дате и времени
Одной из наиболее полезных возможностей является фильтрация по времени возникновения проблемы.
Она позволяет:
Однако важно понимать следующий нюанс:
фильтрация по дате применяется в первую очередь к текстовым логам.
Например:
Журналы событий Windows обычно собираются иначе и могут не подпадать под такую фильтрацию.
Это важно учитывать при планировании сбора данных.
Сбор данных с нескольких серверов
Еще одной крайне полезной возможностью является одновременный сбор данных с нескольких Exchange-серверов.
Это особенно актуально для инфраструктур с:
Многие проблемы Exchange возникают не на одном сервере, а в результате взаимодействия нескольких компонентов.
Централизованный сбор данных помогает сохранить единую временную картину происходящего во всей инфраструктуре.
Работа с архивами
Скрипт позволяет указать каталог для сохранения собранных архивов.
Это особенно удобно, поскольку набор диагностических данных может занимать значительный объем дискового пространства, особенно если:
Выделенная директория упрощает:
Готовые сценарии сбора данных
Еще одним практическим преимуществом являются встроенные сценарии сбора данных.
Вместо ручного выбора каждого источника логов администратор может использовать готовые профили, предназначенные для типовых сценариев диагностики.
Это особенно полезно в условиях аварий и ограниченного времени.
Один из самых важных параметров: AllPossibleLogs
Пожалуй, самая важная практическая рекомендация выглядит следующим образом:
если вы не уверены, какие логи могут понадобиться позже - собирайте все возможные данные сразу.
Для этого в ExchangeLogCollector предусмотрен параметр: -AllPossibleLogs
Этот режим может существенно повысить вероятность успешного определения первопричины проблемы.
На практике это особенно важно потому что:
Очень часто главным ограничением расследования становится не отсутствие экспертизы.
А просто: отсутствие сохраненных диагностических данных.
Поздняя эскалация встречается гораздо чаще, чем кажется
На практике заказчики нередко открывают обращения:
К этому моменту:
Именно поэтому многие расследования заканчиваются выводом:
«Не удалось определить первопричину из-за недостаточного объема диагностических данных».
Чем раньше начинается сбор данных, тем выше вероятность успешного расследования.
Убедитесь, что важные логи действительно хранятся достаточно долго
Еще одна важная рекомендация заключается не только в проверке того, что логирование включено, но и в проверке сроков хранения данных.
Многие Exchange-логи имеют разумные настройки хранения по умолчанию.
Например, большинство протокольных и диагностических логов Exchange обычно хранится около: 7-14 дней
Однако сроки хранения многих других источников данных определяются самой организацией.
К ним относятся:
В ряде организаций эти логи могут ротироваться значительно быстрее из-за:
Это особенно критично в ситуациях поздней эскалации проблем.
Данные производительности могут храниться всего несколько дней
Еще одна часто недооцениваемая область - хранение диагностических данных производительности.
Exchange постоянно собирает большой объем внутренней диагностической информации.
За сбор многих встроенных наборов данных отвечает служба Microsoft Exchange Diagnostics
Однако в зависимости от:
часть диагностических данных может храниться всего 2–3 дня, после чего будет автоматически перезаписана.
В результате к моменту начала расследования наиболее ценная историческая информация уже может быть потеряна.
Именно поэтому долгосрочное хранение данных мониторинга и метрик во внешних системах зачастую оказывается крайне полезным.
Настройки логирования должны соответствовать требованиям организации
Поэтому рекомендуется периодически проверять:
Иначе даже грамотно организованный процесс диагностики может оказаться бесполезным просто потому, что необходимые данные уже были удалены.
Заключение
Диагностика Exchange напрямую зависит от сохранности диагностических данных.
И во многих случаях быстро собрать нужные логи важнее, чем немедленно приступать к их анализу.
Такие инструменты, как ExchangeLogCollector, помогают стандартизировать и ускорить этот процесс, существенно снижая риск потери важной информации.
Даже если организация не работает напрямую с поддержкой Microsoft, ей может быть крайне полезно заранее сохранять подробные диагностические данные при возникновении инцидентов.
Потому что после того, как логи будут перезаписаны даже самая лучшая методология диагностики может уже не помочь.
Когда возникает серьезная проблема, администраторы редко начинают сбор логов немедленно.
На практике обычно происходит следующее:
- пользователи сначала сообщают о симптомах;
- проблема может выглядеть периодической;
- эскалация происходит спустя несколько часов;
- активное расследование начинается через дни;
- инженеры еще не понимают, какие именно данные понадобятся для диагностики.
К сожалению, к этому моменту многие Exchange-логи уже могут быть:
- перезаписаны;
- усечены;
- ротированы;
- либо просто потерять актуальность.
Особенно это актуально в средах с:
- большим количеством пользователей;
- крупными IIS-логами;
- расширенным протоколированием;
- высокой активностью транспортных служб;
- значительным объемом трафика.
Диагностика часто начинается удаленно
Еще одна важная практическая особенность заключается в том, что расследование проблем часто выполняется удаленно.
В рамках обращений в поддержку инженеры обычно не имеют прямого доступа к продуктивной среде.
Вместо этого:
- заказчик самостоятельно собирает данные;
- данные передаются внешним специалистам;
- появляются дополнительные запросы на сбор информации;
- отсутствующие логи приходится собирать повторно.
Поэтому критически важными становятся две задачи:
- Определить правильный набор диагностических данных.
- Максимально упростить и ускорить процесс их сбора.
Идеальная ситуация выглядит так: собрать достаточно данных до того, как они будут потеряны.
ExchangeLogCollector
Для стандартизации и упрощения этого процесса инженеры поддержки Microsoft разработали специальный скрипт:
ExchangeLogCollector (CSS-Exchange)
ExchangeLogCollector - Microsoft - CSS-Exchange
Скрипт входит в состав проекта CSS-Exchange и предназначен специально для сбора диагностических данных Exchange.
Его основные задачи:
- упростить сбор логов;
- сократить объем ручной работы;
- обеспечить единообразие собираемых данных;
- ускорить процесс диагностики;
- сохранить данные до их ротации или удаления.
Какие данные может собирать скрипт ?
ExchangeLogCollector способен собирать широкий спектр диагностической информации, включая:
- логи Exchange;
- IIS-логи;
- HttpProxy логи;
- транспортные логи;
- протокольные логи;
- журналы событий Windows;
- конфигурационную информацию;
- данные производительности;
- сведения о кластере;
- сетевую информацию;
- логи Managed Availability;
- и многие другие данные.
Это значительно снижает риск забыть собрать важную информацию во время аварийных ситуаций.
Фильтрация по дате и времени
Одной из наиболее полезных возможностей является фильтрация по времени возникновения проблемы.
Она позволяет:
- уменьшить размер архивов;
- ускорить передачу данных;
- сосредоточиться на нужном временном интервале.
Однако важно понимать следующий нюанс:
фильтрация по дате применяется в первую очередь к текстовым логам.
Например:
- IIS logs;
- HttpProxy logs;
- Transport logs.
Журналы событий Windows обычно собираются иначе и могут не подпадать под такую фильтрацию.
Это важно учитывать при планировании сбора данных.
Сбор данных с нескольких серверов
Еще одной крайне полезной возможностью является одновременный сбор данных с нескольких Exchange-серверов.
Это особенно актуально для инфраструктур с:
- DAG;
- несколькими точками Client Access;
- балансировкой нагрузки;
- распределенными транспортными ролями;
- периодическими переключениями между серверами.
Многие проблемы Exchange возникают не на одном сервере, а в результате взаимодействия нескольких компонентов.
Централизованный сбор данных помогает сохранить единую временную картину происходящего во всей инфраструктуре.
Работа с архивами
Скрипт позволяет указать каталог для сохранения собранных архивов.
Это особенно удобно, поскольку набор диагностических данных может занимать значительный объем дискового пространства, особенно если:
- включено подробное IIS-логирование;
- участвует несколько серверов;
- включено протоколирование SMTP;
- собираются данные за длительный период времени.
Выделенная директория упрощает:
- подготовку файлов к отправке;
- управление архивами;
- организацию кейсов;
- длительное хранение данных.
Готовые сценарии сбора данных
Еще одним практическим преимуществом являются встроенные сценарии сбора данных.
Вместо ручного выбора каждого источника логов администратор может использовать готовые профили, предназначенные для типовых сценариев диагностики.
Это особенно полезно в условиях аварий и ограниченного времени.
Один из самых важных параметров: AllPossibleLogs
Пожалуй, самая важная практическая рекомендация выглядит следующим образом:
если вы не уверены, какие логи могут понадобиться позже - собирайте все возможные данные сразу.
Для этого в ExchangeLogCollector предусмотрен параметр: -AllPossibleLogs
Этот режим может существенно повысить вероятность успешного определения первопричины проблемы.
На практике это особенно важно потому что:
- проблема уже могла исчезнуть;
- логи быстро ротируются;
- в процессе расследования появляются новые гипотезы;
- разные специалисты могут запросить разные данные.
Очень часто главным ограничением расследования становится не отсутствие экспертизы.
А просто: отсутствие сохраненных диагностических данных.
Поздняя эскалация встречается гораздо чаще, чем кажется
На практике заказчики нередко открывают обращения:
- через несколько дней после инцидента;
- после временного восстановления работоспособности;
- после перезапуска сервисов;
- а иногда и спустя недели.
К этому моменту:
- важные логи уже могут быть перезаписаны;
- временные счетчики потеряны;
- IIS-логи ротированы;
- кратковременные события исчезли.
Именно поэтому многие расследования заканчиваются выводом:
«Не удалось определить первопричину из-за недостаточного объема диагностических данных».
Чем раньше начинается сбор данных, тем выше вероятность успешного расследования.
Убедитесь, что важные логи действительно хранятся достаточно долго
Еще одна важная рекомендация заключается не только в проверке того, что логирование включено, но и в проверке сроков хранения данных.
Многие Exchange-логи имеют разумные настройки хранения по умолчанию.
Например, большинство протокольных и диагностических логов Exchange обычно хранится около: 7-14 дней
Однако сроки хранения многих других источников данных определяются самой организацией.
К ним относятся:
- IIS logs;
- журналы событий Windows;
- SMTP Receive Protocol Logs;
- транспортные логи;
- данные систем мониторинга;
- данные SIEM-систем.
В ряде организаций эти логи могут ротироваться значительно быстрее из-за:
- ограничений по дисковому пространству;
- агрессивных политик очистки;
- большого объема трафика;
- подробного логирования.
Это особенно критично в ситуациях поздней эскалации проблем.
Данные производительности могут храниться всего несколько дней
Еще одна часто недооцениваемая область - хранение диагностических данных производительности.
Exchange постоянно собирает большой объем внутренней диагностической информации.
За сбор многих встроенных наборов данных отвечает служба Microsoft Exchange Diagnostics
Однако в зависимости от:
- размера организации;
- нагрузки;
- активности серверов;
- настроек хранения;
часть диагностических данных может храниться всего 2–3 дня, после чего будет автоматически перезаписана.
В результате к моменту начала расследования наиболее ценная историческая информация уже может быть потеряна.
Именно поэтому долгосрочное хранение данных мониторинга и метрик во внешних системах зачастую оказывается крайне полезным.
Настройки логирования должны соответствовать требованиям организации
Поэтому рекомендуется периодически проверять:
- что необходимое логирование действительно включено;
- что сроки хранения достаточны;
- что выделено достаточное дисковое пространство;
- что исторические данные доступны за необходимый период;
- что политика хранения соответствует внутренним стандартам организации.
Иначе даже грамотно организованный процесс диагностики может оказаться бесполезным просто потому, что необходимые данные уже были удалены.
Заключение
Диагностика Exchange напрямую зависит от сохранности диагностических данных.
И во многих случаях быстро собрать нужные логи важнее, чем немедленно приступать к их анализу.
Такие инструменты, как ExchangeLogCollector, помогают стандартизировать и ускорить этот процесс, существенно снижая риск потери важной информации.
Даже если организация не работает напрямую с поддержкой Microsoft, ей может быть крайне полезно заранее сохранять подробные диагностические данные при возникновении инцидентов.
Потому что после того, как логи будут перезаписаны даже самая лучшая методология диагностики может уже не помочь.