.NET Metrics Proxies

Metrics Scenario:

  • You are collecting metrics using .Net Metrics API
  • Then process, aggregate and export using metrics Opentelemetry SDK

under the hood, Opentelemetry SDK connects to .Net Metrics API Listening to registered meters.

A combination of both is recommended!

If you’re building an internal library, you probably don’t want to equip all your class libraries With the OpenTelemetry package.

.NET Metric! = OpenTelemetry Metric.

It’s important to point out that things work a little differently on each side.

net vs opentelemetry

.NET Metrics API

  • Provides only abstraction and events for telemetry/metrics.
  • no value store
  • no aggregation
  • no ready solution

OpenTelemetry SDK

  • Provides extended implementation
  • aggregation
  • value store.
  • Less code control (cannot manipulate with store)

example counter

Let’s take a look how .Net The counter is handled from start to finish…

1) We define Meter,
2) We register the concrete counter Meter,
3) We trigger a counter from code based on some event/action.

    // 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)
enter fullscreen mode

exit fullscreen mode

It is important to understand that .net counter has no value And No information about past status

You cannot query the current value, reset it, or interact with it.

net counter example

what happens if you call counter.Add(Value) many times?

  • The registered listener callback is called with the currentAdd(..) value.
  • No previous value or condition is passed to the listener.
  • No value exists between calls

Then why is it called counter?

It’s just an abstraction with information about the type and how much to increase/decrease the value. (+1,+10, -5) by a solid audience.

How to get the actual counter behavior?

A: Manual -> Write the code yourself

  • You need to implement a custom metric listener
  • Based on the counter event callback, you need to update a variable that holds the counter reading for you.

Simple example:

internal state implementation

The advantage is that you have complete code control.

B: Readymade -> Use OpenTelemetry SDK

  • Use the Opentelemetry SDK to do this automated analysis for you and access the values ​​through custom readers/exporters.

The advantage is that someone else wrote it for you

Opentelemetry SDK prevent AgregateStore, For each metric, the cumulative, sum, or histogram value is automatically stored, depending on the type.

For this reason readers/exporters can access the counter value.

opentelemetry aggregation

All aggregates are stored in memory, When the process restarts, all values ​​are lost

value representation

All metric values ​​are considered internally double either long,

depending on the source type, Opentelemetry SDK treats them like this double/long and assigns a value to a structure. This ensures equal memory allocation for all types.

so if you make a counterits value will expire long in overall memory.

From sources:

Opentelemetry Metric Point Values

This has simplified many SDK internal processes.

Forget the idea that a kind of counter int Saves some memory 🙂

Unusual Custom Reader+Exporter

  • Readers are responsible for manipulating the data and passing metrics to the exporter.
  • Exporters receive a batch of metrics, and each metric may have 1 or more metric points that must be exported.

Why do we need a practice?

On a project I was working on, I was looking for the easiest way to pass some real-time metrics to GraphQL subscriptions.

Let’s take a look at the example. servers There are IoT brokers for specific communication protocols.

Opentelemetry to GraphQL

  • The code consists of several independent parts and it was not possible to create a worker service to propagate values ​​to each.
  • In the future, there will be more “servers” and API normalization was necessary.

I’m building a custom reader + exporter that reads metrics and propagates those values ​​to a graphical subscription.

  • Each part uses only the essence .Net Metric API + A base class to hold the metric as needed.
  • Readers and exporters collect and forward changes to the graphical sub.
  • All exported values ​​are wrapped by a custom aggregated object with a dynamic value type property

Customers and portal users can now easily access specific real-time metrics data. All other metrics/traces are exported using the default built-in exporters.

The metric name is converted to a subscription topic and the server allows filtering based on UID or metric name.

You can give me GitHub. You can search on it and feel free to ask questions. For this reason the reader/exporter cannot access the counter value.

Leave a Comment