Q: Way to ignore healthcheck traces when using automatic tracer across all languages?

[naseemkullah]

Hi,

Will there be a way to ignore specific endpoints such as health checks when using the automatic tracer?

[z1c0]

Hi, not sure I understand the question correctly. Do you think of a way to exclude e.g. specific URLs? Why only for automatic tracer?

[naseemkullah]

Yes it would be nice to exclude specific URLs in the automatic tracer, and also not in the automatic tracer, but just want to make sure this exclusion feature is configurable in the automatic tracer.

[discostu105]

I agree that URL exclusions would make sense. We currently have that feature in Dynatrace for exactly that purpose.

In OpenTelementry, the broader question is:

At what level does such configuration need to be applied?

• API (config is exposed via API level)
• Tracer-impl (every tracer-implementation can have it's own config system)
  • Should the OTel SDK have such a config system?
• Exporter (it's up to the exporter to have a config)

I think config should not be exposed via API. Would add much more complexity. With healthchecks specifically however, it could make sense that a user gives a "hint" about "unimportant" requests (such as healthchecks), so that the Tracer-impl can decide on it's own to exclude them or not.

[mtwo]

+1 to this issue. Some OpenCensus implementations had a list of paths that wouldn't get sampled, which were often used to ensure that health checks, exporters, and other telemetry providers weren't generating traces. This was incredibly useful.

[tedsuo]

This feels like an SDK detail, but it would be great if there was a way to do this externally: a config file for example.

[naseemkullah]

https://github.com/open-telemetry/opentelemetry-js/issues/585 might be of interest

[pavolloffay]

Has been any decision made on this? I have started looking into this in the context of https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/1060

From the thread I cannot figure out how the skip URL pattern should work. There are two approaches

1. exclude a span from being created
2. create non-recording (not sampled) span, but respect upstream sampling decision

The first approach might result in broken traces (e.g. a health check might have an upstream parent or it calls any downstream service/instrumentation). The second approach is more consistent.

Is there a way to instruct the tracer to create non-recording span?

[pavolloffay]

from @iNikem

I think the right way is to use one of the factory methods on io.opentelemetry.trace.DefaultSpan.

So there is a way how to create non-recording span. The DefaultSpan has invalid context with zero span ID. I don't like two things about this:

• two code paths for creating a span
• invalid context with zero IDs. I would prefer a valid non-sampled context.

In OpenTracing there was sampling.priority=integer tag that span builder could use for sampling decision. This way multiple code paths were avoided.

[anuraaga]

I guess we could implement a custom Sampler? It could do ParentOrElse for non-matched paths and ParentOnly for marched paths I think.

DefaultSpan is going to be renamed to something like PropagatorOnlySpan so it'll become less appropriate, or we need to otherwise chime in on the spec issue that we have a valid use case here.

[directionless]

Forgive me if this is not in the right place, but I think I have a related usecase... I'm starting to use opentelemetry, and I've noticed that some of my libraries (go-redis) create traces. I can see how this is powerful, but right now, they're just clutter. So I'd love a reasonably low-level way to exclude them. I imagine by name, but I'm a bit fuzzy on all the nomenclature.

I think the best I can do right now, is configs in my exporter, but that feels very cumbersome.

[iNikem]

@carlosalberto I think this is a duplicate of #1597 and should be closed.

[xvilo]

@iNikem I want to add that #1597 is comparable, but in this case quite different. They are the other way around for each other and both valid use cases.

Anyway, do we already have a solution to this issue?