Error-logging for javascript on client side

前端 未结 7 1901
走了就别回头了
走了就别回头了 2020-12-08 01:02

My project which contains a lot of pages with forms. This is a backend of banking CRM system, so any error during working process is to be captured and investigated. On the

7条回答
  •  情深已故
    2020-12-08 01:35

    Disclaimer: I'm CEO and creator of Sentry, an open source and paid service which does crash reporting for many languages, including Javascript.

    It can be pretty challenging to capture frontend exceptions. Technology has gotten better (browser JS engines), but there's still a lot of limitations.

    1. You're going to need a server-side logging endpoint. This has a few complexities as it's possible to abuse it (i.e. PEN testers may try to expose vulnerabilities in it). You also need to deal with CORS here. I'd obviously recommend Sentry for this, as we're best in class, and if you want you can host the server yourself (as its open source).
    2. The implementation of actually capturing the errors in your code is pretty complicated. You cant rely on window.onerror for various reasons (mostly because browsers historically give bad information here). What we do in the raven.js client (which is based on TraceKit) is patch a number of functions to wrap them in try/catch statements. For example, window.setTimeout. With this we're able to install error handlers that will generate full stacktraces in most browsers.
    3. You'll want to ensure you're generating sourcemaps for your code, and that the server handling the data supports them. Sentry does this both by scraping them automatically (via the standards) or allowing you to upload them via an API. Without this, assuming you're minifying code, things become almost unusable.
    4. The last major issue is noise. Most browser extensions will inject directly into your scripts so you need to filter out the noise. We solve this in two ways: a blacklist of patterns to ignore (i.e. "Script error." being the most useless), as well as a whitelist of domains to accept (i.e. "example.com"). We've found the combination of the two being effective-enough at removing most random noise.

    Some things you should be aware of on the server:

    • Clients will sometimes persist open (i.e. a bot, or a bad user) and cause large amounts of useless data or simple old errors.
    • Your server should be able to handle a cascade of these events and fail gracefully. Sentry does this by rate limiting things and sampling data.
    • Exceptions are localized into the browser language, and without a centralized database you will be stuck translating them yourself (though its generally obvious what they mean).

提交回复
热议问题