IO operation monitoring method, computer equipment, readable storage medium and program product

By installing an SDK on the client side, monitoring IO operations and creating events, the problem of high network resource consumption in existing technologies is solved, and more efficient IO operation data uploading and anomaly detection are achieved.

CN121008972APending Publication Date: 2025-11-25TENCENT MUSIC ENTERTAINMENT TECH (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511068028.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-31
Publication Date
2025-11-25

AI Technical Summary

Technical Problem

Existing real-time monitoring methods for I/O operations require frequent interaction with the server, resulting in significant network resource consumption.

Method used

By installing an SDK on the client, monitoring IO operations and creating IO events, recording operation data, and sending it all to the server for anomaly detection after the event ends, the frequency of connections between the client and the server is reduced.

Benefits of technology

It reduces network resource consumption, improves the accuracy of anomaly detection, and allows for flexible adjustment of detection logic on the server side without requiring client version updates.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121008972A_ABST
    Figure CN121008972A_ABST
Patent Text Reader

Abstract

The invention relates to an IO operation monitoring method, computer equipment, a readable storage medium and a program product. The method comprises the following steps: monitoring IO (Input / Output) operation of a user on a client through an SDK (Software Development Kit) installed on the client; when an IO operation representing start is monitored, creating an IO event corresponding to the IO operation; the IO event is used for recording all operation data of the IO operation from start to end; when it is monitored that the IO event is ended, all IO operation data corresponding to the IO event are sent to a server; and the server is used for carrying out anomaly detection on the received IO operation data. By adopting the method, the frequent connection between the client and the server can be reduced, the consumption of network resources is reduced, and meanwhile, the logic of anomaly detection can be flexibly modified on the server side without depending on the version update of the client.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to an I / O operation monitoring method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In computer systems, input / output (I / O) operations are the core mechanism for applications to interact with external devices such as storage, networks, and sensors. With increasing software complexity and the diversification of security threats, the need for real-time monitoring, analysis, and control of I / O operations is growing.

[0003] In related technologies, when collecting IO operation data, a method of real-time single-reporting of IO operations is adopted. However, this method requires frequent interaction between the client and the server, which consumes a lot of network resources. Summary of the Invention

[0004] Therefore, it is necessary to provide an I / O operation monitoring method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can reduce network resource consumption in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for monitoring I / O operations, including:

[0006] The SDK installed on the client monitors the user's I / O operations on the client.

[0007] When an I / O operation is detected, an I / O event corresponding to the I / O operation is created; the I / O event is used to record all operation data of the I / O operation from start to finish.

[0008] Upon detecting the end of the IO event, all IO operation data corresponding to the IO event are sent to the server; the server is used to perform anomaly detection on the received IO operation data.

[0009] In one embodiment, after creating the IO event corresponding to the IO operation when an IO operation indicative of its start is detected, the method further includes:

[0010] The IO events are added to a pre-built queue; the queue is used to maintain multiple IO events.

[0011] If the completion of any IO event in the queue is detected, all IO operation data corresponding to the IO event is sent to the server, and the IO event is removed from the queue.

[0012] In one embodiment, the I / O operation includes file operations; the method further includes:

[0013] When a file open operation is detected, an I / O event corresponding to the file is created based on the file path.

[0014] All subsequent operation data for the file will be written into the corresponding IO event of the file until a closing operation on the file is detected, at which point the IO event corresponding to the file will be determined to have ended.

[0015] In one embodiment, the monitoring of user I / O operations on the client via an SDK installed on the client further includes:

[0016] Based on the startup operation of the IO plugin in the SDK, basic configuration information for monitoring the IO operations of the client is received;

[0017] In addition, register a Hook function and replace the original IO operation function with the registered Hook function to collect the user's IO operation data on the client through the Hook function.

[0018] In one embodiment, after receiving the basic configuration information for monitoring the client's I / O operations, the method further includes:

[0019] Receive new configuration information sent by the server;

[0020] Update the basic configuration information in the SDK based on the new configuration information.

[0021] In one embodiment, the basic configuration information includes data collection rules; the method further includes:

[0022] According to the data collection rules in the basic configuration information, the user's IO operation data on the client is collected; wherein, the data collection rules include sampling rate, collection threshold for IO operation buffer size, and filtering rules.

[0023] In one embodiment, the server is further configured to adjust the detection strategy based on business requirement information, and perform anomaly detection on the received IO operation data according to the adjusted detection strategy.

[0024] Secondly, this application also provides an I / O operation monitoring device, comprising:

[0025] The monitoring module is used to monitor the user's I / O operations on the client through the SDK installed on the client.

[0026] A creation module is used to create an IO event corresponding to an IO operation when an IO operation is detected to indicate the start of the operation; the IO event is used to record all operation data of the IO operation from start to end.

[0027] The sending module is used to send all IO operation data corresponding to the IO event to the server when the IO event is detected to have ended; the server is used to perform anomaly detection on the received IO operation data.

[0028] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0029] The SDK installed on the client monitors the user's I / O operations on the client.

[0030] When an I / O operation is detected, an I / O event corresponding to the I / O operation is created; the I / O event is used to record all operation data of the I / O operation from start to finish.

[0031] Upon detecting the end of the IO event, all IO operation data corresponding to the IO event are sent to the server; the server is used to perform anomaly detection on the received IO operation data.

[0032] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0033] The SDK installed on the client monitors the user's I / O operations on the client.

[0034] When an I / O operation is detected, an I / O event corresponding to the I / O operation is created; the I / O event is used to record all operation data of the I / O operation from start to finish.

[0035] Upon detecting the end of the IO event, all IO operation data corresponding to the IO event are sent to the server; the server is used to perform anomaly detection on the received IO operation data.

[0036] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0037] The SDK installed on the client monitors the user's I / O operations on the client.

[0038] When an I / O operation is detected, an I / O event corresponding to the I / O operation is created; the I / O event is used to record all operation data of the I / O operation from start to finish.

[0039] Upon detecting the end of the IO event, all IO operation data corresponding to the IO event are sent to the server; the server is used to perform anomaly detection on the received IO operation data.

[0040] The aforementioned I / O operation monitoring methods, devices, computer equipment, computer-readable storage media, and computer program products monitor user I / O operations on the client side via an SDK installed on the client. When an I / O operation initiation is detected, an I / O event corresponding to the I / O operation is created, recording all operation data from the start to the end of this I / O operation. Upon detecting the end of the I / O event, all I / O operation data corresponding to the I / O event is sent to the server for anomaly detection. This method uploads I / O operation data for the entire process of each I / O operation from start to finish as one event. On the one hand, this reduces frequent connections between the client and server, lowering network resource consumption. On the other hand, by reporting complete I / O operation data for each operation, the problem detection process is shifted to the server side. Therefore, developers can flexibly modify the anomaly detection logic on the server side without relying on client version updates. Furthermore, anomaly detection based on complete I / O operation data on the server side improves the accuracy of the detection results. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating an I / O operation monitoring method in one embodiment;

[0043] Figure 2 This is a schematic diagram of the I / O stream processing flow for file operations in one embodiment;

[0044] Figure 3 This is a flowchart illustrating the IO operation monitoring method in another embodiment;

[0045] Figure 4 This is a schematic diagram illustrating the implementation process of the IO operation monitoring method in another embodiment;

[0046] Figure 5 This is a structural block diagram of an I / O operation monitoring device in one embodiment;

[0047] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. It should be noted that the terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more.

[0049] In one embodiment, such as Figure 1 As shown, an I / O operation monitoring method is provided. This embodiment illustrates the application of this method to a client. It should be noted that the product implementing this method can be in the form of a Software Development Kit (SDK). The client can add the SSDK for implementing this method through an automated project build open-source tool (which pre-downloads the SDK from a specific mirror source or adds the SDK locally). By enabling I / O monitoring during client startup, I / O monitoring can be performed during client usage. In this embodiment, the method includes the following steps:

[0050] Step S110: Monitor user IO operations on the client through the SDK installed on the client.

[0051] I / O operations, or Input / Output operations, are crucial processes in a computer system where the CPU (Central Processing Unit) exchanges information with external devices. I / O operations typically involve file reading and writing, network communication, database access, and hardware interaction. For example, reading a text file and sending a network request are both I / O operations.

[0052] In practice, developers pre-build a software development kit (SDK) for a certain type of application. When a user downloads / uses the client of that application, the SSD is simultaneously downloaded / loaded and connected to the client. After the connection is complete, the SSD can be used to monitor the user's I / O operations in the client of that application.

[0053] For example, developers create a software development kit (SDK) for a music application (such as A Music). When a user downloads the A Music mobile client, the A Music SSD is downloaded simultaneously. After the user installs the A Music mobile client, the corresponding SSD is integrated into the A Music mobile client. Once integrated, the A Music SSD can be used to monitor the user's I / O operations within the A Music mobile client.

[0054] For example, when a user launches the A Music mini-program, A Music's software development kit is simultaneously loaded into the mini-program, and the user's I / O operations in the A Music mini-program are monitored through A Music's software development kit.

[0055] Step S120: When an IO operation is detected to indicate the start of an IO operation, an IO event corresponding to the IO operation is created; the IO event is used to record all operation data from the start to the end of the IO operation.

[0056] The IO operation data may include the name of the IO operation, such as read or write, the file path, size (in bytes), start time, end time, duration, thread name, and call stack of the IO function (representing the function stack for developers to pinpoint the root cause of problems). It should be noted that the content of the IO operation data can be expanded according to actual needs.

[0057] It should be noted that an I / O operation represents a single action, while each I / O operation includes multiple I / O actions from start to finish. Examples include file opening, file reading, file writing, and file closing. Each I / O operation contains an action indicating the start, such as file opening, and an action indicating the end, such as file closing.

[0058] In this step, when an IO operation is detected to indicate the start of an IO stream, an IO event corresponding to this IO operation can be created. This IO event is used to record all operation data from the start to the end of this IO operation.

[0059] For example, when a file open operation is detected, an IO event corresponding to this file operation is created. This IO event is used to record all operation data of this file from opening to closing (such as opening, reading, writing, and closing).

[0060] Step S130: If the IO event is detected to have ended, all IO operation data corresponding to the IO event is sent to the server; the server is used to perform anomaly detection on the received IO operation data.

[0061] It should be noted that the end of an IO event indicates that the completion of the current IO operation has been detected, such as closing a file. When the end of an IO event is detected, it means that the current IO operation has been completed. All IO operation data corresponding to this IO event can be sent to the server, which will then analyze the data to perform anomaly detection.

[0062] For example, taking file operations as an example, when a file closing operation is detected, it means that the corresponding file has completed a complete set of "open-read / write operation-close" IO operation process. Then, the current file operation event ends, and all operation data of this file operation is sent to the server for anomaly analysis.

[0063] In one implementation, the IO operation data collected for each IO event can be stored locally first and then uploaded to the server later, thereby reducing the real-time performance burden of IO data collection on application operation.

[0064] In the aforementioned IO operation monitoring method, a client-side SDK is installed to monitor user IO operations. When an IO operation is detected, an IO event is created to record all operation data from start to finish. Upon the completion of the IO event, all IO operation data corresponding to that event is sent to the server for anomaly detection. This method uploads IO operation data as a single event for each IO operation, reducing frequent client-server connections and network resource consumption. Furthermore, by reporting complete IO operation data for each operation, the problem detection process is shifted to the server side. This allows developers to flexibly modify anomaly detection logic on the server side without relying on client version updates. Simultaneously, server-side anomaly detection based on complete IO operation data improves the accuracy of detection results.

[0065] In an exemplary embodiment, after step S120 detects an IO operation that indicates the start of an IO operation and creates an IO event corresponding to the IO operation, it further includes: adding the IO event to a pre-built queue; the queue is used to maintain multiple IO events; and when the end of any IO event in the queue is detected, sending all IO operation data corresponding to that IO event to the server and removing the IO event from the queue.

[0066] In the implementation, user I / O operations on the client side are handled as I / O streams. When an I / O operation is detected, a corresponding I / O event is created and added to a pre-built queue. This means a new element is added to the queue, representing a new I / O operation, such as opening a new file. Each I / O event (element) in the queue corresponds to all the specific operations of an I / O operation, such as opening, reading, writing, and closing a file. When any I / O event in the queue ends (e.g., a file close operation is received), it indicates that the corresponding I / O event has been completed. At this point, the I / O event can be removed from the queue, and all I / O operation data corresponding to that event is sent to the server for anomaly detection.

[0067] For example, see reference. Figure 2 This is a schematic diagram illustrating the processing flow of file operation I / O streams in one embodiment. When a file open operation (open / xxx / path) is detected, a corresponding I / O event is created, and a new element is added to the queue, indicating that a new file has been opened. This I / O event records all specific operations on the file. Intermediate operations on the file (such as read operations (read / xxx / path) and write operations (read / xxx / path)) are added to the I / O event created for that file. Each I / O event can be regarded as an I / O stream. When a file close operation (close / xxx / path) is detected, it indicates that the file has completed a set of operation processes. The corresponding I / O event can be removed from the queue, and all I / O operation data for that file can be sent to the server.

[0068] In this embodiment, an active IO queue is pre-built, and newly created IO events are added to this queue. After an IO event ends, all IO operation data corresponding to that IO event is sent to the server, and the IO event is removed from the queue. This allows multiple IO events (i.e., multiple IO streams) to be maintained through a single queue, ensuring that all IO operation data for each IO operation is uploaded to the server in an orderly and timely manner.

[0069] It is understood that there are many types of I / O operations, including file operations. In an exemplary embodiment, the method further includes: when a file open operation is detected, creating an I / O event corresponding to the file based on the file path; writing all subsequent operation data for the file into the I / O event corresponding to the file until a file close operation is detected, thus determining that the I / O event corresponding to the file has ended.

[0070] In practical implementation, for file operation type I / O operations, before creating the I / O event for this file operation when a file open operation is detected, the file path of the file to be operated on can be determined first. Using this file path as an identifier, the corresponding I / O event for that file is created. After subsequent operation data for that file is detected, the I / O event for that file in the queue is determined by the file path, and the operation data is written to this I / O event. This process continues until a file close operation is detected, completing the monitoring of the I / O event corresponding to that file.

[0071] For example, refer to Figure 2 Taking the third IO stream as an example, if the file path identifier is path3, then an IO event is created with path3 as the identifier and stored in the queue. Subsequently, when related operations on the file with the file path3 are detected, such as write operations (write / xxx / path3), they are added to the IO events of the third IO stream until a close operation (close / xxx / path3) is detected, and the monitoring of IO operations on that file ends.

[0072] In this embodiment, when a file open operation is detected, an IO event corresponding to the file is created based on the file path. This allows the file path to serve as the identifier for the IO event, so that subsequent operation data for this file can be written into the corresponding IO event, thereby achieving monitoring of the IO events for this file.

[0073] In an exemplary embodiment, before monitoring user IO operations on the client through the SDK installed on the client, step S110 further includes: receiving basic configuration information for monitoring client IO operations based on the startup operation of the IO plugin in the SDK; and registering a Hook function to replace the original IO operation function, so as to collect user IO operation data on the client through the Hook function.

[0074] The Hook function is used to collect data such as the time consumption of each I / O operation and file information.

[0075] In practice, developers pre-build a software development kit (SDK) for a specific type of application. When a user downloads / uses the client for that application, the SSD is simultaneously downloaded / loaded and integrated into the client. After integration, the IO plugin within the SSD is activated. The application's server performs basic configuration of the IO plugin, such as filtering rules (e.g., path filtering lists), read / write buffer thresholds, and sampling rates. Additionally, hook functions are registered, replacing the original IO operation functions. These hook functions then take over the original IO operation functions, collecting user IO operation data on the client according to the SDK's basic configuration information.

[0076] In this embodiment, by configuring the IO plugin in the SDK and registering the Hook function on the server side, the collection of IO operation data based on the basic configuration information of the SDK using the Hook function is realized. This facilitates the flexible adjustment of the monitoring strategy for IO operation data on the server side by adjusting the basic configuration information.

[0077] In one exemplary embodiment, the basic configuration information includes data collection rules; the method further includes: collecting user IO operation data on the client according to the data collection rules in the basic configuration information.

[0078] The data acquisition rules include sampling rate, acquisition threshold for I / O operation buffer size, and filtering rules.

[0079] Specifically, the basic configuration information consists of rules for monitoring client I / O operations. These rules can be viewed as data collection rules and may include sampling rate, I / O operation buffer size thresholds, and filtering rules. The I / O plugin in the software development kit collects client I / O operation data according to the configured data collection rules.

[0080] In some embodiments, the filtering rules can specifically be path filtering rules. For example, a path filtering list can be configured to filter files that do not need to be collected. For instance, if the regular expression used to filter paths is FilterPathList:"^socket", it means that files corresponding to paths starting with "socket" are filtered. Alternatively, FilterPathList:" "" means that the filtering list is set to empty, and no file read / write operations are filtered.

[0081] The threshold for collecting the buffer size of I / O operations, also known as the read / write buffer threshold, can be used to filter out file operations smaller than this threshold. For example, sizeThreshold: 1024 means that the size of the read / write buffer is set to 1024 bits, meaning that only read / write operations exceeding 1024 bits will be collected.

[0082] The sampling rate is used to control the number of samples taken, in order to reduce the amount of collected information reported. For example, ratio:0.1 means that the sampling rate is set to 0.1, indicating that only 10% of the IO operation data will be collected.

[0083] It should be noted that, in addition to the configuration information shown in this embodiment, the configuration rules of the software development kit can be extended according to actual needs. This method can extend the rules for collecting IO operation data in the client, improving the flexibility of the collection rules.

[0084] In one exemplary embodiment, after receiving the basic configuration information for monitoring the client's IO operations, the method further includes: receiving new configuration information sent by the server; and updating the basic configuration information in the SDK according to the new configuration information.

[0085] In practice, when changes in the scenario or client version require adjustments to the configuration information for monitoring client I / O operations, the new configuration information can be set on the server side and updated in the client's software development kit (SDK). The client user is unaware of this process. The new configuration information or initial basic configuration information can be sent to the client in JSON format and updated in the SSD to adapt to changes in the scenario or client version.

[0086] In practical applications, the server side is equipped with a console for developers to operate and a configuration center. Developers can modify configuration information in the console, and the configuration center obtains the configuration information from the console and updates it to the software development kit. In this way, the software development kit can adapt to different scenarios or client versions by dynamically modifying the configuration through the console.

[0087] It should be noted that the new configuration information contains similar content to the basic configuration information, and may include parameters such as filtering rules, sampling rate, I / O operation buffer size, and acquisition threshold, which will not be elaborated here.

[0088] In this embodiment, the basic configuration information in the SDK can be updated by modifying the configuration information on the server side to adapt to changes in the scenario or client version.

[0089] In one exemplary embodiment, the server is further configured to adjust the detection strategy based on business requirement information, and perform anomaly detection on the received IO operation data according to the adjusted detection strategy.

[0090] In practice, on the server side, a detection strategy can be initialized or a detection strategy can be determined based on business requirements. After the business requirements change, the detection strategy can be adjusted according to the new business requirements. Thus, after receiving IO operation data from the client, the received IO operation data can be anomaly detected according to the adjusted detection strategy.

[0091] The following example illustrates how this solution can be used to detect I / O issues. For instance, in some operating systems, the main thread is used for rendering the UI (User Interface) and responding to user actions; therefore, all time-consuming I / O operations should not occur on the main thread. The I / O operation data collected by this method includes the time and thread name of the I / O operation. Therefore, a strategy can be created to classify all I / O operations with a "thread" field set to "main" (i.e., occurring on the main thread) and a "duration" field indicating a duration greater than 13ms as "long-duration I / O operations on the main thread." This method allows for the rapid, batch detection of main thread I / O operation problems.

[0092] In this embodiment, the server receives IO operation data from the client and performs anomaly detection for the IO operation. This allows developers to flexibly modify the anomaly detection logic on the server side according to actual needs, without relying on client version updates. It also avoids the problem that anomaly detection on the client side can only change the parameters of the existing detection strategy, but cannot modify the detection strategy itself.

[0093] refer to Figure 3 The following is a flowchart illustrating an I / O operation monitoring method according to another embodiment. In this embodiment, the method includes the following steps:

[0094] Step S310: Based on the startup operation of the IO plugin in the SDK, receive basic configuration information for monitoring the IO operations of the client.

[0095] Step S320: Register a Hook function and replace the original IO operation function with the registered Hook function so that the user's IO operation data on the client can be collected through the Hook function according to the data collection rules in the basic configuration information.

[0096] The data acquisition rules include sampling rate, acquisition threshold for I / O operation buffer size, and filtering rules.

[0097] Step S330: When a file open operation is detected, an IO event corresponding to the file is created based on the file path, and the IO event is added to a pre-built queue.

[0098] The queue is used to maintain multiple IO events; each IO event is used to record all operation data of the corresponding IO operation from start to finish.

[0099] Step S340: If the end of any IO event in the queue is detected, all IO operation data corresponding to the IO event is sent to the server, and the IO event is removed from the queue; the server is used to perform anomaly detection on the received IO operation data.

[0100] On the server side, the detection strategy can be adjusted based on business requirements, and anomaly detection can be performed on the received IO operation data according to the adjusted detection strategy.

[0101] This method monitors user I / O operations on the client side using an SDK installed on the client. When an I / O operation is detected, an I / O event is created to record all operation data from start to finish. Upon the completion of the I / O event, all I / O operation data corresponding to that event is sent to the server for anomaly detection. This method uploads I / O operation data as a single event for each I / O operation, reducing frequent client-server connections and lowering network resource consumption. Furthermore, by reporting complete I / O operation data for each operation, the problem detection process is shifted to the server side. This allows developers to flexibly modify the anomaly detection logic on the server side without relying on client version updates. Simultaneously, anomaly detection based on complete I / O operation data on the server side improves the accuracy of the detection results.

[0102] To more clearly illustrate the IO operation monitoring method provided in the embodiments of this application, the following is in conjunction with the appendix. Figure 4 This plan will be further explained.

[0103] Figure 4 A flowchart illustrating the IO operation monitoring method of this application is shown. The software development kit (SDK) proposed in this application is used for integration into applications. The SDK includes a data collection module and a data processing module. The data collection module is used to hook the execution of functions performing IO operations on the client according to the monitoring strategy during startup. During program execution, it monitors and collects IO operations on the client through hook callback functions and submits them to the data collection module. The data processing module divides different IO operation streams according to the target file path of the IO operation (each IO operation stream corresponds to one IO event, such as...). Figure 2As shown, each IO operation, from start to finish, constitutes an IO operation stream and is stored. Each IO operation stream carries complete IO operation information and is reported to the console at the end for subsequent analysis. Software maintenance personnel can design anomaly detection strategies based on the raw IO operation data in the console to identify potential problems with IO operations. In the method provided in this application, each IO stream conforming to the monitoring strategy contains complete IO operation information for the target file from opening to closing, including operation time, operation type, operation size, etc., facilitating subsequent analysis of IO problems.

[0104] The specific implementation process is as follows:

[0105] (1) Initialization of configuration information.

[0106] After the application integrates the SDK and enables the IO plugin, developers initialize the basic configuration of the IO plugin in the configuration center, such as: Path filter list, read / write buffer threshold, and sampling rate. In addition to these configurations, the SDK can also extend the configuration items.

[0107] When a developer updates the configuration in the console, the configuration center retrieves the new configuration information and updates it in the SDK.

[0108] (2) Processing of configuration information.

[0109] The configuration center updates the initial configuration information obtained to the data acquisition module in the SDK, so that subsequent hook functions can process the data according to the configuration information when collecting data, such as filtering unnecessary system calls or collecting a fixed proportion of data according to the sampling rate.

[0110] (3) Register the Hook function.

[0111] Register a Hook function, and after completing the configuration registration, use the Hook function to replace the native IO operation function. Thus, when the application performs IO operations, the Hook function can take over the native IO operation function to trigger the data collection logic based on the configuration information in step (2).

[0112] (4) Data collection.

[0113] The Hook function collects time-consuming information and file information for each I / O operation and passes the collected data to the data collection module, which then reports it to the data processing module.

[0114] (5) Data upload.

[0115] The data processing module handles issues using I / O streams: when a file open operation occurs, the module adds a new element to the active I / O queue, indicating that a new file has been opened. Each element in the active I / O queue corresponds to all the specific operations of that I / O operation, such as open, read, write, and close. When the active I / O queue receives a file close operation, it means that the corresponding file has completed a complete I / O operation flow of open-read-write-close. At this time, the active I / O queue removes the I / O operation queue corresponding to this file from the active I / O queue and reports it to the console.

[0116] (6) After the console obtains the data from the client, it can perform anomaly detection through the detection strategy designed according to business requirements.

[0117] This method uploads IO operation data as a single event, representing the entire process from start to finish of each IO operation. This reduces frequent client-server connections and lowers network resource consumption. Furthermore, by reporting complete IO operation data for each operation, the problem detection process is shifted to the server side. This allows developers to flexibly modify anomaly detection logic on the server side without relying on client version updates. Additionally, server-side anomaly detection based on complete IO operation data improves the accuracy of detection results.

[0118] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0119] Based on the same inventive concept, this application also provides an I / O operation monitoring device for implementing the I / O operation monitoring method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more I / O operation monitoring device embodiments provided below can be found in the limitations of the I / O operation monitoring method described above, and will not be repeated here.

[0120] In one exemplary embodiment, such as Figure 5As shown, an I / O operation monitoring device is provided, including: a monitoring module 510, a creation module 520, and a sending module 530, wherein:

[0121] The monitoring module 510 is used to monitor user IO operations on the client through the SDK installed on the client.

[0122] Create module 520 to create an IO event corresponding to an IO operation when an IO operation is detected as starting; the IO event is used to record all operation data from the start to the end of the IO operation;

[0123] The sending module 530 is used to send all IO operation data corresponding to the IO event to the server when the IO event is detected to have ended; the server is used to perform anomaly detection on the received IO operation data.

[0124] In one embodiment, the creation module 520 is further configured to add IO events to a pre-built queue; the queue is used to maintain multiple IO events; when any IO event in the queue is detected to have ended, all IO operation data corresponding to that IO event is sent to the server, and the IO event is removed from the queue.

[0125] In one embodiment, the IO operation includes file operation; the creation module 520 is further configured to, when a file open operation is detected, create an IO event corresponding to the file according to the file path; write all subsequent operation data for the file into the IO event corresponding to the file until a file close operation is detected, and determine that the IO event corresponding to the file has ended.

[0126] In one embodiment, the device further includes an initialization module for receiving basic configuration information for monitoring client IO operations based on a startup operation of the IO plugin in the SDK; and registering a Hook function to replace the original IO operation function, so as to collect user IO operation data on the client through the Hook function.

[0127] In one embodiment, the apparatus further includes an update module for receiving new configuration information sent by the server and updating the basic configuration information in the SDK according to the new configuration information.

[0128] In one embodiment, the basic configuration information includes data collection rules; the device further includes a collection module for collecting user IO operation data on the client according to the data collection rules in the basic configuration information; wherein, the data collection rules include sampling rate, collection threshold for IO operation buffer size, and filtering rules.

[0129] In one embodiment, the server is further configured to adjust the detection strategy based on business requirement information, and perform anomaly detection on the received IO operation data according to the adjusted detection strategy.

[0130] Each module in the aforementioned I / O operation monitoring device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0131] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an I / O operation monitoring method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0132] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0133] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0134] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0135] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0136] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0137] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0138] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0139] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for monitoring I / O operations, characterized in that, The method includes: The SDK installed on the client monitors the user's I / O operations on the client. When an I / O operation is detected, an I / O event corresponding to the I / O operation is created; the I / O event is used to record all operation data of the I / O operation from start to finish. Upon detecting the end of the IO event, all IO operation data corresponding to the IO event are sent to the server; the server is used to perform anomaly detection on the received IO operation data.

2. The method according to claim 1, characterized in that, When an IO operation is detected to begin, after creating the IO event corresponding to the IO operation, the process further includes: The IO events are added to a pre-built queue; the queue is used to maintain multiple IO events. If the completion of any IO event in the queue is detected, all IO operation data corresponding to the IO event is sent to the server, and the IO event is removed from the queue.

3. The method according to claim 1, characterized in that, The I / O operations include file operations; the method further includes: When a file open operation is detected, an I / O event corresponding to the file is created based on the file path. All subsequent operation data for the file will be written into the corresponding IO event of the file until a closing operation on the file is detected, at which point the IO event corresponding to the file will be determined to have ended.

4. The method according to claim 1, characterized in that, The method of monitoring user IO operations on the client via an SDK installed on the client also includes: Based on the startup operation of the IO plugin in the SDK, basic configuration information for monitoring the IO operations of the client is received; In addition, register a Hook function and replace the original IO operation function with the registered Hook function to collect the user's IO operation data on the client through the Hook function.

5. The method according to claim 4, characterized in that, After receiving the basic configuration information for monitoring the client's I / O operations, the method further includes: Receive new configuration information sent by the server; Update the basic configuration information in the SDK based on the new configuration information.

6. The method according to claim 4, characterized in that, The basic configuration information includes data collection rules; the method further includes: According to the data collection rules in the basic configuration information, the user's IO operation data on the client is collected; wherein, the data collection rules include sampling rate, collection threshold for IO operation buffer size, and filtering rules.

7. The method according to claim 1, characterized in that, The server is also used to adjust the detection strategy based on business requirements information, and to perform anomaly detection on the received IO operation data according to the adjusted detection strategy.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.