Hi,

Can I please ask that you use the bug template or feature request template next time to a) show a config and b) show the full list of messages that come out so we have a quick way to reproduce. Thanks!

Steps to reproduce:

[[inputs.statsd]]
  protocol = "udp"
[[outputs.file]]

echo "eliot.diskcache.usage:0|g|c:f1ce8f072aab3dbe86e5dd91dcf83ad7a2a9147f26c45f5549eddd1a6608f763" | nc -C -w 1 -u localhost 8125

2023-03-31T21:20:12Z D! [inputs.statsd] Sample rate must be in format like: @0.1, @0.5, etc. Ignoring sample rate for line: eliot.diskcache.usage:0|g|c:f1ce8f072aab3dbe86e5dd91dcf83ad7a2a9147f26c45f5549eddd1a6608f763
f1ce8f072aab3dbe86e5dd91dcf83ad7a2a9147f26c45f5549eddd1a6608f763
2023-03-31T21:20:12Z E! [inputs.statsd] Splitting '|', unable to parse metric: eliot.diskcache.usage:0|g|c:f1ce8f072aab3dbe86e5dd91dcf83ad7a2a9147f26c45f5549eddd1a6608f763

It looks like this is taking place in parseStatsdLine. The extra data kicks off a logic branch to read extra fields as sample rate currently.

In addition to handling the actual container ID, we would also need to re-work how caching and metric building is handled. Right now there is assumption of a single field which is used to set the metric type. The new field for container id would need to be added and handled.

I am also not sure what work is required for events and if different paths are taken when the datadog specific settings are enabled.

I think it would be a nice improvement if even it just ignored this container field (rather than modeling it) so that it did not choke on these metrics.