Перейти к основному содержанию
Мониторинг вашей системы баз данных в промышленной среде крайне важен для понимания состояния развертывания, чтобы вы могли предотвращать сбои и устранять их. Расширенная панель мониторинга — это легковесный инструмент, предназначенный для того, чтобы дать вам глубокое представление о вашей системе ClickHouse и ее окружении, помогая заранее выявлять узкие места в производительности, системные сбои и неэффективность. Расширенная панель мониторинга доступна как в ClickHouse OSS (Open Source Software), так и в Cloud. В этой статье мы покажем, как использовать расширенную панель мониторинга в Cloud.

Доступ к расширенной панели мониторинга

Чтобы открыть расширенную панель мониторинга, перейдите в:
  • Левая боковая панель
    • MonitoringAdvanced dashboard

Доступ к встроенной расширенной панели мониторинга

Чтобы открыть встроенную расширенную панель мониторинга, перейдите:
  • в левую боковую панель
    • MonitoringAdvanced dashboard
    • Нажмите You can still access the native advanced dashboard.
После этого встроенная расширенная панель мониторинга откроется в новой вкладке. Для доступа к панели мониторинга потребуется пройти аутентификацию. С каждой визуализацией связан SQL-запрос, который её заполняет. Вы можете изменить этот запрос, нажав на значок пера.

Готовые визуализации

Стандартные диаграммы на расширенной панели мониторинга позволяют в реальном времени отслеживать состояние вашей системы ClickHouse. Ниже приведен список с описанием каждой диаграммы. Для удобства они сгруппированы в три категории.

Для ClickHouse

Эти метрики предназначены для мониторинга состояния и производительности вашего экземпляра ClickHouse.

Метрики состояния системы

Мониторинг базовой системы не менее важен, чем мониторинг самого ClickHouse.

Особенности ClickHouse Cloud

ClickHouse Cloud хранит данные в Объектном хранилище (типа S3). Мониторинг этого интерфейса помогает выявлять проблемы.

Выявление проблем с помощью расширенной панели мониторинга

Такое представление о состоянии вашего сервиса ClickHouse в реальном времени помогает выявлять и предотвращать проблемы до того, как они повлияют на бизнес, а также быстрее их устранять. Ниже приведено несколько проблем, которые можно обнаружить с помощью расширенной панели мониторинга.

Вставки без батчей

Как описано в документации Best Practices, по возможности рекомендуется всегда выполнять массовую вставку данных в 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”, выбор первичного ключа, который наилучшим образом соответствует вашему сценарию использования, может значительно повысить производительность за счёт уменьшения количества строк, которые ClickHouse должен прочитать для выполнения запроса. Одна из метрик, за которой можно следить, чтобы выявить возможные улучшения первичного ключа, — это Selected Rows per second. Внезапный пик количества выбранных строк может указывать как на общий рост пропускной способности запросов, так и на запросы, для выполнения которых выбирается большое количество строк. Используя временную метку в качестве фильтра, вы можете найти запросы, выполненные во время пика, в таблице system.query_log. Например, выполните запрос, который показывает все запросы, выполненные между 11:00 и 11:00 в определённый день, чтобы понять, какие запросы читают слишком много строк:
Query
Response
В этом примере видно, что один и тот же запрос выполняется для двух таблиц amazon_reviews_no_pk и amazon_reviews_pk. Отсюда можно сделать вывод, что кто-то тестировал вариант первичного ключа для таблицы amazon_reviews.
Последнее изменение 2 июля 2026 г.