Skip to content

Add logging solution for both front and back end  #69

Description

@ludwigmuench

Motivation

I think this would be great for monitoring apps and finding / understanding bugs throughout the full stack on a live production server.

Requested Feature

It would be useful if we could log errors and other events from both the front and the back end.

Example (frontend):

    try {
      foo()
    } catch (e) {
      // handle error
      logger.log({
        error: e,
        description: 'something something failed when something',
        //...
       })
    }

The logger on the frontend would have to send logged events to the back end with http requests. On the back end all logged events would have to be persisted.

Now even though the error was handled, we could use the logging solution to show us all logged events (of both the front and back end) during a specified time frame and filter for certain keywords.

Monitoring Solutions

Solution Pros Cons
custom solution good labs project?
rails-client-logger ? not maintained
Elastic APM we've used it before can be a lot of work to set up ELK
Prometheus
Airbrake React Integration we've used it before (Rails only)

Activity

  1. chrisgbaker commented on Dec 5, 2019

    @chrisgbaker
    Contributor

    This looks very similar to what I've used before w/ C#/React projects, but this was a very high level scan of the site: https://www.loggly.com/blog/best-practices-for-client-side-logging-and-error-handling-in-react/

    Basically, whatever server-side option we choose, we just need an endpoint and a typescript contract for the frontend to make sure the shape of the messages we are sending is correct.

    window.onerror = function() {
      logger.logError({...})
    };
    

    can catch super global, nebulous errors. There is also a function you can use for uncaught/unhandled promise-based errors that is super helpful for this

    window.addEventListener('unhandledrejection', event => ···);
    

    Outside of that, we would just need to make sure that errors are being appropriately handled/logged inside of the catch { } blocks, and .catch() chains.

    I've gone back and forth on this, but even if we catch an error and know what to do with it, there could be some value in logging it anyways, to keep an eye on those as well. Though, these could be logged with a level of logLevel.WARNING

  2. dkniffin commented on Dec 6, 2019

    @dkniffin
    Contributor

    Another option along these same lines is to use Airbrake. We already have an account and use it on the backend, though I'm not sure if anyone other than me knows that. There's a React version, but I don't think we've tried it before.

  3. ludwigmuench commented on Dec 6, 2019

    @ludwigmuench
    ContributorAuthor

    Nice, I've added it to the list.

  4. woolsox commented on Dec 6, 2019

    @woolsox
    Contributor

    @dkniffin @ludwigmuench seconded, Airbrake is a breeze and it works wonders.

  5. ludwigmuench commented on Dec 6, 2019

    @ludwigmuench
    ContributorAuthor

    @chrisgbaker @dkniffin @woolsox Great! If Airbrake already works well for us on the backend, we should evaluate its React integration before considering alternatives imo. If anyone wants to pair on it, lmk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions