Система событий — механизм , посредством которого управляющие воздействия ядра системы передаются на сетевые службы и оборудование. С помощью событий выполняется множество задач, в том числе следующие:
Управление объектами (ОУ) и субъектами (СУ) учета построено на основе событий (events), возникающих при переходе ОУ/СУ из одного состояния в другое. Здесь состояние понимается в широком смысле: изменение атрибутов (в том числе дополнительных параметров, задаваемых пользователем), адресов, связей и привязок ОУ или СУ.
{graphviz}
// Управление ОУ (общая схема)
digraph G {
size="5,5"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
"ОУ" [shape=ellipse]
"ОУ"->{"Состояние 1"; "Состояние 2"} [dir=none]
subgraph cluster_0 {
color=white
"Состояние 1"->"Событие"->"Состояние 2" [constraint=false]
"Событие" [shape=parallelogram, fillcolor=red, width=2, height=0.25, fixedsize=true]
}
"Событие"->"Действия"
"Действия"->"Агент" [label="Команды"]
"Агент" [shape=ellipse]
}
{graphviz} |
Событие вызывает набор связанных с ним действий (actions), которое преобразует эти действия в набор команд. В свою очередь, команды с помощью протокола удалённого управления передаются на выполнение агенту hamd — специальному внешнему приложению, непосредственно взаимодействующему с сетевыми службами или оборудованием.
Соответствие друг другу событий, действий и команд задаётся в в настройках событий (Справочники -> События). На рисунке показаны основные взаимосвязи между настройками события.
{graphviz}
digraph G {
size="6,6"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
"Управление СУ/ОУ"->{"События"; "Действия"; "Очередь команд";}
"События"->"Возможные события" [dir=none]
"Возможные события" [shape=record, style=rounded, label="{Привязка | Адрес | Состояние | Состояние\ родителя | Поступление\ платежа | Рекомендуемый\ платеж | Выставление\ счета | Подключение\ услуги | Отключение услуги}"];
"Действия"->"Возможные действия" [dir=none]
"Возможные действия" [shape="record", style=rounded, label="{SNMP-команда | Команда\ RSH/SSH/Telnet | Shell-скрипт}"];
}
{graphviz} |
События генерируются системой в момент, определяемый их типом. Как правило, они происходят при переводе СУ, ОУ или связанного с СУ документа (инвойса, платежного поручения) в то или иное состояние.
События добавляются в очередь, которая затем обрабатывается заданиями по агентам. Такой подход позволяет работать с произвольными событиями, которые могут возникать в любом модуле системы, а вызовы процедуры добавления нового события в очередь являются асинхронными, то есть не блокируют выполнение пакета. Кроме того, можно применять события не только для управления устройствами, но и в любых других целях, например, для рассылки Email-сообщений, SMS-уведомлений, факсов и т. д.
В настройках событий указываются:
Действие для представляет собой набор шаблонов команд в текстовом виде. Для использования в шаблонах предусмотрены специальные подстановки, которые при обработке команды агентом заменяются на конкретные значения атрибутов, идентификаторов и других параметров ОУ и СУ (например, подстановок
$TERM_PHYS_ADDR может быть заменён на значение 00-1A-B1-DF-24-A4). При этом в существует как жёстко запрограммированный набор подстановок, так и набор, задаваемый пользователем с помощью параметризованных подстановок. Например, дополнительные параметры ОУ могут представляться подстановкой (
$TERM_OBJ_ADD_PARAMadd_param_id, где add_param_id — идентификатор дополнительного параметра).
Действия при настройке события добавляются двумя группами — прямой и обратной. Для каждого действия может быть задано действие, ему противоположное. Это позволяет системе управления при необходимости с помощью обратного действия корректно отменять изменения, сделанные на оборудовании прямым действием.
Команда имеет свой тип взаимодействия (SNMP, RSH, SSH, локальный и т.д.), определяющий протокол, по которому эта команда будет передаваться на управляемое устройство.
Следует отметить, что деление команд на типы взаимодействия с точки зрения ядра |
Менеджер hamd (Hydra Active Management Daemon) — это специализированное приложение, являющееся внешним по отношению к ядру АСР и предназначенное для приёма от него команд и их дальнейшего выполнения. Данный агент, как и другие агенты разработан на языке Python и поставляется в исходных кодах.
Менеджер принимает сообщения от ядра АСР по протоколу XML-RPC аналогично агенту hcd. В сообщении передаётся как сам пакет команд, так и дополнительные параметры, необходимые для его выполнения (данные для аутентификации на оборудовании и т.д.). Связь ядра с менеджером инициируется заданием по этому менеджеру.
Подстановки передаются отдельно от шаблона, что позволяет проводить их дополнительную обработку на стороне агента.
После того, как пакет команд выполнен, агент передаёт в систему отчёт о выполнении, в котором содержится результат выполнения каждой команды. Всего возможны четыре варианта: успех, предупреждение, ошибка и неизвестно. Пользователь сам задает то, какой результат вернуть в систему в каждом конкретном случае. Кроме того, вместе с результатом можно передавать и сообщение с расшифровкой проблемы. Подробная и качественная обработка ошибок позволяет легче обнаруживать и устранять проблемы, возникающие при работе системы, что в конечном счёте приводит к экономии рабочего времени и средств.
Задания приводят механизм управления СУ/ОУ в действие. Основная сущность, с которой работают задания — очередь событий.
Суть очереди событий ясна из названия. Событие вместе с набором связанных с ним действий добавляется в хвост очереди, а выполнение действий менеджером идёт с её начала. При этом действия группируются в разрезе каждого устройства, на котором они выполняются. Это даёт следующие возможности:
На каждый менеджер создается одно задание в момент перевода менеджера в активное состояние. После создания задание автоматически запускается с определенной периодичностью.
Взаимодействие сущностей при срабатывании события по ОУ показано на примере управления доступом оконечного оборудования абонента к услугам оператора.
{graphviz}
digraph G {
size="8,8"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
rank=source
subgraph cluster_0 {
color=beige
"Абонент" [shape=ellipse, fillcolor=lightpink]
"Абонент"->{"Атрибуты абонента"; "Адреса"}[dir=none]
}
subgraph cluster_1 {
color=lightblue
rank=max
"Оконечное оборудование" [shape=ellipse]
"Оконечное оборудование"->{"Состав"; "Атрибуты оборудования"}
"Состав" [shape=record, label="{Порт\ 1 | Порт\ 2 | ... | Порт\ N}"]
}
subgraph cluster_2 {
color=darkseagreen2
rank=min
"Файрвол" [shape=ellipse]
"Коммутатор" [shape=ellipse]
}
subgraph cluster_3 {
color=mistyrose
rank=min
"Событие"->"Действия"->"Команды"
}
"Абонент"->"Оконечное оборудование"->{"Коммутатор"; "Файрвол"}
"Событие"->{"Менеджер"; "Файрвол"; "Коммутатор"}
}
{graphviz} |
Оконечное оборудование абонента привязано к управляющим устройствам (файрвол, коммутатор).
При работе оператора связи возникают типовые задачи по управлению оборудованием и службами. Все нижеперечисленные задачи решаются с помощью событий: