David Ashpole

I believe it just needs someone to implement it.

/triage accepted /priority important-longterm

I think the proposal is that prometheus exporters strip namespaces from metric labels if they match the namespace of the metric name

I'd like to work on this, if thats alright. I did an initial investigation, but i'm still learning about the structure of the collector. One thing I ran into is...

Comments from bogdan on 4/28: * Context may not be right, since context is lost when we do batching. * nit: maybe not call this latency, call it processing time.

I have implemented prototypes of a few approaches: 1. Pipeline latency with startTime propagated via context. Measures from obsreport.StartXXReceiveOp to obsresport.EndXXExportOp: [changes](https://github.com/dashpole/opentelemetry-collector/commit/3e503868b272402fb8c0c35db1709c1567398656) 2. Pipeline latency with startTime embedded in pdata...

A few thoughts: 3 is definitely the simplest, and aligns with the other obsreport telemetry we generate (per-component successes vs failures, per-component traces). Individual component processing durations aren't as good...

Notes from 5/12: * Lets try doing something context-based * Batch, groupby processors will be problematic. Needs more prototyping. * We need to be specific about exactly what we are...

I have a working draft for context-based e2e metrics that works for the batch processor: https://github.com/open-telemetry/opentelemetry-collector/pull/3183. Here is the description of the metric from the draft, which explains how we...

The schema is here: https://github.com/open-telemetry/opentelemetry-configuration It isn't OpenAPI v3, so we would have to do a good amount of legwork to convert that spec to one that can be embedded...