All Products
Search
Document Center

Application Real-Time Monitoring Service:Statistical metrics

Last Updated:Mar 15, 2024

This topic describes the key statistical metrics on each page for Browser Monitoring of Application Real-Time Monitoring Service (ARMS) and the fields in Browser Monitoring logs.

Satisfaction

Application Performance Index (Apdex) is a global standard for evaluating application performance. The user experience of an application can be evaluated based on Apdex by three levels:

  • Satisfied (0 to T)

  • Tolerating (T to 4T)

  • Frustrated (greater than 4T)

The following formula is used to calculate the Apdex score:

APDEX score = (Number of satisfied samples + Number of tolerating samples/2)/Number of total samples

image

The First Paint Time (FPT) is used as the metric to evaluate the Apdex of ARMS. The default value of T is 2 in seconds.

JS stability

In ARMS, JavaScript (JS) stability is evaluated by the JS error rate of pages.

If a JS error occurs in a page view (PV) cycle, this PV cycle is considered as an error sample.

Error rate = Number of error samples/Number of total samples

In addition to the JS errors that are automatically reported, page exceptions also include errors reported when you manually call methods described in SDK methods.

Access speed

In ARMS, access speed is evaluated by the FPT of a page.

All performance or speed statistics are collected by using the Navigation Timing API defined by the World Wide Web Consortium (W3C).

image
Table 1. Key performance metrics of web pages

Reported field

Description

Formula

Remarks

FMP

The First Meaningful Paint (FMP).

For more information, see Technical solution of FMP.

None

FPT

The FPT.

responseEnd - fetchStart

This field indicates the duration from the point in time when a request is initiated to the point in time when the browser begins to parse the bytes of the first batch of HTML documents.

TTI

The Time to Interactive (TTI).

domInteractive - fetchStart

This field indicates the point in time when the browser starts to load resources after it resolves all HTML documents and constructs the document object model (DOM).

Ready

The time consumed to complete HTML loading, which is the time consumed to construct the DOM.

domContentLoadEventEnd - fetchStart

If a JS script is synchronously executed on the page, the execution time of the JS script can be calculated based on the following formula: Execution time of the JS script = Ready - TTI.

Load

The time consumed to completely load the page.

loadEventStart - fetchStart

This field can be calculated based on the following formula: Load = FPT + DOM + (Ready - TTI) + Res.

FirstByte

The time consumed to receive the first data packet from the server.

responseStart - domainLookupStart

None

Table 2. Fields that describe the time consumed in each phase

Reported field

Description

Formula

Remarks

DNS

The time consumed for Domain Name System (DNS) query.

domainLookupEnd - domainLookupStart

None

TCP

The time consumed for Transmission Control Protocol (TCP) connection.

connectEnd - connectStart

None

TTFB

The time to first byte (TTFB), which indicates the time consumed to respond to a request.

responseStart - requestStart

TTFB can be calculated in different ways. For more information about how TTFB is calculated in ARMS, see Google development definition.

Trans

The time consumed for data transmission.

responseEnd - responseStart

None

DOM

The time consumed for DOM resolution.

domInteractive - responseEnd

None

Res

The time consumed for resource loading.

loadEventStart - domContentLoadedEventEnd

The time consumed to synchronously load resources on the page.

SSL

The time consumed for Secure Sockets Layer (SSL) connection.

connectEnd - secureConnectionStart

This field is valid only when HTTPS is used to transmit data.

Table 3. Key performance metrics of mini programs

Reported field

Description

Formula

Remarks

FPT

The FPT.

onShow (first page) - onLaunch (app)

The duration from the point in time when the mini program calls the onLaunch method to the point in time when the mini program calls the onShow method to display the first page.

Success rate of API calls

Success rate of API calls = Number of successful API calling samples/Number of total API calling samples

In addition to the AJAX requests that are automatically reported, samples for calculating the success rate of API calls also include the data reported when you manually call the methods described in SDK methods.

Log fields

The following tables describe the fields included in ARMS logs.

Table 4. Common fields

Field

Description

uid

The ID of the user. The value is an identifier of the user and can be used to search for the user. You can specify a custom value. If you do not set this field, the SDK automatically assigns an ID to the user and updates the ID every six months.

username

The username. The SDK does not automatically assign a username to the user. If you do not set this field, it is left empty.

release

The ID of the application version.

environment

The production environment.

page

The page.

sampling

The sampling rate.

tag

The custom tag.

Table 5. Fields related to API calls

Field

Description

api

The URL of the API call without parameters.

msg

The response string to the API call.

code

The HTTP status code.

time

The time consumed by the API call.

success

Indicates whether the API call is successful.

Table 6. Fields related to JS errors

Field

Description

msg

The error message.

stack

The stack where the error occurs.

cate

The error type. Valid values:

  • EvalError: The error is related to the eval() function.

  • RangeError: The error is reported because the value of a numeric variable or parameter is invalid.

  • ReferenceError: The error is reported because invalid references exist.

  • SyntaxError: The error is reported because the syntax is invalid.

  • TypeError: The error is reported because the type of a variable or parameter is invalid.

  • URIError: The error is reported because the parameters passed to the encodeURI() function or the decodeURI() function are invalid.

  • AggregateError: Multiple errors are generated by one operation, such as Promise.any().

  • Custom error types.

file

The file where the error occurs.

line

The line where the error occurs.

col

The column where the error occurs.

times

The number of times the error occurs.

Log description

Table 7. Logs for multi-dimensional analysis

Log type

Type

Query field

(Common metric fields can be used to query or filter all types of logs)

PV log

PV

When an onload event occurs, PV logs are uploaded to calculate PVs and unique visitors (UVs).

Calculation methods:

  • PV: the number of PV logs.

  • UV: PV logs are deduplicated based on the UID.

Performance log

Perf

Performance metrics

Slow loading log

(Performance logs in which the loading time is longer than 8 seconds)

RES

Performance metrics

JS error log

Error

  • JS error message

  • URL of the JS error file

  • JS error type

API log

API

  • API name

  • Message returned by the API call

  • HTTP status code

  • Time consumed by the API call

  • Domain name

  • Whether the API call is successful

  • Trace ID

SUM log

SUM

Custom key: event name (example: scroll-count)

AVG log

AVG

Custom key: event name (example: scroll-time)

Resource error log

ResourceError

Resource error

None

Custom

None

Note
  • Custom logs are used for custom business monitoring. Custom logs are generated only if you call the ARMS Agent API to report data.

  • Custom log data is not displayed in the ARMS console. You can query and analyze custom log data in the Simple Log Service console.