ddadmin
ea56314c25
- Зачем: - Сохранить самостоятельное открытие источника нагрузки в задании. - Что: - Убрано заранее названное имя пользователя, уточнен поиск запроса панели. - Исправлены пунктуация и формулировки по ревью Fable. - Проверка: - Проверены сценарии с запросом панели и другого клиента наверху списка. - Проверены относительные ссылки и git diff --check.
8.6 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 и на панели слепков;
- модельная дата отделена от реального времени наблюдения;
- объяснен выбор слоев для свежести, потока и доли брака, а также общее окно числителя и знаменателя;
- службы не остановлены, данные вручную не правились, стендовые дашборды не изменены.