Skip to content

Null-spans, or disabled spans? Null tracer? #174

@kristjanvalur

Description

@kristjanvalur

In our stack, I have been using this project for a particular system. Some colleagues have been adding tracing to Rust projects. We have various components here and there.

One feature they talk about is to check if an incoming request has a trace, and only in this case propagate the tracing through the system.

I don't see how this is possible transparently with dd-trace-cpp. The library relies heavily on auto allocated Span objects and it would be cumbersome to conditionally create and propagate spans.

Wouldn't it be cleaner to be able to set a flag on the captured or root span which then propagates to child spans, declaring the whole trace as disabled, and making trace injection a no-op?

Similarly, a report_traces member might control trace reporting on a trace-by-trace basis.

This would also tie in with a NullTracer a tracer you could create if you don't want any tracing to happen, or if tracer configuration somehow failed. Such a Tracer would create normal spans, but could optionally set the default to not inject any traces. ( I have mentioned this elsewhere, such a Null tracer would allow application code to be unchanged even if the library failed to configure correctly, or if it was decided to override all environment variables and not do any tracing at all)

In short, two flags:

class Span {
   ...
   void  set_report_trace(bool);  // call this to set whether this trace should be reported or not.
   void set_inject_trace(bool);  // call this to set whether this trace should be injected into outgoing dicts or not
};

This would affect the entire trace, would probably be booleans on the trace.
A Null tracer would have both false, although it might want to create trace_ids and inject them for outgoing traces
A tracer might also have a flag as to whether to extract would be a no-op or not.

Having such extra flags might allow us to:

  • customize trace handling for incoming traces, disabling trace reporting and trace propagation if there are no incoming traces.
  • globally disable trace extraction from the Tracer
  • customize the behaviour reporting of the library in null mode, e.g. does it create new trace ids and propagate them, or not?

It is possible to implement the above features by wrapping the library, and I have done so for our implementation where custom classes contain optional std::unique_ptr members to a dd::Span, but having it supported by the core library might be useful for other integrators.

Any thoughts?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions