Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support latest DogStatsD version #31295

Closed
jverce opened this issue Feb 16, 2024 · 4 comments
Closed

Support latest DogStatsD version #31295

jverce opened this issue Feb 16, 2024 · 4 comments
Labels
enhancement New feature or request needs triage New item requiring triage receiver/statsd statsd related issues

Comments

@jverce
Copy link
Contributor

jverce commented Feb 16, 2024

Component(s)

receiver/statsd

Describe the issue you're reporting

When using recent versions of the DogStatsD client (e.g. Java client) I noticed that metrics sent by the client weren't captured by the statsd receiver. The cause of this issue boils down to the statsd receiver rejecting metrics that contain unrecognized parts, and DogStatsD emits metrics with extra fields that are currently unsupported by the receiver.

In particular, there are 2 new fields that are currently unsupported by the receiver:

  • Container ID (since DogStatsD v1.2)
  • Timestamp (since DogStatsD v1.3)

Example of a metric that the statsd receiver drops due to the unrecognized parts:

workflow_execution.failure:1|c|#workflow.version:2,workflow.name:Telemetry 2|c:abc123"
@jverce jverce added the needs triage New item requiring triage label Feb 16, 2024
@github-actions github-actions bot added the receiver/statsd statsd related issues label Feb 16, 2024
Copy link
Contributor

Pinging code owners:

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

@jverce
Copy link
Contributor Author

jverce commented Feb 16, 2024

PR to fix this: #31296

@dmitryax
Copy link
Member

I'm wondering if this additional support should be configurable. But given that we already support tags that are part of the DogStatsD, I think supporting these additional parts OOTB is ok. Later, if we want to define the format in the configuration explicitly, we can have dogstatsd as a default option to keep the backward compatibility.

dmitryax pushed a commit that referenced this issue Feb 27, 2024
**Description:**
* Support DogStatsD v1.2 by accepting metrics with container IDs
* Support DogStatsD v1.3 by accepting metrics with timestamps
* Add tests for the cases above
* Improve readability in `statsd_parser_test.go` when calling
`testStatsDMetric`
* Add changelog entry

**Link to tracking Issue:** #31295

**Testing:**
1. Added unit tests to validate that the new fields are accepted and
interpreted correctly
2. Manual tests to verify that the metrics go through a collector
pipeline. Notice the `container_id` attribute and the `Timestamp` field,
which contains a custom value different from `StartTimestamp`:
```
ScopeMetrics #0
ScopeMetrics SchemaURL:
InstrumentationScope otelcol/statsdreceiver 0.94.0-dev
Metric #0
Descriptor:
     -> Name: workflow_execution.failure
     -> Description:
     -> Unit:
     -> DataType: Sum
     -> IsMonotonic: false
     -> AggregationTemporality: Delta
NumberDataPoints #0
Data point attributes:
     -> container_id: Str(d69b8773f0ac1d93447a5835cb4ed1bf13dd336d32994830687ae1f352c86fe4)
     -> deployment.id: Str(d_0lBskd)
     -> metric_type: Str(counter)
     -> env: Str(development)
     -> project.id: Str(proj_kYRs18)
     -> trace.id: Str(2cQtSfsef2TN3EC2psGIorPaFd8)
     -> workflow.id: Str(p_0PACqQ)
StartTimestamp: 2024-02-16 03:53:30.323425523 +0000 UTC
Timestamp: 2024-02-16 03:53:51 +0000 UTC
Value: 1
```
@crobert-1
Copy link
Member

I believe this was completed by #31296, so I'm going to close. Let me know if I misunderstood.

XinRanZhAWS pushed a commit to XinRanZhAWS/opentelemetry-collector-contrib that referenced this issue Mar 13, 2024
**Description:**
* Support DogStatsD v1.2 by accepting metrics with container IDs
* Support DogStatsD v1.3 by accepting metrics with timestamps
* Add tests for the cases above
* Improve readability in `statsd_parser_test.go` when calling
`testStatsDMetric`
* Add changelog entry

**Link to tracking Issue:** open-telemetry#31295

**Testing:**
1. Added unit tests to validate that the new fields are accepted and
interpreted correctly
2. Manual tests to verify that the metrics go through a collector
pipeline. Notice the `container_id` attribute and the `Timestamp` field,
which contains a custom value different from `StartTimestamp`:
```
ScopeMetrics #0
ScopeMetrics SchemaURL:
InstrumentationScope otelcol/statsdreceiver 0.94.0-dev
Metric #0
Descriptor:
     -> Name: workflow_execution.failure
     -> Description:
     -> Unit:
     -> DataType: Sum
     -> IsMonotonic: false
     -> AggregationTemporality: Delta
NumberDataPoints #0
Data point attributes:
     -> container_id: Str(d69b8773f0ac1d93447a5835cb4ed1bf13dd336d32994830687ae1f352c86fe4)
     -> deployment.id: Str(d_0lBskd)
     -> metric_type: Str(counter)
     -> env: Str(development)
     -> project.id: Str(proj_kYRs18)
     -> trace.id: Str(2cQtSfsef2TN3EC2psGIorPaFd8)
     -> workflow.id: Str(p_0PACqQ)
StartTimestamp: 2024-02-16 03:53:30.323425523 +0000 UTC
Timestamp: 2024-02-16 03:53:51 +0000 UTC
Value: 1
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs triage New item requiring triage receiver/statsd statsd related issues
Projects
None yet
Development

No branches or pull requests

3 participants