docs(handbook): упрощен язык путеводителя по стенду

Зачем: помочь учащемуся понять путь данных и работу служб перед выполнением заданий.

Что: вычитаны оглавление и пять глав, пояснены термины, убраны внутренние метафоры и повторы. Уточнены пояснения к SQL и показателям мониторинга.

Проверка: 62 локальные ссылки и 6 входящих ссылок на разделы проверены; 8 блоков SQL и схем сохранены. git diff --cached --check прошел.

docs/handbook/monitoring.md

@@ -1,52 +1,61 @@
 # Мониторинг: куда смотреть
 
-В Grafana три дашборда, и у каждого своя тема. «Данные» показывает, все ли в
-порядке с потоком данных. «Кластер» — состояние машин и самого ClickHouse.
-«Запросы» — какие запросы выполнялись и сколько ресурсов они заняли.
+В Grafana настроены три дашборда. «Данные» показывает загрузку и обработку
+событий и заказов, «Кластер» — состояние узлов и самого ClickHouse,
+а «Запросы» — выполненные запросы и затраченные на них ресурсы.
 
-Prometheus собирает метрики с двух узлов ClickHouse, keeper и экспортера Kafka.
-Grafana читает и Prometheus, и ClickHouse напрямую. На панелях нет порогов и
-цветовой подсветки: оценивать картинку придется самому. Автоматические
-проверки, которые выносят вердикт, собраны в контуре DQ.
+Prometheus собирает метрики с двух узлов ClickHouse, ClickHouse Keeper
+и экспортера Kafka — службы, которая предоставляет метрики Kafka.
+Grafana получает данные из Prometheus и напрямую из ClickHouse.
+На панелях не заданы пороги для цветовых предупреждений: оценивать показания
+вы будете самостоятельно. Качество данных автоматически проверяет
+даг `dq_check`.
 
 ## Дашборд «Данные»
 
 «Свежесть» показывает, сколько времени прошло с последнего события и с
-последнего заказа в ODS. Свежесть заказов растет весь модельный день и
-сбрасывается, когда на границе суток приходит слепок. Это нормальное поведение
-источника, а не поломка.
+последнего заказа в ODS. Показатель для заказов растет весь модельный день
+и снижается, когда поступает очередная дневная выгрузка — слепок.
+Это ожидаемо: заказы загружаются раз в день.
 
 «Поток» показывает число сырых сообщений в STG за выбранный интервал. «Брак»
-рядом — доля строк, которые не удалось разобрать.
+показывает долю строк, которые не удалось разобрать.
 
 «Сходимость» сравнивает число событий в Kafka и в ClickHouse. Тревожный
-признак — устойчивый разрыв между линиями. Расхождение в одном столбце ничего
-не значит.
+признак — устойчивый разрыв между рядами. Разовое расхождение еще не говорит
+о потере данных: метрики Kafka и строки ClickHouse могут попадать в соседние
+интервалы на графике.
 
 «Отставание» показывает, сколько сообщений в Kafka еще не прочитано
 потребителями. «Дневной слепок» перечисляет последние десять слепков заказов в
-STG: по нему видно, пришла ли выгрузка вовремя.
+STG: по нему видно, поступила ли очередная выгрузка.
 
 Источники и правила чтения всех панелей разобраны в [справочнике дашборда
 «Данные»](../architecture/monitoring/data.md).
 
 ## Почему у панелей разные источники
 
-Свежесть считается по ODS: если разбор остановился, это видно именно там. Поток
-и брак считаются по STG, где сохраняется каждое доставленное сообщение. В ODS
-повторы события и старые версии заказа схлопываются, поэтому счетчик там был бы
-занижен. Подробности — в [разделе о слоях
+Свежесть считается по ODS: если новые сообщения перестали разбираться,
+показатель будет расти. Число поступивших сообщений берется из STG,
+где сохраняются все сообщения, включая повторы. Для доли брака это число
+сравнивается с числом строк в таблицах ошибок ODS.
+
+В основных таблицах ODS повторы событий и старые версии заказов удаляются
+при слияниях. Поэтому число строк в них не подходит для подсчета
+всех доставленных сообщений. Подробности — в [разделе о слоях
 панелей](../architecture/monitoring/data.md#почему-слои-у-панелей-разные).
 
 ## Два других дашборда
 
-Открывайте «Кластер», когда нужно понять, что происходит с процессором, памятью
-и дисками, с кусками данных и их слияниями в ClickHouse, с keeper или очередью
-DDL. Устройство панелей описано в [справочнике дашборда
+Открывайте «Кластер», чтобы проверить нагрузку на процессор, использование
+памяти и дисков, число частей таблиц и ход их слияний в ClickHouse. Здесь же
+показаны состояние ClickHouse Keeper и очередь распределенных DDL-команд.
+Устройство панелей описано в [справочнике дашборда
 «Кластер»](../architecture/monitoring/cluster.md).
 
-«Запросы» пригодится, когда вы ищете тяжелые запросы, ошибки или расход
-ресурсов по пользователям. Как читать списки, объясняет [справочник дашборда
+«Запросы» поможет найти медленные запросы, ошибки и пользователей,
+чьи запросы потребляют много ресурсов. Как читать панели, объясняет
+[справочник дашборда
 «Запросы»](../architecture/monitoring/queries.md).
 
 ## Посмотрите сами
@@ -57,15 +66,18 @@ Airflow [`world_live_day`](airflow-dags.md#даги-мира): модельны
 около двадцати четырех минут.
 
 Смотрите свежесть событий и свежесть заказов по отдельности. Пока день идет,
-свежесть событий держится на секундах, а свежесть заказов растет. На границе дня
-слепок отправляется сразу: свежесть заказов сбрасывается, а свежесть событий
-начинает расти, потому что новых событий до следующего дня не будет. Сам даг
-остается в работе и после конца дня, потому что ждет дневной конвейер.
+со времени последнего события проходят секунды, а время с последней
+загрузки заказов растет. После завершения генерации событий отправляется
+слепок заказов. Когда он загружен, показатель свежести заказов снижается.
+Показатель для событий начинает расти: новые события поступят только
+при генерации следующего дня. Даг пока продолжает работу, ожидая завершения
+обработки данных в дневном конвейере.
 
 ## Куда дальше
 
-Состав мониторинга собран в [справочнике
-зоны](../architecture/monitoring/README.md), детали главного экрана — в
-[справочнике дашборда «Данные»](../architecture/monitoring/data.md), а границы
-решения — в [ADR 0002](../adr/0002-monitoring-scope.md). Следующая глава —
+Устройство мониторинга описано в [техническом
+справочнике](../architecture/monitoring/README.md), панели дашборда «Данные» —
+в [отдельном разделе](../architecture/monitoring/data.md).
+Почему выбраны именно эти показатели, объясняет
+[ADR 0002](../adr/0002-monitoring-scope.md). Следующая глава —
 [«Немного Superset»](superset.md).