Another attempt at span monitoring

[tsloughter]

Things I don't like:

• The monitor option being part of start span but applying to all spans started in that same process is odd.
  • One solution is to have it only end the 1 span but monitoring all spans in a process makes more sense
  • Another is to have a monitor(Pid) function in the API that calls the SDK. Reason I don't like that is it has to lookup what SDK is being used.
• Because pid isn't updated at any point this changes how we will be suggesting child spans are created for remote processes from https://opentelemetry.io/docs/instrumentation/erlang/manual/#spans-in-separate-processes to having to instead use a new API (see the new start_span macro added in this PR) to pass the parent context when starting the child in the new process.

I am still kicking around where I stand on these issues and there are probably more, but opening this for feedback.

[codecov]

Codecov Report

Attention: Patch coverage is 87.87879% with 4 lines in your changes missing coverage. Please review.

Project coverage is 72.53%. Comparing base (b409a5f) to head (ef6fe02).
Report is 435 commits behind head on main.

Files with missing lines	Patch %	Lines
apps/opentelemetry/src/otel_span_monitor.erl	84.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #602      +/-   ##
==========================================
+ Coverage   72.34%   72.53%   +0.19%     
==========================================
  Files          60       61       +1     
  Lines        1902     1930      +28     
==========================================
+ Hits         1376     1400      +24     
- Misses        526      530       +4     

Flag	Coverage Δ
api	68.21% <100.00%> (+0.04%)	⬆️
elixir	18.44% <100.00%> (+0.12%)	⬆️
erlang	73.89% <87.87%> (+0.23%)	⬆️
exporter	66.80% <ø> (ø)
sdk	78.42% <87.50%> (+0.19%)	⬆️
zipkin	54.16% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ferd]

Would using the monitor(Pid) call for a given span allow the process touching the span to define how or when it wants it tracked? I could imagine the monitor option just deferring to an API Call for that, but as you said, the biggest issue is maintaining compatibility by adding the call?

[tsloughter]

@ferd not sure what you mean about touching a span.

[ferd]

@ferd not sure what you mean about touching a span.

Mostly creating a span in one process and then handing it over to another for most of its lifecycle

[tsloughter]

That would depend on updating the pid field of the span data in the ets table when it gets handed over.

[albertored]

I haven't yet looked at the implementation details but from an end-user point of view if monitor is an option on span creation I would expect only that span is monitored, if instead a monitor(pid) API is exposed then I would expect all spans handled by that process to be monitored.

Said so, I agree that monitoring only a subset of the spans handled by a process doesn't make much sense.

Another is to have a monitor(Pid) function in the API that calls the SDK. Reason I don't like that is it has to lookup what SDK is being used.

This is not so clear to me but I'm not very familiar with the internals

[albertored]

Can't you update the pid when set_current_span is called?