Дашборд «Мониторинг ресурсов ноды»
Описание статьи
Дашборд используется для анализа ресурсов выбранного узла кластера Smart Monitor. Он показывает системную загрузку CPU и памяти, дисковое пространство, показатели чтения и записи, открытые HTTP-соединения, файловые дескрипторы и состояние выбранных пулов потоков.
Панели помогают найти интервал изменения показателей и направление дальнейшей проверки. По этому дашборду нельзя определить процесс — источник системной нагрузки, причину роста соединений или конкретные операции, вызвавшие очередь в пуле.
Состав дашборда
Глобальные и локальные фильтры
На дашборде доступны следующие элементы управления:
Периодзадает временной диапазон просмотра данныхНодавыбирает узел кластера для детализацииВременной интервалзадает шаг отображения временных графиковThread Poolопределяет, какие группы потоков отображаются на соответствующем графике
Цветовая индикация
Цветовая индикация помогает быстро заметить приближение показателя к предупреждающей или критичной зоне. Ее нужно использовать как ориентир для первичной оценки, а не как самостоятельное доказательство проблемы.
Цветовая индикация указывает, какой ресурс требует дальнейшего анализа, но не определяет причину изменения показателя. Порядок проверки приведен в соответствующих разделах ниже.
Метрики дашборда
Верхние индикаторы
| Панель | Что показывает | Когда смотреть |
|---|---|---|
| "Загрузка процессора, %" | Общую загрузку CPU на выбранном узле. | При поиске нехватки вычислительных ресурсов или длительных периодов высокой нагрузки. |
| "Загрузка памяти, %" | Использование оперативной памяти на уровне узла. | При росте потребления памяти, JVM-паузах или подозрении на нехватку памяти. |
| "Заполненность хранилищ, %" | Заполненность дискового пространства. | При росте объема данных, проблемах записи, merge-операциях или восстановлении шардов. |
| "Открытых file descriptors" | Количество файловых дескрипторов, открытых процессом. | При ошибках открытия файлов, сокетов или приближении к системному лимиту. |
| "Открытых HTTP соединений" | Количество открытых HTTP-соединений на узле. | При росте входящего трафика, проблемах балансировки или большом числе долгоживущих соединений. |
Системная загрузка
| Панель | Что показывает | Когда смотреть |
|---|---|---|
| "Загрузка процессора" | Динамику загрузки CPU на выбранном узле. | При поиске длительных "плато", резких скачков и связи нагрузки с поиском, записью или фоновыми операциями. |
| "Загрузка памяти" | Динамику использования оперативной памяти. | При росте памяти, JVM-паузах, активном GC или подозрениях на утечку. |
Хранилище и ввод-вывод
| Панель | Что показывает | Когда смотреть |
|---|---|---|
| "Состояние хранилища" | Занятое и доступное место на диске. | При росте объема данных, риске нехватки места и операциях восстановления. |
| "Объем чтения/записи" | Дисковую активность чтения и записи. | При проверке влияния поиска, индексации, merge-операций и восстановления данных на диск. |
Системные лимиты и HTTP-соединения
| Панель | Что показывает | Когда смотреть |
|---|---|---|
| "Открытые file descriptors" | Динамику открытых файловых дескрипторов и запас до лимита. | При устойчивом росте дескрипторов или ошибках открытия файлов и соединений. |
| "Открытые HTTP соединения" | Динамику открытых HTTP-соединений на узле. | При росте входящих подключений, перекосе нагрузки между узлами или подозрении на проблемы балансировки. |
Пулы потоков
| Панель | Что показывает | Когда смотреть |
|---|---|---|
| "Активных" | Количество потоков, выполняющих задачи. | При проверке занятости выбранного пула. |
| "В очереди" | Количество задач, ожидающих выполнения. | Если входящая нагрузка может превышать скорость обработки. |
| "Прерванных" | Количество отклоненных задач. | Если пользователи получают ошибки или пул не принимает новые задачи. |
| "Всего" | Общее число потоков в пуле. | Для сравнения с количеством активных потоков. |
Примеры диагностики проблем
Первичная оценка состояния узла
Верхние индикаторы используйте как первый этап проверки выбранного узла. Они помогают быстро понять, какой ресурс требует дальнейшей детализации на графиках ниже.
Если выделяется CPU или память, проверьте динамику в разделе "Анализ CPU и памяти" и сопоставьте период с поиском, индексацией и JVM. Если выделяется диск, переходите к разделу "Анализ диска и I/O" и оцените темп роста данных. Если растут file descriptors или HTTP-соединения, используйте графики раздела "Проверка системных лимитов и HTTP-соединений" и сравните с узлами той же роли.
Анализ CPU и памяти
Системную загрузку анализируйте по форме графика: короткие пики, устойчивый рост без возврата к нормальным значениям, ступенчатый рост и возврат к обычному уровню требуют разной проверки.
Дашборд показывает общую загрузку CPU на узле, но не распределяет ее по процессам. Если на сервере работают другие сервисы, по этому графику нельзя отнести нагрузку к Smart Monitor.
Если рост совпадает с поисковыми операциями, проверьте дашборды «Мониторинг производительности запросов» и «Число запросов в кластере по типу». При совпадении с записью используйте «Мониторинг производительности индексирования». Если одновременно растет память, появляются паузы или снижается стабильность узла, проверьте «Мониторинг JVM ноды».
Анализ диска и I/O
Снижение свободного места и рост дисковой активности анализируйте отдельно. Если свободное место последовательно уменьшается, проверьте объем и скорость записи в дашборде «Мониторинг производительности индексирования».
Если растет I/O, сопоставьте период с поисковой нагрузкой в дашборде «Мониторинг производительности запросов» и с индексированием. При восстановлении или перемещении шардов дополнительно проверьте «Состояние кластера».
Если изменение совпадает с потоком данных через Logstash, используйте «Мониторинг Logstash» и «Мониторинг JVM ноды Logstash».
Проверка системных лимитов и HTTP-соединений
Линия лимита файловых дескрипторов соответствует ограничению, настроенному в ОС для процесса Smart Monitor. Перед оценкой запаса сравните ее с фактическими значениями LimitNOFILE в конфигурации systemd или nofile в пользовательских лимитах. Рекомендуемые значения и порядок настройки приведены в разделе «Open File Descriptors».
HTTP-соединения анализируйте не только по росту на одном узле, но и по распределению между узлами. Устойчивый рост может указывать на увеличение клиентского трафика или большое количество долгоживущих соединений.
Сравнивайте узлы с одинаковыми ролями. На узлах одной роли количество HTTP-соединений должно быть примерно сопоставимым, а на SM Master — значительно меньше, чем на SM Data Storage.
Если число соединений растет на всех узлах одной роли, проверьте изменение пользовательской нагрузки в дашборде «Число запросов в кластере по типу». Если рост наблюдается только на одном узле, проверьте в конфигурации балансировщика состав backend-узлов, их веса и алгоритм распределения, а также исключите прямые подключения клиентов к этому узлу.
Анализ пулов потоков
Пулы потоков анализируйте с учетом роли узла. Сравнение разных ролей может привести к неверным выводам: для master-узлов и data-узлов ожидаются разные рабочие профили и разные наборы значимых пулов.
| Роль узла | Пулы |
|---|---|
| SM Master | management, generic, search, fetch_shard_started, fetch_shard_store |
| SM Data Storage | write, bulk, search, refresh, flush, generic, fetch_shard_started, fetch_shard_store, management, sme, job_scheduler |
Признаки перегрузки пула:
- растет
В очереди: задачи ожидают свободного потока - растет
Прерванных: часть задач отклоняется Активныхприближается кВсего: пул работает близко к полной занятости
Если перегрузка видна только на одном узле, проверьте размещение и состояние шардов в дашборде «Состояние кластера». Для пула search сопоставьте период с «Мониторингом производительности запросов», для write и bulk — с «Мониторингом производительности индексирования».
Типовые сценарии
Устойчивый рост открытых HTTP-соединений
Сценарий наблюдается, когда количество открытых HTTP-соединений устойчиво растет и не возвращается к обычному уровню. Такая картина может быть связана с ростом пользовательского трафика, большим числом долгоживущих соединений или закреплением пользователей за отдельными узлами.
На изображении количество открытых HTTP-соединений сначала колеблется около одного уровня, затем устойчиво растет и не возвращается к прежним значениям до конца периода. Сравните график с узлами той же роли. Если рост наблюдается на всех однотипных узлах, проверьте изменение нагрузки в дашборде «Число запросов в кластере по типу». Если выделяется один узел, проверьте в конфигурации балансировщика состав backend-узлов, их веса и алгоритм распределения, а также прямые подключения клиентов к этому узлу.
Приближение к лимиту открытых файловых дескрипторов
Сценарий наблюдается, когда количество открытых file descriptors устойчиво растет и приближается к лимиту. В этом состоянии процессу может не хватить дескрипторов для открытия файлов индекса, журналов, сетевых сокетов и служебных файлов.
На изображении количество открытых файловых дескрипторов растет примерно с 27 000 до 64 000 и приближается к линии лимита. Линия показывает ограничение, настроенное в ОС для процесса Smart Monitor, а не оценочное значение: его необходимо сверять с LimitNOFILE или пользовательским лимитом nofile. Рекомендуемые настройки приведены в разделе «Open File Descriptors». При сокращении запаса проверьте журнал Smart Monitor на сообщения Too many open files. Сам график показывает риск достижения лимита, но не определяет причину роста числа дескрипторов.
Устойчивая нагрузка на процессор
Сценарий наблюдается, когда загрузка CPU длительное время удерживается на одном уровне и не возвращается к обычным для узла значениям. Отклонением могут быть значения не только на уровне 80–100%, но и около 50%, если раньше узел стабильно работал с меньшей нагрузкой. Уровни 80%, 90% и 100% требуют особого внимания, поскольку вычислительный запас узла становится минимальным.
На изображении загрузка CPU сначала держится около 40%, затем ступенчато возрастает примерно до 55% и остается на этом уровне до конца периода.
Эта ситуация явно указывает на проблему в Smart Monitor только в том случае, если на узле установлен только Smart Monitor и нет других ресурсоемких процессов. Если на сервере работают дополнительные сервисы, сначала проверьте потребление CPU на уровне операционной системы и убедитесь, что нагрузку создает именно процесс Smart Monitor.
Рост очереди и счетчика Rejected в пуле потоков
Сценарий наблюдается, когда в одном или нескольких пулах растет очередь задач, появляются rejected tasks или количество активных потоков приближается к общему числу потоков в пуле.
На изображении выбран пул search. Видно, что очередь задач растет, а вместе с ней увеличивается значение «Прерванных». Это означает, что часть задач не была принята в обработку.