New traces definition spec

[preet-dev]

Problem Statement

The current traces definition and therefore the traces generator work for most cases but have nuances that can be difficult to process. Case in point, how we split spans of a trace into multiple payloads based on certain frequency limits. Also, the whole terminology in the existing definitions like spans, root spans and their relationships might be introducing a certain learning curve for someone who just wants some demo traces and maybe a few variations but doesn't necessarily understand OpenTelemetry terminology.

Proposed Solution

We should introduce a new definitions format based on endpoints & routes. Endpoints are basically services (db, web, messaging and more) and routes define a trace through them. Additionally, certain routes could be triggered only in certain conditions. We can achieve this using JEL expressions again. A rough sample:

"traces": {
  "routes": [{
    "condition": "event_fired(\"<event.domain:event.type>\", [<attribute_filters>])",
    "route": ["endpoints_type_1[endpoint_1.name]",  "endpoints_type_1[<endpoint_2.name>]"],
  }],
  "endpoints": {
    "endpoints_type_1": [{
      "name": "endpoint_1",
      "quartileDurationSeconds": [3, 5, 7],
      "resource_type": "entity_a",
      "attributes": []
    },
    {
      "name": "endpoint_2",
      "quartileDurationSeconds": [10, 12, 45],
      "resource_type": "entity_c",
      "attributes": []
    }]
  }
}

Alternatives Considered

N/A

[svrnm]

I like this very much, because this is also closer to how people think about things. A challenge might be internal spans, or are you able to represent them with that?

[preet-dev]

There will be endpoints of type internal which won't participate in routes.