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

Print trace id to console and possible URL with the zipkin trace #7313

Merged

Conversation

Projects
None yet
6 participants
@cattibrie
Copy link
Contributor

commented Mar 5, 2019

Problem

It is not obvious for the user how to find the zipkin trace after a pants run.

Solution

One of the solutions is to print zipkin trace in the console.
The better one could be to print a link to the Zipkin API with the trace. But endpoints to send spans to Zipkin API and to view the resulting trace may be different. The set up is not unique.
One of the solutions is to have two flags:
--reporter-zipkin-send-endpoint and
--reporter-zipkin-view-endpoint
Current implementation suggests a link that can point to the current zipkin trace.

I would be grateful for your comments in regard to it

endpoint = self.endpoint.replace("/api/v1/spans", "")

logger.info("Zipkin trace ID {}".format(self.trace_id))
logger.info("Zipkin trace may be located at this URL {}/traces/{}".format(endpoint, self.trace_id))

This comment has been minimized.

Copy link
@illicitonion

illicitonion Mar 5, 2019

Contributor

Let's only log this line, not the one above, and let's maybe log at debug rather than info level, as this is information most people won't want most of the time, but may want to see when they're specifically trying to debug :)

This comment has been minimized.

Copy link
@cosmicexplorer

cosmicexplorer Mar 5, 2019

Contributor

^This is what we do with buildstats internally (print a log at debug level), and we only print a warning if we can't connect to the buildstats server to upload.

This comment has been minimized.

Copy link
@stuhood

stuhood Mar 5, 2019

Member

IMO: in v1, it should be shown all the time as long as the run isn't --quiet.

Rather than the buildstats model (or maybe in-addition-to?), another model that might be useful would be the ./pants server model. If the pants server is running, you see:
see-a-report-at

This comment has been minimized.

Copy link
@stuhood

stuhood Mar 5, 2019

Member

So, concretely: yes... maybe this particular message should be at debug level.

But finding where the See a report at ... message and logging there the same way it logs would be useful.

This comment has been minimized.

Copy link
@illicitonion

illicitonion Mar 6, 2019

Contributor

I'm going to merge for now; I'm not sure concretely what the follow-up you're asking for here is (is it unconditionally logging in a second place?), but we can treat it as a follow-up :)

This comment has been minimized.

Copy link
@stuhood

stuhood Mar 6, 2019

Member

(is it unconditionally logging in a second place?)

Yes. See the "See a report at:" message in the screenshot.

@ity

ity approved these changes Mar 5, 2019

@illicitonion illicitonion merged commit 304691b into pantsbuild:master Mar 6, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.