[statsdreceiver] Counters are marked as monotonic

[mx-psi]

Describe the bug

Statsd count metrics are being reported as monotonic when they are not. This can cause other components to incorrectly assume monotonicity (currently the SignalFx exporter and in the future the Datadog exporter).

Steps to reproduce

Run an OpenTelemetry Collector with the statsd receiver and send a count metric to it.

What did you expect to see?

Statsd metrics being reported as non-monotonic.

What did you see instead?

Statsd metrics being reported as monotonic. For a metric sent as counter.name:1|c.

Metric #28
Descriptor:
     -> Name: counter.name
     -> Description:
     -> Unit:
     -> DataType: IntSum
     -> IsMonotonic: true
     -> AggregationTemporality: AGGREGATION_TEMPORALITY_CUMULATIVE
IntDataPoints #0
StartTime: 0
Timestamp: 1607442068000000000
Value: 1

What version did you use?
313a5a5

What config did you use?
Config:

receivers:
  statsd:
    endpoint: "localhost:8125"

exporters:
  logging:
    loglevel: debug

service:
  pipelines:
    metrics:
      receivers: [statsd]
      exporters: [logging]

Environment
OS: macOS 10.15
Compiler(if manually compiled): go 1.15.5

Additional context

In StatsD, counters are not monotonic and work like deltas that are aggregated on the server side.

From b/statsd_spec:

A counter is a gauge calculated at the server. Metrics sent by the client increment or decrement the value of the gauge rather than giving its current value.

From statsd/statsd:

gorets:1|c This is a simple counter. Add 1 to the "gorets" bucket. At each flush the current count is sent and reset to 0.

They can increment or decrement and the instrumented application should report these increments or decrements rather than the whole value.

In the statsd receiver they are set as cumulative OpenCensus metrics:

opentelemetry-collector-contrib/receiver/statsdreceiver/protocol/statsd_parser.go

Lines 169 to 172 in a20a6f4

	case "c":
	return buildCounterPoint(parsedMetric, now, func(parsedMetric *statsDMetric) {
	parsedMetric.metricType = metricspb.MetricDescriptor_CUMULATIVE_INT64
	})

Cumulative values are described by the OpenCensus proto as:

Floating [resp. Integer] point cumulative measurement. The value cannot decrease [...].
Recorded values are always >= 0.

The OpenCensus translator then maps this type into an IntSum with cumulative aggregation and monotonic.

I am not sure if they should be marked as cumulative either, given the OpenTelemetry proto description:

aggregation_temporality describes if the aggregator reports delta changes
since last report time, or cumulative changes since a fixed start time.

but this seems to be more common (e.g. some components on the core repo do this too, like the hostmetrics receiver), so I am not sure if this last part should be considered a bug.

[mx-psi]

cc @keitwb @jmacd since you are CODEOWNERS of this component.

[gavindoudou]

Thanks for that, the new version has changed the type for counter already: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/master/receiver/statsdreceiver/protocol/statsd_parser.go#L220
Please take a look if the issue can be resolved.

[mx-psi]

Closing since I can no longer reproduce the issue. Thanks for the fix!

[jmacd]

Hmmm. I think the correct output point for a Statsd counter should be the non-monotonic delta sum, not the gauge, but we can revisit this.