В этой статье мы протестируем Coroot — observability-инструмент с открытым исходным кодом на основе технологии eBPF. Coroot не просто собирает данные телеметрии, но и анализирует их, превращая в полезную информацию, которая помогает быстро выявлять и устранять проблемы с приложениями. Расскажем, как установить и настроить Coroot, что утилита умеет и какие у нее плюсы и минусы. Для обзора мы выбрали бесплатную версию.
Coroot — довольно молодое решение, первый коммит на GitHub датируется 22 августа 2022 года. Разработала утилиту команда, которая ранее создала систему мониторинга инфраструктуры Okmeter (сейчас Okmeter развивает команда «Фланта»). Разработчики Coroot позиционируют свой продукт как комплексную систему сбора телеметрии и мониторинга сбоев.
Установка Coroot
Исходные данные. Установка производится в кластер Kubernetes 1.23 под управлением Kubernetes-платформы Deckhouse.
1 способ установки. В официальном репозитории есть манифест для Kubernetes, установку начнем с него. Манифест создает Namespace, PersistentVolumeClaim, Deployment и Service.
Однако тут нам захотелось посмотреть, как работает сервис извне, без использования PortForward или других хаков. Для этого мы добавили Ingress-ресурс, при этом в Nginx создается конфигурационный файл с внешним DNS-адресом, на который можно перейти и попасть в приложение. Так как в Coroot нет авторизации, мы закрыли ресурс при помощи авторизации в Dex через GitLab.
Как запустить Coroot в отказоустойчивой конфигурации. У сервиса есть переменная PG_CONNECTION_STRING. Если указать ее, сервис начинает хранить свою конфигурацию в PostgreSQL. В этом случае его можно поднять в отказоустойчивой конфигурации. Но на этом пункте мы останавливаться не будем, это уже совсем другая история, выходящая за рамки нашего обзора.
2 способ установки. Можно установить Coroot с помощью родного Helm-чарта.
Вместе с Coroot в этом чарте могут быть установлены все нужные экспортеры, а также система для профилирования кода Pyroscope и ClickHouse для хранения ее данных.
Настройка инструмента
Заходим в веб-интерфейс инструмента. Нам предлагают создать новый проект, указав имя проекта, адрес Prometheus’а и авторизацию.
Важный момент: в наших кластерах под управлением Deckhouse взаимодействие c Prometheus происходит через RBAC-авторизацию. Это сделано для большей безопасности. Поэтому нам пришлось применить небольшой хак в виде Proxy-контейнера Nginx, который через RBAC получает токен для доступа в Prometheus. Из коробки Coroot не сможет авторизоваться в Prometheus через RBAC, так как у него предусмотрена только базовая авторизация.
Если вы устанавливали Coroot из обычного yaml-манифеста, вероятно, у вас не задеплоен coroot-node-agent. Это нужно сделать, агент необходим для работы Coroot, так как именно он собирает метрики с каждой ноды.
Следующим шагом добавляем в деплой DeamonSet с node-agent, настраиваем сбор метрик с подов в наш Prometheus, и в интерфейсе Coroot появляется много интересных вещей. Ниже рассмотрим, какие именно возможности предоставляет инструмент.
Возможности Coroot
Информация о подах
Давайте прежде всего посмотрим на сетевое взаимодействие между подами (у ребят на сайте есть симпатичная наглядная демка, а нам пришлось заблюрить названия, чтобы не светить детали инфраструктуры):
Эта функция будет полезна для команд разработки и поддержки. Глядя на инфографику, даже не погруженный в проект человек сразу может представить схему взаимодействия всех сервисов между собой. Красным подсвечены приложения, которые, по мнению Coroot, имеют какие-то отклонения в работе (например, высокое время ответа).
Из минусов этой фичи отметим, что квадратики нельзя двигать, чтобы придать схеме более читаемую структуру.
Если провалиться в под, можно посмотреть информацию о нем более детально:
Есть метрики по использованию CPU:
Доступны метрики памяти:
Можно посмотреть метрики диска:
В Coroot есть возможность парсить логи и находить похожие сообщения по паттернам:
Фильтрация подов
На дашборде, который формируется по умолчанию, представлены сразу все поды из всех пространств имен. Это не очень удобно, поэтому давайте посмотрим, как их можно отфильтровать.
Это можно сделать в настройках проекта, выбрав категории приложений. Приложения можно разделить по пространствам имен или типам. Есть регулярные выражения (regexp) для шаблонов пространств имен: мы можем указать *review* или *test*.
В нашем примере мы выделили отдельные пространства имен.
Эта функция Coroot очень полезна. Применив такую фильтрацию, мы получим более корректную картинку, где приложения связаны друг с другом в рамках одного пространства имен. Если приложения используют ресурс из другого пространства имен, например, СУБД, — его тоже нужно добавить в категорию.
Минус функции в том, что выбранная категория сбрасывается при переходе в другой раздел.
Мониторинг состояния узлов и уведомления
У Coroot есть интересные функции мониторинга и уведомлений.
Какие уведомления доступны:
Утилиту можно интегрировать со Slack, PagerDuty и Microsoft Teams, и она будет отправлять в них уведомления о деплое.
Можно также настроить алерты о превышении SLO, утилизации CPU или недоступности Redis.
Для каждого ресурса (Deployment’а или StatefulSet’а) можно переопределить метрику для расчета SLO и его целевое значение.
Мы протестировали работу уведомлений через Slack. Для этого в Workspace добавляется приложение Coroot, в интерфейсе самого Coroot указывается Oauth Token и открытый канал для уведомлений:
Алерты отправляются оперативно, без задержек.
Давайте теперь посмотрим, как реализован мониторинг узлов. Откроем вкладку Nodes:
В ней очень наглядно показано состояние узла, на котором запущен агент, и легко можно увидеть недозагруженные или перегруженные узлы.
Если мы нажмем на имя узла, откроется небольшой дашборд с основными метриками системы в более детализированном представлении:
В целом, это минимально необходимый набор полезных метрик, которые могут помочь в диагностировании проблемы. Хотя, конечно, хотелось бы видеть и более подробные сетевые метрики, например количество открытых портов или сетевых ошибок. Были бы полезны и метрики по состоянию диска (но можно для этой задачи использовать и Okmeter).
Относительно недавно в Coroot появилась отличная новая функциональность — Cloud cost monitoring.
Она позволяет легко оценить стоимость и утилизацию узлов в облачных провайдерах (AWS, GCP, Azure). Это безопасная и полезная фича, потому что Coroot определяет тип узла без доступа к консоли.
В завершение отметим, что Coroot поддерживает Pyroscope, систему для профайлинга приложений и визуализации процессорного времени в виде flame graphs. Графы можно визуализировать в его интерфейсе.
Плюсы и минусы инструмента
Coroot оказался достаточно удобным инструментом, у которого много преимуществ:
Есть понятная и визуально наглядная схема взаимодействия сервисов, можно посмотреть состояние и метрики по каждому поду.
Можно настроить фильтрацию подов и получить картинку, какие приложения связаны в рамках одного пространства имен.
Есть удобные функции для мониторинга узлов и настройки уведомлений.
Есть поддержка Pyroscope и возможность представить его графы в интерфейсе Coroot.
Но в ходе обзора нам пришлось и столкнуться с некоторыми трудностями:
Нет возможности исключить поды из наблюдения, а иногда это бывает нужно. Например, когда в проекте поды часто запускаются и выключаются через cron-job, вы не планируете следить за их метриками и складывать в Prometheus. Частично эту проблему можно было бы решить через фильтр на самом агенте, но, как оказалось, в нем нельзя настроить исключения для отдельных ресурсов (Deployment, StatefulSet, NameSpace).
UI достаточно простой, и у него, безусловно, есть зоны роста. Но так как проект активно развивается, вероятно, в будущем интерфейс будет улучшен. А возможно, как и его конкурент Caretta, Coroot начнет использовать Grafana в качестве интерфейса отображения метрик.
Альтернативы Coroot
Caretta: проект использует схожую систему сбора метрик с использованием eBPF и «интерфейс» в виде дашбордов в Grafana. Однако утилита почти не развивается, а дашборд работает довольно плохо: информация на нем может отображаться с ошибками, создавать высокую нагрузку на браузер и в целом не оптимизирована.
Suricata — это не совсем проект мониторинга SLO/SLA, однако функциональность схожа. Агенты проверяют трафик, строят по нему метрики и также могут вывести графики взаимодействия между сервисами. Система довольно сложная, потому что для работы Suricata требуется ELK-стек и импорт в Kibana большого числа сторонних объектов для отображения графиков.
Некоторое время назад, еще до появления Coroot, мы написали собственный инструмент для решения аналогичных задач — iptnetflow-exporter. Подробно рассказали о нем в статье. Это приложение на Go + Python, которое при помощи ServiceAccount получает данные из Prometheus и отдает их в формате, требуемом для Nodegraph. Визуализацию реализовали через дашборд в Grafana, карту взаимодействия сервисов — с применением плагина
hamedkarbasi93-nodegraphapi-datasource.
Что в итоге
Coroot выглядит очень полезной утилитой для просто настраиваемого и при этом достаточно глубокого мониторинга приложений и инфраструктуры. Он может быть полезен небольшим компаниям и командам, которым не нужны сложные системы и важно быстро настроить мониторинг с SLO, уведомлениями и трейсингом запросов.
P.S.
Читайте также в нашем блоге: