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

Collect http_response_code for successfull and failed requests #1375

Merged
merged 1 commit into from Mar 13, 2021

Conversation

velo
Copy link
Member

@velo velo commented Mar 12, 2021

On previous implementation response code would only be collected for errors.

To avoid mixing new and old metrics, gave the one that includes successfull codes a different name

On previous implementation response code would only be collected for errors.

To avoid mixing new and old metrics, gave the one that includes successfull codes a different name
@velo velo requested a review from kdavisk6 March 12, 2021 04:20
Copy link
Member

@kdavisk6 kdavisk6 left a comment

Choose a reason for hiding this comment

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

@velo

Should we consider using Timers instead of Counters? Timer implicitly count and can provide more information. Thoughts?

@kdavisk6 kdavisk6 added the feedback provided Feedback has been provided to the author label Mar 12, 2021
@velo
Copy link
Member Author

velo commented Mar 12, 2021 via email

@kdavisk6
Copy link
Member

kdavisk6 commented Mar 12, 2021

Ahh, but with Micrometer you can.

long start = System.nanoTime();  // record the start time.
Response response = client.execute(Request); // execute the request
registry.timer(metric.name).tag(getTags(response)).record(System.nanoTime() - start, TimeUnit.NANOSECONDS) // create a new timer with the time calculated and use getTags() to read the response and set the Success or Failure

This way, you can include a tag that indicates if the request was successful or not. You can use this tag in your metrics system to calculate success and failure rates, without needed a separate counter. Not sure how to do it with Dropwizard.

@velo
Copy link
Member Author

velo commented Mar 13, 2021

Ahh, but with Micrometer you can.

long start = System.nanoTime();  // record the start time.
Response response = client.execute(Request); // execute the request
registry.timer(metric.name).tag(getTags(response)).record(System.nanoTime() - start, TimeUnit.NANOSECONDS) // create a new timer with the time calculated and use getTags() to read the response and set the Success or Failure

This way, you can include a tag that indicates if the request was successful or not. You can use this tag in your metrics system to calculate success and failure rates, without needed a separate counter. Not sure how to do it with Dropwizard.

Yeah, you can do "exactly" the same on dropwizard metrics.... but ...

      return meterRegistry.timer().recordCallable(() -> {...});

Looks much better than

long start = System.nanoTime();
try {
   Response response = delegate.execute();
   meterRegistry.timer( tag(response.getStatus()) ).record(System.nanoTime() - start, TimeUnit.NANOSECONDS);
   return response;
} catch (FeignException e) {
   meterRegistry.timer( tag(e.getStatus()) ).record(System.nanoTime() - start, TimeUnit.NANOSECONDS);
   throw e;
}

Also, if something outside FeignException happens, you won't get neither the timer nor the status code.

Do you have any specific use case for this or just an improvement?

@velo
Copy link
Member Author

velo commented Mar 13, 2021

@kdavisk6 also, do you mind if I merge as is, kick an release and if need be we rework this later?!

Cheers,

@kdavisk6
Copy link
Member

Could refactor with a try/finally instead. Sounds like you need this for something you are working on. I’ll approve and think on it some more.

@kdavisk6 kdavisk6 merged commit fe901ca into master Mar 13, 2021
@kdavisk6 kdavisk6 deleted the http_status_metrics branch March 13, 2021 21:15
@velo
Copy link
Member Author

velo commented Mar 13, 2021

Awesome, thanks @kdavisk6

I will make a new release for this...

shall we go with 11.1 (as I see people using 11.0 out there, or 10.x?

@kdavisk6
Copy link
Member

Yeah. Might as well fix the 11.x problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback provided Feedback has been provided to the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants