A sharable symptom knowledge base driven software system self-repair method

Abstract

The embodiment of the application provides a kind of software system self-repairing method driven by sharable symptom knowledge base, it is applied to software system operation maintenance technical field, by receiving cross-subject fault handling record and generating sharable symptom knowledge base, collection running period log stream and generate structured log record, carry out abnormal screening and semantic coding to structured log record and obtain abnormal feature vector, carry out similarity comparison to abnormal feature vector with sharable symptom knowledge base and generate target symptom entry, generate repair execution plan based on target symptom entry and execute in controlled isolation environment, obtain repair execution result, write back update success rate weight with repair feedback data, generate iteration symptom knowledge base, and as the search base of next round of abnormal matching.The application can improve the accuracy of abnormal matching and the safety of repair execution, realize the reusable, rollbackable and continuous iteration self-repairing of software system failure.

Description

Technical Field

[0001] This application relates to the field of software system operation and maintenance technology, and in particular to a self-healing method for software systems driven by a shareable symptom knowledge base. Background Technology

[0002] During operation, software systems continuously generate runtime log streams, alarm information, resource usage data, and records of handling processes. Existing software operations and maintenance typically identify and handle abnormal events through monitoring alarm rules, log keyword matching, threshold judgment, and manually maintained fault knowledge bases, and in some scenarios, invoke preset repair scripts to perform automated repairs.

[0003] Existing fault knowledge bases often originate from a single operations and maintenance entity. Fault handling records, experience, and repair tools across entities are difficult to share and reuse after de-identification, standardized coding, and verification. This leads to the repeated accumulation of the same or similar software faults across different entities, resulting in limited anomaly matching coverage. Furthermore, existing rule-based matching methods primarily rely on keywords, log levels, or fixed thresholds, failing to fully utilize log templates, contextual relationships, and anomaly semantic features. This makes it easy for differences in log descriptions to prevent accurate matching of similar anomalies, or for different anomalies to be mismatched due to similar local fields.

[0004] Existing automated repair methods typically execute repair operations directly based on preset scripts, lacking system constraints regarding script integrity, execution environment boundaries, protection against repeated calls, consistency of repair results, and rollback in case of exceptions. When repair actions fail or deviate from expectations, it can impact the stable operation of the software system. Furthermore, feedback data such as repair execution results, time consumption, resource usage, and success status are often not structured and written back to the fault knowledge base, making it difficult to continuously update the knowledge base based on actual repair effects and preventing the formation of a closed loop of exception matching, repair execution, and feedback iteration.

[0005] Therefore, existing self-healing technologies for software systems suffer from problems such as insufficient reuse of cross-entity fault experience, insufficient accuracy of anomaly matching, insufficient security of repair execution, and difficulty in continuous iteration of the knowledge base. Summary of the Invention

[0006] The embodiments of this application provide a self-healing method for software systems driven by a shareable symptom knowledge base, realizing cross-subject fault experience reuse, automatic anomaly matching, and safe rollback-capable self-healing processing. To achieve the above objectives, this application adopts the following technical solution: A self-healing method for a software system driven by a shareable symptom knowledge base, the method comprising: The system acquires cross-entity fault handling records, performs desensitization, normalization, hierarchical organization, and unified coding on these records, and generates a shareable symptom knowledge base. This shareable symptom knowledge base includes symptom feature descriptions, applicable domain identifiers, repairable identifiers, repair tool references, and success rate weights. It also collects runtime log streams from the monitored software system, performs field segmentation, template normalization, and session aggregation on these log streams to generate structured log records. The structured log records are then subjected to anomaly event filtering and semantic encoding to generate anomaly feature vectors. Finally, these anomaly feature vectors are compared with the symptom feature descriptions in the shareable symptom knowledge base. Similarity comparison is performed, and the target symptom entries are generated by filtering and sorting based on the applicable domain identifier, the repairable identifier, and the success rate weight. A repair execution plan is generated based on the repair tool references of the target symptom entries, and the repair execution plan is executed idempotently in a controlled, isolated environment to generate repair execution results. The repair execution results are anonymized and indexes are extracted to generate repair feedback data, which is then written back to the shareable symptom knowledge base to update the success rate weights of the corresponding symptom entries, generating an iterated symptom knowledge base. The iterated symptom knowledge base is used as the retrieval basis for the next round of anomaly matching.

[0007] As can be seen from the above technical solution, this application has the following beneficial effects: 1. This application generates a shareable symptom knowledge base by stripping sensitive fields, normalizing expressions, hierarchically classifying, uniformly coding, and verifying cross-entity fault handling records. This enables the fault handling experience of different operation and maintenance entities to be reused on the basis of desensitization and audit verification, expands the data source and symptom coverage of anomaly matching, and avoids the problem of repeated accumulation of the same or similar software faults among different entities, which makes them difficult to reuse.

[0008] 2. This application generates structured log records by performing field segmentation, log template extraction, variable parameter retention, and session aggregation on runtime log streams. It then generates anomaly feature vectors by combining log level, template frequency, preceding log template sequence items, and subsequent log template sequence items. Simultaneously, it compares the similarity of the anomaly feature vectors with the symptom feature vectors within the same source space and filters target symptom items by combining applicable domain identifiers, repairability identifiers, and success rate weights. This makes anomaly matching no longer dependent on keywords or fixed thresholds, which helps improve the matching consistency of similar anomalies under different log descriptions and reduces the risk of cross-domain mismatches and mis-calling of unrepairable items.

[0009] 3. This application constrains the execution environment, repeated calls, repair results, and abnormal execution behavior of repair actions through script integrity verification, controlled running containers, state snapshots, idempotent keys, result consistency checks, and deviation rollback processing, thereby reducing the risk of repair actions adversely affecting the stable operation of the software system. At the same time, it converts repair execution results and execution monitoring data into repair feedback data, and updates the success rate weight based on success identifiers, consistency hit rates, repair time, and environmental characteristics to generate an iterative symptom knowledge base, so that anomaly matching, repair execution, and feedback writing form a closed loop, thereby improving the accuracy, security, and continuous iteration capability of the software system's self-repair. Attached Figure Description

[0010] The present application will be further described below with reference to the accompanying drawings.

[0011] Figure 1 This is a schematic diagram of the overall process of a self-healing method for a software system driven by a shareable symptom knowledge base, provided in an embodiment of this application. Detailed Implementation

[0012] Research has revealed that existing self-healing technologies in software systems largely rely on a single-entity fault knowledge base, log keyword matching, fixed threshold alarms, and the execution of preset repair scripts. Cross-entity fault handling records are difficult to share and reuse after desensitization, unified encoding, and verification, resulting in limited anomaly matching coverage. At the same time, existing rule matching methods are unable to utilize log context and anomaly semantic features, easily leading to mismatches or missed matches. The execution process of repair scripts lacks controlled isolation, state snapshots, consistency checks, and rollback constraints, and the repair results are difficult to continuously write back to the knowledge base, affecting the accuracy, security, and iterative capabilities of self-healing.

[0013] To address the aforementioned issues, this application provides a self-healing method for software systems driven by a shareable symptom knowledge base: Example: Figure 1 As shown, this embodiment relates to a self-healing method for software systems driven by a shareable symptom knowledge base, which is particularly applicable to the field of software system operation and maintenance technology.

[0014] S1. Obtain cross-entity fault handling records, and perform desensitization, normalization, hierarchical organization, and unified coding registration on the cross-entity fault handling records to generate a shareable symptom knowledge base. The shareable symptom knowledge base includes symptom feature descriptions, applicable field identifiers, repairable identifiers, repair tool references, and success rate weights. In this embodiment, step S1 includes the following process: The system receives anonymized fault texts and handling process descriptions reported by different entities, and merges the anonymized fault texts and handling process descriptions into an original fault corpus. Sensitive fields are stripped and the expressions are normalized in the original fault corpus to obtain standardized symptom descriptions. These standardized symptom descriptions are then hierarchically categorized according to business domains, and each standardized symptom description is assigned a predetermined number of unique codes to generate symptom entries. These symptom entries are then registered in the database through a version management channel and a multi-party verification process to generate the shareable symptom knowledge base.

[0015] Specifically, cross-entity fault handling records refer to fault text and handling process descriptions provided by the work order systems, alarm handling systems, or operation and maintenance record systems of multiple collaborating entities. Anonymized fault text refers to fault description text that has undergone preliminary anonymization processing before being reported by the collaborating entities. Handling process descriptions refer to the handling steps, scripts, parameters, and results recorded by operation and maintenance personnel or automated operation and maintenance platforms when handling the fault. Original fault corpus refers to the data set formed by merging the same anonymized fault text and its corresponding handling process description in a paired sample manner.

[0016] The receipt of fault handling records is completed through the operation and maintenance data access gateway. The operation and maintenance data access gateway calls the interfaces provided by the work order systems of each collaborating entity, reads the anonymized fault text field, handling process description field, business domain field, handling result field, and record time field according to the pre-agreed data fields, binds the anonymized fault text and handling process description in the same record into a set of samples, and writes the samples from different entities into the same buffer pool to obtain the original fault corpus.

[0017] Sensitive field stripping is used to perform a secondary compliance check on the original fault data, replacing fields still matched by the sensitive pattern set with placeholders of equal length. During sensitive field stripping of the original fault data, a sensitive pattern set is loaded, including regular expression patterns for ID card numbers, Internet Protocol addresses, account names, asset numbers, and phone numbers. This sensitive pattern set is obtained from a data security compliance rule base and is read from the rule base by the operations and maintenance data access gateway before each processing step. The anonymized fault text and handling process descriptions in the original fault data are scanned character by character. Once a character span matching a sensitive pattern is found, that span is replaced with a placeholder of equal length, resulting in the stripped text.

[0018] Expression normalization continues on the stripped text. Specifically: Synonym mappings are read from the synonym phrase table, and fault descriptions with the same meaning are replaced with uniform descriptions; stop words are read from the stop word table, and conjunctions, modifiers, and redundant modifiers that do not affect the meaning of symptoms are deleted; time field formats are read from the time field template table, and specific times are replaced with uniform time placeholders to obtain candidate standardized text. The synonym phrase table, stop word table, and time field template table are pre-maintained by the operations and maintenance knowledge maintenance terminal and synchronized to the processing node through the version management channel.

[0019] When comparing the similarity of candidate normalized texts, the Levenshtein edit distance is used for calculation. The Levenshtein edit distance, also known as the Levenshtein edit distance, refers to the minimum number of operations required to transform one text into another using the three basic operations of character insertion, deletion, and substitution. In practice, each character of any two candidate normalized texts is compared to obtain the Levenshtein edit distance. Then, the length of the longer text is used for dimensionless processing to obtain the similarity between the two candidate normalized texts.

[0020] The similarity of candidate standardized texts is calculated as follows: ; In the formula, This represents the similarity between two candidate standardized texts, with values ​​falling within the range [0,1]. The Levenshtein edit distance is represented by the sum of the three basic operations: character insertion, deletion, and replacement. Indicates the character length of the first candidate normalized text; This indicates the character length of the second candidate normalized text; and Used to distinguish between two candidate standardized texts participating in the comparison.

[0021] Standardized symptom descriptions refer to symptom description text that has undergone sensitive field stripping, synonym replacement, stop word cleaning, time field templated, and similar text merging. Standardized symptom descriptions are used to uniformly express the symptoms of similar software faults across different entities, avoiding the same fault being registered as multiple symptom entries due to differences in description.

[0022] When stratifying and classifying standardized symptom descriptions, a term frequency-inverse document frequency (TF-IDF) weighted scoring method is used. Specifically, the standardized symptom descriptions are segmented and stop words are removed to obtain a set of valid terms. The TF-IDF weights of each valid term in each business domain are retrieved from the business domain corpus statistics table. The TF-IDF weights of all valid terms in the same business domain are summed to obtain the domain matching score for that business domain. The business domain with the highest domain matching score is identified as the applicable domain identifier.

[0023] After classification, a unique code is assigned to each standardized symptom description. The unique code is a code uniquely bound to the standardized symptom description, used to uniquely locate the symptom entry in the shareable symptom knowledge base. The unique code is generated using the SHA-256 hash function, where SHA-256 stands for Secure Hash Algorithm 256-bit. Specifically, the applicable domain identifier, standardized symptom description, and timestamp of the registration time are concatenated into a string. The concatenated string is then subjected to SHA-256 hash calculation, and the first predetermined number of hexadecimal characters are extracted from the hash result as the unique code.

[0024] The unified encoding generation rules are as follows: ; In the formula, Indication and standardized symptom description The bound unified encoding; This represents the SHA-256 hash function; This represents the string concatenation operator; A timestamp indicating the registration time, accurate to the second; Indicates the length of the extracted hexadecimal characters; This indicates truncating the first part of the hash result. Bit character.

[0025] After unified coding is generated, standardized symptom descriptions, applicable domain identifiers, unified coding, repairable identifiers, repair tool references, and success rate weights are encapsulated into symptom entries. A symptom entry is the smallest registration unit in a shareable symptom knowledge base. The repairable identifier indicates whether the symptom entry is bound to an executable repair script; it is 1 if bound to an executable repair script, and 0 otherwise. The repair tool reference is a structured reference used to locate the repair script and its version, read from the script registration table in the repair script repository. The symptom feature description carries a category label, severity level, triggering context, and resource fingerprint. The category label is obtained by looking up the keywords and business domain in the standardized symptom description; the severity level is read from the alarm level in the original fault corpus or the impact level in the handling process description; the triggering context is extracted from the calling scenario, business operation scenario, and abnormal triggering condition fields in the handling process description; and the resource fingerprint is read from the resource status fields such as memory, connection pool, disk, thread, and port in the handling process description or runtime parameter records.

[0026] The success rate weight is obtained from the treatment result field in the treatment process description when the symptom entry is first registered; when there are historical treatment results for the same standardized symptom description, the statistical results of the successful treatment records in the historical treatment results are read as the initial success rate weight; when there are no historical treatment results, the preset initial success rate weight is written and updated in the subsequent repair feedback write-back stage.

[0027] The registration process is completed through a version management channel and a multi-party verification process. The version management channel is a data management channel used to record the addition, modification, review, release, and rollback status of symptom entries. It consists of a version repository, a review record table, and a version number generator. The multi-party verification process refers to a process in which multiple domain reviewers cross-confirm the standardized symptom description, applicable domain identifier, repairable identifier, and repair tool references for symptom entries. Specifically, a preset number of domain reviewers are read from the reviewer management table, and review tasks are assigned to each reviewer; each reviewer submits an agreement or disagreement flag; the system reads the reviewer's weight from the reviewer's historical annotation accuracy table and performs a weighted vote to obtain a weighted review score for the symptom entry.

[0028] The weighted review score is calculated as follows: ; In the formula, Indicates symptom entries Weighted review score; This indicates the number of reviewers, set to 5. Indicates the number is The reviewer's weight is assigned based on their historical annotation accuracy rate. Indicates the number is Reviewers on symptom entries The given agreement flag is 1 for agreement and 0 for disagreement.

[0029] In the above formula, the greater the reviewer's weight, the greater the impact of the reviewer's approval mark on the weighted review score; the more approval marks, the higher the weighted review score; and the higher the preset review threshold, the stricter the conditions for the symptom item to pass verification. The reviewer's weight is obtained by reading the reviewer's annotation accuracy rate in the most recent preset number of review samples from the reviewer's historical annotation accuracy rate table, obtaining the initial weight based on the interval to which the annotation accuracy rate belongs, and then normalizing it according to the requirement that the sum of the weights of all participating reviewers is 1. The preset review threshold is set to 0.60, determined by the offline evaluation results of historical candidate items.

[0030] When the weighted review score reaches the preset review threshold, the symptom entry passes verification and is written to the repository through the version management channel, recording the incrementing version number, the proposal subject, the list of reviewers, and the registration timestamp. When the weighted review score does not reach the preset review threshold, the symptom entry is returned to the corpus revision queue, awaiting supplementary materials for re-review. All verified and registered symptom entries together constitute a shareable symptom knowledge base.

[0031] S2. Collect the runtime log stream of the monitored software system, and perform field segmentation, template normalization, and session aggregation on the runtime log stream to generate structured log records; In this embodiment, step S2 includes the following process: The runtime log stream is accessed at the running node of the monitored software system to obtain the raw log stream. The log entries in the raw log stream are segmented into fields to obtain fielded log entries containing timestamps, log levels, source identifiers, and text messages. Log templates are extracted from the text messages in the fielded log entries, and placeholders are updated for inconsistent words based on the word position matching results to obtain a log template sequence. The log template sequence is then context-associated and session-aggregated according to a time window to obtain structured log records containing session start and end times, business domains, source identifiers, template numbers, and variable parameter vectors.

[0032] Specifically, runtime log streams refer to the continuous stream of log data generated by the monitored software system during its operation, including file logs, kernel audit logs, and standard output logs. Log collection probes are collection programs deployed on the running nodes of the monitored software system, running as daemons. They access the runtime log stream in parallel through three paths: file trailing, kernel audit interface, and standard output redirection. File trailing is used to read continuously appended log files; the kernel audit interface is used to read system-level audit events; and standard output redirection is used to read log content directly output by containers or processes.

[0033] After the log collection probe connects to the runtime log stream, it gathers the raw log entries according to the collection window to obtain the raw log stream. The raw log entries include the generation time, log level, source identifier, and text message. The generation time is obtained by parsing the time field in the log entry; the log level is read from the log level field; the source identifier consists of the hostname, process number, and component name; the text message is the message text in the log entry excluding the timestamp, log level, and source identifier.

[0034] Field segmentation is performed based on a set of regular expression normalization rules. The set of rules consists of four named capture groups of regular expressions concatenated together, used to capture timestamps, log levels, source identifiers, and message content, respectively. During processing, the original log entries are input into the field segmentation operator, which sequentially matches the timestamp field, log level field, source identifier field, and message content field, outputting fieldized log entries.

[0035] After field segmentation, log templates are extracted from the body message. A log template is a message pattern formed by replacing variable values ​​in the body message with placeholders. Variable values ​​include numbers, port numbers, internet protocol addresses, object identifiers, thread numbers, request identifiers, and file paths. Log template extraction uses a parse tree structure to merge the body message layer by layer. The root node of the parse tree receives the body message, child nodes at the same depth branch according to the first word of the body message, and leaf nodes store the formed log templates. When a new body message descends along the parse tree to a candidate leaf node, the body message is compared with the corresponding log template of the candidate leaf node word by word, and the word matching degree is calculated.

[0036] The word position matching degree is calculated as follows: ; In the formula, Indicates the main text message With number log template The word position matching degree takes a value within the range [0,1]. Log template lexical length; This indicates the number of segments obtained by splitting the data by whitespace characters. One word position; This indicates an indicator function; it takes the value 1 if the condition within the square brackets is true, and 0 otherwise. Placeholders are considered to be matched if they are identical to any word.

[0037] When the word matching degree reaches the preset template matching threshold, the main message is merged into the candidate leaf node, and inconsistent words at the same position are replaced with placeholders "<*>", thereby updating the log template corresponding to the candidate leaf node. When the word matching degree does not reach the preset template matching threshold, a new branch is created under the candidate leaf node, using the current main message as the initial template. Subsequently, variable parameters are extracted from the main message according to the placeholder positions to obtain a variable parameter vector. The variable parameter vector is used to retain the specific running parameters replaced by placeholders in the log template, so that they can be called when generating parameters for subsequent anomaly filtering and repair tools.

[0038] All original log entries are concatenated in order of their generation time, along with their merged template numbers and variable parameter vectors, to form a log template sequence.

[0039] When performing context association on log template sequences, a sliding time window is used for session aggregation. Specifically, the log template sequences are sorted in ascending order by generation time, the time interval between adjacent log entries is calculated, and this time interval is compared to the sliding window length. If the time interval between the current log entry and the previous log entry does not exceed the sliding window length and the source identifiers are completely identical, the current log entry is assigned to the session containing the previous log entry. If the time interval exceeds the sliding window length, or the source identifiers are inconsistent, a new session number is assigned to the current log entry.

[0040] The time intervals between adjacent log entries are as follows: ; In the formula, Indicates the number is The time interval between the first log entry and the next first log entry, in seconds; Indicates the number is The time when the original log entry was created; Indicates the number is The time when the original log entry was created.

[0041] The session numbers are recursively assigned as follows: ; In the formula, Indicates the number is The session number to which the original log entry belongs, where the session number of the first original log entry is set to 1. ; Indicates the number is The session number to which the original log entry belongs; Indicates the number is The original log entries and their numbers are The time interval between the original log entries; This indicates the length of the sliding window, in seconds, and is set to 60. Indicates the number is The source identifier of the original log entry; Indicates the number is The source identifier of the original log entry.

[0042] In the above formula, the smaller the time interval, the easier it is for the current log entry to be aggregated into the session of the previous log entry; the larger the sliding window length, the more adjacent log entries under the same source identifier will be aggregated into the same session; when the source identifiers are inconsistent, a new session number will be assigned even if the time interval does not exceed the sliding window length. The sliding window length is set to 60 seconds, determined by the average latency and percentile latency statistics of the microservice call chain, so that log entries of the same processing process are merged into the same session without crossing call boundaries.

[0043] All log template sequence items under the same session number are aggregated into the same session. Each session is further encapsulated into structured log records. A structured log record refers to structured log data stored on a session-by-session basis, including session start and end times, business domain, source identifier, template number, and variable parameter vector. The business domain is obtained by looking up a source identifier-component name mapping table, which is generated from the deployment manifest of the monitored software system and is consistent with the business domain set in step S1. All structured log records constitute the total set of structured log records.

[0044] S3. Perform abnormal event filtering and semantic encoding on the structured log records to generate abnormal feature vectors; In this embodiment, step S3 includes the following process: The frequency of log levels and log template occurrences in the structured log records is normalized and fused to obtain an anomaly score; the structured log records are filtered according to a preset anomaly score threshold to obtain a candidate anomaly event set; using the highest-level log entry in the candidate anomaly event set as the anchor point, the preceding log template sequence item and the subsequent log template sequence item are extracted and concatenated to obtain the event text; the event text is subjected to semantic embedding, context concatenation, dimension alignment and normalization processing to obtain the anomaly feature vector.

[0045] Specifically, the anomaly score is a dimensionless numerical value used to characterize the severity of anomalies in structured log entries, determined by both the log level and the frequency of log template occurrences. The log level is read from the log entries included in the structured log records; the log template occurrence frequency is statistically obtained from the log template sequence items contained in the structured log records. The log level reflects the severity of the log entry, while the log template occurrence frequency reflects the degree to which the same anomaly pattern recurs within the same session. Since these two metrics differ, they are normalized before being merged.

[0046] When determining the level of a structured log record, the highest log level among all log entries included in the structured log record is taken as the level representation of that structured log record. The log level mapping function assigns values ​​of 1, 2, 3, 4, and 5 to the five levels: DEBUG, INFO, WARN, ERROR, and FATAL, respectively.

[0047] When determining the frequency of structured log records, the number of times the same log template number appears within the same session is used as the basic quantity. In specific processing, the log template sequence items in the structured log record are read, and the number of times each log template number appears in the structured log record is counted to obtain the log template occurrence frequency.

[0048] After obtaining the grading representation and the frequency of log template occurrences, the two are normalized and fused to obtain the anomaly score. The grading representation is normalized using the maximum value of the grading mapping function; the frequency of log template occurrences is standardized using the average number of occurrences and the standard deviation of occurrences in the historical sliding window, and then mapped to an interval using the Sigmoid compression function. The Sigmoid compression function, also known as the S-shaped compression function, is used to compress input values ​​to between 0 and 1.

[0049] The anomaly score is calculated as follows: ; In the formula, Indicates the number is The anomaly score recorded in the structured log records takes values ​​within the range [0,1]. Indicates the weighting of the rank fusion; Indicates the frequency fusion weight; Indicates the number is The hierarchical representation of structured log records; This represents the maximum value achieved by the rank mapping function, which is fixed at 5. Indicates the number is The set of log template numbers appearing in the structured log records; Indicates the number is The structured log record numbered The number of times the log template appears; Indicates the number is The average number of occurrences of the log template was obtained by statistical analysis over a 7-day historical sliding window; Indicates the number is The standard deviation of the number of occurrences of the log template was obtained by statistical analysis over a historical 7-day sliding window; Indicates zero protection item, take ; This represents the Sigmoid compression function.

[0050] In the anomaly scoring formula, the higher the level representation, the larger the level normalization term, and the higher the anomaly score; the higher the frequency of log template occurrences and the greater the deviation from the historical average occurrences, the larger the frequency normalization term, and the higher the anomaly score; the larger the standard deviation of historical occurrences, the stronger the fluctuation of the log template itself, and the smaller the frequency normalization term corresponding to the same increase in occurrences; the zero-prevention protection term is used to avoid division by zero when the standard deviation of historical occurrences is 0; the higher the level fusion weight, the more the anomaly score depends on the log level; the higher the frequency fusion weight, the more the anomaly score depends on the recurrence of log templates.

[0051] The weights for grade fusion and frequency fusion are set to 0.4 and 0.6 respectively, and their sum is 1, ensuring that the anomaly score remains between 0 and 1. The weights for grade fusion and frequency fusion are determined through offline evaluation using historical logs.

[0052] When the anomaly score reaches the preset anomaly score threshold, the corresponding structured log record will be included in the candidate anomaly event set.

[0053] The set of candidate abnormal events is determined as follows: ; In the formula, Represents a set of candidate exception events; Indicates the number is Structured log recording; Indicates the number is The anomaly scoring of structured log records; This indicates the preset abnormal scoring threshold; This indicates the total number of structured log records.

[0054] After the candidate set of exception events is determined, the event text is assembled for each candidate exception event. Using the highest-level log entry as the anchor point, a preset number of preceding log template sequence items are extracted, and a preset number of subsequent log template sequence items are extracted. If the number of items before and after the anchor point is less than the preset number, the actual existing log template sequence items are retained. The preceding log template sequence items, the anchor log template, the variable parameter vector of the anchor log entry, and the subsequent log template sequence items are concatenated in chronological order to obtain the event text. The anchor log entry refers to the log entry with the highest log level within the same session.

[0055] After the event text is assembled, semantic embedding is performed. Semantic embedding refers to mapping the event text into a fixed-length dense vector using a multi-layer text feature extractor. The multi-layer text feature extractor uses a pre-trained bidirectional context encoder as its foundation, and progressively stacks self-attention operations to extract dependencies between word positions. Self-attention operation means calculating the feature extraction operation of the correlation strength between different word positions within the same text sequence. The model file of the multi-layer text feature extractor is loaded from the model repository, and the parameters are frozen after loading and are not updated at runtime.

[0056] The semantic embedding process is as follows: ; In the formula, Indicates the number is The dense vector corresponding to the event text; This represents a multi-layer text feature extractor; Indicates the number is The event text of the candidate exception events; This represents the dimension of a dense vector.

[0057] After obtaining the dense vector, context concatenation is performed. Context concatenation refers to linking the anchor dense vector, the preceding session's tail dense vector, the subsequent session's head dense vector, and the metadata vector to form an anomaly semantic representation. The preceding session's tail dense vector and the subsequent session's head dense vector are read from the semantic encoding cache; the semantic encoding cache stores the anchor dense vectors of the most recent preset number of sessions according to the session number. The metadata vector carries four components: level representation, maximum frequency after logarithmic compression, session duration, and one-hot encoding of the business domain. Before loading, normalization processing is performed so that the overall value falls within [0,1].

[0058] In the metadata vector, the higher the level representation, the larger the component representing severity in the metadata vector; the higher the maximum frequency, the larger the frequency component after logarithmic compression; the longer the session duration, the larger the duration component after normalization; business domain one-hot encoding is used to maintain domain consistency between the current candidate abnormal event and the applicable domain identifier of subsequent symptom entries.

[0059] The dimension of the anomaly semantic representation is Since the dimensions are inconsistent with those required by the downstream retrieval basis, dimensional alignment is performed on the anomaly semantic representations. Dimensional alignment is accomplished using a linear projection matrix and a bias vector. The linear projection matrix and bias vector are loaded from the model repository, and their parameters are trained on historical labeled samples with a triple contrastive learning objective. Triple contrastive learning means using samples with the same symptoms and samples with different symptoms to form training triples, so that the anomaly semantic representations of the same symptoms cluster together in the projection space, and the anomaly semantic representations of different symptoms move away from each other in the projection space.

[0060] Dimension alignment is handled as follows: ; In the formula, This represents the aligned intermediate vector; Represents the projection matrix; Indicates the number is The anomalous semantic representation of candidate anomalous events; Represents the bias vector; Indicates the aligned dimensions; The dimension of a dense vector; Indicates the dimension of the metadata vector.

[0061] After dimension alignment, L2 norm scaling is applied to the intermediate vector. L2 norm, or second-order norm of a vector, is specifically the square root of the sum of the squares of the vector's components. Normalization yields the anomalous eigenvectors, which are then sized onto a unit hypersphere.

[0062] The normalization process is as follows: ; In the formula, Indicates the number is The abnormal feature vector; This represents the aligned intermediate vector; The second norm of the intermediate vector is represented by . This indicates a zero-protection item.

[0063] In the above formula, the larger the second norm of the intermediate vector, the greater the normalization scaling. A zero-prevention term is added to prevent numerical instability caused by an excessively small second norm of the intermediate vector. After normalization, the lengths of different anomalous feature vectors are unified, and subsequent similarity comparisons are mainly determined by the vector direction, thereby reducing the impact of different event text lengths and different session sizes on similarity comparisons.

[0064] The outputs of all candidate anomaly events, after dimension alignment and normalization, are used to fill the set of anomaly feature vectors.

[0065] S4. Compare the abnormal feature vector with the symptom feature description in the shareable symptom knowledge base for similarity, and filter and sort them in combination with the applicable domain identifier, the repairable identifier and the success rate weight to generate target symptom entries; In this embodiment, step S4 includes the following process: The symptom feature descriptions of each symptom entry in the shareable symptom knowledge base are processed by homology encoding and normalization to obtain symptom feature vectors; the abnormal feature vectors are compared with the symptom feature vectors item by item to obtain a similarity score set; the similarity score set is sorted in descending order and filtered according to a preset confidence threshold to obtain a candidate symptom set; the candidate symptom set is further filtered and sorted according to the consistency between the business domain label of the current running node and the applicable domain identifier, the repairable identifier, and the success rate weight to obtain the target symptom entry.

[0066] Specifically, homologous encoding refers to encoding symptom feature descriptions using the same multi-layer text feature extractor, linear projection matrix, bias vector, and normalization method as the abnormal feature vectors in S3. Through homologous encoding, symptom feature vectors and abnormal feature vectors have the same dimension and the same normalization scale, enabling direct cosine similarity comparison.

[0067] When performing homologous encoding on symptom feature descriptions, the category label, severity level, triggering context, and resource fingerprint are converted into a text field sequence according to the field name. The text field sequence is then concatenated with the standardized symptom description and input into a multi-layer text feature extractor. After normalization by linear projection matrix, bias vector, and L2 norm, the symptom feature vector is obtained.

[0068] After obtaining the symptom feature vectors, the abnormal feature vectors are compared with each symptom feature vector for similarity. Since both the abnormal and symptom feature vectors have been normalized using the L2 norm and lie on the same unit hypersphere, the cosine similarity is calculated using the inner product method. The cosine similarity characterizes the degree of proximity between two vectors in a direction; the larger the value, the closer the abnormal and symptom feature vectors are.

[0069] The cosine similarity is calculated as follows: ; In the formula, Represents anomaly feature vectors Symptom feature vector The cosine similarity is dimensionless. Indicates the number is The abnormal feature vector; Indicates the number is The symptom feature vector corresponding to the symptom entries; The abnormal feature vector is represented in the th... Dimensional components; The symptom feature vector represents the first... Dimensional components; Indicates the aligned dimensions.

[0070] In the above formula, the more consistent the directions of the abnormal feature vector and the symptom feature vector, the greater the cosine similarity; the greater the cumulative sum of the component multiplications of the two vectors on the same dimension, the greater the cosine similarity; since the two vectors have been normalized, the cosine similarity is not affected by the vector length.

[0071] After iterating through all symptom entries in the shareable symptom knowledge base, a similarity score set is obtained.

[0072] The similarity score set is sorted from high to low and pre-filtered using a preset confidence threshold to obtain a candidate symptom set.

[0073] After the initial filtering, a second filtering process is performed. This second filtering incorporates the business domain label of the currently running node and the repairability identifier of candidate symptom entries. The business domain label of the currently running node is read from the business domain field of the structured log record in S2; the applicable domain identifier and repairability identifier of candidate symptom entries are read from the symptom entries in the shareable symptom knowledge base. Any candidate symptom entry whose business domain label and applicable domain identifier are inconsistent, or whose repairability identifier is 0, is discarded.

[0074] Within the candidate symptom set retained after secondary screening, the symptom is re-scored based on the product of cosine similarity and success rate weights, and the symptom with the highest score is selected as the target symptom.

[0075] The target symptom items were determined as follows: ; In the formula, Indicates the number is The target symptom entries corresponding to the abnormal feature vectors; Indicates the number is Symptom entries; This represents the set of candidate symptoms retained after secondary screening. Indicates the number is The abnormal feature vector and the number are The cosine similarity between the symptom feature vectors; Indicates the number is The success rate weight carried by the symptom entries.

[0076] When the candidate symptom set is empty, the expansion process is triggered. An empty candidate symptom set indicates that the shareable symptom knowledge base does not adequately cover the current abnormal feature vector. To avoid duplicate misses, a miss counter maintains a hit record for each abnormal feature vector using content hashing. When the cumulative number of misses for the same abnormal feature vector within the rolling window reaches the inclusion threshold, the abnormal feature vector is added to the miss sample pool.

[0077] The sample pool that was not hit was determined as follows: ; In the formula, This indicates that the sample pool was not hit; Indicates the number is The abnormal feature vector; Indicates the number is The cumulative number of misses within the window for the abnormal feature vector; Indicates the lower limit for inclusion; Indicates the number is The moment, in seconds, when the anomalous feature vector first misses within the scrolling window; This indicates the current time, expressed in seconds. This indicates the length of the scrolling window, in seconds.

[0078] In the above formula, the greater the cumulative number of misses, the easier it is for the abnormal feature vector to enter the miss sample pool; the higher the inclusion lower limit, the stricter the conditions for entering the miss sample pool, which can reduce the false expansion caused by occasional anomalies; the longer the rolling window length, the easier it is for long-term low-frequency anomalies to be accumulated and identified, and the shorter the rolling window length, the more the expansion process focuses on recently repeated anomalies.

[0079] When performing cluster analysis on the missed sample pool, DBSCAN neighborhood clustering is used. DBSCAN stands for Density-Based Noisy Spatial Clustering. In practice, cosine distance is used as the distance metric. Abnormal feature vectors whose cosine distance does not exceed the neighborhood radius and whose number of samples in the neighborhood is at the minimum are identified as core points. The clusters of unknown anomalies are then expanded outward from the core points.

[0080] The unknown anomaly cluster set is generated as follows: ; In the formula, This represents the generated set of unknown anomaly clusters; This refers to the DBSCAN neighborhood clustering algorithm; This indicates that the sample pool was not hit; This represents the radius of the cosine distance neighborhood, which is dimensionless. This represents the minimum number of samples required to form a core point.

[0081] After obtaining the clusters of unknown anomalies, the central features of each cluster are calculated. The central features are obtained by normalizing the arithmetic mean vector of the cluster members using the L2 norm.

[0082] Candidate symptom descriptions are generated based on the high-frequency context of central features and log template sequence items within clusters. High-frequency context refers to log template phrases that appear adjacent to and have a high co-occurrence frequency with the anchor log template within the same unknown anomaly cluster. Specifically, the co-occurrence frequency of adjacent anchor log template phrases in the event text corresponding to each anomaly feature vector within the unknown anomaly cluster is counted. The top three phrases with the highest co-occurrence frequency are selected and concatenated in order of appearance to generate candidate symptom descriptions.

[0083] Based on the central features of the unknown anomaly cluster, a predetermined number of historical similar clusters are selected from historically validated clusters in descending order of cosine similarity. The repair tool references bound to these historical similar clusters are read, and their scores are accumulated using the corresponding cosine similarity as weights. The repair tool reference with the highest accumulated score is determined as the suggested repair tool reference. When no historical similar clusters exist, from symptom entries in the same business domain that are marked as repairable (1), the symptom entry with the highest cosine similarity to the central feature of the unknown anomaly cluster is selected, and its repair tool reference is used as the suggested repair tool reference. If no usable symptom entry still exists, a preset diagnostic script reference is used as the suggested repair tool reference and marked as requiring manual confirmation in the multi-party verification process. The preset diagnostic script reference is only used to collect operational status and supplement diagnostic information; it does not execute status modification repair actions.

[0084] Candidate symptom descriptions and suggested repair tools are collectively packaged into symptom entries to be reviewed and submitted to a multi-party verification process for cross-verification. The multi-party verification process adopts the weighted voting method established in S1.

[0085] The weighted review score for the symptom items pending review is calculated as follows: ; In the formula, Indicates the number is The weighted review score of the pending symptom entries; Indicates the number is Pending symptom entries; Indicates the number of reviewers; Indicates the number is The weight of the reviewers; Indicates the number is The reviewers assign an agreement rating of 1 to each symptom item they review, and 0 to each symptom item they disagree with.

[0086] Verified symptom entries awaiting review are written into the version management channel according to the unified coding generation rules, forming an expanded symptom knowledge base.

[0087] S5. Generate a repair execution plan based on the repair tool reference of the target symptom entry, and execute the repair execution plan idempotently in a controlled isolation environment to generate repair execution results; In this embodiment, step S5 includes the following process: The repair tool reference of the target symptom entry is parsed to obtain the script identifier and version number. Execution parameters are obtained from the parameter fields of the repair tool reference or the script registration information corresponding to the script identifier and version number. The repair script is loaded from the repair script repository according to the script identifier and version number, and the verified repair script, the execution parameters, and the idempotent key are encapsulated into a repair execution plan. The repair execution plan is loaded into a controlled running container to obtain an isolated repair task. A state snapshot is generated before the isolated repair task is executed. During execution, repeated calls are masked according to the idempotent key. After execution, the result consistency is checked to obtain the repair execution result. When the deviation between the execution monitoring data and the expected behavior profile exceeds a preset acceptable range, a rollback running node state is generated based on the state snapshot, and an execution failure flag is written into the repair execution result.

[0088] Specifically, the repair tool reference refers to the structured reference information used to locate the repair script and its version. The repair tool reference includes a script identifier field, a version number field, and optional parameter fields. When the parameter field is empty or no execution parameters are configured, the system searches for the corresponding script registry or script execution description in the repair script repository based on the script identifier and version number, and uses the pre-configured default execution parameters as the execution parameters for the repair script. The script identifier is used to locate the repair script in the repair script repository; the version number is used to locate the specific version of the repair script; the execution parameters refer to the set of parameters that need to be read when the repair script is executed, including the timeout limit, concurrency level, target resource identifier, and adjustable threshold. The target resource identifier is jointly determined by the source identifier in S2 and the target symptom entry locked in S4, and is used to indicate the running node, process, or component on which the repair action is applied.

[0089] When parsing the repair tool reference, a regular expression consisting of named capture groups is used to match the repair tool reference string, extracting the script identifier, version number, and parameter fields respectively. When the parameter field contains execution parameters, the parameters in the parameter field are used as the execution parameters. When the parameter field is empty or no execution parameters are configured, default execution parameters are read from the script registry table or script execution description in the repair script repository as described above. Named capture groups are a grouping method in existing regular expression technology. By specifying field names for matching groups, the script identifier, version number, and execution parameters can be directly output by field name.

[0090] After obtaining the script identifier and version number, the script identifier and version number are combined to form an addressing key, and the corresponding repair script byte stream is read from the controlled repair script repository. The repair script repository is a data warehouse that stores audited repair scripts, script version numbers, script hash bases, and script execution instructions. After reading the repair script byte stream, the hash digest of the repair script byte stream is calculated using the SHA-256 hash function and then compared with the script hash base fixed when the symptom entry was registered. SHA-256 is a 256-bit secure hash algorithm used to map the script byte stream to a fixed-length digest to determine whether the script byte stream has been tampered with.

[0091] The script integrity check is as follows: ; In the formula, This represents the SHA-256 hash function; This represents the repair script byte stream that was hit by the address key; Indicates the script identifier; Indicates the version number; Indicates the number is The script hash benchmark is fixed when symptom entries are registered; This indicates an equality check.

[0092] In the above formula, if the hash digest calculated from the repair script byte stream is consistent with the script hash benchmark, it means that the repair script byte stream is consistent with the script content at the time of registration, and the script verification passes; if they are inconsistent, it means that the script byte stream is inconsistent with the registered content, the generation of the repair execution plan stops, and a script verification failure record is output.

[0093] After the repair script passes verification, the repair script, execution parameter set, and idempotent key are encapsulated together into a repair execution plan. The idempotent key is a unique key used to identify whether the same repair execution plan has been called repeatedly. It is composed of the current anomaly feature vector hash, the unified encoding of the target symptom entry, and the execution sequence number, and is 32 hexadecimal characters long. The anomaly feature vector hash is obtained by truncating the anomaly feature vector generated by S3 after SHA-256 hashing; the unified encoding of the target symptom entry is read from the target symptom entries locked by S4; and the execution sequence number is generated by the repair execution scheduler incrementing according to the execution count of the same target symptom entry.

[0094] The remediation execution plan is containerized and loaded into a controlled runtime container isolated from the production environment, resulting in an isolated remediation task. A controlled runtime container is an isolated execution environment with a container image baseline, resource limits, and a network whitelist. The container image baseline carries runtime and dependency libraries from the same source as the production node; resource limits include a maximum of 2 CPU cores, a maximum of 4GB of memory, and a maximum of 100MB / s of disk I / O; the network whitelist only allows access to the runtime node port and monitoring return port pointed to by the target resource identifier. Resource limits are read from the controlled runtime container parameter table, which is pre-set based on historical remediation sample statistics.

[0095] By using three constraints—container image baseline, resource quota, and network whitelist—the script execution dependencies, resource usage limits, and network reachability of isolation and remediation tasks are all limited, ensuring that the remediation actions do not deviate from the execution boundaries defined by the target resource identifier.

[0096] Before executing the isolation and repair task, a state snapshot is generated. A state snapshot is data that permanently saves the state of the running node before performing repair actions, covering four components: the process view, connection table, critical configuration files, and target resource fingerprint. The process view is read through the operating system process query interface; the connection table is read through the network connection query interface; the critical configuration files are read through the file read interface; and the target resource fingerprint is obtained by hashing the target resource state field. The state snapshot stores recoverable data of process startup parameters, connection configurations, copies of critical configuration files, and target resource state fields, and simultaneously saves the SHA-256 hash digest of the above recoverable data; the recoverable data is used for rollback restoration, and the hash digest is used to verify that the snapshot content has not been tampered with.

[0097] State snapshots and idempotent keys are written together to the snapshot storage, serving as the recovery base for subsequent rollback operations. The process view, connection table, key configuration files, and target resource fingerprints correspond to the running state, network state, configuration state, and resource state, respectively. These four components together limit the range of node states that need to be restored during rollback.

[0098] During the execution of the isolation repair task, idempotent keys are used to mask repeated calls. Specifically: before execution, the scheduler queries the set of recorded idempotent keys; if the current idempotent key does not exist in the set, a new execution branch is entered, and the current idempotent key is written to the set; if the current idempotent key already exists, the current repair script is skipped, and the result of the previously executed script is returned. The set of recorded idempotent keys is persisted in a 7-day rolling window.

[0099] The new execution branch operates on the target resource item by item according to the instruction sequence of the repair script. The exit code, standard output, and standard error of each instruction are collected synchronously. After execution, a consistency check is performed. The consistency check involves collecting the process view, connection table, key configuration files, and target resource fingerprint from the target resource again after the repair action is completed, and comparing them with the expected post-repair hash benchmark agreed upon when the target symptom entry was registered, to calculate the consistency hit rate. The expected post-repair hash benchmark is read from the script execution instructions in the repair script repository and associated with the repair tool reference when the symptom entry is bound to the repair tool reference.

[0100] The consistency hit rate is calculated as follows: ; In the formula, Indicates the number is The consistency hit rate of the isolation repair task, dimensionless, with values ​​falling within the set {0, 0.25, 0.50, 0.75, 1}; This indicates the corresponding component obtained by re-collecting from the target resource after the repair is completed. The component This includes process views, connection tables, key configuration files, and target resource fingerprints; Indicates the number is The components registered for the target symptom entries The corresponding corrected expected hash benchmark; This indicates an indicator function that takes the value 1 if the condition is true and 0 otherwise. This represents the SHA-256 hash function.

[0101] In the above formula, the more items that are matched among the four components—process view, connection table, critical configuration file, and target resource fingerprint—the higher the consistency hit rate. When all four items are matched, the consistency hit rate is 1; when none of the four items are matched, the consistency hit rate is 0. Since the number of matched items is divided by a fixed number of 4, the result is a dimensionless value.

[0102] When the consistency hit rate reaches the consistency hit rate threshold, the repair execution result is marked as successful; otherwise, the repair execution result is marked as failed.

[0103] The security rollback process and isolation / remediation tasks are executed in parallel. During execution, the isolation / remediation task continuously collects execution data and resource usage at a 1-second sampling interval, forming execution monitoring data. This data includes CPU utilization, memory usage, disk I / O rate, and system call frequency. CPU utilization is read through the container runtime resource statistics interface; memory usage is read through the container memory statistics interface; disk I / O rate is read through the container block device statistics interface; and system call frequency is obtained through the kernel audit interface.

[0104] The expected behavior profile is data used to define the scope of normal execution behavior for isolation and remediation tasks. The expected behavior profile stores the time mean and standard deviation for CPU utilization, memory usage, disk I / O rate, and system call frequency, respectively. When a target symptom item has historical successful remediation samples, the expected behavior profile is generated based on the time mean and standard deviation of the above indicators from those historical successful remediation samples. When a target symptom item does not have historical successful remediation samples, the expected behavior profile is generated jointly by the remediation tool referencing the corresponding script execution instructions, controlled runtime container resource limits, and statistical values ​​of the same indicator for verified symptom items in the same business domain. It is updated to the statistical values ​​of historical successful remediation samples for that symptom item after the first successful remediation feedback is written back.

[0105] The deviation determination result is calculated as follows: ; In the formula, Indicates the number is The deviation determination result is dimensionless; Indicators representing those involved in determining deviation; Indicates the components in the execution monitoring data The average time value within the execution interval; Indicates the number is The mean of the corresponding indicators for the target symptom items in the expected behavior profile; Indicates the number is The standard deviation of the target symptom items in the expected behavior profile; This indicates a zero-protection item.

[0106] In the above formula, the greater the difference between the time mean of the monitoring data and the mean in the expected behavior profile, the greater the deviation judgment result; the larger the standard deviation of the corresponding indicator in the expected behavior profile, the higher the tolerance of the historical successful repair samples for the fluctuation of the indicator, and the smaller the deviation judgment result corresponding to the same difference; the zero protection term is used to avoid the division by zero problem when the standard deviation is 0.

[0107] When the deviation exceeds the upper limit of the acceptable range, a rollback operation is triggered. The rollback operation reads key configuration file copies, process startup parameters, connection configurations, and target resource status fields from the state snapshot. It overwrites the original path with the key configuration files, restarts the target process according to the process startup parameters, restores the service connection according to the connection configuration, and verifies the status of the running node after the rollback using the target resource status fields. At that time, the rollback process is triggered: ; In the formula, This indicates the upper limit of the acceptable range, set to 3.0; This represents a rollback operator that restores the state based on a snapshot. Indicates the number is The task of isolation and repair; Indicates the number is State snapshot; This indicates the status of the running node after rollback.

[0108] When the deviation determination result exceeds the upper limit of the acceptable range, it indicates that the repair action deviates from the expected range of historical successful repair samples in terms of execution trajectory or resource consumption. The system rolls back according to the state snapshot and rewrites the success flag in the current repair execution result to 0. When the deviation determination result does not exceed the upper limit of the acceptable range, the rollback action is not triggered, and the repair execution result maintains the success flag after consistency verification.

[0109] S6. Desensitize and extract indicators from the repair execution results, generate repair feedback data, and write the repair feedback data back to the shareable symptom knowledge base to update the success rate weight of the corresponding symptom entries and generate an iterated symptom knowledge base. In this embodiment, step S6 includes the following process: The runtime parameters and business fields in the repair execution results are anonymized, desensitized, and numerically binned to obtain repair feedback data. Based on the success identifier, execution time, environmental characteristics, and consistency hit rate in the repair feedback data, symptom item weight update values ​​are generated. The success rate weight of the target symptom item is adjusted based on the symptom item weight update values ​​to obtain the weight-adjusted symptom item. An incrementing version number is registered for the weight-adjusted symptom item through a version management channel, and the weight-adjusted symptom item replaces the corresponding symptom item in the shareable symptom knowledge base, resulting in the iterative symptom knowledge base.

[0110] Specifically, the repair feedback data refers to the feedback records extracted, anonymized, and structured from the repair execution results and execution monitoring data, used to write back the success rate weights of the target symptom entries. Running parameters refer to the resource usage samples and execution trajectory generated during the repair execution process; business fields refer to the target resource identifier, the hostname of the running node, and the accounts involved. The anonymization and de-identification processing operator consists of three interconnected sub-processes: sensitive pattern replacement, numerical bucketing quantization, and field whitelist filtering. Sensitive pattern replacement uses the sensitive pattern set from S1; numerical bucketing quantization maps CPU utilization, memory usage, and disk I / O rate to bucket center values ​​according to preset bucket widths; field whitelist filtering retains only the fields required for the write-back success rate weights.

[0111] Anonymization and desensitization are performed as follows: ; In the formula, Indicates the number is The repair feedback data carries the idempotent bonds after desensitization. Script identifier Version number Consistency hit rate Repair time Success indicator Running parameter time mean vector Source identification after desensitization There are a total of 8 components; The anonymization and desensitization operator consists of three interconnected processes: sensitive pattern replacement, numerical bucketing quantization, and field whitelist filtering. Indicates the number is The results of the repair execution; Indicates the number is Execution monitoring data; Indicates the number is The set of business fields corresponding to the repair execution result includes at least the target resource identifier, the hostname of the running node, the account involved, and the source identifier.

[0112] The time mean vector of running parameters is aligned with the scale during the desensitization process. Specifically, the time mean of CPU utilization, memory utilization, and disk I / O rate are calculated from the execution monitoring data, and the data is quantized into buckets according to the preset bucket width before the bucket center value is taken.

[0113] In the above processing, numerical fields are first bucketed according to their respective dimensions, and then dimensionless through resource limits during subsequent environmental feature score calculations. Therefore, the problem of directly adding different dimensions will not occur. CPU utilization is bucketed by percentage bucket width, memory utilization is bucketed by megabyte bucket width, and disk I / O rate is bucketed by megabytes per second bucket width. After bucketing, the center value of the bucket is taken and filled into the runtime parameter mean vector.

[0114] The calculation of remediation effectiveness metrics extracts four criteria from the remediation feedback data: success flag, consistency hit rate, execution time, and environmental characteristics. Execution time is dimensionless using an exponential decay term; environmental characteristics are normalized using resource limits to obtain an environmental characteristic score. The environmental characteristic score reflects the remaining resource usage of the remediation action within the controlled operating container's resource limits.

[0115] The environmental characteristic score is calculated as follows: ; In the formula, Indicates the number is The environmental characteristic score corresponding to the repair feedback data is dimensionless and its value falls within the interval [0,1]. This represents the set of resource indicators used in the calculation; This represents the components in the time mean vector of the running parameters. The value of ; This represents the resource metrics agreed upon by the controlled running containers in S5. The resource limits are set as follows: CPU limit is 200% (2 cores), memory limit is 4096 megabytes, and disk I / O limit is 100 megabytes per second.

[0116] In the above formula, the closer the time mean of the operating parameter is to the corresponding resource limit, the smaller the margin of the corresponding resource indicator and the smaller the environmental characteristic score; the lower the time mean of the operating parameter is to the corresponding resource limit, the larger the margin of the corresponding resource indicator and the larger the environmental characteristic score. When the time mean of a certain operating parameter exceeds the corresponding resource limit, that term is truncated to 0 using a maximum value function to avoid negative values ​​being dragged down outside the interval. Each term is divided by values ​​of the same dimension, and the resulting ratio is a dimensionless value. The three dimensionless values ​​are then averaged and combined.

[0117] After obtaining the environmental feature scores, the success identifier, consistency hit rate, time consumption, and environmental feature items are merged in a linear fusion manner to obtain the symptom item weight update value. The symptom item weight update value refers to the basis for updating the success rate weight of the target symptom item in this remediation feedback. The calculation of the symptom item weight update value is as follows: ; In the formula, From the number The symptom item weight update value generated from the repair feedback data is used to update the success rate weight of the target symptom item corresponding to the repair feedback data. It is dimensionless and its value falls within the interval [0,1]. Indicates the fusion weight of the success identifier; Indicates the number is The consistency hit rate corresponding to the repair execution results; This represents the fusion weight of the consistency hit rate term; This indicates the fusion weight of the time-consuming items; Represents the fusion weights of environmental features; Indicates success; This indicates the repair time, in seconds. This represents the time normalization benchmark, in seconds, and is set to 60. Indicates environmental characteristic scores; This represents the natural exponential function.

[0118] The fusion weight for the success identifier is 0.4, the fusion weight for the consistency hit rate is 0.2, the fusion weight for the time consumption is 0.25, and the fusion weight for the environmental feature is 0.15, satisfying the following relationship: ; In the above formula, when the success flag is 1, the symptom item weight update value increases; when the success flag is 0, the success flag item does not contribute positive scores. With the same success flag, a higher consistency hit rate indicates a closer reconciliation between the repaired state and the expected state, resulting in a larger symptom item weight update value. A longer repair time results in a smaller time consumption term and a smaller symptom item weight update value; a shorter repair time results in a larger time consumption term and a larger symptom item weight update value. A higher environmental feature score indicates a lower resource consumption relative to the resource limit, resulting in a larger symptom item weight update value. The time normalization benchmark and repair time are both in seconds; therefore, the input to the exponential function is dimensionless, and the output is also dimensionless. The success flag item, consistency hit rate item, time consumption term, and environmental feature term are all dimensionless, and their fusion yields a dimensionless symptom item weight update value.

[0119] The fusion weights are obtained as follows: Historical repair samples and manually annotated repair quality results are read. Successful identification, consistency hit rate, time consumption, and environmental features are used as independent variables, and manually annotated repair quality is used as the target value for regression fitting. The fusion weights for these components are then written into a parameter table. In this embodiment, the fusion weight for successful identification is 0.4, for consistency hit rate it is 0.2, for time consumption it is 0.25, and for environmental features it is 0.15. The time consumption normalization benchmark is determined to be 60 seconds based on the median of historical repair sample time statistics.

[0120] After obtaining the updated symptom item weights, the updated symptom item weights are written back to the success rate weights of the target symptom items using an exponential moving average method. The exponential moving average method is a smooth update method that integrates new and old values ​​with a fixed learning rate.

[0121] The success rate weighting is adjusted as follows: ; In the formula, Indicates the number is The success rate weight of the symptom items after weight adjustment; Indicates the number is The success rate weight of symptom items before weight adjustment; This represents the learning rate, which is dimensionless and takes values ​​within the interval (0,1), and is set to 0.1. Indicates that it is numbered The symptom entry weight update value generated from the repair feedback data is used to update the number of the symptom entries. Success rate weights for target symptom items; numbered as The repair feedback data and number are The correspondence between target symptom entries is determined by the unified encoding of the target symptom entries in the repair execution result.

[0122] After the success rate weight is adjusted, an incrementing version number is registered through the version management channel. Each weight adjustment generates a version record, which includes the symptom entry number, the success rate weight after the weight adjustment, the idempotency key, the write-back time, and the registered version number.

[0123] After version registration is complete, the corresponding symptom entries in the shareable symptom knowledge base are replaced with the weighted symptom entries to obtain the iterated symptom knowledge base. The weighted symptom entries retain the unified coding, standardized symptom description, applicable field identifier, repairable identifier, repair tool reference, and symptom feature description, and update the success rate weight and version number.

[0124] S7. Use the iterated symptom knowledge base as the retrieval basis for the next round of anomaly matching.

[0125] In this embodiment, step S7 includes the following process: The system loads symptom entries from the iterated symptom knowledge base, reads symptom feature descriptions, and generates symptom feature vectors according to the homologous encoding method in S4. It then writes the symptom feature vectors, success rate weights, version numbers, applicable domain identifiers, repairable identifiers, and repair tool references into the index nodes to generate a retrieval base. This retrieval base is then synchronized with the version registration results in the version management channel and written to disk. Read / write isolation is performed between the old and new retrieval bases based on the version number. In the next round of anomaly matching, the new anomaly feature vector is input into the retrieval base for nearest neighbor lookup to obtain a set of nearest neighbor symptom entries. This set of nearest neighbor symptom entries is then filtered and sorted according to a preset trust threshold, business domain label, repairable identifier, and success rate weight to generate the next round of target symptom entries, driving the generation of the next round of repair execution plans and the write-back of repair feedback.

[0126] Specifically, the retrieval base refers to the approximate nearest neighbor index composed of all symptom entries in the iterated symptom knowledge base, used to receive the next round of abnormal feature vectors and return a set of nearest neighbor symptom entries. An index node is a data node in the retrieval base corresponding to a symptom entry. Each index node stores at least the symptom feature vector, success rate weight, version number, applicable domain identifier, repairable identifier, and repair tool reference. The symptom feature vector is used for approximate nearest neighbor queries; the success rate weight is used for weighted sorting within the set of nearest neighbor symptom entries; the version number is used for read / write isolation and version tracking; the applicable domain identifier and repairable identifier are used for secondary filtering; and the repair tool reference is used for generating subsequent repair execution plans.

[0127] After the iterated symptom knowledge base is written to the version management channel, the retrieval base builder reads the symptom entries one by one. The retrieval base is constructed as follows: ; In the formula, Indicates the number is The retrieval base carries an equal number of index nodes as the iterated symptom knowledge base; This indicates an index building operator based on the HNSW adjacency graph. HNSW stands for HierarchicalNavigable Small World. Indicates the number is The symptom feature descriptions in the symptom entries are generated as symptom feature vectors according to the homologous coding method in S4; Indicates the number is The success rate weight after adjusting the weight of symptom items; Indicates the number is The version number of the symptom entry after registration; Indicates the number is The symptom entries carry the identifier of the applicable field; Indicates the number is The symptoms listed carry a repairability indicator; Indicates the number is The symptom entries include references to repair tools; Indicates the number is The symptom entries after weight adjustment; This represents the iterative symptom knowledge base; This indicates the maximum number of edges that can be connected to each node; Indicates the search width during the build phase.

[0128] In the above formula, the more symptom entries there are, the more index nodes there are in the retrieval base; the larger the upper limit of the number of connections per node, the more neighboring nodes each index node can connect to, improving retrieval recall but increasing index space usage; the larger the search width during the construction period, the larger the candidate neighbor search range during construction, improving index quality but increasing construction time. The preset number of connections per node and the preset search width during the construction period are determined by offline evaluation and retrieval throughput stress test results under the symptom entry scale and are written into the parameter table of the retrieval base builder. In this step, the upper limit of the number of connections per node and the search width during the construction period are not dynamically adjusted at runtime; when the version management channel updates the parameter table, the retrieval base builder reads the new parameter values ​​during the next index refresh.

[0129] The distance metric for the approximate nearest neighbor index uses the cosine distance form of one minus cosine similarity, which is homologous to the cosine similarity of the anomaly feature vector and symptom feature vector in the previous steps. Specifically, the retrieval basis builder reads the symptom feature vector and compares the cosine distances between different symptom feature vectors according to the HNSW adjacency graph construction rules. The smaller the cosine distance, the easier it is for two symptom entries to form a nearest neighbor connection in the index graph. Since the symptom feature vectors have already undergone normalization, the distance metric is not affected by the vector length.

[0130] After the search base is built, it is synchronized and persisted to disk along with the version registration results in the version management channel. This synchronization means writing the completed search base file, search base version number, build parameters, and symptom entry version registration results to persistent storage. Read-write isolation means that while online search requests continue to read the old search base, the search base builder writes the new search base in the background. Once the new search base is built and passes version number verification, the online read pointer is switched to the new search base, ensuring that online search requests always hit the specified search base version.

[0131] In the above process, strictly incrementing version numbers is a prerequisite for performing atomic replacement; if the version number of any symptom entry after registration is not greater than the version number before registration, the replacement stops and the previous round of retrieval base is retained. Through this process, online retrieval requests will not read both the old and new retrieval bases simultaneously in the same round of anomaly matching, thereby avoiding inconsistent sets of nearest neighbor symptom entries generated by the same anomaly feature vector on different version indexes.

[0132] After the iterative symptom knowledge base is in place, the next round of anomaly matching connects to the aforementioned processing link in a rolling window format. The log collection probes of the running nodes continuously access the runtime log stream, generating structured log records according to a preset collection window. Then, a new set of anomaly feature vectors is generated by a multi-layer text feature extractor and a linear projection matrix. Each new anomaly feature vector enters the retrieval basis for an approximate nearest neighbor query. `Query` represents the approximate nearest neighbor query operator, which calls the HNSW adjacency graph to search layer by layer starting from the entry node. It first roughly locates nearby regions in the upper-layer graph, then expands candidate nodes in the lower-layer graph according to the search width during the query period, and finally returns a preset number of nearest symptom entries. The generation of the nearest symptom entry set is as follows: ; In the formula, Indicates the number is The set of nearest neighbor symptom entries obtained from the abnormal feature vectors on the retrieval basis; This represents the approximate nearest neighbor query operator; Indicates the number is The retrieval base; Indicates the number is The abnormal feature vector; This indicates the number of nearest neighbors returned. Indicates the search width during the query period.

[0133] In the above formula, a larger number of nearest neighbors returned means more candidate entries in the nearest symptom entry set, increasing recall but increasing the amount of data for subsequent filtering and sorting. A larger query-period search width means more candidate index nodes are expanded during the query, increasing query recall but increasing query latency. The preset number of nearest neighbors returned and the preset query-period search width are determined by offline evaluation of samples and symptom entries and stress test results of the inbound rate of running nodes, and are written into the retrieval base query parameter table. In this step, the number of nearest neighbors returned and the query-period search width are not adjusted during a single query. When the stress test results show that the single query latency exceeds the preset latency limit, the query-period search width is reduced first, and then the number of nearest neighbors returned is reduced to prioritize preserving the coverage of the candidate set.

[0134] After obtaining the set of neighboring symptom entries, the next round of target symptom entries is generated by filtering and sorting according to the aforementioned process of reliable threshold filtering, secondary screening with business domain labels and repairable identifiers, and success rate weighted scoring.

[0135] The foregoing has shown and described the basic principles, main features, and advantages of this application. Those skilled in the art should understand that this application is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this application. Various changes and modifications can be made to this application without departing from the spirit and scope thereof, and all such changes and modifications fall within the scope of this application as claimed. The scope of protection of this application is defined by the appended claims and their equivalents.

Claims

1. A self-healing method for a software system driven by a shareable symptom knowledge base, characterized in that, The method includes: Obtain cross-entity fault handling records, and perform desensitization, normalization, hierarchical organization, and unified coding registration on the cross-entity fault handling records to generate a shareable symptom knowledge base. The shareable symptom knowledge base includes symptom feature descriptions, applicable field identifiers, repairable identifiers, repair tool references, and success rate weights. Collect runtime log streams of the monitored software system, and perform field segmentation, template normalization, and session aggregation on the runtime log streams to generate structured log records; The structured log records are subjected to anomaly event filtering and semantic encoding to generate anomaly feature vectors; The abnormal feature vector is compared with the symptom feature description in the shareable symptom knowledge base for similarity, and then filtered and sorted in combination with the applicable domain identifier, the repairable identifier and the success rate weight to generate target symptom entries; A repair execution plan is generated based on the repair tool reference of the target symptom entry, and the repair execution plan is executed idempotently in a controlled isolation environment to generate repair execution results; The repair execution results are anonymized and indicators are extracted to generate repair feedback data. The repair feedback data is then written back to the shareable symptom knowledge base to update the success rate weights of the corresponding symptom entries and generate an iterated symptom knowledge base. The iterative symptom knowledge base will be used as the retrieval basis for the next round of anomaly matching.

2. The method according to claim 1, characterized in that, The generation of a shareable symptom knowledge base includes: Receive de-identified fault texts and handling process descriptions reported by different entities, and merge the de-identified fault texts and handling process descriptions into the original fault corpus; Sensitive fields are stripped and representations are normalized from the original fault corpus to obtain standardized symptom descriptions. The standardized symptom descriptions are categorized and hierarchically according to business domains, and a unified code of a predetermined number of bits is assigned to each standardized symptom description to generate symptom entries; The symptom entries are registered and stored in the database through a version management channel and a multi-party verification process, thereby generating the shareable symptom knowledge base.

3. The method according to claim 2, characterized in that, The standardized symptom description obtained includes: The original fault corpus is scanned by loading a set of sensitive patterns, and the sensitive fields that are hit are replaced with placeholders to obtain the stripped text. The stripped text is then subjected to synonym replacement, stop word cleaning, and time field templated to obtain candidate standardized text. The candidate standardized texts are compared for similarity. When the similarity reaches a preset merging threshold, the corresponding candidate standardized texts are merged into the same standardized symptom description. The applicable domain identifier is determined based on the valid terms in the standardized symptom description and the statistical weights of the business domain. The standardized symptom description, the applicable domain identifier, the unified code, the repairable identifier, the repair tool reference, and the success rate weight are then encapsulated into the symptom entry.

4. The method according to claim 1, characterized in that, The generation of structured log records includes: Access the runtime log stream at the running node of the monitored software system to obtain the raw log stream; The log entries in the original log stream are segmented by fields to obtain fielded log entries containing timestamps, log levels, source identifiers, and message body. Log templates are extracted from the text messages in the fieldized log entries, and placeholders are updated for inconsistent words based on the word position matching results to obtain a log template sequence. The log template sequence is context-associated and session-aggregated according to the time window to obtain a structured log record containing session start and end time, business domain, source identifier, template number and variable parameter vector.

5. The method according to claim 1, characterized in that, The generation of the abnormal feature vector includes: The frequency of log levels and log templates in the structured log records is normalized and merged to obtain an anomaly score; The structured log records are filtered according to a preset anomaly scoring threshold to obtain a set of candidate anomaly events; Using the highest-level log entry in the candidate abnormal event set as the anchor point, extract the preceding log template sequence item and the subsequent log template sequence item, and concatenate them to obtain the event text; The event text is subjected to semantic embedding, context concatenation, dimension alignment, and normalization to obtain the abnormal feature vector.

6. The method according to claim 2, characterized in that, The generation of target symptom entries includes: The symptom feature descriptions of each symptom entry in the shareable symptom knowledge base are subjected to homologous encoding and normalization to obtain symptom feature vectors; The abnormal feature vector and the symptom feature vector are compared item by item to obtain a similarity score set; The similarity score set is sorted in descending order and filtered according to a preset confidence threshold to obtain a candidate symptom set; Based on the consistency between the business domain label of the current running node and the applicable domain identifier, the repairable identifier, and the success rate weight, the candidate symptom set is further filtered and sorted to obtain the target symptom entries.

7. The method according to claim 6, characterized in that, Also includes: When the candidate symptom set is empty, collect the abnormal feature vectors that occur multiple times but are not hit to obtain the missed sample pool; Cluster analysis was performed on the missed sample pool to obtain unknown anomaly clusters; Based on the central features and high-frequency context of the unknown anomaly cluster, candidate symptom descriptions and suggested repair tool references are generated to obtain symptom entries to be reviewed; The symptom entries to be reviewed are submitted to the multi-party verification process for cross-confirmation, and after passing the verification, a unified code is assigned and written into the shareable symptom knowledge base to obtain the expanded symptom knowledge base.

8. The method according to claim 1, characterized in that, The generation of repair execution results includes: Parse the repair tool reference of the target symptom entry to obtain the script identifier and version number, and obtain the execution parameters from the parameter field of the repair tool reference or the script registration information corresponding to the script identifier and the version number; The repair script is loaded from the repair script repository according to the script identifier and the version number, and the verified repair script, the execution parameters and the idempotent key are encapsulated into a repair execution plan. The repair execution plan is loaded into a controlled runtime container to obtain an isolated repair task; A state snapshot is generated before the isolation repair task is executed; repeated calls are masked according to the idempotent key during execution; and result consistency is checked after execution to obtain the repair execution result. When the deviation between the monitored data and the expected behavior profile exceeds a preset acceptable range, the state of the run node after rollback is generated based on the state snapshot, and the execution failure mark is written into the repair execution result.

9. The method according to claim 8, characterized in that, The generated iterative symptom knowledge base includes: Anonymize, desensitize, and bin numerical quantize the running parameters and business fields in the repair execution results to obtain repair feedback data; Based on the success identifier, execution time, environmental characteristics, and consistency hit rate in the repair feedback data, generate symptom item weight update values; Based on the updated weight value of the symptom item, the success rate weight of the target symptom item is adjusted to obtain the weight-adjusted symptom item; The version management channel is used to register incremental version numbers for the weighted symptom entries, and the weighted symptom entries are used to replace the corresponding symptom entries in the shareable symptom knowledge base to obtain the iterative symptom knowledge base.

10. The method according to claim 9, characterized in that, The step of using the iterated symptom knowledge base as the retrieval basis for the next round of anomaly matching includes: Load the symptom entries in the iterated symptom knowledge base, read the symptom feature descriptions in the symptom entries, and generate symptom feature vectors according to the homologous encoding method. Write the symptom feature vectors, success rate weights, version numbers, applicable field identifiers, repairable identifiers, and repair tool references into the index nodes to generate the retrieval base. The search base and the version registration results in the version management channel are synchronized and written to disk, and the old and new search bases are read and write isolated based on the version number; In the next round of anomaly matching, the new anomaly feature vector is input into the retrieval basis to perform a nearest neighbor query, thereby obtaining a set of nearest neighbor symptom entries; The set of neighboring symptom entries is filtered and sorted according to a preset confidence threshold, business domain label, repairable identifier and success rate weight to generate the next round of target symptom entries, thereby driving the generation of the next round of repair execution plan and repair feedback write-back.

Images