Дашборд «Число запросов в кластере по типу»

Описание статьи

Дашборд используется для анализа задач Smart Monitor, которые выполняются в кластере. Под запросами в рамках этой статьи понимаются записи о задачах: пользовательские операции, внутренние служебные действия, операции поиска, записи, мониторинга и обслуживания кластера.

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

Состав дашборда

Глобальные и локальные фильтры

На дашборде доступны следующие элементы управления:

• Период задает временной диапазон просмотра данных
• Тип задачи используется для ограничения анализа выбранным типом операции
• Node выбирает узел кластера для детализации
• ID задачи используется для поиска или проверки конкретной задачи по идентификатору

Метрики дашборда

Операционная активность

Панель	Что показывает	Когда смотреть	Ориентиры штатной работы	Когда нужна дополнительная проверка
"Количество actions в кластере"	Распределение записей о задачах по типам action.	Когда нужно понять, какие классы операций формируют основную активность кластера.	Распределение соответствует известному профилю нагрузки и плановым операциям.	Устойчивый рост отдельного action стоит сопоставить с пользовательским трафиком, действиями с шардами, ресурсами и задержками. Объем задач не определяет перегрузку.
"Запросов больше 1 сек"	Количество задач, которые превысили порог длительности, отраженный в названии панели.	При первичной проверке роста длительно выполняющихся задач.	Значение оценивается с учетом типа задач и требований к их длительности. Ненулевое значение может быть ожидаемым для долгих служебных операций.	Рост числа задач выше порога стоит проверить, если он затрагивает пользовательские операции, сохраняется дольше обычного или совпадает с очередями и ошибками.

Детализация и связи задач

Панель / поле	Что показывает	Когда смотреть
Детальная таблица задач	Список задач с техническими атрибутами.	Когда нужно перейти от агрегированных панелей к конкретным строкам.
"Время выполнения, сек"	Длительность выполнения задачи в представлении дашборда.	При сортировке таблицы и поиске задач, требующих дальнейшей проверки.
"Нода"	Узел, на котором выполнялась задача.	При проверке, распределена ли задержка по кластеру или сконцентрирована на отдельных узлах.
"Тип задачи"	Тип операции в строке таблицы.	При сопоставлении строк таблицы с распределением action на графике.
"ID задачи"	Идентификатор конкретной задачи.	При сопоставлении строк и отделении разных задач от повторяющихся записей.
"ID родительской задачи"	Идентификатор родительской операции.	При группировке дочерних задач, относящихся к одной распределенной операции.

Примеры диагностики проблем

Первичная оценка активности кластера

Начинайте анализ с распределения action и индикатора длительно выполняющихся задач. Это помогает понять, изменился ли общий профиль операций и есть ли задачи, которые требуют проверки в таблице.

Резкий рост отдельного типа операции сам по себе не означает инцидент. Его нужно сопоставить с пользовательским трафиком, плановыми заданиями, операциями обслуживания шардов и состоянием узлов.

Анализ распределения операций

График "Количество actions в кластере" показывает структуру операционной активности. Высота столбцов отражает общий объем записей о задачах в выбранном периоде, а цветные сегменты показывают вклад отдельных типов action.

График не измеряет загрузку ресурсов и очереди пулов потоков. При росте поисковых операций откройте «Мониторинг производительности запросов»: на панелях «Фазы "Query": кол-во запросов и затраченных секунд» и «Среднее время в фазе "Query"» сравните число операций и длительность поисковой фазы за тот же период. Если задержка связана с получением документов, посмотрите аналогичные панели фазы Fetch. При росте операций записи на дашборде «Мониторинг производительности индексирования» сопоставьте «Количество индексаций» со «Средним временем индексации документа»; при задержках записи проверьте также «Время в подавлении». При росте служебных операций с шардами в «Состоянии кластера» проверьте «Статусы шардов», «Процент активных шардов» и «Журнал сообщений кластера»: есть ли в тот же период перемещение, восстановление или проблемы с размещением шардов.

Анализ длительно выполняющихся задач

Индикатор "Запросов больше 1 сек" используйте как сигнал для перехода к детальной таблице. Он показывает, что в выбранном контексте есть задачи с увеличенной длительностью, но не объясняет причину этой длительности.

Если длительно выполняющиеся задачи сконцентрированы на одном узле, проверьте «Мониторинг ресурсов ноды» и «Мониторинг JVM ноды», а для поисковых задач также «Мониторинг производительности запросов». На дашборде ресурсов сопоставьте «Загрузку процессора», «Объем чтения/записи», «В очереди» и «Прерванных» для соответствующего пула потоков; на дашборде JVM — «Использование Heap, %» и «Среднее время паузы GC». Для поисковых задач сравните «Среднее время в фазе "Query"» и при необходимости «Среднее время в фазе "Fetch"»; события панели «Журнал SME запросов» сопоставьте по времени и узлу, если соответствующие записи в ней есть.

Если длительно выполняющиеся задачи связаны с записью, на дашборде «Мониторинг производительности индексирования» проверьте «Среднее время индексации документа», «Время в подавлении» и «Неудавшиеся индексации». Если события поступают через Logstash, на дашборде «Мониторинг Logstash» сопоставьте динамику счетчиков полученных, обработанных и отправленных событий на панели «Кол-во событий за время работы Logstash» и проверьте «Журнал сообщений».

Анализ связей по родительскому ID

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

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

Типовые сценарии

Группа длительно выполняющихся задач с общим родительским ID

Сценарий наблюдается, когда индикатор длительных задач показывает рост, а в таблице есть несколько строк с одинаковым "ID родительской задачи". Такая картина указывает, что несколько дочерних задач могут относиться к одной распределенной операции.

На изображении показан пример совместного анализа трех зон дашборда: распределения action, индикатора длительных задач и детальной таблицы. Последовательность проверки остается одинаковой: определить доминирующий тип операции, найти длительно выполняющиеся строки, сравнить узлы и проверить, есть ли у задач общий "ID родительской задачи".

Разбор обычно идет в таком порядке:

• Проверить индикатор «Запросов больше 1 сек». Определите, растет ли метрика и превышает ли ожидаемое значение
• Посмотреть график «Количество actions в кластере». График помогает понять, какой тип операций преобладает в выбранном периоде
• Перейти к детальной таблице. В таблице сравните тип операции, узел, время выполнения, «ID задачи» и «ID родительской задачи»
• Сгруппировать строки по родительскому ID. Если строки связаны одним родительским ID, анализируйте их как одну распределенную операцию. Если родительские ID разные, проверьте общий профиль нагрузки и распределение по узлам