Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's INTERNAL span kind and when it should be used #4179

Open
lmolkova opened this issue Aug 6, 2024 · 2 comments
Open

What's INTERNAL span kind and when it should be used #4179

lmolkova opened this issue Aug 6, 2024 · 2 comments
Labels

Comments

@lmolkova
Copy link
Contributor

lmolkova commented Aug 6, 2024

See #4178 for the context.

Internal kind is defined as

* `INTERNAL` Default value. Indicates that the span represents an
internal operation within an application, as opposed to an
operations with remote parents or children.

Presumably it means that span cannot have remote parents and remote children.

Based on discissions referenced in #4178, #110, #526:

  • instrumentations don't know if underlying layer is instrumented. Underlying layer may be instrumented, not enabled, or conditionally suppressed (still propagating current context)
  • there are multiple nested layers of physical operations (e.g. HTTP -> DNS) and lower layers don't usually support context propagation
  • there are protocols that don't support context propagation (yet)
  • there are multiple layers that each support context propagation (e.g. messaging + CloudEvents over HTTP could carry 3 different contexts at the same time)

I.e. there is no reliably way to know whether something will have remote children (or any descendants). It depends on application, enabled instrumentations, potentially interchangeable protocols.

INTERNAL vs SERVER is also controversial. Imagine a cron-job (e.g. FaaS time trigger) - it never has a parent, should it be Internal?

The existing status-quo:

  • the boundary between INTERNAL and CLIENT or SERVER in the spec is unclear.
  • semantic conventions that describe logical operations (DB, messaging, LLM) document the kind
@lmolkova lmolkova added the spec:trace Related to the specification/trace directory label Aug 6, 2024
@lmolkova
Copy link
Contributor Author

lmolkova commented Aug 6, 2024

Proposal:

keep the status quo - clarify INTERNAL description:

  • it should be used for strictly local operations (that are not expected to involve network calls)
  • it could be used in other cases when other kinds don't apply and should not be used when another kind applies
  • semantic conventions should document span kind

Alternatives:

  • ?

@austinlparker
Copy link
Member

INTERNAL vs SERVER is also controversial. Imagine a cron-job (e.g. FaaS time trigger) - it never has a parent, should it be Internal?

Well, depends on where you're modeling from. The trigger would be the client, and the function would be the server.

lmolkova added a commit that referenced this issue Sep 3, 2024
Fixes #3172

(Built on top of #4088)

## Changes

- Explains kinds without assuming presence of parent/children 
- Adds links as another correlation mechanism
- Normalizes nested client spans even further - database, messaging,
RPC, and LLM semantic conventions require CLIENT kind for logical client
operation.
- Does not touch INTERNAL kind yet -
#4179

* [x] Related issues #3172,
open-telemetry/semantic-conventions#674,
open-telemetry/oteps#172,
open-telemetry/semantic-conventions#1315
* ~~[ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) #~~
* ~~[ ] Links to the prototypes (when adding or changing features)~~
* [x]
[`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md)
file updated for non-trivial changes
* ~~[ ]
[`spec-compliance-matrix.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md)
updated if necessary~~

---------

Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants