Log management methods, devices, equipment and media

Abstract

This invention relates to the field of R&D management technology, disclosing a log management method, apparatus, device, and computer-readable storage medium. The method includes: acquiring communication data, extracting communication content and communication status attributes, and determining the corresponding data type based on the communication status attributes; collecting communication data timestamps, combining them with random strings to generate a unique identifier for the communication data; constructing a communication data log object by combining the unique identifier, data type, and communication content; storing the log object at the tail of a log queue, and counting the number of log objects in the queue in real time; removing the log object at the head of the queue when the number of logs exceeds a set threshold; and, upon receiving an export command from the front-end debugging interface, converting all log objects in the queue into a specified format string and pushing it to a preset storage area on the front end to complete the log export. This invention can be applied to business system platforms in fintech, healthcare, and other fields, and can solve the problem of low accuracy in log location and traceability.

Description

Technical Field

[0001] This invention relates to the field of research and development management technology, and in particular to a log management method, apparatus, device and medium. Background Technology

[0002] In real-time communication systems such as chatbots, the front-end and back-end typically use the WebSocket protocol for bidirectional message exchange to achieve core functions such as user-to-human communication, message push, and status synchronization. Due to the asynchronous and real-time nature of WebSocket communication, the transmitted message content and connection status are difficult to directly capture and record on the front-end. Therefore, to meet the needs of independent debugging and analysis of WebSocket communication on the front-end, structured recording and dynamic management of message logs are necessary to improve the accuracy of problem localization.

[0003] In the healthcare field, front-end and back-end communicate in real time via WebSocket to transmit data such as consultation dialogues, medical order pushes, and synchronized treatment status. Under current technology, the front-end relies on back-end logs to troubleshoot communication anomalies, making it difficult to directly capture WebSocket message content and status. There is also a lack of structured message recording, resulting in cumbersome debugging processes, easily missing logs, and difficulties in reproducing problems. Ultimately, this leads to low accuracy in locating medical WebSocket communication problems and tracing message origins.

[0004] In the fintech business, front-end and back-end use WebSocket to transmit core data such as trading instructions, fund changes, market data updates, and account status synchronization in real time. With current technology, the front-end cannot independently capture WebSocket message content and communication status, relying on back-end logs to locate anomalies. This lack of structured logging makes logs prone to loss, problems difficult to reproduce, and debugging inefficient, ultimately resulting in low accuracy in troubleshooting and tracing financial transaction communication anomalies.

[0005] In existing technologies, front-end developers typically rely on back-end logging systems to capture WebSocket communication content and troubleshoot issues by querying the request and response logs recorded by the back-end. However, due to the asynchronous and real-time nature of WebSocket, back-end logs may experience message loss or incomplete recording, and the front-end cannot actively correlate the sending and receiving sequence of messages. This leads to the debugging process relying on manual comparison, which is inefficient and ultimately results in low accuracy in message status tracking. Summary of the Invention

[0006] This invention provides a log management method, apparatus, device, and medium to address the problem of low accuracy in log location and traceability.

[0007] Firstly, a log management method is provided, the method comprising: Acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes; Obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; Using the unique identifier, the data type, and the communication content, a log object of the communication data is constructed; Store the log object at the tail of a preset log queue, and count the number of log objects already stored in the log queue. When the number of log objects exceeds a preset threshold, remove the log object at the head of the queue; When an export command is received from the preset front-end debugging interface, all log objects in the log queue are converted into strings of a preset format, and the strings are output to the preset front-end storage area.

[0008] Secondly, a log management device is provided, the device comprising: The data type identification module is used to acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes. A unique identifier generation module is used to obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; A log object construction module is used to construct a log object of the communication data using the unique identifier, the data type, and the communication content; The log object count module is used to store the log objects into the tail of a preset log queue and count the number of log objects stored in the log queue. The log object removal module is used to remove log objects at the head of the queue when the number of log objects exceeds a preset threshold. The string output module is used to convert all log objects in the log queue into strings of a preset format and output the strings to the preset front-end storage area when it receives an export command issued by the preset front-end debugging interface.

[0009] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described log management method.

[0010] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described log management method.

[0011] The solutions implemented by the aforementioned log management methods, devices, equipment, and media allow for client-side capture of WebSocket communication data at the front end. This involves extracting communication content and status attributes to identify data types, generating unique identifiers using timestamps and random strings, constructing log objects, storing them in a queue, limiting the number of log entries, and supporting log export as specified format strings. In this invention, communication logs can be independently and structurally recorded at the front end, ensuring log uniqueness, preventing memory overflow, and facilitating convenient log export and retention. By directly acquiring communication data at the front end, constructing structured logs, dynamically managing queues, and exporting and retaining logs, all elements of communication are accurately recorded without relying on the back end, reducing information bias and solving the problem of low accuracy in WebSocket communication problem localization and message tracing. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of an application environment for a log management method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a log management method according to an embodiment of the present invention; Figure 3 yes Figure 2 A flowchart illustrating a specific implementation method of step S3; Figure 4 yes Figure 2 A flowchart illustrating a specific implementation of step S6; Figure 5 This is a schematic diagram of a log management device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 7 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0014] It should be noted that in the technical solutions disclosed in this invention, the acquisition of user information (personal image data (e.g., facial videos or pictures, facial feature videos or pictures, etc.) and personal privacy information (e.g., name, ID number, occupation, address, etc.)) is all completed with the user's knowledge and consent, and the acquisition of the relevant user information is legal and compliant.

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] The log management method provided in this embodiment of the invention can be applied to, for example, Figure 1 In this application environment, the client communicates with the server via a network. The server can capture WebSocket communication data on the front end through the client, extract the communication content and status attributes to identify the data type, generate a unique identifier using a timestamp plus a random string to construct a log object, store it in a queue and limit the number of log entries, and support exporting logs to a specified format string. In this invention, communication logs can be independently and structurally recorded on the front end, ensuring log uniqueness, avoiding memory overflow, and facilitating log export and retention. By directly collecting communication data on the front end, constructing structured logs, dynamically managing queues, and exporting and retaining logs, all elements of communication are accurately recorded without relying on the back end, reducing information deviation and solving the problem of low accuracy in WebSocket communication problem localization and message tracing. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0017] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a log management method provided in an embodiment of the present invention, the method comprising the following steps: S1. Obtain communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes.

[0018] In this embodiment of the invention, the web socket communication is typically a real-time bidirectional communication established between the front-end and back-end via WebSocket technology, supporting core interactions such as message push and state synchronization. The communication data can be various messages and status information generated throughout the entire lifecycle of the web socket communication, including received message content and disconnection status records.

[0019] In detail, by initializing the WebSocket logging system and configuring logging to be enabled, a WebSocket message listener can be created to monitor the WebSocket communication link, identify various message types during WebSocket communication such as sending messages, receiving messages, successful connection, reconnection attempt, communication error, disconnection, and receiving heartbeat messages, capture the original message body and communication status information corresponding to each message type, and collect the original message body and communication status information to form the communication data corresponding to the web socket communication.

[0020] In this embodiment of the invention, the communication content may be the raw message body data transmitted during WebSocket communication, including interactive messages sent from the front end to the back end. The communication status attributes may be feature identification information corresponding to the entire lifecycle of WebSocket communication, including message type, communication timestamp, reconnection attempt status, or connection error status.

[0021] In this embodiment of the invention, extracting the communication content and communication status attributes of the communication data includes: The communication data is split into fields to obtain discrete data fragments; Identify the type markers of the discrete data fragments, and identify message data fragments and status data fragments based on the type markers; The message data segments are concatenated in chronological order to obtain the communication content; Parse the event encoding information of the state data fragment and extract the communication state parameters from the event encoding information; The communication state parameters are semantically mapped and transformed according to a preset communication state mapping table to obtain communication state attributes.

[0022] In detail, by parsing the unified log structure specification followed by WebSocket communication data, the integrated communication data can be split into independent basic data units to complete the field splitting process. Discrete data fragments can be independent field data conforming to the WebSocket log structure, such as message ID data, communication timestamp data, message type data, original message body data, and metadata data. According to the preset WebSocket unified log structure specification, the field boundaries corresponding to message ID, message type, timestamp, original message body, and metadata in the communication data are located, and field splitting operations are performed to separate the data content within each boundary, extracting the data units corresponding to each independent field to form discrete data fragments.

[0023] Specifically, discrete data fragments can be identified as belonging to either the message category or the status category by matching the preset category identifiers carried by the discrete data fragments. The type identifier can be the feature identifier information used to classify data categories in the WebSocket log structure. Message data fragments can be discrete data fragments carrying WebSocket communication interaction content. Status data fragments can be discrete data fragments carrying the running status of WebSocket communication. The system reads the identifier characters stored at preset positions within the discrete data fragments, calls the locally stored message class identifier set and status class identifier set, and performs a character consistency comparison between the identifier characters and the two identifier sets. If the comparison matches the message class identifier set, it is determined to be a message data fragment; if the comparison matches the status class identifier set, it is determined to be a status data fragment.

[0024] Furthermore, the communication timestamp data stored in the preset fields within the message data fragments is extracted. The message data fragments are sorted in ascending order according to the timestamp values. The original message body data of adjacent message data fragments are concatenated into strings according to the sorted order. The concatenated complete character sequence is then merged to generate the communication content corresponding to the WebSocket communication.

[0025] Furthermore, by parsing the standardized encoding identifiers built into the state data fragments and filtering valid parameters, the parsing of event encoding information and the extraction of communication state parameters are completed. Event encoding information can be standardized encoded characters used to identify the type of communication event in the WebSocket log. Communication state parameters can be WebSocket communication operation characteristic data carried within the event encoding information. By locating the preset fields storing encoded data within the state data fragments, decoding and conversion operations are performed on the encoded characters within the fields according to the WebSocket communication event encoding parsing rules. The key-value structure of the decoded data is then broken down, non-state data in the key-value structure is filtered out, and the remaining valid numerical data is extracted to form the communication state parameters.

[0026] Furthermore, a locally stored communication state mapping table is used to match communication state parameters and convert them into readable semantic information, completing the mapping transformation. The preset communication state mapping table can be a key-value pair storing WebSocket communication parameter encodings and their corresponding semantic descriptions. By reading the locally cached communication state mapping table data, the encoded values ​​of the communication state parameters are matched against the parameter encoding fields in the mapping table to locate the corresponding semantic description fields, and the content of these semantic description fields is extracted to generate communication state attributes.

[0027] For example, in an online consultation system, the front-end and back-end transmit consultation interaction and connection status communication data via WebSocket. The data fields are split to obtain discrete fragments such as message ID, consultation text, timestamp, and event code. The fragment type is identified to distinguish consultation message fragments from connection status fragments. The message fragments are spliced ​​together in chronological order to generate complete consultation dialogue content. The event code of the status fragment is parsed to extract the reconnection count and connection timeout parameters. The parameters are converted into status attributes such as normal connection and communication interruption by referring to a preset mapping table, so as to realize the structured parsing and semantic presentation of consultation communication data.

[0028] For example, in a financial trading platform, the front-end and back-end use WebSocket to transmit real-time market data, trading instructions, and link status communication data. The data fields are split to obtain discrete fragments such as market data values, trading instructions, timestamps, and event codes. The fragment type is identified to distinguish between trading message fragments and link status fragments. The message fragments are spliced ​​together in chronological order to generate complete trading interaction content. The event codes of the status fragments are parsed to extract parameters such as link delay and reconnection count. The parameters are converted into status attributes such as link normal or communication interruption by referring to a preset mapping table, thereby realizing the structured parsing and accurate presentation of financial communication data.

[0029] In this embodiment of the invention, the data type can be a category of communication data classified according to the WebSocket communication status attributes, such as normal message interaction data, communication error reporting data, and connection reconnection management data.

[0030] In this embodiment of the invention, identifying the data type corresponding to the communication data based on the communication status attribute includes: Extract the state features from the communication state attributes and compile the state features into a state feature set; The communication data is then divided into state sequences based on the state feature set and a preset communication state benchmark library. The interaction behavior features of the communication data are extracted by parsing the state sequence, and the interaction behavior features are encoded to obtain a behavior feature vector; The data type corresponding to the communication data is matched in a preset type benchmark library based on the behavioral feature vector.

[0031] In detail, by filtering and integrating key semantic identifiers in the communication status attributes, status feature extraction and feature set aggregation are completed. Status features can be core semantic identifiers representing the running state in WebSocket communication status attributes, such as connection success identifiers and communication error identifiers. The status feature set can be a collection of feature data formed by summarizing multiple independent status features, such as a feature set containing reconnection attempts, connection timeouts, and normal communication identifiers. By traversing the text content of the communication status attributes, matching it against a preset feature keyword library to locate key semantic fragments, extracting semantic fragments to generate independent status features, and storing all independent status features in a preset array structure to merge and generate the status feature set.

[0032] Specifically, state matching and sequence segmentation are completed by comparing the similarity between the state feature set and the standard feature library and classifying them. The preset communication state benchmark library can be a reference dataset storing WebSocket standard communication state feature combinations. The matching result can be the similarity judgment result between the state feature set and the feature combination of the benchmark library. The state sequence can be a WebSocket communication state combination sequence arranged in chronological order, such as the state combination sequence of successful connection - message interaction - normal disconnection. By calling the locally cached preset communication state benchmark library, each standard feature combination in the benchmark library is traversed, and the intersection of feature elements is compared with the state feature set one by one. The matching degree value is calculated. When the matching degree reaches a preset threshold, the corresponding benchmark type is determined. Communication data of the same type are sorted by timestamp and assigned to the corresponding state group. All groups are integrated to generate the state sequence corresponding to the communication data.

[0033] Furthermore, by analyzing the temporal patterns of the state sequence to extract interaction patterns and digitally encoding them, the analysis of interaction behavior features and the generation of feature vectors are completed. Interaction behavior features can be the characteristics of the interaction patterns presented by the WebSocket communication state sequence. The behavior feature vector can be a numerical array formed by standardizing and encoding the interaction behavior features. By traversing the temporally arranged communication state nodes within the state sequence, statistically analyzing the frequency of state transitions between nodes, message sending and receiving density, and the proportion of abnormal events, the statistical data is matched against a preset behavior encoding mapping table. Various behavior features are then converted into standard numerical codes, and the numerical codes are concatenated in a fixed order according to the encoding dimensions to generate the behavior feature vector.

[0034] Furthermore, by comparing the similarity between the behavioral feature vector and the standard vector in a preset type benchmark library and matching the labels, the data type of communication is identified. The preset type benchmark library can be a reference database that stores the standard behavioral feature vectors and type labels corresponding to various WebSocket communication data. By retrieving the locally cached preset type benchmark library, traversing each standard behavioral feature vector in the library, calculating the cosine similarity value between the behavioral feature vector to be matched and the standard vector, filtering out the type label corresponding to the standard vector with the highest similarity value, and associating the type label with the communication data to form the data type determination result.

[0035] For example, in a remote consultation system, the front-end and back-end transmit consultation dialogues, treatment instructions, and link status data via WebSocket. The system extracts status features such as normal connection, message interaction, communication interruption, and successful reconnection from the communication status attributes and aggregates them into a feature set. It then matches this feature set with a preset communication status benchmark library to classify the status sequence of connection establishment, consultation message sending and receiving, brief disconnection, and automatic reconnection. The system analyzes interaction behavior features such as consultation message frequency, interaction duration, and the proportion of abnormal events and encodes them to generate feature vectors. Finally, it matches these features with a preset type benchmark library to determine whether the communication data is regular consultation interaction data or abnormally interrupted treatment data, supporting rapid localization of medical communication problems.

[0036] For example, in a financial trading platform, the front-end and back-end transmit real-time market data, trading instructions, fund changes, and link status data via WebSocket. The system extracts communication status attributes such as connection stability, market data push, network jitter, and reconnection recovery, and aggregates these into a feature set. It then matches this feature set with a preset communication status benchmark library to classify the state sequence of login authentication, market data reception, order placement, brief disconnection, and reconnection. The system analyzes interactive behavior features such as trading frequency, market data latency, and the proportion of abnormal events, and encodes them to generate feature vectors. Finally, it matches these features with a preset type benchmark library to determine whether the communication data is high-frequency trading data or abnormal link data, supporting rapid location of financial trading link anomalies.

[0037] S2. Obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data.

[0038] In this embodiment of the invention, the timestamp can be identification data that records the time of occurrence of various WebSocket communication events, usually composed of a combination of numbers, such as a millisecond-level numerical sequence corresponding to the occurrence of a WebSocket message sending event.

[0039] In detail, by listening to the WebSocket communication event trigger signal, the system time value at the moment the WebSocket communication event occurs is captured, the millisecond-level numerical sequence within the system time value is extracted, and the timestamp corresponding to the WebSocket communication data is generated.

[0040] In this embodiment of the invention, the random string can be a short sequence formed by random combination of letters and numbers, used to concatenate with a timestamp to generate a unique message ID corresponding to the WebSocket message log, such as a six-digit unordered sequence of letters and numbers.

[0041] In this embodiment of the invention, generating a random string associated with the timestamp includes: The timestamp is converted to a different number system to obtain a time feature code; The random character generation interval is determined based on the time feature code, and the basic character units within the random character generation interval are extracted. The basic character units are dynamically misaligned and reassembled to obtain random character fragments; The time feature code is concatenated with the random character fragment to generate a random string associated with the timestamp.

[0042] In detail, the timestamp number format is changed by a preset number system conversion rule to generate a time signature code corresponding to the WebSocket communication data. The time signature code can be a fixed-length numerical code formed by converting the timestamp to a different number system, used to identify the time of the WebSocket communication event. The decimal millisecond value contained in the timestamp is parsed, and a number system conversion algorithm is called to convert the decimal millisecond value to a hexadecimal value. A specified length of character segment is extracted from the hexadecimal value to generate a time signature code bound to the WebSocket communication data.

[0043] Specifically, the character selection range is defined by parsing the time signature value, and character constituent units are filtered to determine the random character generation interval and extract the basic character units. The random character generation interval can be the boundary range of the character set defined by the time signature value, used to limit the value boundaries of the random characters generated in the WebSocket message log. The basic character unit can be the smallest independent character element that constitutes the random string of the WebSocket message log, used to concatenate and generate a unique message ID. By parsing the hexadecimal value contained in the time signature and comparing it with a preset value threshold to divide the upper and lower boundaries of character selection, the random character generation interval corresponding to the WebSocket message log is determined. The character set contained in the random character generation interval is traversed, and a single independent character within the set is filtered to extract the basic character unit corresponding to the WebSocket message log.

[0044] Furthermore, random character fragments are generated by shuffling and recombining the basic character units. These random character fragments can be short character sequences formed by misaligning and rearranging the basic character units. By retrieving a preset dynamic misalignment offset parameter, the ordered sequence of basic character units is traversed, and the positions of the basic character units are adjusted position by position according to the offset parameter. This shuffles the original fixed order of the sequence, and the basic character units are then concatenated according to their new adjusted positions to generate the random character fragments corresponding to the WebSocket message log.

[0045] Furthermore, the string merging interface can be called to read the character sequence data corresponding to the time feature code, and the string merging interface can be called to read the character sequence data corresponding to the random character fragment. The two sets of character sequence data are then concatenated end to end in a preset order to complete the merging. The validity of the data format of the merged character sequence is verified, and a random string associated with the WebSocket communication data timestamp is output.

[0046] For example, in a medical scenario, when a hospital's front-end WebSocket transmits real-time ECG monitoring data, it captures the millisecond-level timestamp of the ECG data transmission, converts the decimal timestamp into a hexadecimal time signature, defines a random character generation range from 0 to 9 and from a to f based on this signature, selects single digits and lowercase letters within the range as basic character units, retrieves misalignment parameters to shuffle the unit order and reassembles them into four-digit random character fragments, and concatenates the hexadecimal time signature with the character fragments to generate an associated random string, thereby generating a unique ID for the monitoring log, ensuring the traceability of the ECG communication log, and helping the front-end to locate abnormal monitoring data transmission.

[0047] For example, in a financial scenario, when a bank's wealth management system receives real-time net asset value (NAV) update data via WebSocket, it captures the millisecond-level timestamp corresponding to the NAV push event, converts the decimal timestamp to hexadecimal format to generate a time signature, defines a random character generation range of mixed numbers and lowercase letters based on the signature value, extracts a single independent character within the range as a basic character unit, and uses a dynamic offset algorithm to shuffle the original sorting of the character units and reorganize them to generate random character fragments. The hexadecimal time signature and the random character fragments are concatenated to obtain an associated random string, which serves as the unique identifier for the NAV communication log, supporting the front end to quickly locate WebSocket communication failures such as data delays and packet loss.

[0048] In this embodiment of the invention, the unique identifier may be a unique character sequence formed by combining a timestamp and a random string, used to uniquely distinguish the log record corresponding to each WebSocket communication data.

[0049] In this embodiment of the invention, generating a unique identifier for the communication data using the timestamp and the random string includes: The timestamp is characterized to obtain a time-encoded sequence; The random string is segmented and mapped using the time-encoded sequence to obtain concatenated character groups; The concatenated character group is discretized and recombined to obtain the basic identifier code; The basic identifier code is regularized to a fixed length to generate a unique identifier for the communication data.

[0050] In detail, the timestamp value format is converted using characterization encoding rules to generate a time-encoded sequence. The time-encoded sequence can be a fixed-length character combination formed by characterizing the timestamp, used to identify the time of the WebSocket communication event. By parsing the decimal millisecond value contained in the timestamp, the characterization encoding algorithm is called to convert the decimal millisecond value into Base64 format characters, and a six-bit segment from the encoded result is extracted to generate the time-encoded sequence corresponding to the WebSocket communication data.

[0051] Specifically, random string segments are divided using a time-encoded sequence, and character mappings are established to generate concatenated character groups. These concatenated character groups can be ordered combinations of characters formed after segmenting and mapping random strings. The time-encoded sequence is split into equal-length character segments as mapping indices. The random string is divided into substrings with the same number of indices, and a bidirectional mapping relationship is constructed between the indexed character segments and the random string substrings. The corresponding character segments and substrings are matched according to the mapping binding rules to generate the concatenated character groups corresponding to the WebSocket communication data.

[0052] Furthermore, by shuffling and recombining the characters within the concatenated character group, a basic identifier code is generated. This basic identifier code can be the core character sequence formed after the concatenated character group has been discretized and recombined. By invoking a preset discretization and recombination algorithm, the ordered set of character units contained in the concatenated character group is disassembled, the original order of the character units is randomly shuffled, and the positions of the character units are rearranged according to the recombination rules. The recombined character units then generate the basic identifier code corresponding to the WebSocket communication data.

[0053] Furthermore, a preset fixed-length threshold is set to verify the length of the basic identifier character. When the length exceeds the threshold, the valid character segment at the end of the basic identifier character is truncated. When the length does not reach the threshold, preset padding characters are used to fill in the fixed length. The validity of the format of the regularized character sequence is verified, and the regularized character sequence is output as the unique identifier corresponding to the WebSocket communication data.

[0054] S3. Using the unique identifier, the data type, and the communication content, construct a log object for the communication data.

[0055] In this embodiment of the invention, the log object can be a structured data unit that integrates a unique identifier, data type, communication content, and additional information related to WebSocket communication. It is used to completely record the key information of a single WebSocket communication message, such as a data unit containing message ID, message type, original message body, timestamp, and metadata.

[0056] In this embodiment of the invention, reference is made to Figure 3 As shown, step S3 includes: S31. Map the unique identifier to the identity dimension to obtain the number field, map the data type to the category dimension to generate the type field, and map the communication content to the content dimension to generate the content field. S32. Bind the number field, the type field and the content field using key-value pairs to obtain a log tuple; S33. Extract time-series correlation information from the log tuple, and generate timestamp parameters for log records based on the time-series correlation information; S34. Perform semantic aggregation on the log tuple and the timestamp parameter to obtain log-related metadata; S35. The log tuple, the timestamp parameter, and the log-related metadata are structured and encapsulated to form a log object of the communication data.

[0057] In detail, by establishing mapping rules for three dimensions—identity, category, and content—corresponding dimension matching and transformation operations are performed on unique identifiers, data types, and communication content to generate standardized number, type, and content fields. The number field can be a standardized identification code obtained by mapping a unique identifier to the identity dimension. The type field can be a standardized classification label obtained by mapping a data type to the category dimension. The content field can be a standardized core content fragment obtained by mapping the communication content to the content dimension. By retrieving a locally stored identity dimension mapping rule table, the character features of the unique identifier are extracted and compared one by one with the entries in the rule table, converting the unique identifier into a fixed format code to generate the number field. A preset category dimension mapping rule library is retrieved, the attribute features of the data type are identified and matched with the corresponding entries in the rule library, converting the data type into unified classified text to generate the type field. Core information extraction and redundant character removal operations are performed, valid data segments of the communication content are extracted and formatted, and the communication content is converted into concise and compliant text to generate the content field.

[0058] Specifically, by assigning preset key names and performing key-value mapping encapsulation, the number field, type field, and content field are bound and combined into structured data units. A log tuple can be an ordered structured data set formed by key-value binding of the number field, type field, and content field. By retrieving a local preset key name configuration table, unique fixed key identifiers are matched for the number field, type field, and content field respectively. A key-value mapping algorithm establishes a bidirectional association between the actual value of each field and its corresponding key identifier. Then, a data merging and encapsulation operation is performed to integrate the three sets of associated key-value pairs into a unified and ordered data structure, completing the key-value association binding of the number field, type field, and content field.

[0059] Furthermore, by traversing the structured data of log tuples and performing time format conversion operations, time-series correlation information is extracted and timestamp parameters corresponding to log records are generated. Time-series correlation information can be the correlation data within the log tuple representing the chronological order of WebSocket communication events. A log record can be the structured data of a single communication event generated throughout the entire lifecycle of WebSocket communication. The timestamp parameter can be the standardized time value of the communication event corresponding to the log record. By traversing all key-value pairs within the log tuple, valid data fragments carrying time-series identifiers are filtered, irrelevant interference characters are removed, and an ordered data sequence is formed, completing the extraction of time-series correlation information. The built-in time parsing function is then invoked to convert the baseline time-series data in the correlation information into millisecond-level time values, and encapsulated into a unified format of time identifier data according to log specifications, thus generating the timestamp parameters for the log records.

[0060] Furthermore, by combining semantic rule matching with structured data fusion and encapsulation, log tuples and timestamp parameters are semantically associated and integrated to generate log supplementary metadata. This supplementary metadata can be auxiliary data that supplements the completeness of WebSocket communication logs, such as log generation environment identifier data and log-associated communication status marker data. By retrieving a pre-stored semantic association rule table from the front end, the semantic attributes of each key-value pair within the log tuple are parsed and matched with the temporal semantic features of the timestamp parameter. A bidirectional semantic alignment algorithm is executed to eliminate semantic discrepancies between the two types of data. Then, a structured data encapsulation interface is called to merge the aligned log tuples and timestamp parameters into a unified format of auxiliary data units, completing the semantic aggregation of log tuples and timestamp parameters.

[0061] In addition, the predefined WebSocket log object template is retrieved from the front end, and format compliance checks are performed on the log tuple, timestamp parameter, and log auxiliary metadata to remove invalid and redundant characters from the data. A field mapping algorithm is used to accurately match the three types of data to the corresponding fields in the template. A structured data integration interface is then called to perform deep data merging, solidifying the data format and structure according to log specifications. This completes the structured encapsulation of log tuples, timestamp parameters, and log auxiliary metadata, generating a log object containing the communication data.

[0062] S4. Store the log object at the tail of a preset log queue, and count the number of log objects stored in the log queue.

[0063] In this embodiment of the invention, the preset log queue can be a linear storage structure pre-set by the front end for orderly storage of various WebSocket message log objects, used to realize log addition, eviction, and orderly management. The number of log objects can be the cumulative number of all WebSocket structured log objects currently stored in the log queue, used to trigger the logic of removing old logs after the log count limit is exceeded.

[0064] In detail, the tail insertion interface of the preset log queue is called to append the WebSocket structured log object containing message ID, message type, timestamp, original message body and metadata to the last storage position of the preset log queue. All WebSocket structured log objects in the preset log queue are traversed, counted one by one and accumulated to obtain the cumulative number of WebSocket structured log objects stored in the preset log queue.

[0065] Based on structured log objects throughout the entire WebSocket communication lifecycle, logs are appended to a pre-defined log queue in real time to accurately count the number of log objects in the queue, and a mechanism for determining if the number of log entries exceeds the limit is implemented. The appending operation ensures that log objects for WebSocket message sending, message receiving, connection success, and connection termination are ordered in sequence, and the total count provides reliable data support for log queue capacity management, avoiding the problems of disordered log accumulation and excessive memory consumption.

[0066] For example, when the log queue is full of 100 log objects, the total count triggers the automatic removal of old logs, maintaining the stability of the front-end debugging environment and helping developers efficiently locate WebSocket communication anomalies.

[0067] S5. When the number of log objects exceeds a preset threshold, remove the log objects at the head of the queue.

[0068] In this embodiment of the invention, the preset number of entries threshold can be the maximum number of WebSocket structured log objects that the log queue can hold, which is set in advance by the front end and is used to trigger the logic of removing old logs after the log queue exceeds the limit.

[0069] In detail, the system retrieves the threshold value for the number of log entries in the pre-stored log queue. It then performs a size comparison operation between the number of WebSocket structured log objects obtained from the log queue statistics and the threshold value. If the total number is greater than the threshold, it calls the built-in head removal interface of the log queue to clear the WebSocket structured log object stored at the top of the log queue and synchronously updates the storage arrangement position of the remaining log objects in the log queue.

[0070] By using a pre-defined threshold for the number of entries on the front end, and employing a first-in-first-out (FIFO) rule to trigger the removal of the head log object, the size of the WebSocket log queue can be dynamically controlled. The head removal operation can precisely remove the earliest generated WebSocket log object, preventing the log queue from growing indefinitely and consuming excessive front-end memory.

[0071] For example, when the preset threshold for the number of log entries is 100, old logs at the head of the queue are removed when the number of log objects exceeds 100. This ensures the stable operation of functions such as page loading and message receiving during front-end debugging, reserves storage space for new reconnection attempts, disconnections, and other log objects, and maintains the continuity of log sequence to help developers locate communication anomalies.

[0072] S6. When an export command is received from the preset front-end debugging interface, all log objects in the log queue are converted into strings in a preset format and the strings are output to the preset front-end storage area.

[0073] In this embodiment of the invention, the preset front-end debugging interface may be a functional interface provided by the front-end WebSocket message log management system for performing log export debugging operations. The export command may be a control command that triggers the export operation of the log queue log object. The preset format string may be a structured text string formed by converting the log queue log object, such as a JSON format string.

[0074] In this embodiment of the invention, reference is made to Figure 4 As shown, converting all log objects in the log queue into strings of a preset format includes: S41. Sequentially decompose the unique identifier, data type, and communication content of a single log object in the log queue to obtain log field elements; S42. Classify and group the log field elements according to the preset log information dimensions to form a log field set; S43. Perform semantic alignment processing on the log field set to obtain the target log field group; S44. The target log field group is nested and combined in a preset hierarchical order to obtain log data units; S45. Perform character serialization conversion on the log data unit and output a string in a preset format.

[0075] In detail, the log queue decomposes the core information of a log object and generates log field elements by iteratively reading individual log objects, separating core information from key-value pairs, and organizing data fragments. Log field elements can be independent structured data units formed after decomposing a log object, such as a message ID data unit corresponding to the unique identifier of the log object, or a message type data unit corresponding to the data type. By iteratively reading individual log objects stored in the log queue, the current log object data to be processed is locked. For the locked log object, key-value pair separation is used to extract the message ID data corresponding to the unique identifier, the send or receive type data corresponding to the data type, and the original message body and metadata data corresponding to the communication content, splitting it into three independent data fragments. These three independent data fragments are then organized into standardized structured data units to form log field elements.

[0076] Specifically, log field elements are categorized and grouped to generate a log field set by matching preset dimension labels, classifying elements of the same dimension, and summarizing similar data. The preset log information dimensions can be information division standards predefined by the WebSocket logs, such as message type or communication time. The log field set can be a structured data group formed by summarizing log field elements of the same dimension. The process involves traversing all log field elements, retrieving the preset log information dimension classification rule table stored in the front-end WebSocket logging system, and performing a string-by-string comparison between the field identifier of each log field element and the dimension label in the rule table. Based on the matching results, the log field elements are assigned to the corresponding dimension group. Log field elements within the same dimension group are then appended to the end of the array and stored sequentially into the group container. Finally, the data in all dimension group containers are integrated to form the log field set.

[0077] Furthermore, the log field set completes semantic alignment and generates a target log field group by retrieving a semantic mapping dictionary to match standard semantics, replacing non-standard tags, and unifying semantic format. The target log field group can be a standardized combination of log fields with unified semantics and standardized meanings, such as a group of fields composed of message ID, original message body, and connection status after semantic alignment. This can be achieved by retrieving the semantic mapping dictionary stored locally in the front-end WebSocket logging system, traversing all field elements in the log field set, extracting the semantic identifier strings inherent in each field element, performing character-by-character comparison and matching between these semantic identifier strings and standard semantic entries in the semantic mapping dictionary, using a string replacement algorithm to replace non-standard semantic identifiers that fail to match with the corresponding standard semantic identifiers in the dictionary, filtering out semantically conflicting invalid characters within field elements using preset regular expressions, standardizing the semantic expression format of field elements, and aggregating the processed standardized field elements to form the target log field group.

[0078] Furthermore, the target log field group completes hierarchical nesting and generates log data units by retrieving the hierarchical configuration table, sorting by priority, and encapsulating using nested JSON syntax. The preset hierarchical order can be the pre-defined field nesting arrangement rules of the WebSocket log. The log data unit can be a complete structured log data block formed after hierarchical nesting. The hierarchical configuration table stored locally in the front-end WebSocket logging system is retrieved, the hierarchical priority value corresponding to each field in the configuration table is parsed, all standardized field elements in the target log field group are traversed, the field elements are sorted in ascending order according to the priority value, and the low-priority field elements are encapsulated as child nodes of high-priority field elements using nested JSON object key-value syntax. This hierarchical nesting encapsulation of all field elements is completed in sequence, and the nested overall data is encapsulated into an independent structured data block to form a log data unit.

[0079] In addition, by calling the built-in JSON serialization function of the front-end WebSocket logging system, the hierarchical nested structure of the log data units can be recursively traversed, the key name and corresponding data value can be parsed level by level, the numeric data can be converted into a decimal number character sequence, the text data can be escaped by adding double quotes, the nested data can be encapsulated by adding curly braces, and all the parsed and encapsulated character fragments can be concatenated character by character to generate a preset format string that conforms to the JSON specification.

[0080] In this embodiment of the invention, the preset front-end storage area can be a front-end local data storage space used by the front-end WebSocket logging system to store log strings, such as a front-end temporary cache area or a front-end local data persistence area.

[0081] In detail, the write interface of the preset front-end storage area of ​​the front-end WebSocket logging system is invoked, the serialized log string is pushed to the write interface in the form of a character stream, and the character stream data is written to the specified storage address of the preset front-end storage area through the storage write command, thus completing the output and storage of the log string.

[0082] It can improve the efficiency of WebSocket communication problem localization, eliminating the need to rely on the backend logging system to retrieve log data. For example, developers can directly obtain complete communication logs through the frontend debugging interface, enhancing log data sharing and reuse capabilities. Preset format strings adapt to log data transmission and parsing needs; for example, exported JSON format strings can be directly used for frontend and backend joint debugging, reducing backend log storage and transmission overhead. Exporting strings to frontend local storage reduces the data read and write burden on the backend server; for example, during the debugging phase, log data can be stored in the frontend cache area without occupying backend storage resources.

[0083] As can be seen, the above solution allows for independent, structured recording of communication logs on the front end, ensuring log uniqueness, preventing memory overflow, and facilitating log export and retention. By directly collecting communication data from the front end, constructing structured logs, dynamically managing queues, and exporting and retaining logs, all elements of communication are accurately recorded without relying on the back end, reducing information bias and solving the problem of low accuracy in WebSocket communication problem localization and message tracing.

[0084] 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.

[0085] In one embodiment, a log management device 100 is provided, which corresponds one-to-one with the log management method described in the above embodiments. For example... Figure 5 As shown, the log management device 100 includes a data type identification module 101, a unique identifier generation module 102, a log object construction module 103, a log object quantity statistics module 104, a log object removal module 105, and a string output module 106. Detailed descriptions of each functional module are as follows: The data type identification module 101 is used to acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes. The unique identifier generation module 102 is used to obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and generate a unique identifier for the communication data using the timestamp and the random string; Log object construction module 103 is used to construct a log object of the communication data using the unique identifier, the data type, and the communication content; The log object count module 104 is used to store the log objects into the tail of a preset log queue and count the number of log objects stored in the log queue. The log object removal module 105 is used to remove the log objects at the head of the queue when the number of log objects exceeds a preset threshold. The string output module 106 is used to convert all log objects in the log queue into strings of a preset format and output the strings to a preset front-end storage area when it receives an export instruction from a preset front-end debugging interface.

[0086] In one embodiment, the data type identification module 101, when extracting the communication content and communication status attributes of the communication data, is used to: The communication data is split into fields to obtain discrete data fragments; Identify the type markers of the discrete data fragments, and identify message data fragments and status data fragments based on the type markers; The message data segments are concatenated in chronological order to obtain the communication content; Parse the event encoding information of the state data fragment and extract the communication state parameters from the event encoding information; The communication state parameters are semantically mapped and transformed according to a preset communication state mapping table to obtain communication state attributes.

[0087] In one embodiment, the data type identification module 101, when performing the task of identifying the data type corresponding to the communication data based on the communication status attribute, is further configured to: Extract the state features from the communication state attributes and compile the state features into a state feature set; The communication data is then divided into state sequences based on the state feature set and a preset communication state benchmark library. The interaction behavior features of the communication data are extracted by parsing the state sequence, and the interaction behavior features are encoded to obtain a behavior feature vector; The data type corresponding to the communication data is matched in a preset type benchmark library based on the behavioral feature vector.

[0088] In one embodiment, the unique identifier generation module 102, when generating a random string associated with the timestamp, is used to: The timestamp is converted to a different number system to obtain a time feature code; The random character generation interval is determined based on the time feature code, and the basic character units within the random character generation interval are extracted. The basic character units are dynamically misaligned and reassembled to obtain random character fragments; The time feature code is concatenated with the random character fragment to generate a random string associated with the timestamp.

[0089] In one embodiment, the unique identifier generation module 102, when generating a unique identifier for the communication data using the timestamp and the random string, is further configured to: The timestamp is characterized to obtain a time-encoded sequence; The random string is segmented and mapped using the time-encoded sequence to obtain concatenated character groups; The concatenated character group is discretized and recombined to obtain the basic identifier code; The basic identifier code is regularized to a fixed length to generate a unique identifier for the communication data.

[0090] In one embodiment, the log object construction module 103, when constructing a log object for the communication data using the unique identifier, the data type, and the communication content, is configured to: The unique identifier is mapped to the identity dimension to obtain the number field; the data type is mapped to the category dimension to generate the type field; and the communication content is mapped to the content dimension to generate the content field. By binding the number field, the type field, and the content field with key-value pairs, a log tuple is obtained. Extract time-series correlation information from the log tuple, and generate timestamp parameters for log records based on the time-series correlation information; Semantic aggregation is performed on the log tuple and the timestamp parameter to obtain log-related metadata; The log tuple, the timestamp parameter, and the log-related metadata are structured and encapsulated to form a log object of the communication data.

[0091] In one embodiment, the string output module 106, when performing the conversion of all log objects in the log queue into strings of a preset format, is used to: The unique identifier, data type, and communication content of each log object in the log queue are sequentially decomposed to obtain the log field elements; The log field elements are categorized and grouped according to preset log information dimensions to form a log field set; The log field set is semantically aligned to obtain the target log field group; The target log field group is nested and combined in a preset hierarchical order to obtain log data units; The log data unit is converted into a character serialization and output as a string in a preset format.

[0092] This invention provides a log management device that can independently and structurally record communication logs on the front end, ensuring log uniqueness, avoiding memory overflow, and conveniently exporting and storing logs. By directly collecting communication data on the front end, constructing structured logs, dynamically managing queues, and exporting and storing logs, it accurately records all elements of communication without relying on the back end, reducing information deviation, and solving the problem of low accuracy in WebSocket communication problem localization and message tracing.

[0093] For specific limitations regarding the log management device, please refer to the limitations of the log management method above, which will not be repeated here. Each module in the aforementioned log management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, 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.

[0094] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a log management method on the server side.

[0095] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. 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 network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a log management method on the client side.

[0096] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes; Obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; Using the unique identifier, the data type, and the communication content, a log object of the communication data is constructed; Store the log object at the tail of a preset log queue, and count the number of log objects already stored in the log queue. When the number of log objects exceeds a preset threshold, remove the log object at the head of the queue; When an export command is received from the preset front-end debugging interface, all log objects in the log queue are converted into strings of a preset format, and the strings are output to the preset front-end storage area.

[0097] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes; Obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; Using the unique identifier, the data type, and the communication content, a log object of the communication data is constructed; Store the log object at the tail of a preset log queue, and count the number of log objects already stored in the log queue. When the number of log objects exceeds a preset threshold, remove the log object at the head of the queue; When an export command is received from the preset front-end debugging interface, all log objects in the log queue are converted into strings of a preset format, and the strings are output to the preset front-end storage area.

[0098] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0099] 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. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0101] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0102] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A log management method, characterized in that, The method includes: Acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes; Obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; Using the unique identifier, the data type, and the communication content, a log object of the communication data is constructed; Store the log object at the tail of a preset log queue, and count the number of log objects already stored in the log queue. When the number of log objects exceeds a preset threshold, remove the log object at the head of the queue; When an export command is received from the preset front-end debugging interface, all log objects in the log queue are converted into strings of a preset format, and the strings are output to the preset front-end storage area.

2. The log management method as described in claim 1, characterized in that, The extraction of communication content and communication status attributes from the communication data includes: The communication data is split into fields to obtain discrete data fragments; Identify the type markers of the discrete data fragments, and identify message data fragments and status data fragments based on the type markers; The message data segments are concatenated in chronological order to obtain the communication content; Parse the event encoding information of the state data fragment and extract the communication state parameters from the event encoding information; The communication state parameters are semantically mapped and transformed according to a preset communication state mapping table to obtain communication state attributes.

3. The log management method as described in claim 1, characterized in that, The step of identifying the data type corresponding to the communication data based on the communication status attribute includes: Extract the state features from the communication state attributes and compile the state features into a state feature set; The communication data is then divided into state sequences based on the state feature set and a preset communication state benchmark library. The interaction behavior features of the communication data are extracted by parsing the state sequence, and the interaction behavior features are encoded to obtain a behavior feature vector; The data type corresponding to the communication data is matched in a preset type benchmark library based on the behavioral feature vector.

4. The log management method as described in claim 1, characterized in that, The generation of the random string associated with the timestamp includes: The timestamp is converted to a different number system to obtain a time feature code; The random character generation interval is determined based on the time feature code, and the basic character units within the random character generation interval are extracted. The basic character units are dynamically misaligned and reassembled to obtain random character fragments; The time feature code is concatenated with the random character fragment to generate a random string associated with the timestamp.

5. The log management method as described in claim 1, characterized in that, The process of generating a unique identifier for the communication data using the timestamp and the random string includes: The timestamp is characterized to obtain a time-encoded sequence; The random string is segmented and mapped using the time-encoded sequence to obtain concatenated character groups; The concatenated character group is discretized and recombined to obtain the basic identifier code; The basic identifier code is regularized to a fixed length to generate a unique identifier for the communication data.

6. The log management method as described in claim 1, characterized in that, The step of constructing a log object for the communication data using the unique identifier, the data type, and the communication content includes: The unique identifier is mapped to the identity dimension to obtain the number field; the data type is mapped to the category dimension to generate the type field; and the communication content is mapped to the content dimension to generate the content field. By binding the number field, the type field, and the content field with key-value pairs, a log tuple is obtained. Extract time-series correlation information from the log tuple, and generate timestamp parameters for log records based on the time-series correlation information; Semantic aggregation is performed on the log tuple and the timestamp parameter to obtain log-related metadata; The log tuple, the timestamp parameter, and the log-related metadata are structured and encapsulated to form a log object of the communication data.

7. The log management method as described in claim 1, characterized in that, The step of converting all log objects in the log queue into strings of a preset format includes: The unique identifier, data type, and communication content of each log object in the log queue are sequentially decomposed to obtain the log field elements; The log field elements are categorized and grouped according to preset log information dimensions to form a log field set; The log field set is semantically aligned to obtain the target log field group; The target log field group is nested and combined in a preset hierarchical order to obtain log data units; The log data unit is converted into a character serialization and output as a string in a preset format.

8. A log management device, characterized in that, The device includes: The data type identification module is used to acquire communication data generated during web socket communication, extract the communication content and communication status attributes of the communication data, and identify the data type corresponding to the communication data based on the communication status attributes. A unique identifier generation module is used to obtain the timestamp corresponding to the communication data, generate a random string associated with the timestamp, and use the timestamp and the random string to generate a unique identifier for the communication data; A log object construction module is used to construct a log object of the communication data using the unique identifier, the data type, and the communication content; The log object count module is used to store the log objects into the tail of a preset log queue and count the number of log objects stored in the log queue. The log object removal module is used to remove log objects at the head of the queue when the number of log objects exceeds a preset threshold. The string output module is used to convert all log objects in the log queue into strings of a preset format and output the strings to the preset front-end storage area when it receives an export command issued by the preset front-end debugging interface.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the log management method as described in any one of claims 1 to 7.

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

Images