Коллеги, app сервера мониторятся средствами Tivoli monitoring.
Мониторятся сервис и 30999. В лог сервера валятся подобные оповещения.
Пт, 04/05/2012 11:59:05 <Trace> The server socket for the ITP service on port 30999 had an invalid request
Пт, 04/05/2012 11:59:09 <Trace> The request was send by 192.168.0.45 with ip address 192.168.0.45 from port 54283
Пт, 04/05/2012 11:59:09 <Trace> Invalid ITP connection: Unexpected EOF.
Не знаете от них избавиться? Кроме варианта с отключением мониторинга доступности по порту
Коллеги,
Возникла похожая ситуация, но в несколько большем масштабе. В течение некоторого времени планируется открыть филиал с 200-250 операторами и инженерами. Будет ли хватать канала в ~100мбит на подключение толстыми клиентами (app сервера в головном офисе Москве)? Или лучше вынести app сервера в филиал с расчетом канала по 10мбит на app server. Можно ли для этого варианта разделить пул серверов доступных для подключения (пользователям филиала доступны только серверы филиала)?
Коллеги,
Возникла следующая проблема - в организации установлен hp ov service desk в следующей конфигурации:
OS: windows server 2008 x86
app server: SP36
java version "1.6.0_31"
Java SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot Client VM (build 20.6-b01, mixed mode, sharing)
При запуске батником от пользователя сервер работает нормально.
При запуске как сервис вылетает с ошибкой в логе windows:
Faulting application sd_serverservice.exe, version 0.0.0.0, time stamp 0x3d295e53, faulting module ntdll.dll, version 6.0.6002.18327, time stamp 0x4cb73436, exception code 0xc0000005, fault offset 0x000670b9, process id 0xdb4, application start time 0x01ccfc68dade80d5.
Виктор, для расчета длительности с помощью добавленных полей можно использовать Данные-Рассчитываемые поля-ServiceCall. Должно считаться без учета уровня сервиса.
Расчеты же с учетом уровня сервиса делаются обычно для того, чтобы не получать отрицательных данных в часы\дни, когда заказчик по договору не поддерживается.
Варианты с подсчетом времени обработки на 1-й линии следующие:
1. При назначении на группу заявка переводится в следующий статус (допустим, из "Зарегистрировано" в "Назначено"), при этом правилом в custom поле "Время назначения" устанавливается текущая дата. Далее с помощью какой-либо системы отчетности считаем разницу между датой регистрации и временем назначения (среднее значение для группового показателя).
2. Вариант без использования дополнительного поля (тяжелый и неоптимальный). С помощью sql-запроса из таблицы с историей по заявке ищем дату изменения статуса и также считаем разницу.
3. Вариант для расчета времени обработки на 1-й линии с учетом уровня сервиса. При переводе в следующий после автоматической регистрации статус перенести в поле "планируемое начало (может называться по-другому в вашей локализации)" дату регистрации, а поле "планируемое окончание" текущую дату. В поле "планируемый срок" посчитается необходимый вам параметр в часах\минутах. Посчитается он исходя из: уровня сервиса в установленном в заявке SLA\рабочих часов рабочей группы\24х7, в зависимости от настроек системы.