You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is causing us some issues, as we have carbon clients that are providing a float timestamp. The carbon protocol does suggest that an integer Unix timestamp should be used, but there is some prior art for allowing a float (which is why this has been working for us up until now!):
**Description:**
This allows timestamps to be sent as floats.
**Link to tracking Issue:** #31312
**Testing:**
Added unit test case with float timestamp.
**Description:**
This allows timestamps to be sent as floats.
**Link to tracking Issue:** open-telemetry#31312
**Testing:**
Added unit test case with float timestamp.
Component(s)
receiver/carbon
What happened?
Description
The carbon receiver expects an integer timestamp, and will raise an error if a float is provided:
This is causing us some issues, as we have carbon clients that are providing a float timestamp. The carbon protocol does suggest that an integer Unix timestamp should be used, but there is some prior art for allowing a float (which is why this has been working for us up until now!):
Steps to Reproduce
Send a carbon plaintext metric with a float timestamp, e.g.
my.metric 151 1708085258.254
Expected Result
The timestamp is accepted as if it were an int.
Actual Result
An error is raised and the metric is dropped.
Collector version
0.94.0
Environment information
Environment
Using opentelemetry-collector-contrib docker image
OpenTelemetry Collector configuration
No response
Log output
Additional context
No response
The text was updated successfully, but these errors were encountered: