187 Exception notifications [0.5d]

When an application raises an error in production, we want to know about it. This lesson covers how we get notified about exceptions and how tools like Sentry keep the noise down.

Important

Work on this lesson in advisor mode.

Learning goals

• You can explain why an application must report its errors somewhere, and what happens to an exception in production when nobody is notified.
• You can explain how our teams handle incoming exception notifications, and who reacts to them.
• You can integrate exception notification into a Rails app and verify it by triggering an error.
• You can explain what an error-monitoring service like Sentry adds over plain e-mails: grouping similar errors, staying quiet until an error is resolved, deduplicating across servers, and deferring notifications for flaky endpoints.

Resources

Read what's new to you, skim what's familiar, skip what you already master. Stop when you can meet the learning goals.

Your agent can also generate an overview, a tutorial or an explanation for anything here, tailored to what you already know. Just ask.

• 📄 How we deal with e-mails in the fail mailbox — our process for incoming exception notifications
• 📄 Get notified when your application raises an error — our card on integrating exception notification
• 📄 exception_notification Show archive.org snapshot — the gem's README
• 📄 Sentry for Rails Show archive.org snapshot — the official setup guide
• 📄 Controlling issue grouping in Sentry and deferring notifications for an issue — our cards on what Sentry adds over plain e-mails

Exercises

• Understand how we're dealing with exception notifications.
• Integrate exception notification into your MovieDB. Use your personal e-mail as the notification target for now. You can omit any references to sidekiq for now.
• Trigger an error in MovieDB and receive the notification.
• Ask a colleague to show you how their SWAT teams deals with exception notifications.
• Ask a colleague to show you Sentry Show archive.org snapshot , which is a tool we use on apps with non-trivial traffic. Understand the advantages this gives you:
  • aggregating similar errors
  • not getting additional e-mails until an error is resolved
  • not getting the same e-mail from different appservers of the same application
  • not getting e-mails for flaky API endpoints