Привет, Хабр! Я много лет работаю в системной интеграции и занимаюсь внедрением различных проектов в области ИТ и ИБ. Меня попросили написать технический обзор MWS Container Platform, так что ловите то, что получилось. В этом материале подробно поговорим о стеке наблюдаемости (observability) и рассмотрим несколько практических кейсов по обнаружению проблем средствами стека.
Знакомство с платформой
Прежде чем начать рассказ о платформе и реализации стека наблюдаемости, хочу сказать, для кого предназначено это решение. Конечно, MWS Container Platform будет полезна администраторам и инженерам DevOps (Development & Operations — разработка и эксплуатация/поддержка), разворачивающим и обслуживающим приложения. Но использование платформы может также существенно упростить жизнь разработчикам, так как решение позволяет развернуть множество полезных инструментов буквально из коробки, без необходимости дополнительных действий по установке и настройке. О некоторых из этих инструментов поговорим ниже. Сначала рассмотрим работу с платформой и мониторинг с точки зрения администратора, а затем разберем несколько практических кейсов наблюдаемости для разработчиков.
Взаимодействие с компонентами платформы может осуществляться через веб-интерфейс, CLI (Command Line Interface, интерфейс командной строки) и API (Application Programming Interface, программный интерфейс приложения). Об веб-интерфейсе и поговорим. В разделе Administrator находятся все основные компоненты управления кластером. Здесь в Overview можем наблюдать утилизацию процессора, памяти, загруженность отдельных нод в кластере и другую полезную информацию.
В разделе Administrator можем видеть различные вкладки, предназначенные для управления компонентами кластером, сетью, хранилищем, пользователями. Здесь для нас особый интерес представляет вкладка Operations Center, так как именно в ней сосредоточены основные инструменты необходимые для мониторинга.
Вкладка Monitor встречает нас красочными дашбордами, отражающими информацию о текущем состоянии компонентов всего кластера. Здесь мы видим состояние API сервера, экземпляров базы ETCD, количество рабочих нод в кластере, пространства имен, поды и состояние других компонентов.
Примечательно, что все эти дашборды и графики доступны уже из коробки и администратору не требуются дополнительные действия для их развертывания. Еще одно полезное преимущество: эти инструменты мониторинга доступны и для разработчиков, которые могут без лишних затрат мониторить работу приложений в кластере.
Здесь важно отметить, что помимо представленных дашбордов администратор при необходимости может создать и собственные с помощью инструментов веб-интерфейса или импортировать уже готовые в формате JSON. В качестве бэкэнда для хранения и обработки метрик может использоваться Prometheus или VictoriaMetrics.
Помимо непосредственно функционала мониторинга, здесь можно настроить пробы для проверки работоспособности того или иного ресурса в кластере. Возможна ситуация, когда контейнер вроде бы работает нормально, никаких ошибок не выдает, а приложение в нем не работоспособно. Для выявления таких ситуаций применяется механизм пробников. Пробники могут использовать ICMP, TCP или HTTP для проверки доступности, обращаясь к целевому узлу через заданный интервал времени.
В случае отсутствия отклика система создает соответствующее уведомление либо выполняет команду или скрипт, который мы указываем в соответствующих настройках.
Дашборды и пробники позволяют наблюдать за состоянием компонентов кластера и приложений в контейнерах в режиме реального времени, но мы можем уведомлять администраторов о происходящем в системе. Так, платформа предлагает уже готовый набор уведомлений реального времени, которые срабатывают в соответствии с заданными правилами.
Например, на рисунке ниже представлен алерт, срабатывающий на основе указанных условий. Также можно указать пороговые значения для срабатывания правила — например, превышение загрузки CPU или памяти.
Однако алерт в случае срабатывания должен уведомлять всех заинтересованных лиц о произошедшем сбое. Для этого у нас есть вкладка Notifications, в которой можно указать пользователей или группы, которые должны получить уведомление, а также метод получения сообщений.
Как видно, в состав Operations Center входят основные инструменты, предназначенные для ведения мониторинга состояния как компонентов всего кластера, так и отдельных приложений в контейнерах. Но что делать в случае, если инцидент уже произошел и нам необходимо разобраться, почему произошел сбой?
Здесь на помощь приходят журналы событий и инструменты для поиска нужных событий в логах. Во вкладке Events можем наблюдать, какие события произошли в кластере за заданный промежуток времени.
Во вкладке представлена статистика по наиболее критичным событиям, таким как Out Of Memory или рестарт для нод и подов. При нажатии на соответствующее поле получаем фильтрацию событий.
Конечно, когда не слишком много событий, с ними можно работать вручную, но, как правило, в продуктивной среде у нас множество нод с большим количеством подов, и для поиска нужных событий необходимо использовать фильтры.
Мы можем выбрать тип журнала — системный, приложений, Kubernetes — и отфильтровать события как по имени ноды, пода или приложения, так и по содержимому самого сообщения о событии.
Таким образом, администратор может находить нужные события от различных компонентов кластера. Также можно настроить политику сохранения логов, указав, в течение какого времени события должны сохраняться в системе. Это позволит избежать переполнения журналов.
Еще один интересный элемент Operation Center — это возможность проведения самотестирования (System Self Test) состояния всего кластера, а также его подов. Эти тесты можно проводить по расписанию, отправляя уведомления о результатах на электронную почту.
В состав тестов входит проверка валидности используемых в кластере сертификатов, состояние загрузки различных компонентов кластера (здесь часть проверок пересекается с теми, что уже есть в алертах), состояние нод и непосредственно подов.
В разделе Inspection Configuration администратор может активировать отдельные проверки, а также настраивать расписание Cron для выполнения этих проверок.
По результатам проверки составляется отчет, который содержит информацию о сработавших правилах. Этот отчет тоже можно выгрузить в виде файла, содержащего подробные описания каждой из обнаруженных проблем.
Итак, мы рассмотрели те возможности, которые нам предлагает Operations Center. Как видно, это достаточно мощный инструмент, предоставляющий расширенные функции мониторинга состояния кластера и приложений. Однако этот инструмент обычно используют только администраторы для контроля состояния всего кластера, но в Container Platform мониторинг присутствует практически везде, и далее мы поговорим о том, какие инструменты доступны разработчикам.
Мониторинг для разработчика
Прежде чем приступить к рассмотрению тех функций мониторинга, которые доступны разработчикам, необходимо сделать небольшое отступление и рассказать об архитектуре платформы.
В платформе у каждого пользователя есть свой проект или группа проектов, в которых он и размещает свои поды с приложениями. Они неуникальны для конкретного пользователя. Группа пользователей может работать в одном или нескольких проектах. И здесь важно то, что Container Platform предлагает пользователю в рамках проекта свои метрики, которые относятся только к этому проекту и сущностям внутри него без каких-либо ограничений. Такой подход позволяет пользователям вести мониторинг своих проектов без необходимости запрашивать какие-то необходимые данные у администратора кластера.
Также стоит отметить, что мониторинг в проектах доступен из коробки и для него фактически не требуется SRE-инженер, так как базовая функциональность становится доступной сразу после создания проекта.
В целом же в Container Platform мониторинг пронизывает всю систему. То есть помимо Operations Center инструменты мониторинга можно встретить в различных разделах, некоторые из которых рассмотрим далее.
Через веб-интерфейс Container Platfrom разработчик может работать в рамках выделенного проекта — например, создавать и изменять ресурсы Kubernetes с использованием YAML-манифестов, управлять настройками и мониторить приложения.
Для нас в рамках данной статьи наибольший интерес представляет раздел Observe. В нем разработчику также доступны дашборды по его приложениям. В частности, здесь мы видим статусы подов, загрузку CPU, наличие алертов и так далее. Напомню, что все это доступно из коробки и не требует дополнительных настроек.
Вкладки Logging и Events аналогичны тем, что имеются в Operations Center. В них тоже можно просматривать события и находить нужные сообщения с помощью фильтров.
Также разработчику доступны алерты, то есть он может самостоятельно настроить правила для их срабатывания.
В целом Observe для разработчиков содержит базовый набор функций, позволяющий осуществлять эффективный мониторинг своих проектов. Далее рассмотрим несколько практических примеров того, как инструменты мониторинга могут помочь разработчику в решении возникающих проблем.
Смотрим на практике
Итак, мы видим следующую картину:
Для начала посмотрим текущее состояние нормально работающего пода mypython. Здесь во вкладке Pods можем наблюдать общий статус, а также графики загрузки процессора и оперативной памяти.
Кроме того, во вкладке Real-time Logs можно посмотреть события, связанные с данным подом.
Но вернемся во вкладку Applications и посмотрим на другие поды. У некоторых из них статус Failed или No Workloads found. Очевидно, что ничего хорошего это не сулит. Давайте, например, узнаем, что не так с pv-pod.
Для этого достаточно во вкладке Events обратить внимание на раздел Pod Scheduling Failed. В нем есть одно событие, по нажатию на которое выдается его описание:
Как видно, отсутствует запрос Persistent volume claim, без которого данный под не запускается. Помимо использования вкладки Pod Scheduled Failed нужное событие можно попробовать поискать с помощью фильтра, указав Resource Type — Pod и в поле Resources — имя данного пода.
Посмотрим еще один пример. Развертывание deployment выполняется слишком долго:
Причину этого можно тоже довольно просто найти в разделе Events -> Failed to start Pods:
Как видим, наше развертывание, создающее несколько экземпляров пода nginx, уперлось в ограничения по памяти для данного пространства имен, поэтому деплоймент не может завершить свою работу и создать необходимое число экземпляров пода.
В заключении — мои впечатления о тех возможностях, которые предоставляют инструменты мониторинга для администраторов и разработчиков.
Прежде всего стоит отметить возможность начать мониторинг работы приложений прямо из коробки. Разработчику не потребуется тратить время на развертывание и настройку необходимых компонентов. Не нужна и помощь SRE-инженера, так как все базовые функции мониторинга уже активированы. Достаточно подробные дашборды позволяют разработчикам в наглядном виде получить информацию о текущем состоянии объектов Kubernetes. В результате мы можем увидеть проблемы с памятью или потреблением процессорных ресурсов непосредственно на графиках. При необходимости дашборды можно модифицировать для отображ��ния интересующей информации.
Отдельно хотелось бы обратить внимание на мультитенантность мониторинга, то есть на возможность вести мониторинг в рамках своего проекта. В Container Platform для этого не требуются какие-либо дополнительные разрешения и доступы. Здесь это тоже доступно из коробки без дополнительных настроек.
В целом MWS Container Platform предлагает готовый набор функционала для своевременного выявления узких мест и проблем с производительностью, что делает более удобной и эффективной работу с контейнеризированными приложениями.
