# Мониторинг: куда смотреть

Вы познакомитесь с дашбордами мониторинга и проведете два расследования:
найдете запросы, которые создают нагрузку, и выясните, почему события сайта
и заказы обновляются с разной частотой.

## Знакомство с дашбордами

Откройте Grafana и Airflow по адресам из раздела [«Адреса и
пароли»](../../README.md#адреса-и-пароли). Для первого знакомства в Grafana
есть три дашборда:

- «Данные» — путь сообщений от источника до хранилища;
- «Кластер» — процессор, память, диски и внутренняя работа ClickHouse;
- «Запросы» — выполненные запросы, затраченные на них ресурсы и ошибки.

Откройте все три дашборда и запишите по одному вопросу, на который каждый из
них помогает ответить. «Данные» оставьте открытым в соседней вкладке.

Проведите два расследования на работающем стенде. Службы останавливать и данные
портить не понадобится.

## Расследование 1. Какие запросы читают больше всего данных

Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы.
Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше
всех» возьмите первую строку.

Сохраните:

- начало и конец выбранного периода, время запроса;
- место запроса в списке, пользователя и узел;
- текст запроса;
- длительность, память, число прочитанных и отданных строк.

По пользователю и тексту определите, кто отправил запрос и для чего. Затем
найдите запрос одного из трех открытых дашбордов, который прочитал больше всего
строк. Если это другая строка, сохраните для нее те же поля.

По тексту найдите панель, которая отправила запрос. Ищите ее среди трех
дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем запрос
читает столько строк и согласуется ли это с вопросом, на который отвечает
панель.

В меню панели «Кто спрашивает: сколько запросов и какой у них аппетит»
откройте Inspect, затем Query. Ответьте на два вопроса:

1. Почему журнал читают сразу с обоих узлов?
2. Почему при подсчете запросов исключают записи о начале выполнения и
   записи о выполнении частей запроса на шардах?

Проверьте второе объяснение по панели ошибок: ее фильтр не исключает записи
шардов. Объясните, на какие разные вопросы отвечают эти две панели
и зачем им разные условия отбора.

## Расследование 2. Как меняется свежесть заказов

Откройте дашборд «Данные». Панель «Свежесть: сколько прошло с последней
доехавшей строки» показывает, сколько времени прошло с последней загрузки.
Истории значений на ней нет. До наблюдения нарисуйте, как, по вашему ожиданию,
будут меняться эти числа для событий и заказов в течение одного запуска
`world_live_day`. Отдельно отметьте ожидаемый момент доставки слепка заказов.

Если `world_live` снят с паузы, наблюдайте его текущий или следующий
`world_live_day`: новый ручной запуск встанет в очередь. Если `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 и на панели слепков,
      подписали модельную дату отдельно от реального времени наблюдений;
- [ ] вы можете объяснить выбор слоев для свежести, потока и доли брака
      и почему числитель и знаменатель берут за один период;
- [ ] после наблюдений службы продолжают работать, данные и стендовые
      дашборды остались без изменений.