Рекомендуемая методика фиксации базовых метрик для выявления отклонений в работе тракта#

Методики работы с метриками Прикладного журнала (APLJ) и Архивирования (ARCH) для подсчета предельной нагрузки#

Цель – выявить и зафиксировать значения метрик, сигнализирующих о проблеме на тракте, вызывающей отставание реплики от мастер–системы или неудовлетворительное время отклика тракта на запросы.

Требуемые показатели Архивирования (ARCH):

Ответственность	Наименование критерия	Описание	Ед. изм	Метод расчета	Высокий	Средний	Низкий	Дополнительные условия
Архивирование (ARCH)	Отставание репликации на стороне Архивирования (ARCH)	Данный критерий применяется в случае, когда причина отставания репликации на стороне Архивирования (ARCH)	Часы	Мониторинг	2 часа	1 час	5 минут	Регистрация инцидента Архивирования (ARCH) и контроль исполнения производится на стороне Архивирования (ARCH)
Архивирование (ARCH)	Устранение инцидента online–ТКД	Данный критерий применяется в случае, когда нарушена последовательность векторов Прикладного журнала (APLJ) и/или сообщений Архивирования (ARCH), и длительность ответа на автоматический аварийный запрос превышает таймаут 10 секунд	Событие	Поток репликации падает по таймауту после 3–х попыток	Полная остановка потока репликации или отставание реплики более 2 часов	Незначительное отставание реплики в пределах часа после увеличения таймаута	Увеличение таймаута, при этом отсутствует отставание реплики	Максимальное значение таймаута 10 минут, значение по умолчанию 10 секунд

Требуемые показатели Прикладного журнала (APLJ):

Ответственность	Наименование критерия	Описание	Ед. изм	Метод расчета	Высокий	Средний	Низкий	Дополнительные условия
Прикладной журнал (APLJ)	Отставание репликации в ЦСП на стороне Прикладного журнала (APLJ)	Данный критерий применяется к Прикладной Фабрике в случае, когда причина отставания репликации на стороне Прикладного журнала (APLJ)	Часы	Экспертный	2 часа	1 час	5 минут	Регистрация инцидента Архивированием (ARCH) и контроль исполнения производится на стороне Прикладного журнала (APLJ)
Прикладной журнал (APLJ)	Переотправка векторов в случае применения сценария аварийного восстановления реплики ЦСП	Данный критерий применяется в случае, если время повторной отправки векторов отклоняется от зафиксированного по итогам учений времени на применение сценария аварийного восстановления №2 (Восстановление по векторам изменений Прикладного журнала (APLJ) соответствующего модуля из Прикладного Журнала)	Часы	Экспертный	8 часов	4 часа	1 час	Сценарий применяется, если Источник прошел испытания и имеет протокол учений DRP

Пояснения:

При высокой нагрузке на тракт Прикладной журнал (APLJ)–Архивирование (ARCH) возникает ситуация, когда происходит накопление данных, которые находятся в процессе обработки в Прикладном журнале (APLJ) или Архивирование (ARCH).

В случае Прикладного журнала (APLJ) это данные, которые загружены в топик данных для отправки в Архивирование (ARCH), но не вычитаны Архивированием (ARCH).

В случае Архивирования (ARCH) это данные, которые загружены в топик сырых данных, но не вычитаны процессором потока.

Методика подсчета на стороне Прикладного журнала (APLJ)#

Ключевые метрики, которые могут играть основанием для оповещений

Метрика	Описание
`journal.send.latency`	Скорость записи в Kafka Прикладного журнала (APLJ)
`standin.arm.duration.not_replicated.message`	Задержка репликации
`standin.arm.number.not_replicated.message`	Количество нереплицированных сообщений
`journal.wr.cpm`	Количество записанных сообщений в БД Прикладного журнала (APLJ) за минуту
`journal.export.counter`	Счетчик записи экспорта журналов в разрезе потребителей

Все метрики (справочно)#

Метрика	Значение
`journal.creator.counter`	Счетчик формирования Прикладного журнала (APLJ)
`journal.writer.counter`	Счетчик записи журналов
`journal.writer.data.type.counter`	Счетчик записи журналов по типам
`journal.export.counter`	Счетчик записи экспорта журналов в разрезе потребителей
`journal.writer.duplicate.service.counter`	Счетчик сообщений с дублирующим ключом
`journal.client.calls.counter`	Счетчик вызовов Прикладного журнала (APLJ)
`journal.client.calls.errors.counter`	Счетчик неуспешных вызовов Прикладного журнала (APLJ)
`journal.standin.transit.func.to_si.duration`	Длительность перехода в функциональный SI
`journal.standin.transit.func.from_si.duration`	Длительность перехода из функционального SI
`standin.switch.time`	Время недоступности при переключении режимов SI
`standin.arm.heartbeat`	Доступность АРМ StandIn
`journal.send.latency`	Скорость записи в Kafka Прикладного журнала (APLJ)
`standin.arm.duration.not_replicated.message`	Задержка репликации
`standin.arm.number.not_replicated.message`	Количество нереплицированных сообщений
`standin.arm.number.error.message`	Количество сообщений с ошибками репликации
`journal.wr.cpm`	Количество записанных сообщений в БД Прикладного журнала (APLJ) за минуту
`journal.edm.cpm`	Количество выгруженных сообщений из Прикладного журнала (APLJ) за минуту
`standin.edm.heartbeat`	Доступность EDM
`standin.writer.heartbeat`	Доступность Writer
`journal.platform.standin.semaphores`	Статус Платформенного SI

Методика подсчета на стороне Архивирования (ARCH)#

Осуществляется прямой мониторинг двух метрик:

Метрика отставания репликации – arch-journal.timestamp_of_last_sent_journal.timestamp, а именно – не ее абсолютного значения, а разницы значения данной метрики с текущим реальным временем:
- метрика является фактическим точным временем транзакции (event_date) для последнего успешно переданного в топик данных вектора изменений;
- отбрасывается только для потока;
- разница между значением метрики и текущим реальным временем показывает отставание фактической репликации без учета времени обработки на стороне реплики от реально совершенных бизнес–транзакций.
Таким образом, разница прямым образом показывает, насколько реплика (в секундах) отстает от мастер–системы.
Метрика последнего успешного коммита от реплики – arch-journal.timestamp_of_last_sent_journal.commit_timestamp, а именно – не ее абсолютного значения, а разницы значения данной метрики с текущим реальным временем:
- метрика является фактическим точным временем получения от реплики подтверждения принятия на ее стороне данных для последнего переданного в топик данных трактом вектора изменений;
- отбрасывается только для потока;
- позволяет оценить, насколько быстро реплика обрабатывает полученные изменений.

Метрика	Дельта от реального времени	Дельта от реального времени	Дельта от реального времени	Дельта от реального времени	Дельта от реального времени
	<10 сек	До 5 мин	До 1 часа	От 1 до 2 ч	Более чем 2 часа
`arch-journal.timestamp_of_last_sent_journal.timestamp`	Штатная работа Архивирования (ARCH)	Штатная работа Архивирования (ARCH), Повышенная нагрузка на тракт	Всплеск нагрузки. Если стабильно держится длительное время – инцидент, низкий, накопление очереди в Прикладном журнале (APLJ)	Инцидент, средний, необходим поиск причины замедления работы тракта или всплеска нагрузки	Инцидент, средний, необходим поиск причины замедления работы тракта
`arch-journal.timestamp_of_last_sent_journal.commit_timestamp`	Штатная работа загрузчика реплики	Штатная работа, повышенная нагрузка на реплику	Всплеск нагрузки. Если стабильно держится длительное время – инцидент, низкий, накопление очереди в Прикладном журнале (APLJ)	Инцидент, средний, необходим поиск причины замедления работы загрузчика	Инцидент, средний, необходим поиск причины замедления работы тракта

Отслеживание ТКД#

Осуществляется прямой мониторинг двух метрик:

arch-journal.dq.full_processing_time – полное время обработки запроса от ЦСП, мс. В прямом виде определяет необходимые критерии для показателя «Устранение инцидента online ТКД Архивирования (ARCH)» (см. таблицу в разделе Методики работы с метриками Прикладного журнала (APLJ) и Архивированием (ARCH) для подсчета предельной нагрузки).

На дашборде Grafana эта метрика выглядит следующим образом:

Примечание

Для online ТКД канал = DQ.

Для offline ТКД канал = OFFDQ.

Следует отслеживать максимальное время, без учета разреза типов (максимальное из всех типов). Метрики консолидируются за интервал в 15 сек, считаются по каждому отдельному запросу.
arch-journal.dq.ts_error_count – количество ошибок транспортного слоя (ts_error) – должны отсутствовать.

На дашборде Grafana (Архивирование (ARCH) – качество данных) эта метрика выглядит следующим образом:

Примечание

Для online ТКД канал = DQ.

Для offline ТКД канал = OFFDQ.

Отслеживание потока#

Текущие реализованные метрики не отображают в прямом виде отставание и не позволяют увидеть его величину в принципе (метрика arch-journal.timestamp_of_last_sent_journal.timestamp не была реализована).

Возможно косвенное отслеживание потока путем мониторинга двух метрик:

arch-journal.async_process_object.duration – метрика времени обработки одного сообщения трактом на стороне Архивирования (ARCH), мс. Консолидируется за интервал времени 15 сек.

На дашборде Grafana эта метрика выглядит следующим образом (дашборд Архивирования (ARCH) / Общие метрики):

Примечание

Канал – всегда STREAM.

По Источнику отслеживается максимальное значение. Метрика не показывает величину очереди на тракте и в общем случае никак не связана с количеством транзакций, ожидающих обработки, но позволяет определить наличие проблем на тракте по увеличению времени обработки одного сообщения выше порогового значения
arch-journal.async_process_object.count – количество переданных объектов в потоке явным образом. Консолидируется за интервал времени 15 сек.

На дашборде Grafana эта метрика выглядит следующим образом (дашборд Архивирования (ARCH) / Общие метрики):

Примечание

Канал – всегда STREAM.

По сумме величины по всем типам Источника при работающем и транзакционно нагруженном Источнике не должно иметь около нулевые или нулевые значения (свидетельствуют об остановке потока).