В данной публикации предлагается костыль решение, позволяющее автоматически отслеживать сбои службы 1С и выполнять необходимые действия.
Мониторинг работоспособности службы 1С осуществляется с помощью регламентного задания и vbs-скрипта. Принцип работы следующий: создается регламентное задание, которое 1 раз в минуту делает запись в текстовый файл. В то же время, с помощью планировщика Windows, раз в две минуты запускается специальный vbs-скрипт, который проверяет время модификации этого текстового файла. Если время модификации остается неизменным в течение нескольких проверок, значит регламентное задание не выполняется, что вероятнее всего является следствием зависания службы сервера. Тогда скрипт выполняет определенное действие — либо перезапускает службу, либо отправляет уведомление на электронную почту, либо и то и другое.
Процедура записи в текстовый файл регламентным заданием элементарна и может выглядеть следующим образом:
&НаСервере Процедура ОбновитьФайлМониторинга() Экспорт ИмяФайлаМониторинга="C:check.txt"; ТД=Новый ТекстовыйДокумент; ТД.Записать(ИмяФайлаМониторинга); КонецПроцедуры
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А чем не устроил технологический журнал
мы вот такую «поделку» сделали
(1) вещь, конечно, полезная, но чем она поможет в случае внезапного падения службы 1С?
Мониторинг работает ли служба прекрасно делается «GFI N.S.M. 7 Activity Monitor»
а определять автоматом зависла ли она или нет по например времени отклика считаю некорректно, может сервер расчеты выполняет тяжелые какие-нибудь
(2) а вы пробовали пользоваться? 🙂
покажет возможные причины или как минимум образовался ли дамп, где лежит, что можно отправить в 1С на техподдержку
ну не ребутить же циклически
(3) bykasan, а зачем вообще мониторить зависание, пользователи Вам лучше всякого мониторинга «леща» сделают )
а вот с причинами разбираться однозначно надо, но это работа часто постфактум…
(3)Работа скрипта проверена почти годом использования — всегда отрабатывает корректно, даже когда сервер загружен на 100%. Регламентное задание, если служба работает нормально, всегда выполняется по расписанию.
«GFI N.S.M. 7 Activity Monitor» — это софт по-моему немного для других целей, для данной задачи он слишком громоздок, сложен в настройке, функционал до конца не ясен и к тому же программа платная.
(4) (5) Gilev.Vyacheslav, анализ, конечно нужен, но и проблему нужно решать оперативно. К тому же не всегда анализ может дать ответ. Бывает так, что сама служба не останавливается, а начинает глючить — регламентные задания перестают выполняться, клиенты не могут подключиться. Про скорость реакции техподдержки 1С лучше вообще не вспоминать.
А что касается лещей от пользователей — то это кому как нравиться) Если кто-то без пилюлей как без пряников, то пожалуйста. А если надо что бы работало, то я предлагаю вариант.
т.е. я правильно понял, что под мониторингом подразумевается рестарт службы если что то зависло?
(8) Gilev.Vyacheslav, «Тогда скрипт выполняет определенное действие — либо перезапускает службу, либо отправляет уведомление на электронную почту, либо и то и другое.» — можно настроить как угодно.
а чем штатный перезапуск не устраивает ?
(10) Gilev.Vyacheslav, т.к. он периодичный, то он не решает проблему сбоев, возникающих в период между запланированными перезапусками. А сбой может появиться в любой момент.
давайте уточним что за «сбой», у вас на сервере сколько рабочих процессов? циклический перезапуск рабочих штатными средствами кластера организован?
падает ли при сбое процесс сервера 1с? какой?
какие сообщения об ошибках при сбое получают пользователи? получают ли?
(12) Gilev.Vyacheslav, 3 рабочих процесса, циклический перезапуск не настроен. 2-3 раза в месяц бывают такие сбои:перестают выполняться регламентный задания, хотя сервер остается доступен; невозможно подключиться к серверу, хотя служба работает.
У вас мог зависнуть планировщик фоновых заданий. А пользователи замечательно работают. И тут вы их всех жестко выкидываете.
(14) bulpi, вы внимательно читаете? «…либо перезапускает службу, либо отправляет уведомление на электронную почту…».
Каждый решает для себя что ему важнее — нормальное функционирование системы или отключение пользователей на 1 минуту, если они вообще будут в этот момент в базе. И, кстати, не всегда перезапуск службы отрубает пользователей.
У нас другой прикол.
Подрядчики подключили внешнее оборудование (с сетевым интерфейсом) через натив библиотеки. И если оборудование не доступно (отключено, заглючило…), начинают расти дескрипторы процесса rphost, объяснили проблемами платформы. На 2003 м виндовом сервере при отметке в 3000 — 4000 дескрипторов весь сервер уходит в себя, помогает только физический ресет сервака, благо виртуализированный.
В итоге пришлось написать сервисную приблуду которая мониторит к-во дескрипторов процесса и рестартует в случае их количества больше 2000.
Может это тоже как то решаемо цивилизованными методами?
(13) возможно я не прав, но мне кажется что рестартом вы не решаете проблему, а просто оттягиваете «ее»
если «не работают» фоновые задания, то любые ли фоновые задания не работают? в разных версиях платформы проверяли это поведение? смотрели ли записи EXCP в технологическом журнале когда фоновые задания перестают работать?
исключительно для локализации проблемы (Не для эксплуатации) в момент подвисания фоновых заданий можно создать новый кластер, прописать там ту же информационную базу и проверить, а из него фоновые задания работают (только не пишите фоновыми заданиями, а только читайте)
(17) Gilev.Vyacheslav, на самом деле, в моём случае, рестарт решает проблему. Можно, конечно, попытаться сделать всё что вы написали, только всё это слишком хлопотно и вероятность что как-то поможет, мне кажется, не высока. Даже если что-то и удастся выяснить, то что можно будет сделать? Служба настроена и 95% времени работает нормально, а сбои в её работе — это результат багов платформы, которых, как общеизвестно не лишены продукты 1С. Впрочем, как и продукты других компаний.
(18) пока что наша практика показывает, что баги вызваны неумением применять продукцию 1С, хотя конечно часто конфигурации (доработанные чаще всего!) этому не способствуют и предполагают что вы эксперт в этой области
т.е. это не 1с плохая, а проблемы надо решать, а не менять одну программу на другую, я еще не видел ни одной программы которая была бы идеальна…
(19) Gilev.Vyacheslav, так никто и не говорит что 1С плохая), действительно, идеальных программ не существует. Может и я чего-то делаю не так, надо будет ещё поразбираться.
Ну а пока данное решение работает и обеспечивает непрерывное функционирование программы, может оно и кому ещё поможет. А там глядишь и 1С что-нибудь более стабильное и надежное выпустит.
(20) пока фирма 1с не узнает о проблеме, она не сможет ее решить, вы не сообщаете фирме 1с о проблеме, зато ждете пока она ее решит — изъян в своей логике не находите?
(21) Gilev.Vyacheslav, ну сообщить о проблеме это ещё не гарантирует, что её решат — есть, например, официально зарегистрированные в 1С баги типовых конфигураций, которые остаются не исправленные годами.
А к вопросу об изъяне в логике, я считаю, что корпорация, занимающаяся разработкой ПО, если она заботится о качестве своего продукта, должна иметь собственные отделы тестирования, где выявлением багов и глюков должны заниматься специалисты, а не перекладывать полностью эту функцию на пользователей.
(22) вот так все по кругу и происходит, разработчики надеются что вы их оповестите о проблемах, вы считаете что другие оповестят, другие думают что тоже другие оповестят, а в результате имеем то что имеем 🙂
Думаю дальше обсуждать нечего, поскольку из того как вы излагаете вы глубоко тестированием не занимались, и плохо представляете о чем рассуждаете. На досуге подумайте, как бы написать систему тестирования так, чтобы она обнаруживала все теоретические ошибки )))
Спасибо автору за идею! Очень полезная )
у флагмана, видать, досуга не бывает — все о деле, о деле…