{{indexmenu_n> 1}}
====== Принцип работы ======
На рисунке ниже приведена структурная схема модуля "Мониторинг".\\
<imgcaption image1|Структурная схема модуля "Мониторинг">{{:user_manual:modules:monitor:hmfile_hash_16ba362b.jpg?1200|}}</imgcaption>

\\
1. При приеме новых данных модуль мониторинга получает оповещение об изменении/создании файла. При этом происходит следующее:
  * Из имени измененного/созданного файла считывается серийный номер устройства мониторинга, от которого эти данные получены и далее проверяется – есть ли у данного прибора хотя бы одно включенное правило мониторинга для обработки. Если нет правил – никаких действий далее не предпринимается. Если есть хотя бы одно включенное правило, в очередь обработки помещается серийный номер этого устройства.
  * Правила мониторинга могут использоваться для проверки как табличных, так и финальных данных. Принадлежность параметра к итоговому списку влияет на механизм обработки правила.

==== Обработка правил для табличных данных ====
2. По принципу FIFO (first in, first out) обработчик данных правил выполняет поочередный анализ событий из очереди на обработку – поиск нужного объекта мониторинга по серийному номеру и переход к обработке правил.\\
3. На этом этапе выполняется расчет рейса и трека за следующий период: с **[Текущее время]** – **[Окно просмотра]** до **[Текущее время]** + **[2 минуты]**

\\
После расчета рейса модуль «Мониторинг» начинает проверку правил за этот рейс.\\
<imgcaption image2|Анализ табличных данных>{{admin:m_settings:monitor:new:image_138_.png?700|}}</imgcaption>

 <panel type="primary" title="Примечание">Две минуты добавляются к текущему времени для корректной работы на компьютерах с несинхронизированным временем. Если на сервере  системное время отстаёт от актуального (GPS), возникает запаздывание обработки событий. То есть, в данных, полученных от прибора, присутствуют данные в «будущем» относительно системного времени компьютера и эти данные будут отброшены при вычислении рейса без корректировки. Данные инциденты имели место до внесения этой корректировки. На компьютерах с точным системным временем данная корректировка не вносит никаких искажений в расчёт, т.к. в «будущем» времени нет никаких данных и эта настройка будет проигнорирована.</panel>

<panel type="primary" title="Примечание"> Настройка «Окно просмотра» должна подбираться так, чтобы в этот интервал попадала хотя бы одна запись проверяемого параметра. Также в случае редких данных (записываемых в память прибора с большим периодом), настройка «Окно расчета» должна быть увеличена. В противном случае при обновлении значения параметра, оно может не попасть в интервал проверки и будет проигнорировано при анализе правила – при проверке условия правила будет использоваться значение из последней обработанной точки, которое не будет являться актуальным. Следовательно, будет пропущено событие, в случае его срабатывания. Окно просмотра задается в файле конфигурации – единое на все организации. Также для конкретного правила мониторинга внутри организации вы можете задать [[admin:m_settings:monitor:new:others.txt|альтернативное значение окна просмотра]]. </panel>

4. Для каждого включенного правила проверяются следующие условия:
  * Проверяется [[admin:m_settings:monitor:new:40sch.txt|расписание правила]], если правило «выключено» в данное время, его обработка прекращается.
  * Проверяется наличие параметров, указанных в правиле у данного ТС. Если данного параметра нет, обработка правила прекращается.

\\
5. Если есть сохраненное предыдущее состояние из предыдущего цикла проверки правила (см. п.10) – начальным условием при текущей проверке берётся сохраненное значение параметра из п.10 и цикл п.6 начинается с 0-й точки. В противном случае – цикл начинается с 1-й точки.

\\
На рисунке ниже приведен порядок проверки условия из правила в каждой записи на примере поиска превышения.\\
<imgcaption image3|Порядок проверки условий>{{:user_manual:modules:monitor:image_139_.jpg?900|}}</imgcaption>

\\
6. В цикле для каждой вычисленной записи проверяется выполнение условия в правиле. Например, если правило содержит условие «Speed > 60», то в каждой записи проверяется значение параметра Speed и проверяется условие > 60. Если обнаружено, что в предыдущей записи данное условие не выполнялось, а в текущей выполняется – считается, что произошло срабатывание правила, после чего в существующем наборе данных находится окончание действия правила. Если такая точка найдена, вычисляется длительность действия правила.\\
7. Если у правила стоит флаг «на начало события», собирается информация по событию (координаты, дата/время, копия табличных и финальных данных и т.д.) и далее в очередь оповещений добавляется событие на уведомление по этому правилу. Если у правила стоит флаг «на окончание события», то это событие сохраняется для последующей обработки и не генерирует события на уведомление.\\
8. Если в правиле было вычислена длительность события, то проверяется условие "Минимальная продолжительность". Если длительность события меньше, оно игнорируется.\\
9. После обработки всех правил для данного объекта мониторинга все полученные уведомления помещаются в очередь оповещений на отправку.\\
10. Запоминается дата и время последней обработанной точки и значение параметра в этой точке для обработки с этого значения в п.6.\\
11. Выполняется аналогичная проверка для правил с финальными параметрами, начиная с п.4.\\

==== Обработка уведомлений ====

12. Выполняется проверка, когда было сгенерировано предыдущее событие для данного правила и объекта мониторинга. Если текущее событие сработало раньше, чем параметр «Пропускать событие, если оно возникает чаще чем», то событие игнорируется.\\
13. По каждому извлеченному уведомлению формируется сообщение согласно шаблону сообщения и тема согласно шаблону темы сообщения из правила.\\
14. Если в правиле включена опция «Записать в журнал», событие помещается в журнал.\\
15. По каждому извлеченному уведомлению из очереди оповещений выполняется отправка уведомления на сервер (почтовый, ...) или выполняется действие, включенное в правиле. В случае возникновения ошибки (отправки сообщения, создания файла и т.д.) делается запись в системный журнал с сообщением об ошибке, названием объекта мониторинга и параметра.\\

<panel type="primary" title="Примечание">Т.к. многие параметры имеют и табличные и финальные данные, то следует проявлять внимательность при создании правила. Например, если будет создано правило на финальный параметр «Speed > 60» – то будет происходить сравнение предыдущих финальных данных и текущих. Это повлечет за собой пропуск всех точек трека в которых условие «Speed > 60» выполнялось, если эти точки не были последними за  интервал проверки финальных данных. Другими словами, все превышения скорости > 60 км/ч будут пропущены, если они не попали в финальные данные. В случае, если надо проверять аналоговые данные или вычисленные (скорости, уровни), следует создавать правила только на табличные параметры.</panel>

<panel type="primary" title="Примечание">Количество правил и их условия не имеют влияния на скорость работы. Расчёт выполняется только один раз для каждого объекта мониторинга при изменении данных. Скорость проверки правил на условия сработки – ничтожна по сравнению со скоростью выполнения расчёта.</panel>

<panel type="primary" title="Примечание">Существует задержка между изменением файла (поступлением данных от приборов) и генерацией события на оповещение. Это связано с тем, что данные от приборов могут приходить быстрее, чем они обрабатываются. Типичная задержка на средней схеме в 150-200 объектов и периодом загрузки 1 минута может достигать 20-30 секунд.</panel>

==== Обработка правил для финальных данных ====
Для финальных данных происходит проверка аналогично табличным (начиная с п.4 выше), за рядом исключений:
  * т.к. финальные данные должны вычисляться и для тех объектов мониторинга, для которых данные перестали поступать и в этом случае никаких событий об изменений файлов не будет генерироваться (например, если правило создано на параметр OutOfDateCoords – устаревшие координаты), то для запуска обработки происходит принудительное добавление фиктивных событий в очередь обработки (блок 2 на структурной диаграмме). Данное действие выполняется для тех приборов, у которых есть хотя бы одно правило с финальным параметром. Фиктивное событие генерируется только для тех приборов, которых ещё нет в очереди. Если событие для прибора уже есть в очереди, значит правила проверяются штатным образом, начиная с п.2.
  * для финальных данных нет никакого трека, т.к. есть только предыдущее значение подсчитанных финальных данных и текущее. Фактически выполняется обработка данных из массива, состоящего из двух элементов.