Skip to content

Conversation

@imle
Copy link

@imle imle commented Mar 11, 2024

Looking to get some comments and guidance on this approach before getting to far into the weeds.

After a number of attempts, I settled on implementing the MeterProvider interface as a passthrough for otel metrics to the statsd.Client. This keeps much of the pipelineing system from otel out of the way of keeping things lined up with how this library already sends metrics.

Outstanding Work:

  • observable metrics, the whole reason this needs to be implemented in the statsd library
  • callbacks registered against the meter
  • verify that it is acceptable to send a float64 as a Counter value
    it does not appear to be acceptable
  • cleanup and improve readability and repeated work

imle added 5 commits March 11, 2024 13:54
* origin/master:
  update comments
  fix unit tests using global state
  fix unit tests
  Send both origin the container-id and the ENTITY_ID
  Fix cgroup parsing in ECS Fargate (DataDog#305)
  added dedicated codepath + comment
  fix cgroupv1 origin detection
  add description to test
  make sure we retrieve the cgroup inode when the cid is not found
@imle imle force-pushed the simle/add-otel-support branch from 58d8d0d to 9d15e76 Compare July 25, 2024 22:01
@carlosroman
Copy link
Contributor

I wonder if this will break our compatibility with older versions of Golang. At the moment datadog-go compiles and works with versions all the way back to go 1.12.
This is an interesting approach to being able to reuse our Golang client to send OTel metrics. I'll discuss this internally to see what people think.

@imle imle force-pushed the simle/add-otel-support branch from 9d15e76 to ed9e51d Compare December 3, 2024 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants