Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков. Персональный стенд в понимании нашей компании - это отдельно выделенный под разработчика неймспейс в кластере Kubernetes. У себя мы их называем ksb - “kubernetes-sandbox” и дальше дописываем, кому он принадлежит, пример наименования такого стенда: ksb-ivan-ivanov. Такое распределение позволяет легко идентифицировать принадлежность стенда, и исходя из этого формируется dns имя для фронта продукта.
Обязательно хочу подсветить предпосылки, которые послужили триггером для появления такого дашборда:
С увеличением числа микросервисов и их взаимодействия возникла необходимость в более глубоком отслеживании производительности и выявлении потенциальных проблем.
Нагрузка на инфраструктуру стала критичной, требуя более эффективных средств мониторинга и отладки для поддержания стабильности и высокой производительности.
Жалобы разработчиков на сложности в решении инцидентов подчеркнули актуальность внедрения более эффективных средств отладки.
Использование Grafana для создания дашбордов, объединяющих метрики и логи, обеспечивает интуитивно понятное представление состояния персональных стендов, снижая время реакции на проблемы.
Но сначала я бы хотел поделиться тем, какими инструментами мы пользуемся для сбора метрик и логов. Метрики собираются с помощью kube-prometheus-stack-42.1.0, а логи собираем при помощи promtail и храним их в Loki, используя loki-stack-2.9.1. Дашборды отображаем в Grafana 8.4.1. Разработка микросервисов осуществляется на платформе .NET версии 7.0. Фреймворк ASP.NET используется для построения веб-приложений. Для подразделения разработки у нас выделен отдельный K8S кластер, в котором, в теории на каждого разработчика, мы можем выделять два персональных неймспейса, которые в дальнейшем я буду называть персональными стендами. Интеграция kube-prometheus-stack обеспечивает полный мониторинг состояния кластера Kubernetes и микросервисов в реальном времени.
Какова была основная цель создания общего дашборда для персональных стендов разработчиков? Необходимо понимать два момента, как это работает у нас в компании:
Первый момент: после каждого билда разработчик имеет право запустить деплой на свой персональный стенд.
Второй момент: хотелось бы, чтобы разработчик сам мог решить проблему в случае, если деплоймент упал по той или иной причине.
Мы стараемся выводить дополнительную информацию о различных ошибках в лог gitlab-pipeline. Это могут быть логи из проблемных подов, ошибки линтера helm-template своего микросервиса и прочее. После деплоя разработчик получает ссылку на свой Grafana-дэшборд, с помощью которого может оценить состояние своего стенда на момент разворачивания и, возможно, самостоятельно исправить возникшие проблемы. Дашборд предоставляет алгоритмы и базу знаний для типовых проблем, которые разработчики могут решить самостоятельно. Например, проблемы с конфигурацией, зависимостями или неисправностями в коде. В случае более сложных проблем, которые разработчики не могут решить самостоятельно, существует установленный флоу, описанный в предыдущей статье о правиле 30 минут. По прошествии этого времени вопрос автоматически переходит к команде DevOps.
Далее речь пойдет о Grafana-дашборде. Для начала разберем основные элементы дашборда.
Он состоит из базовых сущностей, таких как переменные:
Они помогают централизованно формировать запросы и одновременно изменять панели на всем дашборде.
Список переменных:
datasource — то, откуда мы будем собирать метрики и логи.
namespace — обозначающая имя персонального стенда.
container error — отображающая проблемные поды в неймспейсе.
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-мира.
