Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to solve the front-end exception monitoring". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn "how to solve the front-end exception monitoring"!

Front-end monitoring includes behavior monitoring, exception monitoring, performance monitoring and so on. This paper mainly discusses exception monitoring. For the front end, the front end and the back end are in the same monitoring system, the front end has its own monitoring scheme, and the back end also has its own monitoring scheme, but the two are not separated, because if an exception occurs in the process of operation and application of a user, it may be caused by the front end or the back end, so there needs to be a mechanism to connect the front end and the back end so that the monitoring itself is unified in the monitoring system. Therefore, even if we only discuss the front-end exception monitoring, we can not strictly distinguish the front and back end boundaries, but should reflect the help of monitoring to the development and business in the final report according to the design of the actual system.

Generally speaking, a monitoring system can be divided into four stages: log collection, log storage, statistics and analysis, reporting and warning.

Collection phase: collect exception logs, first do some processing locally, and take certain plans to report to the server.

Storage phase: the backend receives the exception log reported by the front end, and after certain processing, it is stored according to a certain storage scheme.

Analysis stage: divided into machine automatic analysis and manual analysis. The machine automatically analyzes, through the preset conditions and algorithms, statistics and screening the stored log information, finds problems, and triggers the alarm. Manual analysis, by providing a visual data panel, so that system users can see the specific log data, according to the information, find the source of abnormal problems.

Alarm stage: divided into alarm and early warning. Alarm according to a certain level of automatic alarm, through the set channels, in accordance with certain trigger rules. The early warning is to predict and give a warning in advance before the occurrence of the anomaly.

1 Front-end exception

Front-end exception refers to the situation in which users can not quickly get the expected results when using Web applications. Different exceptions bring different degrees of consequences, from displeasure to the use of the product, to the loss of recognition of the product.

1.1 Front-end exception classification

According to the degree of consequence of the exception code, the performance of the front-end exception can be divided into the following categories

a. Make a mistake

The content of the interface is not consistent with the content expected by the user, such as clicking to enter the non-target interface, the data is not accurate, the error prompt is incomprehensible, the interface is misplaced, and jump to the wrong interface after submission. When this kind of exception occurs, although the function of the product itself can still be used normally, but the user can not achieve his own goal.

b. Dull

The interface does not respond after the operation, for example, the button cannot be submitted, and the operation cannot be continued after the prompt is successful. When this kind of exception occurs, the product already has the phenomenon of interface-level local unavailability.

c. Damage

The interface can not achieve the purpose of the operation, such as click can not enter the target interface, click can not view the details, and so on. When this kind of exception occurs, some functions of the application can not be used normally.

d. Fake death

The interface is stuttered and cannot use any function. For example, the user is unable to log in and cannot use the functions in the application, and any subsequent operations cannot be done because a mask layer is blocked and cannot be closed. When such an exception occurs, the user is likely to kill the application.

e. Collapse

Applications often exit automatically or fail to operate. For example, intermittent crash, the web page does not load properly or cannot do anything after loading. The continuous occurrence of such anomalies will directly lead to the loss of users and affect the vitality of the product.

1.2 Classification of causes of exception errors

The causes of exceptions in the frontend are mainly divided into five categories:

Reason case frequency logic error 1) business logic judgment condition error

2) incorrect sequence of event binding

3) call stack timing error

4) incorrect manipulation of js objects often with wrong data types 1) treat null as an object to read property

2) traversing undefined as an array

3) the number in the form of string is directly used in addition operation.

4) function parameters are not passed often syntax errors are less than network errors 1) slow

2) the server does not return data but still 200, and the front end traverses the data as normal

3) Network interruption when submitting data

4) when the server side 500 error occurs, the front end does not do any error handling. Occasional system error 1) insufficient memory

2) the disk is full

3) the shell does not support API

4) less incompatibility

2 abnormal collection

2.1 collect content

When an exception occurs, we need to know the specific information of the exception and decide what kind of solution to adopt according to the specific information of the exception. When collecting abnormal information, you can follow the 4W principle:

WHO did WHAT and get WHICH exception in WHICH environment?

a. User information

The information of the user when an exception occurs, such as the user's status and permissions at the current time, and which terminal the exception corresponds to when it is necessary to distinguish which terminal the user can log on to.

b. Behavior information

There is an exception when the user performs any operation: the path of the interface, the operation performed, the data used during the operation, what data the API vomited to the client, what data was submitted if it was a submission operation, the previous path, and the last behavior log record ID, etc.

c. Abnormal information

The code information that generates the exception: the DOM element node operated by the user; the exception level; the exception type; the exception description; the code stack information, etc.

d. Environmental information

Network environment; device model and identification code; operating system version; client version; API interface version, etc.

Field type interpretation requestIdString an interface generates a requestIdtraceIdString, a stage generates a traceId, which is used to track all log records associated with an exception hashString the unique identification code of this log, which is equivalent to logId, but it is based on the specific content of the current log record generated timeNumber current log generation time (save time) userIdStringuserStatusNumber at that time, user status information (available / disabled) userRolesArray, the previous user's role list userGroupsArray at that time The user's current group, group permissions may affect the result userLicensesArray at that time, license, the path where the pathString may expire, what operations did the URLactionString do on the refererString? The last state of the source URLprevActionString that operates the current interface of dataObject, DatadataSourcesArray upstream api what data dataSendObject submitted what data targetElementHTMLElement user operation DOM element targetDOMPathArray the node path of the DOM element targetCSSObject the element's custom style sheet targetAttrsObject the element's current attributes and values errorTypeString error type errorLevelString exception level errorStackString error stack information errorFilenameString error file errorLineNoNumber error row error column location errorMessageString error description (developer defined) errorTimeStampNumber timestamp eventTypeString event type pageXNumber event x-axis coordinate pageYNumber event Piece y-axis coordinate screenXNumber event x-axis coordinate screenYNumber event y-axis coordinate pageWNumber page width pageHNumber page height screenWNumber screen width screenHNumber screen height eventKeyString trigger event key networkString network environment description userAgentString client description deviceString device description systemString operating system description appVersionString application version apiVersionString interface version

This is a very large log field table that contains almost all the information that can describe in detail the environment around an exception when an exception occurs. In different cases, these fields are not necessarily collected, and because we use a document database to store logs, it does not affect its actual storage results.

2.2 exception catch

The front-end capture exception is divided into global capture and single point capture. The global capture code is centralized and easy to manage; as a supplement, single point capture captures some special cases, but it is scattered and not conducive to management.

A, global capture

Through the global interface, the capture code is written in one place, and the interfaces that can be used are:

Window.addEventListener ('error') / window.addEventListener ("unhandledrejection") / document.addEventListener (' click'), etc.

Global snooping at framework level. For example, interceptor is used to intercept in aixos. Both vue and react have their own error collection interfaces.

By encapsulating the global function, the exception is automatically caught when the function is called.

To rewrite the instance method (Patch), wrap a layer on the basis of the original function, such as rewriting the console.error, and catch exceptions without changing the usage.

B, single point capture

Wrap a single block of code in the business code, or manage it in the logical process to achieve targeted exception capture:

Try... Catch

Write a function to collect exception information and call it when an exception occurs

Write a function to wrap other functions and get a new function that runs exactly the same as the original function, except that it can catch an exception when an exception occurs

2.3 Cross-domain scripting exception

Due to the limitation of browser security policy, when there is an error across domains, you can't get the details of the error directly, you can only get a Script Error. For example, we will introduce third-party dependencies, or put our own scripts in CDN.

Solutions to Script Error:

Option 1:

Inline js into HTML

Put the js file and HTML in the same domain

Option 2:

Add a crossorigin attribute to the script tag on the page

Is introduced into the response header of the server where the script is located, and Access-Control-Allow-Origin is added to support cross-domain resource sharing.

2.4 abnormal recording

For an exception, only having the information of the exception is not enough to fully grasp the nature of the problem, because the location of the exception is not necessarily the location of the source of the exception. We need to restore the scene of the exception in order to restore the whole picture of the problem, and even avoid similar problems in other interfaces. A concept needs to be introduced here, which is "abnormal recording". Recording records the whole process from the occurrence to the occurrence of the exception through the two dimensions of "time" and "space", which is more helpful to find the source of the exception.

Indicates that when an exception occurs, the source of the exception may be far away from us, and we need to go back to the scene where the exception occurred and find the source of the exception. Just like solving a case in real life, it is easier to solve a case if there is a surveillance camera recording the process of the crime. If you only focus on the exception itself, you need luck to find the source of the exception, but with the help of exception recording, it is easier to find the source.

The so-called "abnormal recording" actually collects the user's operation process through technical means, records every user's operation, and reruns the records within a certain period of time when an exception occurs, forming an image for playback, so that the debugger can see the user's operation process at that time without asking the user.

It is a schematic diagram of a set of abnormal recording and recovery solutions from Ali. The events and mutation generated by the user's operations on the interface are collected by the product, uploaded to the server, and sequentially stored in the database after queue processing. When abnormal reproduction is needed, the abnormal recovery can be realized by taking these records out of the database and using a certain technical scheme to play these records sequentially.

2.5 exception level

Generally speaking, we will divide the level of information collection into info,warn,error and so on, and expand on this basis.

When we monitor the occurrence of the exception, the exception can be divided into four levels A, B, C and D in the "important-emergency" model. Although some exceptions have occurred, they do not affect the normal use of users. In fact, users do not feel that although they should be repaired in theory, they can actually be dealt with later compared to other exceptions.

The article will discuss the alarm strategy. in general, the closer to the upper right corner, the faster the exception will be notified to ensure that the relevant personnel can receive the information as soon as possible and deal with it. A level An exception requires a quick response and even needs to be known by the relevant person in charge.

In the stage of collecting anomalies, the severity of the anomalies can be judged according to the abnormal consequences divided in the first section, and the corresponding reporting scheme can be selected to report when the anomalies occur.

(3) arrangement and reporting scheme

As mentioned earlier, in addition to the exception error message itself, we also need to record user operation logs to achieve scene recovery. This involves the quantity and frequency of reporting. If any log is reported immediately, it is tantamount to a self-made DDOS attack. Therefore, we need a reasonable reporting plan. The following article will introduce four reporting schemes, but in practice we will not be limited to one of them, but often use them at the same time, choosing different reporting schemes for different levels of logs.

3.1 the front end stores logs

As we mentioned earlier, we collect not only the log of the exception itself, but also the log of user behavior related to the exception. A single exception log does not help us quickly locate the root cause of the problem and find a solution. However, if you want to collect the user's behavior log, you have to take certain skills, but you can't send the behavior log to the server immediately after every operation. For an application with a large number of users online at the same time, if the user uploads the log immediately as soon as he operates, it is tantamount to a DDOS attack on the log server. Therefore, we first store these logs locally on the user client, meet certain conditions, and then package and upload a set of logs at the same time.

So, how to store the front-end logs? It is impossible to store these logs directly as a variable, which will overwhelm memory, and once the user refreshes, the logs will be lost, so we naturally think of the front-end data persistence solution.

At present, there are many persistence options available, mainly: Cookie, localStorage, sessionStorage, IndexedDB, webSQL, FileSystem, and so on. So how do you choose? We compare it with a table:

Storage mode cookielocalStoragesessionStorageIndexedDBwebSQLFileSystem type key-valuekey-valueNoSQLSQL data format stringstringstringobject capacity 4k5M5M500M60M process synchronous asynchronous retrieval keykeykey, indexfield performance read fast write slow read slow write fast

After synthesis, IndexedDB is the best choice, it has the advantages of large capacity, asynchronous, asynchronous characteristics to ensure that it will not block the rendering of the interface. And IndexedDB is divided into libraries, each library is divided into store, but also can query according to the index, with a complete database management thinking, more suitable for structured data management than localStorage. But one drawback is that api is very complex and not as simple and straightforward as localStorage. In view of this, we can use hello-indexeddb as a tool, which encapsulates complex api with Promise, simplifies the operation, and makes the use of IndexedDB as convenient as localStorage. In addition, IndexedDB is a widely supported HTML5 standard that is compatible with most browsers, so you don't have to worry about its prospects.

Next, how should we make rational use of IndexedDB to ensure the rationality of our front-end storage?

The figure above shows the process and database layout for storing logs at the front end. When an event, change, or exception is caught, an initial log is formed and immediately placed in a temporary storage area (a store of indexedDB), after which the main program ends the collection process, and subsequent events only occur in the webworker. In a webworker, a circular task constantly fetches logs from the temporary storage area, classifies the logs, stores the classification results in the index area, and enriches the information recorded in the log records, so that the log records that will eventually be reported to the server will be transferred to the archive area. When a log exists in the archive area for more than a certain number of days, it is no longer valuable, but in order to prevent special circumstances, it is transferred to the recycling area, and after a period of time, it will be removed from the recycling area.

3.2 the front end collates the log

As mentioned above, the log is sorted and saved to the index area and archive area in a webworker, so what is the collation process?

Since the report we are going to talk about below is carried out according to the index, our log sorting work at the front end is mainly to sort out different indexes according to the log characteristics. When we collect logs, we mark each log with a type, classify it, create an index, and calculate the hash value of each log object through object-hashcode as the unique flag of the log.

Store all log records in the archive area on time, and add the new logs to the index.

BatchIndexes: batch reporting index (including performance and other logs), which can report 100 entries at a time

MomentIndexes: report the index immediately, all at once

FeedbackIndexes: user feedback index, one at a time

BlockIndexes: report the index of blocks, which are divided into blocks by exception / error (traceId,requestId), one at a time

After the report is completed, it will be deleted by the index corresponding to the reported log.

Log for more than 3 days to enter the recycling area

Logs for more than 7 days are cleared from the recycling area

RquestId: track the front and back logs at the same time. Since the backend also records its own log, when the frontend requests api, requestId is used by default, and the log recorded at the backend can correspond to the frontend log.

TraceId: tracks the related logs before and after an exception occurs. When the application starts, create a traceId until an exception occurs, refresh the traceId. Collect a traceId-related requestId, combine these requestId-related logs, and eventually all the logs related to the exception are used to review the exception.

The figure illustrates how to use traceId and requestId to find all the logs associated with an exception. In the figure above, hash5 is an exception log. We found that the traceId corresponding to hash5 is traceId2. In the log list, there are two records with the traceId, but the record of hash4 is not the beginning of an action, because the requestId corresponding to hash4 is reqId2, and reqId2 starts with hash3, so we actually want to add hash3 to the entire review alternative record for the occurrence of the exception. To sum up, we need to find out the log records of all the requestId corresponding to the same traceId, although it is a bit winding, but we can understand the truth a little bit.

We aggregate all these logs related to an exception, called a block, and then use the hash collection of logs to get the hash of the block, and index in the index area, waiting to be reported.

3.3 report Log

Reporting logs are also carried out in webworker. In order to distinguish them from collation, they can be divided into two worker. The reporting process is roughly as follows: in each cycle, the index corresponding to the number of entries is extracted from the index area, and the complete log record is extracted from the archive area through the hash in the index, and then uploaded to the server.

According to the frequency of reporting (important emergency), the reporting can be divided into four categories:

a. Report immediately

As soon as the log is collected, the escalation function is triggered. For type An exceptions only. And due to the influence of network uncertainties, class A log reporting needs a confirmation mechanism, which can only be completed after confirming that the server has successfully received the reported information. Otherwise, there needs to be a circular mechanism to ensure successful reporting.

b. Batch report

The collected logs are stored locally, and when a certain number of logs are collected, they are packaged and reported at one time, or uploaded at a certain frequency (time interval). This is equivalent to merging multiple times into one escalation to reduce the pressure on the server.

c. Block report

Package an exception scenario into a block and report it. It is different from batch reporting, which ensures the integrity and comprehensiveness of the log, but there will be useless information. Block escalation is for the exception itself, ensuring that all logs related to a single exception are reported.

d. Users submit voluntarily

A button is provided on the interface for users to actively feedback bug. This helps to enhance interaction with users.

Or when an exception occurs, although it has no impact on the user, the application monitors it, and a prompt box pops up for the user to choose whether he wants to upload the log or not. This scheme is suitable when users' private data is involved.

Real-time batch reporting block reporting user feedback time limit immediately timed slightly delayed number of messages all reported once 100 items reported once 1 capacity small-urgent urgent important not urgent but important

Although instant reporting is called instant, it is actually accomplished through cyclic tasks similar to queues. It mainly submits some important exceptions to the monitoring system as soon as possible, so that operators can find the problem. Therefore, it corresponds to a relatively high degree of urgency.

The difference between batch reporting and block reporting: batch reporting is to report a certain number of messages at a time, for example, 1000 messages every 2 minutes until the reporting is completed. Block reporting is to collect all logs related to the exception immediately after the exception occurs, find out which logs have been reported in batches, delete them, and upload other related logs. These logs related to the exception are relatively more important. They can help restore the scene of the exception as soon as possible and find out the source of the exception.

The feedback submitted by users can be reported slowly.

In order to ensure that the reporting is successful, there needs to be a confirmation mechanism when reporting, because after the server receives the reporting log, it will not be stored in the database immediately, but in a queue, therefore, the front and back end needs to do some more processing to ensure that the log has indeed been recorded in the database.

The figure shows a general process of reporting. When reporting, use hash query to let the client know whether there are logs that have been saved by the server in the set of logs to be reported. If so, remove these logs to avoid repeated reporting and waste traffic.

3.4 Compression of reported data

When uploading batch data at one time, it is bound to encounter a large amount of data, wasted traffic, or slow transmission, which may lead to reporting failure under the bad state of the network. Therefore, it is also a scheme to compress the data before reporting.

For merging and reporting this situation, the amount of data at a time may be more than ten k, and for sites with a large daily pv, the traffic generated is still considerable. Therefore, it is necessary to compress and report the data. Lz-string is a very excellent string compression library with good compatibility, less code, high compression ratio, short compression time and an amazing 60% compression ratio. However, it is based on LZ78 compression. If the backend does not support decompression, you can choose gzip compression. Generally speaking, the backend will be pre-installed with gzip by default. Therefore, it is also possible to select gzip compression data. Gzip compression is included in the toolkit pako, so you can try it.

4 Log receiving and storage

4.1 access layer and message queuing

Generally, an independent log server is provided to receive the client log. In the receiving process, the legitimacy and security of the client log content should be screened to prevent being attacked. And because log commits are generally frequent, it is common for multiple clients to be concurrent at the same time. It is also a common scheme to process the log information one by one through the message queue and write it to the database for preservation.

The picture shows the architecture of Tencent BetterJS, in which "access layer" and "push center" are the access layer and message queue mentioned here. BetterJS splits the modules monitored by the front end, and the push center plays the role of pushing logs to the storage center for storage and to other systems (such as alarm system). However, we can look at the queues in the receiving log phase independently and make a transition between the access layer and the storage layer.

4.2 Log storage system

Storing logs is a dirty job, but it has to be done. For small applications, a single database and single table plus optimization can cope with. For a large-scale application, if you want to provide more standard and efficient log monitoring services, you often need to make some efforts on the log storage architecture. At present, there are relatively complete log storage schemes in the industry, such as Hbase, Dreamel, Lucene and so on. Generally speaking, the main problems faced by the log storage system are large amount of data, irregular data structure, high write concurrency, large query requirements and so on. In general, in order to solve the above problems, it is necessary to solve the write buffer, select the storage medium according to the log time, design a reasonable index system to facilitate fast reading, and so on.

As the log storage system scheme is more mature, there will be no more discussion here.

4.3 search

The ultimate purpose of the log is to use, because the volume of the general log is very large, therefore, in order to find the required log records in the huge data, we need to rely on a better search engine. Splunk is a mature log storage system, but it is used for a fee. According to the framework of Splunk, Elk is the open source implementation of Splunk, Elk is the combination of ElasticSearch, Logstash and Kibana, ES is a search engine based on Lucene storage and index; logstash is a log standardization pipeline that provides input, output and conversion processing plug-ins; and Kibana provides a user interface for visualization and query statistics.

5 log statistics and analysis

A complete log statistical analysis tool needs to provide convenient panels in all aspects to give feedback to log administrators and developers in a visual way.

5.1 user latitude

Different requests from the same user actually form different request id lines, so it is necessary to design a unique storyline for a series of operations of the user. The same user can also distinguish when operating at different terminals. The user's status, permissions and other information during an operation also need to be reflected in the log system.

5.2 time dimension

How an exception occurs needs to be observed by concatenating the story lines before and after the exception operation. It involves not only an operation by a user, or even a page, but the end result of a series of events.

5.3 performance Dimension

The performance of the application during operation, such as interface loading time, api request time statistics, unit computing consumption, user lag time.

5.4 operating environment dimension

The environment in which the application and service runs, such as the network environment in which the application is located, operating system, device hardware information, server cpu, memory status, network, broadband usage, etc.

5.5 Fine-grained code tracking

The code stack information of the exception, navigating to the location of the code where the exception occurred and the exception stack.

5.6 scene backtracking

By connecting the user logs related to the exception, the process of the exception is output dynamically.

6 Monitoring and notification

The statistics and analysis of anomalies is only the basis, and when an exception is found, it can be pushed and alerted, or even handled automatically, which is the ability that an exception monitoring system should have.

6.1 alarm for custom trigger conditions

a. Monitoring implementation

The monitoring logic can be triggered when the log information enters the access layer. When there is a higher-level exception in the log information, you can also start the alarm immediately. Alarm message queue and log storage queue can be managed separately and implemented in parallel.

Carry on the statistics to the incoming log information, and alarm the abnormal information. Respond to monitoring exceptions. The so-called monitoring exception refers to: regular anomalies are generally more reassuring, the more troublesome is the sudden exception. For example, in a certain period of time, D-level anomalies are suddenly and frequently received. Although D-level anomalies are not urgent, it is necessary to be vigilant when the monitoring itself is abnormal.

b. Custom trigger condition

In addition to the default alarm conditions configured during system development, custom trigger conditions that can be configured by log administrators should also be provided.

When there is anything in the log

What is the degree and quantity of log statistics?

Alert users who meet any conditions.

6.2 push channels

There are many ways to choose, such as email, SMS, Wechat, phone.

6.3 push frequency

The frequency of push can also be set for different levels of alarm. Low-risk alarms can be pushed once a day in the form of a report, and high-risk alarms can be pushed in a 10-minute cycle until the processor manually turns off the alarm switch.

6.4 automatic report

For the push of log statistics, daily, weekly, monthly and annual reports can be automatically generated and e-mailed to relevant groups.

6.5 automatically generate bug work orders

When an exception occurs, the system can call the work order system API to automatically generate the bug order, and feedback it to the monitoring system after the work order is closed to record the tracking information of the exception handling and display it in the report.

7 repair exception

7.1 sourcemap

Most of the front-end code is released after compression, and the reported stack information needs to be restored to the source code information in order to quickly locate the source code for modification.

When publishing, only deploy the js script to the server, upload the sourcemap file to the monitoring system, when the stack information is displayed in the monitoring system, use the sourcemap file to decode the stack information and get the specific information in the source code.

However, there is a problem here, that is, the sourcemap must correspond to the version of the formal environment, and it must also correspond to a commit node in the git, so as to ensure that the stack information can be correctly used when checking exceptions to find the code of the version where the problem occurs. This can be achieved by establishing CI tasks and adding a deployment process to the integrated deployment.

7.2 from alarm to early warning

The essence of early warning is to presuppose the condition under which the exception may occur, and the exception does not really occur when the condition is triggered. Therefore, the user behavior can be checked before the exception occurs and repaired in time to avoid the exception or abnormal expansion.

How do I do that? In fact, it is a statistical clustering process. Carry on the statistics of the abnormal situation in the history, from the time, region, user and other different dimensions to find out the rules, and automatically add these laws to the early warning conditions through the algorithm, when triggered next time, early warning in time.

7.3 Intelligent repair

Automatically fix errors. For example, if the front end requires the interface to return a numeric value, but the interface returns a numeric string, then there can be a mechanism for the monitoring system to send the correct data type model to the back end, and the back end controls the type of each field according to the model when returning data.

8 abnormal test

8.1 active exception testing

Write exception use cases and add exception test users to the automated test system. During testing or running, every time an exception is found, it is added to the original list of exception use cases.

8.2 Random exception testing

Simulate the real environment, simulate the random operation of the real user in the simulator, and use the automatic script to generate the random operation code and execute it.

Define an exception, such as when a pop-up box contains specific content, it is an exception. Recording these test results and then clustering statistical analysis is also very helpful to defend against anomalies.

9 deployment

9.1 Multi-client

A user logs in on a different terminal, or the status of a user before and after logging in. RequestID is generated by a specific algorithm, through which a series of actions of a user on an independent client can be determined, and the specific path of the exception generated by the user can be sorted out according to the log timing.

9.2 Integration convenience

The front end is written as a package, and the global reference can complete most of the logging, storage and reporting. In special logic, you can call specific methods to log.

The back-end is decoupled from the business code of the application itself and can be made into an independent service that interacts with third-party applications through interfaces. With integrated deployment, the system can be expanded and migrated at any time.

9.3 Extensibility of management system

The whole system is scalable, not only for single service applications, but also for multiple applications to run at the same time. All applications under the same team can be managed on the same platform.

9.4 Log system permissions

Different people have different permissions when accessing the log system. A visitor can only view their own related applications. If some statistics are sensitive, permissions can be set separately, and sensitive data can be desensitized.

10 other

10.1 performance Monitoring

Exception monitoring focuses on code-level error reporting, but should also focus on performance exceptions. Performance monitoring mainly includes:

Runtime performance: file level, module level, function level, algorithm level

Network request rate

System performance

10.2 API Monitor

The back-end API also has a great impact on the front-end. Although the front-end code also controls the logic, the data returned by the back-end is the basis, so the monitoring of API can be divided into:

Stability monitoring

Data format and type

Error monitoring

Data accuracy monitoring

10.3 data desensitization

Sensitive data is not collected by the log system. Because the storage of the log system is relatively open, although the data in it is very important, most of the log systems are not classified in storage. Therefore, if the application involves sensitive data, it is best to do so:

Deploy independently and do not share monitoring system with other applications

No specific data is collected, only user operation data is collected. During reproduction, the api results of the data can be taken out from the log information to display.

Log encryption to achieve encryption protection at the software and hardware level

If necessary, the ID that collects the specific data can be used for debugging. When the scene is reproduced, the mock data can be used instead of the mock data. The mock data can be generated by the back-end using a fake data source.

Confuse sensitive data

Thank you for your reading. the above is the content of "how to solve the front-end exception monitoring". After the study of this article, I believe you have a deeper understanding of how to solve the problem of front-end exception monitoring. the specific use situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.