Мониторинг
Настройка Prometheus
Пререквизиты
- установить prometheus-operator по инструкции.
Запуск
Сервисы для мониторинга создаются оператором YTsaurus автоматически. Для сбора метрик необходимо:
- Создать ServiceMonitor.
- Создать сервисный аккаунт.
- Выдать созданному аккаунту роль.
- Создать 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"}
— процент использования дисковой квоты.