A method and apparatus for sampling control of client monitoring events

Abstract

The application discloses a kind of client monitoring event sampling control method, comprising: periodically obtaining client running state index;According to client running index determines client sampling state;Current data transmission situation of client to server is expressed with fuse state;Current effective sampling rate of ordinary event under current sampling state is multiplied by current fuse rate, and the current effective sampling rate of high priority event with greater numerical value is set;Client monitoring SDK collects monitoring events in client according to different fuse states and different priorities of monitoring events;According to different fuse states, the current effective sampling rate of ordinary event and high priority event, the collected monitoring events are sampled and added to the client pending report queue.The application reduces the addition of ordinary events in the fault situation, suppresses the sampling state jitter and avoids premature recovery, and retains error diagnosis information and its context.

Description

Technical Field

[0001] This invention relates to a sampling control technology for client-side monitoring events. Background Technology

[0002] A client-side monitoring SDK (Software Development Kit) is a software development kit embedded in client-side (e.g., computer, mobile phone) applications (e.g., computer software, web browsers, mobile apps, mini-programs, etc.) to collect monitoring events such as user behavior, performance metrics, and errors on the client side, and generate monitoring data to be reported to the server.

[0003] Client-side monitoring SDKs typically do not collect 100% of monitoring events, but rather collect only a subset of events according to a sampling rate. Sampling rate settings include fixed ratios, dynamic ratios, server-side distribution rules, end-to-end consistent sampling based on association identifiers, and client-side throttling (adaptive circuit breaking and rate limiting) mechanisms.

[0004] Existing client-side event sampling and control technologies generally have the following shortcomings.

[0005] First, the sampling control of client-side monitoring events usually focuses on the pressure on the client sending side or the pressure on the server receiving side. It does not control the monitoring data before it enters the client's reporting queue, resulting in control lag, which leads to the expansion of the client's reporting queue and the increase in the client's local resource consumption.

[0006] Second, the decrease (reduction) and increase (recovery) of the sampling rate of client-side monitoring events are usually judged by a single indicator or simple rule. When the relevant indicator fluctuates around the threshold, it is easy to cause frequent adjustments to the sampling rate, which affects the stability of sampling control and data continuity.

[0007] Third, the increase (recovery) of the sampling rate of client monitoring events usually only considers a single inspection cycle. The sampling rate may recover prematurely because the relevant indicators in a single inspection cycle are temporarily normal, and then the sampling rate will drop (degrade) again due to the pressure rebound of the relevant indicators.

[0008] Fourth, when the sampling rate of client-side monitoring events decreases (reduces), the value of monitoring events is not distinguished, which may lead to the loss of monitoring events and their contexts for serious errors or serious performance anomalies.

[0009] Fifth, when the sampling rate of client-monitored events changes dynamically with the running status of the client application, it is difficult to maintain a consistent sampling rate under the same session, the same link, or the same page identifier.

[0010] Sixth, when a server-side failure occurs, the transmission of monitoring data is typically interrupted or rate-limited, but this usually only restricts the sending of data from the client's reporting queue, without reducing the generation and queuing of new monitoring data. Summary of the Invention

[0011] The technical problems to be solved by this invention are: how to control the length of the client's reporting queue based on the overall status of the server, client, and network transmission, so as to avoid the backlog of the reporting queue and the increase of local resource consumption on the client; how to avoid frequent adjustments to the sampling rate of client monitoring events or premature recovery due to brief normality; and how to distinguish the value of monitoring events to ensure that serious errors or serious performance abnormalities and their contexts are collected.

[0012] To address the aforementioned technical problems, this invention proposes a sampling control method for client monitoring events, comprising the following steps: Step S1: Periodically acquire client operating status indicators; the client operating status indicators include two or three of the following: queue backlog indicators, event rate indicators, and resource usage indicators; each client operating status indicator is assigned a degradation threshold and a recovery threshold; the recovery threshold for the same client operating status indicator is less than the degradation threshold, forming a hysteresis interval between them. Step S2: Determine the current sampling state of the client based on the client operating indicators; the client sampling state includes a normal state and a degradation state; the sampling rate of ordinary events in the normal state is greater than the sampling rate of ordinary events in the degradation state; the initial sampling state of the client is normal. When the client sampling state is normal, if any client operating status indicator exceeds its degradation threshold, the client sampling state changes from normal to degradation, and the continuous recovery count is set to 0. When the client sampling status is in a degraded state, if all client operating status indicators are lower than their recovery threshold, the current inspection cycle is determined to meet the recovery conditions, and the continuous recovery count is incremented by 1. When the continuous recovery count reaches the preset number of recovery cycles, the client's sampling status changes from degraded to normal. If the continuous recovery count does not reach the preset number of recovery cycles and the current inspection cycle does not meet the recovery conditions, the continuous recovery count is reset to 0. Step S3: Represent the current data transmission status from the client to the server using a circuit breaker status, divided into closed, open, and half-open states. Determine the circuit breaker ratio based on the current circuit breaker status: the circuit breaker ratio for the closed state > the circuit breaker ratio for the half-open state > the circuit breaker ratio for the fully open state. Steps S1 to S2 constitute the first group, and step S3 constitutes the second group. The order of the two groups can be either first or performed simultaneously. Step S4: Multiply the sampling rate of ordinary events in the current sampling state by the current circuit breaker ratio to obtain the current effective sampling rate of ordinary events; set the current effective sampling rate of high-priority events to be greater than the current effective sampling rate of ordinary events. Step S5: The client-side monitoring software development kit (SDK) collects monitoring events on the client side based on different fuse states and the different priorities of the monitoring events. These monitoring events are divided into three categories: high-priority events, normal events, and low-priority events. When the fuse is closed or partially open, high-priority, normal, and low-priority events are collected simultaneously. When the fuse is fully open, collection of low-priority events stops, and only high-priority and normal events are collected. Steps S4 and S5 can be performed either first or simultaneously. Step S6: The collected monitoring events are sampled according to different fuse states and the current effective sampling rates of normal and high-priority events, and added to the client's reporting queue. When the fuse is closed or partially open, high-priority events are sampled according to the current effective sampling rate of high-priority events, and normal and low-priority events are sampled according to the current effective sampling rate of normal events.When the fuse is fully open, sampling of low-priority events is stopped, and high-priority events and ordinary events are sampled according to the current effective sampling rate of high-priority events and the current effective sampling rate of ordinary events, respectively.

[0013] Furthermore, the queue backlog metric can be any one of the following: the length of the client-side reporting queue, the number of bytes occupied by the client-side reporting queue, the average waiting time of monitoring events in the client-side reporting queue, the number of monitoring events in the offline cache, or the number of events dropped. The event rate metric is the number of monitoring events collected per unit time. The resource usage metric can be any one of the following: client memory usage, CPU usage, network round-trip time (RTT), mobile memory pressure events, mini-program memory warning events, or resource usage information provided by the operating platform.

[0014] Furthermore, in step S2, when any client's operating metric is in the hysteresis interval, the client maintains its current sampling state.

[0015] Furthermore, the closed state of the fuse indicates that data transmission from the client to the server is normal; the open state of the fuse indicates that data transmission from the client to the server is completely interrupted; the half-open state of the fuse indicates that data transmission from the client to the server is in the process of tentative recovery; the fuse state simultaneously represents the server state and the network transmission state.

[0016] Furthermore, in step S5, the monitoring events include any one or more of error logs, network requests, performance metrics, page visits, clicks, exposures, security events, and business-defined events; high-priority events include any one or more of error logs, abnormal requests, security risk events, and severe performance anomaly events; low-priority events include any one or more of clicks, exposures, and ordinary page behavior events; all monitoring events other than high-priority and low-priority events are ordinary events.

[0017] Furthermore, in step S5, the client monitoring SDK also supplements the monitoring events with relevant information; the relevant information includes any one or more of application information, session identifier, device identifier, user identifier, page information, and operating environment information.

[0018] Further, in step S6, if the monitoring event carries an association identifier, the association identifier and sampling decision of the monitoring event are recorded in the client cache; the association identifier includes any one of session identifier, link identifier, page identifier, transaction identifier, or user identifier; the sampling decision includes whether to sample monitoring events of different priorities and the current effective sampling rate. Subsequently, if the monitoring event collected in step S1 does not carry an association identifier, or carries an association identifier that cannot be matched by the client cache, steps S2 to S6 are performed. Subsequently, if the monitoring event collected in step S1 carries a matching association identifier in the client cache, steps S2 to S5 are skipped, and the sampling decision corresponding to the association identifier in the client cache is directly reused in step S6.

[0019] Furthermore, in step S6, if the error log carries an association identifier and the error event is sampled, the error event and sampling decision are recorded in the client cache and marked as sampling priority. Subsequently, if the monitoring event collected in step S1 carries the same association identifier, steps S2 to S5 are skipped, and in step S6, the sampling decision corresponding to the association identifier in the client cache is directly reused, and priority sampling is performed according to the sampling priority mark.

[0020] Furthermore, in step S6, when the client's reporting queue reaches its capacity limit, high-priority events are retained first, low-priority events are discarded first, or low-priority old events are replaced with new high-priority events.

[0021] This invention also proposes a sampling control device for client monitoring events, including a client status checking module, a sampling status judgment module, a fuse status acquisition module, an effective sampling rate calculation module, a monitoring event acquisition module, and a monitoring event sampling queuing module. The client status checking module is used to periodically acquire client operating status indicators; these indicators include two or three of the following: queue backlog indicators, event rate indicators, and resource usage indicators; each client operating status indicator has a degradation threshold and a recovery threshold; the recovery threshold for the same client operating status indicator is less than the degradation threshold, forming a hysteresis interval between them. The sampling status judgment module is used to determine the current sampling status of the client based on the client's operating indicators. The client's sampling status includes a normal state and a degraded state. The sampling rate of ordinary events in the normal state is greater than that in the degraded state. The client's initial sampling status is normal. When the client's sampling status is normal, if any client operating status indicator exceeds its degraded threshold, the client's sampling status changes from normal to degraded, and the continuous recovery count is set to 0. When the client's sampling status is degraded, if all client operating status indicators are below their recovery thresholds, it is determined that the current inspection cycle meets the recovery conditions, and the continuous recovery count is incremented by 1. When the continuous recovery count reaches the preset number of recovery cycles, the client's sampling status changes from degraded to normal. If the continuous recovery count does not reach the preset number of recovery cycles and the current inspection cycle does not meet the recovery conditions, the continuous recovery count is reset to 0. The fuse status acquisition module represents the current data transmission status from the client to the server using fuse status, which is divided into three states: closed, open, and half-open. The fusing ratio is determined based on the current fuse status, with the fusing ratio for the closed state > the half-open state > the fully open state. The effective sampling rate calculation module multiplies the sampling rate of ordinary events in the current sampling state by the current fusing ratio to obtain the current effective sampling rate of ordinary events; the current effective sampling rate for high-priority events is set to be > the current effective sampling rate for ordinary events. The monitoring event acquisition module collects monitoring events on the client according to different fuse states and different priorities of the monitoring events; monitoring events are divided into three categories: high-priority events, ordinary events, and low-priority events. In the closed and half-open states, high-priority events, ordinary events, and low-priority events are collected simultaneously; in the fully open state, low-priority events are stopped from being collected, and only high-priority events and ordinary events are collected.The monitoring event sampling and queuing module is used to sample the collected monitoring events and add them to the client's reporting queue according to different fuse states, the current effective sampling rates of ordinary events and high-priority events. In the fuse closed and half-open states, high-priority events are sampled according to the current effective sampling rate of high-priority events, and ordinary events and low-priority events are sampled according to the current effective sampling rate of ordinary events. In the fuse fully open state, sampling of low-priority events is stopped, and high-priority events and ordinary events are sampled according to the current effective sampling rates of high-priority events and ordinary events, respectively.

[0022] The technical effects achieved by this invention are as follows: Sampling control is performed before monitoring events are added to the client's reporting queue, reducing the addition of ordinary events to the queue from the source when the network environment is poor, the server fails, or the client's pressure increases; Sampling status jitter is suppressed and premature recovery is avoided by judging through multiple client operating status indicators and using degradation thresholds, recovery thresholds, and continuous periodic confirmation mechanisms; The generation, queuing, and caching of ordinary events during faults are reduced by linking the fuse status with the sampling rate and the collection start / stop strategy; Error diagnosis information and its context are retained by prioritizing error event sampling and using associated identifier decision caching. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the sampling control method for client-side monitoring events proposed in this invention.

[0024] Figure 2 This is a schematic diagram of the sampling control device for client-side monitoring events proposed in this invention.

[0025] The attached diagrams are labeled as follows: 1. Client status check module; 2. Sampling status judgment module; 3. Fuse status acquisition module; 4. Effective sampling rate calculation module; 5. Monitoring event acquisition module; 6. Monitoring event sampling queuing module. Detailed Implementation

[0026] Please see Figure 1 The sampling control method for client monitoring events proposed in this invention includes the following steps.

[0027] Step S1: Periodically acquire client runtime status indicators according to the "check cycle". For example, the check cycle is 3000ms (milliseconds). The client runtime status indicators include at least two of the following three indicators, preferably all three. The first is the queue backlog indicator, such as the length of the client's pending reporting queue, the number of bytes occupied by the client's pending reporting queue, the average waiting time of monitoring events in the client's pending reporting queue, and the number of monitoring events in the offline cache or the number of dropped events. The second is the event rate indicator, such as the number of monitoring events collected per unit time. The third is the resource usage indicator, such as the client's memory usage, CPU usage, network RTT (Round-Trip Time), mobile memory pressure events, mini-program memory warning events, or resource usage information provided by the operating platform. For example, in a web browser environment, JavaScript heap memory usage information is obtained through the browser performance API (Application Programming Interface); in a Node.js environment, resource usage is obtained through process memory usage information; in a mini-program environment, memory pressure is judged through memory warning events provided by the mini-program; and in a mobile browser or WebView environment, resource pressure is judged by combining device memory information, memory pressure events, browser performance information, or preset estimation rules. Each client runtime status indicator has a separate degradation threshold and a recovery threshold; the recovery threshold is lower than the degradation threshold, thus forming a hysteresis interval. For example, the recovery threshold for each client runtime status indicator is set to 80% of the degradation threshold.

[0028] Step S2: Determine the current sampling state of the client based on client performance metrics. Divide the client into at least two sampling states—normal state and degraded state. The sampling rate r1 for ordinary events in the normal state is greater than the sampling rate r2 for ordinary events in the degraded state. For example, r1 is 1.0 and r2 is 0.3. The client's initial sampling state is the normal state.

[0029] When the client sampling status is in the normal state, if any client running status indicator exceeds its degradation threshold, the client sampling status will change from the normal state to the degradation state, and the continuous recovery count will be set to 0.

[0030] When a client's sampling status is in a degraded state, if all client operational status indicators are below their recovery thresholds, the current check period is deemed to meet the recovery conditions, and the continuous recovery count is incremented by 1. When the continuous recovery count reaches a preset number of recovery periods (e.g., 3), the client's sampling status changes from degraded to normal. If the continuous recovery count does not reach the preset number of recovery periods and the current check period does not meet the recovery conditions, the continuous recovery count is reset to 0. This recovery mechanism requires continuous fulfillment of recovery conditions. If, in any check period, the client's reporting queue becomes backlogged, the event rate is too high, or resource consumption is too high again, the accumulated recovery count is not retained but restarts from 0.

[0031] The recovery threshold for each client's operating metric is lower than the degradation threshold, forming a hysteresis interval between them. When any client's operating metric is in the hysteresis interval, the client maintains its current sampling state, thereby avoiding repeated switching of the client's sampling state.

[0032] Switching the client sampling state allows the client to promptly reduce the amount of ordinary events being enqueued when any of the following risks occur: backlog in the reporting queue, excessively high event rate, or excessively high resource consumption.

[0033] Step S3: Represent the current data transmission status from the client to the server using circuit breaker states, categorized into three types: closed, open, and half-open. A closed circuit breaker indicates normal data transmission from the client to the server. An open circuit breaker indicates that data transmission from the client to the server is completely cut off. A half-open circuit breaker indicates that data transmission from the client to the server is tentatively recovering. These three circuit breaker states simultaneously represent both the server's status and the network transmission status. The circuit breaker tripping ratio is determined based on the current circuit breaker state: closed > half-open > fully open. For example, the circuit breaker tripping ratio is 1.0 for the closed state, 0.3 for the half-open state, and 0.1 for the fully open state.

[0034] Steps S1 to S2 constitute the first group, and step S3 constitutes the second group. There is no strict restriction on the order between the two groups; either step can be performed first or simultaneously.

[0035] Step S4: Multiply the sampling rate of ordinary events under the current sampling state by the current circuit breaker multiplier to obtain the current effective sampling rate of ordinary events. Set the current effective sampling rate of high-priority events to be greater than the current effective sampling rate of ordinary events.

[0036] Step S5: The client-side monitoring SDK collects monitoring events on the client side based on different circuit breaker states and the different priorities of the monitoring events. These monitoring events include error logs, network requests, performance metrics, page visits, clicks, impressions, security events, and business-defined events. Monitoring events are divided into three categories: high-priority events, normal events, and low-priority events. High-priority events include, for example, error logs, abnormal requests, security risk events, and severe performance anomaly events. Low-priority events include, for example, clicks, impressions, and normal page behavior events. Monitoring events other than high-priority and low-priority events are considered normal events.

[0037] While the fuse is closed, high-priority events, normal events, and low-priority events are collected simultaneously.

[0038] While the fuse is half open, high-priority events, normal events, and low-priority events are collected simultaneously.

[0039] When the fuse is fully open, stop collecting low-priority events and only collect high-priority events and ordinary events.

[0040] In step S5, the client monitoring SDK further supplements the monitoring events with relevant information. This relevant information includes application information, session identifier, device identifier, user identifier, page information, and operating environment information.

[0041] The order of steps S4 and S5 is not strictly limited; either step can be performed first or simultaneously.

[0042] Step S6: Sample the monitoring events collected by the client monitoring SDK according to the current effective sampling rate of different fuse states, normal events and high priority events, and add them to the client's reporting queue.

[0043] With the fuse closed, high-priority events are sampled according to the current effective sampling rate, while ordinary and low-priority events are sampled according to the current effective sampling rate. This higher fuse coverage ensures comprehensive collection of monitoring data.

[0044] When the circuit breaker is half-open, high-priority events are sampled according to the current effective sampling rate of high-priority events, while ordinary and low-priority events are sampled according to the current effective sampling rate of ordinary events. In this state, the lower circuit breaker multiplier can control the number of new monitoring events during service recovery probing.

[0045] When the fuse is fully open, sampling of low-priority events is stopped, and high-priority events are sampled according to the current effective sampling rate of high-priority events, while ordinary events are sampled according to the current effective sampling rate of ordinary events, in order to retain fault diagnosis information.

[0046] In step S6, if the monitoring event carries an association identifier, the association identifier and sampling decision of the monitoring event are recorded in the client cache. The association identifier includes at least one of session identifier, link identifier, page identifier, transaction identifier, or user identifier. The sampling decision includes whether to sample monitoring events of different priorities and the current effective sampling rate. Subsequently, if the monitoring event collected in step S1 does not carry an association identifier, or carries an association identifier that cannot be matched by the client cache, steps S2 to S6 proceed normally. Subsequently, if the monitoring event collected in step S1 carries a matching association identifier in the client cache, steps S2 to S5 are skipped, and the sampling decision corresponding to the association identifier in the client cache is directly reused in step S6. For association identifiers and sampling decisions already written to the client cache, even if the client sampling state changes, the server fails, or the network transmission state changes, the client does not recalculate the sampling decision corresponding to the association identifier, but continues to reuse the existing sampling decision in the client cache until the cached item expires, is evicted, or is explicitly cleared, thereby maintaining the stability of sampling decisions within the same association dimension.

[0047] In step S6, if the error log carries an association identifier and the error event is sampled, the error event and sampling decision are recorded in the client cache and marked as sampling priority. Subsequently, if the monitoring events collected in step S1 (such as request logs, page browsing events, or click events) carry the same association identifier, steps S2 to S5 are skipped. In step S6, the sampling decision corresponding to the association identifier in the client cache is directly reused, and monitoring events carrying the same association identifier are sampled first according to the sampling priority mark. This increases the probability that the subsequent associated context events of the error event are retained, which is beneficial for restoring the user operation path before and after the error occurs.

[0048] In step S6, when the client's reporting queue reaches its capacity limit, it prioritizes retaining high-priority events and discarding low-priority events, or replaces low-priority old events with new high-priority events.

[0049] Please see Figure 2 The sampling control device for client monitoring events proposed in this invention includes a client status check module 1, a sampling status judgment module 2, a fuse status acquisition module 3, an effective sampling rate calculation module 4, a monitoring event acquisition module 5, and a monitoring event sampling queuing module 6. Figure 2 The device shown corresponds to Figure 1 The method shown.

[0050] The client status check module 1 is used to periodically acquire client operation status indicators according to a "check cycle". These indicators include two or three of the following: queue backlog indicator, event rate indicator, and resource usage indicator. Each client operation status indicator has a degradation threshold and a recovery threshold. The recovery threshold for the same client operation status indicator is lower than the degradation threshold, forming a hysteresis interval between them.

[0051] The sampling state judgment module 2 is used to determine the current sampling state of the client based on the client's operating indicators, which are at least divided into normal state and degraded state. The sampling rate of ordinary events in the normal state is greater than the sampling rate of ordinary events in the degraded state. The client's initial sampling state is normal. When the client's sampling state is normal, if any client operating state indicator exceeds its degraded threshold, the client's sampling state changes from normal to degraded, and the continuous recovery count is set to 0. When the client's sampling state is degraded, if all client operating state indicators are below their recovery thresholds, it is determined that the current check cycle meets the recovery conditions, and the continuous recovery count is incremented by 1. When the continuous recovery count reaches a preset number of recovery cycles, the client's sampling state changes from degraded to normal. If the continuous recovery count does not reach the preset number of recovery cycles and the current check cycle does not meet the recovery conditions, the continuous recovery count is reset to 0.

[0052] The fuse status acquisition module 3 is used to represent the current data transmission status from the client to the server in terms of fuse status, which is divided into three types: closed, open, and half-open. The fusing ratio is determined according to the current fuse status, with the fusing ratio of the closed state > the fusing ratio of the half-open state > the fusing ratio of the fully open state.

[0053] The effective sampling rate calculation module 4 is used to multiply the sampling rate of ordinary events under the current sampling state by the current circuit breaker ratio to obtain the current effective sampling rate of ordinary events; and to set the current effective sampling rate of high-priority events to be greater than the current effective sampling rate of ordinary events.

[0054] The monitoring event acquisition module 5 is used to collect monitoring events on the client side according to different fuse states and different priorities of the monitoring events. Monitoring events are divided into three categories: high-priority events, normal events, and low-priority events. When the fuse is closed or partially open, high-priority, normal, and low-priority events are collected simultaneously. When the fuse is fully open, low-priority events are stopped from being collected, and only high-priority and normal events are collected.

[0055] The monitoring event sampling and queuing module 6 is used to sample the collected monitoring events and add them to the client's reporting queue according to different fuse states and the current effective sampling rates of ordinary and high-priority events. In the fuse closed and half-open states, high-priority events are sampled according to the current effective sampling rate of high-priority events, and ordinary and low-priority events are sampled according to the current effective sampling rate of ordinary events. In the fuse fully open state, sampling of low-priority events stops, and high-priority events and ordinary events are sampled according to the current effective sampling rates of high-priority events and ordinary events, respectively.

[0056] Compared with the prior art, the present invention has the following beneficial effects.

[0057] First, this invention controls the collection and sampling of monitoring events before they are added to the client's reporting queue. This reduces the number of new events added to the queue, lowers the length of the client's reporting queue, and reduces the amount of offline cached monitoring events, thus reducing the risk of further increases in client memory usage when the network environment is poor, the server is abnormal, or the number of client monitoring events suddenly increases.

[0058] Second, this invention utilizes multiple client runtime status indicators (at least two) simultaneously, rather than solely relying on server quotas or monitoring data transmission failure results, to sample and control client monitoring events. Even if the server-side policy has not yet been issued, the client can perform self-protective sampling control based on its local runtime status.

[0059] Third, this invention sets two thresholds for each client's operating state, with the recovery threshold lower than the degradation threshold, forming a hysteresis interval between them. When any client's operating state indicator fluctuates around any threshold, the client will not frequently switch sampling states due to a single exceedance or fallback, thereby improving the stability of sampling control.

[0060] Fourth, this invention requires all client operating status indicators to be below the recovery threshold and to continuously meet a preset number of check cycles before the sampling rate can be restored (increased); if any check cycle is not met, the recovery count is reset. Therefore, the normal sampling rate is only restored after the client pressure has continuously subsided, which can reduce the probability of a relapse after recovery.

[0061] Fifth, this invention reflects the network transmission status and server status through the circuit breaker state. In the half-open or fully-open circuit breaker state, it reduces the effective sampling rate of ordinary events by a smaller circuit breaker multiplier, and in the fully-open circuit breaker state, it stops collecting low-priority monitoring events. Therefore, it not only reduces the number of monitoring data sending requests but also reduces the subsequent collection, queuing, and caching of ordinary monitoring events on the client side.

[0062] Sixth, this invention employs a higher sampling priority (higher sampling rate) for high-priority monitoring events. Even if ordinary events are downsampled or circuit-breaker protected, this invention still prioritizes the retention of high-priority monitoring events and can retain the context of the same session or link through associated identifier caching.

[0063] Seventh, this invention uses a higher sampling rate under normal client conditions to ensure the integrity of monitoring data, and reduces the sampling rate of ordinary events under pressure or failure conditions on the client, network or server to protect the client. The sampling rate is automatically restored after the pressure stabilizes and subsides, thereby achieving a balance between data integrity, transmission cost and client performance.

[0064] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A sampling control method for client-side monitoring events, characterized in that, Includes the following steps; Step S1: Periodically acquire client running status indicators; the client running status indicators include two or three of the following: queue backlog indicators, event rate indicators, and resource usage indicators; each client running status indicator is set with a degradation threshold and a recovery threshold; the recovery threshold of the same client running status indicator is less than the degradation threshold, and a hysteresis interval is formed between the two. Step S2: Determine the current sampling state of the client based on the client's operating metrics. The client's sampling state includes normal state and degraded state. The sampling rate of ordinary events in the normal state is greater than the sampling rate of ordinary events in the degraded state. The initial sampling state of the client is normal state. When the client sampling status is in the normal state, if any client running status indicator exceeds its degradation threshold, the client sampling status will be changed from the normal state to the degradation state, and the continuous recovery count will be set to 0. When the client sampling status is in a degraded state, and when all client running status indicators are lower than their recovery threshold, it is determined that the current inspection cycle meets the recovery conditions, and the continuous recovery count is incremented by 1; When the continuous recovery count reaches the preset number of recovery cycles, the client's sampling status changes from degraded status to normal status. If the continuous recovery count value does not reach the preset number of recovery cycles and the current inspection cycle does not meet the recovery conditions, the continuous recovery count will be reset to 0. Step S3: Represent the current data transmission status from the client to the server using the fuse state, which is divided into closed state, open state, and half-open state; determine the fusing ratio based on the current fuse state, with the fusing ratio of the closed state > the fusing ratio of the half-open state > the fusing ratio of the fully open state. Steps S1 to S2 constitute the first group, and step S3 constitutes the second group. Either step can be performed first or simultaneously between the two groups. Step S4: Multiply the sampling rate of ordinary events under the current sampling state by the current circuit breaker ratio to obtain the current effective sampling rate of ordinary events; set the current effective sampling rate of high-priority events to be greater than the current effective sampling rate of ordinary events; Step S5: The client monitoring software development kit (SDK) collects monitoring events on the client according to different fuse states and different priorities of the monitoring events; the monitoring events are divided into three categories: high-priority events, normal events, and low-priority events. While the fuse is in both closed and partially open states, high-priority events, normal events, and low-priority events are collected simultaneously. When the fuse is fully open, stop collecting low-priority events and only collect high-priority events and ordinary events. The order of steps S4 and S5 can be either first or simultaneously. Step S6: Sample the collected monitoring events according to the current effective sampling rate of different fuse states, normal events and high priority events, and add them to the client's reporting queue; When the fuse is closed or half-open, high-priority events are sampled according to the current effective sampling rate of high-priority events, and ordinary and low-priority events are sampled according to the current effective sampling rate of ordinary events. When the fuse is fully open, sampling of low-priority events is stopped, and high-priority events and ordinary events are sampled according to the current effective sampling rate of high-priority events and the current effective sampling rate of ordinary events, respectively.

2. The sampling control method for client monitoring events according to claim 1, characterized in that, The queue backlog metric can be any one of the following: length of the client-side reporting queue, number of bytes occupied by the client-side reporting queue, average waiting time of monitoring events in the client-side reporting queue, number of monitoring events in the offline cache, or number of events dropped. The event rate metric is the number of monitoring events collected per unit time. The resource usage metrics can be any one of the following: client memory usage, CPU usage, network round-trip time (RTT), mobile memory pressure events, mini-program memory warning events, or resource usage information provided by the operating platform.

3. The sampling control method for client monitoring events according to claim 1, characterized in that, In step S2, when any client's operating metric is in the hysteresis interval, the client maintains its current sampling state.

4. The sampling control method for client monitoring events according to claim 1, characterized in that, The closed state of the fuse indicates that data transmission from the client to the server is normal; the open state of the fuse indicates that data transmission from the client to the server is completely interrupted; the half-open state of the fuse indicates that data transmission from the client to the server is tentatively recovering; the fuse state simultaneously represents the server state and the network transmission state.

5. The sampling control method for client monitoring events according to claim 1, characterized in that, In step S5, the monitoring events include any one or more of error logs, network requests, performance metrics, page visits, clicks, exposures, security events, and business-defined events. High-priority events include any one or more of error logs, abnormal requests, security risk events, and severe performance anomaly events; Low-priority events include any one or more of clicks, impressions, and ordinary page behavior events; monitoring events other than high-priority and low-priority events are all ordinary events.

6. The sampling control method for client monitoring events according to claim 1, characterized in that, In step S5, the client monitoring SDK also supplements the monitoring events with relevant information; the relevant information includes any one or more of application information, session identifier, device identifier, user identifier, page information, and runtime environment information.

7. The sampling control method for client monitoring events according to claim 1, characterized in that, In step S6, if the monitoring event carries an association identifier, the association identifier and sampling decision of the monitoring event are recorded in the client cache; the association identifier includes any one of session identifier, link identifier, page identifier, transaction identifier or user identifier; the sampling decision includes whether to sample monitoring events of different priorities and the current effective sampling rate. Subsequently, if the monitoring event collected in step S1 does not carry an association identifier, or carries an association identifier that cannot be matched by the client cache, then proceed to steps S2 to S6. Subsequently, if the monitoring event collected in step S1 carries a matching association identifier in the client cache, then step S2 is skipped to step S5, and the sampling decision corresponding to the association identifier in the client cache is directly reused in step S6.

8. The sampling control method for client monitoring events according to claim 7, characterized in that, In step S6, if the error log carries an association identifier and the error event is sampled, the error event and the sampling decision are recorded in the client cache and marked as sampling priority. Subsequently, if the monitoring events collected in step S1 carry the same association identifier, step S2 to step S5 is skipped. In step S6, the sampling decision corresponding to the association identifier in the client cache is directly reused, and priority sampling is performed according to the sampling priority mark.

9. The sampling control method for client monitoring events according to claim 1, characterized in that, In step S6, when the client's reporting queue reaches its capacity limit, high-priority events are retained first, low-priority events are discarded first, or low-priority old events are replaced with new high-priority events.

10. A sampling control device for client-side monitoring events, characterized in that, It includes a client status check module, a sampling status judgment module, a fuse status acquisition module, an effective sampling rate calculation module, a monitoring event acquisition module, and a monitoring event sampling queuing module; The client status check module is used to periodically acquire client running status indicators; the client running status indicators include two or three of the following: queue backlog indicators, event rate indicators, and resource usage indicators; each client running status indicator is set with a degradation threshold and a recovery threshold; the recovery threshold of the same client running status indicator is less than the degradation threshold, and a hysteresis interval is formed between the two. The sampling status judgment module is used to determine the current sampling status of the client based on the client's operating indicators. The client's sampling status includes a normal state and a degraded state. The sampling rate of ordinary events in the normal state is greater than that in the degraded state. The client's initial sampling status is normal. When the client's sampling status is normal, if any client operating status indicator exceeds its degraded threshold, the client's sampling status changes from normal to degraded, and the continuous recovery count is set to 0. When the client's sampling status is degraded, if all client operating status indicators are lower than their recovery thresholds, it is determined that the current inspection cycle meets the recovery conditions, and the continuous recovery count is incremented by 1. When the continuous recovery count reaches the preset number of recovery cycles, the client's sampling status changes from degraded status to normal status. If the continuous recovery count value does not reach the preset number of recovery cycles and the current inspection cycle does not meet the recovery conditions, the continuous recovery count will be reset to 0. The fuse status acquisition module is used to represent the current data transmission status from the client to the server in terms of fuse status, which is divided into three types: closed, open, and half-open. The fusing ratio is determined according to the current fuse status, with the fusing ratio of the closed state > the fusing ratio of the half-open state > the fusing ratio of the fully open state. The effective sampling rate calculation module is used to multiply the sampling rate of ordinary events under the current sampling state by the current circuit breaker ratio to obtain the current effective sampling rate of ordinary events; and to set the current effective sampling rate of high-priority events to be greater than the current effective sampling rate of ordinary events. The monitoring event acquisition module is used to acquire monitoring events on the client side according to different fuse states and different priorities of monitoring events. Monitoring events are categorized into three types: high-priority events, normal events, and low-priority events. High-priority events, normal events, and low-priority events are collected simultaneously in both the closed and partially open states of the fuse. When the fuse is fully open, stop collecting low-priority events and only collect high-priority events and ordinary events. The monitoring event sampling and queuing module is used to sample the collected monitoring events and add them to the client's reporting queue according to different fuse states, the current effective sampling rate of ordinary events and high-priority events; in the fuse closed state and half-open state, high-priority events are sampled according to the current effective sampling rate of high-priority events, and ordinary events and low-priority events are sampled according to the current effective sampling rate of ordinary events. When the fuse is fully open, sampling of low-priority events is stopped, and high-priority events and ordinary events are sampled according to the current effective sampling rate of high-priority events and the current effective sampling rate of ordinary events, respectively.

Images