Detailed Description
In order that the above-recited objects, features and advantages of the present application will become more readily apparent, a more particular description of the application will be rendered by reference to the appended drawings and appended detailed description.
The technical scheme of the application is mainly applied to the Internet scene to realize the monitoring of the stability of the page script. The client in the embodiment of the present application is a browser, for example, a browser in a computer or a browser in a mobile phone, and of course, may also be other applications including pages of a JS script, which is not limited by the embodiment of the present application.
Referring to fig. 1, a schematic diagram of a processing architecture of a page script monitoring method according to an embodiment of the present application is shown.
For example, for the same page www.xxxxx.com, the application server corresponding to the page www.xxxxx.com, such as application server B, therefore, when the user needs to access the page www.xxxxx.com in the browser, first, needs to send a page request to the application server B, the application server B returns corresponding page information according to the received page request, and the client receives the page information returned by the application server B, renders the page information, and displays the page information in the web page of the client.
In a certain period of time, N users respectively access the same page at respective clients, the corresponding N clients respectively send page requests to the application server, and the N clients respectively execute step S1: a page request is sent to an application server.
The application server returns page information to the corresponding client according to the received N page requests, and the N clients execute step S2 respectively: and receiving page information returned by the application server. In the process of loading and running the page information, the client may cause script errors due to various reasons such as coding errors, grammar errors and the like, a function such as window, onerror and the like can be adopted in the client to capture script errors in the page execution process, and when the script errors are captured in the page of the client, page state information in the page execution process is sent to a log monitoring server, wherein the page state information comprises the script error state information; when script errors are not captured in the page of the client, sending a page state message in the page execution process to the log monitoring server, wherein the page state message comprises script normal state information. The log monitoring server executes step S3: and receiving a page status message sent by the client in the page execution process.
And the log monitoring server determines page stability parameters according to script execution state information in the received page state message.
Referring to fig. 2, a schematic diagram of a processing architecture of another page script monitoring method according to an embodiment of the present application is shown.
When script errors are captured in the page of the client, page state information in the page execution process can be sent to the application server, wherein the page state information comprises script error state information; when script errors are not captured in the page of the client, sending page state information in the page execution process to the application server, wherein the page state information comprises script normal state information. The application server performs step S3: and receiving a page status message sent by the client in the page execution process.
And the application server determines the page stability parameter according to script execution state information in the received page state message.
As described in fig. 1 and fig. 2, in the embodiment of the present application, for the provider of the page and the receiver of the page status message, both may be disposed in different servers, or may be disposed in one server, which is not limited by the embodiment of the present application. Such as the application server in fig. 1 providing page information to the client-side, and the log monitor server is configured to perform the process of receiving page status messages and determining page stability parameters; while the application server in fig. 2 provides page information to the client, the process of receiving page status messages and determining page stability parameters is also performed daily.
Referring to fig. 3, an interaction diagram of a page script monitoring method according to an embodiment of the present application is shown.
For one of the clients, the interaction process of the page script monitoring method is described in detail, and the interaction process can be completed by the cooperation of the client, the application server and the log monitoring server as shown in fig. 1.
When a user accesses a page in a client, step A1 is first performed by sending a page request to an application server. After receiving the page request of the client, the application server executes step A2: and returning page information to the corresponding client. After receiving the page information returned by the application server, the client loads and runs the page information and executes the step A3: and determining script execution states in the page execution process. Capturing script errors in the page execution process by adopting a window, and after executing the step A3, executing the step A4: and sending a page state message comprising script execution state information to the log monitoring server. Step A5 is then performed: and receiving a page status message sent by the client in the page execution process. After receiving the page status message, the log monitoring server performs step A6: and determining the page stability parameter according to the page state information belonging to the same page.
Of course, the interaction process may be completed by the client and the application server in fig. 2, and then the servers in steps A4, A5, and A6 may be the application servers in fig. 2.
In the embodiment of the application, the page state information comprising script execution state information is reported to the server by monitoring the script execution state in the page execution process, the server counts the reported page state information without considering the specific occurrence times of script errors in the page, and only when script errors occur, one script error state information is recorded, and when no script errors occur, one script normal state information is recorded, so that the reported page state information is equivalent to a user reporting the script execution state information, and page script stability parameters are determined according to the script execution state information, so that the accuracy for measuring the page script stability is higher and more objective, and the probability of false alarm can be reduced.
Example 1
The embodiment of the application is described from the server side. Such as the log monitor server in fig. 1 or the application server in fig. 2.
Referring to fig. 4, a flowchart of an embodiment of a page script monitoring method according to an embodiment of the present application may specifically include the following steps:
Step 401, receiving a page status message sent by a client in a page execution process; the page status message includes script execution status information.
In the embodiment of the application, page information acquired from an application server is used for capturing script errors in the page execution process by adopting a window/error function in the client execution process, and when the script errors are captured in the page of the client, page state information in the page execution process is sent to a log monitoring server in FIG. 1 or the application server in FIG. 2, wherein the page state information comprises the script error state information; when no script error is captured in the page of the client, a page status message in the page execution process is sent to the log monitoring server in fig. 1 or the application server in fig. 2, and the page status message includes script normal status information. The log monitoring server in fig. 1 or the application server in fig. 2 receives the page status message sent by the client.
The page execution process comprises a page loading process and/or a page running process; the script error state information and the script normal state information can be respectively regarded as one piece of identification information, and whether the received page state information comprises the script error state information or the script normal state information is determined by detecting the identification information in the page state information.
The client may send a page status message to the log monitor server in fig. 1 or the application server in fig. 2 based on an HTTP (Hyper Text Transfer Protocol ) protocol, the page status message including script execution status information, and the script execution status information includes: script error state information or script normal state information.
Step 402, determining the page stability parameter according to the page status messages belonging to the same page.
In the embodiment of the application, the log monitoring server in fig. 1 or the application server in fig. 2 counts page status messages belonging to the same page within a certain duration, and calculates page stability parameters according to the page status messages belonging to the same page.
Specifically, the script execution state information included in the page state message is detected, a page stability parameter is determined according to the script execution state information, and the page stability parameter is used as an index for measuring page script stability.
For the same page, the total number of the message number containing the script error state information and the message number containing the script normal state information is equal to the total number of page state messages belonging to the same page.
For example, for the same page www.xxxxx.com, if the log monitoring server in fig. 1 or the application server in fig. 2 receives 100 page status messages sent by clients, and each page status message sent by each client is 1, the log monitoring server in fig. 1 or the application server in fig. 2 receives 100 page status messages, the number of script error status information in the 100 page status messages is counted to be 1, and the number of script normal status information in the 100 page status messages is counted to be 99; and determining page stability parameters according to the 1 script error state information and the 99 script normal state information, and taking the page stability parameters as indexes for measuring page stability.
According to the embodiment of the application, the page state information in the page execution process sent by the client is received, the page state information comprises script execution state information, and the page stability parameter is determined according to the page state information belonging to the same page. In the page execution process, the received page state information comprises script execution state information, the specific occurrence times of script errors in the page do not need to be considered, one script error state information is recorded as long as the script errors occur, and one script normal state information is recorded as long as no script errors occur, so that the reported page state information is equivalent to a user reporting the script execution state information, and the page script stability parameters are determined according to the script execution state information, so that the accuracy for measuring the page script stability is higher and more objective, and the probability of false alarm can be reduced.
Example two
The embodiment of the application is described from the server side.
Referring to fig. 5, a specific flowchart of an embodiment of a page script monitoring method according to an embodiment of the present application is shown, and may specifically include the following steps:
step 501, receiving a page status message sent by a client for a page loading process when the page loading is completed.
In the embodiment of the application, the client sends the page request to the corresponding application server, the application server returns the corresponding page information according to the received page request, the client loads the page information in the webpage after receiving the page information, and a window function can be adopted to capture script errors in the page loading process.
Referring to fig. 6, a schematic diagram of sending a page status message according to an embodiment of the present application is shown.
When the page loading is completed, namely at a window moment point, sending the page state information aiming at the page loading process to a log monitoring server in fig. 1 or an application server in fig. 2, wherein the log monitoring server in fig. 1 or the application server in fig. 2 receives the page state information aiming at the page loading process and sent by a client; the page status message includes script execution status information, where the script execution status information includes: script error state information or script normal state information.
Specifically, the page status message sent by the client through the window loading completion event is received.
In practical applications, a window_onload is an event that is triggered when all elements in a page are loaded.
When a window-loading event is triggered, namely, when a window loading completion event is triggered, the client sends a page state message in the process of loading a page to the log monitoring server in fig. 1 or the application server in fig. 2, and the log monitoring server in fig. 1 or the application server in fig. 2 receives the page state message in the process of loading the page, which is sent by the client through the window loading completion event; wherein the page status message includes script execution status information.
It should be noted that, whether the specific number of script errors captured by using the window/onerror in the page loading process is one or more, when the page loading is completed, the window/onload event is triggered, and the number of script error state information included in the page state message sent to the log monitoring server in fig. 1 or the application server in fig. 2 is only one; of course, a specific number of script errors may be included in the page status message, but when the script error status information in the page status message is counted later, a script error status information is recorded.
Step 502, receiving a page status message sent by a client in a page running process when the page exits.
In the embodiment of the application, in the page running process, a window can be adopted to capture script errors in the page running process.
As shown in fig. 6, when the page exits, that is, at the window. Before unloading point, the page status message for the page running process is sent to the log monitoring server in fig. 1 or the application server in fig. 2, and the log monitoring server in fig. 1 or the application server in fig. 2 receives the page status message for the page running process sent by the client; the page status message includes script execution status information, where the script execution status information includes: script error state information or script normal state information.
Specifically, the page status message sent by the client through the window closing event is received.
In practical application, window.before load is an event, when a window.before load event is triggered during closing or refreshing of a page, a dialog box with determination and cancellation is popped up in the page, when determination is selected, the page is left, namely, the page stops running, and when cancellation is selected, the page continues to be kept at the current page.
When a window.before load event is triggered, namely, when a window is closed, the client sends a page state message aiming at the page running process to the log monitoring server in fig. 1 or the application server in fig. 2, and the log monitoring server in fig. 1 or the application server in fig. 2 receives the page state message aiming at the page running process and sent by the client through the window closing event; wherein the page status message includes script execution status information.
It should be noted that, whether the specific number of script errors captured by using window. Onerror in the page running process is one or more, when the page exits, a window. Before unloading event is triggered, and the number of script error state information included in the page state message sent to the log monitoring server in fig. 1 or the application server in fig. 2 is only one; of course, a specific number of script errors may be included in the page status message, but only one script error status message is recorded when the script error status message in the page status message is counted later.
Embodiments of the present application may perform steps 501 and 502, and may perform only any one of steps 501 and 502.
When executing step 501 and step 502, the log monitoring server in fig. 1 or the application server in fig. 2 receives page status messages sent by the client, including a page status message for a page loading process and a page status message for a page running process; when only step 501 is performed, the log monitor server in fig. 1 or the application server in fig. 2 receives a page status message for the page loading process; when only step 502 is performed, either the log monitor server in FIG. 1 or the application server in FIG. 2 receives a page status message for the page in the process of running.
Step 503, determining the page stability parameter according to the page status messages belonging to the same page.
In the embodiment of the application, the log monitoring server in fig. 1 or the application server in fig. 2 counts page status messages belonging to the same page within a certain duration, and calculates page stability parameters according to the page status messages belonging to the same page.
Specifically, the log monitoring server in fig. 1 or the application server in fig. 2 receives the page status message sent by the client and further includes a page identifier, and determines the page stability parameter according to determining the page status message belonging to the same page identifier.
In practical applications, the log monitoring server in fig. 1 or the application server in fig. 2 receives the page status message of each page sent by the client, the page status message carries the page identifier of the corresponding page, the log monitoring server in fig. 1 or the application server in fig. 2 distinguishes each page according to the page identifier, counts the page status messages belonging to the same page identifier, and determines the page stability parameter of the page corresponding to the page identifier.
For example, within 1 minute, the page status messages received by the log monitor server in fig. 1 or the application server in fig. 2 include C1, C2, C3, C4, D1, D2, D3, E1 and E2, the page identifications in the page status messages C1, C2, C3 and C4 are all C, the page identifications in the page status messages D1, D2 and D3 are all D, and the page identifications in the page status messages E1 and E2 are E; the method comprises the steps of counting script execution state information contained in page state messages C1, C2, C3 and C4, determining page stability parameters of pages corresponding to page identifiers C, counting script execution state information contained in page state messages D1, D2 and D3, determining page stability parameters of pages corresponding to page identifiers D, counting script execution state information contained in page state messages E1 and E2, and determining page stability parameters of pages corresponding to page identifiers E.
In one embodiment of the application, for page status messages belonging to the same page, determining the proportion of the number of messages containing script error status information to the number of page status messages, and obtaining the page stability parameter.
And counting the number of messages of script error state information included in the page state messages for page state messages belonging to the same page within a certain time period, and correspondingly, counting the number of page state messages.
Calculating the proportion of the number of messages containing script error state information to the number of page state messages to obtain page stability parameters of the page, wherein the corresponding calculation formula is as follows:
M=failCount/(successCount+ failCount)×100%; (1)
in formula (1), M represents a page stability parameter, failCount represents the number of messages containing script error state information, successecount represents the number of messages containing script normal state information, and the total of the number of messages containing script error state information and the number of messages containing script normal state information is equal to the number of page state messages.
For example, in the last 5 minutes, 100 page status messages of the page F are received altogether, wherein the number of messages containing script error status information is 10, and the page stability parameter M of the page F is 10%.
In another embodiment of the present application, for page status messages belonging to the same page, determining a ratio of the number of messages containing script error status information to the number of messages containing script normal status information, and obtaining the page stability parameter.
And counting the number of messages of script error state information included in the page state information for page state information belonging to the same page within a certain time period, and correspondingly counting the number of messages of script normal state information included in the page state information.
Calculating the ratio of the number of messages containing script error state information to the number of messages containing script normal state information to obtain the page stability parameter of the page, wherein the corresponding calculation formula is as follows:
M=failCount/successCount; (2)
in formula (2), M represents a page stability parameter, failCount represents the number of messages containing script error state information, and succgcount represents the number of messages containing script normal state information.
Of course, the page stability parameter M in equation (2) may also be converted into a percentage display by multiplying the ratio of the number of messages containing script error status information to the number of messages containing script normal status information by a percentage.
For example, in the last 3 minutes, 50 page status messages of the page G are received, wherein the number of messages containing script error status information is 10, and the number of messages containing script normal status information is 40, and then the page stability parameter M of the page G is 0.25.
And 504, generating alarm information when the page stability parameter is greater than a set threshold value.
In the embodiment of the application, a set threshold value can be set, and when the calculated page stability parameter is greater than the set threshold value, alarm information is generated.
The alarm information can be sent to the appointed client or the application server corresponding to the page, so that script errors of the page can be conveniently analyzed and processed.
Of course, the page is unstable as the page stability parameter calculated in the formula (1) and the formula (2) is larger, so that when the page stability parameter is larger than a set threshold value, alarm information is generated; if the formula (1) is converted into the proportion of the number of messages containing script normal state information to the number of page state messages, obtaining the page stability parameter of the page, and generating alarm information when the page stability parameter is smaller than a set threshold value.
According to the embodiment of the application, the page stability parameter is determined according to the page state information belonging to the same page by receiving the page state information which is sent by the client and is used for the page loading process when the page loading is completed and/or receiving the page state information which is sent by the client and is used for the page running process when the page exits, and when the page stability parameter is larger than the set threshold value, the alarm information is generated. In the page execution process, the received page state information comprises script error state information or script normal state information, the specific occurrence times of script errors in the page do not need to be considered, one script error state information is recorded as long as the script errors occur, and one script normal state information is recorded as long as the script errors do not occur, so that the reported page state information and the user reporting the script execution state information are equivalent, and page stability parameters are determined according to the number of the messages containing the script error state information and the number of the messages containing the script normal state information, so that the accuracy for measuring the stability of the page script is higher and more objective, and the probability of false alarm can be reduced; and meanwhile, a set threshold is set, and when the page stability parameter is larger than the set threshold, alarm information is generated, so that script errors can be conveniently analyzed and processed in time.
Example III
The embodiment of the application is described from the client side.
Referring to fig. 7, a flowchart of another page script monitoring method embodiment of the present application is shown, and specifically may include the following steps:
step 701, determining script execution state in the page execution process.
In the embodiment of the application, when a user needs to access a certain page at a client, the client sends a page request to a corresponding application server, the application server returns corresponding page information according to the received page request, and the client loads and operates the page in a webpage of the client after receiving the page information; the script error in the page execution process is captured through a window/onerror function in the client, the script error can be determined to occur as long as one script error is captured in the page execution process, the script error is determined not to occur when the script error is not captured, and the script execution state in the page execution process is determined according to whether the window/onerror function captures the script error or not.
In a preferred embodiment of the application, determining script execution state in the page loading process; and/or determining script execution state in the page running process.
The script execution state can be monitored only in the page loading process, the script execution state can be monitored only in the page running process, and the script execution state can be monitored in both the page loading process and the page running process.
Step 702, a page status message including script execution status information is sent to a server, so that the server determines a page stability parameter according to the page status message belonging to the same page.
In the embodiment of the application, a client sends a page state message comprising script execution state information to a server, the server receives the page state message sent by the client, and the server determines a page stability parameter according to the page state message belonging to the same page.
The server may be the log monitoring server in fig. 1 or the application server in fig. 2. Specifically, script execution state information included in a page state message is detected, where the script execution state information includes: script error state information or script normal state information, and determining page stability parameters according to the script error state information and the script normal state information.
In a preferred embodiment of the application, when the page loading is completed, a page status message for the page loading process is sent to the server; and/or sending a page status message aiming at the page running process to the server when the page exits.
When the script execution state is monitored in the page loading process, and when the page loading is completed, namely when a window. Onload event is triggered, a page state message aiming at the page loading process is sent to a server, and the server calculates page stability parameters according to the page state message in the page loading process.
When the script execution state is monitored in the page running process, and when the page exits, namely when a window.before load event is triggered, a page state message aiming at the page running process is sent to a server, and the server calculates page stability parameters according to the page state message in the page running process.
When the page loading process and the page running process are both monitored, sending page state information aiming at the page loading process to the server, and when the page exits, sending page state information aiming at the page running process to the server, and calculating page stability parameters according to the page state information in the page loading process and the page state information in the page running process by the server.
According to the embodiment of the application, the script execution state in the page execution process is determined, and the page state information comprising the script execution state information is sent to the server, so that the server can determine the page stability parameter according to the page state information belonging to the same page. In the page execution process, the sent page state information comprises script error state information or script normal state information, the specific occurrence times of script errors in the page do not need to be considered, one script error state information is recorded as long as the script errors occur, and one script normal state information is recorded as long as the script errors do not occur, so that the reported page state information and the user reporting the script execution state information are equivalent, and the page script stability parameters are determined according to the number of the messages containing the script error state information and the number of the messages containing the script normal state information, so that the accuracy for measuring the page script stability is higher and more objective, and the probability of false alarm can be reduced.
Example IV
Referring to fig. 8, a block diagram of an embodiment of a page script monitoring apparatus according to an embodiment of the present application is mainly applied to a server 800, where the server 800 may be a log monitoring server in fig. 1 or an application server in fig. 2, and specifically may include the following modules:
a receiving module 801, configured to receive a page status message sent by a client in a page execution process; the page status message includes script execution status information.
The parameter determining module 802 is configured to determine a page stability parameter according to a page status message belonging to the same page.
Optionally, the script execution state information includes: script error state information or script normal state information.
Optionally, the receiving module 801 includes:
the first receiving sub-module is used for receiving a page state message which is sent by the client side when the page loading is completed and is aimed at the page loading process;
and/or the second receiving sub-module is used for receiving the page status message sent by the client in the page running process when the page exits.
Optionally, the parameter determining module 802 includes:
and the first parameter determination submodule is used for determining the proportion of the number of messages containing script error state information to the number of page state messages for the page state messages belonging to the same page, and obtaining the page stability parameter.
Optionally, the parameter determining module 802 includes:
and the second parameter determination submodule is used for determining the ratio of the number of messages containing script error state information to the number of messages containing script normal state information for page state messages belonging to the same page, and obtaining the page stability parameter.
Optionally, the first receiving sub-module includes:
the first receiving unit is used for receiving the page state message sent by the client through the window loading completion event;
the second receiving sub-module includes:
and the second receiving unit is used for receiving the page status message sent by the client through the window closing event.
Optionally, the page status message further includes a page identifier, and the parameter determining module 802 includes:
and the page stability parameter determination submodule is used for determining the page stability parameter according to the page state information which is determined to belong to the same page identifier.
Optionally, the apparatus further includes:
and the generation module is used for generating alarm information when the page stability parameter is larger than a set threshold value.
According to the embodiment of the application, the page state information in the page execution process sent by the client is received, the page state information comprises script execution state information, and the page stability parameter is determined according to the page state information belonging to the same page. In the page execution process, the received page state information comprises script execution state information, the specific occurrence times of script errors in the page do not need to be considered, one script error state information is recorded as long as the script errors occur, and one script normal state information is recorded as long as no script errors occur, so that the reported page state information is equivalent to a user reporting the script execution state information, and the page script stability parameters are determined according to the script execution state information, so that the accuracy for measuring the page script stability is higher and more objective, and the probability of false alarm can be reduced.
Example five
Referring to fig. 9, a block diagram of another embodiment of a page script monitoring apparatus according to an embodiment of the present application is mainly applied to a client 900, and may specifically include the following modules:
the script execution state monitoring module 901 is configured to determine a script execution state in a page execution process.
And a sending module 902, configured to send a page status message including script execution status information to a server, so that the server determines a page stability parameter according to the page status message belonging to the same page.
Optionally, the script execution state monitoring module 901 includes:
the first monitoring sub-module is used for determining script execution states in the page loading process;
and/or a second monitoring sub-module, which is used for determining script execution state in the page running process.
Optionally, the sending module 902 includes:
the first sending submodule is used for sending a page state message aiming at the page loading process to the server when the page loading is completed;
and/or the second sending submodule is used for sending a page state message aiming at the page running process to the server when the page exits.
According to the embodiment of the application, the script execution state in the page execution process is determined, and the page state information comprising the script execution state information is sent to the server, so that the server can determine the page stability parameter according to the page state information belonging to the same page. In the page execution process, the sent page state information comprises script error state information or script normal state information, the specific occurrence times of script errors in the page do not need to be considered, one script error state information is recorded as long as the script errors occur, and one script normal state information is recorded as long as the script errors do not occur, so that the reported page state information and the user reporting the script execution state information are equivalent, and the page script stability parameters are determined according to the number of the messages containing the script error state information and the number of the messages containing the script normal state information, so that the accuracy for measuring the page script stability is higher and more objective, and the probability of false alarm can be reduced.
For the device embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference is made to the description of the method embodiments for relevant points.
Fig. 10 is a schematic structural diagram of a server according to an embodiment of the present application. Referring to fig. 10, a server 800 may be used to implement the page script monitoring method provided in the above-described first and second embodiments. The server 800 may vary considerably in configuration or performance and may include one or more central processing units (central processing units, CPUs) 822 (e.g., one or more processors) and memory 832, one or more storage media 830 (e.g., one or more mass storage devices) storing applications 842 or data 844. Wherein the memory 832 and the storage medium 830 may be transitory or persistent. The program stored in the storage medium 830 may include one or more modules (not shown), each of which may include a series of instruction operations on a server. Still further, the central processor 822 may be configured to communicate with the storage medium 830 to execute a series of instruction operations in the storage medium 830 on the server 800.
The server 800 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input/output interfaces 858, one or more keyboards 856, and/or one or more operating systems 841, such as Windows ServerTM, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like. The central processor 822 may execute, among other things, the following instructions on the server 800:
receiving a page status message sent by a client in a page execution process; the page status message includes script execution status information;
and determining the page stability parameter according to the page state information belonging to the same page.
Optionally, the script execution state information includes: script error state information or script normal state information.
Optionally, receiving a page status message sent by the client side when the page loading is completed and aiming at the page loading process;
and/or receiving a page status message sent by the client in the page running process when the page exits.
Optionally, for the page status messages belonging to the same page, determining the proportion of the number of messages containing script error status information to the number of page status messages, and obtaining the page stability parameter.
Optionally, for the page status messages belonging to the same page, determining the ratio of the number of messages containing script error status information to the number of messages containing script normal status information, and obtaining the page stability parameter.
Optionally, receiving the page status message sent by the client through a window loading completion event; and receiving the page status message sent by the client through a window closing event.
Optionally, the page status message further includes a page identifier, and the page stability parameter is determined according to the page status message determined to belong to the same page identifier.
Optionally, when the page stability parameter is greater than a set threshold, generating alarm information.
The embodiment of the present application further provides a client 900, where the client 900 may be used to implement the page script monitoring method provided in the third embodiment.
The specific structure of the client 900 may refer to the schematic structure of the server shown in fig. 10, which is different in that the cpu of the client 900 and the cpu of the server 800 execute different operation instructions, which execute the client-side method.
The present application provides an apparatus, one or more machine readable media having instructions stored thereon, which when executed by the one or more processors, cause the apparatus to perform a page script monitoring method.
The present application also provides one or more machine-readable media having instructions stored thereon that, when executed by one or more processors, cause an apparatus to perform a page script monitoring method.
In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described by differences from other embodiments, and identical and similar parts between the embodiments are all enough to be referred to each other.
It will be apparent to those skilled in the art that embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the scope of the embodiments of the application.
Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or terminal device comprising the element.
The above detailed description of the method and apparatus for monitoring page script provided by the present application applies specific examples to illustrate the principles and embodiments of the present application, and the above description of the examples is only used to help understand the method and core ideas of the present application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present application, the present description should not be construed as limiting the present application in view of the above.