Discourse Logging Improvements

Feature
,
1

Discourse ships with Logster a component that allows us to view logs in the /logs route.

It gathers server side errors and client side errors and logs them in redis.

###Current Issues

  • The fact we ship with this component is a “secret”, we do not surface any information in our admin screens
  • We have no way of sharing errors (between team members or publicly) Done
  • We have no way of clearing the error log Done
  • There is no mechanism for collapsing similar errors

The above heavily limits the usefulness of logster in production.

This week @riking will be working on improving Logster, I wanted to lay out the work that I would like done.

If anyone else wants to work on any of the bits here, please reply here so there is no overlap.

###Minor/Polish issues
Search is case-sensitive, which is annoying.
The interface looks very bad - some icons or images would help

###Suppressing error messages
Some errors are way too noisy. Logster already has a way to suppress errors (we do this for 404s already), but we want a way to add to the list from the web.

###Sharing error messages (Done)

We need a simple way to share errors between team members, this work should compose of 2 distinct pieces.

  1. Allow users to “protect” and “unprotect” an error. Out-of-the-box logster will only log the 1000 most recent incidents in redis, we need a way to ensure that an error is never removed so you don’t share dead links.

  2. Add an endpoint for sharing error messages. /logs/message/MESSAGE_GUID. This URL should share all the information about the error (backtrace, info, env). This is not meant for public consumption only as a link to share between admins.

  3. Add a little link at the bottom to view error as text so people can copy paste error info, do not worry about sanitizing for the first go. People will have to do that manually.

###Expose top errors in the dashboard

We need a simple way to expose the current hot problems and teach people about logster’s existence.

  1. Add two new sections to /admin

    • Top server errors today, this week (more link links to logster)
    • Top client errors today, this week

  2. You will need to do some work in https://github.com/discourse/logster/blob/master/lib/logster/redis_store.rb to handle deduping and aggregating.

Add a clear errors button (Done*)

Not much to say here, except that you need a “are you sure?” for this as it needs some friction. It would also be nice to have a delete button for any single error, in case you want to just remove it.

Add a “collapsed” mode to logster UI

At the moment if you get the same error 1000 times we log 1000 rows, it makes it very hard to tell which errors are extra problematic and which not. Instead there should be a “production mode” that does its best to aggregate rows. Instead of displaying the same row, over and over again, show the count and first error. (you may allow people to iterate through the various instances of the error if you wish.

Tips:

  • Logster was built with TDD, be sure to work through the server model first, run bundle exec guard to execute the tests. A solid object model will make changing the client trivial.

  • Logster ships with lodash,ember,handlebars,moment … use them

  • Logster is very light weight rack application, it ships with its own asset pipeline.

  • To report server side errors use Rails.logger.warn (or info or debug etc)

  • To report client side errors use window.onerror …

4 Likes
2

I do not agree with “expose top errors” for V1. Provide a link to detail logs somewhere reasonable, sure, but I am not sure we want that much visibility to error logs, it kind of feels like “you as an admin are now also responsible for helping us to debug Discourse” when all they want to do is run their discussions.

If people want to do that, fine, but do not force it into their to do list. Outside of hopefully rare troubleshooting you shouldn’t need to be going here that much, it is like having a “top 3 injuries that sent you to the hospital” page. Ummm… yay?

1 Like
3

My reasoning is that I want us to fix issues that crop up. If we bury our logs too much nobody can tell anything is wrong. I understand your concern though. My amendment then would be

  1. Make those dashboard sections optional, default off, we can enable them on meta for ourselves.
  2. Regardless, add a link to logs on the “Logs” page somewhere, even as a magic tab that just links you there (after Screened URL)
  3. If error count is unreasonably high, warn about it, same as we warn about when sidekiq has a huge backlog.
2 Likes
4

2 Likes
5

I’d also like us to migrate this Ember application to use ember-cli as currently it’s using constants which has been deprecated in the ember community.

Also conceivably the front end of Logster could be used for non-ruby apps if the server side API worked? That would be awesome!

2 Likes