Monitoring configuration method and system based on fingerprint recognition and large model inference

Abstract

The application discloses a monitoring configuration method and system based on fingerprint identification and large model inference, and belongs to the technical field of server monitoring and automatic operation and maintenance. The method first scans a target server to collect running environment characteristics and performs static fingerprint regular matching, identifies known services and marks unknown processes; then, deep context of the unknown processes is extracted to generate a structured prompt word inputting a large language model, semantic feature extraction and classification inference are performed to output an inferred service type and a recommended monitoring method; further, a server role image and a basic monitoring configuration are generated, and a dynamic alarm threshold and a monitoring strategy are output in combination with hardware parameters; finally, after visual inspection and confirmation through an interface, target server hot loading is issued, and unknown process features are extracted to generate new fingerprint rules which are persisted and added to a knowledge base. The application realizes intelligent identification of unknown services, automatic generation of monitoring configuration and closed-loop update of fingerprint knowledge, reduces repeated manual analysis, and improves the efficiency of large-scale server monitoring configuration.

Description

Technical Field

[0001] This invention relates to the field of server monitoring and automated operation and maintenance technology, and in particular to a monitoring configuration method and system based on fingerprint recognition and large model inference. Background Technology

[0002] In the IT operations and maintenance (O&M) field, server monitoring is a crucial means of ensuring the stable operation of information systems and business continuity. As servers increasingly host business applications, databases, middleware, and microservices, IT O&M personnel need to promptly grasp the operational status of server resources and various services in order to detect anomalies and take appropriate O&M measures. Therefore, when implementing server monitoring, it is necessary to accurately identify the server's disks, ports, processes, databases, and business services, and configure corresponding monitoring items and alarm parameters accordingly. This provides fundamental support for status monitoring, anomaly alerts, and fault handling in IT O&M.

[0003] Existing server monitoring technologies typically combine monitoring clients and monitoring servers. Monitoring agents are deployed on the target server to collect server operational information, which is then centrally managed by the monitoring server. During monitoring configuration, operations personnel usually examine environmental information such as server disk partitions, running processes, TCP listening ports, and database instances. Based on the actual software and services deployed on the server, they determine the monitoring targets and configure monitoring items such as disk usage, process liveness, TCP port connectivity, database connection status, HTTP service status, and log keywords using YAML, JSON, or other configuration files. They also configure corresponding alarm thresholds and notification methods. Some monitoring systems with automatic discovery capabilities also pre-establish service fingerprint databases, recording characteristic information such as service names, process names, default ports, log paths, and health check addresses. During environment scanning, they match the running characteristics of processes and listening ports on the server with the pre-set service fingerprints to identify the corresponding services and generate corresponding monitoring configurations based on service types and preset monitoring templates.

[0004] However, in the process of implementing the inventive technical solution in the embodiments of this application, it was found that the above-mentioned technology has at least the following technical problems:

[0005] In operational scenarios involving large-scale deployment of new servers and frequent iterations of microservices, existing technologies lack the ability to intelligently reason about the deep contextual information of unknown processes in non-standard environments such as self-developed services or customized middleware. Furthermore, the entire automatic discovery process exhibits a unidirectional characteristic. Specifically, existing technologies rely solely on static fingerprint databases for shallow matching. Once an unknown process is encountered, they often lack the ability to perform deep semantic understanding of contextual information such as process command lines and network connections, failing to automatically infer service types and monitoring requirements. Simultaneously, the scan results are only used for the current configuration generation, lacking a closed-loop feedback mechanism to feed newly discovered service characteristics back to the knowledge base. This limitation in identification capabilities and the fragmented unidirectional process mean that the same type of unknown service must still undergo the lengthy process of "static database matching failure - manual intervention analysis - manual configuration writing" on each server. Because it is impossible to use intelligent reasoning to solidify investigation experience or identification results into reusable fingerprint rules, the knowledge base cannot evolve on its own. As a result, the automatic generation of monitoring configurations can never get rid of the deep dependence on manually writing monitoring items, deriving alarm thresholds, and customizing monitoring strategies. True zero-configuration monitoring generation and large-scale intelligent operation and maintenance are difficult to achieve. Summary of the Invention

[0006] To address the technical problems of existing technologies, such as the lack of intelligent reasoning capabilities for deep context of unknown processes and the absence of a closed-loop feedback mechanism for feature-based knowledge base evolution, which prevents the knowledge base from self-evolving and necessitates lengthy manual analysis processes for similar services, and consequently makes monitoring configuration generation heavily reliant on manually written monitoring items, derived thresholds, and customized strategies, thus hindering the achievement of zero-configuration automatic monitoring and intelligent operation and maintenance in large-scale server environments, this invention provides a monitoring configuration method and system based on fingerprint recognition and large-model reasoning. The technical solution is as follows:

[0007] On the one hand, a monitoring configuration method based on fingerprint recognition and large-scale model inference is provided. This method includes: initiating an environment scanning mode on the target server to collect the target server's runtime environment characteristics, including a list of running processes, listening ports, disk partition information, and hardware configuration parameters; performing regular expression matching between the process names in the running process list and static fingerprint rules in a pre-set service fingerprint knowledge base to identify known services and marking processes that fail to match as unknown processes; extracting deep context information of unknown processes and concatenating this deep context information according to a pre-set service identification template to generate structured prompt words; inputting the structured prompt words into a pre-deployed large-scale language model, which then performs semantic feature extraction and classification inference on the deep context information to obtain the intelligent inference results for unknown processes output by the large-scale language model. These intelligent inference results include inferred service types. The system generates server role profiles representing dependencies and resource constraints between services based on known services and inferred service types. It also generates basic monitoring configurations based on runtime environment characteristics and recommended monitoring methods. Server role profiles and hardware configuration parameters are combined into threshold derivation prompts, which are input into a large language model for context-aware computation. The model outputs dynamic alarm threshold parameters and monitoring strategy description text. The basic monitoring configuration, dynamic alarm threshold parameters, and intelligent inference results are visualized and rendered on the monitoring server interface. The system receives server-side verification instructions for the intelligent inference results and, in response, sends the verified basic monitoring configuration and dynamic alarm threshold parameters to the target server for hot reloading. Fingerprint features are extracted from the runtime environment characteristics and deep context information of unknown processes, generating corresponding new fingerprint rules and persistently appending them to the service fingerprint knowledge base.

[0008] On the other hand, a monitoring and configuration system based on fingerprint recognition and large-scale model inference is provided, including: a fingerprint matching and recognition module, a large-scale model inference module, a monitoring configuration generation module, and a knowledge base feedback module. The fingerprint matching and recognition module initiates an environment scanning mode on the target server, collecting the target server's operating environment characteristics, including a list of running processes, listening ports, disk partition information, and hardware configuration parameters. It performs regular expression matching between the process names in the running process list and the static fingerprint rules in a pre-set service fingerprint knowledge base to identify known services and marks processes that fail to match as unknown processes. The large-scale model inference module extracts deep contextual information from unknown processes, concatenates this information according to a pre-set service identification template, and generates structured prompts. These structured prompts are then input into a pre-deployed large-scale language model, which performs semantic feature extraction and classification inference on the deep contextual information to obtain the intelligent inference results for unknown processes output by the large-scale language model. The intelligent reasoning results include inferred service types and recommended monitoring methods; a monitoring configuration generation module, used to generate server role profiles representing the dependencies and resource constraints between services based on known services and inferred service types; generating basic monitoring configurations based on runtime environment characteristics and recommended monitoring methods; combining server role profiles with hardware configuration parameters into threshold derivation prompts, inputting them into a large language model for context-aware calculation, and obtaining dynamic alarm threshold parameters and monitoring strategy description text output by the large language model; a knowledge base feedback module, used to visualize and render the basic monitoring configurations, dynamic alarm threshold parameters, and intelligent reasoning results on the monitoring server interface; receiving server-side review and confirmation instructions for the intelligent reasoning results, and responding to the review and confirmation instructions by sending the confirmed basic monitoring configurations and dynamic alarm threshold parameters to the target server for hot reloading; extracting fingerprint features from the runtime environment characteristics and deep context information corresponding to unknown processes, generating corresponding new fingerprint rules, and persistently appending them to the service fingerprint knowledge base.

[0009] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0010] Compared with existing technologies, this invention combines static fingerprint recognition with intelligent reasoning using a large language model. Based on the rapid identification of known services using a service fingerprint knowledge base, it further extracts deep contextual information from unknown processes that fail to match, and performs semantic feature analysis and classification reasoning to infer the service type of the unknown process and recommend monitoring methods. This overcomes the problems of existing technologies that rely solely on shallow static features such as process name and port for matching, and have insufficient ability to identify unknown services such as self-developed services and customized middleware. It also reduces the manual analysis work after static fingerprint matching failures. Simultaneously, based on the identification results, it constructs server role profiles representing service dependencies and resource constraints, and generates basic monitoring configurations, dynamic alarm threshold parameters, and monitoring strategies by combining runtime environment characteristics and hardware configuration parameters. This allows the monitoring configuration to adapt to the actual service roles and resource conditions of different servers. Compared with existing methods that use fixed monitoring templates and uniform alarm thresholds, it improves the pertinence and adaptability of monitoring configurations and alarm strategies, and reduces the need for manual writing of monitoring items and pushing... This reduces the workload of setting thresholds and customizing monitoring strategies. Furthermore, by visually reviewing the intelligent inference results and generated monitoring configurations, and then hot-loading them onto the target server after confirmation, the controllability and deployment efficiency of automatically generated configurations applied to the production environment are improved. Further, the runtime environment characteristics and deep context information corresponding to confirmed unknown processes are transformed into new fingerprint rules and persistently fed back into the service fingerprint knowledge base. This allows a single intelligent identification result to be precipitated as reusable static fingerprint knowledge, changing the existing one-way processing method where scan results only serve the current configuration and similar unknown services still require repeated manual analysis. It forms a closed-loop mechanism of static fingerprint recognition, intelligent inference for unknown services, monitoring strategy generation, review and distribution, and fingerprint rule feedback. This enables the service fingerprint knowledge base to continuously expand and iterate, thereby reducing repetitive maintenance work in scenarios involving large-scale new server deployments and frequent microservice iterations, improving the automation level of monitoring configuration generation and deployment, and providing technical support for achieving zero-configuration automatic monitoring and intelligent operation and maintenance. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating the monitoring configuration method based on fingerprint recognition and large model inference provided in this application embodiment;

[0013] Figure 2 The overall architecture diagram of the monitoring configuration method based on fingerprint recognition and large model inference provided in the embodiments of this application;

[0014] Figure 3 A detailed flowchart of the monitoring configuration method based on fingerprint recognition and large model inference provided in the embodiments of this application;

[0015] Figure 4 This is a schematic diagram of the structure of a monitoring configuration system based on fingerprint recognition and large model inference provided in an embodiment of this application. Detailed Implementation

[0016] Embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present disclosure are shown in the drawings, it should be understood that embodiments of the present disclosure may be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure.

[0017] It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure. In the description of the embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "this embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects.

[0018] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0019] With the rapid development of cloud computing, microservice architecture, and distributed applications, the number of servers and service instances in enterprise information systems continues to grow. The batch deployment of new servers, dynamic scaling of business services, and frequent iterations of microservice versions are becoming the norm. In such large-scale operational environments, to ensure the stable operation of business systems, it is typically necessary to promptly identify the types of services deployed on servers after they are put into use, and configure corresponding monitoring items, alarm thresholds, and monitoring policies based on the operational characteristics of different services. Therefore, the ability to quickly and accurately complete server service discovery and monitoring configuration directly impacts server deployment efficiency and the ability to monitor subsequent operational status.

[0020] Existing server monitoring configuration methods typically rely on pre-established service fingerprint databases or fixed monitoring templates. They identify known services on the server using static features such as process names and listening ports, and generate corresponding monitoring configurations based on preset rules. This method is efficient for services with high standardization and already included in the fingerprint database. However, with the emergence of self-developed services, customized middleware, and new versions of microservices, discrepancies easily arise between the actual server operating environment and pre-built fingerprint knowledge. When a running process cannot match existing static fingerprint rules, relying solely on shallow features such as process names is insufficient to accurately determine its actual service type, operational functions, and monitoring requirements. This usually requires operations personnel to further analyze contextual information such as process command lines, startup parameters, and network connections, and manually determine monitoring items and alarm policies. This leads to a significant increase in repetitive analysis and configuration workload as the number of servers increases.

[0021] Meanwhile, different servers have different business roles, deployed services, and hardware resource conditions. Even when running the same or similar services, their resource usage characteristics and reasonable alarm ranges may differ. Traditional methods using fixed monitoring templates or uniform alarm thresholds are insufficient to dynamically adjust based on the actual service roles, service dependencies, and hardware resource constraints of servers, easily leading to a mismatch between monitoring configurations and the actual operating environment. Furthermore, existing service discovery processes typically end with the identification and configuration of the current server. Newly discovered and confirmed service characteristics are difficult to promptly transform into reusable fingerprint rules and feed back into the service fingerprint knowledge base. This means that when the same unknown service reappears on other servers, it may repeatedly undergo fingerprint matching failures, manual analysis, and manual configuration, limiting the continuous reuse of existing operational analysis results.

[0022] Therefore, in operation and maintenance scenarios involving large-scale server deployments and frequent microservice iterations, it is necessary to establish a monitoring configuration mechanism that balances rapid identification of known services with intelligent analysis of unknown services. While maintaining the efficiency of static fingerprint matching, this mechanism should further utilize the deep contextual information of unknown processes to infer their service type and monitoring requirements, and adaptively generate monitoring configurations and alarm thresholds based on server roles and hardware resource conditions. Simultaneously, the confirmed unknown service identification results need to be transformed into new fingerprint knowledge and continuously fed back into the service fingerprint knowledge base. This allows the results of an unknown service analysis to be reused by subsequent services of the same type, forming a closed-loop processing process from service discovery, intelligent identification, monitoring configuration generation to knowledge accumulation. This reduces the workload of repetitive manual analysis and configuration in large-scale server environments and improves the automation and intelligence of monitoring configuration generation.

[0023] In the above context, such as Figure 1 The diagram shown is a flowchart of a monitoring configuration method based on fingerprint recognition and large model inference provided in an embodiment of this application; based on Figure 1It should also be understood that the four steps of this invention form a progressive technical chain from quickly identifying known services to intelligently identifying unknown services, then to dynamically generating adaptive monitoring strategies, and finally to accumulating the identification results and feeding back to subsequent identifications. This not only enables the automatic monitoring and configuration of the current server, but also continuously improves the service identification efficiency of subsequent servers through knowledge feedback, thereby reducing the amount of repetitive manual operation and maintenance work in scenarios of large-scale server batch deployment and continuous iteration of microservices.

[0024] refer to Figure 1 The first step of the monitoring configuration method based on fingerprint recognition and large model inference is as follows: An environment scanning mode is initiated on the target server to collect the operating environment characteristics of the target server, including the list of running processes, listening ports, disk partition information, and hardware configuration parameters. The process names in the running process list are then matched with static fingerprint rules in a pre-set service fingerprint knowledge base using regular expressions to identify known services, and processes that fail to match are marked as unknown processes. This step enables the rapid automatic discovery of known services using static fingerprint rules, while using processes that fail to match as subsequent intelligent analysis objects. This approach reduces the scope of large model processing while ensuring the efficiency of known service identification, thereby reducing unnecessary inference calculations and manual investigation work.

[0025] This embodiment provides a specific implementation of the first step of the monitoring configuration method based on fingerprint recognition and large model inference. This step is the environmental scanning and static fingerprint screening step, which specifically includes three stages: environmental feature acquisition, static fingerprint rule construction, and regular expression matching recognition.

[0026] First, the environmental feature collection phase: When the target server initiates environment scanning mode, a collection agent pre-deployed on the target server performs the environment scanning task, comprehensively collecting the target server's operating environment features. The environment scanning mode can be automatically triggered when the target server first connects to the monitoring platform, or it can be manually triggered by operations and maintenance personnel through commands issued by the monitoring platform. The specific operating environment features include:

[0027] List of running processes: This is obtained by calling the process management interface provided by the operating system. In Linux, this can be done by reading the / proc virtual file system or executing a process query command to traverse and record the process ID (PID) and process name of each process.

[0028] Listening Port: Collect all network ports currently in listening state and the process IDs associated with each listening port through the network status query command, thereby establishing the correspondence between ports and processes.

[0029] Disk partition information: By reading the system's disk mount information and partition table data, parameters such as the mount point, file system type, total capacity, and used capacity of each disk partition can be obtained.

[0030] Hardware configuration parameters: By reading the system hardware information interface, hardware configuration parameters such as the number of CPU cores, CPU model, total memory capacity, and total disk space can be obtained.

[0031] All of the above-mentioned operating environment characteristics are organized and stored in a structured data format to form a complete snapshot of the target server's operating environment for subsequent steps.

[0032] Secondly, in the static fingerprint rule construction phase: the pre-built service fingerprint knowledge base is a structured database that is pre-built and dynamically expandable within the monitoring platform. Each static fingerprint rule in the service fingerprint knowledge base contains at least the following three fields:

[0033] Service Name: Uniquely identifies the standard service type corresponding to this rule, such as "MySQL service" or "Nginx service"; Process Name Regular Expression: Characterizes the naming characteristics of the process name of this service. For example, for the MySQL database service, the regular expression "^mysqld" or "^mysqld_safe" can be configured to accommodate differences in process naming across different versions and startup methods; Default Listening Port: Used as an auxiliary verification criterion. For example, the default listening port for the MySQL service is 3306, and the default listening port for the Nginx service is 80 or 443.

[0034] Next, the regular expression matching and recognition step: The process names in the running process list are matched with the static fingerprint rules in the pre-set service fingerprint knowledge base using regular expressions. This specifically includes the following sub-steps:

[0035] S11. Traverse the list of running processes, take out one of the unprocessed processes as the current process to be identified, and get its process name.

[0036] S12. Compare the process name of the current process to be identified with each process name regular expression in the service fingerprint knowledge base in turn: if the current process name matches a process name regular expression, the comparison is successful, then execute sub-step S13; if the comparison fails after traversing all process name regular expressions in the service fingerprint knowledge base, then execute sub-step S14.

[0037] S13. Determine that the current process to be identified is a known service, associate the service name in the hit static fingerprint rule with the known service, and optionally combine it with the collected listening port information for cross-validation, that is, determine whether the port number listened to by the known service is consistent with the default listening port in the static fingerprint rule. If they are consistent, the identification result is confirmed to be reliable, and then return to sub-step S11 to process the next process.

[0038] S14. Determine that the current process to be identified is an unknown process, and summarize and record its process ID, process name, startup command line, user, and associated listening port to form an unknown process list. This list will be used in subsequent steps to extract its deep context information and input into a large language model for intelligent reasoning.

[0039] Once all processes in the running process list have completed the above processing steps, this step ends, and the final output includes the identification results containing a list of known services and a list of unknown processes.

[0040] It should be understood that by pre-setting service names, process name regular expressions, and default listening ports in the service fingerprint knowledge base, and using regular expression matching to identify running processes one by one, the differences in process names under different versions or naming formats can be taken into account, improving the compatibility and matching efficiency of known service identification. At the same time, completing the rapid screening of known services in a rule-based manner can reduce the number of unknown processes that the subsequent large language model needs to process, thereby reducing the data processing overhead of intelligent inference and improving the overall service discovery efficiency.

[0041] The second step of the monitoring configuration method based on fingerprint recognition and large-scale model reasoning is as follows: Extract the deep context information of the unknown process; concatenate the deep context information according to a preset service identification template to generate structured prompts; input the structured prompts into a pre-deployed large-scale language model; and use the large-scale language model to extract semantic features and perform classification reasoning on the deep context information to obtain the intelligent reasoning results for the unknown process output by the large-scale language model. The intelligent reasoning results include inferred service types and recommended monitoring methods. Through this step, the operational characteristics reflected by the deep context of the process can be used to compensate for the limited coverage of static fingerprint rules, enabling self-developed services, customized middleware, and newly added microservices not included in the fingerprint knowledge base to still obtain corresponding service type judgments and monitoring method recommendations, thereby improving the automatic identification capability of unknown services.

[0042] This embodiment provides a specific implementation of the second step of the monitoring configuration method based on fingerprint recognition and large model reasoning. This step is a deep context extraction and intelligent reasoning step, which follows the list of unknown processes output in the first step. Specifically, it includes three stages: deep context information collection, structured prompt word generation, and large language model reasoning.

[0043] First, the deep context information collection phase: For each unknown process in the unknown process list output in the first step, the collection agent deployed on the target server extracts the deep context information of that unknown process. Deep context information refers to multi-dimensional correlated data that reflects the actual business functions, operational behavior, and resource consumption characteristics of the process, and includes at least:

[0044] The complete command-line startup parameters for a process: In Linux operating systems, these are obtained by reading the ` / proc / [PID] / cmdline` file or by calling the process query command. These parameters include the executable file path, startup parameters, and configuration file path. For example, the complete command line of a self-developed service process may contain configuration path information such as "-c / opt / custom-app / conf / server.yaml". This type of information is an important semantic clue for determining the service type.

[0045] The list of file descriptors opened by the process is obtained by traversing the / proc / [PID] / fd directory and resolving the target paths pointed to by the symbolic links of each file descriptor, including log file paths (such as files with the .log extension), configuration file paths, socket files, and dependent dynamic library files, etc.

[0046] List of network listening ports bound to a process: This command filters all listening ports associated with the process ID of the unknown process and their protocol types, including TCP and UDP. For example, if an unknown process is bound to a TCP listener on port 9090, it suggests that it may be an HTTP or RPC service.

[0047] Process resource usage percentage: This includes the process's CPU usage percentage and memory usage percentage, which reflects the process's business load characteristics and serves as one of the reference bases for threshold derivation in step three.

[0048] Secondly, the structured prompt generation step involves concatenating the aforementioned deep contextual information according to a preset service identification template to generate structured prompts. This process includes the following sub-steps:

[0049] S21. Configure the service identification template in the monitoring platform beforehand. The service identification template defines several data fields, the filling specifications for each data field, and output format constraints. The data fields include at least the process name field, the complete command line field, the file descriptor list field, the listening port list field, the resource usage field, and the reference service list field. The output format constraints are used to limit the returned content of the large language model to a structured format that can be parsed by the program, and explicitly require that the returned data items include the inferred service type, confidence score, suggested log path, and health check link.

[0050] S22. Map the process name and deep context information of the unknown process to the corresponding data fields of the service identification template one by one, that is: fill in the process name field, fill in the complete command line startup parameters field, fill in the open file descriptor list field, fill in the bound network listening port list field, and fill in the CPU utilization rate and memory usage rate field.

[0051] S23. Append a reference list containing known service characteristics to the reference service list field of the template. The reference list is selected from the known services identified in the first step, and the selection rules are as follows: prioritize known services that are related or similar to the current unknown process, including known services whose listening port numbers are in the same common range, and known services whose command lines contain the same configuration directory or the same running user characteristics; the reference list must contain at least the service name, process name characteristics, and default listening port information of each known service. For example, when there is a feature sample in the reference list that "port 8080 corresponds to a Web gateway service", if the current unknown process also listens in a similar port range, the large language model can use this reference information to make an analogy judgment.

[0052] S24. Concatenate the contents of all filled fields according to the structured format specified in the service identification template to generate structured prompt words for input into the large language model; in this embodiment, the structured format can be either JSON key-value pair format or Markdown section format.

[0053] Furthermore, in the large language model inference stage: S25, the structured prompt words are input into the pre-deployed large language model. The large language model is a generative large language model with text semantic understanding and classification reasoning capabilities. It can be deployed as an inference service in a local private environment based on an open-source large language model to meet the security requirement of data not leaving the domain; other deployment forms with security isolation mechanisms can also be adopted, which are not limited in this embodiment.

[0054] S26. Semantic feature extraction and classification reasoning are performed on the deep contextual information in structured prompts using a large language model. Specifically, the large language model performs semantic parsing on text content such as command-line startup parameters, file paths, and port numbers, extracting implicit service function features, such as application server keywords (e.g., gunicorn, uwsgi), database connection strings, and registry addresses, and then compares and comprehensively judges these features with known service features in a reference list.

[0055] S27. Obtain the intelligent reasoning result for the unknown process returned by the large language model according to the output format constraints in S21. The intelligent reasoning result shall include at least:

[0056] Inferred Service Type: The large language model's determination of the service category to which the unknown process belongs, such as "self-developed order processing microservice" or "customized message middleware"; Confidence Score: A quantitative score reflecting the credibility of the large language model's inferred service type determination, ranging from 0 to 1. This score is used by the monitoring platform to decide whether to directly adopt the inference result or to request manual review. For example, if the confidence score is below a preset threshold (e.g., 0.6), the unknown process is marked as a key target for manual review; Recommended Monitoring Method: Automatically generated monitoring access suggestions based on the inferred service type, further including: Recommended Log Path: The recommended log collection path based on the log files identified in the file descriptor list, such as / opt / custom-app / logs / app.log, used for subsequent log collection item configuration; Health Check Link: A health status probe URL derived by the large language model based on the inferred service type and listening port list, such as http: / / 127.0.0.1:9090 / health, used for subsequent liveness probe monitoring item configuration.

[0057] By further collecting in-depth contextual information such as complete command-line parameters, file descriptors, network listening ports, and resource usage of unknown processes, and organizing it in a structured manner according to a unified template, while introducing known service characteristics as reference information, we can provide more complete and comparative service operation characteristics for large language models, reduce inference bias caused by fragmented input information, and improve the accuracy of identifying unknown service types and monitoring methods. We can also simultaneously obtain monitoring parameters such as log paths and health check links, providing direct data basis for the subsequent automatic generation of targeted monitoring configurations.

[0058] The third step of the monitoring configuration method based on fingerprint recognition and large-scale model inference is as follows: Based on known services and inferred service types, generate server role profiles representing the dependencies and resource constraints between services; generate basic monitoring configurations based on runtime environment characteristics and recommended monitoring methods; combine server role profiles and hardware configuration parameters into threshold derivation prompts, input them into a large language model for context-aware calculation, and obtain the dynamic alarm threshold parameters and monitoring strategy description text output by the large language model; through this step, the aforementioned service identification results can be further transformed into monitoring configuration basis, and the monitoring strategy can be determined by comprehensively considering the server's service dependencies, resource constraints, and hardware conditions. Compared with fixed monitoring templates and uniform alarm thresholds, this improves the matching degree and adaptability of monitoring configurations with the actual runtime environment of the target server.

[0059] This embodiment provides a specific implementation of the third step of the monitoring configuration method based on fingerprint recognition and large model inference. This step follows the known service list and unknown process list output from the first step, as well as the intelligent inference results (including inferred service types and recommended monitoring methods) output from the second step. Specifically, it includes three stages: server role profile construction, basic monitoring configuration generation, and context-aware threshold derivation.

[0060] First, the server role profile construction phase: A server role profile is a comprehensive descriptive model that uses structured data to depict the dependencies and resource constraints of the services hosted by the target server. The specific construction process includes the following sub-steps:

[0061] S301. Count the number and category attributes of known and inferred service types on the target server. The number refers to the total number of coexisting service processes on the target server; the category attribute is divided according to service function type, including at least database, caching, message queue, web application, gateway proxy, and self-developed business services. For example, after counting, a target server has a total of 6 services: 1 database, 1 caching, 3 web applications, and 1 self-developed business service.

[0062] S302. Analyze the network call connections between known services and inferred service types to construct service dependency relationship links reflecting the communication order. Specifically: The collection agent periodically captures network connections initiated by each service process and the peer information of the listening connections, i.e., the mapping relationship between local ports and remote IP addresses and remote ports; then, combined with the correspondence between services and ports established in the first and second steps, the network connections are restored to call edges between services; the call direction is determined based on the chronological order of requests in two adjacent capture samples, forming a directed dependency relationship link, such as "Web application A → Cache B" or "Web application A → Database C". Here, the communication order refers to the chronological relationship of the call behavior between each service.

[0063] S303. Based on the aforementioned quantity and category attributes, identify the resource contention mode and business priority of the target server. The resource contention mode is determined based on the combination of resource consumption types of coexisting services. For example, when database services and multiple compute-intensive web application services coexist on the same server, it is determined as a "dual contention mode for processor and disk I / O"; when multiple coexisting services are memory-sensitive services (such as multiple caching services), it is determined as a "concentrated memory contention mode". Business priority is determined based on the service category attributes and its position in the dependency chain. For example, data storage services located at the downstream end of the dependency chain are marked as high-priority because they are depended on by multiple upper-layer applications, while edge auxiliary services are marked as low-priority.

[0064] S304. Structure the quantity, category attributes, service dependency chain, resource contention mode, and business priority, for example, by organizing them into a JSON-formatted profile document to construct a server role profile. For example, a typical server role profile would read: "This server is a hybrid application node: it hosts 6 services (3 Web application services, 1 database service, 1 cache service, and 1 self-developed business service); the core dependency chain is Web application → cache → database; the resource contention mode is dual contention for memory and disk I / O; the database service has the highest business priority."

[0065] Next, the basic monitoring configuration generation stage: Based on the characteristics of the operating environment and recommended monitoring methods, the basic monitoring configuration is generated, which specifically includes the following sub-steps:

[0066] S305. Based on the disk partition information in the operating environment characteristics, valid data partitions are filtered out, and disk usage monitoring items are generated for these valid data partitions. Valid data partitions refer to partitions that actually carry business data or application data, excluding temporary file systems, virtual mount points, and system boot partitions. The specific filtering rules are: remove partitions whose file system type belongs to the preset exclusion list (including tmpfs, devtmpfs, proc, sysfs, etc.), and generate a disk usage monitoring item containing the mount point path and the disk usage limit configuration value for each remaining valid data partition.

[0067] S306. Based on the listening ports in the operating environment, generate network port connectivity monitoring items. That is, generate a connectivity probe item for each port in the listening state. The monitoring platform periodically initiates a Transmission Control Protocol (TCP) handshake probe to the corresponding port of the target server, and verifies that the port is in a reachable and acceptable connection state based on whether the handshake is successful.

[0068] S307. For running processes corresponding to known services and unknown processes, generate unified process survival status monitoring items. That is, monitor whether the corresponding process entity continues to exist by using the process identifier as an index. If the monitored process disappears, a process abnormal event is triggered and reported.

[0069] S308. Parse the monitoring path parameters included in the recommended monitoring method to generate corresponding log keyword monitoring items and Hypertext Transfer Protocol (HTTP) health check monitoring items. Specifically: For the suggested log path parameters output in the second step, register incremental collection tasks for the corresponding log files and configure keyword matching rules (e.g., error level keywords such as ERROR, FATAL, etc.). When newly added log content matches the keywords, an alarm is generated; this is the log keyword monitoring item. For the health check link parameters, convert them into periodic probe tasks using HTTP. The service health status is determined based on the HTTP response status code. For example, a status code in the 2xx series is considered healthy, while a status code in the 5xx series or a probe timeout is considered abnormal; this is the HTTP health check monitoring item.

[0070] Furthermore, the context-aware threshold derivation process:

[0071] S309. Combine the server role profile with the hardware configuration parameters in the operating environment characteristics to form threshold derivation prompts. Specifically: Using a template-based approach, fill the corresponding fields in the threshold derivation template pre-configured in the monitoring platform with various contents from the server role profile document (quantity, category attributes, service dependency chain, resource contention mode, business priority) and hardware configuration parameters (number of CPU cores, CPU model, total memory capacity, total disk space, etc.); simultaneously, add an output format constraint to this threshold derivation template to restrict the large language model to return two types of content according to a pre-defined structure: one is structured dynamic alarm threshold parameters, and the other is text-based monitoring strategy description text. It should be noted that the definition method of this output format constraint is the same as the constraint method used in the service identification template in the second step, and will not be repeated here.

[0072] S310. Input the threshold derivation prompts into the large language model for context-aware calculation. Context-aware calculation means that the large language model does not mechanically apply a globally uniform default threshold, but rather performs comprehensive reasoning calculations based on the server role profile context and hardware configuration parameter context carried in the prompts. The large language model outputs two parts in parallel according to the output format constraints: dynamic alarm threshold parameters and monitoring strategy description text. The specific acquisition methods for these two parts are parallel and are as follows: S311. The specific steps for acquiring the dynamic alarm threshold parameters include:

[0073] S311a: The large language model calculates the service distribution density based on the statistics in S301 and the resource contention patterns identified in S303, and dynamically derives the monitoring warning threshold parameters for processors and memory based on the service distribution density. Here, service distribution density is a quantitative indicator of the number of services carried per unit of resource, such as the ratio of the total number of service processes to the number of CPU cores. The monitoring warning threshold parameters for processors and memory are dynamically derived according to the following logic: When the service distribution density is higher than the preset high-density threshold (this high-density threshold and the following low-density threshold are configurable parameters in the monitoring platform; for example, the high-density threshold can be set to 2 services per core), the warning threshold for the processor is lowered accordingly to provide earlier warnings of resource contention risks; when the service distribution density is lower than the preset low-density threshold, the warning threshold is appropriately raised to suppress invalid alarms.

[0074] S311b: The large language model derives the disk capacity alarm threshold parameters for the corresponding data storage partitions based on category attributes. This means that data partitions mounted by data storage services (such as database services) are assigned stricter capacity alarm thresholds and higher warning lead times, while ordinary application partitions are assigned relatively lenient conventional thresholds. Furthermore, the large language model derives the delay suppression time parameters and notification distribution routing strategies for cascading alarms based on service dependency relationships. The delay suppression time parameter refers to the duration of delay set for similar alarms from downstream dependent services when an upstream service in a dependency relationship has already triggered an alarm. For example, connection-related alarms from downstream databases are temporarily suspended for 60 seconds after an upstream web application crashes to avoid a single point of failure triggering an alarm storm. This delay suppression time parameter is a configurable value that can be adjusted in the monitoring platform. The notification distribution routing strategy refers to the combination rules of alarm notification delivery objects and notification channels determined by dependency relationships and business priorities. For example, alarms from storage services with the highest business priority are directly sent to the main notification channel for on-duty maintenance personnel, while alarms from ordinary application services are aggregated to the daily report channel.

[0075] S312. Combine the monitoring warning threshold parameter obtained in S311a, the disk capacity alarm threshold parameter obtained in S311b, the delay suppression time parameter, and the notification distribution routing policy and output them as dynamic alarm threshold parameters.

[0076] S313. The specific steps for obtaining the monitoring strategy description text include: the large language model synchronously outputs the monitoring strategy description text in text form according to the output format constraints. The content includes: explanations of the reasons for setting various basic monitoring configurations (e.g., explaining why a more stringent capacity alarm threshold is set for this data storage partition), explanations of the automatic adjustment logic for dynamic alarm threshold parameters (e.g., explaining the adjustment rules and triggering conditions of the processor warning threshold as the load changes when the service hybrid deployment density increases), alarm escalation suggestions generated based on service dependency relationship links (e.g., specifying the notification path that should be reported level by level when an alarm on a certain critical dependency link has not been restored for a preset duration, the preset duration being a configurable parameter), and global operation and maintenance guidance strategies for server role profiles (e.g., operation and maintenance constraints suggesting that this hybrid deployment node avoid continuing to deploy memory-sensitive services).

[0077] By identifying confidence scores, low-confidence inference results are subject to focused manual verification. A server role profile, including service dependencies, resource contention patterns, and business priorities, is constructed by combining known and inferred services. Based on this profile, basic monitoring items such as disk, port, process, log, and health checks are generated. Furthermore, processor, memory, disk capacity, and cascading alarm parameters are dynamically determined based on service distribution density, service category, and dependency chains, thus linking service identification results, the overall server operating role, and specific monitoring strategies. On the one hand, confidence grading reduces the risk of directly using low-reliability inference results for monitoring configuration. On the other hand, it allows monitoring items and alarm thresholds to be adjusted according to the server's service deployment, resource contention level, and dependencies, reducing monitoring omissions, invalid alarms, and cascading alarm interference caused by fixed monitoring templates and uniform thresholds. This improves the targeting of monitoring configuration, the adaptability of alarm strategies, and the reliability of the automatic configuration process.

[0078] The fourth step of the monitoring configuration method based on fingerprint recognition and large model inference is as follows: The basic monitoring configuration, dynamic alarm threshold parameters, and intelligent inference results are visualized and rendered on the monitoring server interface; the server receives a verification and confirmation instruction for the intelligent inference results, and in response, the confirmed basic monitoring configuration and dynamic alarm threshold parameters are sent to the target server for hot loading; fingerprint features are extracted from the runtime environment characteristics and deep context information corresponding to unknown processes, generating corresponding new fingerprint rules and persistently appending them to the service fingerprint knowledge base. This step ensures the controllability of the intelligent inference results and automatically generated configurations in actual application through a verification mechanism, and improves the deployment efficiency of monitoring configurations through hot loading; simultaneously, the confirmed unknown services are transformed into reusable static fingerprint knowledge, enabling subsequent identical or similar services to be directly identified through fingerprint rules, reducing repetitive large model inference and manual verification processes, and achieving continuous expansion and iteration of the service fingerprint knowledge base.

[0079] This embodiment provides a specific implementation of the fourth step of the monitoring configuration method based on fingerprint recognition and large model inference. This step follows the runtime environment characteristics and unknown process list output from the first step, the intelligent inference results output from the second step (including inferred service type, recognition confidence score, and recommended monitoring method), and the basic monitoring configuration and dynamic alarm threshold parameters generated from the third step. Specifically, it includes three stages: visualization rendering and confidence-based traffic splitting, manual review and confirmation and hot loading and distribution, and fingerprint feature extraction and new rule feedback and accumulation.

[0080] First, the visualization rendering and confidence level splitting process:

[0081] S401. Visualize and render the basic monitoring configuration, dynamic alarm threshold parameters, and intelligent inference results on the monitoring server interface. Specifically: The basic monitoring configuration generated in the third step is displayed in groups according to monitoring item categories, including a list of disk usage monitoring items, a list of network port connectivity monitoring items, a list of process liveness monitoring items, log keyword monitoring items, and Hypertext Transfer Protocol health check monitoring items; the dynamic alarm threshold parameters are displayed in key-value pair table format, including monitoring warning threshold parameters for processors and memory, disk capacity alarm threshold parameters, latency suppression time parameters, and notification distribution routing strategies; the intelligent inference results output by the large language model in the second step are also listed, including the inferred service type, identification confidence score, suggested log path, and health check link for each unknown process; and the monitoring strategy description text is presented synchronously in expandable and readable text blocks for auditors to understand the rationale behind each configuration setting.

[0082] S402. Determine whether the identification confidence score corresponding to each unknown process is lower than the preset confidence threshold. The identification confidence score is the quantitative score of the large language model's judgment on the credibility of the inferred service type in the second step, with a value range of 0 to 1; the confidence threshold is an adjustable parameter pre-configured in the monitoring platform, which can be set to 0.6 for example.

[0083] S403. If the identification confidence score is higher than or equal to the confidence threshold, the inferred service type and recommended monitoring method corresponding to the unknown process will be displayed on the interface in a normal pending review state. If the identification confidence score is lower than the confidence threshold, the inferred service type and recommended monitoring method corresponding to the unknown process will be marked as pending manual key verification on the monitoring server interface. The purpose of marking the pending manual key verification state is to adjust the review processing order rather than block the process: the marked items are displayed with a prominent visual style that is different from regular items (for example, a bright warning color with an additional "key verification" text label) and are arranged at the front of the review queue, thereby guiding maintenance personnel to prioritize verification efforts. The marked items still need to be manually reviewed and confirmed as described in S404 below before they can take effect, thereby improving the overall review efficiency and ensuring that low-confidence conclusions do not deviate from human review.

[0084] Further, the manual review and confirmation process, along with the hot-loading distribution process:

[0085] S404. Receive the server's review and confirmation instruction for the intelligent inference results. Specifically: Operations personnel review the rendered content item by item on the monitoring server interface. For monitoring configuration items that are confirmed to be correct, they submit a confirmation operation through the interface controls. For items that need to be corrected, they can directly edit and modify them on the interface and then confirm. The monitoring server receives the review and confirmation instructions generated by the above operations and records the operator's ID, operation time, and differences in content before and after each confirmation operation, forming a review log for future reference.

[0086] S405. In response to the verification and confirmation command, the confirmed basic monitoring configuration and dynamic alarm threshold parameters are sent to the target server for hot reloading. Hot reloading refers to a mechanism that updates the configuration without restarting the data collection agent process on the target server or interrupting the operation of various business services on the target server. The specific implementation process includes the following three parallel execution steps:

[0087] S405a The monitoring platform encapsulates the confirmed basic monitoring configuration and dynamic alarm threshold parameters into a versioned configuration file and pushes it to the collection agent on the target server. Versioning means that each configuration file carries a unique version number and content verification code so that the collection agent can distinguish between new and old configurations and verify data integrity.

[0088] S405b: After receiving the new configuration file, the acquisition agent first performs local format verification and content verification code verification. If the verification passes, the new configuration completely replaces the old configuration in memory at once (i.e., atomic replacement, ensuring that there is no intermediate state of half new and half old during the replacement process) and takes effect immediately. Then, it sends a receipt to the monitoring platform to show the successful loading status and the current effective version number.

[0089] S405c If the verification fails, the data acquisition agent retains the old configuration and continues to operate normally, and reports the reason for the failure to the monitoring platform. The monitoring platform then prompts the maintenance personnel to reissue the configuration, thereby ensuring that the monitoring and data acquisition process on the target server is not interrupted due to the configuration update.

[0090] Furthermore, the fingerprint feature extraction and new rule feedback and accumulation stage: In response to the review and confirmation instruction, fingerprint features are extracted from the runtime environment characteristics and deep context information corresponding to the unknown process, generating corresponding new fingerprint rules and persistently appending them to the service fingerprint knowledge base. This specifically includes the following sub-steps:

[0091] Before executing S406 below, the relevant definitions should be clarified first: Command line text features refer to the part of the text in the complete command line startup parameters in the deep context information that has a stable identification function; since the command line startup parameters usually contain dynamic values ​​such as port number, instance number, temporary path, etc. that change with the deployment environment, the reduction rule should be agreed upon in advance: remove the volatile numeric parameter values ​​and environment-related path variables, and retain the stable executable file name and its fixed naming skeleton.

[0092] S406. Process the complete command-line startup parameters of the unknown process according to the above reduction rules, extract the command-line text features, and convert the command-line text features into a process name regular expression. For example, the complete command line of a self-developed service process is " / opt / custom-app / bin / order-server --port=9090", after removing the dynamically valued parts such as the port number, the result is the regular expression "order-server".

[0093] S407. Extract the target port bound to the unknown process from the listening port information in the runtime environment characteristics corresponding to the unknown process. Specifically: based on the correspondence between ports and processes established in the first step, find all listening ports associated with the process ID of the unknown process, and select one of the main service listening ports as the target port; when there are multiple candidate listening ports, combine the port number contained in the health check link output in the second step to determine the main service listening port. For example, when the health check link is "http: / / 127.0.0.1:9090 / health", the target port is determined to be 9090.

[0094] S408. In response to the review confirmation instruction, obtain the configuration parameter characteristics from the confirmed recommended monitoring method. That is, upon receiving the review confirmation instruction, read all the configuration parameters from the finally adopted recommended monitoring method as configuration parameter characteristics, including at least the confirmed suggested log path and health check link; if the operations and maintenance personnel have made modifications during the review, the modified actual effective value shall prevail, thereby ensuring that the returned and accumulated data is real experience endorsed by humans and verified in practice.

[0095] S409. Encapsulate the extracted fingerprint features using the process name regular expression, target port, and configuration parameter features to generate a corresponding new fingerprint rule. Specifically, map and assemble the three-field structure of the static fingerprint rule in the first step. The field correspondence is as follows: the service name field is filled with the confirmed inferred service type conclusion, the process name regular expression field is filled with the regular expression obtained in S406, and the default listening port field is filled with the target port obtained in S407. At the same time, the suggested log path, health check link, and other configuration parameter features obtained in S408 are added as extended fields and stored in the new fingerprint rule to form a complete new fingerprint rule record.

[0096] S410. Persistently append the new fingerprint rule to the service fingerprint knowledge base. Specifically: Before writing, perform deduplication verification on the new fingerprint rule, that is, compare its process name regular expression and default listening port to see if they are duplicated or conflict with existing static fingerprint rules in the service fingerprint knowledge base; if there is a conflict, it is handled by updating and merging existing rules; if there is no conflict, it is written in append mode; after successful writing, the new fingerprint rule has the same status as other static fingerprint rules and can be directly called in the static matching stage of any subsequent round of environment scanning. After that, when the same type of process appears again on the target server or any other server, it will be directly hit as a known service in the first step, and its log path and health check link and other configuration information will be automatically associated, without having to enter the large language model inference and manual review process.

[0097] By generating basic monitoring configuration settings, dynamic threshold adjustment logic, alarm escalation suggestions, and global operation and maintenance guidance strategies through a large language model, the automatically generated monitoring configurations and alarm parameters have corresponding explanatory basis, facilitating the understanding, review, and adjustment of intelligent inference results by operation and maintenance personnel. Simultaneously, after review and confirmation, stable fingerprint features are extracted from the command lines, listening ports, and recommended monitoring methods of unknown processes to generate new fingerprint rules, further solidifying the manually confirmed intelligent inference results into reusable service fingerprint knowledge. This achieves a collaborative closed loop of large model inference interpretation, manual review and confirmation, fingerprint feature extraction, and knowledge base update. This allows for priority identification using static fingerprints when encountering identical or similar services, reducing repetitive large model inference and manual verification, improving the continuous accumulation of service fingerprint knowledge, and enhancing the efficiency of subsequent monitoring configuration.

[0098] Furthermore, Figure 2 The overall architecture diagram of the monitoring configuration method based on fingerprint recognition and large model inference provided in the embodiments of this application is shown below. Figure 3 A detailed flowchart of the monitoring configuration method based on fingerprint recognition and large model inference provided in the embodiments of this application; based on Figure 2 , Figure 3It should also be noted that the steps described above in this invention are interconnected and work synergistically. Environmental scanning and static fingerprint matching obtain the characteristics of known services, unknown processes, and operating environments, providing a data foundation for large-scale model inference of unknown services. The inferred service types and recommended monitoring methods obtained from large-scale model inference further supplement the static fingerprint recognition results and are combined with server role profiles, hardware configurations, and resource constraints to generate monitoring configurations and dynamic alarm thresholds adapted to the actual operating environment of the target server. After review and confirmation, the corresponding configurations are issued and executed, and the confirmed unknown service characteristics generate new fingerprint rules that are fed back to the service fingerprint knowledge base, enabling the intelligent recognition results to be used for subsequent static recognition of similar services. This forms a closed-loop processing mechanism of environmental scanning, fingerprint recognition, intelligent inference, policy generation, review and issuance, and knowledge feedback, achieving complementary advantages between static fingerprint recognition and large-scale model inference. Furthermore, the continuous accumulation of fingerprint knowledge reduces repetitive inference and manual analysis, thereby improving the automation, processing efficiency, and environmental adaptability of service recognition and monitoring configuration.

[0099] like Figure 4 The diagram shown is a structural schematic of a monitoring configuration system based on fingerprint recognition and large model inference provided in an embodiment of this application. (Refer to...) Figure 4 The system includes: a fingerprint matching and recognition module, a large model inference module, a monitoring configuration generation module, and a knowledge base feedback module.

[0100] Specifically, the fingerprint matching and recognition module is used to start the environment scanning mode on the target server, collect the operating environment characteristics of the target server, including the list of running processes, listening ports, disk partition information and hardware configuration parameters; perform regular expression matching between the process names in the list of running processes and the static fingerprint rules in the preset service fingerprint knowledge base, identify known services, and mark processes that fail to match as unknown processes.

[0101] The large-scale model reasoning module is used to extract deep contextual information of unknown processes. It concatenates the deep contextual information according to a preset service identification template to generate structured prompt words. The structured prompt words are then input into a pre-deployed large language model. The large language model extracts semantic features and performs classification reasoning on the deep contextual information to obtain the intelligent reasoning results for the unknown processes output by the large language model. The intelligent reasoning results include inferred service types and recommended monitoring methods.

[0102] The monitoring configuration generation module is used to generate server role profiles representing the dependencies and resource constraints between services based on known services and inferred service types; generate basic monitoring configurations based on runtime environment characteristics and recommended monitoring methods; combine server role profiles with hardware configuration parameters to form threshold derivation prompts, input them into a large language model for context-aware calculation, and obtain dynamic alarm threshold parameters and monitoring strategy description text output by the large language model.

[0103] The knowledge base feedback module is used to visualize and render basic monitoring configurations, dynamic alarm threshold parameters, and intelligent inference results on the monitoring server interface; it receives the server's review and confirmation instructions for the intelligent inference results, and in response to the review and confirmation instructions, sends the confirmed basic monitoring configurations and dynamic alarm threshold parameters to the target server for hot reloading; it extracts fingerprint features from the runtime environment characteristics and deep context information corresponding to unknown processes, generates corresponding new fingerprint rules, and persistently appends them to the service fingerprint knowledge base.

[0104] Overall, this invention organically combines service fingerprinting, large language model inference, server role profiling, dynamic alarm threshold generation, and fingerprint knowledge feedback mechanisms. This enables automatic perception of the server operating environment, rapid identification of known services, intelligent inference of unknown services, and adaptive generation of monitoring configurations and alarm policies. A complete closed-loop processing flow is formed through verification, hot configuration loading, and persistence of new fingerprint rules. Compared to existing technologies that primarily rely on static fingerprint matching and manual analysis, this invention effectively improves the identification capabilities of non-standard services such as self-developed services, customized middleware, and newly added microservices. It reduces repetitive manual investigation and monitoring configuration work for similar unknown services, while continuously accumulating and expanding the service fingerprint knowledge base with confirmed identification results. This improves the efficiency of subsequent service identification and monitoring configuration generation, thereby enhancing the automation, intelligence, and scalability of monitoring configuration in scenarios involving large-scale server deployments and frequent microservice iterations. This provides effective technical support for achieving zero-configuration monitoring and intelligent operation and maintenance.

[0105] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the above functions can be divided into different functional modules to complete all or part of the functions described above.

[0106] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0107] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units, located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the solution, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0110] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A monitoring configuration method based on fingerprint recognition and large model inference, characterized in that, Includes the following steps: The environment scanning mode is started on the target server to collect the operating environment characteristics of the target server. The operating environment characteristics include the list of running processes, listening ports, disk partition information and hardware configuration parameters. The process names in the list of running processes are matched with the static fingerprint rules in the preset service fingerprint knowledge base using regular expressions to identify known services and mark the processes that fail to match as unknown processes. Extract deep context information of unknown processes, and concatenate the deep context information according to the preset service identification template to generate structured prompt words; The structured prompt words are input into a pre-deployed large language model. The large language model extracts semantic features and performs classification reasoning on deep contextual information to obtain the intelligent reasoning results for unknown processes output by the large language model. The intelligent reasoning results include inferring service types and recommending monitoring methods. Based on known services and inferred service types, generate server role profiles representing the dependencies and resource constraints between services; Based on the characteristics of the operating environment and the recommended monitoring methods, a basic monitoring configuration is generated; the server role profile and hardware configuration parameters are combined into threshold derivation prompts, which are then input into a large language model for context-aware calculation to obtain the dynamic alarm threshold parameters and monitoring strategy description text output by the large language model. The monitoring server interface displays basic monitoring configurations, dynamic alarm threshold parameters, and intelligent inference results in a visual representation. Receive the server's review and confirmation instruction for the intelligent reasoning results, and in response to the review and confirmation instruction, send the confirmed basic monitoring configuration and dynamic alarm threshold parameters to the target server to perform hot reloading; Fingerprint features are extracted from the runtime environment characteristics and deep context information of the unknown process, and corresponding new fingerprint rules are generated and persistently added to the service fingerprint knowledge base.

2. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 1, characterized in that, The static fingerprint rules in the pre-built service fingerprint knowledge base include at least: service name, process name regular expression, and default listening port; The step of performing regular expression matching between the process names in the running process list and the static fingerprint rules in the preset service fingerprint knowledge base specifically includes: Iterate through the list of running processes, comparing each process name with the regular expressions of each process name in the service fingerprint knowledge base. If a match is found, mark the corresponding process as a known service.

3. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 1, characterized in that, The deep context information includes at least: the complete command-line startup parameters of the process, the list of file descriptors opened by the process, the list of network listening ports bound to the process, and the resource usage percentage of the process; The step of concatenating deep context information according to a preset service identification template to generate structured prompt words specifically includes: The process name and deep context information of the unknown process are mapped and filled into the corresponding data fields of the preset service identification template, and a reference list containing known service characteristics is attached. The list is then concatenated to generate structured prompt words for prompting the intelligent reasoning results output by the large language model. The recommended monitoring methods include suggested log paths and health check links.

4. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 3, characterized in that, The intelligent reasoning results output by the large language model also include a confidence score. The steps of visually rendering basic monitoring configurations, dynamic alarm threshold parameters, and intelligent inference results on the monitoring server interface also include: Determine whether the confidence score is lower than the preset confidence threshold; If the confidence score is lower than the confidence threshold, the inferred service type and recommended monitoring method corresponding to the unknown process will be marked as pending manual verification on the monitoring server interface.

5. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 1, characterized in that, The generation of server role profiles, representing the dependencies and resource constraints between services, specifically includes: Count and classify the number and inferred service types of known services on the target server. Analyze the network call connections between known services and inferred service types, and construct service dependency relationship links that reflect the communication order; Based on quantity and category attributes, identify the resource contention patterns and business priorities of the target server; By structurally combining quantity, category attributes, service dependency links, resource contention patterns, and business priorities, a server role profile representing the dependencies and resource constraints among services is constructed.

6. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 1, characterized in that, The generation of basic monitoring configuration based on operating environment characteristics and recommended monitoring methods specifically includes: Based on the disk partition information in the runtime environment characteristics, valid data partitions are filtered out, and disk usage monitoring items for valid data partitions are generated. Based on the listening port in the runtime environment characteristics, generate network port connectivity monitoring items; For running processes corresponding to known services and unknown processes, generate process liveness status monitoring items; The monitoring path parameters included in the recommended monitoring method are parsed to generate corresponding log keyword monitoring items and Hypertext Transfer Protocol health check monitoring items.

7. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 5, characterized in that, The specific steps for obtaining the dynamic alarm threshold parameter include: The service hybrid density is calculated based on the quantity and resource contention patterns using a large language model, and the monitoring warning threshold parameters for processors and memory are dynamically derived based on the service hybrid density. The disk capacity alarm threshold parameters for the corresponding data storage partition are derived from the large language model based on the category attributes, and the latency suppression time parameters and notification distribution routing strategies for cascading alarms are derived based on the service dependency relationship links. The monitoring warning threshold parameter, disk capacity alarm threshold parameter, latency suppression time parameter, and notification distribution routing policy are combined and output as dynamic alarm threshold parameters.

8. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 7, characterized in that, The specific steps for obtaining the monitoring strategy description text include: The large language model outputs a text describing the monitoring strategy, which includes explanations of the reasons for setting various basic monitoring configurations, explanations of the automatic adjustment logic for dynamic alarm threshold parameters, alarm escalation suggestions generated based on the dependencies between services, and global operation and maintenance guidance strategies for server role profiles.

9. The monitoring configuration method based on fingerprint recognition and large model inference as described in claim 3, characterized in that, The extraction of fingerprint features from the runtime environment characteristics and deep context information corresponding to the unknown process specifically includes: Extract command line text features from the deep context information corresponding to the unknown process, and convert the command line text features into process name regular expressions; Extract the target port bound to the unknown process from the listening port information in the runtime environment characteristics corresponding to the unknown process; In response to the audit confirmation instruction, obtain the configuration parameter characteristics of the confirmed recommended monitoring method; The process name regular expression, target port, and configuration parameter features are used as extracted fingerprint features for data encapsulation to generate corresponding new fingerprint rules.

10. A monitoring configuration system based on fingerprint recognition and large model inference, employing the monitoring configuration method based on fingerprint recognition and large model inference as described in any one of claims 1-9, characterized in that, include: The module includes a fingerprint matching and recognition module, a large model inference module, a monitoring configuration generation module, and a knowledge base feedback module. The fingerprint matching and recognition module is used to start the environment scanning mode on the target server, collect the operating environment characteristics of the target server, including the list of running processes, listening ports, disk partition information and hardware configuration parameters; perform regular expression matching between the process names in the list of running processes and the static fingerprint rules in the preset service fingerprint knowledge base, identify known services, and mark the processes that fail to match as unknown processes; The large model reasoning module is used to extract deep context information of unknown processes, and to concatenate the deep context information according to a preset service identification template to generate structured prompt words. The structured prompt words are input into a pre-deployed large language model. The large language model extracts semantic features and performs classification reasoning on deep contextual information to obtain the intelligent reasoning results for unknown processes output by the large language model. The intelligent reasoning results include inferring service types and recommending monitoring methods. The monitoring configuration generation module is used to generate server role profiles representing the dependencies and resource constraints between services based on known services and inferred service types. Basic monitoring configuration is generated based on the characteristics of the operating environment and recommended monitoring methods; The server role profile and hardware configuration parameters are combined into threshold derivation prompt words, which are then input into the large language model for context-aware calculation to obtain the dynamic alarm threshold parameters and monitoring strategy description text output by the large language model. The knowledge base feedback module is used to visualize and render basic monitoring configurations, dynamic alarm threshold parameters, and intelligent reasoning results on the monitoring server interface. Receive the server's review and confirmation instruction for the intelligent reasoning results, and in response to the review and confirmation instruction, send the confirmed basic monitoring configuration and dynamic alarm threshold parameters to the target server to perform hot reloading; Fingerprint features are extracted from the runtime environment characteristics and deep context information of the unknown process, and corresponding new fingerprint rules are generated and persistently added to the service fingerprint knowledge base.

Images