Обзор Coroot — Open Source-утилиты для наблюдаемости: установка, настройка, возможности, плюсы и минусы

В этой статье мы протестируем Coroot ^[1] — observability-инструмент с открытым исходным кодом на основе технологии eBPF. Coroot не просто собирает данные телеметрии, но и анализирует их, превращая в полезную информацию, которая помогает быстро выявлять и устранять проблемы с приложениями. Расскажем, как установить и настроить Coroot, что утилита умеет и какие у нее плюсы и минусы. Для обзора мы выбрали бесплатную версию.

Coroot — довольно молодое решение, первый коммит на GitHub датируется 22 августа 2022 года. Разработала утилиту команда, которая ранее создала систему мониторинга инфраструктуры Okmeter ^[2] (сейчас Okmeter развивает команда «Фланта»). Разработчики Coroot позиционируют свой продукт как комплексную систему сбора телеметрии и мониторинга сбоев.

Установка Coroot

Исходные данные. Установка производится в кластер Kubernetes 1.23 под управлением Kubernetes-платформы Deckhouse ^[3]. 

1 способ установки. В официальном репозитории есть манифест для Kubernetes ^[4], установку начнем с него. Манифест создает Namespace, PersistentVolumeClaim, Deployment и Service. 

Однако тут нам захотелось посмотреть, как работает сервис извне, без использования PortForward или других хаков. Для этого мы добавили Ingress-ресурс, при этом в Nginx создается конфигурационный файл с внешним DNS-адресом, на который можно перейти и попасть в приложение. Так как в Coroot нет авторизации, мы закрыли ресурс при помощи авторизации в Dex через GitLab. 

Как запустить Coroot в отказоустойчивой конфигурации. У сервиса есть переменная PG_CONNECTION_STRING. Если указать ее, сервис начинает хранить свою конфигурацию в PostgreSQL. В этом случае его можно поднять в отказоустойчивой конфигурации. Но на этом пункте мы останавливаться не будем, это уже совсем другая история, выходящая за рамки нашего обзора. 

2 способ установки. Можно установить Coroot с помощью родного Helm-чарта ^[5].

Вместе с 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

Информация о подах

Давайте прежде всего посмотрим на сетевое взаимодействие между подами (у ребят на сайте есть симпатичная наглядная демка ^[6], а нам пришлось заблюрить названия, чтобы не светить детали инфраструктуры):

Эта функция будет полезна для команд разработки и поддержки. Глядя на инфографику, даже не погруженный в проект человек сразу может представить схему взаимодействия всех сервисов между собой. Красным подсвечены приложения, которые, по мнению 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 ^[2]). 

Относительно недавно в Coroot появилась отличная новая функциональность — Cloud cost monitoring. 

Она позволяет легко оценить стоимость и утилизацию узлов в облачных провайдерах (AWS, GCP, Azure). Это безопасная и полезная фича, потому что Coroot определяет тип узла без доступа к консоли.

В завершение отметим, что Coroot поддерживает Pyroscope, систему для профайлинга приложений и визуализации процессорного времени в виде flame graphs. Графы можно визуализировать в его интерфейсе. 

Плюсы и минусы инструмента

Coroot оказался достаточно удобным инструментом, у которого много преимуществ:

• Есть понятная и визуально наглядная схема взаимодействия сервисов, можно посмотреть состояние и метрики по каждому поду. 

• Можно настроить фильтрацию подов и получить картинку, какие приложения связаны в рамках одного пространства имен. 

• Есть удобные функции для мониторинга узлов и настройки уведомлений. 

• Есть поддержка Pyroscope и возможность представить его графы в интерфейсе Coroot.

Но в ходе обзора нам пришлось и столкнуться с некоторыми трудностями:

• Нет возможности исключить поды из наблюдения, а иногда это бывает нужно. Например, когда в проекте поды часто запускаются и выключаются через cron-job, вы не планируете следить за их метриками и складывать в Prometheus. Частично эту проблему можно было бы решить через фильтр на самом агенте, но, как оказалось, в нем нельзя настроить исключения для отдельных ресурсов (Deployment, StatefulSet, NameSpace). 

• UI достаточно простой, и у него, безусловно, есть зоны роста. Но так как проект активно развивается, вероятно, в будущем интерфейс будет улучшен. А возможно, как и его конкурент Caretta ^[7], Coroot начнет использовать Grafana в качестве интерфейса отображения метрик. 

Альтернативы Coroot 

• Caretta ^[7]: проект использует схожую систему сбора метрик с использованием eBPF и «интерфейс» в виде дашбордов в Grafana. Однако утилита почти не развивается, а дашборд работает довольно плохо: информация на нем может отображаться с ошибками, создавать высокую нагрузку на браузер и в целом не оптимизирована. 

• Suricata ^[8] — это не совсем проект мониторинга SLO/SLA, однако функциональность схожа. Агенты проверяют трафик, строят по нему метрики и также могут вывести графики взаимодействия между сервисами. Система довольно сложная, потому что для работы Suricata требуется ELK-стек и импорт в Kibana большого числа сторонних объектов для отображения графиков.

• Некоторое время назад, еще до появления Coroot, мы написали собственный инструмент для решения аналогичных задач — iptnetflow-exporter. Подробно рассказали о нем в статье ^[9]. Это приложение на Go + Python, которое при помощи ServiceAccount получает данные из Prometheus и отдает их в формате, требуемом для Nodegraph. Визуализацию реализовали через дашборд ^[10] в Grafana, карту взаимодействия сервисов ^[10] — с применением плагина hamedkarbasi93-nodegraphapi-datasource. 

Что в итоге

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

P.S.

Читайте также в нашем блоге:

• «Мимо тещиного дома я без метрик не хожу» ^[11]

• «Обзор утилиты Weave Scope для мониторинга и отладки контейнеризированных приложений» ^[12]

• «Мониторинг межсервисного взаимодействия Kubernetes с помощью протокола NetFlow» ^[9]