# Мониторинг в Grafana

В Grafana настроены три дашборда — экрана с показателями и графиками.
«Данные» показывает загрузку и обработку событий и заказов,
«Кластер» — состояние узлов и самого ClickHouse, а «Запросы» — выполненные
запросы и затраченные на них ресурсы.

На панелях не заданы пороги для цветовых предупреждений: оценивать показания
вы будете самостоятельно. Качество данных автоматически проверяет
даг `dq_check`.

## Дашборд «Данные»

«Свежесть» показывает, сколько реального времени прошло с поступления
последних успешно разобранных событий и заказов. Время поступления хранится
в колонке `_load_ts` слоя ODS. Показатель для заказов растет весь модельный день
и снижается, когда поступает очередная дневная выгрузка — слепок.
Это ожидаемо: заказы загружаются раз в день.

«Поток» показывает число сырых сообщений в STG за выбранный интервал. «Брак»
показывает долю строк, которые не удалось разобрать.

«Сходимость» сравнивает число событий в Kafka и в ClickHouse. Тревожный
признак — устойчивый разрыв между рядами. Разовое расхождение еще не говорит
о потере данных: метрики Kafka и строки ClickHouse могут попадать в соседние
интервалы на графике.

«Отставание» показывает, сколько сообщений в Kafka еще не прочитано
потребителями. «Дневной слепок» перечисляет последние десять слепков заказов в
STG: по нему видно, поступила ли очередная выгрузка.

Источники и правила чтения всех панелей разобраны в [справочнике дашборда
«Данные»](../architecture/monitoring/data.md).

## Источники показателей

Grafana получает данные напрямую из ClickHouse и через Prometheus.
Prometheus собирает метрики с двух узлов ClickHouse, ClickHouse Keeper
и экспортера Kafka — службы, которая предоставляет метрики Kafka.

Свежесть считается по ODS: если новые сообщения перестали разбираться,
показатель будет расти. Число поступивших сообщений берется из STG,
где сохраняются все сообщения, включая повторы. Для доли брака это число
сравнивается с числом строк в таблицах ошибок ODS.

В основных таблицах ODS повторы событий и старые версии заказов удаляются
при слияниях. Поэтому число строк в них не подходит для подсчета
всех доставленных сообщений. Подробности — в [разделе о слоях
панелей](../architecture/monitoring/data.md#почему-слои-у-панелей-разные).

## Состояние кластера и запросы

Открывайте «Кластер», чтобы проверить нагрузку на процессор, использование
памяти и дисков, число частей таблиц и ход их слияний в ClickHouse. Здесь же
показаны состояние ClickHouse Keeper и очередь распределенных DDL-команд.
Устройство панелей описано в [справочнике дашборда
«Кластер»](../architecture/monitoring/cluster.md).

«Запросы» поможет найти медленные запросы, ошибки и пользователей,
чьи запросы потребляют много ресурсов. Как читать панели, объясняет
[справочник дашборда
«Запросы»](../architecture/monitoring/queries.md).

## Показатели за один модельный день

Откройте Grafana по адресу из раздела [«Адреса и
пароли»](../../README.md#адреса-и-пароли), затем дашборд «Данные». Запустите в
Airflow [`world_live_day`](airflow-dags.md#генерация-модельных-дней): модельный день займет
около двадцати четырех минут.

Смотрите свежесть событий и свежесть заказов по отдельности. Пока день идет,
со времени последнего события проходят секунды, а время с последней
загрузки заказов растет. После завершения генерации событий отправляется
слепок заказов. Когда он загружен, показатель свежести заказов снижается.
Показатель для событий начинает расти: новые события поступят только
при генерации следующего дня. Даг пока продолжает работу, ожидая завершения
обработки данных в дневном конвейере.

## Следующая глава и справочники

Устройство мониторинга описано в [техническом
справочнике](../architecture/monitoring/README.md), панели дашборда «Данные» —
в [отдельном разделе](../architecture/monitoring/data.md).
Почему выбраны именно эти показатели, объясняет
[ADR 0002](../adr/0002-monitoring-scope.md). Следующая глава —
[«Отчеты в Superset»](superset.md).