Application process monitoring method and device, equipment and medium

Abstract

The invention relates to the technical field of base frame operation and maintenance, can be applied to business system platforms of financial science and technology, medical treatment and health and the like, and discloses an application process monitoring method, device, equipment and medium, and the method comprises the following steps: starting a monitoring agent program, and collecting an application performance index of an application process based on the monitoring agent program; acquiring historical index data of the application process, inputting the historical index data into the exception prediction model, and calculating a dynamic exception threshold based on the exception prediction model; comparing the application performance index with the dynamic abnormal threshold value, if it is detected that the application performance index triggers the dynamic abnormal threshold value, obtaining a service corresponding to the application performance index, and obtaining a service priority based on the service; and executing a corresponding repair strategy according to the service priority. According to the method, the judgment accuracy is improved through the dynamic threshold value and the AI model, self-healing triggered by transient high load is avoided, the fault recovery time is remarkably shortened, and fault diffusion is avoided through predictive repair.

Description

Technical Field

[0001] This invention relates to the field of infrastructure maintenance technology, and in particular to an application process monitoring method, device, equipment and medium. Background Technology

[0002] In the fintech sector, the application of financial applications is profoundly changing the traditional financial service model, driving efficiency improvements, cost reductions, user experience optimization, and the promotion of inclusive finance through technology. These applications can be used for mobile payments, digital wallets, robo-advisors, and wealth management. When using financial applications on mobile devices such as smartphones, it is necessary to monitor the application process. Monitoring the application process is a necessary means to ensure financial information security, maintain market order, and protect investor rights.

[0003] In the healthcare field, application monitoring and repair are crucial for ensuring user data security, stable application operation, and compliance. Healthcare applications directly involve sensitive information such as users' personal health data and medical records. Attacks or malfunctions can lead to serious consequences such as data breaches, business data tampering, and compliance penalties. Therefore, when using healthcare applications on mobile devices such as smartphones, comprehensive monitoring of the application process is necessary. Application process monitoring is an essential means to ensure user data security and maintain stable application operation and compliance.

[0004] Currently, monitoring the progress of applications in the fintech and healthcare sectors can be achieved through infrastructure-level monitoring, such as Kubernetes liveness / readiness probes, which determine container liveness via HTTP requests or scripts. Alternatively, APM tools like New Relic and Datadog can be used to monitor application performance metrics (such as response time and error rate) and trigger alerts or automatic scaling. Circuit breaking and rate limiting methods, such as using tools like Hystrix and Resilience4j, can also be employed to prevent cascading failures through service degradation and traffic control.

[0005] Existing application process monitoring methods rely on HTTP probes or system-level metrics, which cannot accurately detect internal application lag; they require waiting for a timeout threshold to trigger recovery, tolerate business losses within the time window, and have high response latency. Summary of the Invention

[0006] In view of the shortcomings of the prior art, the present invention provides an application process monitoring method, apparatus, device and medium, which aims to solve the problems of existing application process monitoring methods that rely on HTTP probes or system-level indicators, cannot accurately detect internal application lag, and require waiting for a timeout threshold to trigger recovery, tolerate business loss within the time window and have high response latency.

[0007] The technical solution of the present invention is as follows: The first embodiment of the present invention provides an application process monitoring method, the method comprising: Start the monitoring agent program and collect application performance indicators of the application process based on the monitoring agent program. Obtain historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The application performance metric is compared with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The corresponding repair strategy is executed according to the business priority.

[0008] Another embodiment of the present invention provides an application process monitoring device, the device comprising: The metrics acquisition module is used to start the monitoring agent program and collect application performance metrics of the application process based on the monitoring agent program. The calculation module is used to acquire historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The comparison module is used to compare the application performance metric with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The repair module is used to execute the corresponding repair strategy according to the service priority.

[0009] Another embodiment of the present invention provides a computer device, the computer device including at least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the steps of the application process monitoring method described above.

[0010] Another embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the application process monitoring method described above.

[0011] Beneficial Effects: The application process monitoring method, apparatus, device, and medium of this invention include: starting a monitoring agent program and collecting application performance indicators of the application process based on the monitoring agent program; obtaining historical indicator data of the application process, inputting the historical indicator data into an anomaly prediction model, and calculating a dynamic anomaly threshold based on the anomaly prediction model; comparing the application performance indicators with the dynamic anomaly threshold; if the application performance indicator is detected to trigger the dynamic anomaly threshold, obtaining the service corresponding to the application performance indicator, determining the service priority based on the service; and executing a corresponding repair strategy according to the service priority. This invention improves judgment accuracy through dynamic thresholds and AI models, avoids self-healing triggered by brief periods of high load, significantly reduces fault recovery time, and prevents fault propagation through predictive repair. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of the application environment of an embodiment of the application process monitoring method of the present invention; Figure 2 This is a flowchart of a preferred embodiment of an application process monitoring method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the application process monitoring device of the present invention; Figure 4 This is a schematic diagram of a preferred embodiment of a computer device according to the present invention; Figure 5 This is another structural schematic diagram of a preferred embodiment of a computer device according to the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention is further described in detail below. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0015] The embodiments of the present invention will be described below with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0016] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Here, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0017] The method provided in this application can be applied to artificial intelligence (AI) scenarios. AI is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. In other words, artificial intelligence is a branch of computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine capable of reacting in a way similar to human intelligence. Artificial intelligence studies the design principles and implementation methods of various intelligent machines, enabling them to have the functions of perception, reasoning, and decision-making. Research in the field of artificial intelligence includes robotics, natural language processing, computer vision, decision-making and reasoning, human-computer interaction, recommendation and search, and fundamental AI theories.

[0018] The application process monitoring method provided in this invention can be applied to applications such as... Figure 1 In this application environment, the client communicates with the server via a network. The client accesses the server's network or business platform, and the server can start a monitoring agent to collect application performance indicators of the application process; obtain historical indicator data of the application process, input the historical indicator data into an anomaly prediction model, calculate a dynamic anomaly threshold based on the anomaly prediction model; compare the application performance indicators with the dynamic anomaly threshold, and if the application performance indicator triggers the dynamic anomaly threshold, obtain the business corresponding to the application performance indicator, obtain the business priority based on the business, and execute the corresponding repair strategy according to the business priority. In this invention, the accuracy of judgment is improved by using dynamic thresholds and AI models, avoiding self-healing triggered by short-term high load, significantly reducing fault recovery time, and preventing fault propagation through predictive repair. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster composed of multiple servers. The invention will be described in detail below through specific embodiments.

[0019] To address the above problems, embodiments of the present invention provide an application process monitoring method. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating a preferred embodiment of an application process monitoring method according to the present invention. Figure 2 As shown, it includes: Step S100: Start the monitoring agent program and collect application performance indicators of the application process based on the monitoring agent program.

[0020] This invention relates to the monitoring of application processes in healthcare or fintech. The monitoring agent is a software component deployed on the target system. Its core function is to collect performance metrics, operational status, and other data in real time, and then transmit the data to a central monitoring platform for analysis and display via encrypted transmission.

[0021] The monitoring agent can collect hardware metrics such as CPU utilization, memory usage, disk space, and network traffic in real time, as well as software information such as service process status and log files. It supports custom monitoring items, such as slow queries and connection counts for databases, or response time and error rates for web services. The monitoring agent can also send data to a central monitoring system via encrypted protocols (such as HTTPS and SSH tunnels) to ensure transmission security. It supports breakpoint resumption and data caching to prevent data loss due to network interruptions. The monitoring agent can also perform preliminary filtering, aggregation, or compression of collected data to reduce transmission bandwidth consumption. It executes local alarm rules, such as triggering local logging or simple notifications when CPU utilization exceeds a threshold.

[0022] In this embodiment of the invention, a monitoring agent is embedded in the application process to monitor the application's performance metrics. The application process of this invention is built using the Go language. Go (also known as Golang) is an open-source programming language designed to provide concise, efficient, and reliable software development solutions. Golang is a statically typed, compiled language with strong expressive power. Thanks to its concurrency mechanism, programs written in Go can very effectively utilize multi-core and networked computers. Its novel type system makes program structures flexible and modular. Go code compiles to machine code very quickly and has a convenient garbage collection mechanism and a powerful runtime reflection mechanism. Application performance metrics include, but are not limited to, Goroutine states, function latency distribution, resource contention signals, and dependency health.

[0023] In Go, goroutines are lightweight concurrent execution units. Their state transitions are managed by the Go scheduler, and their main states include core states and additional states. Core states include: `_Gidle`: newly allocated and uninitialized; `_Grunnable`: waiting to be executed in the run queue; `_Grunning`: executing user code; `_Gsyscall`: executing a system call; `_Gwaiting`: blocked in runtime (e.g., channel operations); `_Gdead`: exited or idle. Additional states include: `_Gmoribund_unused`: unused (reserved for debugging); `_Genqueue_unused`: unused; `_Gcopystack`: stack migration in progress; `_Gpreempted`: preempted and paused. State transitions are automatically triggered by the scheduler based on context; for example, blocking leads to `_Gwaiting`, and system calls lead to `_Gsyscall`. Function latency distribution includes, but is not limited to, the response time and latency of critical functions. Resource contention signals are the number of lock contention attempts monitored in Go. Dependency health refers to downstream service dependency metrics.

[0024] Step S100, which involves starting the monitoring agent program and collecting application performance metrics of the application process based on the monitoring agent program, includes: Step S101: Embed a monitoring agent in the application process in advance; Step S102: When the application process is detected to be starting, start the monitoring agent program; Step S103: Collect application performance indicators of the application process based on the monitoring agent program.

[0025] Metrics can be collected in real time within the application process using Go's native toolchain (such as pprof, expvar) or eBPF technology, rather than relying on external probes.

[0026] In the Go ecosystem, leveraging native toolchains (such as pprof and expvar) enables real-time in-process metric collection, allowing for lightweight monitoring of application performance, resource usage, and business status. The core components of the toolchain include pprof, expvar, and net / http. Pprof is a built-in performance analysis tool that supports real-time collection and visualization of metrics such as CPU, memory, blocking, and lock contention. It requires no additional dependencies, exposes data via an HTTP interface, and supports interactive analysis. expvar provides a standardized variable export mechanism, supporting the real-time exposure of custom metrics (such as business counters and status flags). The data format is JSON, compatible with monitoring systems such as Prometheus. net / http serves as the HTTP service carrier, hosting endpoints for both pprof and expvar.

[0027] eBPF (Extended Berkeley Packet Filter) is a revolutionary Linux kernel technology that allows user-defined sandboxed programs to run securely and efficiently without modifying the kernel source code. Originally used for network packet filtering, it has now expanded to multiple areas such as performance monitoring, security, and tracing.

[0028] Traditional Kubernetes probes can only detect process liveness, while the internally embedded monitoring agent can detect application internal logic bottlenecks (such as Goroutine deadlocks), thus breaking through the blind spots of external monitoring.

[0029] The eBPF-based data acquisition solution requires no modification to the application code, consumes less than 5% of CPU resources, and achieves lightweight and non-intrusive operation.

[0030] Step S103, which involves collecting application performance metrics of the application process based on the monitoring agent program, includes: Step S131: Collect the Goroutine status of the application process based on the monitoring agent program, and count the number of active / blocked Goroutines; Step S132: Record the P99 / P999 response time of the key function to capture long-tail latency; Step S133: Monitor the number of lock contention attempts, GC pause duration and frequency; Step S134: Track the downstream service dependency metrics.

[0031] Key metrics include, but are not limited to, Goroutine state, function delay distribution, resource contention distribution, and dependency health.

[0032] Obtaining Goroutine status involves counting the number of active / blocked Goroutines to identify deadlocks or channel blockages (e.g., Goroutines exceeding a threshold are in the chan receive state). For example, this can be achieved by collecting the number of active / blocked Goroutines per second; obtaining detailed stack information via runtime.GoroutineProfile; triggering log alerts when the chan receive state exceeds a threshold; and exposing JSON-formatted metrics via expvar.

[0033] The method for obtaining function latency distribution involves recording the P99 / P999 response times of key functions to capture long-tail latency. Zero network requests: Data is exchanged via a file interface, bypassing security restrictions; Sliding window: The most recent 1000 samples are retained, balancing memory and accuracy; Incremental reading: The Python side only reads when the file changes, reducing I / O overhead; Double-ended verification: Data updates are detected by modification time and file size; Persistent storage: Data is persisted to files, supporting recovery after restart. During deployment, Go monitoring code is integrated into the application; the Python monitoring script runs after the application starts; monitoring data is automatically written to `response_times.json`; the script analyzes in real time and triggers long-tail latency alerts.

[0034] Resource contention signals can be monitored by tracking lock contention counts (e.g., wait times for `sync.Mutex`), GC pause durations, and frequencies. Data is exchanged via file interfaces to circumvent security restrictions; real-time monitoring: Go applications update data every second, while Python analyzes it every 5 seconds; double-ended verification: data updates are detected by modifying the time; anomaly detection: alarms are triggered when lock contention exceeds 100 times / second; alarms are triggered when the average GC pause exceeds 50ms; data persistence: data is stored in JSON format for easy third-party parsing.

[0035] Dependency health can be monitored by tracking downstream service dependency metrics such as SQL connection pool utilization and RPC request queue depth. The specific implementation method is as follows: SQL connection pool monitoring. Data collection method: Obtain the connection pool status via `database / sql.DB.Stats()`. Key metrics: `InUse`: The number of connections currently in use; `MaxOpenConnections`: The maximum capacity of the connection pool; Calculation formula: Utilization rate = `InUse` / `MaxOpenConnections`.

[0036] Prerequisites for RPC queue depth monitoring: The RPC client must provide the `GetQueueDepth()` method (or similar functionality). Alternative: If the client does not support this, it can be obtained indirectly through the following methods: Example: Estimating queue depth using the number of incomplete requests. func (c *Client) GetQueueDepth() int { c.mu.Lock() defer c.mu.Unlock() return len(c.pendingRequests) / / Assuming there is a pendingRequests field } When optimizing file storage, the data format is JSON (human-readable and highly compatible); the write mode is O_TRUNC, overwriting each time (to avoid excessively large files); and exception handling is achieved by adding a file operation retry mechanism (example omitted). Threshold configuration for alert policies: can be flexibly adjusted via the alert_thresholds dictionary; multi-level alerts: high: yellow warning (e.g., SQL occupancy > 80%); critical: red critical alert (e.g., RPC queue > 50).

[0037] Step S200: Obtain historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model.

[0038] The anomaly prediction model in this embodiment of the invention is an artificial intelligence model. Historical indicator data refers to the historical performance indicator data of the application process over a predetermined period of time. Historical performance indicator data includes, but is not limited to, Goroutine growth curves. A Goroutine growth curve typically refers to the trend of the number of Goroutines in a Go program over time, and its shape is affected by program logic, resource constraints, and scheduling mechanisms. Growth curve shapes include linear growth, stepped fluctuations, and sudden increases followed by a decline. Linear growth is common in scenarios where new Goroutines are continuously created (such as HTTP servers processing requests). If the number is not promptly recycled or limited, it may lead to memory leaks or OutOfMemoryError (OOM). Stepped fluctuations refer to the number of Goroutines fluctuating within the maximum concurrency under a worker pool or rate limiting mechanism, exhibiting periodic changes. Sudden increases followed by a decline refer to a short-term surge caused by sudden tasks (such as batch processing), which is subsequently recovered through the goroutine pool or garbage collection.

[0039] Factors influencing the growth curve include code logic, resource constraints, and scheduling strategies. Code logic factors include frequent calls to `go func()` or failure to close channels, which can lead to uncontrolled growth. Resource constraints refer to the fact that when memory or the number of threads is insufficient, the Go runtime may actively terminate some Goroutines. The scheduling strategy, under the M:N scheduling model, involves idle Ps stealing Goroutines from other Ps to balance the load. Step S200, which involves acquiring historical indicator data of the application process, inputting the historical indicator data into the anomaly prediction model, and calculating the dynamic anomaly threshold based on the anomaly prediction model, includes: Step S201: Construct an initial anomaly prediction model based on an LSTM neural network; Step S202: Obtain application performance index samples corresponding to the application process, and train the initial anomaly prediction model based on the application performance index samples to generate anomaly prediction model. Step S203: Obtain historical indicator data of the application process within a preset time period, and input the historical indicator data into the anomaly prediction model; Step S204: Obtain the dynamic anomaly threshold based on the output of the anomaly prediction model.

[0040] LSTM neural networks are used to analyze historical metrics (such as the growth curve of Goroutines over the past 7 days) and dynamically calculate health thresholds (such as expected Goroutine count ± 20%). Long Short-Term Memory (LSTM) networks are a type of recurrent neural network specifically designed to address the long-term dependency problem inherent in general RNNs (Recurrent Neural Networks). All RNNs have a chain-like structure of repeating neural network modules.

[0041] For example, the pseudocode for calculating dynamic health thresholds is as follows: def dynamic_threshold_prediction(historical_metrics): # Input: Historical metrics (e.g., number of Goroutines, latency distribution) # Output: Dynamic threshold (e.g., current P99 latency tolerance) model = load_lstm_model("threshold_model") predicted_values ​​= model.predict(historical_metrics) thresholds = { "goroutine_block": predicted_values["goroutine_block"] * 1.2,# 20% fault tolerance "function_latency": predicted_values["latency_p99"] * 1.5 } return thresholds.

[0042] Lightweight implementation based on LSTM to calculate dynamic thresholds: using only NumPy and scikit-learn, no TensorFlow required; Dynamic prediction: automatically retrains the model and updates predictions every hour; Adaptive threshold: automatically calculates a ±20% healthy range based on the predicted value; Real-time monitoring: detects whether the current value exceeds the healthy range every hour; Historical data management: automatically maintains the data for the most recent 7 days using a deque.

[0043] Step S300: Compare the application performance metric with the dynamic anomaly threshold. If the application performance metric triggers the dynamic anomaly threshold, obtain the service corresponding to the application performance metric and determine the service priority based on the service.

[0044] This invention eliminates the misjudgment caused by static thresholds by using dynamic anomaly thresholds. The dynamic model can distinguish between "daily traffic peaks" and "abnormal lag," reducing the false alarm rate by 70%. A proactive defense mechanism: "Repairing before faults occur" is achieved through prediction, avoiding business losses caused by passively waiting for timeouts.

[0045] When one or more of the application performance metrics trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, the service priority is determined based on the service, and then different operations are performed according to different priorities.

[0046] Step S300 involves comparing the application performance metric with the dynamic anomaly threshold. If the application performance metric triggers the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service, including: Step S301: Pre-set service priorities and configure corresponding repair strategies based on the service priorities; Step S302: Compare the application performance indicators with the dynamic anomaly threshold; Step S303: If the application performance indicator is detected to trigger the dynamic anomaly threshold, then obtain the service corresponding to the application performance indicator, and obtain the corresponding service priority based on the service.

[0047] The testing services are as follows: def detect_anomalies(current_metrics, thresholds): anomalies = [] # Detect Goroutine blocking if current_metrics["blocked_goroutines"]>thresholds["goroutine_block"]: anomalies.append("Goroutine deadlock risk") # Detect long-tail latency if current_metrics["latency_p999"]>thresholds["function_latency"]: anomalies.append("Long-tail delay of critical functions") return anomalies.

[0048] Isolated Goroutine Cluster Identification: Locating abnormal Goroutines not associated with the main process through call stack analysis. The stack capture mechanism uses frequency control, capturing once per minute to balance performance and real-time performance; the file format is a structured storage of timestamps and stack data; pattern injection involves pre-setting detectable exception patterns in the Go code. Exception detection logic includes: regular expression matching: identifying abnormal Goroutines through predefined patterns; historical comparison: using a deque to retain the most recent 10 records for trend analysis; main process association detection: extending detection capabilities by checking for the presence of `main.main`; custom patterns: adding new detection rules by modifying the `patterns` dictionary; multi-level alerts: triggering different levels of alerts based on the number of matches; and visual analysis, which can be expanded to generate stack call relationship graphs.

[0049] Lock contention mutation detection: Compares real-time lock wait time with historical averages and triggers a surge alert (e.g., a 3-fold increase lasting 10 seconds). It collects lock wait time data in real-time; dynamically calculates historical averages (sliding window); intelligently compares real-time values ​​with historical averages; and triggers threshold alerts. This effectively identifies abnormal surges in lock wait time, helping developers discover potential lock contention issues early. In actual deployment, Redis or file storage solutions can be selected based on system scale.

[0050] Predictive repair: Execute repair strategies in advance before the metric reaches a hard threshold (e.g., predicting that a deadlock will be triggered in 30 seconds).

[0051] Step S400: Execute the corresponding repair strategy according to the service priority.

[0052] Local repair strategies include, but are not limited to, closing idle channels, resetting blocked worker pools, and dynamically adjusting GOMAXPROCS / GOGC.

[0053] Global remediation strategies include, but are not limited to, container restarts / traffic switching.

[0054] The scenario-based strategy configuration is as follows: For high-priority services (such as financial transactions): prioritize partial repairs to avoid transaction interruptions caused by restarts.

[0055] Low-priority services (such as log aggregation): Quickly restart to release resources and reduce operational complexity.

[0056] Relying on topology awareness: Combining service mesh (such as Istio) topology information, prioritize repairing core nodes that affect downstream services.

[0057] Step S400, which involves executing the corresponding repair strategy based on the service priority, includes: Step S401: Determine whether the service priority meets the preset priority conditions. If the service priority meets the preset priority conditions, then execute step S402. If the service priority does not meet the preset priority conditions, then execute step S403. Step S402: Execute the local repair strategy and obtain the repair results; if the repair fails, perform container restart or traffic switching operations. Step S403: Perform container restart or traffic switching operation.

[0058] def self_healing_strategy(anomalies, service_priority): for anomaly in anomalies: if "Goroutine deadlock" in anomaly: if service_priority == "high": force_close_idle_channels() # High-priority services will be repaired locally first else: trigger_container_restart() # Low priority restart directly elif "long-tail delay" in anomaly: dynamic_tune_gomaxprocs() # Dynamically tune CPU parameters hotfix_sql_connection_pool() # Hot-loads SQL connection pool patches.

[0059] Determine whether the service priority meets the preset priority conditions. If the service priority meets the preset priority conditions, execute the local repair strategy and obtain the repair result. When the repair fails, perform container restart or traffic switching operations. If the service priority does not meet the priority conditions, perform container restart or traffic switching operations. When restarting the container, the specific implementation is as follows: # Restart a single container using docker docker restart <container ID or name> # Restart a K8s Pod using kubectl (will trigger reconstruction) kubectl delete pod <Pod name> --namespace=<namespace> # Or restart through rolling update (without interruption) kubectl rollout restart deployment / <Deployment name> --namespace=<namespace>; When performing traffic switching, several different methods can be adopted, as follows: Blue-green deployment: The old and new version services run simultaneously, and seamless upgrade is achieved by switching traffic. Canary release: Gradually migrate traffic from the old version to the new version to reduce risks. Failover: When the primary service fails, switch traffic to the standby service. Regional load balancing: Allocate traffic based on geographical location or user characteristics.

[0060] Traffic switching tools include but are not limited to Kubernetes Service and service styles. Kubernetes Service dynamically switches the backend Pod by modifying the selector or endpoints of the Service. Use Ingress rules to route traffic based on paths, domain names, etc. Service meshes (such as Istio) configure traffic rules through VirtualService and DestinationRule to achieve refined management.

[0061] Among them, step S402, that is, if the service priority meets the preset priority conditions, execute the local repair strategy and obtain the repair result; when the repair fails, perform container restart or traffic switching operations, including: Step S421: If the service priority meets the preset priority conditions, execute the local repair strategy; Step S422: Obtain the repair result of the local repair strategy; Step S423: If the local repair strategy is successful, record the repair effectiveness of the local repair strategy; Step S424: If the local repair strategy fails, then perform a container restart or traffic switching operation.

[0062] When prioritizing local repairs, the following repair operations can be performed: Goroutine-level cleanup: forcibly close idle Channels or reset blocked Worker pools (e.g., cancel blocking operations via context timeout). Worker pool management mainly involves: using `queue.get(timeout)` to avoid permanent blocking, and notifying all workers to exit via `shutdown_event`; resource cleanup: clearing the task queue upon shutdown. The channel shutdown mechanism uses locks to protect the shutdown state and tracks the channel state using the `closed` flag; attempting to put after shutdown will throw an exception. Context timeout control methods are as follows: independent timing thread: using a daemon thread to implement timeout; resource safety: ensuring the timing thread does not leak; easy integration: automatic management via a context manager.

[0063] Dynamic parameter tuning: Real-time adjustment of GOMAXPROCS (limiting the number of CPU cores) or GOGC parameters (controlling GC frequency). File overwriting is used instead of appending to avoid configuration conflicts; version control includes a timestamp field to track update time; range verification: parameter range checks (e.g., number of CPU cores, GC percentage) are performed on the Python side. The dynamic parameter adjustment logic is as follows: GOMAXPROCS: Increased to all cores under high load; reduced to 2 cores under low load. GOGC: Reduced to 50% under high memory (increasing GC frequency); increased to 200% under low memory (reducing GC frequency); defaults to "auto" (Go's default behavior). Monitoring and update cycle methods are as follows: Python monitoring cycle: 30 seconds (balancing real-time performance and performance); Go configuration check cycle: 10 seconds (ensuring configuration takes effect promptly).

[0064] Hot-reload patching mechanism: Loads fix code (such as replacing Channel logic with deadlock risk) through a plug-in architecture without restarting the process. Hot reloading is implemented using Go's plugin packages; isolation is achieved by compiling each plugin independently as a .so file; version management uses file hashing to detect plugin changes. Deadlock repair strategy uses non-blocking channels with select + default to achieve non-blocking operations; timeout control: combines time.After to avoid permanent blocking. Context cancellation: integrates context.Context to support propagating cancellation signals. Dynamic replacement mechanism: Function pointer replacement: updates function addresses via reflection; type safety: verifies function signature consistency at runtime; contention-free replacement: uses read-write locks to ensure replacement safety.

[0065] Backup strategy coordination: If a partial repair fails, a Kubernetes rolling update or traffic switch to a backup instance group is triggered. A highly available fault recovery system is built through a three-level recovery mechanism (plugin retry → rolling update → traffic switch), which, combined with the native capabilities of Kubernetes, achieves: seamless repair: prioritizing partial hot repair; automated recovery: automatically triggering cluster-level recovery after failure; traffic control: ensuring service continuity while completing version upgrades.

[0066] This invention can minimize business interruptions. Partial repairs ensure the availability of core functions (e.g., payment services remain operational, only non-critical functions are downgraded).

[0067] Resource utilization optimization. By tuning parameters, redundant GC pressure is reduced, resulting in a 20%-30% decrease in memory usage.

[0068] Align business and technology: Adapt remediation strategies to business priorities to avoid secondary losses caused by a "one-size-fits-all" approach.

[0069] Compatible with complex architectures: Supports dynamic environments such as microservices and serverless, and enables automatic policy synchronization through Kubernetes Operator.

[0070] Furthermore, step S400, which involves executing the corresponding repair strategy according to the service priority, also includes: Provide feedback on the effectiveness of the repair and update the weights of the anomaly prediction model for model iteration.

[0071] def record_healing_effectiveness(repair_success): if repair_success: update_model_weights("success_strategy") # Update AI model weights else: escalate_to_human_ops()# Human intervention as a fallback.

[0072] In this embodiment of the invention, the model weights are updated when the model repair is successful. If the repair fails, a manual fallback operation is performed.

[0073] Compared with the prior art, the embodiments of the present invention have the following technical advantages: Significantly reduces fault recovery time (MTTR): from minutes to seconds, preventing fault propagation through predictive repair.

[0074] Reduce false positives on healthy instances: Dynamic thresholds and AI models improve judgment accuracy and prevent self-healing from being triggered by brief periods of high load.

[0075] Enhance system resilience: The local repair mechanism ensures the availability of core functions, and basic services can still be maintained even if some modules malfunction.

[0076] Compatible with complex architectures: Adaptable to microservices, serverless and other scenarios, and supports automated deployment by Kubernetes Operator.

[0077] Resource optimization: Reduce redundant resource consumption (such as reducing GC pressure) through Goroutine-level cleanup and parameter tuning.

[0078] It should be noted that there is no necessary order between the above steps. Those skilled in the art will understand from the description of the embodiments of the present invention that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in turn, etc.

[0079] Another embodiment of the present invention provides an application process monitoring device, which corresponds one-to-one with the application process monitoring method described in the above embodiments. For example... Figure 3 As shown, device 1 includes: The indicator acquisition module 100 is used to start the monitoring agent program and collect the application performance indicators of the application process based on the monitoring agent program. The calculation module 200 is used to acquire historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The comparison module 300 is used to compare the application performance indicator with the dynamic anomaly threshold. If the application performance indicator is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance indicator is obtained, and the service priority is determined based on the service. The repair module 400 is used to execute the corresponding repair strategy according to the service priority.

[0080] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0081] In one embodiment, the indicator acquisition module 100 is specifically used for: Pre-embed monitoring agents in the application process; When the application process is detected to be starting, the monitoring agent program is started; The monitoring agent collects application performance metrics of the application process.

[0082] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0083] In one embodiment, the computing module 200 is specifically used for: Construct an initial anomaly prediction model based on an LSTM neural network; Obtain application performance index samples corresponding to the application process, and train the initial anomaly prediction model based on the application performance index samples to generate anomaly prediction model. Obtain historical indicator data of the application process within a preset time period, and input the historical indicator data into the anomaly prediction model; Based on the output of the anomaly prediction model, the dynamic anomaly threshold is obtained.

[0084] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0085] In one embodiment, the comparison module 300 is specifically used for: Pre-set service priorities and configure corresponding repair strategies based on the service priorities; Compare the application performance metrics with the dynamic anomaly threshold; If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the corresponding service priority is obtained based on the service.

[0086] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0087] In one embodiment, the repair module 400 is specifically used for: Determine whether the service priority meets the preset priority conditions; If the service priority meets the preset priority conditions, a partial repair strategy is executed and the repair result is obtained; if the repair fails, a container restart or traffic switching operation is executed. If the service priority does not meet the preset priority conditions, then a container restart or traffic switching operation will be performed.

[0088] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0089] In one embodiment, the repair module 400 is further configured to: If the service priority meets the preset priority conditions, then a local repair strategy is executed; Obtain the repair results of the local repair strategy; If the local repair strategy is successful, the effectiveness of the local repair strategy is recorded. If the local repair strategy fails, then a container restart or traffic switching operation will be performed.

[0090] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0091] In one embodiment, the indicator acquisition module 100 is further configured to: Based on the monitoring agent program, the Goroutine status of the application process is collected, and the number of active / blocked Goroutines is counted. Record the P99 / P999 response time of key functions to capture long-tail latency; Monitor the number of lock contention attempts, GC pause duration and frequency; Track downstream service dependency metrics.

[0092] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0093] This invention provides an application process monitoring device that improves judgment accuracy through dynamic thresholds and AI models, avoids self-healing triggered by short-term high load, significantly reduces fault recovery time, and prevents fault spread through predictive repair.

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

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

[0096] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Start the monitoring agent program and collect application performance indicators of the application process based on the monitoring agent program. Obtain historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The application performance metric is compared with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The corresponding repair strategy is executed according to the business priority.

[0097] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Start the monitoring agent program and collect application performance indicators of the application process based on the monitoring agent program. Obtain historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The application performance metric is compared with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The corresponding repair strategy is executed according to the business priority.

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

[0099] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0100] The embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0101] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general-purpose hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can exist in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0102] It should be noted that if any software tools or components not belonging to our company appear in the embodiments of this application, they are merely for illustrative purposes and do not represent actual use.

[0103] Among other things, conditional language such as “can,” “may,” “may,” or “may,” unless otherwise specifically stated or otherwise understood as in the context in which they are used, is generally intended to convey that a particular implementation may include (but not others) certain features, elements, and / or operations. Therefore, such conditional language is also generally intended to imply that features, elements, and / or operations are necessary for one or more implementations in any way, or that one or more implementations must include logic for determining, with or without input or prompting, whether such features, elements, and / or operations are included or will be performed in any particular implementation.

[0104] The contents already described herein in this specification and accompanying drawings include examples of methods and apparatuses capable of providing application process monitoring. It is, of course, impossible to describe every conceivable combination of elements and / or methods for the purpose of describing the various features of this disclosure, but it will be appreciated that many other combinations and substitutions of the disclosed features are possible. Therefore, it will be apparent that various modifications can be made to this disclosure without departing from the scope or spirit of this disclosure. Furthermore, or in alternatives, other embodiments of this disclosure may become apparent from consideration of this specification and accompanying drawings and from practice of this disclosure as presented herein. It is intended that the examples presented in this specification and accompanying drawings be considered illustrative rather than restrictive in all respects. Although specific terminology is used herein, it is used in a general and descriptive sense and is not intended for limiting purposes.

Claims

1. An application process monitoring method, characterized in that... The method includes: Start the monitoring agent program and collect application performance indicators of the application process based on the monitoring agent program. Obtain historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The application performance metric is compared with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The corresponding repair strategy is executed according to the business priority.

2. The application process monitoring method according to claim 1, characterized in that, The process of launching the monitoring agent program and collecting application performance metrics of the application process based on the monitoring agent program includes: Pre-embed monitoring agents in the application process; When the application process is detected to be starting, the monitoring agent program is started; The monitoring agent collects application performance metrics of the application process.

3. The application process monitoring method according to claim 1, characterized in that, The step of acquiring historical indicator data of the application process, inputting the historical indicator data into the anomaly prediction model, and calculating the dynamic anomaly threshold based on the anomaly prediction model includes: Construct an initial anomaly prediction model based on an LSTM neural network; Obtain application performance index samples corresponding to the application process, and train the initial anomaly prediction model based on the application performance index samples to generate anomaly prediction model. Obtain historical indicator data of the application process within a preset time period, and input the historical indicator data into the anomaly prediction model; Based on the output of the anomaly prediction model, the dynamic anomaly threshold is obtained.

4. The application process monitoring method according to claim 1, characterized in that, The step of comparing the application performance metric with the dynamic anomaly threshold, and if the application performance metric is detected to trigger the dynamic anomaly threshold, then obtaining the service corresponding to the application performance metric and determining the service priority based on the service, includes: Pre-set service priorities and configure corresponding repair strategies based on the service priorities; Compare the application performance metrics with the dynamic anomaly threshold; If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the corresponding service priority is obtained based on the service.

5. The application process monitoring method according to claim 4, characterized in that, The step of executing the corresponding repair strategy according to the service priority includes: Determine whether the service priority meets the preset priority conditions; If the service priority meets the preset priority conditions, a partial repair strategy is executed and the repair result is obtained; if the repair fails, a container restart or traffic switching operation is executed. If the service priority does not meet the preset priority conditions, then a container restart or traffic switching operation will be performed.

6. The application process monitoring method according to claim 5, characterized in that, If the service priority meets the preset priority condition, then a local repair strategy is executed and the repair result is obtained; If the repair fails, perform a container restart or traffic switching operation, including: If the service priority meets the preset priority conditions, then a local repair strategy is executed; Obtain the repair results of the local repair strategy; If the local repair strategy is successful, the effectiveness of the local repair strategy is recorded. If the local repair strategy fails, then a container restart or traffic switching operation will be performed.

7. The application process monitoring method according to claim 2, characterized in that, The application performance metrics collected based on the monitoring agent program for the application process include: Based on the monitoring agent program, the Goroutine status of the application process is collected, and the number of active / blocked Goroutines is counted. Record the P99 / P999 response time of key functions to capture long-tail latency; Monitor the number of lock contention attempts, GC pause duration and frequency; Track downstream service dependency metrics.

8. An application process monitoring device, characterized in that, The device includes: The metrics acquisition module is used to start the monitoring agent program and collect application performance metrics of the application process based on the monitoring agent program. The calculation module is used to acquire historical indicator data of the application process, input the historical indicator data into the anomaly prediction model, and calculate the dynamic anomaly threshold based on the anomaly prediction model. The comparison module is used to compare the application performance metric with the dynamic anomaly threshold. If the application performance metric is detected to trigger the dynamic anomaly threshold, the service corresponding to the application performance metric is obtained, and the service priority is determined based on the service. The repair module is used to execute the corresponding repair strategy according to the service priority.

9. A computer device, characterized in that, The computer device includes at least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the steps of the application process monitoring method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the application process monitoring method according to any one of claims 1-7.

Images