Jaa

Сценарии поиска неисправностей Exchange 2010 SP1

  • Artikkeli

При управлении Exchange 2010 в производственной среде администраторы часто хотят отслеживать такие вещи, как задержки базы данных, проблемы со свободным местом, проблемы с поиском, проблемы с пользователями и другие. PowerShell был создан для того, чтобы дать нам больше возможностей при выполнении задач администрирования, и уже написано много книг по тонкостям программирования на PowerShell. А что если я сообщу вам, что у вас уже есть примеры программирования на PowerShell,причем они лежат прямо на вашем сервере Exchange? И они самые полезные из всех. Начиная с версии RTM, Exchange поставляется в комплекте вместе с тремя сценариями для поиска неисправностей. Они написаны на PowerShell и готовы к использованию:

• Content Index Troubleshooter(Troubleshoot-CI.ps1)
• Database Latency Troubleshooter(Troubleshoot-DatabaseLatency.ps1)
• Database Disk Space troubleshooter(Troubleshoot-DatabaseSpace.ps1)

Эти сценарии находятся в папке  \Program Files\Microsoft\Exchange Server\V14\Scripts. Давайте познакомимся с ними.

Content Index Troubleshooter

CI Troubleshooter (Troubleshoot-CI.ps1) предназначен для мониторинга и поиска неисправностей в каталогах индексов контента. Он обнаруживает и решает следующие проблемы:

• Deadlock: Exchange Search заблокирован ожиданием потока MSSearch
• Corruption: один или несколько поисковых индексов повреждены
• Stall: аналогична deadlock в том, что индексы не обновляются
• Backlog: безрезультатные поисковые запросы из-за очереди к каталогу поиска

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

Параметры

Server (необязательный): Имя NETBIOS почтового сервера, на котором должна выполняться проверка для каталогов CI. Если параметр не задан, то используется локальный сервер.

Database (необязательный): Имя базы для поиска неисправности. Если имя не задано, то действие выполняется для всех  каталогов CI на сервере, заданном параметром Server.

Symptom (необязательный): Задает симптомы, которые надо обнаружить и исправить.

Варианты значений:

• Deadlock
• Corruption
• Stall
• Backlog
• All(по умолчанию)

Если задано 'All', то проверяются все симптомы.

Action (необязательный): Задает действие для устранения симптома. Варианты значений:

• Detect (по умолчанию)
• DetectAndResolve
• Resolve

MonitoringContext (необязательный): Указывает, что сценарий должен выполняться в режиме мониторинга. Возможные значения – $true и $false. По умолчанию равно $false. Если значение равно $true, то события warning/failure записываются в журнал Application.

FailureCountBeforeAlert (необязательный): Задает число ошибок, которые сценарий игнорирует, после чего запишет в журнал событий сообщение об ошибке, которое приведет к появлению алерта в SCOM. Допустимый диапазон значений – [1,100], по умолчанию равен 3. Алерт не генерируется, если значение MonitoringContext равно $false.

FailureTimeSpanMinutes (необязательный): Задает число минут, за которое сценарий подсчитывает ошибки и алерты. Если на момент выполнения сценария количество ошибок за последние FailureTimeSpanMinutes минут превышает значение FailureCountBeforeAlert, то генерируется алерт. Алерт не генерируется, если значение MonitoringContext равно $false. Значение по умолчанию равно 600 минут.

Примеры

C:\PS> .\Troubleshoot-CI.ps1 -database DB01

Определяет, есть ли проблемы с каталогом базы DB01. Попыток исправления не предпринимается.

C:\PS> .\Troubleshoot-CI.ps1 -database DB01 -symptom Stall

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

C:\PS> .\Troubleshoot-CI.ps1 -Server <S001>

Определяет, есть ли проблемы с любыми каталогами на сервере <S001>. Попыток исправления не предпринимается.

C:\PS> .\Troubleshoot-CI.ps1 -database DB01 -Action DetectAndResolve

Определяет, есть ли любые проблемы с каталогом у DB01. Пытается их исправить.

Журнал событий

События, записываемые в журнал Microsoft-Exchange-Troubleshooters/Operational:

5000 Informational The troubleshooter started successfully (сценарий успешно запущен)
5001 Informational The troubleshooter finished successfully (сценарий успешно завершен)
5002 Informational The troubleshooter didn't find any issues for any catalog (сценарий не обнаружил никких проблем ни с одним каталогом)
5003 Informational The troubleshooter didn't find any catalog issues for the specified database (сценарий не обнаружил никаких проблем с каталогом дл указанной базы данных)
5004 Informational Restart of search services succeeded (перезапуск служб поиска выполнен)
5005 Informational Reseeding succeeded for the catalog of the specified database (повторное заполнение каталога для указанной базы данных успешно завершено)
5300 Warning Detected search service deadlock (обнаружена блокировка службы поиска)
5301 Warning Detected catalog corruption for the specified database (обнаружено повреждение каталога для указанной базы данных)
5302 Warning Detected indexing stall for the specified database (обнаружено зависание индексирования для указанной базы данных)
5600 Error The troubleshooter failed with the specified exception (сценарий завершился с исключением)
5601 Error The troubleshooter detected the symptom %1 %2 times in the past %3 hours for catalog %4. This exceeded the allowed limit for failures. (сценарий обнаружил симптом %1 %2 раз за последние %3 часов для каталога %4, это превысило допустимое количество отказов)
5602 Error Search services failed to restart. (службы поиска не смогли перезапуститься)
5603 Error Reseeding failed for the content index catalog of mailbox database %1. Reason: %2 (повторное заполнение каталога индексов контента для базы данных %1 завершилось с ошибкой, причина – %2)
5604 Error Indexing backlog reached a critical limit of %2 hours or more for the specified database (очередь индексирования для указанной базы данных превышает критический предел на протяжении %2 или более часов)
5605 Error Another instance of the troubleshooter is already running on this machine. Two or more instances cannot be run simultaneously. (другой экземпляр сценария уже запущен на этой машине, два и более экземпляра не могут работать одновременно)
6000 Informational The troubleshooter started detection. (сценарий начал обнаружение)
6001 Informational The troubleshooter finished detection (сценарий завершил обнаружение)
6002 Informational The troubleshooter started resolution. (сценарий начал устранение проблем)
6003 Informational The troubleshooter finished resolution. (сценарий завершил устранение проблем)
6600 Error The troubleshooter failed during detection. (сценарий завершился с ошибкой во время обнаружения)
6601 Error The troubleshooter failed during resolution. (сценарий завершлся с ошибкой во время устранения проблем)

Database Latency Troubleshooter

Database Latency Troubleshooter (Troubleshoot-DatabaseLatency.ps1) предназначен для обнаружения и устранения задержек базы. Он обнаруживает и решает следующие проблемы:

• Дисковая задержка
• Задержка Active Directory
• Задержка RPC
• Пользователь, больше всех загружающий процессор

Этот сценарий работает только для локальной почтовой базы.

Проверки Disk Latency

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

"\MSExchange Database ==> Instances($database)\I/O Database Reads Average Latency"
"\MSExchange Database ==> Instances($database)\I/O Database Reads/sec"
"\MSExchange Database ==> Instances($database)\I/O Database Writes Average Latency"
"\MSExchange Database ==> Instances($database)\I/O Database Writes/sec"

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

• Максмальная задержка – 200
• Минимальная скорость чтения – 20
• Минимальная скорость записи – 20

Проверки задержки RPC

Сценарий определяет задержки RPC, проверяя следующие счетчики на почтовом сервере, где расположена проверяемая база:

"\MSExchangeIS Mailbox($database)\rpc average latency"
"\MSExchangeIS Mailbox($database)\RPC Operations/sec"

Используются следующие пороговые значения:

Максимальная средняя задержка RPC – 70
Максимальное количество операций RPC в секунду – 50

Проверки пользователя, больше всего загружающего процессор

Сценарий определяет  наиболее «тяжелого» пользователя (занимающего больше всего процессорного времени), генерируя убывающий список пользователей, которые используют больше всего времени сервера для заданной базы. Он использует вывод Get-StoreUsageStatistics для того, чтобы получить MailboxGuid и время сервера, используемое за тестовый период (10 минут). Если карантин разрешен,то сценарий запишет событие в журнал и перенесет самого "тяжелого" пользователя в карантин.

Параметры

MailBoxDatabaseName (обязательный): Имя базы, которую будет проверять сценарий. Возможные значения:

• GUID
• Distinguished name (DN)
• Database name

LatencyThreshold (необязательный): Максимальная средняя задержка RPC, которую может испытыватьсервер. Пороговое значение задержки – от 1 до 200, по умолчанию 70.

MonitoringContext (необязательный): Указывает, будет ли сценарий записывать события мониторинга в журналы Application и Operations журнала событий.

TimeInServerThreshold (необязательный): Задает пороговое значение для определения пользователей, которые больше всего занимают процессор. Допустимые значения – от 1 до 600000. По умолчанию – 60000.

Quarantine (необязательный): Указывает, переносить ли в карантин наиболее «тяжелого» пользователя. По умолчанию – нет.

Пример

Troubleshoot-Databaselatency.ps1 -MailboxDatabaseName <DatabaseID> [-latencyThreshold <1-200>] [-TimeinServerThreshold <1-600000>] [-Quarantine <switch>] [-MonitoringContext <switch>]

Журнал событий

События, записываемые в журнал Microsoft-Exchange-Troubleshooters/Operational:

5110 Informational The troubleshooter started successfully (сценарий успешно запущен)
5111 Informational The troubleshooter detected latency (сценарий обнаружил задержку)
5411 Warning The troubleshooter quarantined a user (сценарий поместил пользователя в карантин)
5412 Warning Unusual activity found in a mailbox, but quarantine was not specified (обнаружена необычная активность почтового ящика, но в карантин он не помещен)
5710 Error Disk latencies are abnormal for the specified database (ненормальная дисковая задержка для указанной базы данных)
5711 Error DSAccess latencies are abnormal for the specified database (ненормальная задержка доступа к службе каталогов для указанной базы данных)
5712 Error High RPC Average Latencies were detected for the specified database, but the troubleshooter was unable to determine the cause. (обнаружены высокие средние задержки RPC для указанной базы данных, но сценарий не смог определить причину)

Database Disk Space Troubleshooter

Database Disk Space Troubleshooter (Troubleshoot-DatabaseSpace.ps1) предназначен для обнаружения и устранения проблем с размером базы на диске. Он определяет размер базы на диске и определяет причину генерации журналов:

• Он отслеживает, какие пользователи генерируют больше всего журналов
• Он отслеживает доступное пространство на диске для базы и журналов

Сценарий может переносить в карантин наиболее «тяжелого» пользователя на основе занимаемого им дискового пространства и порогового значения времени.

Параметры

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

Замечание:  использовать этот параметр вместе с параметром MailboxDatabaseName нельзя.

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

• GUID
• Distinguished name (DN)
• Database name

Замечание: использовать этот параметр вместе с параметром Server нельзя.

PercentEdbFreeSpaceThreshold (необязательный): Задает процент дискового пространства, занимаемого файлом EDB, при достижении которого Exchange должен переносить пользователей в карантин. Допустимые значения – 1-99, по умолчанию – 25 процентов.

PercentLogFreeSpaceThreshold (необязательный): Задает процент дискового пространства, занимаемого файлами журналов, при достижени которого Exchange должен переносить пользователей в карантин. Допустимые значения – 1-99, по умолчанию – 25 процентов.

HourThreshold (необязательный): Задает количество часов, которое вы можете ждать до исчерпания места на диске. По умолчанию – 12 часов. Допустимые значения – от  1 до 1000000000.

MonitoringContext (необязательный): Указывает, будет ли сценарий записывать события мониторинга в журналы Application и Operations журнала событий.

Quarantine (необязательный): Указывает, переносить ли в карантин наиболее «тяжелого» пользователя или нет. По умолчанию – нет.

Примеры

Troubleshoot-DatabaseSpace.ps1 -MailboxDatabaseName <DatabaseID> [-PercentEdbFreeSpaceThreshold <1-99>] [-PercentLogFreeSpaceThreshold <1-99>] [-HourThreshold <1- 1000000000>] [-Quarantine <switch>] [-MonitoringContext <switch>]

Troubleshoot-DatabaseSpace.ps1 -Server <ServerID> [-PercentEdbFreeSpaceThreshold <1-99>] [-PercentLogFreeSpaceThreshold <1-99>] [-HourThreshold <1- 1000000000>] [-Quarantine <switch>] [-MonitoringContext <switch>]

Журнал событий

События, записываемые в журнал Microsoft-Exchange-Troubleshooters/Operational:

5100 Informational The troubleshooter started successfully (сценарий успешно запущен)
5101 Informational The troubleshooter finished. No problems detected (сценарий завершил работы, проблем не обнаружено)
5400 Warning The database is over the expected threshold (база данных превысила пороговое значение)
5401 Warning Over the threshold, but the database is not growing. No action taken. (база данных превысила пороговое значение, но больше не растет, ничего не предпринято)
5410 Warning The troubleshooter quarantined the specified mailbox. (сценарий поместил указанный почтовый ящик в карантин)
5700 Error The database is over the expected threshold and continues to grow. Manual intervention is required. (база данных превысила пороговое значение и продолжает расти, требуется ручное вмешательство)

Где посмотреть результаты:

Даже если вы запускаете эти сценарии из Exchange Management Shell, большая часть из них выводит в окно очень мало информации. Для того, чтобы увидеть отчеты, вам нужно открыть журнал событий. Исключение – если вы запускаете сценарии в режиме Verbose Mode.

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

Бонус:

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

$servers= get-mailboxserver
while($true)
{
     foreach ($server in $servers)
     {
        .\Troubleshoot-CI.ps1 -verbose -server $server.Name -Action:DetectAndResolve -Symptom:Stall
     }
     sleep 14440
}

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

Стив Брайант

Перевод: Илья Сазонов, MVP