jaeger-ui search filter by duration is misleading

[JaredTan95]

What happened?

I set max duration and min duration in jaeger-ui, but it seems not work well.

Steps to reproduce

max duration and min duration in jaeger-ui

Expected behavior

works well

Relevant log output

No response

Screenshot

No response

Additional context

No response

Jaeger backend version

No response

SDK

No response

Pipeline

No response

Stogage backend

No response

Operating system

No response

Deployment model

No response

Deployment configs

No response

[clement2026]

It is likely that a span of insight-server: gorm.Query has a duration less than 10ms.

If any span of a trace satisfies the filter, the trace should appear in the search result. The code of memory storage and Elasticsearch storage can confirm this.

memory storage:

jaeger/plugin/storage/memory/memory.go

Lines 246 to 253 in 3d67ac8

	func (m *Store) validTrace(trace *model.Trace, query *spanstore.TraceQueryParameters) bool {
	for _, span := range trace.Spans {
	if m.validSpan(span, query) {
	return true
	}
	}
	return false
	}

Elasticsearch storage:

jaeger/plugin/storage/es/spanstore/reader.go

Lines 509 to 564 in 3d67ac8

	// Below is the JSON body to our HTTP GET request to ElasticSearch. This function creates this.
	// {
	// "size": 0,
	// "query": {
	// "bool": {
	// "must": [
	// { "match": { "operationName": "op1" }},
	// { "match": { "process.serviceName": "service1" }},
	// { "range": { "startTime": { "gte": 0, "lte": 90000000000000000 }}},
	// { "range": { "duration": { "gte": 0, "lte": 90000000000000000 }}},
	// { "should": [
	// { "nested" : {
	// "path" : "tags",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "nested" : {
	// "path" : "process.tags",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "nested" : {
	// "path" : "logs.fields",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "bool":{
	// "must": {
	// "match":{ "tags.bat":{ "query":"spook" }}
	// }}},
	// { "bool":{
	// "must": {
	// "match":{ "tag.bat":{ "query":"spook" }}
	// }}}
	// ]
	// }
	// ]
	// }
	// },
	// "aggs": { "traceIDs" : { "terms" : {"size": 100,"field": "traceID" }}}
	// }
	aggregation := s.buildTraceIDAggregation(traceQuery.NumTraces)
	boolQuery := s.buildFindTraceIDsQuery(traceQuery)
	jaegerIndices := s.timeRangeIndices(s.spanIndexPrefix, s.spanIndexDateLayout, traceQuery.StartTimeMin, traceQuery.StartTimeMax, s.spanIndexRolloverFrequency)

[JaredTan95]

It is likely that a span of insight-server: gorm.Query has a duration less than 10ms.

makes me more confused.
From my understanding, the search result's duration range will be between 1ms and 10ms.

[clement2026]

As you see, there are 87 spans in the insight-server: gorm.Query trace. If one of these spans has a duration between 1ms and 10ms, the whole trace should appear in the search results.
When jaeger processes your search request, it searches all spans, not all traces.

[yurishkuro]

Correct - duration filter applies to individual spans, not to the duration of the whole trace or the root span.

[JaredTan95]

BTW, root span 's duration represents the whole trace's duration, right? If root span's duration match the range, so the traceId would not be aggs and would not be searched then.

[JaredTan95]

If we filter the root span by determining whether the reference value exists, can it fix the problem? @ClementRepo :-P

e.g. add exists query in

jaeger/plugin/storage/es/spanstore/reader.go

Lines 509 to 564 in 3d67ac8

	// Below is the JSON body to our HTTP GET request to ElasticSearch. This function creates this.
	// {
	// "size": 0,
	// "query": {
	// "bool": {
	// "must": [
	// { "match": { "operationName": "op1" }},
	// { "match": { "process.serviceName": "service1" }},
	// { "range": { "startTime": { "gte": 0, "lte": 90000000000000000 }}},
	// { "range": { "duration": { "gte": 0, "lte": 90000000000000000 }}},
	// { "should": [
	// { "nested" : {
	// "path" : "tags",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "nested" : {
	// "path" : "process.tags",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "nested" : {
	// "path" : "logs.fields",
	// "query" : {
	// "bool" : {
	// "must" : [
	// { "match" : {"tags.key" : "tag3"} },
	// { "match" : {"tags.value" : "xyz"} }
	// ]
	// }}}},
	// { "bool":{
	// "must": {
	// "match":{ "tags.bat":{ "query":"spook" }}
	// }}},
	// { "bool":{
	// "must": {
	// "match":{ "tag.bat":{ "query":"spook" }}
	// }}}
	// ]
	// }
	// ]
	// }
	// },
	// "aggs": { "traceIDs" : { "terms" : {"size": 100,"field": "traceID" }}}
	// }
	aggregation := s.buildTraceIDAggregation(traceQuery.NumTraces)
	boolQuery := s.buildFindTraceIDsQuery(traceQuery)
	jaegerIndices := s.timeRangeIndices(s.spanIndexPrefix, s.spanIndexDateLayout, traceQuery.StartTimeMin, traceQuery.StartTimeMax, s.spanIndexRolloverFrequency)

  "query": {
    "bool": {
      "must_not": [
        {
          "exists": {
            "field": "references.traceID"
          }
        }
      ], 
...

[yurishkuro]

BTW, root span 's duration represents the whole trace's duration, right?

Not always, you can have child spans finishing or even starting after the parent is finished. Trace duration in the results is computed as max-min timestamp across all spans.

[JaredTan95]

Yes, The asynchronous pattern is a typical case.