Блог Бафа

После достаточно длительной подготовки по написанию и тестированию скрипта по установке службы SNMP на Windows сервера в подразделениях понадобилось оценить потери бойцов, а конкретно сколько MS SQL Server'ов упало в результате моей деятельности В итоге на нескольких  серверах сервис MSSQLSERVER был всё же остановлен, и о причинах, почему используемый мною в скрипте workaround не помог - ещё предстоит исследовать.

Отследить требовавшиеся мне события очень просто - был известен период запуска скрипта по установке службы SNMP и требовалось отловить event'ы с вполне определённым ID'ами: 7035, 7036 источником которых является Service Control Manager, с текстом, содержающим "sql", сигнализирующие о случаях, когда в результате установки службы SNMP несмотря на все принятые меры MS SQL Server всё же прекращал свою работу.

Текст событий:
Служба "SQL Server (MSSQLSERVER)" перешла в состояние Остановлена.
Служба "SQL Server (MSSQLSERVER)" успешно отправила управляющий элемент "остановить".

Я попытался написать скрипт на Powershell, который бы находил нужные мне события. И у меня это даже получилось (как обычно, на коленке):

$user = $env:username
 $servers = gc "C:\Documents and Settings\$user\Рабочий стол\servers.txt"

$After = get-date "2/07/12 09:34"
 $Before = get-date "2/08/12 09:35"

foreach ($server in $servers)
 {
write-host "Обрабатываем" $server "`n"
$Events = get-eventlog -logname "System" -computername $server -before $before -after $After -message "*sql*"
$Events | out-gridview
$events | %{write-host $_.EventId $_.Message $_.MachineName $_.UserName, $_.TimeGenerated}
 }

Проблема была в том, что скрипт отлично и быстро выполнялся на моей локальной машине (слава SSD!), медленно на серверах и уж совсем и очень грустно на удалённых серверах, связь с которыми ведётся по весьма небыстрым каналам. Я был не вполне уверен, но было ощущение, что скрипт просто зависает. С учётом, что итоговое множество, на которых мне нужно было найти события равнялось нескольким сотням - операция была бы очень медленной и грустно. После этого я добавил в скрипт вывод даты начала и окончания сбора статистики и выяснил ну очень удручающие данные:

07.08.2012 13:58:16
 Обрабатываем test_server
 ----
 7036 Служба "SQL Server (MSSQLSERVER)" перешла в состояние "Остановлена". test_server  02.08.2012 9:36:25
 7035 Служба "SQL Server (MSSQLSERVER)" успешно отправила управляющий элемент "остановить". test_server  02.08.2012 9:36:25
 ----
 07.08.2012 14:46:24

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

В утилитку EventCombNT был загружен список целевых серверов, указана дата искомых событий с помощью меню Options -> Set Data Range, искомые ID'ы событий, источник и текст (в моём случае "sql").

Полученный итог не может не радовать:
Просмотрено записей: 7227941 (7 миллионов!)
Найдено соответствующих записей: 6 (это хорошо, чем меньше, тем лучше
Производительность: 2250 записей в секунду (при 50 потоках)
Итого прочитано: 1,24Gb (!)
Целевых серверов: 372
Время выполнения: 55 минут

После проделанной работы мною были сделаны некоторые выводы.

• Массовые мероприятия, в т.ч. установки/модификации ПО, особенно могущие повлечь за собой какие-либо печальные последствия должны проходить под присмотром обученного персонала. В моём случае я был отвлечён на очередную аварию, и у меня не было возможности контролировать процесс.

• Массовые мероприятия должны иметь подготовленные заранее инструменты мониторинга успешности, а так же отслеживания возможных проблем. В моём случае - требовалось иметь понимание и умение пользоваться соответствующими инструментами для отслеживания событий, которые позволят выполнить это наиболее эффективно. В моём случае наиболее эффективным оказался специализированный софт, в других случаях это могут быть простые (или не очень) скрипты на Powershell / VBS. Это позволит как можно быстрее отреагировать на проблемы.
• Скрипты это клёво, без них как без рук, особенно если нет возможности найти специализированный софт. Нужно постоянно совершенствоваться в их изучении / составлении, чтобы иметь возможность как можно быстрее делать маленькие инструменты для everyday use.

P.S. Нашёл информацию, что командлет Get-WinEvent работает значительно быстрее, позволяя фильтровать данные на машине источнике. Но, к сожалению, он работает только для 6.0/6.1