Василий Каменев (все сообщения)

не, spot мониторит сессии скула. 1000 это круто, апп сервера столько не сделают, а если делают, то есть явно проблема с сессиями на лицо!!
по умолчанию у апп сервера стоит 16 сессию на, если включены "репы", то ещё добавится 6, итого 22. больше сервер не поднимет сессий в sql сервер.
посмотри свои настройки и посчитай по серверам сумму сессий, всё что больше - левые, либо падает нет и они зависаю, либо просто зависаю а сервер делает рестарт, либо их создает др. софт вообще.

а про что вопрос: чтоб сделать самому(мим) плагин? чтоб его купить? чтоб повесить TZ на внешний скрипт?

Создание через sd_event Инцидентов(IN) в СД не проблема. Проблема начинается тогда, когда захотите дополнить или закрыть открытый IN. Тут нужно выбрать поле(я) по которым будет идти сравнение. Если это КЕ, то тут понятно оно уникально и можно использовать его в качестве поля поиска, плюс статус. Но тут возникает вопрос в синхронизации имён КЕ и их имени в мониторинговой системе, что не всегда реально - это первая проблема. Если использовать любое другое поле, например SourdeId, то тогда для обновления или закрытия последующий эвент должен иметь тот же текст что уже записан в SourceID. Иначе будет создан новый IN, и это будет Event storm. Они начнут плодиться как кролики. Это проблема вторая. В таком случае чтоб её избежать надо хранить SourceID или ID в самой системе мониторинга, что не позволяют делать они и сам sd_event не возвращает результат поля - это проблема третья. Если удастся их решить, то эвент система заработает как часики - будет открывать, обновлять и закрывать сама эвенты.
Решение упирается в любом случае в доработку, либо на стороне СД, либо на стороне мониторинговой системы. Так на стоне мон. системы вы должны знать её внутреннюю организацию мон. системы, одной, потом другой, это довольно муторно и отнимет много времени на тест, потом на внедрение. Можно конечно использовать вебсервис, это легче, но не все мон. системы умеют работать с ними и тогда надо доработать будет ещё и мон. систему. Так что самый логичный вариант использовать почту, потому как любая мон. система имеет интер-с для настройки посылки майла. Так вот это вам и нужно сделать или если есть прогр. в вашей орг-и, то эта задача для них. Если будет интерес к нашей разработке в этой область, то пиши мне или Григорию, она есть и она работает.

эта ошибка возникает когда атрибут действительно открыт другим пользователем. Это может быть реальный пользователь , но иногда бывает просто зависший процесс. Об этом можно смотреть в БД, таблица IFC_ENTITYUSAGES.

Код

Вот вот, и я о том же - неправильно тут использовать изменения. <br />Изменения должны создаваться, если пользователь требует внести изменения в функционал, инфраструктуру итд. Change management имеет своей целью отследивать изменения и связывать их с Инцидентами, чтобы понимать, какое Изменение повлекло тот или иной Инцидент. А какой Инцидент может повлечь создание нового рабочего места? Такой запрос - это чистой воды ServiceCall.

да нет же, правильно! пользователь может и не требовать, а обращение становиться Изменением. Он может думать что это "один клик" , а реально работа для нескольких групп.