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

Span link and event count limits should have corresponding environment variables #1750

Closed
codeboten opened this issue Jun 9, 2021 · 4 comments · Fixed by #1751
Closed

Span link and event count limits should have corresponding environment variables #1750

codeboten opened this issue Jun 9, 2021 · 4 comments · Fixed by #1751
Assignees
Labels
area:sdk Related to the SDK spec:trace Related to the specification/trace directory

Comments

@codeboten
Copy link
Contributor

What are you trying to achieve?

Environment variables are defined for setting span attribute limits, but not span link and event attribute limits. These should exist to be consistent.

@codeboten codeboten added the spec:trace Related to the specification/trace directory label Jun 9, 2021
@arminru arminru added the area:sdk Related to the SDK label Jun 10, 2021
@carlosalberto
Copy link
Contributor

Personally I'd be up for having all of it in a single environment variable (probably a new one), unless there's a technical reason to really want to have limits per Span/Event/Link.

@ghost
Copy link

ghost commented Jun 10, 2021

I believe that keeping this separated (per span attribute, span link, event) makes certain sense from eg backend processing point of view. Different backends may have certain limitations with eg rendering of operations or connected data, so having these configurable at the agent level may help customers and increase OTEL adoption.

@codeboten
Copy link
Contributor Author

According to the spec we already have different limits: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#span-limits, we just haven't exposed them as environment variables.

@carlosalberto
Copy link
Contributor

Yes, we do. In a perfect world we don't need that much level of detail in the public configuration and a single value should be fine ;) I'm ok with the proposed solution but I'd rather go for the simplest way :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK spec:trace Related to the specification/trace directory
Projects
None yet
3 participants