Log pushing method, system, device and storage medium

Abstract

The application discloses a log pushing method, system, device and storage medium, and relates to the technical field of computers.The log pushing method comprises the following steps: when a log file change event is detected and / or a log file state change is detected through timing polling, state information of a current log file is acquired, wherein the state information comprises a current file size; according to the current file size, the content of the current log file is incrementally read to obtain log increment content; and the log increment content is pushed to at least one subscribed client. The log file dynamic change is captured in parallel through two monitoring modes of log file change event monitoring and timing polling detection, and the real-time performance of log pushing is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a log push method, system, device and storage medium. Background Technology

[0002] In Windows platform LCD (Liquid Crystal Display) control card production line testing scenarios, it is necessary to monitor the log output of multiple test devices in real time to allow testers to view the status of each device promptly. However, existing log monitoring solutions mostly use a single file system event listener for log monitoring. Under the Windows platform, due to the file system caching mechanism, there are problems such as event triggering delays or even loss, resulting in log pushes lagging behind actual writes, making it difficult to detect device anomalies in a timely manner. Summary of the Invention

[0003] The main purpose of this application is to provide a log push method, system, device and storage medium, which aims to improve the real-time performance of log push.

[0004] To achieve the above objectives, this application proposes a log push method, the method comprising: When a log file change event is detected and / or the log file status is changed by periodic polling, the current log file status information is obtained, wherein the status information includes the current file size; Based on the current file size, the contents of the current log file are read incrementally to obtain the incremental log content; Push the incremental log content to at least one subscribed client.

[0005] In one embodiment, the step of incrementally reading the contents of the current log file based on the current file size to obtain incremental log content includes: Compare the current file size with the recorded file read position; If the current file size is greater than the file read position, then starting from the file read position, the contents of the current log file are read incrementally to obtain the incremental log content.

[0006] In one embodiment, before comparing the current file size with the recorded file read position, the method further includes: Compare the current file size with the recorded historical file sizes; If the current file size is smaller than the historical file size, then the file read position is reset to the beginning position of the current log file; If the current file size is greater than or equal to the historical file size, then the following step is performed: compare the current file size with the recorded file read position.

[0007] In one embodiment, the step of incrementally reading the contents of the current log file starting from the file reading position to obtain the incremental log content includes: Starting from the file reading position, read the contents of the current log file line by line according to the preset byte length to obtain the line content; Update the file read position according to the preset byte length; Based on the updated file read position, return to the execution steps: starting from the file read position, read the contents of the current log file line by line according to the preset byte length to obtain the line content, until the end position of the current log file is read; The read line content is summarized to obtain the incremental log content.

[0008] In one embodiment, before pushing the incremental log content to at least one subscribed client, the method further includes: Receive a subscription request sent by a client, wherein the subscription request carries a log file path and a client identifier; Check if the specified log file path is associated with a created log monitoring execution instance; If it does not exist, create a new log monitoring execution instance associated with the log file path, and start listening for log file change events and periodic polling detection for the log monitoring execution instance; The client identifier is stored in the client set corresponding to the log monitoring execution instance.

[0009] In one embodiment, pushing the incremental log content to at least one subscribed client includes: Match the corresponding log monitoring execution instance based on the log file path corresponding to the log increment content; Iterate through the client set under the log monitoring execution instance and push the incremental log content to the client corresponding to the client identifier in the client set.

[0010] In one embodiment, it further includes: Receive an unsubscribe request sent by a client, wherein the unsubscribe request includes a log file path and a client identifier; Based on the log file path, determine the corresponding log monitoring execution instance; Remove the client identifier from the client set of the log monitoring execution instance; When the client set is empty, stop listening to log file change events and periodic polling of the log monitoring execution instance, and remove the log monitoring execution instance from the system manager.

[0011] Furthermore, to achieve the above objectives, this application also proposes a log push system, which includes: The acquisition module is used to acquire the current status information of the log file when a log file change event is detected and / or when the log file status is detected by periodic polling, wherein the status information includes the current file size; The reading module is used to incrementally read the contents of the current log file according to the current file size to obtain the incremental log content; The log push module is used to push the incremental log content to at least one subscribed client.

[0012] In addition, to achieve the above objectives, this application also proposes a log push device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the log push method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the log push method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the log push method described above.

[0015] This application provides a log push method, system, device, and storage medium. The log push method includes: when a log file change event is detected and / or a log file status change is detected by periodic polling, obtaining the current log file status information, wherein the status information includes the current file size; incrementally reading the content of the current log file based on the current file size to obtain incremental log content; and pushing the incremental log content to at least one subscribed client. By simultaneously capturing dynamic changes in the log file through both log file change event monitoring and periodic polling detection, the real-time performance of log push is improved. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the log push method of this application in Embodiment 1; Figure 2 This is a schematic diagram of the module structure of the log push system according to an embodiment of this application; Figure 3 This is a schematic diagram of the device structure of the hardware operating environment involved in the log push method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or log push system capable of implementing the above functions. The following description uses a log push system as an example to illustrate this embodiment and the subsequent embodiments.

[0023] Based on this, this application provides a log push method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the log push method of this application in Embodiment 1.

[0024] Step S11: When a log file change event is detected and / or the log file status is changed by periodic polling, obtain the current log file status information; It should be noted that log file change events refer to system notification signals reported by the operating system's file monitoring interface after a write or modification operation has occurred in the log file. Periodic polling refers to a monitoring mechanism where the system proactively initiates file status checks at fixed time intervals.

[0025] It should be noted that the current log file refers to the log storage file used to record equipment operating parameters and abnormal fault information in the testing scenario of the LCD (Liquid Crystal Display) control card production line. The status information of the current log file refers to the basic file attribute data used to characterize the log file's storage size and modification records. The status information includes the current file size and timestamp of the current log file, where the current file size refers to the total length of bytes occupied by the current log file.

[0026] In this embodiment, the system's built-in log monitoring manager synchronously starts two sets of monitoring logics: file system event listening and timed polling checks, which run in parallel. When a log file change event is detected and / or the log file status is changed by timed polling, the current log file status information is obtained. The interval of timed polling can be customized and adjusted. Thus, when file system events fail to be triggered in time due to the system caching mechanism, timed polling can proactively detect file changes and trigger the processing flow, ensuring that the real-time push of logs does not depend on the notification timeliness of the operating system.

[0027] In one specific implementation, the log monitoring manager synchronously starts the fs.watch file event listener and a 50-millisecond periodic polling timer. When the LCD control card test device writes logs and triggers file modification, fs.watch immediately reports the log file change event, and the log monitoring manager then reads the total length of the current log file as the current file size. In addition, when the 50-millisecond polling period is reached, the system actively reads the log file size, compares it with historical records to identify file size changes, and also performs the operation of reading the current file size.

[0028] Step S12: Based on the current file size, incrementally read the contents of the current log file to obtain the incremental log content; It's important to note that incremental reading refers to reading the portion of the log file that has been updated since the last read operation, rather than rereading the entire log file each time. The purpose of incremental reading is to reduce the amount of data read and transmitted, improve log push efficiency, and avoid repeatedly reading processed historical log data. The incremental log content refers to the newly added log data between the last read position and the end of the current file. In one embodiment, after obtaining the current log file's status information, the current file size is compared with the recorded file read position to determine if there is any new content in the current log file. When the current file size is greater than the recorded file read position, the system determines that there is new content in the current log file. At this point, an incremental read process is triggered, that is, a file stream is created starting from the file read position, and data is read sequentially along the file until the end of the file indicated by the current file size is reached. In this way, the system performs incremental data read operations, minimizing disk I / O overhead and memory usage while ensuring log integrity.

[0029] In another embodiment, the system uses the recorded file read position as the starting read position, and reads the contents of the current log file line by line in batches with a preset byte length as the single read unit. After each line is read, the system updates the file read position by incrementing it according to the actual byte length of the line content, until the current file size is no greater than the file read position and the reading ends. Finally, all the read lines are summarized to obtain the log increment content.

[0030] Step S13: Push the incremental log content to at least one subscribed client.

[0031] It should be noted that the client refers to the front-end monitoring interface, test terminal, or analysis process that has successfully subscribed to the log file by submitting a subscription request to the system.

[0032] In this embodiment, after reading the incremental log content, the system obtains the log file path corresponding to the incremental log content, determines the corresponding log monitoring execution instance based on the log file path, traverses the client set under the log monitoring execution instance, and then pushes the incremental log content to the client corresponding to each client identifier in the client set. Through this method, the system achieves an efficient distribution mechanism of "read once, push multiple times," meaning the system only needs to perform one incremental read operation to distribute the same incremental log content to all subscribed clients.

[0033] This embodiment obtains the current log file's status information, including the current file size, when a log file change event is detected and / or when the log file status changes are detected through periodic polling. Based on the current file size, the content of the current log file is incrementally read to obtain incremental log content. This incremental log content is then pushed to at least one subscribed client. By simultaneously using both log file change event monitoring and periodic polling to capture dynamic changes in the log file, the real-time performance of log pushes is improved.

[0034] In one feasible implementation, the contents of the current log file are incrementally read according to the current file size to obtain incremental log content, including: Step S21: Compare the current file size with the recorded file read position; Step S22: If the current file size is greater than the file read position, then starting from the file read position, the contents of the current log file are read incrementally to obtain the incremental log content.

[0035] It should be noted that the recorded file read position refers to the file byte offset recorded by the system after performing the last incremental read operation. This position marks the end of the file that the system successfully read last time. The file read position is recorded and stored in bytes and serves as the starting reference point for the system to perform incremental read operations. The difference between the current file size and the recorded file read position is the amount of incremental data that the system needs to read this time.

[0036] In this embodiment, the current file size is compared with the recorded file read position to determine if there is any new content in the log file. Specifically, the system determines whether the current file size is greater than the recorded file read position. If the current file size is greater than the recorded file read position, it indicates that new log data has been written to the log file. The system performs an incremental read operation, reading the contents of the current log file from the file read position until the end of the current file to obtain the incremental log content. If the current file size is not greater than the recorded file read position, it indicates that there is no new content in the log file. The system directly ends the current processing and waits for the next monitoring trigger.

[0037] Additionally, it's important to note that the initial value of the recorded file read position is 0, indicating that the system will start reading from the beginning of the log file upon its first read operation. After each successful incremental read operation, the system updates the file read position to the current file size to ensure accurate positioning of the new starting position for the next incremental read. Through this position maintenance mechanism, the system can continuously track the progress of each read, avoiding repeated reading of processed historical log data and ensuring the accuracy and continuity of incremental reads.

[0038] In one specific implementation, the system obtains the current file size of the log file test.log as 1024000 bytes, and the recorded file read position is 512000 bytes. The system compares the current file size of 1024000 bytes with the recorded file read position of 512000 bytes, determining that 1024000 is greater than 512000, indicating that the log file has 512000 bytes of new content since the last read. The system creates a file stream starting from the 512000th byte position and reads up to the 1024000th byte position, reading a total of 512000 bytes of incremental data to obtain the current log increment content.

[0039] In another feasible implementation, the system needs to verify the validity of the file read position before starting incremental reading from the file read position. If the file read position is greater than the current file size, it indicates that the log file may have been truncated or the file has been recreated. The system will then trigger a file truncation processing procedure, reset the file read position to the beginning of the file, and then perform subsequent incremental reading operations.

[0040] In another feasible implementation, after the system completes the incremental read operation and obtains the incremental log content, it can temporarily store the incremental log content in the system memory buffer so that it can be re-pushed if the push fails, thereby improving the system's fault tolerance.

[0041] This embodiment achieves accurate determination of whether new content exists in the log file and its data volume by comparing the current file size with the recorded file read position, providing an accurate basis for incremental reading.

[0042] In one feasible implementation, before comparing the current file size with the recorded file read position, the method further includes: Step S31: Compare the current file size with the recorded historical file sizes; Step S32: If the current file size is smaller than the historical file size, then reset the file read position to the starting position of the current log file; Step S33: If the current file size is greater than or equal to the historical file size, then perform the step: compare the current file size with the recorded file read position.

[0043] It should be noted that the recorded historical file size refers to the total number of bytes in the log file recorded by the system after the last incremental read operation.

[0044] It's important to note that before comparing the current file size with the recorded file read position, a file truncation detection operation is performed first. File truncation detection compares the current file size with the recorded historical file size to determine if the current log file has been truncated since the last read. Specifically, it checks if the current file size is smaller than the historical file size. If the current file size is smaller than the historical file size, it indicates that the log file was truncated or cleared since the last read. Examples include scenarios where old files were cut or overwritten due to log rotation, the system administrator manually clearing the log file, or the application recreating the log file. In this case, the recorded file read position is reset to the beginning of the current log file (i.e., byte 0) to ensure that subsequent incremental read operations can start from the new file's beginning, avoiding data read failures or data loss due to the read position pointing to an invalid offset. If the current file size is greater than or equal to the historical file size, it indicates that the log file has not been truncated, and the system continues with the step of comparing the current file size with the recorded file read position.

[0045] In another feasible implementation, after a file truncation event is detected, in addition to resetting the read position, a truncation event log can be generated to record the time when the file truncation occurred, the file path, and the file size information before and after the truncation, which is convenient for subsequent operation and maintenance audits and troubleshooting.

[0046] For example, in one specific implementation, the system has recorded a historical file size of 1,024,000 bytes and a recorded file read position of 512,000 bytes. When the system detects a change in the log file test.log through periodic polling, it obtains the current file size as 20,480 bytes. The system compares the current file size 20,480 with the recorded historical file size of 1,024,000, determining that 20,480 is less than 1024,000, indicating that a log file truncation event has occurred (e.g., log rotation caused the old file to be cut, and the system created a new log file). The system resets the recorded file read position to 0, which is the beginning position of the current log file. Subsequently, the system continues to compare the current file size 20,480 with the reset file read position 0, determining that there are 20,480 bytes of new content, and reads all content starting from the beginning position of the file, ensuring that the truncated new log data can be completely read and pushed. This process avoids the problem of read out-of-bounds errors and data loss caused by the read position still pointing to 512,000 when the new file is only 20,480 bytes.

[0047] In another specific implementation, the system has recorded a historical file size of 1,024,000 bytes and a recorded file read position of 1,024,000 bytes. The system obtains the current file size as 1,536,000 bytes. The system compares the current file size of 1,536,000 bytes with the recorded historical file size of 1024,000 bytes and determines that 1,536,000 bytes is greater than 1024,000 bytes, indicating that no file truncation has occurred. The system continues to execute the step of comparing the current file size of 1,536,000 bytes with the recorded file read position of 1024,000 bytes, and determines that there is 512,000 bytes of newly added content. Incremental reading begins from file read position 1024,000.

[0048] This embodiment achieves automatic identification and intelligent processing of log file truncation events through the aforementioned file truncation detection mechanism. When a log file is truncated due to rotation or overwriting, the system can automatically reset the read position, ensuring the continuity, integrity, and accuracy of log data reading, and avoiding read position failure and data loss problems caused by file truncation.

[0049] In one feasible implementation, starting from the file read position, the contents of the current log file are read incrementally to obtain the incremental log content, including: Step S41: Starting from the file reading position, read the contents of the current log file line by line according to the preset byte length to obtain the line content; Step S42: Update the file read position according to the preset byte length; Step S43: Based on the updated file read position, return to the execution steps: Starting from the file read position, read the contents of the current log file line by line according to the preset byte length to obtain the line content, until the end position of the current log file is read; Step S44: Summarize the read line content to obtain the log incremental content.

[0050] In this embodiment, starting from the file reading position, the system reads the content of the current log file line by line according to a preset byte length, obtaining the line content. It should be noted that the preset byte length can be set according to actual conditions. Based on the preset byte length, the file reading position is updated; that is, after reading each line, the file reading position is updated to the current file reading position plus the preset byte length of that line. After updating the file reading position, the system uses the updated file reading position as the starting position for the next line and returns to execute the operation of reading the content of the current log file line by line according to the preset byte length until the end of the current log file is reached. Then, the read line content is summarized to obtain the log increment content. Summarizing means arranging the line content read line by line according to its original order in the log file and combining them into a complete log increment data set to maintain the original order and format integrity of the log content. Through the above-described cyclical line-by-line reading method, the system can accurately identify the boundary of each log record and precisely track the progress of each reading.

[0051] In one specific implementation, the system obtains that the current file size of the log file "test.log" is 15360 bytes, and the recorded file read position is 10240 bytes, a difference of 5120 bytes, indicating that new content has been added. Starting from byte 10240, the system creates a file read stream according to a preset byte length and reads the newly added log content line by line. The system reads the first line of log content, which is actually 48 bytes long, and updates the read position to byte 10288. It continues reading the second line, which is actually 52 bytes long, and updates the read position to byte 10340. The system continues reading line by line until the read position reaches byte 15360, reading a total of 100 lines of newly added log content, which are then summarized to obtain the incremental log content for this instance.

[0052] This application embodiment ensures that even if a program interruption or system abnormality occurs during the reading process, the reading can be resumed from the last successfully read position by reading line by line and accumulating the update position, thus avoiding data loss or duplication and ensuring the integrity and consistency of log data.

[0053] In one feasible implementation, before pushing the incremental log content to at least one subscribed client, the method further includes: Step S51: Receive a subscription request sent by the client, wherein the subscription request carries the log file path and the client identifier; It should be noted that a subscription request is a message initiated by a client to the system to request the receipt of real-time push content from a specified log file. The subscription request carries the log file path and the client identifier. The log file path refers to the complete path of the log file the client wishes to monitor within the file system, used to uniquely identify the log file to be subscribed to. The client identifier is the identity information used to uniquely identify the client instance.

[0054] In this embodiment, after receiving a subscription request from a client, the system parses the log file path and client identifier from the subscription request. Step S52: Query whether the log file path is associated with a created log monitoring execution instance; It should be noted that a log monitoring execution instance refers to a complete monitor object created by the system for a specific log file, used to perform continuous monitoring, reading, and push operations on that log file. The data structure of a log monitoring execution instance includes the following core attributes: file path, used to identify the current location of the monitored log file; file read position, used to record the last read byte position, initially set to 0; historical file size, used to record the file size at the time of the last read, initially set to 0, used to detect file truncation; file monitoring handle, i.e., the handle object for listening to file system events; timed polling timer, i.e., the timer object for periodic polling checks; and client collection, used to store the identifiers of all clients subscribed to this log file, supporting dynamic addition and removal.

[0055] Optionally, the system maintains a monitoring instance mapping table. The table uses the log file path as the key and the log monitoring execution instance as the value, allowing for quick queries to determine if a corresponding log monitoring execution instance already exists for a specified log file path. When the system receives a subscription request from a client, it uses the log file path carried in the subscription request as an index to query the monitoring instance mapping table to see if a log monitoring execution instance corresponding to that path already exists.

[0056] Step S53: If it does not exist, create a new log monitoring execution instance associated with the log file path, and start listening for log file change events and periodic polling detection for the log monitoring execution instance; In this embodiment, if the log file path is already associated with a created log monitoring execution instance, the system does not need to create the monitoring resource again. If the log file path is not associated with a created log monitoring execution instance, a new log monitoring execution instance associated with the log file path needs to be created. Creating a new log monitoring execution instance means that the system creates a new monitor object in memory and allocates independent storage space for it.

[0057] After creating the log monitoring execution instance, the system starts listening for log file change events and performing periodic polling detection for the instance. Specifically, the system calls the file monitoring interface provided by the operating system to register change event listeners on the file pointed to by the log file path. When a change is detected in the log file, the operating system immediately triggers a callback function, and the system then performs file change processing operations. Simultaneously, the system sets a periodic polling timer to periodically and proactively check the log file for new content at preset time intervals.

[0058] Step S54: Store the client identifier in the client set corresponding to the log monitoring execution instance.

[0059] It should be noted that a client collection refers to the storage of identifiers for all clients subscribing to this log file. Client collections support dynamic addition and removal of client identifiers and can accommodate multiple client identifiers simultaneously.

[0060] In this embodiment, the client identifier is parsed from the subscription request and added to the client set of the log monitoring execution instance. After completing the above storage operation, the client successfully subscribes to the log file. Subsequently, when the log file changes, the system will retrieve all client identifiers from the client set of the log monitoring execution instance and push the read incremental log content to the client corresponding to each client identifier.

[0061] It should be noted that when a client identifier already exists in the client set, the system can ignore this storage operation or return a subscription success response to avoid storing the same client identifier repeatedly. When multiple client identifiers are stored in the client set, the system will traverse the entire client set when performing log incremental content push, pushing the same log incremental content to each client in parallel, thereby achieving an efficient "read once, push multiple times" distribution mechanism.

[0062] In this embodiment, through the subscription management process described above, when any client initiates a subscription request, the system first checks whether the target log file is already being monitored. If it is, the existing log monitoring execution instance is reused directly; otherwise, a new monitoring instance is created and dual monitoring is started. The client identifier is then added to the client set to complete the subscription. In this way, multiple clients can subscribe to the same log file simultaneously without creating separate monitoring resources for each client. System resource overhead does not increase linearly with the number of clients, effectively solving the resource consumption problem when multiple clients concurrently subscribe to the same log file.

[0063] In one feasible implementation, it further includes: Step S61: Receive an unsubscribe request sent by the client, wherein the unsubscribe request includes the log file path and the client identifier; It should be noted that an unsubscribe request is a message initiated by the client to the system to request that it stop receiving real-time push content from a specified log file. The unsubscribe request carries the log file path and the client identifier.

[0064] It should be noted that the client can initiate an unsubscribe request in various scenarios. In one possible implementation, the client automatically sends an unsubscribe request to the system when the user closes the corresponding front-end monitoring interface. In another possible implementation, the client proactively sends an unsubscribe request to the system to release resources when it detects that its process is about to exit. In yet another possible implementation, the user manually triggers the unsubscribe operation through the unsubscribe button on the front-end interface, and the client accordingly sends an unsubscribe request to the system. In yet another possible implementation, the system can set a client timeout detection mechanism; when it detects that a client has no activity response within a preset time, the system proactively removes the client from the client set.

[0065] In this embodiment, after receiving the unsubscribe request sent by the client, the log file path and client identifier are parsed from the unsubscribe request for subsequent log monitoring execution instance determination and client removal operations.

[0066] Step S62: Determine the corresponding log monitoring execution instance based on the log file path; In this embodiment, the system uses the log file path carried in the unsubscribe request as an index to query the monitoring instance mapping table and determine the log monitoring execution instance corresponding to the log file path. After determining the corresponding log monitoring execution instance, it also needs to verify whether the client identifier carried in the unsubscribe request exists in the client set of the log monitoring execution instance. If the client identifier exists in the client set, the system continues to perform subsequent removal operations; if the client identifier does not exist in the client set, the system may return an error response or ignore this unsubscribe request.

[0067] Step S63: Remove the client identifier from the client set of the log monitoring execution instance; Step S64: When the client set is empty, stop the log file change event listening and timed polling of the log monitoring execution instance, and remove the log monitoring execution instance from the system manager.

[0068] It should be noted that the system call log monitoring execution instance removal method removes the client identifier from the client set.

[0069] It should be noted that after the system removes a client identifier from the client set, that client will no longer receive push content for that log file. In this case, if the system subsequently detects changes to the log file, it will no longer send log data to that client when performing incremental content pushes.

[0070] It should be noted that after removing the client identifier from the client set, the system checks whether the client set is empty. An empty client set indicates that no client is currently subscribed to the log file, meaning that the log monitoring execution instance no longer needs to execute monitoring tasks.

[0071] In this embodiment, when the client set is empty, the system performs a resource release operation. The resource release operation includes: stopping the log file change event listening of the log monitoring execution instance, i.e., closing the file monitoring handle and canceling file change event registration, so that the operating system no longer sends file change notifications to this instance; stopping the timed polling of the log monitoring execution instance, i.e., clearing the timed polling timer and releasing the timer resources, so that the system no longer periodically checks the status of the log file; closing the file handle held by the log monitoring execution instance and releasing file system resources; and removing the log monitoring execution instance from the monitoring instance mapping table, so that the log file path is no longer associated with any log monitoring execution instance. When a new client subscribes to this log file later, the system will recreate the log monitoring execution instance.

[0072] In this embodiment, through the resource release process described above, when any client unsubscribes, the system removes its identifier from the corresponding client set, and immediately stops all monitoring tasks and releases related resources when the client set is empty. Through this method, the system achieves coordinated release of monitoring resources and client subscription status. When all clients unsubscribe, the system automatically reclaims resources such as file monitoring handles, timers, and memory, effectively avoiding resource waste caused by ineffective monitoring and improving the overall system resource utilization.

[0073] It should be noted that the examples in the figure are only for understanding this application and do not constitute a limitation on the log push method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0074] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0075] This application also provides a log push system; please refer to [link / reference]. Figure 2 , Figure 2This is a schematic diagram of the module structure of the log push system according to an embodiment of this application; the log push system includes: The acquisition module 71 is used to acquire the status information of the current log file when a log file change event is detected and / or when the log file status is detected by periodic polling, wherein the status information includes the current file size; Reading module 72 is used to incrementally read the contents of the current log file according to the current file size to obtain the incremental log content; The log push module 73 is used to push the incremental log content to at least one subscribed client.

[0076] The reading module is also used for: Compare the current file size with the recorded file read position; If the current file size is greater than the file read position, then starting from the file read position, the contents of the current log file are read incrementally to obtain the incremental log content.

[0077] The reading module is also used for: Compare the current file size with the recorded historical file sizes; If the current file size is smaller than the historical file size, then the file read position is reset to the beginning position of the current log file; If the current file size is greater than or equal to the historical file size, then the following step is performed: compare the current file size with the recorded file read position.

[0078] The reading module is also used for: Starting from the file reading position, read the contents of the current log file line by line according to the preset byte length to obtain the line content; Update the file read position according to the preset byte length; Based on the updated file read position, return to the execution steps: starting from the file read position, read the contents of the current log file line by line according to the preset byte length to obtain the line content, until the end position of the current log file is read; The read line content is summarized to obtain the incremental log content.

[0079] The log push system is also used for: The first receiving module is used to receive a subscription request sent by the client, wherein the subscription request carries a log file path and a client identifier; The query module is used to query whether the log file path is associated with a created log monitoring execution instance; Create a module to create a new log monitoring execution instance associated with the log file path if it does not exist, and start listening for log file change events and periodic polling detection for the log monitoring execution instance; The storage module is used to store the client identifier in the client set corresponding to the log monitoring execution instance.

[0080] The reading module is also used for: Match the corresponding log monitoring execution instance based on the log file path corresponding to the log increment content; Iterate through the client set under the log monitoring execution instance and push the incremental log content to the client corresponding to the client identifier in the client set.

[0081] The log push system is also used for: The second receiving module is used to receive an unsubscribe request sent by the client, wherein the unsubscribe request includes a log file path and a client identifier; The determination module is used to determine the corresponding log monitoring execution instance based on the log file path; The removal module is used to remove the client identifier from the client set of the log monitoring execution instance; The stop module is used to stop the log file change event listening and timed polling of the log monitoring execution instance when the client set is empty, and to remove the log monitoring execution instance from the system manager.

[0082] The log push system provided in this application, employing the log push method in the above embodiments, can solve the technical problems described in the background section. Compared with the prior art, the beneficial effects of the log push system provided in this application are the same as those of the log push method provided in the above embodiments, and other technical features of the log push system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0083] This application provides a log push device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the log push method in the first embodiment described above.

[0084] The following is for reference. Figure 3 , Figure 3This is a schematic diagram of the device structure of the hardware operating environment involved in the log push method in this application embodiment. The log push device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The log push device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 3 As shown, the log push device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the log push device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the log push device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show log push devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0086] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0087] The log push device provided in this application, employing the log push method in the above embodiments, can solve the technical problems described in the background section. Compared with the prior art, the beneficial effects of the log push device provided in this application are the same as those of the log push method provided in the above embodiments, and other technical features of the log push device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0088] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0090] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the log push method in the above embodiments.

[0091] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable storage medium may be included in the log push device; or it may exist independently and not be assembled into the log push device.

[0093] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by the log push device, the log push device: when it detects a log file change event and / or periodically polls to detect a change in the log file status, it obtains the current log file status information, wherein the status information includes the current file size; based on the current file size, it incrementally reads the content of the current log file to obtain incremental log content; and pushes the incremental log content to at least one subscribed client.

[0094] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0097] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described log push method, and can solve the technical problems described in the background art. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the log push method provided in the above embodiments, and will not be repeated here.

[0098] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the log push method described above.

[0099] The computer program product provided in this application can solve the technical problems described in the background section. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as the beneficial effects of the log push method provided in the above embodiments, and will not be repeated here.

[0100] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A log push method, characterized in that, include: When a log file change event is detected and / or the log file status is changed by periodic polling, the current log file status information is obtained, wherein the status information includes the current file size; Based on the current file size, the contents of the current log file are read incrementally to obtain the incremental log content; Push the incremental log content to at least one subscribed client.

2. The log push method as described in claim 1, characterized in that, The step of incrementally reading the contents of the current log file based on the current file size to obtain the incremental log content includes: Compare the current file size with the recorded file read position; If the current file size is greater than the file read position, then starting from the file read position, the contents of the current log file are read incrementally to obtain the incremental log content.

3. The log push method as described in claim 2, characterized in that, Before comparing the current file size with the recorded file read position, the method further includes: Compare the current file size with the recorded historical file sizes; If the current file size is smaller than the historical file size, then the file read position is reset to the beginning position of the current log file; If the current file size is greater than or equal to the historical file size, then the following step is performed: compare the current file size with the recorded file read position.

4. The log push method as described in claim 2, characterized in that, The step of incrementally reading the contents of the current log file starting from the file reading position to obtain the incremental log content includes: Starting from the file reading position, read the contents of the current log file line by line according to the preset byte length to obtain the line content; Update the file read position according to the preset byte length; Based on the updated file read position, return to the execution steps: starting from the file read position, read the contents of the current log file line by line according to the preset byte length to obtain the line content, until the end position of the current log file is read; The read line content is summarized to obtain the incremental log content.

5. The log push method as described in claim 1, characterized in that, Before pushing the incremental log content to at least one subscribed client, the method further includes: Receive a subscription request sent by a client, wherein the subscription request carries a log file path and a client identifier; Check if the specified log file path is associated with a created log monitoring execution instance; If it does not exist, create a new log monitoring execution instance associated with the log file path, and start listening for log file change events and periodic polling detection for the log monitoring execution instance; The client identifier is stored in the client set corresponding to the log monitoring execution instance.

6. The log push method as described in claim 5, characterized in that, The step of pushing the incremental log content to at least one subscribed client includes: Match the corresponding log monitoring execution instance based on the log file path corresponding to the log increment content; Iterate through the client set under the log monitoring execution instance and push the incremental log content to the client corresponding to the client identifier in the client set.

7. The log push method as described in claim 1, characterized in that, Also includes: Receive an unsubscribe request sent by a client, wherein the unsubscribe request includes a log file path and a client identifier; Based on the log file path, determine the corresponding log monitoring execution instance; Remove the client identifier from the client set of the log monitoring execution instance; When the client set is empty, stop listening to log file change events and periodic polling of the log monitoring execution instance, and remove the log monitoring execution instance from the system manager.

8. A log push system, characterized in that, include: The acquisition module is used to acquire the current status information of the log file when a log file change event is detected and / or when the log file status is detected by periodic polling, wherein the status information includes the current file size; The reading module is used to incrementally read the contents of the current log file according to the current file size to obtain the incremental log content; The log push module is used to push the incremental log content to at least one subscribed client.

9. A log push device, characterized in that, The log push device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the log push method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the log push method as described in any one of claims 1 to 7.

Images