В этом документе в общих чертах описывается, что ожидается от решения для мониторинга, а также предлагаются инструменты, которые могут быть использованы для приложений C++.
OpenTelemetry имеет широкую и общую терминологию для определения понятий вокруг возможных типов телеметрических данных. Здесь мы сосредоточимся на трассировках, метриках, журналах и на том, что там не рассматривается: отчеты о сбоях.
- Мониторинг приложений C++
- Общая архитектура
- Доступные инструменты и сервисы
- Журналы
- Метрики
- Трассировки
- Отчеты об авариях
- Визуализация
- Заключение
Общая архитектура
Вообще говоря, любое программное приложение генерирует следующие виды данных для целей мониторинга:
- Журналы: текстовая запись с метаданными и потенциально семантической информацией о действии, выполняемом программным обеспечением.
- Метрики: числовые измерения, которые могут описывать полезную информацию (например, счетчик выполнения или таймер) о выполняемом действии или событии
- Трассы: метаданные, которые могут быть соотнесены между приложениями, взаимодействующими между собой (используются для создания распределенных профилировщиков).
- Отчеты о сбоях: артефакты, генерируемые приложением при возникновении неустранимого сбоя (обычно в виде дампов памяти).
Каждый вид данных обычно имеет сервис (или независимую функциональность сервиса), который поддерживает и хранит их для будущих запросов и анализа. И в зависимости от используемого инструмента, механизм получения данных может быть различным. Тем не менее, обычно сервисы на рынке следуют схожему подходу, когда данные подталкиваются, за исключением журналов, где есть другое программное обеспечение (называемое агентом), которое запускается отдельно и отвечает за получение журналов из источника (например, файла в файловой системе) в предназначенный сервис.
Примечание: это простой анализ только независимого приложения, за которым ведется наблюдение. Здесь не рассматриваются возможности, которыми обладают системы оркестровки контейнеров, такие как Kubernetes.
Общая архитектура того, что было описано, может быть показана следующей схемой:
+-----------------------------------------+
| Company Infrastructure |
| |
+-----------------------------------+ | +-----------------+ |
| Machine | | | | |
| | +--------+-----> Logs Server | |
| +-------------+ | | | | | |
| | | | Push | | +-----------------+ |
| Pull | Log agent +---+-------------+ | |
| +--------> | | | +------------------------------+ |
| | +-------------+ | | | | |
| | | +------+-----> Distributed Tracing System | |
| +----v--+ | Push traces | | | | |
| | +-----------------------+---------------+ | +------------------------------+ |
| | App | | | |
| | +-----------------------+---------------+ | +------------------+ |
| +-----+-+ | Push metrics | | | | |
| | | +------+-----> Metrics Server | |
| | | | | | |
| | | | +------------------+ |
+---------+-------------------------+ | |
| | +----------------------------+ |
| | | | |
+------------------------------------------------+-----> Crash Reporting System | |
Push minidumps | | | |
| +----------------------------+ |
| |
| |
+-----------------------------------------+
Для трассировок, метрик и отчетов о сбоях необходимы изменения в коде, чтобы отправить данные соответствующим службам. А для журналов, как уже говорилось, за это отвечает агент. Таким образом, приложению нужно только отправить журналы, например, в файл, а все остальное сделает правильно настроенный агент.
При таком подходе приложение, работающее в клиентской среде, может публиковать данные телеметрии без необходимости раскрывать свою внутреннюю сеть, разрешая внешний входящий трафик. Весь трафик является исходящим.
Для каждого компонента, представленного на схеме, существует несколько (и я действительно имею в виду несколько 😅) инструментов и услуг, доступных на рынке, которые могут помочь реализовать эту архитектуру мониторинга. Чтобы не затягивать обсуждение, здесь я упомяну лишь несколько из них для каждого вида данных, которые мы хотим отслеживать.
Доступные инструменты и сервисы
Основное внимание будет уделено стандарту OpenTelemetry и инструментам в экосистеме Grafana. Это позволит приложению быть совместимым с множеством инструментов и сервисов на рынке, при этом обеспечивая легкую визуализацию и управление почти всеми телеметрическими данными (за исключением отчетов об авариях, которые будут рассмотрены позже).
Журналы
Рекомендуется использовать форматтер логов для добавления степени тяжести, временной метки, идентификаторов корреляции и других метаданных для корреляции логов с другими телеметрическими данными. Также хорошо форматировать журналы в определенном формате (например, json), чтобы иметь возможность быстро запросить журналы после этого без слишком больших правил предварительной обработки.
Для этого можно использовать OpenTelemetry SDK.
Что касается сервера логов, можно использовать Grafana Loki (также известны ELK stack и Datadog с поддержкой не только логов, но и трасс и метрик).
Поскольку агент должен быть совместим с сервером логов, нам нужно следовать документации Grafana. Там показано несколько вариантов на выбор, например Promtail или Fleunt Bit.
Метрики
Следуя экосистеме Grafana, Prometheus является широко используемым сервером метрик, а в OpenTelemetry уже есть хороший пример его использования.
Трассы
И здесь мы снова можем использовать инструмент из экосистемы Grafana и OpenTelemetry. Используя Tempo в качестве распределенной системы трассировки, мы можем использовать OpenTelemetry (пример) для отправки трасс на него, поскольку Tempo совместим со стандартом OpenTelementry.
Отчеты об авариях
Что касается отчетов об авариях, то здесь все интереснее. Ни в OpenTelemetry, ни в Grafana нет ничего, что было бы предназначено для обработки такого рода телеметрических данных. Мы по-прежнему можем публиковать трассировки с информацией об ошибках для исключений, которые можно обработать, но для получения информации о таких сбоях, как segfaults, необходимо использовать другой инструмент.
Одним из интересных вариантов является Sentry. Он также имеет интеграцию с приложениями на базе Qt — библиотеки, широко используемой в графических интерфейсах C++.
Еще один пример — Raygun. Хотя у него нет SDK, он показывает, как вы можете интегрировать свое программное обеспечение с брейкпадом Google и отправлять отчет о падении через http-запрос.
Оба варианта имеют собственные графические интерфейсы, поэтому вы не сможете получить к ним доступ на том же месте, где вы получаете доступ к остальным данным телеметрии.
Визуализация
И в заключение, для визуализации всех этих данных (за исключением отчетов об авариях) можно использовать саму Grafana для запросов, управления и создания приборных панелей, оповещений и т.д. на основе этих данных. А при правильной настройке корреляционные идентификаторы могут быть использованы для того, чтобы разработчик мог получить все виды телеметрических данных, связанных с взаимодействием с пользователем, чтобы получить лучшее представление о том, как используется приложение и насколько оно эффективно.
Заключение
Конечно, это не единственный способ достижения хорошего уровня наблюдаемости вашего приложения, но это один из способов с хорошей синергией между инструментами и сервисами, выбранными с помощью лаконичного технологического стека.