Front-end error logging and monitoring can improve application stability. Help programmers respond to user feedback in a timely manner: identify problems early and solve them.

When a user encounters a program exception, the program reports an error message (that is, logs are collected and reported) and notifies the responsible person (that is, alarms) by SMS. The responsible person analyzes the reported error information to locate the problem.

When we talk about logs, we usually mean the collection, reporting, and analysis of logs. When we talk about monitoring, we usually refer to log displays and alarms.

This article mainly introduces the main functions of error log and monitoring: error log data collection, storage, reporting, analysis, display, and error information alarm. Let’s look at one function at a time.

Error log collection

Collecting error logs consists of two steps:

  1. Catch front-end exceptions
  2. Record details about exceptions.

Catch front-end exceptions

Front-end exceptions to catch include:

  • Actively catch runtime exceptions. withtry-catchTo deal with.
  • Handle unexpected global runtime exceptions. towindows 绑 errorEvent to handle.
  • Exception in unhandled asynchrony. towindows 绑 unhandledrejectionEvent to handle.
  • An interface error occurred. Procedure
  • Vue, React exception.

To learn more, read: Summary of Handling front-end Exceptions.

Record details about exceptions

Detailed exception information can help us better locate errors. The recording content follows the 4W principle:

WHO did WHAT and get WHICH exception in WHICH environment?

User information (WHO) User information when an exception occurs, including the status and rights of the user.

Did What An exception occurred when the user performed an operation. It is best to record a video of the user making a mistake. Recording with lots of screenshots is poor performance. A better solution would be to record the sequence of operations (user behavior, DOM changes) and run the sequence again during replay. For details, see the following article:

  • Rrweb: open the web page to record and playback of the black box “: zhuanlan.zhihu.com/p/60639266
  • How should a Web page screen? : blog.fundebug.com/2019/08/06/…

The code information of WHICH exception includes: error message, error stack, error file, error source line and column, page URL, DOM element node of user operation, etc.

The environment information includes the mobile phone brand, operating system, browser and version, interface address, and parameter information.

The logging stored

A single exception log cannot help us locate problems quickly. A series of user operations need to be recorded. However, if the user immediately sends the behavior log to the server after each operation, the user’s network resources will be wasted. Therefore, these logs are generally stored locally on the user client. When certain conditions are met, a group of logs are packaged and uploaded at the same time.

Log storage is usually stored using IndexedDB. The log data is large. IndexedDB is large in size, supports partial relational database functions (branches, tables, indexes, etc.), and supports asynchrony. The asynchronous nature ensures that it does not block the rendering of the interface.

Recommended reading: Creating front-end Offline Logs (1): IndexedDB: juejin.cn/post/684490…

The log report

Log reporting You need to design interfaces to upload exception logs. I’m not going to expand it here.

There are two types of log reporting timing: instant reporting and batch reporting.

Real-time reporting

Serious exceptions are reported immediately. Considering the network instability, a confirmation mechanism is required for reporting serious exceptions. The report is complete only after the server has successfully received the information. Otherwise, a loop mechanism is required to ensure successful reporting.

The batch report

Non-serious exceptions are reported in batches. The batch upload time can be a certain number of logs or a certain interval.

When transferring batch data, a large amount of data must be generated. Therefore, the reported data must be compressed. Compression can be done using lZ-string. Lz-string is a very good string compression class library, good compatibility, less code, high compression ratio, short compression time, compression rate up to an amazing 60%.

Log analysis and display

The core of log analysis and presentation is data visualization: the conversion of collected data into comprehensible metrics. According to different usage scenarios, design appropriate display methods: tables, discount charts, pie charts and so on. Recommend a website to help you choose the right chart: Tuzhidian.com/.

Log analysis also considers query performance. After all, log data can accumulate over a long period of time. I’m not going to expand it.

The alarm

An alarm is a notification to the relevant personnel when an error occurs. The configuration rules are as follows:

  • Trigger rules. Trigger when any conditions are met. Conditions include the severity level of the exception, content contained in the exception, and the alarm to which the alarm is generated.
  • Push channels. Such as: SMS, phone, email, enterprise wechat, nail nail and other ways.
  • Push frequency. For example, if a major alarm is generated, the alarm is periodically pushed within 10 minutes until the alarm is manually disabled. If it’s not serious, send it once.
  • Post action. An alarm is automatically triggered. For example: build Bug work order automatically.

conclusion

Front-end error logging and monitoring are effective ways to improve application stability. Front-end error log and monitoring system mainly includes: error log collection, storage, reporting, analysis, display, and error information alarm.

Developing a front-end error logging and monitoring system requires a lot of work. You can access some third-party logging and monitoring tools:

  • Sentry: professional application error monitoring platform. You can deploy it yourself.
  • FunDebug: a professional application error monitoring platform in China.
  • Bad.js: Excellent open source solution of front-end monitoring in China.
  • Grafana: Open source visualization panel. Configure data sources, set display rules, can generate charts (tables, line charts, thermal maps, etc.). You can also configure alarms.

Reference documentation

  • “Front-end Anomaly Monitoring Solution Research – Tencent CDC” : juejin.cn/post/684490…
  • Creating front-end Offline Logs (1): IndexedDB: juejin.cn/post/684490…