Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков. Персональный стенд в понимании нашей компании - это отдельно выделенный под разработчика неймспейс в кластере Kubernetes. У себя мы их называем ksb - “kubernetes-sandbox” и дальше дописываем, кому он принадлежит, пример наименования такого стенда: ksb-ivan-ivanov. Такое распределение позволяет легко идентифицировать принадлежность стенда, и исходя из этого формируется dns имя для фронта продукта. 

Обязательно хочу подсветить предпосылки, которые послужили триггером для появления такого дашборда:

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

2. Нагрузка на инфраструктуру стала критичной, требуя более эффективных средств мониторинга и отладки для поддержания стабильности и высокой производительности.

3. Жалобы разработчиков на сложности в решении инцидентов подчеркнули актуальность внедрения более эффективных средств отладки.

4. Использование Grafana для создания дашбордов, объединяющих метрики и логи, обеспечивает интуитивно понятное представление состояния персональных стендов, снижая время реакции на проблемы.

Но сначала я бы хотел поделиться тем, какими инструментами мы пользуемся для сбора метрик и логов. Метрики собираются с помощью kube-prometheus-stack-42.1.0, а логи собираем при помощи promtail и храним их в Loki, используя loki-stack-2.9.1. Дашборды отображаем в Grafana 8.4.1. Разработка микросервисов осуществляется на платформе .NET версии 7.0. Фреймворк ASP.NET Core используется для построения веб-приложений. Для подразделения разработки у нас выделен отдельный K8S кластер, в котором, в теории на каждого разработчика, мы можем выделять два персональных неймспейса, которые в дальнейшем я буду называть персональными стендами. Интеграция kube-prometheus-stack обеспечивает полный мониторинг состояния кластера Kubernetes и микросервисов в реальном времени.

Какова была основная цель создания общего дашборда для персональных стендов разработчиков? Необходимо понимать два момента, как это работает у нас в компании: 

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

Второй момент: хотелось бы, чтобы разработчик сам мог решить проблему в случае, если деплоймент упал по той или иной причине. 

Мы стараемся выводить дополнительную информацию о различных ошибках в лог gitlab-pipeline. Это могут быть логи из проблемных подов, ошибки линтера helm-template своего микросервиса и прочее. После деплоя разработчик получает ссылку на свой Grafana-дэшборд, с помощью которого может оценить состояние своего стенда на момент разворачивания и, возможно, самостоятельно исправить возникшие проблемы. Дашборд предоставляет алгоритмы и базу знаний для типовых проблем, которые разработчики могут решить самостоятельно. Например, проблемы с конфигурацией, зависимостями или неисправностями в коде. В случае более сложных проблем, которые разработчики не могут решить самостоятельно, существует установленный флоу, описанный в предыдущей статье о правиле 30 минут. По прошествии этого времени вопрос автоматически переходит к команде DevOps.

Далее речь пойдет о Grafana-дашборде. Для начала разберем основные элементы дашборда.

Он состоит из базовых сущностей, таких как переменные:

Они помогают централизованно формировать запросы и одновременно изменять панели на всем дашборде.

Список переменных:

1. datasource — то, откуда мы будем собирать метрики и логи.

2. namespace — обозначающая имя персонального стенда.

3. container error — отображающая проблемные поды в неймспейсе.

4. ingress — связанные с ингрессом выбранного стенда, для сбора статистики по ошибкам и задержкам до фронта.

Сам дашборд разделен на пять основных глав:

Состояние здоровья подов в неймспейсе

Эта панель отображает состояние всех микросервисов на стенде, используя метрику aspnetcore_healthcheck_status.

Панель на дашборде формирует ссылку на персональный стенд:

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

Каждый микросервис отдает метрику aspnetcore_healthcheck_status по которой мы определяем, в порядке наш микросервис или нет:

Основное окружение неймспейса

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

Далее собираем таблицу с общей информацией:

• под;

• время жизни;

• ip-адрес;

• количество рестартов;

• нода, на которую под распределил Kubernetes.

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

Ниже привожу пример по формирования ссылки на дашборд с нужными параметрами, при переходе по ней формируются необходимые панельки по интересующей нас ноде.

Сформированная ссылка на дашборд:

Готовый дашборд и информация по метрикам проблемной ноды:

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

Сервисы в неймспейсе

Следующая глава дашборда - это сущности сервисов и ингрессов внутри персонального стенда. Она полезна для анализа состояния стенда или проведения тестирования.

Как и в предыдущей главе, тут собрана табличка с информацией по ингрессам и сервисам. И столбец service-name позволяет нам отправить пользователя на дополнительный дашборд с более детальной информацией по каждому ингрессу в его персональном стенде.

Конфигурации и хранилища неймспейса

Дашборд содержит информацию о конфигмапах, секретах и проблемных PVC внутри персонального стенда.

Логи с ошибками контейнера

Здесь отображаются логи с ошибками проблемных подов. Разработчик может группировать логи и метрики по контейнеру и неймспейсу.

И дальше мы видим последние сто строк ошибочного контейнера. Переключение между проблемными контейнерами в подах производится с помощью variables container_error.

Таким образом, мы предоставляем разработчикам инструменты для самостоятельного анализа и решения проблем на их персональных стендах.

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

Для удобства полезно выставить переключатель  “Open in new tab” при переходе по ссылке:

Для примера рассмотрим формирование ссылки на ноду/хост, где возникла ошибка при развертывании пода. Начнем с создания сводной таблицы по набору метрик и использования параметра Transform для логического распределения и формирования правильной таблицы. Затем определим основные полезные поля таблицы, прежде чем перейти к формированию ссылок на дашборд.

Пример настройки параметра Transform:

Пример таблицы подов в неймспейсе main:

В таблице мы видим название ноды, на которой был развернут под. Для лучшего понимания происходящего в момент развертывания пода или его работы мы направляем пользователя на дашборд с метриками от сервиса Node-Exporter. Перекрестную ссылку можно создать, используя параметр "$__value.raw", что позволяет подготовить нужный дашборд с необходимой нодой и временным периодом.

В разобранном примере с той же нодой мы можем также предоставить пользователю возможность погружения еще глубже в другой дашборд с более подробными метриками. Конечно, чаще всего, если пользователь понял, что проблема связана с инфраструктурой, он передает ссылку инженеру/DevOps для более детального анализа. Однако сам факт использования вложенности помогает пользователю понимать, что происходит с его стендом, и на какие ошибки и проблемы следует обратить внимание. 

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

Ну и, конечно же, нельзя не поговорить про баги в дашборде. Если панель в дашборде отображает что-то неверно, вносятся исправления через UI, и бекапом собираем JSON из Grafana. Настройки и конфигурации дашбордов хранятся в Git-репозитории, что обеспечивает единый и управляемый способ хранения изменений. В будущем планируем расширить процесс изменений дашбордов через Git-репозиторий и CI/CD. Это включает в себя возможность внесения изменений через репозиторий, автоматизированные пайплайны и интеграцию с системой управления конфигурациями.

Заключение

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

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

• Расширить возможности изменения дашбордов через Git-репозиторий и CI/CD, что обеспечит более прозрачное и автоматизированное управление конфигурациями.

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

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

Особо стоит выделить применение вложенных ссылок на дополнительные дашборды, что открывает двери для более глубокого анализа проблем. Этот метод позволяет не только быстро выявить первопричину ошибки, но и предоставляет пользователям инструменты для самостоятельного решения возникающих проблем.

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