Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито.
При работе с тысячами серверов, объединенных в десятки кластеров, важно иметь инструменты для быстрой диагностики. В инфраструктуре на многих уровнях что-то может пойти не та, и очень здорово, если ты можешь быстро исключить тот или иной уровень. Либо наоборот – понять, что на него нужно обратить пристальное внимание.
Эта статья посвящена дашбордам для Grafana, существенно упрощающим диагностику различных систем. Я расскажу про новые подходы, которые я использовал при создании дашбордов, и продемонстрирую, как эти подходы реализованы на практике в отношении серверов и кластеров Kubernetes.
Что внутри статьи:
Пример реализации в отношении кубонод
Пример реализации в отношении кластера в целом
О подходах при создании
Раньше для диагностики нод и Kubernetes-кластеров нам приходилось открывать несколько дашбордов и пролистывать десятки графиков. С этим было связано две проблемы:
во-первых, это создавало значительную когнитивную нагрузку на инженеров. Графики требуют интерпретации, а когда их слишком много – легко упустить что-то важное;
во-вторых, сложно было обмениваться экспертизой по интерпретации графиков. Опыт у всех разный. Кто-то знает, какие значения softnet times squeezed являются критичными, кто-то нет, и это нормально.
В 2024 году нам удалось достичь существенного повышения observability в наших Kubernetes-кластерах. Большую роль в этом сыграли два спроектированных мною дашборда. При их создании я использовал несколько подходов. Я ранее не встречал, чтобы кто-нибудь применял их одновременно, а именно их совместное применение, на мой взгляд, делает использование дашбордов столь удобными для быстрой диагностики.
Вот эти подходы:
вся значимая информация об объектах собрана на одном дашборде с максимально компактным ее представлением;
использована единообразная цветовая сигнализация о том, на что стоит обратить внимание;
расширенная информация находится на расстоянии одного клика;
дашборд обогащен сведениями о действиях администраторов.
Пример реализации в отношении кубонод
Дашборд Node Status позволяет позволяет достичь сразу нескольких целей, но в первую очередь он служит для быстрой диагностики выбранной ноды в Kubernetes-кластере.
Компактное представление
Как вы видите, почти все метрики представлены в виде небольших панелей с текущим значением и примерным графиком его изменения во времени. В терминах Grafana это означает использование Stat со включенным Graph Mode вместо стандартных Time Series. Так удается компактно разместить большое число метрик, охватить которые можно практически одним взглядом. При этом наиболее важная информация не только не теряется, но и как бы выходит на первый план. Не требуется совершать никаких дополнительных действий для того, чтобы увидеть текущее значение метрики и составить представление о том, что происходило с ней в прошлом. Так реализован первый подход – вся значимая информация собрана на одном дашборде с максимально компактным ее представлением.
Цветовая сигнализация
Большинство панелей в приведенном мною примере являются зелеными, и только некоторые из них подсвечены оранжевым. Оранжевый означает «обрати внимание». Помимо него мы используем также красный («здесь явно что-то не так») и синий («нет данных, хотя в обычных обстоятельствах они должны быть») цвета. Подсветка выполняется через Thresholds и Value Mappings. Так реализован второй подход – единообразная цветовая сигнализация. Сложность здесь состоит в том, чтобы отобрать только те метрики, для которых можно предусмотреть пороги, и аккуратно подобрать сами пороги, в дальнейшем совершенствуя их при необходимости.
На расстоянии клика
Абсолютное большинство панелек – активные. Это означает, что на них можно кликнуть, чтобы получить более подробную информацию. Предположим, вы открываете дашборд, выбираете ноду, которая вызывает у вас подозрения, и видите, что панелька Memory Usage горит оранжевым. Теперь вы хотите больше узнать о потреблении оперативной памяти. Для этого достаточно кликнуть по панельке, и почти мгновенно в том же окне браузера на полный экран откроется следующий график:
Или вот другой пример - на панельке Kubelet Runtime отображается самое длинное выполнение операции kubelet с docker или containerd. Если кликнуть по ней, то откроется график, на котором видно, сколько времени занимало выполнение операций каждого вида:
Наконец, последний пример – посмотрите на панельку Load Average. Сейчас она зеленая. В нашем случае это означает, что показатель LA за одну минуту держится ниже 70% от числа процессорных ядер. Однако на ней заметен всплеск.
Если мы щелкнем по панели, то увидим следующую картину:
Видно, что всплеск был существенным. В этом конкретном случае он вызван рестартом деградировавшего container runtime, но в общем случае такой график – неплохой старт для того, чтобы копнуть глубже. Напомню, что всплеск был виден на маленькой панели. Именно поэтому стоит использовать микропанели с графиками, а не с одними только текущими значениями.
Итак, использовать мгновенно открывающиеся графики по щелчку на панели, довольно удобно, но так мы добираемся только одного из вариантов представления метрик. Другие дашборды, которые мы используем, используют другие метрики и другие варианты отображения. Иногда мы хотим посмотреть и на них. Рядом с заголовком у некоторых панелек находится значок ссылки. После клика по нему в новом окне откроется альтернативный дашборд. Это полезно, например, в тех случаях, когда одни и те же подсистемы мониторятся одновременно разными способами или для быстрого доступа к специализированным бордам.
Так выполнен третий из провозглашенных подходов - расширенная информация находится на расстоянии одного клика. Механика активных панелек реализована с помощью Data Links, которые содержат ссылки на панели с той же самой дашборды, но расположенные внизу страницы (что и позволяет им открываться почти мгновенно). Механика значков со ссылками на другие дашборды выполнена с помощью Panel Links.
Не только метрики
Открыв дашборд в отношении некоторых наших нод, можно увидеть сообщения о действиях, выполненных инженерами, а также их комментарии в отношении нод. В ходе подготовки скриншотов нашел вот такой забавный комментарий, оставленный коллегой:
С технической точки зрения указанные сообщения – аннотации Grafana с тегами в виде имен нод. Я добавил их простановку в kubectl-плагины, которые мы используем, например, для дрейна/кордона/раскардона нод. К ним я добавил плагин kubectl comment, который позволяет добавлять заметки любого содержания. Например, если на ноде возникла какая-то нетипичная проблема, мы стараемся оставить комментарий с её описанием. Тогда, если эта нода позже попадет на радары коллег, они будут знать ее предысторию.
Мы разобрали практическое применение всех четырех упомянутых мною подходов. Помимо них, при реализации дашборды Node Status использовалось немало хитростей. Например, на последнем скриншоте можно заметить, что панелька Pods разбивается на две в том случае, если появляются поды в статусе NotReady и является единой, если таких подов нет (как на первом скриншоте). Это достигнуто за счет трансформаций типа Group by и Rows to fields. Описание всех подобных нюансов заняло бы много места и было бы привязано к специфике метрик, которые мы используем. Но если вам интересны способы реализации конкретных элементов, я буду рад рассказать о них в комментариях.
Пример реализации в отношении кластера в целом
Второй дашборд призван отображать статус Kubernetes-кластера. Я покажу только его половину, поскольку оставшаяся часть не представляет интереса в контексте этой статьи.
Несложно заметить, что тут в целом использованы те же подходы. Обратите внимание, как много панелек имеют значок i после заголовка. Всплывающие подсказки используются и на предыдущем дашборде, однако здесь их больше из-за того, что метрики control-plane сложнее интерпретировать. Подсказки позволяют накапливать экспертизу и делать ее общедоступной для всех инженеров.
Из интересного можно отметить панель max etcd objects, на которой отображается количество объектов того типа, которых сейчас больше всего в etcd, за исключением объектов типа events. Эта панель призвана детектировать известную проблему, когда etcd забивается большим числом нестандартных объектов, создаваемых, например, Kyverno. Поэтому на самой панели виден только лидер. Однако, кликнув по ней, можно увидеть динамику изменения количества объектов всех типов во времени:
Другой любопытный пример – панель controlplane status. Она автоматически разбивается на плитки по числу компонентов, сведения о которых возвращает Kubernetes в одноименной метрике. Их число может отличаться от версии к версии Kubernetes.
На скриншоте из кластера k8s 1.29 их довольно много, поэтому разглядеть название отдельных компонентов сложно. Представим, что одна из плиток загорелась красным, и нам нужно посмотреть, какой именно компонент не в порядке. Для этого достаточно навести мышь на панель и нажать «v», в результате чего панель с плитками откроется на весь экран.
Подведение итогов
Дашборд Node Status существенно упростил наш алгоритм поиска проблем на нодах. Многие аномалии теперь бросаются в глаза. Он уже множество раз позволял нам быстро понять, что пошло не так. Поэтому я могу с уверенностью сказать, что подходы, на которых он основан, в нашем случае работают.
Cluster Status создан позднее и является менее зрелым решением. Тем не менее, и он оказывался полезен, чтобы подсветить вход control plane в «желтые зоны», например, избыточный рост потребления памяти на мастерах. Кроме того, мы используем его при проведении работ на мастер-нодах, поскольку он позволяет быстро оценить, затронута ли ими функциональность control plane.
Про дашборды на этом все. Если вам интересно обсудить детали реализации – пожалуйста, задавайте вопросы в комментариях.
cru5ader
Спасибо за статью, думаю нам было бы тоже интересно сравнить ваши дашборды.
А где сами дашборды для скачивания?)
lyova Автор
Дашборды мы не выкладывали, они слишком завязаны на нашу специфику, поэтому существенная часть панелей все равно не работала бы. Я привел их просто как примеры того, как можно реализовать предложенные подходы.