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