Emergency monitoring script (emon)

Обсуждение вопросов по администрированию СУБД Progress OpenEdge
Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Emergency monitoring script (emon)

Сообщение George » 11 апр 2012, 15:22

Вашему вниманию предлагается emergency monitoring script (a.k.a. emon, что в переводе с французского означает возглас ё-моё :wink: ):
ftp://ftp.progress-tech.ru/pub/Users/george/emon/

Скрипт предназначен для сбора Progress'ой статистики в случае возникновения каких-либо проблем при работе приложения. Если с приложением происходит что-то непонятное, но явно что-то нехорошее - запустите emon скрипт и только потом можно, например, перезапустить базы. Если информация не собрана во время инцидента, то после его завершения будет весьма проблематично установить его причину, а значит остается ненулевая вероятность его повторения. Скрипт собирает весьма подробную информацию, т.е. её объем будет относительно большим - по этой причине скрипт не предназначен для сбора статистики на регулярной основе и/или на больших промежутках времени. Возможно стоит разок собрать скриптом статистику в нормальный период времени, чтобы было с чем сравнивать данные, полученные во время инцидента.

Скрипт сообщает о запуске своих процессов и ждет указанное время. Если по истечении этого времени какие-то процессы всё еще продолжают работать, то появится сообщение "Still waiting...". В этот момент ожидание можно прервать по Ctrl-C. Логи всё равно упакуются в архив, но часть логов может оказаться недописанными. С другой стороны ждать до бесконечности тоже не имеет смысла (процесс мог, например, подвиснуть при подключении к базе и в лог всё равно ничего не писалось). Т.е. скрипт гарантирует, что информация будет собираться в течении ограниченного промежутка времени.

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

Синтаксис:

emon.sh [-h|help] [-t time] [-F] [SaveDir]
где:
-h - подсказка.

-t time - продолжительность мониторинга. Это время будет разделено на три интервала, для которых скрипт собирет статистику.
По-умолчанию продолжительность мониторинга составляет 60 секунд. Минимальная продолжительность - 6 секунд.
Общее время работы скрипта будет на несколько секунд больше, чем то, что задается параметром -t.

-F - использовать опцию -F (Force Access) для запуска promon'а.
Эту опцию следует использовать только если не получается подключиться к базе (или к базам) в нормальном режиме. Возможно, что в будущих версиях скрипта эта опция исчезнет.

SaveDir - директория, в которой будет создан архив всей собранной статистики.
По-умолчанию всё пишется в текущий каталог. Возможно имеет смысл указывать ram диск. На одну базу может приходится порядка 1MB информации.


Перед запуском скрипта должна быть установлена переменная DLC. Статистика будет собираться только для версии Progress'а, на которую указывает переменная DLC. Всё остальное скрипт пытается найти самостоятельно. Тем не менее в скрипте есть внутренние переменные, которые возможно стоит подкорректировать под своё окружение (но в общем случае эти переменные можно оставить как есть):

WrkDirList - список рабочих каталогов Progress'овых процессов. Список используется для поиска protrace файлов. Скрипт сам добавляет к списку рабочие каталоги всех работающих в данный момент Progress'овых процессов, если операционная система позволяет это сделать (есть команды pwdx или procwdx, или линк /proc/$pid/cwd). Также в этот список автоматически добавляются каталоги, в которых лежат все запущенные базы, и workDir'ы всех аппсерверов и прочих тварей, описанных в ubroker.properties файле. Каждый каталог в этом списке будет использоваться как стартовый для команды find, т.е. если приложение для каждой новой сессии создает свой временный подкаталог, то в списке достаточно указать их корневой каталог - find прочешет все его подкаталоги.

CmdList - команды, которые следует использовать для мониторинга работы операционной системы. Команды выбираются в зависимости от ОС. Помимо самих команд стоит обратить внимание на параметры запуска команд - например на возможность добавлять в вывод время каждого интервала, для которого выводится статистика.

DbLogLimit=100000
UBLogLimit=10000
Количество последних строк, которые будут копироваться из логов баз (DbLogLimit) и логов аппсерверов (UBLogLimit).

Широкие возможности для корректировки предоставляет функция SysEnvInfo(). Там можно использовать любые команды, которые скажут что-то полезное об операционной системе и о железе, на котором она работает. Вывод будет сохранен в файл env.sys.*.txt.


Версия скрипта не является окончательной. Планируются следующие доработки:

1) Запуск с параметром -t 0 будет означать сбор логов, protrace файлов и прочего, но без запуска мониторинга баз и операционной системы.

2) Тестовые подключения к базам. Проверка возможности подключиться к каждой из баз через разделяемую память. Если это не удается сделать, то скрипт попытается выяснить причину - локирован ли логин-семафор или USR латч.

3) Для каждой базы будет собираться статистика _TableStat/_IndexStat/_UserIO по тем же трем интервала в течении всего мониторинга. Я не уверен в необходимости собирать статистику из _UserTableStat/_UserIndexStat, это может оказаться ресурсоемкой процедурой, которую не стоит запускать в то время, когда системе и без того плохо. Впрочем при небольшом количестве пользователей можно собрать и такую статистику.

Буду рад услышать предложения по доводке скрипта.

Я старался сделать скрипт годным для запуска под разными версиями Unix'а, но возможно мне это не вполне удалось. У меня нет возможности протестировать скрипт под разнообразными ОС, на которых может работать Progress. Сообщайте об обнаруженных в скрипте ошибках, я буду их исправлять. Опробуйте скрипт сначала на "кошках" и только потом переносите его в рабочее окружение. Несмотря на то, что скрипт не делает ничего опасного, лучше перестраховаться. Если вы запустили скрипт и он успешно отработал, пожалуйста сообщите в этой теме на каком Unix'е это было сделано и пришлось ли корректировать скрипт. Другие смогут смелее использовать скрипт на той же ОС.
Последний раз редактировалось George 24 июл 2012, 15:10, всего редактировалось 1 раз.

Аватара пользователя
dmitri
Старожил
Сообщения: 1016
Зарегистрирован: 04 авг 2005, 16:19
Откуда: Pennsylvania, USA

Сообщение dmitri » 11 апр 2012, 22:29

Dmitri Levin and

Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 14 апр 2012, 10:06

Скрипт прошел проверку на AIX'е и Linux'е.
По результатам тестов в скрипт внесены небольшие изменения.
Также добавлена поддержка нулевой продолжительности мониторинга (-t 0).

По-прежнему требуется добровольцы для тестирования скрипта под другими типами Unix'а.

Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 07 июн 2012, 10:34


Аватара пользователя
Goldenhands
Старожил
Сообщения: 123
Зарегистрирован: 30 май 2011, 11:41

Сообщение Goldenhands » 08 июн 2012, 09:05


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 08 июн 2012, 11:24


Аватара пользователя
Goldenhands
Старожил
Сообщения: 123
Зарегистрирован: 30 май 2011, 11:41

Сообщение Goldenhands » 08 июн 2012, 13:46


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 08 июн 2012, 14:05


Аватара пользователя
Goldenhands
Старожил
Сообщения: 123
Зарегистрирован: 30 май 2011, 11:41

Сообщение Goldenhands » 08 июн 2012, 14:45


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 08 июн 2012, 15:07


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 09 июн 2012, 08:06

Исправил DbStatMon. Считаю, что программа готова к запуску на реальных базах в рабочем окружении:
ftp://ftp.progress-tech.ru/pub/Users/ge ... bStatMon.p

Краткое описание:
Программа работает только с одной базой и собирает статистику по каждой сессии, подключенной к этой базе (DbAccess, DbRead, BiRead, открытая транзакция, какой ресурс ждет, выставлены ли для сессии флаги Disconnect, Resync). Количество интервалов для сбора статистики и их продолжительность определяется переменными vMonCount и vMonIntrv.

По-умолчанию отключена проверка числа локировок записей, которые держит сессия. Если такую проверку включить (vCheckUserLock = true), то даже в этом случае информация будет собираться не для всех сессий (только "локальные максимумы"), но в итоге будет найдена одна сессия с максимальным числом локированных записей. Побочным следствием включения сбора такой информации может стать, как уже выше писалось, значительное увеличение времени снятия статистики (до секунд или десятков секунд) с возможным торможением пользовательских сессий, активно работающих с таблицей локировок. А может и не стать - эффект от чтения записей в _UserLock трудно предсказать.

Среди всех сессий выбираются самые активные - топ-лист по DbAccess и по DbRead, топ-лист по долгооткрытым транзакциям, сессия с максимальным числом локированных записей (если сбор такой статистики включен), все сессии, которые занимаются откатом своих транзакций или которым выставлен флажок на отключение, но они по какой-то причине этого не сделали. Размер топ-листов можно настраивать (по умолчанию он равен пяти). Кандидат в топ-лист должен показать результаты, превышающие пороговое значение - разумеется, пороги свои для каждого топ-листа. Всё это делается для того, чтобы выбранных сессий было немного.

Для выбранных сессий собирается статистика их обращений к таблицам и индексам (начиная только с V10.1B) и какие программы они в это время выполняют (начиная только с V10.1C).

Так же собирается суммарная (по всем сессиям) статистика обращений ко всем таблицам и индексам и в целом по базе (Read, Update, Create, Delete, OsRead). Значение OsRead доступно, начиная только с V10.2B и только для объектов, расположенных в областях второго типа. Также собирает статистика по секвенциям (эта активность в базе обычно остается за кадром) - количество изменений по каждой из секвенции (число вызовов NEXT-VALUE) и общее по всем секвенциям число чтений (число вызовов CURRENT-VALUE).

Собранная статистика выводится в соответствующие текстовые файлы, которые предназначены для работы в Excel'е: (*.TableStat.txt, *.IndexStat.txt, *.SeqStat.txt, *.UserStat.txt, *.UserCache.txt). Кроме того создается файл *.Timing.txt, в который пишутся тайминги выполнения отдельных процедур программы. Предполагается, что на сбор статистика каждый раз должно уходить меньше секунды даже для баз с большим количеством объектов и с большим количеством подключенных сессий. Тайминги можно использовать в качестве непрямого теста на наличие проблем с производительностью в базе. Если -tablerangesize или -indexrangesize имеют недостаточные значения для того, чтобы охватить мониторингом все таблицы и индексы, то файл *.Timing.txt изменит своё название на *.Warning.txt. В файле можно найти значения, которые должны иметь эти параметры, чтобы статистику можно была собирать по всем пользовательским таблицам и индексам.

Программа может запускаться с версиями Progress'а младше 10.1B, но при этом потеряется главная особенность данной программы - сбор расширенной статистики по выбранным пользователям. Я не проверял с какой минимальной версии Progress'а программа откомпилируется без ошибок. Например, для работы с секвенциями программа использует функцию DYNAMIC-CURRENT-VALUE, которая появилась только в V9.1E, а значит на более ранних версиях точно возникнет ошибка. Если вы используете Progress версии 10.1B или выше, но при компиляции возникает ошибка 201 (** Unknown Field or Variable name), то это значит, что на базе, на которой происходит компиляция, при смене версии Progress'а не была выполнена команда proutil -C updatevst. В таком случае соответствующий функционал в программе можно отключить, изменив имя флажка, который за него отвечает (например заменить Version_GE_101B на notVersion_GE_101B). Или при удобном случае запустить на базе updatevst.

В принципе некоторые значения в полученных отчетах нуждаются в дополнительных комментариях. Например, откуда программа берет значение числа уровней индексных деревьев и насколько этой информации можно доверять. :wink: Позже постараюсь сделать более подробное описание содержимого файлов.

Буду благодарен за замечания и предложения по расширению функционала программы.

Аватара пользователя
Arelav
Администратор
Сообщения: 1881
Зарегистрирован: 25 мар 2005, 17:05
Откуда: Progress Technologies

Сообщение Arelav » 09 июн 2012, 09:02

Юра, привет,

Может стоить создать Open Source проект, сделать репозиторий где-нить на https://github.com/ или даже на http://code.google.com/intl/ru-RU/ ?


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 09 июн 2012, 09:17


Аватара пользователя
Goldenhands
Старожил
Сообщения: 123
Зарегистрирован: 30 май 2011, 11:41

Сообщение Goldenhands » 11 июн 2012, 14:45


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Сообщение George » 11 июн 2012, 15:28