---
# System prepended metadata

title: Описание сценариев для МосГорТелекома
tags: [ТЗ]

---

# Описание сценариев построения сервисов для МосГорТелекома

## Сценарий 1. Мониторинг по ICMP

Группа содержит 3 IP ареса ( это скорее всего  один маршрутизатор). 

Опрос Адресов идет по ICMP.
Для каждого адреса оператором устанавливается отдельный вес. Вес указывается через ГУИ.

Может быть установлен следующий вес:
- Вес 3 Используется для адреса интерфейса резервного канала.  
- Вес 6 Используется для адреса основного канала. 
- Вес 9 Для общего адреса, скорее всего адрес ЛАН или Loopback.

"По недостуности" кажого адреса формируется аварий "Ping Fail".
Параллельно производится проверка аварий для всех адресов в группе и суммирование весов. 

Далее формируется групповая авария  "Статус Сервиса" по следующим правилам. 

### Определние статуса сервиса

На сервис генерируется авария с уровнем приоритета "Critical"  если сумма весов недоступных адресов >= 10

На сервис генерируется авария с уровнем приоритета "Degraded"  если сумма весов недоступных адресов >= 6

На сервис генерируется авария с уровнем приоритета "Slightly Degraded"  если сумма весов недоступных адресов >= 3




## Сценарий 2. Мониторинг по SNMP 

Группа состоит из 2 IP адресов. Адеса могут быть физически заведены на одном маршрутизаторе). Адрес определят интерфейс. основной или резервный. 

Дополнительно для этих обектов принимабтся  SNMP Трапы (возмоно опрос статуса по SNMP). По статусу BGP или других роутинговых сессий.  Привязка адреса соседа в пире к интерфейсам  производится по вхождению адреса пира и интерфейса в одну IP подсеть.  

При переходе интерфейса в состояние DOWN или разрыве сессии формируется аварийя. 

Дополнительно формируется групповая аваиря "Статус Сервиса", в которую входят все аварии по сессиям и интерфейсам для всех адресов в группе. 


Возможно также использовать вес, который указывается через  ГУИ.
Хотелось бы так же видеть/определять в ГУИ, там же где выставляется вес, что для объека мониторится статус интерфейса и состояние роутинговой сессии.


### Определение статуса Сервиса

Сервис считается:
- "Down" -  если оба интерфейса (по IP адресам) "Down" либо все сессии для обоих IP аресов разрваны.
- "Degraded" если один интерфейс "Down" либо одна сессия разорвана.

## Сценарий 3
"Выборы УИК"
- Контейнер 1 6 IP - по ICMP   на каждом вес 15 

- Контейнер 2  1 IP Адрес SNMP и ICMP (ИБП)
  IP недоступн   -  вес 45
  SNMP трап  "Пропадание внешнего питания" - 45


### Определение статуса Сервиса

Суммируем вес по обоим контейнерам. 

- Вес всех аварий в группе >= 75  Critical/Down
- Вес всех аварий в группе >= 45  Degraded 

# Авария "Статус Сервиса"

Для аварии "Статус сервиса", и производится эскалачия через WEBService API.

В аварию должны быть добвлены следующие данные:
1.	Шаблон HP SM (String); (Константная строка определяется для каждого сервиса)
2.	Код из внешней системы (String);
3.	Приоритет (String);
4.	Краткое описание (String);
5.	Описание (Array);
6.	ФИО (String);
7.	Телефон (String);
8.	E-mail (String);
9.	Номер услуги (String);
10.	Номер ГК (String) (4 последние цифры);
11.	Местоположение (String);
12.	Идентификатор базовой услуги (String)


Вес эти данные привязаны к группе


## Изменение уровня критичночти аварии "Статус Сервиса"

Неоходимо предусмотреть ситуации когда сначала генерируется авария "Degraded"  а потом у сервиса  меняется статус на "Down".  Соотвественно изменение статуса посылает обновление в виде новой(повтороной) ескалацией. 
Ну и при закрытии в обратную сторону. 




