feat(telemetry): add telemetry support for user agent parsing

[BenjaminAbt]

• fixes Add telemetry (aka event-counters) #6
• due to breaking change with fluent api, bump version

[gfoidl]

Instead of the event source, I'd prefer to use OTel metrics via the meters.
Especially as we don't write to the event stream (which could be read e.g. via PerfView), and I don't think we need the diagnostic events.

[gfoidl]

As we don't write an event, should we use metrics (via meter factory) instead?
I'd prefer the OTel metrics here.

[BenjaminAbt]

There are too many projects that do not use OTEL - even I/we currently still use native app insights in almost all projects because OTEL features are missing.

[gfoidl]

Hm, with UseAzureMonitor I see metrics in Azure. What features are there missing?

[BenjaminAbt]

But we would still enforce everybody to use OTEL as foundation... I am not happy with that.

[gfoidl]

Then OK.

[BenjaminAbt]

@gfoidl , I added a telemetry hub and exposed otel native meters and dotnet metrics.
I think I dont have added any overhead.

[gfoidl]

For the OTel attributes we should follow the semantic convention (now, because changing it later would be a breaking change).

Sorry for the delay.

[BenjaminAbt]

@gfoidl no problem. I expected the delay, since it was the holidays. Happy New Year.

[BenjaminAbt]

@gfoidl there is this note

When instruments are measuring durations, seconds (i.e. s) SHOULD be used.

does this really make sense? We have parse.duration which is always 0s because its way faster than 0s

[gfoidl]

does this really make sense? We have parse.duration which is always 0s because its way faster than 0s

Makes sense, but the value has to be given as floating point number. Then the tools to display should show it as ms or that like.

[BenjaminAbt]

@gfoidl

the event source is

        _concurrentCacheMiss = new IncrementingEventCounter("cache-miss", this)
        {
            DisplayName = "Cache miss",
            DisplayUnits = "calls",
        };

the meter is

        s_concurrentCacheMiss = s_meter.CreateCounter<long>(
            name: "cache.miss",
            unit: "{call}",
            description: "Cache miss");

so calls vs call ..

Should that match as best practise?

[gfoidl]

Should that match as best practise?

Good question.

For the meter the singular "call" is correct, as the display end will use the pluralized form when needed.
For the event source, respectively the display ends no such pluralization is done automatically or at least there's no written down convention that dictates to do so. As "calls" is correct for the event source, I think it's best to keep them as they are now (so "calls" for the event source, and "call" for the meter).

[gfoidl]

Just the shared code, otherwise LGTM.