Мониторинг и наблюдаемость
Термины «мониторинг» и «наблюдаемость» в последнее время часто используются в запутанных взаимозаменяемых контекстах. Они тесно связаны, но по существу подходят к проблемам с разных сторон.
Короче говоря, мониторинг — это акт сбора данных, а наблюдаемость — это свойство (и мера https://en.wikipedia.org/wiki/Observability) системы, которая позволяет нам делать выводы о внутреннем состоянии исключительно на основе внешний вывод. Можно сказать, что мониторинг обеспечивает наблюдаемость, а мониторинг без наблюдаемости имеет ограниченное применение.
Но зачем вообще нужны мониторинг и наблюдаемость? Распределенные системы, которые мы создаем, с каждым днем становятся все более сложными. И даже без распределенного аспекта — мы используем все более и более высокие уровни абстракций, часто не понимая, как они взаимодействуют с более низкими уровнями — вплоть до ОС и оборудования. В то же время эти системы берут на себя все больше и больше обязанностей, и иногда нам приходится полностью полагаться на них. В таких обстоятельствах сбои могут быть очень дорогостоящими или даже катастрофическими, поэтому приоритетной задачей является возможность быстро определить любую проблему по мере ее возникновения. Какой микросервис вышел из строя? В каком состоянии он находился в момент аварии? Это проблема с памятью или ошибка приложения? Где именно оно находилось? Нам нужны все эти ответы, чтобы смягчить проблему и убедиться, что она не повторится. В противном случае все, что мы можем сделать, это угадать или дать известный ответ: «Вы пробовали выключить и снова включить».
Некоторые другие ценные варианты использования для мониторинга включают в себя:
- Наблюдение за тревожным поведением системы и прогнозирование сбоя до того, как он произойдет (например, у машины не хватает памяти, отставание в теме кафки и т. д.)
- Выявление ошибок в программном обеспечении
- Выявление тенденций более низкого использования ресурсов и соответствующее масштабирование, чтобы иметь возможность эффективно сокращать расходы.
- Выявление узких мест
Три столпа мониторинга
В большинстве случаев данные телеметрии можно разделить на следующие категории:
Следы
Трассировки позволяют нам отслеживать и измерять ход выполнения одного действия. По мере прохождения действия (или запроса) через систему отдельные единицы работы (называемые промежутками) объединяются в древовидную структуру. Визуализация трассировок позволяет нам быстро определить, где чаще всего происходило действие и в каком порядке вызывались определенные компоненты.
Последовательность может выглядеть примерно так:
Как видите, мы можем определить, сколько времени в целом занял запрос, что вызов базы данных был самой длинной частью, если поиск в кэше был удачным или неудачным, и какие конкретные проверки выполнялись параллельно.
Хотя в целом это очень полезно, хранить и анализировать каждую трассировку запроса нецелесообразно. На практике сохраняются только некоторые части трасс. Этот процесс также позволяет нам отслеживать выбросы — запросы, которые нанесли ущерб приложению. Это также отличное место для начала анализа, когда что-то пойдет не так, хотя есть и лучшие способы измерения общей производительности приложения.
Метрики
Метрики — это тип данных телеметрии, которые отслеживают необработанные измерения. Это может быть сводка, такая как использование ЦП, текущая задержка Kafka, процентили HTTP-ответов или общие суммы, такие как количество полученных байтов или общее время ответа. Последнее открывает путь к расчету ставок на наблюдаемость бэкэнд-сервисов. Метрики гораздо больше подходят для мониторинга общей производительности приложения и обычно являются первым индикатором проблем с производительностью. Однако предостережение — важно знать, что означают конкретные показатели и единицы измерения — разные агрегации могут выполняться для разных типов показателей, и несоблюдение правил здесь может привести к бессмысленным значениям.
Журналы
Журналы представляют собой независимые события на протяжении всего жизненного цикла приложения. Это наиболее детализированный тип данных телеметрии, однако очень сложно что-то сказать о производительности приложения, глядя только на журналы. Существуют инструменты, которые позволяют создавать информационные панели из файлов журналов, которые вносят большую ясность, но они очень хрупкие, и любое изменение в формате журнала может полностью его сломать.
Введение в OpenTelemetry
Краткая история
OpenTelemetry берет свое начало в двух конкурирующих проектах — OpenTracing и OpenCensus. Оба были нацелены на создание независимого от поставщика набора инструментов и API, и оба сделали свои собственные архитектурные решения и компромиссы.
В конце концов, два проекта решили объединиться, и появилась OpenTelemetry (https://medium.com/opentracing/a-roadmap-to-convergence-b074e5815289). На момент написания этот проект является проектом песочницы Cloud Native Computing Foundation и поддерживается всеми основными поставщиками и сообществами, связанными с наблюдаемостью.
Архитектура
OpenTelemetry основан на простом потоке, взятом из других решений, но делает его более мощным, делая его независимым от поставщика.
- Приложение инструментируется или автоматически инструментируется некоторыми библиотеками в зависимости от того, какой язык/платформу вы используете или какую библиотеку.
- Данные передаются сборщику.
- Коллектор осуществляет фильтрацию и отбор проб.
- Сборщик отправляет данные на какой-либо наблюдательный сервер (или запрашивается сервером, как в случае с Prometheus).
В случае более сложных инфраструктур с несколькими отслеживаемыми компонентами, например, микросервисов, рекомендуется использовать сборщик для каждого компонента (в качестве вспомогательного компонента) и дополнительный сборщик-агрегатор/шлюз.
Коллекционеры
Как видите, инфраструктура OpenTelemetry построена вокруг сборщиков, которые отвечают за получение данных телеметрии, выполнение некоторой обработки данных (или нет) и экспорт данных в серверную часть.
Сборщики OpenTelemetry поддерживают множество поставщиков как на принимающей, так и на экспортирующей стороне. Они также поддерживают сбор данных с нескольких входов и одновременный экспорт на несколько выходов. Это очень удобно при внедрении OpenTelemetry в существующую инфраструктуру телеметрии и миграции между поставщиками.
API и SDK
API OpenTelemetry определяет набор интерфейсов, которые можно использовать для инструментовки отслеживаемого приложения, а также версии реализации noop. С другой стороны, SDK предоставляет конкретную реализацию API с дополнительными средствами для настройки и запуска механизма OpenTelemetry.
С точки зрения разработчика приложений это означает, что вы будете использовать API для создания счетчиков, диапазонов и т. д., поскольку они представляют сквозные задачи мониторинга. Затем вы будете использовать SDK для создания экспортера и других компонентов мониторинга среды выполнения, возможно, где-то в точке входа в ваше приложение.
Для разработчиков библиотек (как в случае с Mesmer) разделение API и SDK означает, что библиотека должна зависеть исключительно от API.
Месмер
Что такое агент Scalac Mesmer Akka
Mesmer — это автоинструментальная библиотека OpenTelemetry для приложений Akka. Он начинался как проект для одного из клиентов Scalac, а теперь исходный код находится в открытом доступе.
Он состоит из двух частей: агента Java, который необходим Mesmer для инструментирования байт-кода, и расширения Akka, которое обрабатывает и экспортирует метрики.
Поскольку Mesmer — это библиотека автоинструментации, ее добавление в существующий проект не требует каких-либо изменений в существующем коде, кроме настройки OpenTelemetry SDK Exporter. И даже это может не понадобиться, если вы уже используете OpenTelemetry в своем проекте.
Попробуйте Mesmer Akka Agent сегодня →
Диаграмма архитектуры ниже лучше всего описывает место Mesmer в конвейере OpenTelemetry.
Зачем контролировать Akka с помощью Mesmer Akka Agent
Akka — передовая и сложная технология. Он основан на концепции акторов и работает во многих направлениях: HTTP-серверы, удаленное взаимодействие, кластеризация, потоковая передача, постоянство и многое другое. Благодаря этому мы можем создавать комплексные решения, способные справиться практически с любым сценарием. Но даже наши решения имеют ограничения и могут иметь проблемы. Очень важно знать, где находятся эти ограничения и где находятся проблемы. Вот тут-то и начинается мониторинг вообще и Месмер в частности.
Попробуйте Mesmer Akka Agent сегодня →
Вот несколько примеров метрик, которые доступны из коробки, просто включив Mesmer в ваше развертывание:
Актеры Акка
- Количество обработанных сообщений с течением времени
- Время в почтовом ящике
Потоки Акка
- Количество запущенных потоков
- Сообщения, обрабатываемые при материализации потока
Акка HTTP
- Количество подключений
- Время отклика
Постоянство Akka
- Постоянное время действия
- Восстановление актера
Кластер Акка
- Доступные узлы
- Количество даун-событий
Полный список поддерживаемых метрик см. на странице https://github.com/ScalaConsultants/mesmer-akka-agent/blob/main/metrics.md.
Архитектура (расширение Akka и агент Java)
Как уже упоминалось, Mesmer состоит из двух основных компонентов — расширения системы акторов и агента Java. Генерация большинства интересных метрик требует использования технологии агента Java, которая выполняет модификацию байт-кода при загрузке классов Java. Существует несколько способов присоединения агента Java к процессу, но рекомендуемый способ — сделать это из командной строки с флагом `-javaagent`. Использование любого параметра среды выполнения может привести к тому, что некоторые функции будут недоступны, потому что если присутствует какой-либо уже загруженный класс, его преобразование возможно, но будет гораздо менее мощным.
Расширение Mesmer — это обычное расширение Akka, которое можно включить как из конфигурации, так и из кода. Поскольку агент Mesmer не имеет состояния, расширение Akka хранит информацию для расчета метрик из измененных классов и экспортирует ее в сборщик OpenTelemetry для дальнейшей обработки.
Это почти все. Когда речь заходит о мониторинге, наблюдаемости и OpenTelemetry, эта статья — лишь верхушка айсберга. Мы настоятельно рекомендуем вам ознакомиться с документацией OpenTelemetry (https://opentelemetry.io/docs/). В то же время, если вы используете Akka и хотите быстро начать работу, подключив свое приложение к инфраструктуре OpenTelemetry, вы можете заглянуть в репозиторий Mesmer (https://github.com/ScalaConsultants/ месмер-акка-агент). Он содержит инструкции и пример проекта, который поможет вам быстро приступить к работе. См. скриншоты ниже с интеграцией Mesmer, OpenTelemetry и Prometheus/Grafana.
Попробуйте Mesmer Akka Agent сегодня →
Дополнительные ресурсы:
- https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/ — история opentelemetry (создан 2 года назад, но показывает цели проэкт)
- https://opentelemetry.io/ — проект OpenTelemetry
- https://www.cncf.io/ — Фонд облачных вычислений
Первоначально опубликовано на https://scalac.io 12 июля 2021 г.
