ddadmin
3bfe9ca4ee
Зачем: убрать механические повторы в итогах и избежать ложных расхождений при проверке графика Superset. Что: уточнены правила итоговых списков и название задания о проверках заказов. В разборе событий разделены учет повторных доставок и выбор событий ODS для сравнения. Первый график Superset и проверочный SQL используют весь период витрины. Проверка: git diff --check, локальные ссылки и переходы к измененным заголовкам прошли. Блоки кода и таблицы требований сохранены. Согласованность периода графика с SQL проверена по тексту; повторный проход через интерфейс Superset не выполнялся.
8.7 KiB
Мониторинг: куда смотреть
Чему учит: начать расследование с подходящего экрана, найти источник нагрузки и объяснить свежесть данных через путь доставки.
Перед началом
Откройте Grafana и Airflow по адресам из раздела «Адреса и пароли». Для первого знакомства в Grafana есть три дашборда:
- «Данные» — путь сообщений от источника до хранилища;
- «Кластер» — процессор, память, диски и внутренняя работа ClickHouse;
- «Запросы» — выполненные запросы, их стоимость и ошибки.
Откройте все три дашборда и запишите по одному вопросу, на который каждый из них помогает ответить. «Данные» оставьте открытым в соседней вкладке.
Проведите два расследования на работающем стенде. Службы останавливать и данные портить не понадобится.
Расследование 1. Кто читает больше всех
Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы. Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше всех» возьмите первую строку.
Сохраните:
- границы окна и время запроса;
- место запроса в списке, пользователя и ноду;
- текст запроса;
- длительность, память, число прочитанных и отданных строк.
По пользователю и тексту определите, кто отправил запрос и для чего. Затем найдите запрос одного из трех открытых дашбордов, который прочитал больше всего строк. Если это другая строка, сохраните для нее те же поля.
По тексту найдите панель, которая отправила запрос. Ищите ее среди трех дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем запрос читает столько строк и согласуется ли это с вопросом, на который отвечает панель.
В меню панели «Кто спрашивает: сколько запросов и какой у них аппетит» откройте Inspect, затем Query. Ответьте на два вопроса:
- Почему журнал читают сразу с обеих нод?
- Почему из счета исключены строки начала запроса и работа шардов?
Проверьте второе объяснение по панели ошибок: ее фильтр не исключает записи шардов. Объясните, почему различаются вопросы панелей, а не только их SQL.
Расследование 2. Как меняется свежесть заказов
Откройте дашборд «Данные». Панель «Свежесть: сколько прошло с последней доехавшей строки» показывает текущее число, а не историю. До наблюдения нарисуйте ожидаемую форму свежести событий и заказов в течение одного живого дня. Отдельно отметьте момент доставки слепка заказов.
Если world_live снят с паузы, наблюдайте его текущий или следующий
world_live_day: новый ручной запуск встанет в очередь. Если выключатель на
паузе и активного живого дня нет, запустите один world_live_day вручную.
Модельные сутки занимают около 24 реальных минут.
Запишите несколько наблюдений до конца дня и сразу после него:
| Реальное время | Свежесть событий, с | Свежесть заказов, с | Что происходило в Airflow |
|---|---|---|---|
Дашборд обновляется раз в минуту, поэтому точного совпадения момента доставки со строкой таблицы ждать не нужно. Рост и сброс свежести заказов перенесите на свой набросок. Объясните форму линии: какую метку времени вычитает панель из текущего времени, почему число растет и какое событие его сбрасывает. Модельную дату сыгранного дня подпишите отдельно от реального времени наблюдения.
Подтвердите сброс двумя следами:
- в Airflow завершился прием слепка
orders_ingest; - на панели «Дневной слепок заказов: какой доехал, когда и после какой паузы» появилась новая верхняя строка.
Если вы начали после доставки, дождитесь следующего дня либо честно запишите, какую часть формы увидели. Одно текущее значение не доказывает ни рост, ни сброс.
Объясните путь данных
Не открывая справочник, объясните своими словами:
- почему свежесть считают в ODS, а поток — в STG;
- почему знаменатель доли брака берут из STG;
- почему у числителя и знаменателя доли брака одно окно.
Свяжите ответы с тем, что вы видели на панелях. Затем сверьте объяснение с главой о мониторинге и справочниками дашбордов «Запросы» и «Данные». Устройство живого дня и доставки слепка описано в главе об Airflow.
Что должно получиться
- для каждого из трех дашбордов записан вопрос, на который он отвечает;
- у вас сохранены окно, текст и показатели верхнего запроса; вы выяснили, кто его отправил и зачем;
- вы нашли запрос открытых дашбордов, который прочитал больше всего строк, и панель, которая его отправила;
- вы можете объяснить, зачем журнал собирают с двух нод и какие записи учитывают при подсчете запросов;
- у вас есть прогноз свежести, сделанный до наблюдения, и несколько замеров; рост и сброс на рисунке объяснены через время последней доставки;
- вы подтвердили доставку заказов в Airflow и на панели слепков, подписали модельную дату отдельно от реального времени наблюдений;
- вы можете объяснить выбор слоев для свежести, потока и доли брака и почему числитель и знаменатель берут за одно окно;
- после наблюдений службы продолжают работать, данные и стендовые дашборды остались без изменений.