Where Do Logs Fit in Our Observability Toolbox?

As engineers, it’s our jobs to build applications and features… not to deal with support tickets and passive aggressive tweets from our users. Additionally, it’s unreliable to assume our users will send these issues to us. Errors could go unnoticed for months, resulting in users getting frustrated with your application and eventually turning to a competitor instead.

The bad news: we’re never going to write flawless code (written before AI has replaced us all… but we’ll probably have bugs in those, too). The good news: there are tools designed to help with this. Logs help us answer the question “What happened?”, but how should we be alerted and shown these details?

As you’ll see in our video, I have configured Sentry into a simple ReactJS application. We’ve designed integrating Sentry with your app to be a very simple process. “Process” is really even too strong of a word, since you can get our SDK up and running in your application’s runtime with just two or three lines of code.

First I need to load Raven.js directly from our CDN.This script tag should be included after other libraries are loaded, but before your main application code:

<script
  src="https://cdn.ravenjs.com/3.22.2/raven.min.js"
  crossorigin="anonymous"
></script>

I have configured Raven.js to use my Sentry DSN like so:

Raven.config('https://<my_dsn>@sentry.io/<my_project_id>', {
  release: '%REACT_APP_RELEASE%',
}).install();

As you can see I am using our releases feature to include additional context for my issues. There are many features that can be added to Sentry (check out our documentation for details), but the basic format is:

'{PROTOCOL}://{PUBLIC_KEY}:{SECRET_KEY}@{HOST}/{PATH}{PROJECT_ID}';

I have also added a breadcrumb to my application that will record when people press our “Click here for fun! 🎉” button.

makeBreadcrumb() {
  Raven.captureBreadcrumb({
    message: 'Dropped a breadcrumb!',
    category: 'action',
    level: 'info',
    data: {
      version: '1.0',
      note: 'Clicked the fun (obvious breadcrumb) button'
    }
  });
  alert("That was fun! 🎉");
}

I have also added context- this will allow me capture and identify the user affected by this bug ig they have entered their email:

handleSubmit(event) {
  var email = this.state.email;
  this.setState({ submitted_email: email });
  Raven.setUserContext({email});
}

Now that I’ve installed and configured Sentry, added context (user’s email), and a breadcrumb (when they click our “fun” button) , Sentry is ready to start tracking and alerting any errors within my application. Of course, this application is built to throw errors, and it therefore not the most realistic application. However, it shows us a great example of why we can’t rely on our users to report errors. To a user, this application appears to be running smoothly. Without an error tracking and reporting tool like Sentry, we would have to sift through our logs for context, identify the issue, fix the issue, and set an alert to notify us if it occurs again (if we notice a spike/dip on a metrics or if a user reports an issue, that is).

Additionally, if we wanted even more insight into our application, Sentry has data forwarding features that allow us to send processed data to any business intelligence tools we may be using. For example, if I’m using Splunk, I can automatically forward all new events into my Splunk instance. Adding this feature helps us make meaning out of the data we are getting from Sentry, allowing us to have advanced analytics, helping us surface trends and meaning from our data. You can check out our documentation for more details and additional integrations with Amazon SQS as well as Segment.

With Sentry, we’re able to take time to resolution from 5 hours to 5 minutes. While error tracking is part of this, the real value lies in not knowing something’s wrong, but what’s wrong. Specific errors are sorted into an issue that contains every instance of that error, displaying further information that shows how many times the error has occurred and in which browsers and operating systems it’s been seen. This is where our logs become invaluable. Instead of playing detective, Sentry brings us all the clues to help crack the case, resulting in a lot less

So…. should you get rid of your logs? Are they useless? NO! Logs are great! Logs help solve the mysteries of our code and help us dive into user behavior. So using an error tracking tool is essential to having your logs be used to their full potential. So yes, you need logs… but it’s not the only tool you should be using to have a full view of your application’s health. By using a tool like Sentry along with our logs and metrics, we’re not only able to know what’s going on much faster, but we’re able to put out fires faster. In other words, using the right tools for the job is key.