Сценарий показателей:

  • Вы собираете метрики, используя .Net Metrics API
  • Затем обработайте, агрегируйте и экспортируйте метрики, используя Opentelemetry SDK

Телеметрия показателей .Net

Под капотом, Opentelemetry SDK подключается к .Net Metrics API путем прослушивания зарегистрированных счетчиков.

Рекомендуется сочетание обоих!

Если вы создаете внутреннюю библиотеку, вы, вероятно, не хотите оборудовать все свои class libraries с пакетами opentelemetry.


Метрика .Net != Метрика Opentelemetry.

Важно отметить, что все работает немного по-разному на каждой стороне.

Сеть против Opentelemetry

API метрик .Net

  • Предоставляет только абстракцию и события для телеметрии/показателей.
  • Нет хранилища ценности
  • Нет агрегации
  • Нет готовых решений

SDK OpenTelemetry

  • Обеспечивает расширенную реализацию
  • Агрегация
  • Магазин ценностей.
  • Меньше контроля над кодом (не могу манипулировать с магазином)


Счетчик как пример

Давайте посмотрим, как .Net счетчик обрабатывается от начала до конца…

1) Определяем Meter.
2) Прописываем конкретный счетчик под Meter.
3) Мы запускаем счетчик из кода на основе какого-то события/действия.

    // Meter instance
    var _meter = new Meter("MeterName","v0.1");

    // Counter creation
    var counter = _meter.CreateCounter<long>("InstrumentName", "Unit", "Description");

    // Triger on Event
    counter.Add(1)
Войти в полноэкранный режим

Выйти из полноэкранного режима

Важно понимать, что Счетчик .Net не имеет значения а также не имеет представления о предыдущем состоянии

Вы не можете запросить текущее значение, сбросить его или взаимодействовать с ним.

Пример чистого счетчика


Что произойдет, если вы позвоните counter.Add(Value) много раз?

  • Зарегистрированные обратные вызовы прослушивателя вызываются с текущим значением Add(..).
  • Слушателю не передается предыдущее значение или состояние.
  • Между вызовами нет значения


Тогда почему он называется счетчиком?

Это просто абстракция с информацией о типе и насколько увеличить/уменьшить значение. (+1 ,+10, -5) конкретными слушателями.


Как добиться реального поведения счетчика?

A: Вручную -> Пишите код самостоятельно

  • Вам необходимо реализовать собственный прослушиватель метрик
  • На основе обратного вызова события счетчика вам необходимо обновить переменную, которая содержит показания счетчика.

Простой пример:

Реализация внутреннего состояния

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

B: ReadyMade -> Использовать Opentelemetry SDK

  • Используйте Opentelemetry SDK, чтобы делать это автоматически и получать доступ к значениям с помощью пользовательских программ чтения/экспорта.

Преимущество в том, что кто-то другой написал это для вас

Opentelemetry SDK содержит AgregateStore. Для каждой метрики автоматически сохраняется совокупное значение, сумма или значение гистограммы, в зависимости от типа.

По этой причине читатели/экспортеры могут получить доступ к значению счетчика.

Агрегация OpenTelemetry

Все агрегаты хранятся в памяти! При перезапуске процесса все значения теряются


Представление стоимости

Все значения метрик внутренне обрабатываются как double или же long.

В зависимости от типа источника, Opentelemetry SDK относится к ним как double/long и присваивает значение структуре. Это обеспечивает одинаковое выделение памяти для всех типов.

Итак, если вы создадите counterего значение будет равно long в совокупной памяти.

Из источников:

Значение метрики Opentelemetry в баллах

Это упростило многие внутренние процессы SDK.

Забудьте о том, что счетчик типа int экономит память 🙂


Необычный пользовательский ридер+экспортер

  • Читатели несут ответственность за обработку данных и передачу метрик экспортеру.
  • Экспортеры получают пакет метрик, и каждая метрика может содержать 1 или несколько точек метрики, которые необходимо экспортировать.

Зачем нужен обычай?

В проекте, над которым я работал, я искал самый простой способ передать некоторые метрики в реальном времени подпискам GraphQL.

Давайте посмотрим на примере. servers являются IoT-брокерами для определенного протокола связи.

Открыть телеметрию в GraphQL

  • В коде есть несколько независимых частей и для каждой не было возможности создать рабочий сервис для распространения значений.
  • В будущем будет больше «серверов», и необходима нормализация API.

В итоге я создаю собственный модуль чтения и экспорта, который считывает метрики и распространяет эти значения на подписки Graphql.

  • Каждая часть просто использует аннотацию .Net Metric API + базовый класс для хранения метрики в требуемом виде.
  • Reader и Exporter собирают и отправляют изменения в Graphql Sub.
  • Все экспортируемые значения упаковываются в настраиваемый унифицированный объект со свойством динамического типа значения.

Клиенты и пользователи портала теперь могут легко получить доступ к конкретным данным метрик в реальном времени. Все остальные метрики/трассировки экспортируются с использованием встроенных средств экспорта по умолчанию.

Имя метрики преобразуется в тему подписки и позволяет выполнять фильтрацию на основе UID сервера или имени метрики.

Вы можете найти меня на Гитхаб.и не стесняйтесь задавать вопросы. По этой причине читатели/экспортеры не могут получить доступ к значению счетчика.