Are trace and span id integers too big for Datadog ?
davidjulien opened this issue · 1 comments
Hi,
I have an anomaly on metadata displayed by Datadog for my logs. trace_id and span_id values are incorrect if I keep them in integer format. I try different strategies to store trace_id value in metadata :
▎ 7 trace_id = Tracer.current_trace_id() # returns an integer
▎ 8
▎ 9 Logger.info("Trace: #{Tracer.current_trace_id()}",
▎ 10 trace_id_md_in_call: Tracer.current_trace_id(),
▎ 11 test_tostring_build: "#{Tracer.current_trace_id()}",
▎ 12 test_tostring_build_toint:
▎ 13 String.to_integer(
▎ 14 Regex.replace(
▎ 15 ~r/[A-Z]/,
▎ 16 "AFSGDFGDFGDFGD#{Tracer.current_trace_id()}RETGERYHRTJYTJX",
▎ 17 ""
▎ 18 )
▎ 19 ),
▎ 20 test_tostring_fun: Integer.to_string(Tracer.current_trace_id()),
▎ 21 test_local_var: trace_id,
▎ 22 test_tostring_toint:
▎ 23 String.to_integer(Integer.to_string(Tracer.current_trace_id()))
▎ 24 )
Log output :
"message":"Tracer: 7537620865444280684",
"test_local_var":7537620865444280684,
"test_tostring_build":"7537620865444280684",
"test_tostring_build_toint":7537620865444280684,
"test_tostring_fun":"7537620865444280684",
"test_tostring_toint":7537620865444280684,
"trace_id":7537620865444280684,
"trace_id_md_in_call":7537620865444280684
Datadog website:
message: Tracer: 7537620865444280684
test_local_var: 7537620865444280000
test_tostring_build: 7537620865444280684
test_tostring_build_toint: 7537620865444280000
test_tostring_fun: 7537620865444280684
test_tostring_toint: 7537620865444280000
trace_id: 7537620865444280000
trace_id_md_in_call: 7537620865444280000
How to fix that ?
Moreover, is there a way to display metrics send to Datadog agent in a friendly format ? Trace and span ids in apm seem correct (whereas they are not in logs). When I click on logs related to a span, I have this filter: "trace_id:7537620865444280684". Trace id value is correct here.
Thanks !
According to https://docs.datadoghq.com/tracing/connect_logs_and_traces/opentelemetry/ , trace_id and span_id must be formatted as a string in log.
Moreover this issue should have been created in Spandex project. Sorry !