PrometheusReceiver ignores Summary and Histogram Metrics that do not have _sum counter.

[sankala-dremio]

Describe the bug
Summary and Histogram metrics exposed by frameworks like DropWizard do not track "_sum" counter and hence do not produce this in the output. When Prometheus receiver is run against such outputs, the histograms and Summaries are just ignored.

Steps to reproduce
A Simple Dropward application with a histogram metric and otelcollector with prometheus receiver.

What did you expect to see?
Expect to see the Histogram / Summary passed through the pipeline and available for exporters (with _sum as "0").

What did you see instead?
The Metric is dropped silently.

What version did you use?
Version: (v0.21.0)

What config did you use?
`receivers:
prometheus:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: [ 'localhost:35599' ]
labels:
instance_type: gke_container
container_name: "${CONTAINER_NAME}"
namespace_id: "${NAMESPACE_NAME}"
pod_id: "${POD_NAME}"

processors:
batch:

exporters:
file:
path: /tmp/metrics.json

logging:
loglevel: debug
sampling_initial: 5
sampling_thereafter: 5

service:
pipelines:
metrics:
receivers: [prometheus]
processors: []
exporters: [logging, file]
`
Environment
OS: Debian
Docker image.

Additional context
Add any other context about the problem here.

[rakyll]

cc @odeke-em

[odeke-em]

Thank you for this report @sankala-dremio and welcome to the OpenTelemetry project!
Thank you for the tag @rakyll!

Investigation

Using a DropWizard quickstart from Brian Brazil's repository I spun up https://github.com/odeke-em/bugs/tree/master/opentelemetry-collector/2661 which is a Java service using DropWizard and a Prometheus metrics scrape endpoint
To ensure that both Prometheus server and the OpenTelemetry collector can be run and compared against here are their configurations in the Appendix subsection

Firstly if we add a single print of the metrics translated to OTLP metrics, we can clearly see the summaryValue

I believe this might be a problem in the prometheus exporter and NOT the receiver and if you apply this diff we'll see
the metric CLEARLY scraped and received from the prometheusreceiver

diff --git a/receiver/prometheusreceiver/internal/transaction.go b/receiver/prometheusreceiver/internal/transaction.go
index e2252f23..fa1dce00 100644
--- a/receiver/prometheusreceiver/internal/transaction.go
+++ b/receiver/prometheusreceiver/internal/transaction.go
@@ -17,6 +17,7 @@ package internal
 import (
        "context"
        "errors"
+      "encoding/json"
        "math"
        "net"
        "sync/atomic"
@@ -154,6 +155,8 @@ func (tr *transaction) Commit() error {
                obsreport.EndMetricsReceiveOp(ctx, dataformat, 0, err)
                return err
        }
+        blob, _ := json.MarshalIndent(metrics, "", "  ")
+        println(string(blob))
 
        if tr.useStartTimeMetric {
                // startTime is mandatory in this case, but may be zero when the

  {
    "metric_descriptor": {
      "name": "jvm_gc_collection_seconds",
      "description": "Time spent in a given JVM garbage collector in seconds.",
      "unit": "s",
      "type": 7,
      "label_keys": [
        {
          "key": "gc"
        }
      ]
    },
    "timeseries": [
      {
        "start_timestamp": {
          "seconds": 1617691509,
          "nanos": 619000000
        },
        "label_values": [
          {
            "value": "G1 Young Generation",
            "has_value": true
          }
        ],
        "points": [
          {
            "timestamp": {
              "seconds": 1617691509,
              "nanos": 619000000
            },
            "Value": {
              "SummaryValue": {
                "count": {
                  "value": 4
                },
                "sum": {
                  "value": 0.026
                }
              }
            }
          }
        ]
      },
      {
        "start_timestamp": {
          "seconds": 1617691509,
          "nanos": 619000000
        },
        "label_values": [
          {
            "value": "G1 Old Generation",
            "has_value": true
          }
        ],
        "points": [
          {
            "timestamp": {
              "seconds": 1617691509,
              "nanos": 619000000
            },
            "Value": {
              "SummaryValue": {
                "count": {},
                "sum": {}
              }
            }
          }
        ]
      }
    ]
  },

1. Scrape directly from localhost:1234/metrics

By visiting http://localhost:1234/metrics we can get the full source of truth and we can see the summary metrics

# HELP jvm_gc_collection_seconds Time spent in a given JVM garbage collector in seconds.
# TYPE jvm_gc_collection_seconds summary
jvm_gc_collection_seconds_count{gc="G1 Young Generation",} 4.0
jvm_gc_collection_seconds_sum{gc="G1 Young Generation",} 0.026
jvm_gc_collection_seconds_count{gc="G1 Old Generation",} 0.0

2. Using Prometheus to directly scrape DropWizard

Using the Prometheus configuration and then running a fresh Prometheus server with targets set to scrape the DropWizard server, shows the summary *gc_collection_seconds metrics scraped

3. Using the OpenTelemetry Collector Prometheus Receiver to scrape DropWizard then be scraped by Prometheus

Using the OpenTelemetry configuration and the Prometheus configuration and then running a fresh Prometheus server with targets set to scrape the DropWizard server, unfortunately doesn't show those metrics

4. Using @sankala-dremio's PR that skips

That PR #2812 doesn't seem to do anything either

Appendix

Configuration files

prometheus.yaml

global:
  scrape_interval: 10s

  external_labels:
    monitor: 'otlc'
        
scrape_configs:
  - job_name: 'otlc'
                  
    scrape_interval: 10s
        
    static_configs:
        - targets: ['localhost:8888', 'localhost:1234']

otel_collector_config.yaml

receivers:
    otlp:
        protocols:
            grpc:
            http:

    prometheus:
        config:
            scrape_configs:
                - job_name: 'otel-collector'
                  scrape_interval: 10s
                  static_configs:
                      - targets: ['0.0.0.0:8888', 'localhost:1234']

processors:
    batch:

exporters:
    jaeger:
        endpoint: "0.0.0.0:14250"
        insecure: true

    prometheus:
        endpoint: "0.0.0.0:8889"
        namespace: "collector-origin"
        metric_expiration: 180m
        send_timestamps: true

service:
    pipelines:
        traces:
            receivers: [otlp]
            processors: [batch]
            exporters: [jaeger]
        metrics:
            receivers: [otlp, prometheus]
            processors: [batch]
            exporters: [prometheus]

[odeke-em]

The problem here is that the Prometheus exporter doest NO support for the MetricDataTypeSummary type. Please help update this title accordingly @alolita to make it a feature request for exporter/prometheusexporter: support translating MetricDataTypeSummary