Мониторинг задержек
ATSD предоставляет набор метрик, правил реагирования, и утилит, позволяющих наблюдать за задержками в поступлении рыночных данных, а также проводить исследования скорости данных в зависимости от нагрузки и типов сообщений для оптимизации торговых стратегий.
Состояние и задержки в режиме реального времени Admin > Diagnostics > MOEX Consumer Monitoring.
Встроенный портал Latency: Key Classes.
Абсолютный уровень задержки в значительной степени определяется выбором расположения АТСД - в зоне колокации или в удаленном ЦОДе. В примерах ниже АТСД расположена в ЦОДе на расстоянии приблизительно 22 миллисекунды от зоны колокации, где установлены консьюмеры.
Мониторинг задержек обезличенных сделок в ATSD
Получаемые консьюмерами сообщения об обезличенных сделках в потоках TLR/FO-TRADES отправляются в ATSD. Задержка в поступлении сообщений вычисляется ATSD ежеминутно по каждому режиму торгов (классу) отдельно на основании всех сделок, поступивших в течение данного интервала времени. Задержка сделки равна разнице между временем сервера ATSD AddTime
и временем ТКС биржи (поле MDEntryTime
FAST) с округлением до миллисекунды.
Вычисляемые метрики:
trade_latency_count
- Количество сделок в интервалеtrade_latency_min
- Минимальная задержкаtrade_latency_max
- Максимальная задержкаtrade_latency_avg
- Среднеарифметическая задержкаtrade_latency_percentile_50
- 50% перцентиль задержки (также 75, 90, 95, 99)
В примере ниже в интервале с 11:00:33.535
до 11:01:33.560
(чуть больше минуты) было получено 3501 сделок с максимальной задержкой в 148 миллисекунд и медианой в 24 миллисекунды.
| time_msk | count | min | p50 | p90 | max |
|--------------|------:|----:|----:|----:|----:|
| 11:00:33.535 | 3577 | 22 | 24 | 30 | 148 |
| 11:01:33.560 | 3501 | 22 | 24 | 30 | 224 |
| 11:02:33.593 | 2485 | 22 | 23 | 28 | 224 |
Посмотреть SQL запрос
SELECT date_format(time, 'HH:mm:ss.SSS') AS time_msk,
tcount.value AS "count", tmin.value AS "min", tp50.value AS "p50", tp90.value AS "p90", tmax.value AS "max"
FROM trade_latency_count tcount
JOIN trade_latency_min tmin
JOIN trade_latency_percentile_50 tp50
JOIN trade_latency_percentile_90 tp90
JOIN trade_latency_max tmax
WHERE tcount.tags.class = 'TQBR'
--AND datetime >= current_working_day
AND datetime BETWEEN '2021-03-02 11:00:00' AND '2021-03-02 12:00:00'
ORDER BY datetime
LIMIT 10
Мониторинг задержек рыночных статистик в ATSD
Получаемые консьюмерами сообщения статистик, такие как лучшая покупка или продажа, отправляются в ATSD. Задержка в поступлении сообщений вычисляется ATSD ежеминутно по каждому режиму торгов отдельно на основании всех сообщений, поступивших в течение данного интервала времени. Задержка сообщения равна разнице между временем сервера ATSD AddTime
и временем ТКС биржи (как правило поле LastUpdateTime
в FAST) с округлением до миллисекунды.
Вычисляемые метрики:
instrument_statistic_count
- Количество сообщений в интервалеinstrument_statistic_min
- Минимальная задержкаinstrument_statistic_max
- Максимальная задержкаinstrument_statistic_avg
- Среднеарифметическая задержкаinstrument_statistic_percentile_50
- 50% перцентиль задержки (также 75, 90, 95, 99)
В примере ниже в интервале с 11:00:26.731
до 11:01:26.731
(1 минута) было получено 43042 сообщений с максимальной задержкой в 225 миллисекунд и медианой в 26 миллисекунд.
| time_msk | count | min | p50 | p90 | max |
|--------------|------:|----:|----:|----:|----:|
| 11:00:26.731 | 34533 | 21 | 24 | 39 | 148 |
| 11:01:26.731 | 43042 | 21 | 26 | 48 | 225 |
| 11:02:26.731 | 27783 | 21 | 24 | 36 | 317 |
Посмотреть SQL запрос
SELECT date_format(time, 'HH:mm:ss.SSS') AS time_msk,
tcount.value AS "count", tmin.value AS "min", tp50.value AS "p50", tp90.value AS "p90", tmax.value AS "max"
FROM instrument_statistic_latency_count tcount
JOIN instrument_statistic_latency_min tmin
JOIN instrument_statistic_latency_percentile_50 tp50
JOIN instrument_statistic_latency_percentile_90 tp90
JOIN instrument_statistic_latency_max tmax
WHERE tcount.tags.class = 'TQBR'
--AND datetime >= current_working_day
AND datetime BETWEEN '2021-03-02 11:00:00' AND '2021-03-02 12:00:00'
ORDER BY datetime
LIMIT 10
Метрики задержки консьюмера
Поэтапное время обработки сообщений консьюмером вычисляется утилитой ConsumerLatencyParser
ежедневно на основании архивов логов консьюмера, которые содержат временные метки поступления сообщения на каждом этапе:
entry
- Время регистрации транзакции ТКС биржи (lastupdate
для отдельных потоков безMDEntryTime
).sending
- Время отправки сообщения шлюзом рыночных данныхreceive
- Время получения сообщения консьюмеромprocess
- Время окончания обработки сообщения консьюмером, включая парсинг и логирование.
Расчет производится отдельно по каждому типу файлов:
trades.*.log.gz
statistics.*.log.gz
orders.*.log.gz
index.*.log.gz
(для Spectra)
Дополнительно детализируется время обработки по уникальным комбинациям значений полей MDEntryType
и MDUpdateAction
FAST.
В качестве начального времени (from
) принимается время одного из этапов, например entry
. В качестве конечного времени - время одного из последующих этапов.
from | to | Описание интервала |
---|---|---|
entry | sending | Время с момента регистрации сообщения в ТКС до отправки шлюзом FAST (задержка биржи) |
sending | receive | Время с момента отправки сообщения шлюзом FAST до получения консьюмером (задержка сети) |
receive | process | Время с момента получения сообщения консьюмером и окончания обработки (задержка консьюмера) |
entry | process | Время с момента регистрации сообщения в ТКС до окончания обработки консьюмером (совокупная задержка) |
Дополнительно рассчитывается
lastupdate -> sending
иlastupdate -> process
для потоков безMDEntryTime
Единица измерения - микросекунды.
consumer_latency.count
- Количество сообщений данного типа в течение дняconsumer_latency.max
- Максимальная задержка в течение дняconsumer_latency.min
- Минимальная задержка в течение дняconsumer_latency.p50
- 50% перцентиль задержки в течение дня (также 0.1, 1, 5, 10, 25, 75, 90, 95, 99, 99.9)
Пример расчета (время в UTC):
| MsgSeqNum | ReceiveTime | ProcessTime | SendingTime | MDUpdateAction | MDEntryType | MDEntryID | Symbol | MDEntryTime |
|----------:|-------------------:|-------------------:|-------------------:|---------------:|-------------|-----------:|--------|-------------------:|
| 29953 | 210305070243014585 | 210305070243015769 | 210305070243014443 | 0 | z | 3687232746 | GAZP | 210305070243013931 |
| 29954 | 210305070243014875 | 210305070243015810 | 210305070243014793 | 0 | z | 3687232747 | GAZP | 210305070243013957 |
Колонка | Этап | Время | Разница, мкс |
---|---|---|---|
MDEntryTime | entry | 2021-03-05 07:02:43.013957 | - |
SendingTime | sending | 2021-03-05 07:02:43.014793 | 836 |
ReceiveTime | receive | 2021-03-05 07:02:43.014875 | 82 |
ProcessTime | process | 2021-03-05 07:02:43.015810 | 935 |
Результаты обработки архивов ConsumerLatencyParser
отправляются в ATSD и доступны для мониторинга с помощью правил реагирования и просмотра на портале Consumer Log Latency by Stage. Портал позволяет выбрать метрику, этапы и тип данных для каждого консьюмера.
| dt | directory | file | from | to | count | median | p90 | p95 | p99 | p99.9 | max |
|------------|---------------|--------|-------|---------|--------:|-------:|-----:|-----:|------:|------:|---------:|
| 15-02-2021 | logger_hc_jdk | trades | entry | sending | 1897651 | 348 | 854 | 1562 | 5899 | 27914 | 12534612 |
| 16-02-2021 | logger_hc_jdk | trades | entry | sending | 1820326 | 360 | 923 | 1726 | 7532 | 32661 | 361499 |
| 17-02-2021 | logger_hc_jdk | trades | entry | sending | 2051517 | 369 | 1099 | 2211 | 11732 | 45858 | 12774733 |
Посмотреть SQL запрос
SELECT date_format(tcount.time, 'dd-MM-yyyy') AS dt,
tcount.tags."directory" AS "directory", tcount.tags."file" AS "file",
tcount.tags."from" AS "from", tcount.tags."to" AS "to",
tcount.value AS "count", tp50.value AS "median",
tp90.value AS "p90", tp95.value AS "p95", tp99.value AS "p99",
tp999.value AS "p99.9", tmax.value AS "max"
FROM "consumer_latency.count" AS tcount
JOIN "consumer_latency.p50" AS tp50
JOIN "consumer_latency.p90" AS tp90
JOIN "consumer_latency.p95" AS tp95
JOIN "consumer_latency.p99" AS tp99
JOIN "consumer_latency.p99.9" AS tp999
JOIN "consumer_latency.max" AS tmax
WHERE tcount.datetime BETWEEN '2021-02-15' AND '2021-02-20' EXCL
AND tcount.tags.directory = 'logger_hc_jdk' AND tcount.tags.file = 'trades'
AND (tcount.tags."from" = 'entry' AND tcount.tags."to" = 'sending')
AND tcount.tags.action IS NULL AND tcount.tags.type IS NULL
ORDER BY tcount.datetime,
CASE concat(tcount.tags."from", tcount.tags."to")
WHEN 'entrysending' THEN 0 WHEN 'lastupdatesending' THEN 1
WHEN 'sendingreceive' THEN 2 WHEN 'receiveprocess' THEN 3
WHEN 'entryprocess' THEN 4 WHEN 'lastupdateprocess' THEN 5
ELSE 10 END, tcount.tags.action, tcount.tags.type
Просмотр результатов с разбивкой по отдельным комбинациям MDEntryType
и MDUpdateAction
позволяет обнаружить типы сообщений, приходящих с аномальной задержкой, например статистика 1:p
(update:lcurrentprice
) в потоке MSR консьюмера фондового рынка.
| dt | directory | file | from | to | action | type | count | p25 | median | p75 | max |
|------------|---------------|------------|------------|---------|-------:|------|-------:|------:|-------:|------:|-------:|
| 2021-03-03 | logger_hc_jdk | statistics | lastupdate | sending | 1 | p | 72510 | 11913 | 14323 | 19160 | 203539 |
| 2021-03-03 | logger_hc_jdk | statistics | lastupdate | sending | 1 | u | 746 | 613 | 715 | 832 | 185383 |
| 2021-03-03 | logger_hc_jdk | statistics | lastupdate | sending | 1 | 9 | 103001 | 437 | 512 | 634 | 185086 |
Посмотреть SQL запрос
SELECT date_format(tcount.time, 'yyyy-MM-dd') AS dt, tcount.tags."directory" AS "directory", tcount.tags."file" AS "file",
tcount.tags."from" AS "from", tcount.tags."to" AS "to",
tcount.tags."action" AS "action", tcount.tags."type" AS "type",
tcount.value AS "count",
tp25.value AS "p25", tp50.value AS "median", tp75.value AS "p75", tmax.value AS "max"
FROM "consumer_latency.count" AS tcount
JOIN "consumer_latency.min" AS tmin
JOIN "consumer_latency.p25" AS tp25
JOIN "consumer_latency.p50" AS tp50
JOIN "consumer_latency.p75" AS tp75
JOIN "consumer_latency.max" AS tmax
WHERE tcount.datetime = '2021-03-03'
AND tcount.tags.directory = 'logger_hc_jdk' AND tcount.tags.file = 'statistics'
AND tcount.tags.action = '1'
AND tcount.tags.type IS NOT NULL
AND (tcount.tags."from" = 'lastupdate' AND tcount.tags."to" = 'sending')
--AND "count" > 1000
ORDER BY "median" DESC
Служебные метрики консьюмеров
Служебные метрики представлены на порталах Consumer Metrics: Fond, Consumer Metrics: FX, Consumer Metrics: Spectra.
Портал Consumer TCP Recovery Sessions содержит информацию о количестве восстановительных сессий по сравнению с предыдущими днями.
Получение сообщений
moex-consumer.datagrams.received
- Количество полученных сообщений. Должен быть ненулевым.moex-consumer.datagrams.decode_errors
- Количество сообщений при обработке которых произошла ошибка. Должен быть нулевым.moex-consumer.datagrams.decoded
- Количество декодированных сообщенийmoex-consumer.datagrams.dropped
- Количество отброшенных сообщенийmoex-consumer.datagrams.dropped_old_snapshot
- Количество отброшенных устаревших снэпшотовmoex-consumer.datagrams.filtering
- Количество сообщений на стадии фильтрацииmoex-consumer.datagrams.filtered
- Количество отфильтрованных сообщенийmoex-consumer.datagrams.processing
- Количество сообщений в процессе обработкиmoex-consumer.datagrams.process_queue
- Количество сообщений в очереди на обработку. Должен быть нулевым практически всегда.moex-consumer.datagrams.processed
- Количество обработанных сообщений
Восстановление данных
moex-consumer.recovery.attempts
- Количество попыток восстановлений пробелов данных.moex-consumer.recovery.failures
- Количество попыток восстановлений пробелов данных, закончившихся ошибкой. Должен быть нулевым.moex-consumer.recovery.packets.requested
- Количество сообщений, запрошенных для восстановления.moex-consumer.recovery.packets.received
- Количество сообщений, полученных при восстановлении.moex-consumer.recovery.retries
- Количество повторных попыток восстановлений. Должен быть нулевым.moex-consumer.recovery.sessions
- Количество восстановлений. Должен быть в пределах 1000 для каждого консьюмера в течение дня.
Встроенные правила реагирования
Правила доступны в разделе Rule Engine и осуществляют уведомление в мессенджеры Telegram/Slack/Rocket Chat или по электронной почте при наступлении критического события.
- MOEX Consumer Processing Stopped
- MOEX Consumer Trade Availability
- MOEX Consumer UDP package loss
- MOEX Consumers Alive: asts_curr spectra_all
- MOEX Consumers Alive: asts_fond
- MOEX Latency Spike
- MOEX Latency Spike Per Class
- Consumer Latency File Empty
- Consumer file latency