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

Record tags inconditionally at server receive #144

Merged
merged 3 commits into from
Mar 30, 2019

Conversation

jcarres-mdsol
Copy link
Collaborator

This removes the possibility of constraining the tags recorded at server receive. It was always half-baked and pretty useless.

We originally created the feature of optionally setting tags in server because:

  • UI bugs
  • Being cheap with storage

I do not think any of these hold anymore.

Also, by our own experience using zipkin more often than not we want more info not less.

This PR also adds status_code and method alongside the path info to server spans so that info is available when for some reason the client spans do not have it.

@adriancole @ykitamura-mdsol @jfeltesse-mdsol

@@ -39,8 +39,6 @@ def initialize(app, config_hash)
if @sampled_as_boolean
@logger && @logger.warn("Using a boolean in the Sampled header is deprecated. Consider setting sampled_as_boolean to false")
end
# Record the given tags on server receive, even if the zipkin headers were present in the incoming request?
@record_on_server_receive = parse_tags(config[:record_on_server_receive])
Copy link
Contributor

Choose a reason for hiding this comment

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

tags.each { |annotation_key, env_key| span.record_tag(annotation_key, zipkin_env.env[env_key]) }
def trace_server_information(span, zipkin_env, status)
span.kind = Trace::Span::Kind::SERVER
span.record_tag(Trace::Span::Tag::STATUS, status)
Copy link
Member

Choose a reason for hiding this comment

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

you can consider doubling this as error so the span appears red

ex from java

    // 1xx, 2xx, and 3xx codes are not all valid, but the math is good enough vs drift and opinion
    // about individual codes in the range.
    if (httpStatusInt < 100 || httpStatusInt > 399) {
      customizer.tag("error", String.valueOf(httpStatusInt));
    }

Copy link
Contributor

Choose a reason for hiding this comment

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

Here is how we are doing it in client spans:

span.record_tag(Trace::Span::Tag::ERROR, status) if STATUS_ERROR_REGEXP.match(status)

Maybe we can have a method like this in the Span class:

    STATUS_ERROR_REGEXP = /\A(4.*|5.*)\z/.freeze

    def record_status(status)
      record_tag(Tag::STATUS, status)
      record_tag(Tag::ERROR, status) if STATUS_ERROR_REGEXP.match(status)
    end

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Mar 30, 2019 via email

@jcarres-mdsol jcarres-mdsol merged commit 717afa5 into master Mar 30, 2019
@jcarres-mdsol jcarres-mdsol deleted the feature/all_server_tags branch March 30, 2019 05:27
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.

3 participants