Filtering Internal Event Spans

[CagriYonca]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[GSVarsha]

Hey @CagriYonca, the overall structure looks good to me!
But can you explain the significance of this block? Its a bit unclear to me

[CagriYonca]

I've included this block in case the customer wants to see internal spans.

[GSVarsha]

I think we aren't supposed to refer this as INTERNAL spans because that could mean the concept of INTERMEDIATE (neither ENTRY nor EXIT but useful/ interesting internal application code) spans. After some contemplating, I remember something that we discussed earlier about whether we should not capture those internal tracer calls at all (existing code) or capture these urllib3/ requests calls to the agent and filter later (this new code).

Although the latter looks more structured I think functionality-wise the earlier could be better because we might try to communicate to the agent multiple times and creating a span each time might be expensive and not something the end-user would be interested (to view with an env var like INSTANA_ALLOW_INTERNAL_SPANS ).

I would like to know the team's thoughts on this, TIA!

[pvital]

I agree with Varsha that earlier filtering would improve performance by eliminating this specific type of span. However, the task is clear when requested to use the new span filtering feature, and we already have a rejected PR that proposed not collecting these spans earlier.

That said, let's keep this PR but:

1. remove this environment variable checking - users don't need to know about these spans, and
2. substitute the add_internal_span_filter() method name with _add_instana_agent_span_filter().