simitt
simitt
We should test this with the new benchmarking framework that @marclop is working on, once available.
related issue https://github.com/elastic/apm-server/issues/7504
@bryce-b we are currently targeting `7.15` for this, please let us know if this is more urgent.
@axw @bryce-b are we still blocked on this?
@bryce-b can you let us know if this becomes urgent? Pushing that further back for now.
@bryce-b can you please provide a current mapping so we can take a look?
Thanks for the heads up @bryce-b. Since the ingest processors live in the apm-server repo (https://github.com/elastic/apm-server/tree/main/apmpackage/apm/data_stream) - I suggest we just repurpose this issue (this way we also keep the...
The revisited goal is to add the mapping directly to ES, as an ingest processor (https://github.com/elastic/apm/issues/666, also see https://github.com/elastic/ecs/pull/2013). Rescoping this issue to add the processor to the relevant apm...
> I think this investigation should indeed focus on opentelemetry/cpp (and differences with opentelemetry/python and our own agents). It's likely that opentelemetry/cpp doesn't create the exit spans we need. @davemoore-...
This most certainly will require a fix in the Kibana code where the stack monitoring part lives.