Front-end exception monitoring solution
Logan
Logan is a large front-end log system launched by Meituan-Dianping Group, including log collection and storage, reporting analysis and visual display. Five components are provided, including end-end log collection and storage, Web SDK, back-end log storage and analysis server, and log analysis platform LoganSite.
Logan
ARMS
ARMS front-end monitoring focuses on monitoring Web scenarios, Weex scenarios and mini-program scenarios. It monitors Web and mini-programs from three aspects: page opening speed (speed test), page stability (JS Error) and external service call success rate (API). The health of the program page.
What is ARMS front-end monitoring?
fundebug
fundebug is
a professional application error monitoring platform that detects bugs in time and improves debugging efficiency. Currently supports front-end JavaScript, WeChat mini programs, WeChat mini games, Alipay mini programs, React Native, Java and Node.js.
Sentry
sentry
Sentry is a modern real-time event log monitoring, recording and aggregation platform built on Django. It is mainly used to quickly detect faults. Resolve errors and performance issues faster and gain continuous visibility into their application health from front-end to back-end.
badjs
BetterJS
BadJS is a web front-end exception monitoring solution that provides a systematic tracking solution for script error monitoring, reporting, statistics, and viewing of web pages.
Currently, the more popular exception monitoring solutions include the above. However, considering the ease of use, whether it is free, and whether the project is open source, Sentry is a very good choice. The server-side deployment is also very simple. Of course, the server can also be directly deployed. Using what Sentry provides, the website client introduces the sentry sdk and inserts the code to initialize Sentry to monitor page script exceptions.
advantages and disadvantages of sentry
advantage
1. Good product experience and complete functions
2. Less access workload 3.
Sentry focuses on Error, Exception, and Crash
4. Provides rich contextual information
5. Automatically merges duplicate issues
6. Proactive email alerts
shortcoming
1. Deployment depends on many things. Using the official Github repository, based on Docker and Docker Compose, you can deploy it with one click and use it out of the box. However, when I see 30 containers listed in front of me, I still feel hesitant.
2. You need to ensure high availability by yourself, such as: ZooKeeper, Nginx, Redis, etc. It is not easy to operate and maintain these components by yourself and ensure high availability.
3. If a large number of errors! [Please add image description](https://img-blog.csdnimg.cn/c1d08c48447b4b8d9f56ecf6b495a5e0.png
information floods into the Sentry server, it will cause serious delays in Sentry response
sentry access process
sentry deployment
1. Install docker dependencies.
Install docker, docker-compose, yum-utils and other dependencies.
2. Install onpremise.
Download sentry and run the warehouse onpremise
git clone https://github.com/getsentry/self-hosted.git
. Enter the directory: cd self-hosted
Execute the script: ./install.sh This process will run for a while. After success, you will be prompted whether to create an account.
3. Run the sentry service
. If the account is successfully created, execute docker-compose up -d to start the project. Port 9000 is opened by default.
sentry basic settings
Sentry defaults to a pure English interface, but the language can be modified. The steps are as follows:
1. User->User settings
2. Language selection, select Simplified Chinese, which is Simplified Chinese
3. Timezone selection, select Shangehai
4. Refresh the page and successfully enter the Chinese interface
vue project access
Configuration guide: https://docs.sentry.io/platforms/javascript/guides/vue/Installation
dependencies:npm install --save @sentry/vue @sentry/tracing
SourceMaps configuration
Mirror source replacement
Add .yarnrc to the project with the following content:
SENTRYCLI_LOCAL_CDNURL "https://cdn.npm.taobao.org/dist/sentry-cli"
SENTRYCLI_CDNURL "https://cdn.npm.taobao.org/dist/sentry-cli"
Or .npmrc, the content is as follows:
sentrycli_cdnurl=https://cdn.npm.taobao.org/dist/sentry-cli
PS: Change the download source to avoid unsuccessful downloading when downloading @sentry/cli
sentry/webpack-plugin
1. Install dependencies npm install @sentry/webpack-plugin -D
2. Add configuration in vue.config.js, as follows:
3. Set productionSourceMap to false, execute npm run buildpackaging to generate .map.js file, and upload it to sentry server
4. After building and uploading the js file, you need to delete *.map.jsthe file
Page load metrics
Google's Good, Needs Improvement, and Poor thresholds are used to classify data points into green, yellow, and red for corresponding Web Vitals. “Needs improvement” is called “Meh” in Sentry.
Largest Contentful Paint (LCP)
LCP (Largest Contentful Paint): Maximum content painting time, used to measure the loading experience. Google requires that LCP should ideally occur within 2.5 seconds of the page first starting to load.
First Input Delay (FID)
FID (First Input Delay): First input delay time, used to measure page interactivity. Google requires the FID of the page to be less than 100 milliseconds.
Cumulative Layout Shift (CLS)
CLS (Cumulative Layout Shift): Cumulative layout displacement, used to measure visual stability. Google requires that the CLS of the page be kept less than 0.1.
First Paint (FP)
First Paint (FP) measures the time it takes for the first pixel to appear in the viewport, rendering any visual changes compared to what was previously displayed.
First Contentful Paint (FCP)
First Contentful Paint (FCP) measures the time it takes for the first content to render in the viewport. FCP helps developers understand how long it takes for users to see any content changes on the page.
Time To First Byte (TTFB)
Time To First Byte (TTFB) measures the time it takes for the user's browser to receive the first byte of page content. TTFB refers to the time when the browser begins to receive response data from the server (background processing time + redirection time). It is an important indicator that reflects the response speed of the server. We can consider TTFB time above 500 ms as too long. TTFB helps developers understand whether their slowness is caused by the initial response or render-blocking content.
Online website optimization detection tool: https://web.dev/optimize-lcp/
Web Vitals: https://docs.sentry.io/product/performance/web-vitals/