Update Metric Filter proposed spec

[Leonardo-Ferreira]

Added "value" to the metric filter parameters as a way to filter metrics based on observed values.

This is very useful to avoid metrics like "You received zero http requests", "Your http queue length is zero", "The GC ran Zero times" and other "default" values.

[cijothomas]

This is very useful to avoid metrics like "You received zero http requests", "Your http queue length is zero", "The GC ran Zero times" and other "default" values.

I am not sure if this is the right direction. Would you elaborate a bit more? I'd like to first see an example where you see metrics like "you received zero http requests". If you were using Counters for this purpose, with delta temporality, if no new requests are received, then nothing gets exported. With cumulative, it'll be exporting the total count since start, not the requests-since-last-export).

[Leonardo-Ferreira]

If you want to collect metrics like "You received zero http requests" than just don't filter. In my case, I pay for every single byte I log, so I really want to only log relevant data.

The accumulated cost of logging "between 11:54 and 11:55 you received zero http requests" on application insights for all my apis was over $200. Each of those logs end up being about 500bytes long! and there are so many others that 99% of time report "default"... like process.runtime.dotnet.thread_pool.queue.length, kestrel.queued_connections, kestrel.queued_connections, aspnetcore.routing.match_attempts and many others...

We must be wasting several thousand dollars per day logging these kind of redundant data

[cijothomas]

If you want to collect metrics like "You received zero http requests" than just don't filter. In my case, I pay for every single byte I log, so I really want to only log relevant data.

The accumulated cost of logging "between 11:54 and 11:55 you received zero http requests" on application insights for all my apis was over $200. Each of those logs end up being about 500bytes long! and there are so many others that 99% of time report "default"... like process.runtime.dotnet.thread_pool.queue.length, kestrel.queued_connections, kestrel.queued_connections, aspnetcore.routing.match_attempts and many others...

We must be wasting several thousand dollars per day logging these kind of redundant data

I understand that some providers bill based on bytes, but this is not the right solution.
If you can tell where/how you are seeing such metrics, I can suggest better fixes. If this is specifically in OTel .NET (as you opened an issue there), I'd suggest to share a repro app, demonstrating the issue and we can take it from there.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.