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

fix: don't log host functions by default #5911

Merged
merged 2 commits into from
Dec 21, 2021

Conversation

matklad
Copy link
Contributor

@matklad matklad commented Dec 20, 2021

We received feedback that near_vm_runner produces too much output couple
of times. At the same time, there was once instance where having a log
line for something as trivial read_register was useful.

So, let's downgrade the logging here to trace for now, and maybe revisit
in the future when we have a clearer understanding of which amount of
logs is acceptable.

We received feedback that near_vm_runner produces too much output couple
of times. At the same time, there was once instance where having a log
line for something as trivial `read_register` was useful.

So, let's downgrade the logging here to trace for now, and maybe revisit
in the future when we have a clearer understanding of which amount of
logs is acceptable.
@matklad matklad requested a review from olonho as a code owner December 20, 2021 15:05
@matklad matklad requested a review from nagisa as a code owner December 21, 2021 12:04
Copy link
Collaborator

@nagisa nagisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change made here would suggest to me that we are logging span entries and exits. Ability to do so to the best of my knowledge is really intended to be a debugging tool for people implementing subscribers or similar parts of the tracing ecosystem, and probably should not be left enabled in a production system as is.

The primary reason is indeed just how spammy it is (and formatting all those messages can't possibly be very cheap). Mitigating the amount of messages the way is done here, however, has a downside that the alternative subscribers, which natively understand spans, will no longer receive them, either. In my view the spans should generally remain at info! level so that tools like opentelemetry collector can actually take advantage of the data that's available to them.

If we absolutely must output some information about span durations to the standard output alongside other log messages, I would probably approach this from the angle of implementing a subscriber which consumes spans of the form:

info_span!(..., span_logger.warn_deadline = 10ms)

and outputs a single message if the span did indeed exceed the specified duration.

Alternatively I would investigate our ability to utilize ecosystem tooling which natively understands tracing data such as opentelemetry+jaeger so that we don't need to try and coerce logs into a trace system.

Copy link
Collaborator

@nagisa nagisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, I believe this discussion should be held more widely than just within the runtime team and so I'm fine with this landing as a temporary measure, but we should definitely keep in mind reverting this when we have some real tracing infrastructure in place.

@near-bulldozer near-bulldozer bot merged commit c527d96 into near:master Dec 21, 2021
@matklad matklad deleted the m/trace-host branch December 21, 2021 13:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants