> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Расширенная панель мониторинга в ClickHouse Cloud
# Расширенная панель мониторинга в ClickHouse Cloud
export const Image = ({img, alt, size}) => {
return
;
};
Мониторинг вашей системы баз данных в промышленной среде крайне важен
для понимания состояния развертывания, чтобы вы могли предотвращать сбои и устранять их.
Расширенная панель мониторинга — это легковесный инструмент, предназначенный для того, чтобы дать вам глубокое представление
о вашей системе ClickHouse и ее окружении, помогая заранее выявлять
узкие места в производительности, системные сбои и неэффективность.
Расширенная панель мониторинга доступна как в ClickHouse OSS (Open Source Software),
так и в Cloud. В этой статье мы покажем, как использовать расширенную панель мониторинга в
Cloud.
## Доступ к расширенной панели мониторинга
Чтобы открыть расширенную панель мониторинга, перейдите в:
* Левая боковая панель
* `Monitoring` → `Advanced dashboard`
## Доступ к встроенной расширенной панели мониторинга
Чтобы открыть встроенную расширенную панель мониторинга, перейдите:
* в левую боковую панель
* `Monitoring` → `Advanced dashboard`
* Нажмите `You can still access the native advanced dashboard.`
После этого встроенная расширенная панель мониторинга откроется в новой вкладке. Для доступа к панели мониторинга потребуется
пройти аутентификацию.
С каждой визуализацией связан SQL-запрос, который её заполняет. Вы можете
изменить этот запрос, нажав на значок пера.
## Готовые визуализации
Стандартные диаграммы на расширенной панели мониторинга позволяют в реальном времени
отслеживать состояние вашей системы ClickHouse. Ниже приведен список с описанием
каждой диаграммы. Для удобства они сгруппированы в три категории.
### Для ClickHouse
Эти метрики предназначены для мониторинга состояния и производительности вашего
экземпляра ClickHouse.
| Метрика | Описание |
| ----------------------- | ------------------------------------------------------------------------------------------------- |
| Запросов в секунду | Отслеживает скорость обработки запросов |
| Прочитанных строк/с | Показывает количество строк, считываемых запросами |
| Вставленных строк/с | Измеряет скорость ингестии данных |
| Всего частей MergeTree | Показывает количество активных частей в таблицах MergeTree, помогая выявлять вставки без батчинга |
| Макс. частей в партиции | Показывает максимальное количество частей в любой партиции |
| Выполняющихся запросов | Отображает количество запросов, выполняющихся в данный момент |
| Прочитанных байт/с | Показывает объём данных, считываемых запросами |
### Метрики состояния системы
Мониторинг базовой системы не менее важен, чем мониторинг самого ClickHouse.
| Метрика | Описание |
| -------------------------------- | ----------------------------------------------------------------------------------- |
| Ожидание I/O | Отслеживает время ожидания I/O |
| Ожидание CPU | Измеряет задержки, вызванные конкуренцией за ресурсы CPU |
| Чтение с диска | Отслеживает количество байтов, прочитанных с дисков или блочных устройств |
| Чтение из файловой системы | Отслеживает количество байтов, прочитанных из файловой системы, включая кэш страниц |
| Память (отслеживается, байты) | Показывает использование памяти процессами, отслеживаемыми ClickHouse |
| Средняя нагрузка (15 минут) | Показывает текущее среднее значение нагрузки системы за 15 минут |
| Использование CPU ОС (Userspace) | Использование CPU при выполнении userspace code |
| Использование CPU ОС (Kernel) | Использование CPU при выполнении кода ядра |
## Особенности ClickHouse Cloud
ClickHouse Cloud хранит данные в Объектном хранилище (типа S3). Мониторинг этого
интерфейса помогает выявлять проблемы.
| Метрика | Описание |
| --------------------------------- | ---------------------------------------------------------------- |
| Ожидание чтения из S3 | Измеряет задержку запросов чтения к S3 |
| Ошибки чтения из S3 в секунду | Отслеживает частоту ошибок чтения |
| Чтение из S3 (байт/с) | Отслеживает скорость чтения данных из хранилища S3 |
| Disk S3 write req/sec | Отслеживает частоту операций записи в хранилище S3 |
| Disk S3 read req/sec | Отслеживает частоту операций чтения из хранилища S3 |
| Доля попаданий в кэш страниц | Доля попаданий в кэш страниц |
| Доля попаданий в файловый кэш | Доля попаданий в файловый кэш |
| Размер файлового кэша | Текущий размер файлового кэша |
| Отправка по сети, байт/с | Отслеживает текущую скорость входящего сетевого трафика |
| Получение по сети, байт/с | Отслеживает текущую скорость исходящего сетевого трафика |
| Одновременные сетевые подключения | Отслеживает текущее количество одновременных сетевых подключений |
## Выявление проблем с помощью расширенной панели мониторинга
Такое представление о состоянии вашего сервиса ClickHouse в реальном времени помогает
выявлять и предотвращать проблемы до того, как они повлияют на бизнес, а также быстрее
их устранять. Ниже приведено несколько проблем, которые можно обнаружить с помощью
расширенной панели мониторинга.
### Вставки без батчей
Как описано в [документации Best Practices](/ru/concepts/best-practices/selecting-an-insert-strategy#batch-inserts-if-synchronous), по возможности рекомендуется всегда
выполнять массовую вставку данных в ClickHouse синхронно.
Массовая вставка с разумным размером батча уменьшает количество частей, создаваемых
во время ингестии, что приводит к более эффективной записи на диск и меньшему числу операций
слияния.
Ключевые метрики для выявления неоптимальной вставки — это **Inserted Rows/sec** и
**Max Parts for Partition**
Пример выше показывает два всплеска **Inserted Rows/sec** и **Max Parts for Partition**
между 13h и 14h. Это указывает на то, что данные поступают с разумной скоростью.
Затем мы видим ещё один большой всплеск **Max Parts for Partition** после 16h, но
при этом скорость **Inserted Rows/sec** очень низкая. Создаётся много частей при
очень небольшом объёме данных, что указывает на неоптимальный размер частей.
### Ресурсоемкий запрос
Нередко приходится выполнять SQL-запросы, которые потребляют много ресурсов, например
CPU или памяти. Однако важно отслеживать такие запросы и понимать,
как они влияют на общую производительность развертывания.
Резкое изменение потребления ресурсов без изменения пропускной способности запросов может
указывать на выполнение более ресурсоемких запросов. В зависимости от типа выполняемых запросов
это может быть ожидаемым поведением, но уметь выявлять их на расширенной
панели мониторинга полезно.
Ниже приведен пример пикового использования CPU без существенного изменения
количества выполняемых запросов в секунду.
### Неудачный выбор первичного ключа
Ещё одна проблема, которую можно выявить с помощью расширенной панели мониторинга, — неудачный выбор первичного ключа.
Как описано в ["A practical introduction to primary indexes in ClickHouse"](/ru/guides/clickhouse/data-modelling/sparse-primary-indexes#a-table-with-a-primary-key),
выбор первичного ключа, который наилучшим образом соответствует вашему сценарию использования, может значительно повысить производительность
за счёт уменьшения количества строк, которые ClickHouse должен прочитать для выполнения запроса.
Одна из метрик, за которой можно следить, чтобы выявить возможные улучшения первичного ключа, —
это **Selected Rows per second**. Внезапный пик количества выбранных строк может
указывать как на общий рост пропускной способности запросов, так и на запросы,
для выполнения которых выбирается большое количество строк.
Используя временную метку в качестве фильтра, вы можете найти запросы, выполненные во время
пика, в таблице `system.query_log`.
Например, выполните запрос, который показывает все запросы, выполненные между 11:00
и 11:00 в определённый день, чтобы понять, какие запросы читают слишком много строк:
```sql title="Query" theme={null}
SELECT
type,
event_time,
query_duration_ms,
query,
read_rows,
tables
FROM system.query_log
WHERE has(databases, 'default') AND (event_time >= '2024-12-23 11:20:00') AND (event_time <= '2024-12-23 11:30:00') AND (type = 'QueryFinish')
ORDER BY query_duration_ms DESC
LIMIT 5
FORMAT VERTICAL
```
```response title="Response" theme={null}
Row 1:
──────
type: QueryFinish
event_time: 2024-12-23 11:22:55
query_duration_ms: 37407
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 150957260
tables: ['default.amazon_reviews_no_pk']
Row 2:
──────
type: QueryFinish
event_time: 2024-12-23 11:26:50
query_duration_ms: 7325
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 150957260
tables: ['default.amazon_reviews_no_pk']
Row 3:
──────
type: QueryFinish
event_time: 2024-12-23 11:24:10
query_duration_ms: 3270
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 6242304
tables: ['default.amazon_reviews_pk']
Row 4:
──────
type: QueryFinish
event_time: 2024-12-23 11:28:10
query_duration_ms: 2786
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 6242304
tables: ['default.amazon_reviews_pk']
```
В этом примере видно, что один и тот же запрос выполняется для двух
таблиц `amazon_reviews_no_pk` и `amazon_reviews_pk`. Отсюда можно сделать вывод, что
кто-то тестировал вариант первичного ключа для таблицы `amazon_reviews`.