Commit a8fadb21 authored by Andrey Vertiprahov's avatar Andrey Vertiprahov
Browse files

Add Fault Management Background.

parent 43c4e9ef
# alarms check
<!-- prettier-ignore -->
!!! todo
Describe *alarms* check
## Requirements
* [get_alarms](../../../../dev/reference/scripts/get_cpe.md)
* alarms check is enabled in [Managed Object Profile](../../../../user/reference/concepts/managed-object-profile/index.md)
# UI Design Principles
## Описание
Работа пользовательского интерфейса с сущностями системы во многих случаях сводится к набору типовых операций:
* Получение списка сущностей, возможно, с фильтрацией и заданием лимитов
* Получение данных для сущности
* Создание новой сущности
* Редактирование сущности: Как одного поля, так и всех полей в целом
* Удаление сущности
В результате анализа мы пришли к выводу, что в разных частях интерфейса одна и та же сущность может быть представлена в нескольких видах:
* id, текст -- для combobox
* набор редактируемых полей - для формы редактирования.
* сжатая информация - для всплывающих подсказок.
* Расширенная информация, включающая в себя и часть связанных сущностей - карточки объекта и так далее.
В связи с этим было решено ввести в API такое понятие как `View` - фактический вид сущности.
В информационных запросах `View` должен быть частью пути url по двум причинам:
* FastAPI не поддерживает роутинг по `querystring`
* Для каждого `View` тип `response` отличается кардинально.
Делать несколько типов ответов и объединять их через Union - крайне плохой вариант,
так как пользователь API не будет заранее знать, в каком виде ему ожидать ответ.
Делать один тип ответа с большинством полей в `Optional` - еще более худший вариант,
так как тогда у пользователя вообще не будет понимания,
в каком случае может быть заполнено конкретное поле.
Предлагается принять соглашение о следующем наборе view:
* `default` - вид по умолчанию (если не задан). Если не определен, использовать preview
* `label` - для комбобоксов - id + метка + стиль + иконка (если есть)
* `short` - короткий preview для комбобоксов, если не определен, используется preview
* `preview` - просмотр
* `full` - самый расширенный вариант, если не определен, использовать preview.
* `form` - форма редактирования
* `secret` - показать credentials?
Предлагается следующая иерархия URL
* GET `/api/ui/<сущность>?<filter>` - список сущностей (результат сформатирован для view default)
* GET `/api/ui/<сущность>/v/<view>?<filter>` - список сущностей (результат сформатирован для заданного view)
* GET `/api/ui/<сущность>/<id>` - данные для сущности с <id> (результат сформатирован для view default)
* GET `/api/ui/<сущность>/<id>/v/<view>` - данные для сущности с <id> (результат сформатирован для заданного view)
* POST `/api/ui/<cущность>` - создать новый объект.
* PUT `/api/ui/<сущность>/<id>/v/<view>` - редактировать объект с заданным набором полей
* DELETE `/api/ui/<сущность>/<id> - удаление объекта
То есть вводится дополнительный классификатор-суффикс:
* `/v/<view>` - использовать формат `<view>`
* `/a/<action>` - запуск дополнительного действия для объекта
## Открытые вопросы
* Завязывать ли POST на view?
\ No newline at end of file
......@@ -4,7 +4,8 @@
Получение инвентарной информации из внешней системы позволяет автоматизировать добавление оборудования и настройку НОКа.
Для этого в составе системы предусмотрена поддержка механизма `ETL`. Основная применяемая терминология:
* Внешняя система [Remote System](../../../user/reference/concepts/remote-system/index.md) - cистема, являющаяся источником данных для работы ETL
* Внешняя система [Remote System](../../../user/reference/concepts/remote-system/index.md) - источник данных для работы ETL
* `Extractor` - Адаптер *выгрузки*, модуль на `Python` отвечающий за извлечение информации из `Внешней системы`, преобразование её к необходимому для работы формату
* `Loader` - адаптер *загрузки*. Создаёт сущности в НОКе и формирует файл привязки (`mapping file`)
* `mappings` формирует привязку между ID системам (ID НОКа <> ID внешней системы)
......
# events.POOL Stream
# Потоки events.POOL
`events.POOL` stream is a part of [Events Pipeline](index.md#events-pipeline).
Registered events are passed in unified way from various collectors
to classifier service for further analysis.
Each system [Pool](../../../user/reference/concepts/pool/index.md) has separate
`events` stream instance. i.e. `DEFAULT` pool will use `events.DEFAULT` stream,
while `CORE` pool will use `events.CORE` stream.
У каждого пула [Pool](../../../user/reference/concepts/pool/index.md) отдельный поток
`events`. Например пул `DEFAULT` будет использоваться поток `events.DEFAULT`,
когда пул `CORE` - поток `events.CORE`.
## Publishers
## Отправители
- [ping](../../../admin/reference/services/ping.md) service.
- [syslogcollector](../../../admin/reference/services/syslogcollector.md) service.
- [trapcollector](../../../admin/reference/services/trapcollector.md) service.
## Subscribers
## Слушатели
- [classifier](../../../admin/reference/services/classifier.md) service.
## Message Headers
## Заголовки сообшения
`events` stream doesn't use additional headers.
У потока `events` отсутствуют дополнительные заголовки.
## Message Format
## Формат сообщения
`events` stream carries JSON-encoded messages.
Потоки `events` передают сообщения закодированные в JSON.
| Field | Type | Description |
| Поле | Тип | Описание |
| --------------------- | -------------------- | -------------------------------------- |
| `ts` | Integer | Event timestamp, UNIX epoch |
| `object` | Integer | Managed Object Id |
| `data` | Object {{ complex }} | Message Data |
| {{ tab }} `source` | String | Message source: |
| {{ tab }} `source` | String | Message source: |
| | | ping |
| | | syslog |
| | | SNMP Trap |
| {{ tab }} `collector` | String | Pool name |
| {{ tab }} `message` | String | Incoming syslog message, if any |
| {{ tab }} `<OID>` | String | SNMP Trap varbinds in key-value format |
| `ts` | Integer | Время регистрации события (UNIX epoch) |
| `object` | Integer | Идентификатор устройства-источника (`Managed Object`) |
| `data` | Object {{ complex }} | Данные сообщения |
| {{ tab }} `source` | String | Источник сообщения: |
| | | {{ tab }} ping |
| | | {{ tab }} syslog |
| | | {{ tab }} SNMP Trap |
| {{ tab }} `collector` | String | Пул коллектора |
| {{ tab }} `message` | String | Сообщение `syslog` |
| {{ tab }} `<OID>` | String | Переменные сообщения SNMP Trap в форматер ключ-значение |
......@@ -4,7 +4,7 @@
Работа с конфигурацией оборудования один из самых развитых компонентов НОКа. Он позволяет:
* Сбор конфигурации с оборудование
* Сбор конфигурации с оборудования
* Версионированное хранение изменений (возможность посмотреть историю изменений с получением разницы)
* Полнотекстовый поиск по конфигурации
* Выгрузка информации на дисковое хранилище
......@@ -164,7 +164,7 @@ interface gigabitethernet1/0/24 description Description 2
Запросы представляют собой унифицированный способ работы со структурой `ConfDB`. По синтаксису они чем-то напоминают [Prolog](https://ru.wikipedia.org/wiki/Пролог_(язык_программирования)). Сам запрос состоит из **Цепочки предикатов**, разделённых словами `and` (в этом случае исполнение идёт друг за другом) и/или `or` (исполняются вместе). Для простоты запрос можно представить в виде `конвеера` на входе которого данные, на выходе результат запросов, либо пустота. Выполнение проходит слева направо, каждая стадия передаёт результаты работы следующей.
* **Предикат** - конструкция вида `<FUNC_NAME>(agrs)`, где `FUNC_NAME` - название применяемой функции, `args` - список аргументов. В примере: `Match`, `Filter`, `Del`
* **Путь** (`confdb path`) - содержимое предиката (указывается в скобках). Состоит из списка элементов дерева. Если оный указан в кавычках (`'interfaces'`, `'description'`) - то ищется точное совпадение, а если без (`X`, `Y`) обозначает переменную, которой присвоется элемент
* **Путь** (`confdb path`) - содержимое предиката (указывается в скобках). Состоит из списка элементов дерева. Если оный указан в кавычках (`'interfaces'`, `'description'`) - то ищется точное совпадение, а если без (`X`, `Y`) обозначает переменную, которой присваивается элемент
* **Контекст** - место хранения переменных. После выполнения всех предикатов в запросе становится *результатом*. Можно посмотреть предикатом `Dump`.
Работать с запросами можно в интерфейсе `ConfDB` (кнопка `Query`) или командой `./noc confdb query`
......@@ -311,7 +311,7 @@ interface gigabitethernet1/0/24 description Description 2
* Политика применения валидации (`Validation Policy`) - настройка валидации:
* Всегда (`Always`) - политика будет проверяться при каждом опросе
* При изменениии (`Validate on Change`) - применяться только при изменении конфигурации
* При изменении (`Validate on Change`) - применяться только при изменении конфигурации
* Отключить (`Disable`) - валидация отключена
* Действие (`Action`) - выбранная политика
......
This diff is collapsed.
......@@ -328,6 +328,6 @@ flowchart TD
* Схема сегмента
* Ттрассировка пути на верх из карточки
* Расчёт пути [path](../../../dev/reference/api/nbi/path.md)
* Расчёт RCA в авариях
* Расчёт RCA в авариях [Корреляция по топологии](../fault-management/index.md#Корреляция%20по%20топологии)
* Отчёты по метрикам с учётом топологии
# Event Class
Описывает значение пришедшего в систему события, также место хранения его настроек.
## Настройки
* **Имя** (`Name`) - имя класса события. Должно быть уникальным, используется нотация категорий, разделённых `|`
* **Текст** (`Text`) - блок настроек текстового описания события
* **Описание** (`Description`) - краткое описание
* **Шаблон заголовка** (`Subject Template`) - шаблон заголовка события, отображающийся в интерфейсе.
* **Шаблон содержания** (`Body template`) - шаблон содержания события, отображающийся при его просмотре
* **Симптомы** (`Symptoms`) - описание вероятных симптомов, вызвавших появление события
* **Возможные причины** (`Probably Cause`) - возможные причины
* **Рекомендованные действия** (`Recommended Actions`) - действия, которые необходимо принять для устранения события
* **Серьёзность** (`Severity`)
* **Серьёзность по умолчанию** (`Default Severity`) -
* **Уникальная** (`Unique`) - Авария может быть только в единственном числе
* **Закрытие пользователем** (`User Clearable`) - Пользователь может закрыть аварию
* **** (`Ephemeral`) - авария не размещается в архив, существует только в активном виде
* **Ключ** (`Reference`) - список ключевых переменных аварии
* **Переменные** (`Vars`)
* **Имя** (`Name`)
* **Описание** (`Description`)
* **Умолчание** (`Default`)
* **Источники данных** (`Datasources`)
* **Имя** (`Name`)
* **Источник данных** (`Datasource`)
* **Search**
* **Компоненты** (`Components`)
* **Имя** (`Name`)
* **Модель** (`Model`) - модель данных
* **Аргументы** (`Args`)
* *Параметр* (`Param`)
* *Переменная* (`Var`)
* **Первопричина** (`Root Cause`)
* **Имя** (`Name`)
* **Первопричина** (`Root`) - ссылка на класс аварии
* **Окно** (`Window`) - временное окно корреляции
* **Условие** (`Condition`) - условия совпадения текущей аварии
* **Криптерий совпадения** (`Match Condition`) - критерии совпадения с первопричиной (`Root`)
* (`Topology RCA`) - корреляция по топологии, настройка не выведена, выполняется только для класса `Ping Failed`
* **Задачи** (`Job`) - ~~не используются~~
* **Обработчики** (`Hadlers`)
* **Обработчик при открытии** (`Handler`)
* **Обработчик закрытия** (`Clear Handler`)
* **Плагины**
* **Имя** (`Name`)
* **Конфигурация** (`Configuration`)
* Настройки таймеров (`Timing`)
* (`Flap Condition`)
* (`Flap Window`)
* (`Flap Threshold`)
* **Время восстановления** (`Recover Time`)
## Описание работы
Настройки класса аварии влияют на работу классификатора [correlator](../../../../admin/reference/services/correlator.md),
## Правила именования
В наименовании классов событий используются разделение по категориям символом `|`: `<category1> | <category2> | <category3>`,
для каждого производителя выделена своя категория, в неё заносятся специфичные для него классы.
# Alarm Severity
Важность аварии
## Настройки
![](images/alarm-severity-warning-form.png)
* **Имя** (`Name`) - наименование важности. Должно быть уникальным, отображается в аварии
* **Описание** (`Description`) - краткое описание
* **Серьёзность** (`Severity`) - числовой уровень важности (`Severity`)
* **Мин. Вес** (`Min Weight`) - минимальный вес [Weight](../../../background/fault-management/index.md#Серьёзность%20и%20Вес), который должна набрать авария для присвоения важности
* **Звук** (`Sound`) - звук воспроизводимый при появлении аварии данного веса
* **Громкость** () - громкость звука (0 - отключить)
## Описание работы
Базовый уровень аварии определяет *минимальное* и *максимальное* значение веса аварии.
При обнаружении аварии система должна определять количество объектов мониторинга,
услуг и пользователей, попавших под влияние аварии. Максимальное значение уровня аварии является минимальным значением для следующего уровня.
После обнаружения аварии на конкретном оборудовании, система вычисляет вес аварии и в какой интервал базовых значений важности попадает авария.
# Event Class
Описывает значение пришедшего в систему события, также место хранения его настроек.
## Настройки
* **Имя** (`Name`) - имя класса события. Должно быть уникальным, используется нотация категорий, разделённых `|`
* **Текст** (`Text`) - блок настроек текстового описания события
* **Описание** (`Description`) - краткое описание
* **Шаблон заголовка** (`Subject Template`) - шаблон заголовка события, отображающийся в интерфейсе.
* **Шаблон содержания** (`Body template`) - шаблон содержания события, отображающийся при его просмотре
* **Симптомы** (`Symptoms`) - описание вероятных симптомов, вызвавших появление события
* **Возможные причины** (`Probably Cause`) - возможные причины
* **Рекомендованные действия** (`Recommended Actions`) - действия, которые необходимо принять для устранения события
* **Действие** - действия системы с событием
* **Действие** (`Action`)
* **Drop** - прекратить обработку события
* **Log** - Продолжить обработку и сохранить в событиях
* **Archive** - Продолжить обработку и перенести в архивные
* **Событие на интерфейсе** (`Link Event`)
* **Переменные** (`Vars`) - используемые в событии переменные
* **Имя** (`Name`) - имя переменной
* **Тип** (`Type`) - тип переменной
* **Обязательно** (`Required`) - переменная обязательно должна быть заполнена
* **Подавление** (`Match Suppress`) - переменная используется в обнаружении подавления
* **Описание** (`Description`) - краткое разъяснение
* **Размещение** (`Disposition`) - правила обработки события, обрабатываются последовательно до окончания или указателя на окончание (`Stop`)
* **Имя** (`Name`) - имя, должно быть уникальным
* **Условие** (`Condition`) - условие применения размещения
* **Действие** (`Action`) - действия при применении
* `drop` - удалить событие и остановить обработку
* `ignore` - проигнорировать строку
* `raise` - отправить событие на обработку в коррелятор для создания аварии
* `clear` - отправить событие на обработку в коррелятор для закрытия аварии
* **Класс аварии** (`Alarm Class`) - Класс аварии (применяется при действиях `raise` и `clear`)
* **Окончание** (`Stop`) - Остановить обработку при выставленном
* **Объект** (`Managed Object`) - выражение `Python` для обозначение устройства (`ManagedObject`)
* **Привязка переменных** (`Vars Mapping`)
* **Подавление** (`Supression`) - настройки подавления событий
* **Окно подавления повторов** (`Deduplication Window`)
* **Suppression Window** (`Suppression Window`)
* **Время жизни события** (`TTL`)
* **Обработчики** (`Handlers`) - список обработчиков [Handler](../handler/index.md) для исполнения
* **Плагины** (`Plugins`) - список плагинов *не используется*
## Описание работы
Настройки класса событий влияют на работу классификатора [classifier](../../../../admin/reference/services/classifier.md),
и назначаются на основе правил классификации [Classification Rule](../event-classification-rule/index.md). Если подходящего
правила на найдено, то срабатывают правила по умолчанию либо назначается класс `Unknown | Default`:
* `Unknown | Syslog` - назначается событиям на основе `Syslog`, для которых не обнаружено подходящего правила
* `Unknown | SNMP Trap` - назначается событиям на основе `SNMP Trap`, для которых не обнаружено подходящего правила
* `Unknown | Default` - назначается событиям, если не удалось сопоставить с любым из правил.
Время жизни события (`TTL`) позволяет не засорять базу излишними данными.
При этом, если событие было передано на дальнейшую обработку, например стало аварией, то действие TTL отменяется.
## Правила именования
В наименовании классов событий используются разделение по категориям символом `|`: `<category1> | <category2> | <category3>`,
для каждого производителя выделена своя категория, в неё заносятся специфичные для него классы.
\ No newline at end of file
# Event Classification Rule
Предназначены для определения класса событий, поступающих с оборудования.
## Настройки
Настройки правил классификации событий расположены в
`Управление авариями (Fault Management) -> Настройки (Setup) -> Правила классификации (Classification Rule)`
* **Имя** (`Name`) - название правила. Используется нотация с разделением по категориям
* **Описание** (`Description`) - описание правила
* **Приоритет** (`Priority`) - приоритет проверки правила
* **Класс события** (`Event Class`) - выставляется при совпадении
* **Шаблоны** (`Patterns`) - список шаблонов, проверяемых на совпадение с событием
* `RE Key` - регулярное выражение для названия переменной
* `RE Value` - регулярное выражение для значения переменной
* **Переменные** (`Vars`) - добавляет указанные переменные в событие
* Имя (`Name`) - имя переменной
* Значение (`Value`) - значение
## Описание работы
Правила применяются классификатором в порядке возрастания приоритета (`Preference`) до полного совпадения регулярных
выражений, перечисленных в шаблонах (`Patterns`). При полном совпадении событию назначается класс события из настроек,
а именованные группы из регулярных выражений становятся переменными, имя группы - имя переменной, совпадение - это значение переменной.
## Пример
......@@ -21,7 +21,7 @@
* Создав(`Create new`)
* Заменять (`Replace`)
* Облако (`Cloud`)
* **Вес аварии** (`Alarm Weight`)
* **Вес аварии** - весовой коэффициент для расчёта веса аварии [Alarm Weight](../../../background/fault-management/index.md#Серьёзность%20и%20Вес)
* **Политика сбора MAC адресов** (`MAC Discovery Policy`)
* `Transit` - собирать MAC адреса на интерфейсе (Настройка для опроса [MAC](../../../../admin/reference/discovery/periodic/mac.md))
* `Disable` - не собирать MAC адреса на интерфейсе (Настройка для опроса [MAC](../../../../admin/reference/discovery/periodic/mac.md))
......
......@@ -80,7 +80,7 @@
* **Политика событий** (`Event Policy`) - политика обработки сообщений FM для устройства
* (`Enable`) - обрабатывать сообщения FM для устройства
* (`Disable`) - не обрабатывать сообщения FM для устройства
* **Вес аварии** (`Alarm Weight`) - настройка веса аварии
* **Вес аварии** (`Alarm Weight`) - настройка для расчёта веса аварии [Alarm Weight](../../../background/fault-management/index.md#Серьёзность%20и%20Вес)
* **Политика архивирования Syslog** (`Syslog Archive Policy`) - отправлять принятые сообщения `Syslog` в архивное хранилище
* `Merge Downlink` - активировать механизм `Merge Downlink` (!описание)
......@@ -154,11 +154,11 @@
* ConfDB - использовать адреса (`Address`) из конфигурации устройства - должна быть поддержка (`ConfDB`)
* *Clear links*
* **On platform change** - удалять линки устройства при изменении платформы (`Platform`)
* [(`SLA`)](../../../../admin/reference/discovery/box/sla.md) - собирать SLA пробы с устройства (необходима поддержка со стороны адаптера)
* (`CPE Status`) - собирать оперативный статус CPE с контроллера
* [SLA](../../../../admin/reference/discovery/box/sla.md) - собирать SLA пробы с устройства (необходима поддержка со стороны адаптера)
* [CPE Status](../../../../admin/reference/discovery/periodic/cpestatus.md) - собирать оперативный статус CPE с контроллера
* (`CPE`) - собирать устройства `CPE` с контроллера
* *NRI* - Опросы по интеграции с внешней системой
* **Привязка портов** (`Portmapper`) - маппинг сетевых интерфейсов с получеными из внешней системы (необходима реализация адаптера)
* **Привязка портов** [Portmapper](../../../../dev/reference/etl/index.md#Portmapper) - маппинг сетевых интерфейсов с портами внешней системы (необходима реализация адаптера)
* **Привязка сервисов к портам** (`Service Binding`) - осуществлять привязку сервисов к интерфейсам
* *Housekeeping* - активировать механизм [HK Check](../../../../admin/reference/discovery/box/hk.md)
* *Discovery Alarm* -
......@@ -177,12 +177,12 @@
* Всегда (`Always Run`)
* **Интервал** (`Interval, sec`) - интервал запуска опроса
* *Опросы* (`Discovery`) - состав опроса
* [(`Uptime`)](../../../../admin/reference/discovery/periodic/uptime.md)
* [(`Interface status`)](../../../../admin/reference/discovery/periodic/interfacestatus.md)
* [(`CPE status`)](../../../../admin/reference/discovery/periodic/cpestatus.md)
* [(`MAC`)](../../../../admin/reference/discovery/periodic/mac.md)
* (`Alarms`)
* [(`Metrics`)](../../../../admin/reference/discovery/periodic/metrics.md)
* [Uptime](../../../../admin/reference/discovery/periodic/uptime.md)
* [Interface status](../../../../admin/reference/discovery/periodic/interfacestatus.md)
* [CPE status](../../../../admin/reference/discovery/periodic/cpestatus.md)
* [MAC](../../../../admin/reference/discovery/periodic/mac.md)
* [Alarms](../../../../admin/reference/discovery/periodic/alarms.md)
* [Metrics](../../../../admin/reference/discovery/periodic/metrics.md)
* *Discovery Alarm* -
* **Аварий при опросе** (`Box Alarm`)
* Включить (`Enable`) - включить создание аварий по полному опросу
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment