Зачем: убрать механические повторы в итогах и избежать ложных расхождений при проверке графика Superset. Что: уточнены правила итоговых списков и название задания о проверках заказов. В разборе событий разделены учет повторных доставок и выбор событий ODS для сравнения. Первый график Superset и проверочный SQL используют весь период витрины. Проверка: git diff --check, локальные ссылки и переходы к измененным заголовкам прошли. Блоки кода и таблицы требований сохранены. Согласованность периода графика с SQL проверена по тексту; повторный проход через интерфейс Superset не выполнялся.
119 lines
8.7 KiB
Markdown
119 lines
8.7 KiB
Markdown
# Мониторинг: куда смотреть
|
|
|
|
**Чему учит:** начать расследование с подходящего экрана, найти источник
|
|
нагрузки и объяснить свежесть данных через путь доставки.
|
|
|
|
## Перед началом
|
|
|
|
Откройте Grafana и Airflow по адресам из раздела [«Адреса и
|
|
пароли»](../../README.md#адреса-и-пароли). Для первого знакомства в Grafana
|
|
есть три дашборда:
|
|
|
|
- «Данные» — путь сообщений от источника до хранилища;
|
|
- «Кластер» — процессор, память, диски и внутренняя работа ClickHouse;
|
|
- «Запросы» — выполненные запросы, их стоимость и ошибки.
|
|
|
|
Откройте все три дашборда и запишите по одному вопросу, на который каждый из
|
|
них помогает ответить. «Данные» оставьте открытым в соседней вкладке.
|
|
|
|
Проведите два расследования на работающем стенде. Службы останавливать и данные
|
|
портить не понадобится.
|
|
|
|
## Расследование 1. Кто читает больше всех
|
|
|
|
Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы.
|
|
Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше
|
|
всех» возьмите первую строку.
|
|
|
|
Сохраните:
|
|
|
|
- границы окна и время запроса;
|
|
- место запроса в списке, пользователя и ноду;
|
|
- текст запроса;
|
|
- длительность, память, число прочитанных и отданных строк.
|
|
|
|
По пользователю и тексту определите, кто отправил запрос и для чего. Затем
|
|
найдите запрос одного из трех открытых дашбордов, который прочитал больше всего
|
|
строк. Если это другая строка, сохраните для нее те же поля.
|
|
|
|
По тексту найдите панель, которая отправила запрос. Ищите ее среди трех
|
|
дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем запрос
|
|
читает столько строк и согласуется ли это с вопросом, на который отвечает
|
|
панель.
|
|
|
|
В меню панели «Кто спрашивает: сколько запросов и какой у них аппетит»
|
|
откройте Inspect, затем Query. Ответьте на два вопроса:
|
|
|
|
1. Почему журнал читают сразу с обеих нод?
|
|
2. Почему из счета исключены строки начала запроса и работа шардов?
|
|
|
|
Проверьте второе объяснение по панели ошибок: ее фильтр не исключает записи
|
|
шардов. Объясните, почему различаются вопросы панелей, а не только их SQL.
|
|
|
|
## Расследование 2. Как меняется свежесть заказов
|
|
|
|
Откройте дашборд «Данные». Панель «Свежесть: сколько прошло с последней
|
|
доехавшей строки» показывает текущее число, а не историю. До наблюдения
|
|
нарисуйте ожидаемую форму свежести событий и заказов в течение одного живого
|
|
дня. Отдельно отметьте момент доставки слепка заказов.
|
|
|
|
Если `world_live` снят с паузы, наблюдайте его текущий или следующий
|
|
`world_live_day`: новый ручной запуск встанет в очередь. Если выключатель на
|
|
паузе и активного живого дня нет, запустите один `world_live_day` вручную.
|
|
Модельные сутки занимают около 24 реальных минут.
|
|
|
|
Запишите несколько наблюдений до конца дня и сразу после него:
|
|
|
|
| Реальное время | Свежесть событий, с | Свежесть заказов, с | Что происходило в Airflow |
|
|
|---|---:|---:|---|
|
|
| | | | |
|
|
|
|
Дашборд обновляется раз в минуту, поэтому точного совпадения момента
|
|
доставки со строкой таблицы ждать не нужно. Рост и сброс свежести заказов
|
|
перенесите на свой набросок. Объясните форму линии: какую метку времени
|
|
вычитает панель из текущего времени, почему число растет и какое событие его
|
|
сбрасывает. Модельную дату сыгранного дня подпишите отдельно от реального
|
|
времени наблюдения.
|
|
|
|
Подтвердите сброс двумя следами:
|
|
|
|
- в Airflow завершился прием слепка `orders_ingest`;
|
|
- на панели «Дневной слепок заказов: какой доехал, когда и после какой паузы»
|
|
появилась новая верхняя строка.
|
|
|
|
Если вы начали после доставки, дождитесь следующего дня либо честно запишите,
|
|
какую часть формы увидели. Одно текущее значение не доказывает ни рост, ни
|
|
сброс.
|
|
|
|
## Объясните путь данных
|
|
|
|
Не открывая справочник, объясните своими словами:
|
|
|
|
- почему свежесть считают в ODS, а поток — в STG;
|
|
- почему знаменатель доли брака берут из STG;
|
|
- почему у числителя и знаменателя доли брака одно окно.
|
|
|
|
Свяжите ответы с тем, что вы видели на панелях. Затем сверьте объяснение с
|
|
[главой о мониторинге](../handbook/monitoring.md) и справочниками дашбордов
|
|
[«Запросы»](../architecture/monitoring/queries.md) и
|
|
[«Данные»](../architecture/monitoring/data.md). Устройство живого дня и
|
|
доставки слепка описано в [главе об Airflow](../handbook/airflow-dags.md).
|
|
|
|
## Что должно получиться
|
|
|
|
- [ ] для каждого из трех дашбордов записан вопрос, на который он отвечает;
|
|
- [ ] у вас сохранены окно, текст и показатели верхнего запроса;
|
|
вы выяснили, кто его отправил и зачем;
|
|
- [ ] вы нашли запрос открытых дашбордов, который прочитал больше всего
|
|
строк, и панель, которая его отправила;
|
|
- [ ] вы можете объяснить, зачем журнал собирают с двух нод и какие записи
|
|
учитывают при подсчете запросов;
|
|
- [ ] у вас есть прогноз свежести, сделанный до наблюдения, и несколько
|
|
замеров; рост и сброс на рисунке объяснены через время последней доставки;
|
|
- [ ] вы подтвердили доставку заказов в Airflow и на панели слепков,
|
|
подписали модельную дату отдельно от реального времени наблюдений;
|
|
- [ ] вы можете объяснить выбор слоев для свежести, потока и доли брака
|
|
и почему числитель и знаменатель берут за одно окно;
|
|
- [ ] после наблюдений службы продолжают работать, данные и стендовые
|
|
дашборды остались без изменений.
|