This is a feature needed to improve the experience of profiler-inferred spans.
This aims to fix a problem outlined here: https://github.com/elastic/apm-agent-java/blob/master/apm-agent-plugins/apm-profiling-plugin/README.md#with-non-implemented-workaround
Because inferred spans are created after-the-fact, a regular span cannot be a child of an inferred span.
Hence, we need a way to modify the parent id of spans after they are created.
Intake API changes
We'd need a new event type, either a specific one to just change the parent id or a generic one which allows updating arbitrary properties.
Just some ideas on how to tackle this:
Approach 1: update the ID in Elasticsearch
Use Elasticsearch's update API to update the parent id
Challenges:
A span can be in the following states:
- Waiting in the agent's internal queue
- On the wire in-between the agent and APM Server
- Waiting in APM Server's queue to be transmitted to Elasticsearch
- Indexed in Elasticsearch
There's even a chance that an ID update requests arrives at Elasticsearch before the corresponding span arrives. That can happen if the update request is handled by another API Server, for example.
In summary, we can't be sure whether a span is already in Elasticsearch when we want to update the ID.
Approach 2: index update document alongside span document
Instead of actually changing the parent id we could just index a separate document that sits alongside a span that contains the updated properties.
Challenges: The logic in the UI that constructs the waterfall tree has to incorporate this.
This is a feature needed to improve the experience of profiler-inferred spans.
This aims to fix a problem outlined here: https://github.com/elastic/apm-agent-java/blob/master/apm-agent-plugins/apm-profiling-plugin/README.md#with-non-implemented-workaround
Because inferred spans are created after-the-fact, a regular span cannot be a child of an inferred span.
Hence, we need a way to modify the parent id of spans after they are created.
Intake API changes
We'd need a new event type, either a specific one to just change the parent id or a generic one which allows updating arbitrary properties.
Just some ideas on how to tackle this:
Approach 1: update the ID in Elasticsearch
Use Elasticsearch's update API to update the parent id
Challenges:
A span can be in the following states:
There's even a chance that an ID update requests arrives at Elasticsearch before the corresponding span arrives. That can happen if the update request is handled by another API Server, for example.
In summary, we can't be sure whether a span is already in Elasticsearch when we want to update the ID.
Approach 2: index update document alongside span document
Instead of actually changing the parent id we could just index a separate document that sits alongside a span that contains the updated properties.
Challenges: The logic in the UI that constructs the waterfall tree has to incorporate this.