- You are collecting metrics using
.Net Metrics API
- Then process, aggregate and export using metrics
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 Metrics API
- Provides only abstraction and events for telemetry/metrics.
- no value store
- no aggregation
- no ready solution
- Provides extended implementation
- value store.
- Less code control (cannot manipulate with store)
Let’s take a look how
.Net The counter is handled from start to finish…
1) We define
2) We register the concrete counter
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)
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.
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.
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.
All aggregates are stored in memory, When the process restarts, all values are lost
All metric values are considered internally
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.
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.
- 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.