Система событий — механизм , посредством которого управляющие воздействия ядра системы передаются на сетевые службы и оборудование. С помощью событий выполняется множество задач, в том числе следующие:
Управление объектами (ОУ) и субъектами (СУ) учета построено на основе событий (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} |
Оконечное оборудование абонента привязано к управляющим устройствам (файрвол, коммутатор).
При работе оператора связи возникают типовые задачи по управлению оборудованием и службами. Все нижеперечисленные задачи решаются с помощью событий: