[Feature]: When ES stores trace information queried through traceID, it can bypass the limitation of the "max_span_age" parameter by querying based on the time range.

[MicroOps-cn]

Requirement

My suggestion is to follow this: if no time is specified (or the default time range selected on the UI), use now - max_span_age~now. If the user enters a time range, use the time range to query. If the time range exceeds max span age, an error will occur. Alternatively, use startTime~startTime+max_span_age to calculate.

Problem

When ES is used as backend storage, querying trace information through traceID can only retrieve data within the period set by the "max_span_age" parameter?

If a time range is specified when querying, it can also narrow down the search ES index range. If only "max_span_age" is used to restrict, it may sometimes feel unfriendly.

Proposal

No response

Open questions

No response

[yurishkuro]

I don't understand the problem. max_span_age is the equivalent of TTL, beyond that the data may not exist. And when retrieving trace by ID, the time range is often not specified - as long as the trace is still within the retention / TTL period I think it makes sense to return it. So what is it that you are trying to achieve?

[MicroOps-cn]

I don't understand the problem. max_span_age is the equivalent of TTL, beyond that the data may not exist. And when retrieving trace by ID, the time range is often not specified - as long as the trace is still within the retention / TTL period I think it makes sense to return it. So what is it that you are trying to achieve?

I can find last month's tracking records through the Search page, but I cannot query the detailed information of last month's tracking records based on the returned tracking ID (because the default parameter is 72 hours). Although it is possible to expand the max_stpan_age parameter to query longer tracking details, I do not think this is a wise move.

I guess the original design of max_stpan_age was to optimize performance and avoid hitting too many indexes when querying detailed information based on tracking IDs. But if I want to query tracking information for a longer period of time, I have to increase the value of max_stpan'age, which goes against the original intention of max_stpan'age.

[yurishkuro]

if you have 30d worth of data your max_span_age is supposed to be set to 30d, not 72hrs

[MicroOps-cn]

if you have 30d worth of data your max_span_age is supposed to be set to 30d, not 72hrs

If you say that, I don't understand the meaning of the max_span_age parameter. If the max_span_age can be set arbitrarily, or if you think it is used to control the lifecycle of tracking, why not design it this way:
Allow ES to control the lifecycle on its own (such as ES's Index Lifecycle Management), with the default setting being unlimited or simply removing the setting.

[yurishkuro]

It depends on how you setup es index rotation, since es doesn't support row level TTL. If you use the manual rotation scripts from early versions of Jaeger then the settings for retention are split and you have to tell Jaeger how far back through dated indices to look, which is where you need max span age parameter. If you're using read alias (recommended) then max age parameter is irrelevant.