Conversation
CagriYonca
force-pushed
the
internal-spans
branch
2 times, most recently
from
36fd507 to
a06c130
Compare
…tering mechanism Signed-off-by: Cagri Yonca <cagri@ibm.com>
CagriYonca
force-pushed
the
internal-spans
branch
from
a06c130 to
1256757
Compare
|
| if "INSTANA_ALLOW_INTERNAL_SPANS" not in os.environ: | ||
| self.add_internal_span_filter() |
There was a problem hiding this comment.
Hey @CagriYonca, the overall structure looks good to me!
But can you explain the significance of this block? Its a bit unclear to me
There was a problem hiding this comment.
I've included this block in case the customer wants to see internal spans.
There was a problem hiding this comment.
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!
2 participants
No description provided.