A Service Monitoring and Management System Based on Distributed Agents

Abstract

This invention relates to the interdisciplinary field of distributed artificial intelligence systems and microservice governance, specifically a service monitoring and management system based on distributed agents. The system adopts a three-tier architecture: user layer, host agent layer, and service agent layer. The user layer has a unified entry point for forwarding requests; the host agent layer integrates modules such as a service registry for global management; and the service agent layer includes modules for registration and function / status feedback. It achieves dynamic binding of service functions and states through four innovations: a dynamic observability model, an incremental heartbeat protocol, a fine-grained state machine, and an intelligent routing engine. The advantages of this solution are improved service observability, optimized problem localization efficiency, reduced monitoring data transmission volume, shortened service interruption time, improved availability, and increased throughput in high-concurrency scenarios, making it suitable for scenarios such as intelligent customer service.

Description

Technical Field

[0001] This invention relates to the field of distributed artificial intelligence systems and microservice governance, and in particular to a service monitoring and management system based on distributed agents. Background Technology

[0002] With the rapid evolution of large model technology, functional agents built on large models are showing a trend of distributed, specialized and fragmented development. These functional agents are usually deployed in heterogeneous computing environments and have characteristics such as high dynamism, short life cycle and inconsistent interfaces.

[0003] The core contradiction facing the current large-scale model application ecosystem is the increasing integration of functional requirements and the growing fragmentation of service implementation. Specifically, on the one hand, end users expect a one-stop intelligent service experience; on the other hand, limited by computing resources and technical expertise, developers tend to build smaller, single-function agents. This contradiction leads to three major pain points in existing technologies:

[0004] 1. Functional agents are deployed in a scattered manner, lacking a unified service catalog and status view, making it difficult for developers to grasp the overall service status;

[0005] 2. Agent services are highly dynamic, and traditional static service discovery mechanisms cannot adapt to frequent online / offline changes;

[0006] 3. Service anomalies are difficult to detect and handle in a timely manner, and the scope of the impact of the fault is uncontrollable.

[0007] Existing solutions fail to address the core issue of "dynamic binding of service function availability," meaning that the external exposure of service functions is not correlated with their actual operational status in real time. This invention addresses this technological gap by proposing an innovative solution. Summary of the Invention

[0008] The purpose of this invention is to overcome the problems of the prior art and provide a service monitoring and management system based on distributed agents. This system addresses the technical problems of existing large-scale service monitoring and management, such as the separation of service function description and operational status monitoring, difficulty in accurately assessing service capabilities, high monitoring overhead of traditional full-scale heartbeat mechanisms affecting system performance, coarse granularity of service status management, easy service interruption due to state transitions, and single dimension of service routing decision, which cannot adapt to the scheduling needs of complex heterogeneous environments.

[0009] The above objectives are achieved through the following technical solutions:

[0010] A service monitoring and management system based on distributed agents includes a three-layer architecture: user layer, host agent, and service agent.

[0011] The user layer has a unified service entry point, which is used to receive user requests for large model services and, based on the intelligent decision-making of the host agent, accurately forwards user requests to available service agents.

[0012] There is at least one host agent, which serves as the unified entry point for service scheduling. It integrates a service registry, heartbeat monitor, service controller, and health checker to achieve full lifecycle management of the service agent, specifically:

[0013] The service registry is used to store metadata of all registered service agents, build a service directory index, and provide a data foundation for user-level request routing and service status analysis.

[0014] The heartbeat monitor is used to receive incremental heartbeat data sent by the service agent in real time, track the last active timestamp of the service agent, combine historical heartbeat data, analyze service anomaly patterns, and trigger health checks or service isolation processes.

[0015] The service controller is used to send instructions to the service agent, link the service registry to update the service status, drive the smooth transition of the service state machine, and ensure rapid response and self-healing when the service is abnormal.

[0016] The health checker is used to proactively check the health status of the service.

[0017] The service agent comprises multiple agents, serving as the unit that actually provides the large-scale model service functionality. These agents integrate a registration module, a heartbeat module, a control interface module, and a health check module, specifically:

[0018] The registration module is used to register service information containing semantic capability descriptions with the host Agent;

[0019] The heartbeat module is used to periodically send incrementally updated heartbeat messages to the host agent;

[0020] The control interface module is used to receive instructions from the service controller of the host agent and execute service lifecycle operations;

[0021] The health check module is used to provide the health status and operational indicators of this service;

[0022] Also includes:

[0023] A service registration mechanism is used for the service agent to register its service capabilities with the host agent;

[0024] A heartbeat monitoring mechanism is used for the service agent to periodically send heartbeat signals;

[0025] Dynamic directory management is used by the host agent to update or manage the available service directory based on monitoring status;

[0026] Furthermore, the service monitoring method of the system includes the following steps:

[0027] In step (1), the service agent registers service information containing semantic capability descriptions with the host agent.

[0028] In step (2), the service agent periodically sends incremental update heartbeat messages to the host agent;

[0029] In step (3), the host agent dynamically adjusts service routes through the intelligent routing decision engine;

[0030] In step (4), the host agent manages service state transitions based on a fine-grained state machine.

[0031] In step (5), the host agent controls the abnormal service to perform a recovery operation.

[0032] Furthermore, the registration module in the service agent executes the service registration process, including:

[0033] Step S101: The service agent is started, triggering the registration process;

[0034] Step S102: Collect service metadata and monitoring endpoint information;

[0035] Step S103: Construct a standardized registration request and send it to the host Agent;

[0036] Step S104: After receiving the registration request, the host Agent performs a dual verification of "legitimacy + integrity";

[0037] Step S105: After successful verification, the host agent updates the service catalog information;

[0038] Step S106: The host agent sends the registration result back to the service agent, including monitoring configuration parameters, to guide the service agent to report the status in a standardized manner.

[0039] Furthermore, the heartbeat module of the service agent, together with the heartbeat monitor of the host agent, the service controller, and the health checker, collaboratively executes the service heartbeat control process, including:

[0040] Step S201: The service agent initializes heartbeat information, sets the heartbeat sending interval, and clarifies the range of incremental running data that needs to be reported;

[0041] Step S202: Construct a heartbeat message;

[0042] Step S203: Send the heartbeat message to the heartbeat monitor of the host agent through a persistent network connection;

[0043] Step S204: The host agent updates the heartbeat timestamp;

[0044] Step S205: The host agent detects anomalies in the analyzed data;

[0045] Step S206: Combine the last active timestamp with the heartbeat timeout threshold configured in the system to determine whether the abnormal in-depth processing procedure is triggered. If no timeout occurs, proceed to step S207; if a timeout occurs, proceed to step S208.

[0046] Step S207: If the heartbeat timestamp has not expired and the metric analysis shows no abnormalities, the host Agent marks the service as "healthy" in the service registry, updates the "most recent uptime", and includes the service in the candidate set of the "intelligent routing decision engine".

[0047] Step S208: The host agent checks the service health status;

[0048] Step S209: The host agent initiates service control.

[0049] Furthermore, the service directory index constructed by the service registry of the host agent supports classification by "service type and function tag", providing data support for intelligent routing of the unified entry point for user-level services. The intelligent routing decision engine comprehensively considers multiple factors such as service health, load status, and performance indicators to calculate service priority scores and match the optimal service agent for user requests.

[0050] Furthermore, the semantic service description submitted by the registration module of the service agent includes a detailed description of the service capabilities, enabling the host agent to perceive the service capabilities from the perspective of functional characteristics, and to achieve dynamic observability of the service capabilities by combining the operational status monitoring data.

[0051] Furthermore, the incremental heartbeat information sent by the heartbeat module of the service agent only includes operational metrics that have changed compared to the previous one.

[0052] Furthermore, the host agent manages the state of the service agent using a fine-grained state machine mechanism, specifically including:

[0053] (1) Real-time health status assessment combined with heart rate increment data and active detection results;

[0054] (2) Service control processes support smooth state transitions, such as gradual recovery attempts in an isolated state;

[0055] (3) The state transition rules reflect fine-grained management.

[0056] Furthermore, the decision model of the intelligent routing decision engine supports dynamic adjustment of weights according to different application scenarios, and prioritizes services with low response latency in content generation scenarios with high real-time requirements.

[0057] Furthermore, the deep probing request initiated by the health checker of the host agent can, in addition to obtaining the internal state of the service and the state of key dependencies, also collect specific operational indicators in a customized manner according to different service types.

[0058] This invention provides a distributed agent-based service monitoring and management system. Through an innovative host agent architecture, it constructs a novel monitoring and management system for large-model agent services. This system not only monitors the status of distributed service agents but, more importantly, establishes a dynamic binding mechanism between service capabilities and monitoring status. This allows the host agent to intelligently aggregate available service functions, providing a unified and reliable service entry point for upper-layer applications. This technology can be widely applied to large-model application scenarios such as intelligent customer service, content generation, and data analysis, effectively solving the management challenges caused by the "fragmentation" of functional agents. It also includes the following advantages:

[0059] 1. Dynamic Observability Model for Service Capabilities: This model unifies service function descriptions and operational status monitoring through standardized interfaces. During the functional agent registration phase, semantic capability descriptions (such as service type, processing scope, response time, etc.) and standardized monitoring indicator interfaces (such as CPU usage, error rate, concurrency, etc.) must be provided, enabling the host agent to comprehensively perceive service capabilities from both functional characteristics and operational status dimensions. For example, in an intelligent customer service scenario, the question-and-answer function agent needs to register a "sentiment analysis" function tag and business indicators such as "intent recognition accuracy" to achieve a linked evaluation of functional availability and performance indicators.

[0060] 2. Highly Efficient Heartbeat Protocol Based on Incremental Updates: The service agent only carries the changed metric data (such as reporting specific values ​​when response latency exceeds a threshold) in the heartbeat message, and the host agent quickly updates the service status through incremental parsing. Real-world testing shows that this mechanism can reduce monitoring data transmission volume by more than 60%, making it suitable for edge computing environments with limited network bandwidth, significantly reducing monitoring overhead while ensuring real-time performance.

[0061] 3. Fine-grained service state machine management: Defines multiple levels of states such as "Pending Inspection - Healthy - Pending Confirmation - Isolation - Recovery" as well as transition conditions and timeout thresholds. For example, when a service transitions from "Healthy" to "Pending Confirmation", the host Agent first attempts to retransmit incremental data; after entering the "Isolation State", the basic communication channel is reserved for sending recovery commands to avoid service jitter and support smooth service state migration and automatic recovery.

[0062] 4. Intelligent Service Routing Decision Engine: This engine integrates multiple factors such as service health, load status, and performance metrics, employing a built-in decision model and dynamically adjusting weights. For content generation scenarios with high real-time requirements, it prioritizes services with low response latency; for data analysis scenarios, it focuses on services with low resource utilization. It also supports custom strategies (such as allocating high SLA service nodes to paying users) to achieve optimal utilization of service resources.

[0063] The aforementioned synergistic effects of innovation resolve the contradiction between fragmented functions and integrated needs in the large-scale model service ecosystem. Attached Figure Description

[0064] Figure 1 This is a block diagram of a service monitoring and management system based on distributed agents as described in this invention.

[0065] Figure 2 This is a flowchart of the service registration process in a distributed agent-based service monitoring and management system as described in this invention.

[0066] Figure 3 This is a flowchart of the service heartbeat control process in a distributed agent-based service monitoring and management system as described in this invention. Detailed Implementation

[0067] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. The described embodiments are merely some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0068] This solution provides a service monitoring and management system based on distributed agents. Specifically, it designs a three-tiered technical mechanism: First, a semantic registration mechanism for service capabilities, where each functional agent, upon startup, not only reports basic service information but also a complete semantic description of its capabilities and a service level commitment; second, a two-way health awareness mechanism, which constructs a multi-dimensional service health assessment model by combining passive heartbeats and active probes; and most importantly, a dynamic service binding mechanism, where the host agent dynamically adjusts the set of exposed service functions based on real-time monitoring data, ensuring that only healthy and usable functional agents are included in the service catalog.

[0069] like Figure 1 As shown, this solution provides a service monitoring and management system based on distributed agents, comprising a three-layer architecture: user layer, host agent, and service agent.

[0070] The user layer has a unified service entry point, which is used to receive user requests for large model services and, based on the intelligent decision-making of the host agent, accurately forwards user requests to available service agents.

[0071] There is at least one host agent, which serves as the unified entry point for service scheduling. It integrates a service registry, heartbeat monitor, service controller, and health checker to achieve full lifecycle management of the service agent, specifically:

[0072] The service registry is used to store metadata (including service type, function description, monitoring endpoint, historical operation indicators, etc.) of all registered service agents, build a service directory index, and provide a data foundation for user-level request routing and service status analysis.

[0073] The heartbeat monitor is used to receive incremental heartbeat data sent by the service agent in real time, track the last active timestamp of the service agent, combine historical heartbeat data, analyze service anomaly patterns, and trigger health checks or service isolation processes.

[0074] The service controller is used to send instructions (start, stop, restart, parameter configuration adjustment, etc.) to the service agent, link the service registry to update the service status, drive the smooth transition of the service state machine, and ensure rapid response and self-healing when the service is abnormal.

[0075] The health checker is used to proactively initiate probe requests to the service agent to obtain the actual operating status of the service, verify the anomalies detected by the heartbeat monitor, and provide "secondary confirmation" for the service controller's decision-making. The deep probe requests initiated by the health checker of the host agent, in addition to obtaining the internal status and key dependency status of the service, can also collect specific operating indicators (such as the generation queue length of the text generation service and the knowledge base hit rate of the intelligent question answering service) according to different service types, further improving the accuracy of service anomaly diagnosis.

[0076] The service agent comprises multiple entities, serving as the unit that actually provides the large-scale model service functionality. It integrates a registration module, a heartbeat module, a control interface module, and a health check module, achieving a closed loop between "functional services" and "status reporting," specifically:

[0077] The registration module is used to submit a "semantic service description" (including service name, functional boundaries, SLA commitments, etc.) and a "standardized monitoring interface" (heartbeat / health check endpoint definition) to the service registry of the host agent when the service starts, thus completing the service "admission" process;

[0078] The heartbeat module is used to send incremental heartbeat data (containing only changed indicators) to the host agent heartbeat monitor at the configured period, carrying out real-time reporting of "service liveness status" and "key operating indicators";

[0079] The control interface module is used to receive instructions from the service controller of the host agent, execute service lifecycle operations, and provide feedback on the operation results, thereby supporting the host agent in precise control over the service status.

[0080] The health check module is used to respond to the probe requests of the host agent health checker and return "deep running status" (such as business logic health, resource leak detection, etc.) to supplement the heartbeat module's "lightweight monitoring".

[0081] This system also includes:

[0082] A service registration mechanism, used by the service agent to register service capabilities with the host agent, includes:

[0083] (1) Standardized representation of functional description information, including semantic description of service capabilities and definition of monitoring interfaces;

[0084] (2) Automatic discovery of monitoring endpoints;

[0085] (3) Metadata management of service capabilities;

[0086] A heartbeat monitoring mechanism is used by the service agent to periodically send heartbeat signals, including:

[0087] (1) The service agent periodically sends heartbeat signals containing incremental update metrics;

[0088] (2) The host agent tracks the last active time and parses incremental data;

[0089] (3) Automatically detect abnormally terminated services, significantly reducing monitoring data transmission overhead;

[0090] Dynamic directory management, used by the host agent to update or manage the available service directory based on monitoring status, includes:

[0091] (1) Real-time assessment of service health status based on fine-grained state machine;

[0092] (2) Automatic isolation and status marking of abnormal services;

[0093] (3) Automatic detection of service recovery and smooth state migration.

[0094] The specific implementation of directory management includes:

[0095] (1) Real-time health status assessment

[0096] A. The host agent sends a request to the health check endpoint of the service agent;

[0097] B. The service agent returns a health status containing operational metrics;

[0098] C. The host agent determines the true state of the service based on the response.

[0099] (2) Main Service Control Process

[0100] A. Send start / stop / restart commands to the control endpoint of the target service;

[0101] B. The service agent executes the requested operation and returns the result;

[0102] C. The host agent records the operation results and updates the service status.

[0103] (3) State transition rules

[0104] A. New Registration Service → Pending Inspection Status

[0105] B. Check passed → Health status

[0106] C. Heartbeat Loss → Pending Confirmation

[0107] D. Confirm an anomaly → Isolate state

[0108] E. Resume inspection → pending inspection status.

[0109] In addition, this embodiment also provides a service monitoring method for this system, including the following steps:

[0110] In step (1), the service agent registers service information containing semantic capability descriptions with the host agent.

[0111] In step (2), the service agent periodically sends incremental update heartbeat messages to the host agent;

[0112] In step (3), the host agent dynamically adjusts service routes through the intelligent routing decision engine;

[0113] In step (4), the host agent manages service state transitions based on a fine-grained state machine.

[0114] In step (5), the host agent controls the abnormal service to perform a recovery operation.

[0115] like Figure 2 As shown, in this embodiment, the registration module in the service agent executes the service registration process, including:

[0116] Step S101: The service agent is started, triggering the registration process;

[0117] Step S102: Collect service metadata (service name, function description, service type, version number, etc.) and monitoring endpoint information (network addresses of heartbeat endpoint, control endpoint, health check endpoint, etc.).

[0118] Step S103: Construct a standardized registration request (including a unique service identifier, functional semantic description, network addresses of each monitoring endpoint, initial operating metrics, etc.) and send it to the host Agent;

[0119] Step S104: After receiving the registration request, the host agent performs a dual verification of "legitimacy + integrity", including checking whether the service metadata conforms to the system specifications, verifying the accessibility of the monitoring endpoint, ensuring that the registration request contains the necessary fields, and matching the system's preset "service type - monitoring dimension" mapping.

[0120] Step S105: After successful verification, the host agent updates the service catalog information; that is, the host agent writes the metadata, monitoring endpoints, and initial status of the service agent into the service registry, establishes a service index, associates monitoring dimensions, and marks the initial status (to be checked).

[0121] Step S106: The host agent sends the registration result back to the service agent, including monitoring configuration parameters (heartbeat cycle, heartbeat index range, health check trigger conditions, etc.), to guide the service agent to report the status in a standardized manner.

[0122] In this embodiment, the heartbeat module of the service agent, together with the heartbeat monitor, the service controller, and the health checker of the host agent, collaboratively execute the service heartbeat control process, including:

[0123] (1) Function Agent initializes the heartbeat timer;

[0124] (2) Construct a heartbeat message;

[0125] (3) Send to the host Agent via a persistent connection;

[0126] (4) The host agent receives and updates the last active timestamp;

[0127] (5) Analyze indicator data to detect abnormal patterns;

[0128] (6) If no heartbeat is received beyond the threshold, a health check is triggered.

[0129] like Figure 3 As shown, the specific steps are as follows:

[0130] Step S201: The service agent initializes heartbeat information, sets the heartbeat sending interval, and clarifies the range of incremental running data that needs to be reported;

[0131] Step S202: Construct a heartbeat message; that is, according to the initial configuration, collect incremental operation indicators (such as changes in response latency, changes in error rate, etc.) and encapsulate them into a standardized heartbeat message (including a unique service identifier, incremental indicator data, heartbeat sending timestamp, etc.).

[0132] Step S203: Send the heartbeat message to the heartbeat monitor of the host agent through a persistent network connection (such as HTTP long connection, MQTT, etc.);

[0133] Step S204: After receiving the heartbeat message, the host agent updates the "last active time" of the service agent in the service registry and stores incremental indicator data;

[0134] Step S205: Based on the historical incremental indicators stored, start the "multi-dimensional anomaly detection model" to analyze indicator anomalies (identify business performance anomalies by comparing with preset thresholds) and behavioral anomalies (identify service agent failures by analyzing heartbeat message time intervals and data integrity).

[0135] Step S206: Combine the last active timestamp with the heartbeat timeout threshold configured in the system to determine whether the abnormal in-depth processing procedure is triggered. If no timeout occurs, proceed to step S207; if a timeout occurs, proceed to step S208.

[0136] Step S207: If the heartbeat timestamp has not expired and the metric analysis shows no abnormalities, the host Agent marks the service as "healthy" in the service registry, updates the "most recent uptime", and includes the service in the candidate set of the "intelligent routing decision engine".

[0137] Step S208: If the heartbeat times out, the host agent triggers the health checker and sends a deep probe request to the "health check endpoint" of the service agent to obtain the internal state of the service and the state of key dependencies.

[0138] Step S209: If the health check confirms that the service is abnormal, the service controller of the host agent sends an instruction to the "control interface" of the service agent (preferably attempting a soft reboot). If the soft reboot fails, the service is marked as "isolated" and removed from the service directory, while recording the fault log and recovery operation.

[0139] As an optimization of this embodiment, the service directory index constructed by the service registry of the host agent supports classification by "service type and function tag", providing data support for intelligent routing of the unified entry point of user layer services. The intelligent routing decision engine comprehensively considers multiple factors such as service health, load status, and performance indicators to calculate service priority scores and match the optimal service agent for user requests.

[0140] The semantic service description submitted by the registration module of the service agent includes detailed descriptions of service capabilities (such as the maximum number of characters that can be generated by the text generation service, the supported sentiment categories for the sentiment analysis service, etc.), enabling the host agent to perceive service capabilities from the perspective of functional characteristics. Combined with operational status monitoring data, this achieves dynamic observability of service capabilities.

[0141] The incremental heartbeat information sent by the heartbeat module of the service agent only includes the operating indicators that have changed compared to the last time. Compared with the traditional full heartbeat mechanism, it can significantly reduce the amount of monitoring data transmission (actual tests show that the amount of data transmission can be reduced by more than 60%). While ensuring real-time performance, it effectively reduces the occupation of network bandwidth and system computing resources.

[0142] In this embodiment, the host agent manages the state of the service agent using a fine-grained state machine mechanism, specifically including:

[0143] (1) Real-time health status assessment combined with heart rate increment data and active detection results;

[0144] (2) Service control processes support smooth state transitions, such as gradual recovery attempts in an isolated state;

[0145] (3) The state transition rules reflect fine-grained management;

[0146] A. Newly registered service → Pending inspection status (Perform multi-dimensional initialization checks)

[0147] B. Check passed → Health status (included in the smart routing candidate set)

[0148] C. Heartbeat lost → Pending confirmation status (incremental data retransmission mechanism initiated)

[0149] D. Confirm anomaly → Isolate (maintain basic communication channels for recovery)

[0150] E. Resume inspection → Pending inspection status (execute differentiated re-inspection process)

[0151] Specifically, it defines multiple states such as "pending inspection - healthy - pending confirmation - isolated - recovering", sets clear transition conditions and timeout thresholds for each state, and supports smooth migration of service states. For example, when the service changes from the "healthy" state to "pending confirmation", the host agent first tries to retransmit incremental data instead of directly marking it as abnormal. After entering the "isolated state", the basic communication channel is still reserved for sending recovery instructions to avoid service jitter caused by state jumps.

[0152] The decision model of the intelligent routing decision engine described in this embodiment supports dynamic adjustment of weights according to different application scenarios. In content generation scenarios with high real-time requirements, it prioritizes services with low response latency; in data analysis scenarios, it focuses on selecting services with low resource utilization. It also supports custom strategies (such as allocating service nodes with higher SLAs to paid users) to achieve optimal utilization of service resources.

[0153] like Figure 1 As shown, to further illustrate the system modules in this solution, the system architecture consists of three levels: the user layer, the host agent layer, and the service agent layer.

[0154] User layer: Receives user requests through the "unified service entry point", relies on the host agent intelligent routing decision engine to shield the deployment details of the underlying service agents, provides users with a one-stop service call experience, and accurately forwards requests to available service agents.

[0155] Host Agent Layer: Integrates a service registry, heartbeat monitor, health checker, service controller, and intelligent routing decision engine. The service registry stores agent metadata and builds a service directory index; the heartbeat monitor receives incremental heartbeat data, tracks service status, and analyzes anomalies; the service controller sends commands to manage service lifecycles and update status; the health checker proactively probes the true state of services; and the intelligent routing decision engine calculates service priorities based on multi-dimensional metrics and matches the optimal service agent.

[0156] Service Agent Layer: Each functional agent integrates a registration module, a heartbeat module, a control interface module, and a health check module. The registration module submits a semantic service description and a standardized monitoring interface; the heartbeat module sends incremental heartbeat data periodically; the control interface module receives and executes instructions from the host agent; and the health check module provides feedback on the deep operational status of the service, achieving a closed loop between functional services and status reporting.

[0157] like Figure 2As shown below, as a further explanation of the service registration process in this system, service registration is the foundation for service agents to access the system and achieve dynamic observability. The steps are as follows:

[0158] Step S101: The service agent starts, triggering the registration process and transitioning from an independent running state to the system ecosystem preparation stage.

[0159] Step S102: Collect service metadata (name, function description, type, version number, etc.) and monitoring endpoint information (heartbeat, control, health check endpoint network addresses) to provide data for the host agent to identify service capabilities and incorporate them into the monitoring system.

[0160] Step S103: Encapsulate the metadata and endpoint information into a standardized registration request (including service unique identifier, functional semantic description, endpoint address, initial operation indicators, etc.) and actively send it to the host agent to realize the first handshake between the service agent and the host agent.

[0161] Step S104: After receiving the request, the host agent verifies the legality (whether it conforms to the specifications and whether the endpoint is accessible) and completeness (whether it contains the necessary fields and matches the monitoring dimension mapping). If the verification fails, an error code is returned to guide the correction. If it passes, the process proceeds to the next step.

[0162] Step S105: After successful verification, the host agent writes the service agent information into the service registry, establishes a service index (by type and function tag), associates monitoring dimensions (binds each management module of the host agent), and marks the initial state (to be checked), providing a data foundation for subsequent monitoring and scheduling.

[0163] Step S106: The host agent sends the registration result back to the service agent, including monitoring configuration parameters such as heartbeat cycle, heartbeat index range, and health check trigger conditions, to guide the service agent to report the status in a standardized manner. The service agent starts sending heartbeats and listening to endpoints according to the rules, and officially connects to monitoring and control.

[0164] like Figure 3 As shown below, as a further explanation of the service heartbeat control process in this solution, service heartbeat control is the core logic for realizing dynamic perception of service status and intelligent handling of anomalies. The process is as follows:

[0165] Step S201: After the service agent completes registration, it starts the heartbeat management module, sets the heartbeat sending interval (e.g., 5 seconds / time) according to the monitoring configuration returned by the host agent, and clarifies the range of incremental running data to be reported (e.g., only the changed items), laying the foundation for lightweight and efficient heartbeat reporting.

[0166] Step S202: According to the initial configuration, collect incremental operation indicators (such as response latency and error rate changes), encapsulate them into standardized heartbeat messages containing a unique service identifier, incremental indicator data, and sending timestamp, to achieve low-overhead, high-value heartbeat reporting.

[0167] Step S203: Send the heartbeat message to the host Agent heartbeat monitor through a persistent network connection (such as an HTTP long connection) to ensure real-time and reliable data transmission.

[0168] Step S204: After receiving the message, the host agent updates the "last active time" of the service agent in the service registry, stores incremental indicator data, and monitors the service's survival status and operating trend in real time.

[0169] Step S205: Based on historical incremental indicators, start a multi-dimensional anomaly detection model to analyze indicator anomalies (identify business performance anomalies by comparing thresholds) and behavioral anomalies (identify Agent failures by analyzing message intervals and integrity), accurately locate service anomalies, and deeply apply the dynamic observability of service capabilities.

[0170] Step S206: Combine the "last active timestamp" with the heartbeat timeout threshold (e.g., if no heartbeat is received for 30 seconds, it is considered abnormal) to determine whether to trigger in-depth abnormal processing. If no timeout occurs, proceed to step S207; if a timeout occurs, proceed to step S208.

[0171] Step S207: If the heartbeat has not timed out and the indicators are normal, the host agent marks the service as "healthy", updates the "most recent uptime", and includes the service in the intelligent routing candidate set to ensure user request scheduling.

[0172] Step S208: Heartbeat timeout. The host agent triggers the health checker and sends a deep probe request to the service agent health check endpoint to obtain the status of the service's internal (business threads, memory) and key dependencies (large model inference engine) to distinguish between network jitter and real failures.

[0173] Step S209: If the health check confirms the abnormality, the service controller sends an instruction to the service agent control interface (with priority to soft reboot). If the soft reboot fails, it is marked as "isolated" and removed from the service catalog. The fault log and recovery operation are recorded to realize the self-healing of abnormal services and perform fine-grained service state machine management.

[0174] The above description is merely illustrative of the embodiments of the present invention and is not intended to limit the present invention. For those skilled in the art, any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A service monitoring and management system based on distributed agents, characterized in that, The architecture includes a three-layer structure: user layer, host agent, and service agent. The user layer has a unified service entry point, which is used to receive user requests for large model services and, based on the intelligent decision-making of the host agent, accurately forwards user requests to available service agents. There is at least one host agent, which serves as the unified entry point for service scheduling. It integrates a service registry, heartbeat monitor, service controller, and health checker to achieve full lifecycle management of the service agent, specifically: The service registry is used to store metadata of all registered service agents, build a service directory index, support classification by "service type and function tag", and provide a data foundation for user-level request routing and service status analysis; The heartbeat monitor is used to receive incremental heartbeat data sent by the service agent in real time, track the last active timestamp of the service agent, combine historical heartbeat data, analyze service anomaly patterns, and trigger health checks or service isolation processes. The service controller is used to send instructions to the service agent, link the service registry to update the service status, and drive the smooth transition of the service state machine. This includes the host agent first attempting to retransmit incremental data when the service changes from "healthy" to "pending confirmation". After entering the "isolation state", the basic communication channel is reserved for resuming instruction sending, avoiding service jitter and ensuring rapid response and self-healing in the event of service abnormalities. The health checker is used to proactively check the health status of the service: the deep probing request initiated by the health checker of the host agent can not only obtain the internal status and key dependency status of the service, but also collect specific operating indicators according to different service types, including the generation queue length of the text generation service and the knowledge base hit rate of the intelligent question answering service. The service agent comprises multiple agents, serving as the unit that actually provides the large-scale model service functionality. These agents integrate a registration module, a heartbeat module, a control interface module, and a health check module, specifically: The registration module is used to register service information containing semantic capability descriptions with the host agent. The semantic service descriptions contain descriptions of service capabilities, enabling the host agent to perceive service capabilities from the perspective of functional characteristics. Combined with runtime monitoring data, this achieves dynamic observability of service capabilities. The heartbeat module is used to periodically send incrementally updated heartbeat messages to the host agent, carrying only the indicator data that has changed compared to the last time in the heartbeat message; The control interface module is used to receive instructions from the service controller of the host agent and execute service lifecycle operations; The health check module is used to provide the health status and operational indicators of this service; Also includes: A service registration mechanism is used for the service agent to register service capabilities with the host agent. In the service registration mechanism, after receiving the registration request, the host agent performs a dual verification of "legitimacy + completeness", including checking whether the service metadata conforms to the system specifications, verifying the accessibility of the monitoring endpoint, ensuring that the registration request contains necessary fields, and matching the system's preset "service type-monitoring dimension" mapping. After the verification is successful, the host agent updates the service catalog information and sends the registration result back to the service agent, including monitoring configuration parameters, to guide the service agent to report the status in a standardized manner. The heartbeat monitoring mechanism is used by the service agent to periodically send heartbeat signals and send heartbeat messages to the heartbeat monitor of the host agent through a persistent network connection. Dynamic directory management is used by the host agent to update or manage the available service directory based on the monitoring status. It is based on a fine-grained state machine for real-time evaluation of service health status, automatic isolation and status marking of abnormal services, automatic detection of service recovery and smooth state migration. The state transition rules are: newly registered service → pending inspection, inspection passed → healthy status, heartbeat lost → pending confirmation, confirmed abnormality → isolated status, recovery inspection → pending inspection.

2. The service monitoring and management system based on distributed agents according to claim 1, characterized in that, The service monitoring method of the system includes the following steps: In step (1), the service agent registers service information containing semantic capability descriptions with the host agent; In step (2), the service agent periodically sends incremental update heartbeat messages to the host agent; In step (3), the host agent dynamically adjusts service routes through the intelligent routing decision engine; In step (4), the host agent manages service state transitions based on a fine-grained state machine. In step (5), the host agent controls the abnormal service to perform a recovery operation.

3. A service monitoring and management system based on distributed agents according to claim 1 or 2, characterized in that, The registration module in the service agent executes the service registration process, including: Step S101: The service agent is started, triggering the registration process; Step S102: Collect service metadata and monitoring endpoint information; Step S103: Construct a standardized registration request and send it to the host Agent; Step S104: After receiving the registration request, the host Agent performs a dual verification of "legitimacy + integrity"; Step S105: After successful verification, the host agent updates the service catalog information; Step S106: The host agent sends the registration result back to the service agent, including monitoring configuration parameters, to guide the service agent to report the status in a standardized manner.

4. A service monitoring and management system based on distributed agents according to claim 1 or 2, characterized in that, The heartbeat module of the service agent, together with the heartbeat monitor of the host agent, the service controller, and the health checker, collaboratively executes the service heartbeat control process, including: Step S201: The service agent initializes heartbeat information, sets the heartbeat sending interval, and clarifies the range of incremental running data that needs to be reported; Step S202: Construct a heartbeat message; Step S203: Send the heartbeat message to the heartbeat monitor of the host agent through a persistent network connection; Step S204: The host agent updates the heartbeat timestamp; Step S205: The host agent detects anomalies in the analyzed data; Step S206: Combine the last active timestamp with the heartbeat timeout threshold configured in the system to determine whether the abnormal in-depth processing procedure is triggered. If no timeout occurs, proceed to step S207; if a timeout occurs, proceed to step S208. Step S207: If the heartbeat timestamp has not expired and the metric analysis shows no abnormalities, the host Agent marks the service as "healthy" in the service registry, updates the "most recent uptime", and includes the service in the candidate set of the "intelligent routing decision engine". Step S208: The host agent checks the service health status; Step S209: The host agent initiates service control.

5. A service monitoring and management system based on distributed agents according to claim 1, characterized in that, The service directory index built by the service registry of the host agent supports classification by "service type and function tag", providing data support for intelligent routing of the unified entry point of user layer services. The intelligent routing decision engine comprehensively considers multiple factors such as service health, load status, and performance indicators to calculate service priority scores and match the optimal service agent for user requests.

6. The service monitoring and management system based on distributed agents according to claim 1, characterized in that, The incremental heartbeat information sent by the heartbeat module of the service agent only includes operational metrics that have changed compared to the previous one.

7. A service monitoring and management system based on distributed agents according to claim 1 or 2, characterized in that, The host agent manages the state of the service agent using a fine-grained state machine mechanism, specifically including: (1) Real-time health status assessment combined with heart rate increment data and active detection results; (2) The service control process supports smooth state migration, including gradual recovery attempts in isolation states; (3) The state transition rules reflect fine-grained management.

8. A service monitoring and management system based on distributed agents according to claim 2, characterized in that, The decision model of the intelligent routing decision engine supports dynamic adjustment of weights according to different application scenarios. In content generation scenarios with high real-time requirements, it prioritizes services with low response latency.

Images