Оптимизация DevOps: Как персональные стенды и Grafana улучшают разработку и мониторинг
Всем привет, меня зовут Зуев Алексей, и я работаю 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-дашборде. Для начала разберем основные элементы дашборда.
Он состоит из базовых сущностей, таких как переменные:
Переменные Grafana-дашборда
Они помогают централизованно формировать запросы и одновременно изменять панели на всем дашборде.
Меню varibles в Grafana-UI
Список переменных:
datasource — то, откуда мы будем собирать метрики и логи.
namespace — обозначающая имя персонального стенда.
container error — отображающая проблемные поды в неймспейсе.
ingress — связанные с ингрессом выбранного стенда, для сбора статистики по ошибкам и задержкам до фронта.
Сам дашборд разделен на пять основных глав:
Основные поля дашборда
Состояние здоровья подов в неймспейсе
Эта панель отображает состояние всех микросервисов на стенде, используя метрику aspnetcore_healthcheck_status.
Статус панель с Healthcheck
Панель на дашборде формирует ссылку на персональный стенд:
Почти на каждой панели дашборда, мы даем дополнительную информацию/ссылку/документацию
Разработчик может перейти по этой ссылке и оценить состояние стенда в онлайн формате.
Каждый микросервис отдает метрику aspnetcore_healthcheck_status по которой мы определяем, в порядке наш микросервис или нет:
Пороги сробатывания
Основное окружение неймспейса
Панель собирает информацию об основном окружении стенда, включая количество деплойментов, стейтфулсетов и общее количество подов. Отображает ошибки фронта и среднюю задержку ответа.
Далее собираем таблицу с общей информацией:
под;
время жизни;
ip-адрес;
количество рестартов;
нода, на которую под распределил Kubernetes.
Первый столбец pod и последний столбец node имеют вложенные ссылки на другие дашборды. Это позволяет нам собирать в одном месте интересующие нас дашборды и при необходимости переходить на них и отсматривать информацию по интересующим нас поду или ноде. Особенно это необходимо, если есть подозрения, что проблема в инфраструктурной части, и дашборд с определенной нодой даст понимание проблемы.
Ниже привожу пример по формирования ссылки на дашборд с нужными параметрами, при переходе по ней формируются необходимые панельки по интересующей нас ноде.
Сформированная ссылка на дашборд:
Сформированная ссылка на вложенный дашборд
Готовый дашборд и информация по метрикам проблемной ноды:
После таблицы со всеми подами персонального стенда формируем табличку с ошибочными подами. Тут можем наблюдать присутствие ссылок на другие дашборды внутри таблицы. В столбце reason, отсылаем пользователя на общую статью в Confluence. Статья содержит основные причины возникновения тех или иных ошибок и способы их решения. В перспективе доработаем ссылочку прямо по главам, чтобы поиск производился точно по названию ошибки. Это позволит пользователю не тратить время на долгий поиск и найти определенную причину ошибки по предлагаемой ссылке, а далее пробовать решить ее самостоятельно.
Ссылки на документацию по частым ошибкам и их решению
Сервисы в неймспейсе
Следующая глава дашборда — это сущности сервисов и ингрессов внутри персонального стенда. Она полезна для анализа состояния стенда или проведения тестирования.
Как и в предыдущей главе, тут собрана табличка с информацией по ингрессам и сервисам. И столбец service-name позволяет нам отправить пользователя на дополнительный дашборд с более детальной информацией по каждому ингрессу в его персональном стенде.
Конфигурации и хранилища неймспейса
Дашборд содержит информацию о конфигмапах, секретах и проблемных PVC внутри персонального стенда.
Логи с ошибками контейнера
Здесь отображаются логи с ошибками проблемных подов. Разработчик может группировать логи и метрики по контейнеру и неймспейсу.
variables container_error
И дальше мы видим последние сто строк ошибочного контейнера. Переключение между проблемными контейнерами в подах производится с помощью variables container_error.
Таким образом, мы предоставляем разработчикам инструменты для самостоятельного анализа и решения проблем на их персональных стендах.
Теперь рассмотрим процесс создания дашборда и определенные моменты, которые можно использовать в своей практике. Первое, что я считаю наиболее удобным, — это формирование ссылок на дополнительные дашборды, которые помогут пользователю более глубоко проанализировать первопричину ошибки.
Формирование ссылки на вложенный дашборд
Для удобства полезно выставить переключатель «Open in new tab» при переходе по ссылке:
Для примера рассмотрим формирование ссылки на ноду/хост, где возникла ошибка при развертывании пода. Начнем с создания сводной таблицы по набору метрик и использования параметра Transform для логического распределения и формирования правильной таблицы. Затем определим основные полезные поля таблицы, прежде чем перейти к формированию ссылок на дашборд.
Пример настройки параметра Transform:
вкладка Transform
Пример таблицы подов в неймспейсе main:
В таблице мы видим название ноды, на которой был развернут под. Для лучшего понимания происходящего в момент развертывания пода или его работы мы направляем пользователя на дашборд с метриками от сервиса Node-Exporter. Перекрестную ссылку можно создать, используя параметр »$__value.raw», что позволяет подготовить нужный дашборд с необходимой нодой и временным периодом.
В разобранном примере с той же нодой мы можем также предоставить пользователю возможность погружения еще глубже в другой дашборд с более подробными метриками. Конечно, чаще всего, если пользователь понял, что проблема связана с инфраструктурой, он передает ссылку инженеру/DevOps для более детального анализа. Однако сам факт использования вложенности помогает пользователю понимать, что происходит с его стендом, и на какие ошибки и проблемы следует обратить внимание.
Конечно, хочется также отметить и проблему использования таких дашбордов. Потому что чаще всего то, что может быть понятно и логично для DevOps-инженера, не всегда может быть понятно для разработчика. И при создании любого дашборда необходимо придерживаться цели максимально упростить понимание проблем и их первопричин. Дополнительные вложенности позволяют глубже разбираться при дальнейшем освоении и понимании, но первоначально необходимо подсвечивать базовые понятия, которыми легче оперировать.
Ну и, конечно же, нельзя не поговорить про баги в дашборде. Если панель в дашборде отображает что-то неверно, вносятся исправления через UI, и бекапом собираем JSON из Grafana. Настройки и конфигурации дашбордов хранятся в Git-репозитории, что обеспечивает единый и управляемый способ хранения изменений. В будущем планируем расширить процесс изменений дашбордов через Git-репозиторий и CI/CD. Это включает в себя возможность внесения изменений через репозиторий, автоматизированные пайплайны и интеграцию с системой управления конфигурациями.
Заключение
И в заключение отмечу, что в современной разработке, где скорость и надежность играют ключевую роль, эффективный мониторинг становится неотъемлемой частью процесса. В своей статье я хотел немного пролить свет на важность системного подхода к мониторингу, особенно когда речь идет о персональных стендах разработчиков.
Основываясь на рассмотренных моментах, становится очевидным, что создание дашбордов для персональных стендов — это не просто инструмент для отслеживания состояния микросервисов, но и эффективный способ дать разработчикам полный контроль над своим окружением. Важность этого подхода в том, что разработчики могут не только отслеживать, но и реагировать на проблемы на своих стендах, повышая тем самым скорость выявления и устранения неполадок. В дополнение к текущим достижениям мы планируем реализовать следующие улучшения:
Расширить возможности изменения дашбордов через Git-репозиторий и CI/CD, что обеспечит более прозрачное и автоматизированное управление конфигурациями.
Продолжить расширять дашборды с использованием дополнительных метрик, чтобы дать разработчикам еще больше данных для глубокого анализа.
Создание структурированных дашбордов с основными компонентами, такими как состояние здоровья подов, информация об окружении стенда, анализ сущностей сервисов и ингрессов, позволяет разработчикам получать комплексное представление о работе и состоянии их стенда в реальном времени.
Особо стоит выделить применение вложенных ссылок на дополнительные дашборды, что открывает двери для более глубокого анализа проблем. Этот метод позволяет не только быстро выявить первопричину ошибки, но и предоставляет пользователям инструменты для самостоятельного решения возникающих проблем.
Таким образом, эффективный мониторинг через персональные стенды и их дашборды не только улучшают процесс разработки, но и предоставляют разработчикам возможность брать полный контроль над своим творческим пространством. Это необходимый элемент для достижения высокой производительности и качества программного обеспечения в условиях быстро меняющегося IT-мира.
