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

Guidelines to prevent excessive logging is confusing #3147

Closed
alanwest opened this issue Jan 25, 2023 · 1 comment · Fixed by #3151
Closed

Guidelines to prevent excessive logging is confusing #3147

alanwest opened this issue Jan 25, 2023 · 1 comment · Fixed by #3151
Assignees
Labels
area:error-reporting Related to error reporting area:sdk Related to the SDK spec:logs Related to the specification/logs directory spec:trace Related to the specification/trace directory triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal

Comments

@alanwest
Copy link
Member

From the trace spec:

There SHOULD be a log emitted to indicate to the user that an attribute, event,
or link was discarded due to such a limit. To prevent excessive logging, the log
should not be emitted once per span, or per discarded attribute, event, or links.

What is this meant to communicate?

To prevent excessive logging, the log should not be emitted once per span, or per discarded attribute, event, or links.

I want to improve the wording here, though the following are possible interpretations:

  1. Whenever something is dropped or truncated on a span we should only log this for a fraction of the occurrences - e.g. 1 in 10 occurrences.
  2. For a given span, if multiple things are dropped or truncated only log at most once per span.
  3. Something else?

Or is it even important that the spec be prescriptive here? Another option would be to move this to a supplementary guidelines doc like we have for metrics. We could make a general guidelines doc that suggests that care should be taken when logging potentially high-frequency errors/warnings from the SDK.

@alanwest alanwest added the spec:trace Related to the specification/trace directory label Jan 25, 2023
@tigrannajaryan tigrannajaryan added the triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal label Jan 27, 2023
@tigrannajaryan
Copy link
Member

@alanwest will you be able to make a PR for this?

@tigrannajaryan tigrannajaryan added the spec:logs Related to the specification/logs directory label Jan 27, 2023
@tigrannajaryan tigrannajaryan assigned alanwest and unassigned arminru Jan 27, 2023
@arminru arminru added area:sdk Related to the SDK area:error-reporting Related to error reporting labels Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:error-reporting Related to error reporting area:sdk Related to the SDK spec:logs Related to the specification/logs directory spec:trace Related to the specification/trace directory triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants