From 3ec4d79576dc72305cd910e2ab3aa2ba6e8b2586 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Mon, 7 Sep 2026 04:54:11 -0400 Subject: [PATCH 1/2] =?UTF-8?q?docs(labs):=20=D0=B4=D0=BE=D0=B1=D0=B0?= =?UTF-8?q?=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE=20=D0=B7=D0=B0=D0=B4=D0=B0=D0=BD?= =?UTF-8?q?=D0=B8=D0=B5=20=D0=BF=D0=BE=20=D0=BC=D0=BE=D0=BD=D0=B8=D1=82?= =?UTF-8?q?=D0=BE=D1=80=D0=B8=D0=BD=D0=B3=D1=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - Завершить ТЗ основной программы расследованиями нагрузки и свежести данных. - Что: - Добавлено ТЗ ступени 7 с наблюдением запросов Grafana и доставки слепка заказов. - В индексе лаб открыта ссылка на последнее задание программы. - Проверка: - Проверены относительные ссылки, git diff --check и соответствие панелям стенда. --- docs/labs/7-1-monitoring.md | 114 ++++++++++++++++++++++++++++++++++++ docs/labs/README.md | 4 +- 2 files changed, 115 insertions(+), 3 deletions(-) create mode 100644 docs/labs/7-1-monitoring.md diff --git a/docs/labs/7-1-monitoring.md b/docs/labs/7-1-monitoring.md new file mode 100644 index 0000000..e061b87 --- /dev/null +++ b/docs/labs/7-1-monitoring.md @@ -0,0 +1,114 @@ +# Мониторинг: куда смотреть + +**Чему учит:** начать расследование с подходящего экрана, найти источник +нагрузки и объяснить свежесть данных через путь доставки. + +## Перед началом + +Откройте Grafana и Airflow по адресам из раздела [«Адреса и +пароли»](../../README.md#адреса-и-пароли). Для первого знакомства в Grafana +есть три дашборда: + +- «Данные» - путь сообщений от источника до хранилища; +- «Кластер» - процессор, память, диски и внутренняя работа ClickHouse; +- «Запросы» - выполненные запросы, их стоимость и ошибки. + +Откройте все три дашборда и запишите по одному вопросу, на который каждый из +них помогает ответить. «Данные» оставьте открытым в соседней вкладке. + +Проведите два расследования на работающем стенде. Службы останавливать и данные +портить не понадобится. + +## Расследование 1. Кто читает больше всех + +Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы. +Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше +всех» найдите запрос пользователя `grafana`. Он часто оказывается наверху, но +при другой нагрузке первым будет другой запрос. + +Сохраните: + +- границы окна и время запроса; +- место запроса в списке, пользователя и ноду; +- текст запроса; +- длительность, память, число прочитанных и отданных строк. + +По тексту найдите панель, которая выполнила запрос. Ищите ее среди трех +дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем панели +нужно читать столько строк и согласуется ли цена с вопросом, на который она +отвечает. + +Затем через меню панели откройте «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 и на панели слепков; +- [ ] модельная дата отделена от реального времени наблюдения; +- [ ] объяснен выбор слоев для свежести, потока и доли брака, а также общее + окно числителя и знаменателя; +- [ ] службы не остановлены, данные вручную не правились, стендовые дашборды + не изменены. diff --git a/docs/labs/README.md b/docs/labs/README.md index 39d4c8a..46e2315 100644 --- a/docs/labs/README.md +++ b/docs/labs/README.md @@ -14,9 +14,7 @@ | 4 | [Перепиши нарезку стенда](4-1-session-pipeline.md) | изменить расчетную сущность внутри готового конвейера и проверить ее внешним эталоном | | 5 | [Сначала сторож, потом ломай: заказы](5-1-order-checks.md)
[Перепишите разбор заказов в ODS](5-2-order-parsing.md)
[Перепишите сборку заказов в DDS](5-3-order-pipeline.md) | написать проверки качества до рискованного изменения, затем переписать разбор и сборку заказов | | 6 | [Разбери сырые события и сверь результат со стендом](6-1-event-parsing.md) | изучить разбор потока отдельно от живого приема и сверить его со стендовым результатом | -| 7 | Мониторинг: куда смотреть | выбрать, куда и на что смотреть в живой системе | - -ТЗ для ступени 7 появится по мере продвижения программы. +| 7 | [Мониторинг: куда смотреть](7-1-monitoring.md) | выбрать, куда и на что смотреть в живой системе | ## Ступень 1: пять витрин слоя DM From ea56314c259c121125926bedb37b8ff94aedbb35 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Mon, 7 Sep 2026 05:16:17 -0400 Subject: [PATCH 2/2] =?UTF-8?q?docs(labs):=20=D1=83=D1=82=D0=BE=D1=87?= =?UTF-8?q?=D0=BD=D0=B5=D0=BD=D0=BE=20=D1=80=D0=B0=D1=81=D1=81=D0=BB=D0=B5?= =?UTF-8?q?=D0=B4=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5=20=D1=81=D1=82=D0=BE?= =?UTF-8?q?=D0=B8=D0=BC=D0=BE=D1=81=D1=82=D0=B8=20=D0=BC=D0=BE=D0=BD=D0=B8?= =?UTF-8?q?=D1=82=D0=BE=D1=80=D0=B8=D0=BD=D0=B3=D0=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - Сохранить самостоятельное открытие источника нагрузки в задании. - Что: - Убрано заранее названное имя пользователя, уточнен поиск запроса панели. - Исправлены пунктуация и формулировки по ревью Fable. - Проверка: - Проверены сценарии с запросом панели и другого клиента наверху списка. - Проверены относительные ссылки и git diff --check. --- docs/labs/7-1-monitoring.md | 39 +++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 17 deletions(-) diff --git a/docs/labs/7-1-monitoring.md b/docs/labs/7-1-monitoring.md index e061b87..9f5dd9e 100644 --- a/docs/labs/7-1-monitoring.md +++ b/docs/labs/7-1-monitoring.md @@ -9,9 +9,9 @@ пароли»](../../README.md#адреса-и-пароли). Для первого знакомства в Grafana есть три дашборда: -- «Данные» - путь сообщений от источника до хранилища; -- «Кластер» - процессор, память, диски и внутренняя работа ClickHouse; -- «Запросы» - выполненные запросы, их стоимость и ошибки. +- «Данные» — путь сообщений от источника до хранилища; +- «Кластер» — процессор, память, диски и внутренняя работа ClickHouse; +- «Запросы» — выполненные запросы, их стоимость и ошибки. Откройте все три дашборда и запишите по одному вопросу, на который каждый из них помогает ответить. «Данные» оставьте открытым в соседней вкладке. @@ -23,8 +23,7 @@ Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы. Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше -всех» найдите запрос пользователя `grafana`. Он часто оказывается наверху, но -при другой нагрузке первым будет другой запрос. +всех» возьмите первую строку. Сохраните: @@ -33,19 +32,23 @@ - текст запроса; - длительность, память, число прочитанных и отданных строк. -По тексту найдите панель, которая выполнила запрос. Ищите ее среди трех -дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем панели -нужно читать столько строк и согласуется ли цена с вопросом, на который она -отвечает. +По пользователю и тексту определите, кто отправил запрос и для чего. Затем +найдите запрос одного из трех открытых дашбордов, который прочитал больше всего +строк. Если это другая строка, сохраните для нее те же поля. -Затем через меню панели откройте «Inspect» -> «Query» у панели «Кто спрашивает: -сколько запросов и какой у них аппетит». Ответьте на два вопроса: +По тексту найдите панель, которая отправила запрос. Ищите ее среди трех +дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем запрос +читает столько строк и согласуется ли это с вопросом, на который отвечает +панель. + +В меню панели «Кто спрашивает: сколько запросов и какой у них аппетит» +откройте Inspect, затем Query. Ответьте на два вопроса: 1. Почему журнал читают сразу с обеих нод? 2. Почему из счета исключены строки начала запроса и работа шардов? -Проверьте второе объяснение по панели ошибок: там правило для работы шардов -другое. Объясните, почему различаются вопросы панелей, а не только их SQL. +Проверьте второе объяснение по панели ошибок: ее фильтр не исключает записи +шардов. Объясните, почему различаются вопросы панелей, а не только их SQL. ## Расследование 2. Как меняется свежесть заказов @@ -86,9 +89,9 @@ Не открывая справочник, объясните своими словами: -- почему свежесть считают в ODS, а поток - в STG; +- почему свежесть считают в ODS, а поток — в STG; - почему знаменатель доли брака берут из STG; -- почему числитель и знаменатель доли брака должны использовать одно окно. +- почему у числителя и знаменателя доли брака одно окно. Свяжите ответы с тем, что вы видели на панелях. Затем сверьте объяснение с [главой о мониторинге](../handbook/monitoring.md) и справочниками дашбордов @@ -99,8 +102,10 @@ ## Приемка - [ ] для каждого из трех дашбордов записан вопрос, на который он отвечает; -- [ ] сохранены окно, текст и показатели стоимости одного реального запроса, - найдена выполнившая его панель; +- [ ] сохранены окно, текст и показатели верхнего запроса, определены его + источник и назначение; +- [ ] среди запросов открытых дашбордов найден тот, который прочитал больше + всего строк, и соответствующая панель; - [ ] объяснено, как журнал собирают с двух нод и какие записи учитывают для счета запросов; - [ ] до наблюдения нарисован прогноз свежести событий и заказов, а форма