dd-trace-go
dd-trace-go copied to clipboard
How to configure automatic APM metrics correctly?
I've been using custom metrics to discriminate http.status_code
and http.method
.
According to
https://docs.datadoghq.com/tracing/guide/metrics_namespace/ I should have access to at least http.status_code
, but the tag is missing in the metric.
I am using the opentracing API and setting the tags manually.
opentracing:v1.2.0
dd-trace-go.v1:v1.34.0
datadog-agent:7 88420c49af00


I ran into what appears to be the same issue.
In my setup, the spans with the HTTP metadata that should yield the http.status_code
and other tags described in https://docs.datadoghq.com/tracing/guide/metrics_namespace/ are rendered by the instrumentation from opentracing-contrib. The http.status_code
value is added on this line as a numeric tag. But Datadog Agent only looks for the http status code in the span's metadata fields.
The options for fixing this are:
- Patch dd-trace-go's opentracing implementation so that it adds http status and other fields to metadata rather than metrics. See how Datadog's native http instrumentation does this.
- Have datadog-agent explore the metrics part of the trace payload here in addition to the metadata.
If it was up to me, I'd fix it on the agent end: encoding and decoding integers is more efficient than strings, no changes in the applications are necessary. However, I may be lacking some context making this a bad option. It'd be cool if somebody from Datadog looked into this.
👋 @nacho692 @deadok22
Looking into this. Thanks for the detailed information.
My initial inclination is to change this in the agent as @deadok22 suggests.