Add ads served counter metric with request and response types

[jlawrienyt]

Changes

Add a new counter to track the number of ad requests along with whether the request is targeted or not with context keys, and whether or not the response is targeted or random. This fulfills some of #73.

Merge Requirements

For new features contributions please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the docs folder

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[julianocosta89]

LGTM, I would just like to test it out whenever #656 gets merged.

[jlawrienyt]

I had some questions on some of the requirements in #73. Can post in slack also if that'd be the more appropriate place.

1. Services should use push metrics where possible. Is this just using the OTLP exporter for metrics?
2. Collectors should perform metric transforms to normalize resource and service metrics. Not sure what this was driving at

[julianocosta89]

@cartersocha may have some insights about it: #678 (comment)

[cartersocha]

The original requirements were created when metrics weren’t widely supported and mostly based off the spec. The requirements are probably worth revisiting in general.

In my mind we’d like at least multiple manual instrument types, trace exemplars, views, instrumentation libraries, regular attribute enrichment, and resource attribute enrichment.

What do y’all think?

I think the collector service / resource line poorly refers to resource enrichment haha.

[jlawrienyt]

In my mind we’d like at least multiple manual instrument types, trace exemplars, views, instrumentation libraries, regular attribute enrichment, and resource attribute enrichment.

Just to clarify a few things: by instrumentation libraries do you mean auto-instrumentation libraries providing metrics? And for resource attribute enrichment, I believe resource attributes can only be set when initializing the sdk, so do you mean adding more resource attributes beyond what might be auto-configured (also that would seem to apply beyond metrics, to all signal types)?

Otherwise, I think the list looks good.

[cartersocha]

Yes those. Auto instrumentation is a fraught topic given all the flavors and can mean many things. There's agent or injection based auto instrumentation like in Python-Java / Dotnet and general instrumentation libraries.

We probably want to separate those as distinct features in the feature matrix besides just saying instrumentation libraries?

Agent based metrics / traces vs. instrumentation libraries added to a provider?

Resource detectors like severin has been adding. They need to be added to both providers (if available)

[julianocosta89]

I like it!

[jlawrienyt]

Yes those. Auto instrumentation is a fraught topic given all the flavors and can mean many things. There's agent or injection based auto instrumentation like in Python-Java / Dotnet and general instrumentation libraries.

We probably want to separate those as distinct features in the feature matrix besides just saying instrumentation libraries?

Agent based metrics / traces vs. instrumentation libraries added to a provider?

Maybe the distinction between auto vs manual for instrumentation libraries is not so important, at least in terms of the feature matrix.

BTW, looks like your last PR overwrite the metrics table with trace info; going to revert that in this PR and attempt to update the columns to capture this dicussion.

[cartersocha]

thanks for catching that @jlawrienyt ! lgtm after resolving the conflict and thanks for the contribution 🚀