A system health inspection method and device based on combination of software and hardware

Abstract

The application discloses a system health inspection method and device based on combination of software and hardware, and the method comprises the following steps: periodically detecting a plurality of function nodes of a target system, acquiring and determining a software health score of the function nodes according to a total number of detections, a number of successful responses and an average response time of the function nodes in a target statistical period; collecting and determining a hardware health score of a plurality of hardware devices of the target system according to a utilization rate of the hardware devices in the target statistical period; and determining a target health score of the target system according to the software health scores of the plurality of function nodes and the hardware health scores of the plurality of hardware devices, so that an efficient and highly reliable system health monitoring scheme is realized.

Description

Technical Field

[0001] This application relates to the field of system monitoring technology, and in particular to a system health inspection method and device based on a combination of software and hardware. Background Technology

[0002] With the rapid development of information technology, the depth and breadth of IT information systems in enterprise production and operation have continued to increase. From core business transactions to daily office collaboration, the entire process of enterprise operation is highly dependent on the support of various information systems. Therefore, the continuous and stable operation of the system is directly related to the business continuity and the availability of external services of the enterprise. Once an operational anomaly or service interruption occurs, it will bring direct or indirect economic losses to the enterprise.

[0003] To ensure the continuous and stable operation of the system, the industry generally adopts manual inspection to periodically check the health status of the system: maintenance personnel need to manually check the operating status, resource usage, and functional availability of each system according to the preset inspection checklist, record relevant parameters and compile inspection reports, and manually trigger alarms when abnormal parameters are found.

[0004] However, the manual inspection mode has obvious limitations: on the one hand, the frequency of manual inspections is limited by the cost of maintenance manpower, and can usually only be carried out periodically on a daily or weekly basis. It cannot achieve high-frequency continuous monitoring, and it is difficult to provide early warning of potential abnormal risks. Many problems have already caused service failures by the time they are discovered, which increases the difficulty of fault handling. On the other hand, the process of manually recording, verifying and analyzing inspection data is generally inefficient and prone to omissions and misjudgments due to human negligence. It cannot guarantee the accuracy and consistency of inspection results, which further increases the risk of hidden system failures. Ultimately, this reduces the reliability of system operation and affects the user experience of end users.

[0005] In summary, the manual inspection model is no longer suitable for the current operational and maintenance needs of enterprises for highly available IT systems. There is an urgent need in this field for an automated system inspection solution to solve the efficiency and reliability problems of the existing model. Summary of the Invention

[0006] This application provides a system health inspection method and device based on a combination of software and hardware, which solves the problems of low efficiency and poor reliability of related system health monitoring schemes.

[0007] Firstly, this application provides a system health inspection method based on a combination of software and hardware, the method comprising: For multiple functional nodes of the target system, periodic probes are performed on each functional node to obtain the total number of probes, the number of successful responses, and the average response time within the target statistical period. Based on the total number of probes, the number of successful responses, and the average response time, the software health score of the functional node is determined. For multiple hardware devices in the target system, the usage rate of each hardware device is collected within the target statistical period; based on the usage rate and the preset correspondence between different usage rate ranges and scores, the hardware health score of the hardware device is determined. The target health score of the target system is determined based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

[0008] The above technical solution has the following advantages or beneficial effects: This application replaces the traditional process of manual point-to-point verification and data recording with a mechanism that automatically and periodically probes functional nodes and automatically collects usage data from hardware devices. This improves the efficiency of system health checks and avoids the labor cost constraints of manual checks, eliminating the need for maintenance personnel's time and effort. The software health score is calculated using three objectively quantifiable indicators: the number of probes, the number of successful responses, and the average response time. The hardware health score is automatically generated by matching preset usage rates with scoring rules. The entire scoring process is based on objective data, avoiding subjective oversights from manual judgment and improving the reliability of system health checks.

[0009] Secondly, this application provides a system health inspection device based on a combination of software and hardware, the device comprising: The software health score determination module is used to periodically probe multiple functional nodes of a target system, obtain the total number of probes, the number of successful responses, and the average response time of the functional node within the target statistical period, and determine the software health score of the functional node based on the total number of probes, the number of successful responses, and the average response time. The hardware health score determination module is used to collect the usage rate of a hardware device within the target statistical period for multiple hardware devices of the target system; and determine the hardware health score of the hardware device based on the usage rate and the preset correspondence between different usage rate ranges and scores. The target health score determination module is used to determine the target health score of the target system based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

[0010] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, used to execute a program stored in memory, implements the method described.

[0011] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0012] Fifthly, this application provides a computer program product comprising an executable program that is executed by a processor to implement the method described. Attached Figure Description

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

[0014] Figure 1 A schematic diagram of the first system health inspection process based on hardware and software integration provided for this application; Figure 2 A schematic diagram illustrating the process of determining the software health score of functional nodes provided in this application; Figure 3 A schematic diagram illustrating the process of target health scoring in the first target determination system provided in this application; Figure 4 A schematic diagram illustrating the process of target health scoring for the second target determination system provided in this application; Figure 5 A schematic diagram of a second type of system health inspection process based on hardware and software integration provided for this application; Figure 6 The system health inspection architecture diagram based on the combination of software and hardware provided for this application; Figure 7 A schematic diagram illustrating the transmission of RPA inspection data to a web application as provided in this application; Figure 8 The Grafana screenshot shows the effect of the client parameters provided in this application; Figure 9 A schematic diagram of the system health inspection device based on the combination of software and hardware provided in this application; Figure 10A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0015] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0016] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0017] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0018] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0019] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0020] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0021] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0022] Zabbix is ​​an open-source, mature enterprise-grade IT monitoring solution. Its core function is real-time monitoring of the performance and availability of servers, network devices, applications, and cloud services. It automatically collects massive amounts of metrics through various methods such as Agent, SNMP, and IPMI, and supports user-defined monitoring items. Zabbix provides a robust alerting mechanism, supporting multi-channel notifications based on flexible triggers to ensure timely response from operations teams to anomalies. Its built-in data visualization and dashboard features help users intuitively analyze performance trends and bottlenecks. The platform boasts high scalability and stability, making it a reliable choice for building centralized operations and maintenance monitoring systems. This application primarily utilizes Zabbix tools to obtain data such as memory and disk usage.

[0023] Robotic Process Automation (RPA) is a technology that uses software robots to automatically perform repetitive and routine digital tasks. It can simulate human user operations, such as logging into a system, reading and writing data, processing reports, and sending and receiving emails, automatically executing predetermined processes across applications. RPA operates non-intrusively at the presentation layer, allowing for rapid deployment without modifying existing IT systems. It significantly improves the efficiency and accuracy of business processes, reduces labor costs, and is an important tool for driving enterprise digital transformation and intelligent operations. It is widely used in business scenarios such as finance, human resources, supply chain, and customer service. This application primarily utilizes RPA technology to obtain software webpage login information data.

[0024] To improve the comprehensiveness of system performance evaluation, this application proposes a "multi-dimensional software and hardware evaluation method." This method utilizes system-wide functional path inspection data and hardware-level parameters to calculate scores for each software function and hardware module. Then, a "hybrid software and hardware weighting method" is used to calculate the overall system health score. This method, combining software and hardware approaches, provides a reliable method for comprehensive system health evaluation. Finally, based on the health score hierarchy, the system will issue warnings via telephone, email, and other means according to a "tiered early warning mechanism."

[0025] The following describes the steps for obtaining hardware and software inspection parameters.

[0026] First, RPA can automatically perform routine tasks such as data entry, form filling, and email processing through a user interface. It can simulate various user operations in a graphical interface, such as clicking buttons, filling in fields, and copying and pasting data, thereby achieving efficient and accurate automated processing. Furthermore, RPA has the ability to handle complex business process logic, performing conditional judgments, loop operations, and exception handling based on preset rules, demonstrating high business adaptability and flexibility. It can be widely applied to automation scenarios ranging from simple repetitive tasks to multi-step complex processes. This application leverages the automatic operation capabilities of RPA web page images to obtain system and functional module availability and response time information through single-point operations. Second, Zabbix, through a server-client architecture, allows the server to collect application server hardware information in real time and obtain key data such as CPU utilization using configured monitoring templates.

[0027] In addition, the obtained software and hardware parameters are displayed in this application through Grafana and a front-end interface based on the Spring Boot-Vue architecture.

[0028] Grafana is a popular open-source data visualization and monitoring analytics platform. It supports various data sources (such as Prometheus, MySQL, Zabbix, and Elasticsearch) and can transform complex time-series data into intuitive dashboards and charts. Users can configure flexible dashboards to monitor system status in real time, analyze performance trends, and set alerts. Grafana emphasizes ease of use and powerful visualization capabilities, and is widely used in operations, IoT, and business data analysis to help users efficiently understand and utilize data.

[0029] A front-end / back-end separation architecture based on Spring Boot is a mainstream enterprise application development model. The back-end uses Spring Boot to build a RESTful API, providing data interfaces and business logic processing, and is responsible for data persistence, security authentication, and transaction management. The front-end, on the other hand, uses frameworks such as Vue and React to develop independent projects, focusing on user interface and interactive experience. The front-end and back-end interact with JSON data via HTTP protocol, achieving separation of concerns and improving development efficiency and system maintainability. This architecture supports distributed deployment and has good scalability and flexibility. This application transmits application parameters obtained from RPA to the Spring Boot application system for data processing and display via API.

[0030] The main purpose of this application's multi-dimensional intelligent evaluation of software and hardware is to scientifically and reasonably assess the system by monitoring front-end functions and server hardware, utilizing a "software and hardware hybrid weighting method" and "tiered intelligent early warning," and referencing inspection data. The system inspection test mainly covers the following five aspects: (1) Comprehensive evaluation of hardware and software performance: The performance of the system under high load conditions is evaluated by simulating key indicators such as response time, processing capacity and throughput of the user behavior detection system. (2) End-to-end business process verification: RPA simulates the complete operation of users logging into the system, submitting forms, querying data, generating reports, etc., to verify whether the business functions are smooth; (3) Stability testing: Through long-term continuous operation and repeated operation, identify whether the system has potential stability problems such as memory leaks and crashes; (4) Compatibility check: Verify the system's adaptability and operational stability under different operating systems, browser versions, and network environments; (5) Operation and maintenance diagnosis: Input RPA and Zabbix inspection data into the AI ​​model and return the results in the warning log to provide the technical team with accurate repair basis.

[0031] By using the "multi-dimensional evaluation method of software and hardware", enterprises can identify and resolve potential problems in advance, thereby improving system reliability and user experience.

[0032] Figure 1 The first hardware and software-based system health inspection process provided in this application includes the following steps: S101: For multiple functional nodes of the target system, periodically probe the functional node to obtain the total number of probes, the number of successful responses, and the average response time of the functional node within the target statistical period; determine the software health score of the functional node based on the total number of probes, the number of successful responses, and the average response time. S102: For multiple hardware devices of the target system, collect the usage rate of the hardware device within the target statistical period; based on the usage rate and the preset correspondence between different usage rate ranges and scores, determine the hardware health score of the hardware device. S103: Determine the target health score of the target system based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

[0033] The system health inspection method based on the combination of software and hardware provided in this application is applied to electronic devices, such as PCs, computers, smart terminals, servers, etc.

[0034] This application first identifies multiple functional nodes in the target system, including, for example, a front-end gateway interface, user center service, order center service, payment center service, product retrieval service, and log reporting service. An automated probing unit is deployed on an independent probing cluster of electronic devices, and periodic probing is performed on each functional node based on this automated probing unit. Optionally, the probing frequency for each functional node is configured to be once per minute or every few minutes, with a probing period of, for example, 30 minutes or 1 hour. For each functional node, within each probing period, the automated probing unit calculates the total number of probing attempts initiated by that functional node, the number of successful responses that returned the expected response, and the average response time from initiation to receipt of the response for all successful probing requests.

[0035] For three statistical data points of a single node, a software health score is output based on pre-configured scoring rules. These pre-configured scoring rules can be pre-defined mappings between different triplet arrays (total number of probes, number of successful responses, and average response time) and the software health score. Based on the total number of probes, number of successful responses, and average response time of the functional node within the target statistical period, the software health score of the functional node is determined by matching these mappings.

[0036] For multiple hardware devices in the target system, including CPU, hard disk, and memory, a non-intrusive usage data acquisition unit is deployed on each hardware device to collect the usage rate of each hardware device within the target statistical period. Specifically, the CPU usage rate, memory usage rate, and disk usage rate are collected within the target statistical period.

[0037] For each hardware device, a pre-defined correspondence between different usage ranges and ratings is established. This correspondence can be the same or different for different hardware devices. Optionally, the correspondence between different usage ranges and ratings can be such that the larger the value within a usage range, the lower the corresponding rating.

[0038] Taking CPU utilization as an example, the correspondence between different utilization ranges and scores is shown in Table 1 below.

[0039] Table 1. Correspondence between usage range and rating

[0040] Optionally, for each hardware device, the average value of the usage rate data collected within the target statistical period is calculated, and then the corresponding usage rate range and score are matched to obtain the hardware health score of the hardware device.

[0041] Finally, the target health score of the target system is determined based on the software health scores of multiple functional nodes and the hardware health scores of multiple hardware devices. Optionally, weight values ​​for each hardware device and each functional node are pre-configured, with the sum of the weight values ​​for each hardware device and each functional node being 1. The target health score of the target system is determined by weighted summation based on the software health scores of multiple functional nodes, the hardware health scores of multiple hardware devices, and the weight values ​​for each hardware device and each functional node.

[0042] Alternatively, the final target health score, the software health scores of each functional node, and the hardware health scores of each hardware device can all be pushed to the operation and maintenance dashboard to display the health status of the target system. At the same time, an inspection report can be automatically generated and archived, eliminating the need for manual processing and output of results.

[0043] This application replaces the traditional process of manual point-to-point verification and data recording with a mechanism that automatically and periodically probes functional nodes and automatically collects usage data from hardware devices. This improves the efficiency of system health checks and avoids the labor cost constraints of manual checks, eliminating the need for maintenance personnel's time and effort. The software health score is calculated using three objectively quantifiable indicators: the number of probes, the number of successful responses, and the average response time. The hardware health score is automatically generated by matching preset usage rates with scoring rules. The entire scoring process is based on objective data, avoiding subjective oversights from manual judgment and improving the reliability of system health checks.

[0044] Figure 2 The schematic diagram illustrating the process of determining the software health score of a functional node provided in this application shows that, based on the total number of probes, the number of successful responses, and the average response time, determining the software health score of the functional node includes the following steps: S201: Determine the availability score of the functional node based on the number of successful responses and the total number of probes; S202: Determine the performance score of the functional node based on the average response time, the preset performance threshold, and the preset unacceptable threshold; S203: Determine the software health score of the functional node based on its availability score and performance score.

[0045] The availability score of the functional node is determined based on the number of successful responses and the total number of probes, including: Determine the ratio of the number of successful responses to the total number of probes, and determine the availability score of the functional node based on the ratio.

[0046] Optionally, for each functional node, after obtaining the total number of probes and the number of successful responses for that functional node within the target statistical period, the ratio of the number of successful responses to the total number of probes is calculated, and this ratio is multiplied by 100 to obtain the availability score for that functional node. For example, if a functional node has a total of 100 probes and 96 successful responses within the target statistical period, then the availability score for that functional node is determined to be (96 ÷ 100) × 100 = 96 points.

[0047] The performance score of this functional node is determined based on the average response time, a preset performance threshold, and a preset unacceptable threshold, including: Substitute the average response time, the preset performance threshold, and the preset unacceptable threshold into the formula: x=max(0,min(100,(x_max - x_ave) / (x_max - x_tar)) 100); Determine the performance score of this functional node; In the formula, x is the performance score of the functional node, x_max is the preset unacceptable threshold, x_tar is the preset performance threshold, and x_ave is the average response time.

[0048] Examples are given below: The performance threshold x_tar=200ms means that the business side considers a response speed of less than 200ms to be a high performance experience, and the performance score is 100.

[0049] The unacceptable threshold x_max = 2000ms means that a response time exceeding 2000ms is unacceptable to users, and the performance score is 0.

[0050] For example, to obtain the average response time of a certain functional node within the target statistical period as 750ms, we can substitute it into the formula: x=max(0,min(100,(x_max - x_ave) / (x_max - x_tar)). 100))= max(0,min(100,(2000ms –750ms) / (2000ms – 200ms) 100)) = 69 points.

[0051] In this application, determining the software health score of a functional node based on its availability score and performance score includes: Determine the product of the availability score and performance score of the functional node, and determine the software health score of the functional node based on the product.

[0052] For each functional node, after determining its availability score and performance score, calculate the product of their scores. This product can be directly used as the software health score for that functional node. Alternatively, the product can be normalized to obtain the final software health score.

[0053] In this application, the availability score characterizes whether the service is accessible, and the performance score characterizes how fast the access is. This application combines these two independent failure dimensions to obtain the final software health score, thus improving the accuracy of the determined software health score.

[0054] This application addresses the problem that manually pre-configured fixed weights rely entirely on operational experience and cannot dynamically adapt to changes in system importance during different business periods. This application proposes a technical solution to dynamically determine the weight values ​​of multiple functional nodes and multiple hardware devices, thereby subsequently determining the target system's health score. Specifically, this includes the following two solutions. Figure 3 This is the first technical solution for determining the target health score of a target system. Figure 4 This is the second technical solution for determining the target health score of the target system. The two technical solutions are explained in detail below: Figure 3 This application provides a schematic diagram of a first method for determining the target health score of a target system. The determination of the target health score of the target system based on the software health scores of the plurality of functional nodes and the hardware health scores of the plurality of hardware devices includes: S301: Determine the software health score of each of the multiple functional nodes and the hardware health score of each of the multiple hardware devices within multiple statistical periods, including the target statistical period. S302: Standardize the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices within the multiple statistical periods to obtain multiple standardized scores within the multiple statistical periods. S303: Based on the multiple standardized scores within the multiple statistical periods, determine the information entropy of each of the multiple functional nodes and the multiple hardware devices within the target statistical period; based on the information entropy of each of the multiple functional nodes and the multiple hardware devices, determine the first weight value of each of the multiple functional nodes and the multiple hardware devices. S304: Determine the target health score of the target system based on the first weight values ​​of the plurality of functional nodes and the plurality of hardware devices, the software health scores of the plurality of functional nodes, and the hardware health scores of the plurality of hardware devices.

[0055] The following section uses historical data generated over the past 7 days at an hourly granularity as a basic dataset to illustrate the process of determining the target health score for the target system.

[0056] First, the data collection scope was defined. Using the current target statistical period as the endpoint, all hourly statistical data from the previous 7 days were retrieved, resulting in a total of 168 continuous statistical periods, covering the operational status of all scenarios, including weekdays, weekends, and pre-sale periods for major promotions. Software health scores for each functional node and hardware health scores for each hardware device were then fully retrieved within these 168 periods.

[0057] The Min-Max normalization algorithm is used to standardize the software health scores of each functional node and the hardware health scores of each hardware device within 168 cycles, and to uniformly map the original health scores to the 0~1 range, eliminating the differences in the magnitude of the original scores of different functional nodes and different hardware devices.

[0058] Optionally, construct the original matrix X = (x...) for m indicators (including software health scores of all functional nodes and hardware health scores of hardware devices) over n evaluation periods. ij ) n×m , where x ij Let be the health score of the j-th indicator in the i-th period. Since both hardware and software health scores are positive indicators (the higher the score, the better), they are standardized using the following formula to eliminate the influence of dimensions.

[0059] ; Where y ij This is the standardized value, ranging from 0 to 1.

[0060] Based on multiple standardized scores over multiple statistical periods, the information entropy of multiple functional nodes and multiple hardware devices within the target statistical period is determined.

[0061] For the j-th indicator, first calculate the proportion p of the i-th sample under that indicator. ij : ; Based on the definition of information entropy, calculate the information entropy e of the j-th index. j : ; The core property of information entropy is: the greater the dispersion of the health score of the indicator, the higher the information entropy e. j The smaller the value, the greater the amount of effective information provided by the indicator; conversely, if all health scores are similar, the information entropy e is low. j The closer it is to 1, the less information the indicator contains.

[0062] According to information entropy e jCalculate the entropy redundancy (information difference coefficient) of the j-th indicator g. j : ; Entropy redundancy g j Entropy redundancy g directly reflects the amount of information contained in the indicator. j The larger the value, the more important the indicator is, and the higher its corresponding weight.

[0063] Finally, the dynamic weight (first weight value) w of the j-th indicator. j for: .

[0064] Finally, based on the first weight values ​​of multiple functional nodes and multiple hardware devices, the software health scores of multiple functional nodes, and the hardware health scores of multiple hardware devices, the target health score of the target system is determined by weighted calculation.

[0065] This application eliminates the reliance on manual experience to configure weights. The system can automatically and dynamically adjust the weights in real time according to the node operation characteristics at different times. Based on the dynamic weights, the target health score of the target system can be calculated, which can improve the accuracy and reliability of the determined target health score.

[0066] Figure 4 This application provides a second schematic diagram of the process for determining the target health score of a target system. The determination of the target health score of the target system based on the software health scores of the plurality of functional nodes and the hardware health scores of the plurality of hardware devices includes: S401: Input the software health scores of the plurality of functional nodes and the hardware health scores of the plurality of hardware devices into the dynamic weight prediction model, and output the second weight values ​​of the plurality of functional nodes and the plurality of hardware devices based on the dynamic weight prediction model; wherein, the dynamic weight prediction model is trained based on the health scores of the plurality of functional nodes and the plurality of hardware devices and the weight labels of the plurality of functional nodes and the plurality of hardware devices within a historical statistical period. S402: Determine the target health score of the target system based on the second weight values ​​of the plurality of functional nodes and the plurality of hardware devices, the software health score of the plurality of functional nodes, and the hardware health score of the plurality of hardware devices.

[0067] In this application, a training dataset is pre-constructed, for example, by pulling historical data from the past 6 months. This dataset is accompanied by health scores and weight labels for multiple functional nodes and hardware devices corresponding to real fault events. The health scores and weight labels for these functional nodes and hardware devices within the historical statistical period are input into the dynamic weight prediction model to be trained. Based on this model, predicted weights for each functional node and hardware device are output. The loss value of the dynamic weight prediction model is calculated based on the predicted weights and weight labels for each functional node and hardware device. The model is then iteratively trained using this loss value until the loss value meets the requirements, resulting in a fully trained dynamic weight prediction model.

[0068] When applying the model, the software health scores of multiple functional nodes and the hardware health scores of multiple hardware devices are input into the dynamic weight prediction model. Based on the dynamic weight prediction model, the model outputs the second weight values ​​for each functional node and hardware device. Then, based on the second weight values ​​of each functional node and hardware device, the software health scores of each functional node, and the hardware health scores of each hardware device, the target health score of the target system is determined through weighted calculation.

[0069] Figure 5 The second hardware-software integrated system health inspection process provided in this application includes the following steps: S501: For multiple functional nodes of the target system, periodically probe the functional node to obtain the total number of probes, the number of successful responses, and the average response time of the functional node within the target statistical period; determine the software health score of the functional node based on the total number of probes, the number of successful responses, and the average response time. S502: For multiple hardware devices of the target system, collect the usage rate of the hardware device within the target statistical period; based on the usage rate and the preset correspondence between different usage rate ranges and scores, determine the hardware health score of the hardware device. S503: Determine the target health score of the target system based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices. S504: Compare the target health score with a preset multi-level warning threshold; determine the warning level based on the comparison result, and output the warning information corresponding to the warning level, wherein the warning level includes at least a prompt warning, a warning level warning, and an emergency level warning; different warning levels correspond to different notification scopes, notification methods, and handling priorities.

[0070] In one optional implementation, three clearly defined thresholds are preset based on the actual impact boundaries of the business, covering the complete health score range of 0 to 100 points: Warning threshold setting: The target system health score falls within the range of 85 to 90 points. The corresponding scenario is that individual non-core nodes experience slight fluctuations that do not affect the user's core business. For example, the performance of the background log collection node may decrease by less than 10%.

[0071] Warning threshold setting: The target system health score falls within the range of 70 to 84 points. The corresponding scenario is that a single non-core business link experiences performance degradation, a small number of edge users experience request timeouts, and no large-scale business failure is triggered.

[0072] Emergency warning threshold setting: When the target system's health score is below 70, the corresponding scenario is that there is a significant anomaly in the core transaction link, some users' order placement and payment processes are blocked, and the impact of the failure is spreading rapidly.

[0073] Different warning levels are matched with specific notification scopes and channels to avoid unnecessary disruptions: Alert-level warning: The notification scope only covers members of the operation and maintenance on-duty team, the notification method is WeChat for Enterprise, and it does not push SMS or make phone calls, does not occupy high-priority notification resources, and is only used as a synchronous reminder of daily operation status.

[0074] Warning Level: The notification covers the entire operations and maintenance team and the development manager of the corresponding business line. The notification method is to send a group message to everyone and push a card to the dedicated application, with a link to the health score details of the current abnormal node, guiding the relevant person in charge to take the initiative to intervene and investigate.

[0075] Emergency alert: The notification scope covers the operations and maintenance manager, the core development team across the entire chain, and the business duty team. The notification methods combine multiple channels such as group notifications to all people, SMS, and automatic voice calls to ensure that the alarm reaches all key responsible persons in a short time and avoids missing it.

[0076] Different warning levels correspond to specific priorities for handling: Warning level: The priority for handling is P3. On-duty personnel are required to complete the problem investigation and record the optimization log within 2 hours. There is no need to interrupt the daily iteration schedule.

[0077] Warning Level: The priority for handling is P2. On-duty personnel are required to locate the root cause within 30 minutes and quickly perform routine recovery operations such as flow control and restart to prevent the fault from escalating further.

[0078] Emergency alert: The priority for handling is P0. All employees are required to immediately suspend their non-core work and directly enter the emergency response process. They should immediately perform high-priority recovery operations such as downgrading and switching resources to minimize business losses.

[0079] The system automatically generates a closed-loop tracking link for alarms. Each alarm automatically records the arrival time, responder, and handling progress. If there is no response within the time limit, the notification level is automatically escalated to ensure that all anomalies are handled in a closed loop.

[0080] Figure 6 The system health inspection architecture diagram provided in this application, based on a combination of hardware and software, shows that RPA simulates a single point of failure, logs into the target system and all functional path modules, obtains system response time, and checks whether the login and various functional data are normal. The Zabbix client collects data from the client application server to obtain hardware information. Application and hardware information data are displayed through a Vue frontend and Grafana, respectively, facilitating real-time analysis by operations and maintenance technicians.

[0081] like Figure 6 As shown, the system health inspection architecture includes RPA data crawling and inspection, Spring Boot (backend receives and processes data), Zabbix client data collection, Zabbix server data processing and display, Python script front-end and back-end data processing, calling the deepseek model and hierarchical early warning.

[0082] This application uses Python scripts to process system inspection data and calculate the overall health score. In the "multi-dimensional hardware and software evaluation method," the utilization rates of critical server hardware components—CPU, hard disk, and memory—are each assigned a 10% importance weight, denoted as a1, a2, a3. The importance weights of each functional node in the system are denoted as a4, a5, ... a n It means that: a1 + a2 + ... + a n =1.

[0083] Secondly, this application calculates the availability score s and performance score x for each functional node. The availability score is calculated by performing multiple probes through RPA simulation of user requests within a statistical period (e.g., 1 minute, 5 minutes) and calculating the success rate of probes. The performance score is calculated by setting a performance threshold x_target and an unacceptable threshold x_max. The calculation process of s and x is shown below, where s_sus represents the number of successful responses, s_tol represents the total number of probes, and x_ave represents the average probe response time: s = (s_sus / s_tol); x=max(0, min(100, (x_max - x_ave) / (x_max - x_tar) 100)); Therefore, the health score Si of this functional node is: S i =s i x i .

[0084] For hardware parameters, scores are awarded based on usage rate, with 0 points for usage exceeding 95%, 60 points for 85%–95%, 80 points for 60%–85%, and 100 points for all other usage rates. Therefore, the overall system health score is: .

[0085] Finally, based on the "tiered intelligent early warning mechanism," this application issues phone and email warnings when the score is less than 70, email warnings when the score is between 70 and 90, and no warning when the score is greater than 90. When the score is less than 90, the Python script in this paper automatically calls the Deepseek API interface, inputs RPA and Zabbix inspection data, returns large-scale model analysis results, and integrates them into the email content for maintenance personnel to refer to.

[0086] The following example illustrates the process of system health inspection based on a combination of hardware and software.

[0087] First, by pre-setting usernames and passwords in the RPA program, the robot can simulate human login to the system. Then, a comprehensive test is performed on all functional paths of the system, including data scraping and recording system response times. Data scraping can be used to verify the system's functionality and database connection, while response time analysis helps assess the design status of the system architecture.

[0088] Compared to traditional Python scripting, using RPA to crawl system functional data is simpler and more efficient. For example, when downloading high-security Excel spreadsheets that require verification, RPA programs can easily complete the security review process and can embed Python scripts for data analysis, thereby effectively verifying the accuracy of system functional data. Figure 7 This is a schematic diagram illustrating the transmission of RPA inspection data to a web application as provided in this application.

[0089] Zabbix obtains client parameters in real time and displays them through Grafana. Figure 8 The Grafana display screenshot shows the client parameters provided in this application. Finally, based on the above inspection data, the "multi-dimensional intelligent evaluation of software and hardware" method of this application is applied to calculate the overall health score of the system, and the AI ​​model is invoked to issue early warnings.

[0090] This application utilizes RPA and Zabbix technologies to crawl the response time, availability, and hardware status information of the entire system's functional path. It employs a "multi-dimensional software and hardware evaluation method," a "hybrid software and hardware weighting method," and "tiered intelligent early warning" to comprehensively and objectively generate a system health score. Furthermore, it calls upon an AI model to generate system operation and maintenance suggestions, improving system management. The comprehensive system software and hardware status data crawling solution involves acquiring system front-end application and server hardware status information through RPA and Zabbix respectively, achieving information complementarity. RPA front-end application data and Zabbix server status data are simultaneously input into the AI ​​model, and the processing results are returned, with notifications sent via email. Based on the comprehensive system evaluation score, different early warning levels are set, and appropriate early warning methods such as telephone and email are used according to the score.

[0091] Figure 9 The schematic diagram of the system health inspection device based on the combination of software and hardware provided in this application includes: The software health score determination module 11 is used to periodically probe multiple functional nodes of the target system, obtain the total number of probes, the number of successful responses, and the average response time of the functional node within the target statistical period, and determine the software health score of the functional node based on the total number of probes, the number of successful responses, and the average response time. The hardware health score determination module 12 is used to collect the usage rate of the hardware device within the target statistical period for multiple hardware devices of the target system; and determine the hardware health score of the hardware device based on the usage rate and the preset correspondence between different usage rate ranges and scores. The target health score determination module 13 is used to determine the target health score of the target system based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

[0092] The software health score determination module 11 is specifically used to determine the availability score of the functional node based on the number of successful responses and the total number of probes; to determine the performance score of the functional node based on the average response time, a preset performance threshold, and a preset unacceptable threshold; and to determine the software health score of the functional node based on its availability score and performance score.

[0093] The software health score determination module 11 is specifically used to determine the ratio of the number of successful responses to the total number of probes, and to determine the availability score of the functional node based on the ratio.

[0094] The software health score determination module 11 is specifically used to substitute the average response time, the preset performance threshold, and the preset unacceptable threshold into the formula: x=max(0, min(100, (x_max - x_ave) / (x_max - x_tar)) 100)); Determine the performance score of the functional node; where x is the performance score of the functional node, x_max is the preset unacceptable threshold, x_tar is the preset performance threshold, and x_ave is the average response time.

[0095] The software health score determination module 11 is specifically used to determine the product of the availability score and the performance score of the functional node, and to determine the software health score of the functional node based on the product.

[0096] The target health score determination module 13 is specifically used to determine the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices within multiple statistical periods, including the target statistical period; to standardize the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices within the multiple statistical periods to obtain multiple standardized scores within the multiple statistical periods; to determine the information entropy of the multiple functional nodes and the multiple hardware devices within the target statistical period based on the multiple standardized scores within the multiple statistical periods; to determine the first weight value of the multiple functional nodes and the multiple hardware devices based on the information entropy of the multiple functional nodes and the multiple hardware devices; and to determine the target health score of the target system based on the first weight value of the multiple functional nodes and the multiple hardware devices, the software health scores of the multiple functional nodes, and the hardware health scores of the multiple hardware devices.

[0097] The target health score determination module 13 is specifically used to input the software health scores of the plurality of functional nodes and the hardware health scores of the plurality of hardware devices into a dynamic weight prediction model, and output the second weight values ​​of the plurality of functional nodes and the plurality of hardware devices based on the dynamic weight prediction model; wherein, the dynamic weight prediction model is trained based on the health scores and weight labels of the plurality of functional nodes and the plurality of hardware devices within a historical statistical period; and the target health score of the target system is determined according to the second weight values ​​of the plurality of functional nodes and the plurality of hardware devices, the software health scores of the plurality of functional nodes, and the hardware health scores of the plurality of hardware devices.

[0098] The device further includes: The graded early warning module 14 is used to compare the target health score with preset multi-level early warning thresholds; determine the early warning level based on the comparison result, and output early warning information corresponding to the early warning level, wherein the early warning level includes at least a prompt level early warning, an early warning level early warning, and an emergency level early warning; different early warning levels correspond to different notification scopes, notification methods, and handling priorities.

[0099] This application also provides an electronic device, such as Figure 10 As shown, it includes: processor 21, communication interface 22, memory 23 and communication bus 24, wherein processor 21, communication interface 22 and memory 23 communicate with each other through communication bus 24; The memory 23 stores a computer program, which, when executed by the processor 21, causes the processor 21 to perform any of the above method steps.

[0100] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0101] Communication interface 22 is used for communication between the above-mentioned electronic device and other devices.

[0102] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0103] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0104] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0105] This application provides a computer program product, which includes an executable program that, when executed by a processor, implements the method described herein.

[0106] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0107] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A system health inspection method based on a combination of hardware and software, characterized in that, The method includes: For multiple functional nodes of the target system, periodic probes are performed on each functional node to obtain the total number of probes, the number of successful responses, and the average response time within the target statistical period. Based on the total number of probes, the number of successful responses, and the average response time, the software health score of the functional node is determined. For multiple hardware devices in the target system, the usage rate of each hardware device is collected within the target statistical period; based on the usage rate and the preset correspondence between different usage rate ranges and scores, the hardware health score of the hardware device is determined. The target health score of the target system is determined based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

2. The method as described in claim 1, characterized in that, Based on the total number of probes, the number of successful responses, and the average response time, the software health score of this functional node is determined, including: The availability score of the functional node is determined based on the number of successful responses and the total number of probes. The performance score of the functional node is determined based on the average response time, the preset performance threshold, and the preset unacceptable threshold. The software health score of a functional node is determined based on its availability score and performance score.

3. The method as described in claim 2, characterized in that, The availability score of this functional node is determined based on the number of successful responses and the total number of probes, including: Determine the ratio of the number of successful responses to the total number of probes, and determine the availability score of the functional node based on the ratio.

4. The method as described in claim 2, characterized in that, The performance score of this functional node is determined based on the average response time, a preset performance threshold, and a preset unacceptable threshold, including: Substitute the average response time, the preset performance threshold, and the preset unacceptable threshold into the formula: x=max(0,min(100,(x_max - x_ave) / (x_max - x_tar)) 100); Determine the performance score of this functional node; In the formula, x is the performance score of the functional node, x_max is the preset unacceptable threshold, x_tar is the preset performance threshold, and x_ave is the average response time.

5. The method as described in claim 2, characterized in that, The process of determining the software health score of a functional node based on its availability and performance scores includes: Determine the product of the availability score and performance score of the functional node, and determine the software health score of the functional node based on the product.

6. The method as described in claim 1, characterized in that, The target health score of the target system is determined based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices, including: Determine the software health score of each of the multiple functional nodes and the hardware health score of each of the multiple hardware devices within multiple statistical periods, including the target statistical period. The software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices within the multiple statistical periods are standardized to obtain multiple standardized scores within the multiple statistical periods. Based on multiple standardized scores within the multiple statistical periods, determine the information entropy of each of the multiple functional nodes and the multiple hardware devices within the target statistical period; based on the information entropy of each of the multiple functional nodes and the multiple hardware devices, determine the first weight value of each of the multiple functional nodes and the multiple hardware devices. The target health score of the target system is determined based on the first weight values ​​of the plurality of functional nodes and the plurality of hardware devices, the software health scores of the plurality of functional nodes, and the hardware health scores of the plurality of hardware devices.

7. The method as described in claim 1, characterized in that, The target health score of the target system is determined based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices, including: The software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices are input into the dynamic weight prediction model, and the second weight values ​​of the multiple functional nodes and the multiple hardware devices are output based on the dynamic weight prediction model; wherein, the dynamic weight prediction model is trained based on the health scores of the multiple functional nodes and the multiple hardware devices and the weight labels of the multiple functional nodes and the multiple hardware devices within a historical statistical period. The target health score of the target system is determined based on the second weight values ​​of the plurality of functional nodes and the plurality of hardware devices, the software health scores of the plurality of functional nodes, and the hardware health scores of the plurality of hardware devices.

8. The method as described in claim 1, characterized in that, The method further includes: The target health score is compared with a preset multi-level warning threshold; the warning level is determined based on the comparison result, and the warning information corresponding to the warning level is output. The warning level includes at least a prompt warning, a warning level warning, and an emergency level warning. Different warning levels correspond to different notification scopes, notification methods, and handling priorities.

9. A system health inspection device based on a combination of hardware and software, characterized in that, The device includes: The software health score determination module is used to periodically probe multiple functional nodes of a target system, obtain the total number of probes, the number of successful responses, and the average response time of the functional node within the target statistical period, and determine the software health score of the functional node based on the total number of probes, the number of successful responses, and the average response time. The hardware health score determination module is used to collect the usage rate of a hardware device within the target statistical period for multiple hardware devices of the target system; and determine the hardware health score of the hardware device based on the usage rate and the preset correspondence between different usage rate ranges and scores. The target health score determination module is used to determine the target health score of the target system based on the software health scores of the multiple functional nodes and the hardware health scores of the multiple hardware devices.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method according to any one of claims 1 to 8.

Images