[receiver/prometheus] add telemetry metrics for translation phase (metrics attempted and metrics dropped)

[lucasfcosta]

Add prometheus_receiver_translation_metric_points_attempted and prometheus_receiver_translation_metric_points_dropped counters to track OTLP data point translation success/failure rates.

Description

Adds two internal telemetry metrics to observe the Prometheus-to-OTLP translation phase:

• prometheus_receiver_translation_metric_points_attempted: Number of OTLP metric points the receiver attempted to create
• prometheus_receiver_translation_metric_points_dropped: Number of OTLP metric points that failed to be created (e.g., incomplete histograms missing _count)

Counting semantics: These metrics count in OTLP terms, not Prometheus series. A histogram with labels {method="GET"} counts as 1 attempted data point regardless of how many Prometheus series (buckets, sum, count) comprise it.

As explained in #44196, this makes it easier to correlate with the existing receiver_accepted_metric_points metric from ObsReport and understand the actual output of the receiver.

Also, note that even though the metric here uses the term metric_points, the unit for it is datapoints so that it's consistent with the collector's own metrics terminology, as in this example.

Link to tracking issue

Resolves #44196

Testing

I tested this PR manually and added unit tests.

The automated tests cover:

• Multiple gauges succeeding
• Complete histogram (with _count) succeeding
• Incomplete histogram (missing _count) being dropped
• Mixed gauge success + incomplete histogram drop

For my manual test, I did the following:

1. Created a fake Prometheus metrics server (basically hardcoded the metrics) serving:
   • 2 valid gauges, 2 valid counters, 1 complete histogram (5 successful metric points)
   • 2 incomplete histograms missing _count (2 metric points that should be dropped)
2. Configured the collector to scrape this server and expose telemetry on :8888
3. Built and ran the collector:

   make otelcontribcol ./bin/otelcontribcol_darwin_arm64 --config receiver/prometheusreceiver/testing/collector-config.yaml
   

4. After one scrape, queried the collector's metrics:
   curl -s http://localhost:8888/metrics | grep prometheus_receiver_translation
5. Verified the expected values:

• otelcol_prometheus_receiver_translation_metric_points_attempted = 7 (+5 for prometheus own metrics, up, scrape_duration_seconds, scrape_samples_scraped, scrape_series_added, scrape_samples_post_metric_relabeling)
• otelcol_prometheus_receiver_translation_metric_points_dropped = 2

If you want to verify my manual testing yourselves, I created an example repository here.

Documentation

The docs I added for this PR were autogenerated by mdatagen using the description and spec included in metadata.yaml.

Question for maintainers: Should we add a brief section to the README mentioning these new internal telemetry metrics? I considered doing that, but I wasn't sure if this was important enough to be there.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lucasfcosta / name: Lucas da Costa (ccb7272)

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Please review our Contributing Guidelines.
• Don't forget to sign the Contributor License Agreement (CLA) if you haven't already.

A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better!

[ArthurSens]

Wow, that's a great first contribution, thank you! Nothing to comment, LGTM! Thanks a lot for the very detailed description of how you've tested it!

We just need to fix some stuff to make CI happy. Changelog entry is missing .yml in the file name, and there's just some ordering issue in go.mod for some reason. make gotidy in the repository root should fix it