Software behavior anomaly detection method and device, computer equipment and storage medium

Abstract

The invention belongs to the technical field of software detection, and relates to a software behavior anomaly detection method and device, computer equipment and a storage medium, and the method comprises the steps: determining a monitoring entity and behavior granularity, defining a behavior index, and formulating an evaluation benchmark; according to the determined monitoring entity and the behavior index, original time sequence data and event flow are collected from the level of software and infrastructure; carrying out data preprocessing on the collected time sequence data and the event stream, extracting time sequence characteristics, and carrying out behavior sequence modeling; performing baseline modeling and anomaly detection; performing alarm association and root cause analysis according to an abnormal detection result; and performing response feedback and model optimization according to a root cause analysis result. The problem can be accurately positioned, the detection accuracy is improved, root cause analysis can be assisted, and continuous optimization is realized.

Description

Technical Field

[0001] This invention relates to the field of software detection technology, and in particular to methods, apparatus, computer equipment, and storage media for detecting abnormal software behavior. Background Technology

[0002] Software behavior anomaly detection involves monitoring various metrics during software operation to identify behaviors that deviate from normal patterns, thereby ensuring system stability and security. Its core function is to capture abnormal states and prevent potential failures or attacks.

[0003] Existing technologies typically employ the following process: First, identify the monitored entities (such as processes and services) and behavioral granularities (such as API call frequency), define behavioral metrics (such as response time and resource utilization), and establish evaluation benchmarks; then, collect time-series data and event streams from software logs, system monitoring tools, etc.; construct behavioral models through data cleaning and feature extraction (such as statistics and time-series patterns); detect anomalies using baseline modeling (such as historical data statistics) or machine learning algorithms (such as Isolation Forest and LSTM); finally, locate the root cause through alarm correlation analysis and provide feedback to optimize the model.

[0004] Existing methods suffer from limitations due to static baselines: relying on historical data to build baselines makes them difficult to adapt to dynamic environments (such as sudden load changes or the launch of new features), leading to false positives or false negatives; feature engineering dependency: manually extracting features requires domain knowledge and may miss key information, affecting the model's generalization ability; coarse-grained root cause analysis: existing methods mostly focus on anomaly detection and lack in-depth analysis of the causal chain of complex systems, making it difficult to quickly locate the root cause; and insufficient model adaptability: failing to fully utilize real-time feedback to optimize the model leads to a decline in detection performance over long-term operation. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for detecting software behavior anomalies, employing the following technical solution, including the following steps:

[0006] Identify the entities and behaviors to be monitored, define behavioral indicators, and establish evaluation benchmarks;

[0007] Based on the identified monitoring entities and behavioral indicators, raw time-series data and event streams are collected from the software and infrastructure levels.

[0008] The collected time-series data and event stream are preprocessed to extract time-series features and perform behavioral sequence modeling.

[0009] Perform baseline modeling and anomaly detection;

[0010] Based on the anomaly detection results, alarm correlation and root cause analysis are performed;

[0011] Based on the results of the root cause analysis, response feedback and model optimization are performed.

[0012] Preferably, the steps of determining the monitoring entity and behavior granularity, defining behavior indicators, and establishing evaluation benchmarks specifically include:

[0013] Determine the granularity of monitored entities and behaviors;

[0014] Define behavioral indicators;

[0015] Establish evaluation benchmarks.

[0016] Preferably, the step of collecting raw time-series data and event streams from the software and infrastructure level based on the determined monitoring entity and the behavioral indicators specifically includes:

[0017] Deploy data acquisition devices;

[0018] Perform data stream aggregation and buffering;

[0019] Define a unified format and time base for data from different sources.

[0020] Preferably, the steps of preprocessing the collected time-series data and event stream, extracting time-series features, and performing behavioral sequence modeling specifically include:

[0021] The collected time-series data and event stream are cleaned and aligned.

[0022] Extracting time series features from raw time series data;

[0023] The discrete event sequence is transformed into numerical features for behavioral sequence modeling.

[0024] Preferably, the steps of baseline modeling and anomaly detection specifically include:

[0025] Using unsupervised or supervised learning methods, learn patterns of normal behavior from historical normal data to model a baseline of normal behavior;

[0026] For a new data point, quantify its deviation from the normal baseline;

[0027] A threshold for abnormal scores is determined; an alarm is triggered if the score exceeds this threshold.

[0028] Preferably, the step of performing alarm correlation and root cause analysis based on the anomaly detection results specifically includes:

[0029] Based on the anomaly detection results, alarm noise reduction and aggregation are performed;

[0030] By linking alerts from different monitoring entities and metrics, the chain of failure propagation can be revealed;

[0031] Root cause analysis and impact analysis were conducted.

[0032] Preferably, the step of performing response feedback and model optimization based on the results of root cause analysis specifically includes:

[0033] Perform predefined response actions for known, common exception types;

[0034] Systematically collect the verification results of alarms;

[0035] The model is periodically retrained using feedback data to adapt it to changes in software and environment.

[0036] To address the aforementioned technical problems, the present invention also provides a software behavior anomaly detection device, which employs the following technical solution, including:

[0037] The definition module is used to determine the granularity of monitored entities and behaviors, define behavioral indicators, and establish evaluation benchmarks.

[0038] The acquisition module is used to acquire raw time-series data and event streams from the software and infrastructure level based on the determined monitoring entities and behavioral indicators.

[0039] The preprocessing module is used to preprocess the collected time-series data and event stream, extract time-series features, and perform behavioral sequence modeling.

[0040] The detection module is used for baseline modeling and anomaly detection;

[0041] The analysis module is used to perform alarm correlation and root cause analysis based on the anomaly detection results;

[0042] The optimization module is used to perform response feedback and model optimization based on the results of root cause analysis.

[0043] To address the aforementioned technical problems, the present invention also provides a computer device that employs the technical solution described below, comprising a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the above-described software behavior anomaly detection method.

[0044] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium, which employs the technical solution described below. The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the aforementioned software behavior anomaly detection method.

[0045] Compared with the prior art, the present invention has the following main advantages:

[0046] Firstly, it can accurately locate problems: by clearly defining the granularity of monitored entities and behaviors, it can focus on key links, and the collected data and constructed models can accurately reflect the software's operating status, quickly locate abnormal locations, and reduce the scope and time of investigation.

[0047] Secondly, it improves detection accuracy: by defining detailed behavioral indicators and evaluation benchmarks, and combining time-series feature extraction and behavioral sequence modeling, it can comprehensively capture software behavior patterns, accurately identify anomalies that deviate from the normal baseline, and reduce false alarms and false negatives.

[0048] Third, it can assist in root cause analysis: the alarm association and root cause analysis process can deeply analyze the underlying reasons for the anomaly, providing a strong basis for subsequent repair and optimization, and preventing the problem from recurring.

[0049] Fourth, it enables continuous optimization. Response feedback and model optimization based on root cause analysis results allow the detection method to continuously adapt to software changes, thereby improving detection capabilities and effectiveness, ensuring long-term stable software operation, and enhancing system reliability and availability. Attached Figure Description

[0050] To more clearly illustrate the solutions in this invention, the accompanying drawings used in the description of the embodiments of this invention will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0051] Figure 1 This is a flowchart of an embodiment of the software behavior anomaly detection method of the present invention;

[0052] Figure 2 This is a schematic diagram of the structure of one embodiment of the software behavior anomaly detection device of the present invention;

[0053] Figure 3 This is a schematic diagram of the structure of an embodiment of the computer device of the present invention. Detailed Implementation

[0054] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects and not to describe a particular order.

[0055] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0056] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0057] It should be noted that the software behavior anomaly detection method provided in the embodiments of the present invention is generally executed by a server / terminal device, and correspondingly, the software behavior anomaly detection device is generally set in the server / terminal device.

[0058] It should be understood that the number of terminal devices, networks, and servers is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be used.

[0059] Example 1

[0060] Please refer to Figure 1 The diagram illustrates a flowchart of an embodiment of the software behavior anomaly detection method of the present invention. The software behavior anomaly detection method includes the following steps:

[0061] Step S1: Determine the monitoring entities and behavioral granularity, define behavioral indicators, and establish evaluation benchmarks.

[0062] In this embodiment, the electronic device (e.g., a server / terminal device) on which the software behavior anomaly detection method runs can receive software behavior anomaly detection requests via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAXX connections, Zigbee connections, UWB (ultra wideband) connections, and other currently known or future-developed wireless connection methods.

[0063] In this embodiment, step S1, determining the monitoring entity and behavior granularity, defining behavior indicators, and establishing evaluation benchmarks, specifically includes the following steps:

[0064] S11, Determine the granularity of monitored entities and behaviors.

[0065] Entity recognition includes entity recognition at the host level, process / service level, user / session level, and network traffic level.

[0066] Host-level: Monitors the behavior of the entire server or virtual machine, such as system call sequences and global resource utilization.

[0067] Process / service level: Monitor the behavior of specific application processes (such as Nginx, MySQL), such as process CPU / memory, network connections, and internal function call chains.

[0068] User / session level: Monitor the behavior sequence of a single user or session, such as user click streams or API call sequences in a web application.

[0069] Network traffic level: Monitor network communication patterns between microservices or Pods, such as request volume, latency, and error code distribution.

[0070] Granularity definitions include single metrics, sets of metrics, and event sequences.

[0071] Single metric: such as CPU utilization. Simple, but with limited information.

[0072] A set of metrics, such as [CPU, Memory, IO], can reflect multi-dimensional states.

[0073] Event sequences: such as system call sequences and API call chains. They can capture complex temporal logic.

[0074] Step S11 clarifies the software objects that need to be monitored and their behavioral abstraction levels.

[0075] S12, define behavioral indicators.

[0076] Step S12 selects a specific metric for each monitored entity to quantify its behavior.

[0077] Defining behavioral metrics includes defining resource metrics, performance metrics, and logical behavioral metrics.

[0078] Resource metrics: CPU utilization, memory usage, disk I / O, network bandwidth.

[0079] Performance metrics: request latency, throughput, error rate, response code distribution (e.g., HTTP 5xx ratio).

[0080] Logical behavior metrics include function call frequency, system call sequence, and log event patterns.

[0081] Function call frequency: The number of times a specific function is called within a time window.

[0082] System call sequence: A sequence of low-level behaviors provided by the operating system kernel, which is very effective in detecting intrusions.

[0083] Log event pattern: The frequency of occurrence of specific errors or events extracted from application logs.

[0084] S13, Establish evaluation criteria.

[0085] Step S13 predefines metrics for measuring the performance of the detection system and an acceptable baseline.

[0086] Key performance indicators include accuracy, precision, recall, and F1-Score.

[0087] Accuracy: The percentage of correct results (whether normal or abnormal) among all test results.

[0088] Accuracy: The proportion of detected abnormal behaviors that are actually abnormal. High accuracy means low false alarms, which is crucial for operations and maintenance.

[0089] Recall rate: The percentage of all genuine anomalies that are successfully detected by the system. A high recall rate means a low false negative rate, which is crucial for security.

[0090] F1-Score: The harmonic mean of precision and recall, a comprehensive and balanced metric.

[0091] Business metrics: average detection time, average response time.

[0092] Set a goal: For example, "To maximize recall while ensuring precision is no less than 95%".

[0093] Step S1 clarifies what needs to be protected and what constitutes anomalies, providing guidance for all subsequent technology selections and data processing. The outputs of Step S1 (such as monitored entities, behavioral indicators, and evaluation criteria) directly determine the specific content of data collection in Step S2.

[0094] Step S2: Based on the identified monitoring entities and behavioral indicators, collect raw time-series data and event streams from the software and infrastructure level.

[0095] Step S2 is the specific execution of the target definition. Based on the monitoring entities and metrics determined in Step S1, it collects raw time-series data and event streams from various levels of software and infrastructure. The output of Step S2 is massive amounts of unprocessed monitoring data, which forms the data foundation for feature engineering in Step S3.

[0096] In this embodiment, step S2, which involves collecting raw time-series data and event streams from the software and infrastructure level based on the determined monitoring entities and behavioral indicators, specifically includes the following steps:

[0097] S21, Deploy the data acquisition unit.

[0098] Install and configure the data collection agent in the target software environment via step S21.

[0099] Deploying data collectors enables system-level, application-level, and network-level data collection.

[0100] System-level data collection: Agents, such as Telegraf and Datadog Agent, are deployed on the host to collect system metrics; eBPF, a revolutionary kernel model, allows for secure and efficient collection of kernel events (such as system calls and network packets) without modifying the code.

[0101] Application-level data collection: Code instrumentation, embedding data points in application code (such as using the OpenTelemetry library) to collect function call chains and business metrics; Sidecar pattern, in a microservice architecture, deploying a proxy Sidecar (such as Envoy) for each service instance to collect traffic and logs uniformly.

[0102] Network-level data collection: Collects network traffic data through network traffic mirroring and NetFlow / sFlow protocols.

[0103] S22 performs data stream aggregation and buffering.

[0104] Step S22 aggregates the data from the scattered collection points into the central processing system and resolves the data rate mismatch problem.

[0105] Data stream aggregation and buffering are achieved through message queues / log aggregation, stream processing platforms, and time-series databases.

[0106] Message queue / log aggregation: Utilizes Kafka, RabbitMQ, etc., as a data bus to receive data streams from various collectors. They offer high throughput and buffering capabilities, decoupling the collection and processing processes.

[0107] Stream processing platform: Uses Flink and Spark Streaming to perform preliminary cleaning and aggregation of data streams.

[0108] Time series databases: The data is ultimately written to time series databases such as Prometheus and InfluxDB, which are optimized for efficient writing and querying of time series data.

[0109] S23 defines a unified format and time base for data from different sources.

[0110] Step S23 defines a uniform format and time base for data from different sources.

[0111] By standardizing formats, synchronizing timestamps, and tagging metadata, a unified format and time reference are defined for data from different sources.

[0112] Standardize the format: Convert all data into a uniform format, such as JSON or Protobuf, and include the required fields: timestamp, entity_id, metric_name, and metric_value.

[0113] Timestamp synchronization: This addresses the issue of clock asynchrony between different data collectors. It may be necessary to embed the collector's local timestamp and Coordinated Universal Time (UTC) stamp into the data.

[0114] Metadata tagging: Add rich tags to the data, such as host=web-server-01, service=payment-api, region=us-east-1, to facilitate subsequent filtering and aggregation.

[0115] Step S3: Perform data preprocessing on the collected time-series data and event streams, extract time-series features, and perform behavioral sequence modeling.

[0116] Raw monitoring data is typically characterized by high noise, high dimensionality, and missing values, making it unsuitable for direct input into the model. Step S3 takes the raw data gathered in step S2, cleans and transforms it, and extracts features that can effectively characterize the software's behavioral patterns. The output of this step is a high-quality, model-usable feature vector, which is crucial for building an accurate behavioral baseline.

[0117] In this embodiment, step S3, which involves preprocessing the collected time-series data and event streams to extract time-series features and perform behavioral sequence modeling, specifically includes the following steps:

[0118] S31 performs data cleaning and alignment on the collected time-series data and event streams.

[0119] Step S31 addresses data quality issues and aligns multi-source data on the timeline.

[0120] By handling missing values, smoothing noise, and aligning time windows, the collected time-series data and event streams are cleaned and aligned.

[0121] Handling missing values ​​involves two aspects: deletion and interpolation. Deletion involves directly deleting data from a given time point if the missing proportion is too high. Interpolation involves using forward imputation, linear interpolation, or more complex spline interpolation to estimate missing values.

[0122] Noise smoothing: Use moving averages or low-pass filters (such as Savitzky-Golay filters) to smooth out random fluctuations in the data and highlight trends.

[0123] Time window alignment: Align metrics collected at different frequencies (such as CPU data collected once per second and network traffic data collected once every 5 seconds) to a unified time window (such as a point every 5 seconds) through downsampling or upsampling.

[0124] S32 extracts time series features from the original time series data.

[0125] Extract meaningful statistical features from raw time series data, such as statistical features, trend features, and periodic features.

[0126] Statistical characteristics: Calculate the following within each time window: mean, standard deviation, median, maximum, minimum, and percentile (e.g., 95th).

[0127] Trend characteristics: Calculate the slope of the linear regression within the sliding window, or the difference / ratio with the previous window.

[0128] Periodic characteristics: Extract daily and weekly patterns of behavior through Fourier transform or autocorrelation analysis.

[0129] S33 transforms discrete event sequences into numerical features for behavioral sequence modeling.

[0130] Step S33 converts the discrete event sequence (such as system calls) into numerical features.

[0131] First, an N-gram model is used to divide the event sequence into continuous subsequences of length N, and the frequency of each N-gram is counted. For example, when N=2, the 2-grams of the sequence ABCA are AB, BC, and CA.

[0132] Then, sequence embedding is performed: using Word2Vec or Doc2Vec, the entire event sequence or a single event is mapped to a low-dimensional dense vector. This vector can capture the semantic information of the sequence.

[0133] Then, construct a behavioral profile: for each entity (such as a user), aggregate all its behavioral characteristics (statistical characteristics + N-gram frequency, etc.) during the normal period to form a multivariate distribution, which serves as its normal behavioral profile.

[0134] Step S4: Perform baseline modeling and anomaly detection.

[0135] Step S4 uses the feature data collected during normal operation, generated in step S3, to learn normal behavioral patterns, i.e., establish a baseline. Then, the real-time incoming feature data is compared to this baseline to identify deviations, i.e., anomalies. The feature vector is the input, and the anomaly score or label is the output.

[0136] In this embodiment, step S4, baseline modeling and anomaly detection, specifically includes the following steps:

[0137] S41 uses unsupervised or supervised learning methods to learn patterns of normal behavior from historical normal data and to model the baseline of normal behavior.

[0138] Unsupervised learning: Training using only normal data (or assuming that most of the data is normal).

[0139] The Gaussian distribution model assumes that each feature follows a normal distribution and models it by calculating its mean and variance. It is suitable for univariate indicators.

[0140] The multivariate Gaussian distribution can capture the correlation between features. Its probability density function is:

[0141] Where x is the eigenvector, μ is the mean vector of the eigenvectors, Σ is the covariance matrix, |Σ| is the determinant of Σ, and T denotes transpose. This formula calculates the probability that vector x appears in a multivariate normal distribution defined by μ and Σ. (x-μ) T Σ -1 (x-μ) is called the squared Mahalanobis distance, which measures the distance between a data point x and the mean μ, taking into account the correlation of the data and the shape of the data distribution. This formula calculates the probability that a data point x appears in a multivariate normal distribution. The lower the probability, the more likely x is to be an anomaly.

[0142] Supervised learning: If there are clear labels for normal and abnormal samples, classification algorithms (such as random forest and XGBoost) can be used to directly learn the distinction rules.

[0143] S42, for a new data point, quantifies its deviation from the normal baseline.

[0144] A method based on reconstruction error can be used to quantify the deviation of a new data point from the normal baseline: using dimensionality reduction techniques such as autoencoders or PCA. The model first learns how to compress and then restore (reconstruct) normal data. Abnormal data, due to its different patterns, will have a large reconstruction error.

[0145] The reconstruction error formula is: Error=||xx′|| 2 , where x is the original input feature vector, and x′ is the vector reconstructed by the model. The larger the error, the higher the anomaly score.

[0146] Distance / density-based methods, such as the Local Outlier Factor (LOF) algorithm. The formula for the Local Outlier Factor (LOF) is: Where p: the data point to be measured, N k (p): The set of k nearest neighbors of point p, |Nk (p)|: Size of the set (i.e., k), lrd k (p): Local reachability density of point p, representing the density relationship between point p and its neighbors, lrd k (o): Local reachability density of neighboring point o.

[0147] This formula calculates the outlier score of point p. If LOF ≈ 1, it means that p has the same density as its neighborhood; if LOF is significantly greater than 1, it means that p is in a relatively sparse region and is an outlier.

[0148] Prediction-based methods: Use time series models (such as LSTM, Transformer) to predict the indicator value at the next time point. If the actual value differs too much from the predicted value, it is considered an anomaly.

[0149] S43, determine a critical point for abnormal scores, and trigger an alarm if the score exceeds this point.

[0150] A quantile method can be used: calculate the distribution of abnormal scores on historical normal data, and set the threshold at a certain high quantile, such as the 99.5th quantile. This means that 99.5% of normal behaviors have scores below this threshold.

[0151] Peak detection algorithms can also be used: using extreme value theory algorithms such as SPOT / BiSPOT, the threshold is dynamically set according to the peak value of the outlier score, which is suitable for streaming data.

[0152] Feedback optimization: Based on the false alarm situation of the initial alarm, the threshold is manually adjusted. This is an iterative process.

[0153] Step S5: Based on the anomaly detection results, perform alarm correlation and root cause analysis.

[0154] Step S4 generates a large number of low-level anomalous events, but these events may be isolated, repetitive, or even false alarms. Step S5 aims to intelligently aggregate and correlate these raw alerts, deduce the root causes, and transform the signals into insights. The raw alerts are the input, and the aggregated critical alerts with root cause explanations are the output.

[0155] In this embodiment, step S5, which involves performing alarm correlation and root cause analysis based on the anomaly detection results, specifically includes the following steps:

[0156] S51 performs alarm noise reduction and aggregation based on the anomaly detection results.

[0157] Step S5 can reduce the number of alarms and prevent alarm storms.

[0158] A window aggregation method can be used: multiple alerts from the same entity or the same indicator within a short period of time can be merged into one.

[0159] Alternatively, a rule-based deduplication method can be used: define rules to compress duplicate alarms describing the same problem (such as simultaneous alarms from the CPU and memory of the same host).

[0160] Another approach is to use false alarm filtering: establish a false alarm rule base, for example, specific alarms generated during known batch operation and maintenance can be automatically silenced.

[0161] S52 links alerts from different monitored entities and metrics to reveal the chain of failure propagation.

[0162] Step S52 links alerts from different monitoring entities and metrics to reveal the chain of failure propagation.

[0163] Topology association can be used: based on the system architecture diagram (such as a service dependency diagram or network topology diagram). If service A depends on service B, then an anomaly alert in service B is likely to cause an anomaly alert in service A, so they can be associated.

[0164] Alternatively, a time series correlation approach can be used: statistical methods such as Granger causality tests or transfer entropy can be employed to analyze the chronological order of the occurrence of anomalies in different indicators and infer causal relationships.

[0165] Graph algorithms can also be used: construct a graph of alerts and resources, and use community detection algorithms to find densely related alert clusters that may point to a common root cause.

[0166] S53, conduct root cause localization and impact analysis.

[0167] Step S53 locates the initial source of a series of anomalies and assesses its scope of impact.

[0168] Decision trees / random forests can be used: train a model whose input is the outlier state of all indicators, and whose output is the most likely root cause component. The interpretability of the model (such as feature importance) can help in localization.

[0169] Root cause analysis in a microservice architecture: Combine distributed tracing data (such as Jaeger, SkyWalking) to quickly locate the earliest service in the call chain that experienced a delay or error.

[0170] Next, an impact propagation analysis is performed: on the topology graph, starting from the suspected root cause node, the downstream nodes affected by it are traversed to visually display the impact of the fault.

[0171] Step S6: Based on the results of the root cause analysis, perform response feedback and model optimization.

[0172] Step S6 is the closing and evolutionary stage of this embodiment. It takes action on the high-confidence alarm generated in step S5 and collects the handling results and expert feedback. This feedback information is fed back as new labeled data to optimize the detection model in step S4, making it increasingly accurate. This is a feedback loop from decision-making to learning.

[0173] In this embodiment, step S6, which involves response feedback and model optimization based on the results of root cause analysis, specifically includes the following steps:

[0174] S61 executes predefined response actions for known, common exception types.

[0175] Set up a script: Preset if-then rules. For example, "If a memory leak is detected in a process, automatically restart the process."

[0176] Integration with operations and maintenance tools: Trigger actions in the operations and maintenance system, such as elastic scaling, traffic switching, and isolation of faulty nodes, through Webhook or API calls.

[0177] Notification and Reporting: Alert information will be pushed to relevant personnel via SMS, email, DingTalk, Slack, and other channels.

[0178] S62 systematically collects the verification results of alarms.

[0179] Explicit feedback is available: the alarm management interface provides buttons for confirmation, false alarm, and marking as fixed, allowing maintenance personnel to directly provide labels.

[0180] Implicit feedback: Inferences are made by monitoring subsequent operations. For example, if an alert is triggered and an operations and maintenance personnel quickly log in to the server and execute a command, the alert can be indirectly considered valid.

[0181] Feedback storage: Establish a feedback database to store information such as alarm ID, processing result, handler, and timestamp in a structured manner.

[0182] S63 uses feedback data to periodically retrain the model, adapting it to changes in software and environment.

[0183] Supervised learning retraining: The confirmed true anomalies and false alarms are used as new label data to incrementally or periodically retrain the detection model in step S4 (if it is a supervised or semi-supervised model) to improve its discrimination ability.

[0184] Concept drift detection: Monitors the model's predicted distribution or performance metrics (such as decreased accuracy) on new data, automatically detecting changes in the software's normal behavior patterns (e.g., changes in traffic patterns after a new version is released).

[0185] Online learning / adaptive thresholding: For streaming data, online learning algorithms are used to enable the model to dynamically adjust its parameters or thresholds based on the data within the latest short time window to adapt to slow changes.

[0186] The beneficial effects of implementing this embodiment are:

[0187] Firstly, it can accurately locate problems: by clearly defining the granularity of monitored entities and behaviors, it can focus on key links, and the collected data and constructed models can accurately reflect the software's operating status, quickly locate abnormal locations, and reduce the scope and time of investigation.

[0188] Secondly, it improves detection accuracy: by defining detailed behavioral indicators and evaluation benchmarks, and combining time-series feature extraction and behavioral sequence modeling, it can comprehensively capture software behavior patterns, accurately identify anomalies that deviate from the normal baseline, and reduce false alarms and false negatives.

[0189] Third, it can assist in root cause analysis: the alarm association and root cause analysis process can deeply analyze the underlying reasons for the anomaly, providing a strong basis for subsequent repair and optimization, and preventing the problem from recurring.

[0190] Fourth, it enables continuous optimization. Response feedback and model optimization based on root cause analysis results allow the detection method to continuously adapt to software changes, thereby improving detection capabilities and effectiveness, ensuring long-term stable software operation, and enhancing system reliability and availability.

[0191] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0192] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

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

[0194] Example 2

[0195] Further reference Figure 2 As a response to the above Figure 1 The present invention provides an embodiment of a software behavior anomaly detection device, which is similar to the method shown. Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0196] like Figure 2 As shown, the software behavior anomaly detection device 70 described in this embodiment includes: a definition module 71, a data acquisition module 72, a preprocessing module 73, a detection module 74, an analysis module 75, and an optimization module 76. Wherein:

[0197] Definition module 71 is used to determine the granularity of monitoring entities and behaviors, define behavioral indicators, and establish evaluation benchmarks;

[0198] The acquisition module 72 is used to acquire raw time-series data and event streams from the software and infrastructure level based on the determined monitoring entities and behavioral indicators.

[0199] The preprocessing module 73 is used to preprocess the collected time-series data and the event stream, extract time-series features, and perform behavioral sequence modeling.

[0200] Detection module 74 is used for baseline modeling and anomaly detection;

[0201] Analysis module 75 is used to perform alarm correlation and root cause analysis based on anomaly detection results;

[0202] The optimization module 76 is used to perform response feedback and model optimization based on the results of root cause analysis.

[0203] The beneficial effects of implementing this embodiment are:

[0204] Firstly, it can accurately locate problems: by clearly defining the granularity of monitored entities and behaviors, it can focus on key links, and the collected data and constructed models can accurately reflect the software's operating status, quickly locate abnormal locations, and reduce the scope and time of investigation.

[0205] Secondly, it improves detection accuracy: by defining detailed behavioral indicators and evaluation benchmarks, and combining time-series feature extraction and behavioral sequence modeling, it can comprehensively capture software behavior patterns, accurately identify anomalies that deviate from the normal baseline, and reduce false alarms and false negatives.

[0206] Third, it can assist in root cause analysis: the alarm association and root cause analysis process can deeply analyze the underlying reasons for the anomaly, providing a strong basis for subsequent repair and optimization, and preventing the problem from recurring.

[0207] Fourth, it enables continuous optimization. Response feedback and model optimization based on root cause analysis results allow the detection method to continuously adapt to software changes, thereby improving detection capabilities and effectiveness, ensuring long-term stable software operation, and enhancing system reliability and availability.

[0208] Example 3

[0209] To address the aforementioned technical problems, embodiments of the present invention also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.

[0210] The aforementioned computer device 8 includes a memory 81, a processor 82, and a network interface 83 that are interconnected via a system bus. It should be noted that only the computer device 8 with components 81, 82, and 83 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0211] The aforementioned computer devices can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. These devices can facilitate human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0212] The aforementioned memory 81 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the aforementioned memory 81 may be an internal storage unit of the aforementioned computer device 8, such as the hard disk or memory of the computer device 8. In other embodiments, the aforementioned memory 81 may also be an external storage device of the aforementioned computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Of course, the aforementioned memory 81 may also include both the internal storage unit and its external storage device of the aforementioned computer device 8. In this embodiment, the aforementioned memory 81 is typically used to store the operating system and various application software installed on the aforementioned computer device 8, such as computer-readable instructions for software behavior anomaly detection methods. In addition, the aforementioned memory 81 can also be used to temporarily store various types of data that have been output or will be output.

[0213] In some embodiments, the processor 82 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 82 is typically used to control the overall operation of the computer device 8. In this embodiment, the processor 82 is used to execute computer-readable instructions stored in the memory 81 or to process data, such as executing computer-readable instructions for the software behavior anomaly detection method.

[0214] The network interface 83 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 8 and other electronic devices.

[0215] The beneficial effects of implementing this embodiment are:

[0216] Firstly, it can accurately locate problems: by clearly defining the granularity of monitored entities and behaviors, it can focus on key links, and the collected data and constructed models can accurately reflect the software's operating status, quickly locate abnormal locations, and reduce the scope and time of investigation.

[0217] Secondly, it improves detection accuracy: by defining detailed behavioral indicators and evaluation benchmarks, and combining time-series feature extraction and behavioral sequence modeling, it can comprehensively capture software behavior patterns, accurately identify anomalies that deviate from the normal baseline, and reduce false alarms and false negatives.

[0218] Third, it can assist in root cause analysis: the alarm association and root cause analysis process can deeply analyze the underlying reasons for the anomaly, providing a strong basis for subsequent repair and optimization, and preventing the problem from recurring.

[0219] Fourth, it enables continuous optimization. Response feedback and model optimization based on root cause analysis results allow the detection method to continuously adapt to software changes, thereby improving detection capabilities and effectiveness, ensuring long-term stable software operation, and enhancing system reliability and availability.

[0220] Example 4

[0221] The present invention also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the software behavior anomaly detection method as described above.

[0222] The beneficial effects of implementing this embodiment are:

[0223] Firstly, it can accurately locate problems: by clearly defining the granularity of monitored entities and behaviors, it can focus on key links, and the collected data and constructed models can accurately reflect the software's operating status, quickly locate abnormal locations, and reduce the scope and time of investigation.

[0224] Secondly, it improves detection accuracy: by defining detailed behavioral indicators and evaluation benchmarks, and combining time-series feature extraction and behavioral sequence modeling, it can comprehensively capture software behavior patterns, accurately identify anomalies that deviate from the normal baseline, and reduce false alarms and false negatives.

[0225] Third, it can assist in root cause analysis: the alarm association and root cause analysis process can deeply analyze the underlying reasons for the anomaly, providing a strong basis for subsequent repair and optimization, and preventing the problem from recurring.

[0226] Fourth, it enables continuous optimization. Response feedback and model optimization based on root cause analysis results allow the detection method to continuously adapt to software changes, thereby improving detection capabilities and effectiveness, ensuring long-term stable software operation, and enhancing system reliability and availability.

[0227] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0228] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A method for detecting software behavior anomalies, characterized in that, Includes the following steps: Identify the entities and behaviors to be monitored, define behavioral indicators, and establish evaluation benchmarks; Based on the identified monitoring entities and behavioral indicators, raw time-series data and event streams are collected from the software and infrastructure levels. The collected time-series data and event stream are preprocessed to extract time-series features and perform behavioral sequence modeling. Perform baseline modeling and anomaly detection; Based on the anomaly detection results, alarm correlation and root cause analysis are performed; Based on the results of the root cause analysis, response feedback and model optimization are performed.

2. The software behavior anomaly detection method according to claim 1, characterized in that, The steps of determining the monitoring entity and behavior granularity, defining behavior indicators, and establishing evaluation benchmarks specifically include: Determine the granularity of monitored entities and behaviors; Define behavioral indicators; Establish evaluation benchmarks.

3. The software behavior anomaly detection method according to claim 1, characterized in that, The step of collecting raw time-series data and event streams from the software and infrastructure level based on the identified monitoring entities and behavioral indicators specifically includes: Deploy data acquisition devices; Perform data stream aggregation and buffering; Define a unified format and time base for data from different sources.

4. The software behavior anomaly detection method according to claim 1, characterized in that, The steps of preprocessing the collected time-series data and event stream, extracting time-series features, and performing behavioral sequence modeling specifically include: The collected time-series data and event stream are cleaned and aligned. Extracting time series features from raw time series data; The discrete event sequence is transformed into numerical features for behavioral sequence modeling.

5. The software behavior anomaly detection method according to claim 1, characterized in that, The steps for baseline modeling and anomaly detection specifically include: Using unsupervised or supervised learning methods, learn patterns of normal behavior from historical normal data to model a baseline of normal behavior; For a new data point, quantify its deviation from the normal baseline; A threshold for abnormal scores is determined; an alarm is triggered if the score exceeds this threshold.

6. The software behavior anomaly detection method according to claim 1, characterized in that, The steps of performing alarm correlation and root cause analysis based on the anomaly detection results specifically include: Based on the anomaly detection results, alarm noise reduction and aggregation are performed; By linking alerts from different monitoring entities and metrics, the chain of failure propagation can be revealed; Root cause analysis and impact analysis were conducted.

7. The software behavior anomaly detection method according to any one of claims 1 to 6, characterized in that, The steps of response feedback and model optimization based on the results of root cause analysis specifically include: Perform predefined response actions for known, common exception types; Systematically collect the verification results of alarms; The model is periodically retrained using feedback data to adapt it to changes in software and environment.

8. A software behavior anomaly detection device, characterized in that, include: The definition module is used to determine the granularity of monitored entities and behaviors, define behavioral indicators, and establish evaluation benchmarks. The acquisition module is used to acquire raw time-series data and event streams from the software and infrastructure level based on the determined monitoring entities and behavioral indicators. The preprocessing module is used to preprocess the collected time-series data and event stream, extract time-series features, and perform behavioral sequence modeling. The detection module is used for baseline modeling and anomaly detection; The analysis module is used to perform alarm correlation and root cause analysis based on the anomaly detection results; The optimization module is used to perform response feedback and model optimization based on the results of root cause analysis.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the software behavior anomaly detection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the software behavior anomaly detection method as described in any one of claims 1 to 7.

Images