Мониторинг

Настройка Prometheus

Пререквизиты

• установить prometheus-operator по инструкции.

Запуск

Сервисы для мониторинга создаются оператором YTsaurus автоматически. Для сбора метрик необходимо:

1. Создать ServiceMonitor.
2. Создать сервисный аккаунт.
3. Выдать созданному аккаунту роль.
4. Создать Prometheus.

Способы мониторинга и важные метрики YTsaurus

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

Качественный мониторинг

Качественный мониторинг проверяет, способна ли система выполнять свою базовую функциональность. Для этого запускаются тестовые задания или, по-другому, проверки. Такие проверки возвращают качественное описание проверяемой системы:

• работает в штатном режиме (OK);
• не работает (CRITICAL);
• работает, но с отклонениями от штатного режима (WARNING).

Список наиболее важных качественных проверок YTsaurus:

• sort_result — запускает sort операцию над небольшой тестовой таблицей, ждет её завершения и проверяет результат сортировки;
• map_result — запускает map операцию с небольшой тестовой таблицей на входе, ждет её завершения и проверяет результат map;
• dynamic_table_commands — проверяет работоспособность динамических таблиц, проходя весь жизненный цикл динамической таблицы: создаёт тестовую таблицу, монтирует таблицу, записывает и читает данные из таблицы, после чего отмонтирует и удаляет таблицу.

Существуют проверки сообщений самодиагностики подсистем YTsaurus кластера:

• master_alerts — проверяет значение атрибута //sys/@master_alerts;
• scheduler_alerts — проверяет значение атрибута //sys/scheduler/@alerts;
• controller_agent_alerts — вычитывает атрибут alerts из всех узлов из //sys/controller_agents/instances;
• lost_vital_chunks — проверяет, что счетчик lost_vital_chunks равен нулю из //sys/lost_vital_chunks/@count. Подробнее про vitality можно прочитать по ссылке;
• tablet_cells — проверяет, что в динамических таблицах нет tablet cells в статусе failed;
• quorum_health — проверяет, что все мастера работают и находятся в кворуме.

Реализацию данных проверок можно посмотреть в Odin.

В текущей реализации odin не поддерживает алерты, только запуск проверок с сохранением результатов в динамическую таблицу с отображением в UI.

Количественный мониторинг

Для количественного мониторинга с различных подсистем снимаются метрики в виде временных рядов (Time series data). С их помощью можно оценить тенденции нагрузки и потребляемых ресурсов и исправить ситуацию до появления проблем на кластере, заметных пользователям.

Некоторые важные количественные метрики в Prometheus:

• yt_resource_tracker_total_cpu{service="yt-master", thread="Automaton"} — загрузка Automaton, основного исполняющего потока мастера. Загрузка не должна быть больше 90%;
• yt_resource_tracker_memory_usage_rss{service="yt-master"} — использование мастером памяти. Порог должен быть чуть меньше половины памяти контейнера. Мастер делает fork для записи снапшота, потому должен быть двойной запас по памяти;
• yt_resource_tracker_memory_usage_rss — важная метрика и для других компонентов кластера, позволяющая оценить тенденцию потребления памяти для избежания событий out of memory;
• yt_changelogs_available_space{service="yt-master"} — свободное место под changelogs. В конфигурационном файле мастера есть настройка хранения changelogs, свободного места должно быть больше, чем эта настройка;
• yt_snapshots_available_space{service="yt-master"} — аналогично для snapshots;
• yt_logging_min_log_storage_available_space{service="yt-master"} — аналогично для logs.

Необходимо следить за ростом чанков в «нехороших» состояниях:

• yt_chunk_server_underreplicated_chunk_count — число чанков, имеющих на дисках кластера меньше реплик, чем указано в атрибуте replication_factor. Постоянный рост underreplicated может говорить о том, что настройки media не позволяют выполнять условия replication_factor в текущей конфигурации кластера. Число underreplicated чанков можно посмотреть в //sys/underreplicated_chunks/@count;
• yt_chunk_server_parity_missing_chunk_count и yt_chunk_server_data_missing_chunk_count — постоянный рост parity_missing_chunk или data_missing_chunk может быть вызван тем, что процесс починки erasure не успевает за поломкой при выходе хостов или дисков из строя. Число parity_missing и data_missing чанков можно посмотреть в //sys/parity_missing_chunks/@count и //sys/data_missing_chunks/@count.

Важно отслеживать квоты системных аккаунтов, таких как sys, tmp, intermediate, а также пользовательские квоты продуктовых процессов. Пример для аккаунта sys:

• yt_accounts_chunk_count{account="sys"} / yt_accounts_chunk_count_limit{account="sys"} — процент использования чанковой квоты;
• yt_accounts_node_count{account="sys"} / yt_accounts_node_count_limit{account="sys"} — процент использования квоты на число узлов Кипариса;
• yt_accounts_disk_space_in_gb{account="sys"} / yt_accounts_disk_space_limit_in_gb{account="sys"} — процент использования дисковой квоты.