TCP Statsd Receiver is not able to read payload

[4wdonny]

Component(s)

receiver/statsd

What happened?

Description

TCP Statsd Receiver can't decode payload

Steps to Reproduce

I've deployed the veneur-emit docker image and have it setup to emit metrics to a GCP LB in front of some collector pods using the statsd receiver set to TCP transport mode. If I set veneur-emit to ship the same metric via UDP to an agent running the statsd receiver with UDP set as the transport, I see my metrics processed correctly.

Expected Result

Statsd Metrics are ingested and processed over TCP the same as they are UDP

Actual Result

debug [email protected]/reporter.go:46 TCP transport (10.3.5.124:8128) Error reading payload: EOF {"kind": "receiver", "name": "statsd", "data_type": "metrics"}

Veneur Emit command

/veneur-emit -hostport tcp://$GCP_LB:8128 -name "my.test.metric" -tag "env:sandbox" -count "1" -debug

Collector version

0.103.0

Environment information

Environment

GKE 1.28

OpenTelemetry Collector configuration

statsd:
    endpoint: "0.0.0.0:8128"
    transport: "tcp"
    aggregation_interval: 60s
    enable_metric_type: true
    enable_simple_tags: true
    is_monotonic_counter: true
    timer_histogram_mapping:
      - statsd_type: "histogram"
        observer_type: "gauge"
      - statsd_type: "timing"
        observer_type: "histogram"
        histogram:
          max_size: 100

Log output

No response

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/statsd: @jmacd @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[bacherfl]

Hi, I was looking into this and also encountered this error log. However the metric i have sent seemed to have been received correctly. This was the command i used:

echo "test.metric:42|c|#myKey:myVal" | nc -w 100000 -4 -v localhost 8125;

I have also created a PR to not log an error when an EOF is encountered, as that is expected when the received payload is read completely

[4wdonny]

@bacherfl thanks for the reply. I have recreated your example and can confirm that the metric is logged when fired that way. I'm still not having any luck with the veneur-emit tool, which I had been relying on to programmatically emit statsd metrics for testing, but perhaps this is a bug on that side and not the tcp receiver. Feel free to close this when your PR is merged (or it can be closed before since the two aren't 100% related. Thanks again.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/statsd: @jmacd @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[atoulme]

If this is a Veneur emit issue, please consider opening an issue in veneur and link this one.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/statsd: @jmacd @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.