Александр Гольдебаев «OpenTelemetry для самых маленьких»

• Приложения сталкиваются с большим количеством ошибок и медленной работой.  

• Телеметрия помогает отслеживать ошибки, диагностировать их и исправлять.  

• Анализ телеметрии позволяет отслеживать деградацию системы после обновлений.  

• Observability предупреждает о возможных ошибках и помогает отслеживать актуальность нового кода.  

• Телеметрия — это лишь часть observability, которая способствует её реализации.  

• Классические логи — это простые строки, удобные для чтения, но сложные для анализа.  

• Структурированные логи имеют шаблон и данные, что облегчает анализ и фильтрацию.  

• Структурированные логи интегрируются с системами мониторинга и экономят место.  

• В .NET используется интерфейс ILogger для написания логов.  

• Методы ILogger: logInformation, logDebug, logError.  

• Для структурированного логирования рекомендуется использовать Serilog.  

• Конфигурация Serilog: насыщение логов контекстом, настройка вывода в консоль.  

• Пример логирования объекта с помощью Serilog.  

• Избегать использования имён свойств в качестве содержимого сообщения.  

• Использовать свойства шаблона для включения переменных сообщения.  

• Именовать свойства, используя префиксы.  

• Распределённая трассировка позволяет отслеживать путь запроса и определять место сбоя.  

• Контекст и пропагейшн передают метаданные между сервисами.  

• Спецификация OpenTelemetry по умолчанию использует Double-U Context.  

• Приложение состоит из фронтенда с двумя страницами: настроек и погоды.  

• Взаимодействие с сервисами настроек и погоды.  

• Генерация погоды и сохранение ответа в Redis.  

• Добавление статического ActivitySource к каждому контроллеру или сервису.  

• Передача названия и опционального параметра версии.  

• Начало операции через вызов startActivity с передачей названия активности.  

• После завершения операции вызывается метод stop.  

• Если модель не валидна, устанавливается статус ошибки.  

• Activity может вернуть null, если у Source нет слушателей.  

• В Event-контроллере добавляется Activity Source и ивент для логирования.  

• Спаны используются для пометкок действий.  

• Метод setTag позволяет добавлять метаданные.  

• Имя источника должно быть уникальным и иерархическим.  

• Имя должно быть основано на сборке, определяющей Activity Source.  

• Метрики помогают предупреждать ошибки и отслеживать состояние системы.  

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

• Сравнение с прошлыми версиями системы помогает выявить проблемы.  

• Примеры метрик: количество обращений к пункту, потребление ресурсов.  

• Современный провайдер метрик предлагает доступ к метру.  

• Метры — это группа инструментов для подсчёта метрик.  

• Инструменты бывают синхронными и асинхронными.  

• Синхронные инструменты требуют ручного добавления.  

• Асинхронные инструменты используют колбек-функцию для подсчёта метрик.  

• Примеры инструментов: counter, gauge, histogram.  

• Создание класса MyMetrics для управления метриками.  

• Регистрация класса как синглтон в DI.  

• Добавление метрик и метаданных в контроллер.  

• Выбор инструментов зависит от типа данных: время, уменьшение значений.  

• Использование dotnet-counters для просмотра метрик.  

• Разделение уровня иерархии через точку, слов — через нижнее подчёркивание.  

• Использование глобального стандарта для единиц измерения.  

• Создание отдельных классов метрик для каждого логического блока.  

• Телеметрия собирает данные с удалённых систем для мониторинга, визуализации и хранения.  

• Основные этапы телеметрии: сбор, передача, хранение, мониторинг, визуализация, анализ.  

• Инструментирование кода и сбор метрик, трассировок и логов.  

• Использование OpenTelemetry для объединения данных из разных источников.  

• Единый стандарт для бэкенд-телеметрии и языков.  

• Инструменты для экспорта данных.  

• Открытый исходный код и растущее сообщество.  

• Три категории пакетов: Core, .NET и инструменты-экспортеры.  

• Экспортеры для отправки данных в различные бэкенды телеметрии.  

• Объединение бэкендов телеметрии единым протоколом.  

• Поддержка разными сервисами телеметрии.  

• Принцип запрос-ответ и цели разработчиков.  

• Поддержка разных типов узлов.  

• Высокая скорость доставки данных.  

• Минимальное потребление процессорной мощности.  

• Бэкпшер-сигналинг для управления потоком данных.  

• Лофт-френдлильность и балансировка нагрузки.  

• ElasticSearch, Loki Stack, Kibana.  

• Выбор инструментов для экспорта метрик.  

• Библиотека Prometheus.NET и экспортер OpenTelemetry.  

• Преимущества и недостатки каждого варианта.  

• Структура Prometheus: сервер, ретривер, сервер алертинга.  

• Хранение данных в базе данных временных рядов.  

• Запрос данных с помощью PromQL.