Even though you tested your application perfectly errors and bugs will still happen in production, especially if other services or databases go down or are under high load. Thus it is very important to see errors happing and to be able to react to them quickly. In this talk I’ll introduce you to efficient ways for monitoring and logging for errors and show how you can handle them if they happen, covering deployment strategies, using intelligent circuit breakers and gracefully reducing functionality.

Comments

Comments are closed.

Great talk 'just what I needed'

Christiaan Bye at 11:42 on 28 Jan 2017

Excellent talk with great real world examples! I particularly liked how you filled in some saved time with a quick demo of Kibana

Hans Stevens at 13:34 on 28 Jan 2017

Excellent talk!

Thijs at 14:01 on 28 Jan 2017

Good talk, nice examples. Could be a tad faster every now and than! Thank you

Iamabot at 14:37 on 28 Jan 2017

Amazing talk. Interesting topic. Good real life examples. Wish I had seen this one years ago.

Interesting and very informative talk covering a wide range of techniques to be graceful with errors! Could be a bit shorter because circuit breakers were interesting topic to hear, but rushed.

Jeroen de Jong at 17:12 on 28 Jan 2017

Well given talk with nice real world examples. You sometimes talk a bit fast, so that might be a small thing to improve.

Great talk. Easy to follow examples that trigger me to try at least some of these techniques/work-flows myself.

You have a pleasant style of presenting, sure hope you will be back next year!

Very well presented talk with brillant information.

Like your other talk, this one was well brought. Even though this was the first talk in the morning, after the social, you kept me awake. :) Thank you!

Muhammed at 22:46 on 29 Jan 2017

The examples and arguments where really helping to understand how to use logging.

Great talk, easy to understand and with practical actual examples.

I'd just like to add one extra tip regarding the X-Trace-Id: You could go one step further by carrying it across all internal service calls and have all logs related to a single external request searchable at once. (you could even get your SQL wrapper/ORM to add it as a comment to your queries if you log them at db level using the audit plugin for example, we have a setup similar to yours and we try to stuff that information everywhere we can)

@Renaud Drousies very good points. Thanks for your feedback. We are actually transporting the Trace-Id to all internal services, include it in all logs and of course have these ids then also available in Elasticsearch to search it over all logs from all services there. I thought I also mentioned that during the talk, but I'll try to make it clearer in the future.
We are actually also including the trace id as comments in db queries like you do. I'll add this to the talk in the future.