Service monitoring and management system based on distributed Agent

Abstract

The invention relates to the cross technical field of a distributed artificial intelligence system and micro-service governance, in particular to a service monitoring and management system based on a distributed Agent, which adopts a three-level architecture of a user layer, a host Agent layer and a service Agent layer: the user layer is provided with a unified entrance forwarding request; the host Agent layer is integrated with a service registry and other modules to realize global management and control; the service Agent layer comprises a registration module and the like to complete function and state feedback. Through four innovations of a dynamic observability model, an incremental heartbeat protocol, a fine-grained state machine and an intelligent routing engine, dynamic binding of a service function and a state is realized. The scheme has the advantages that the service observability is improved, and the problem positioning efficiency is optimized; the monitoring data transmission quantity is reduced; the service interruption time is shortened, and the availability is improved; and the method is suitable for scenes such as intelligent customer service and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed artificial intelligence systems and microservice governance, and particularly relates to a service monitoring and management system based on distributed Agents. BACKGROUND

[0002] With the rapid evolution of large model technology, functional Agents based on large models show a development trend of distribution, specialization and fragmentation. These functional Agents are usually deployed in heterogeneous computing environments and have characteristics such as strong dynamics, short life cycle and non-uniform interfaces.

[0003] The core contradiction faced by the current large model application ecosystem is that functional requirements are increasingly integrated, while service implementation is increasingly fragmented. Specifically, on the one hand, end users expect one-stop intelligent service experience; on the other hand, developers tend to build small Agents with single functions due to limitations of computing resources and technical expertise. This contradiction leads to three major pain points in existing technologies: 1. Functional Agents are scatteredly deployed, lacking a unified service directory and state view, making it difficult for developers to grasp the overall service state; 2. Agent services are highly dynamic, and traditional static service discovery mechanisms cannot adapt to frequent online and offline changes; 3. Service exceptions are difficult to discover and handle in a timely manner, and the scope of the impact is uncontrollable.

[0004] Existing solutions have failed to solve the core problem of "dynamic binding of service function availability", i.e., the real-time association of service function exposure with actual running state. The present application proposes an innovative solution to this technical gap. SUMMARY

[0005] The present application aims to overcome the problems of the prior art and provides a service monitoring and management system based on distributed Agents to solve the technical problems of separation of service function description and running state monitoring, difficulty in accurately assessing service capability, large monitoring overhead of traditional full heartbeat mechanism affecting system performance, coarse service state management granularity, service interruption caused by state migration, and single service routing decision dimension unable to adapt to complex heterogeneous environment scheduling requirements in existing large model service monitoring and management.

[0006] The above object is achieved by the following technical solution: A service monitoring and management system based on distributed Agents, comprising a user layer, a host Agent and a service Agent three-layer architecture, wherein: The user layer is equipped with a unified service entrance for receiving user requests for large model services and accurately forwarding user requests to available service agents based on the intelligent decision-making of the host agent. There is at least one host agent, which serves as a unified entry point for service scheduling, integrating the service registry, heartbeat monitor, service controller, and health checker to achieve full life cycle management of the service agent, specifically: The service registry is used to store metadata of all registered service agents, build a service directory index, and provide a data basis for user layer request routing and service status analysis; The heartbeat monitor is used to receive the incremental heartbeat data sent by the service agent in real time, track the last active timestamp of the service agent, analyze the service abnormality pattern in combination with historical heartbeat data, and trigger the health check or service isolation process; The service controller is used to send instructions to the service agent, link the service registry to update the service status, drive the smooth migration of the service state machine, and ensure rapid response and self-healing when the service is abnormal; The health checker is used to proactively check the health status of the service: There are multiple service agents, which are the units that actually provide large model service functions, integrating registration module, heartbeat module, control interface module, and health check module. Specifically: The registration module is used to register service information including semantic capability description with the host agent; The heartbeat module is used to periodically send incrementally updated heartbeat messages to the host Agent; The control interface module is used to receive instructions from the service controller of the host agent and perform service life cycle operations; The health check module is used to provide the health status and operation indicators of this service; Also includes: A service registration mechanism, used for the service agent to register service capabilities with the host agent; Heartbeat monitoring mechanism, used for the service agent to send heartbeat signals regularly; Dynamic catalog management, used by the host agent to update or manage the available service catalog based on the monitoring status; Furthermore, the service monitoring method of the system includes the following steps: Step (1) the service agent registers the service information including the semantic capability description with the host agent; Step (2) the service agent periodically sends incremental updated heartbeat messages to the host agent; Step (3) The host Agent dynamically adjusts service routing through an intelligent routing decision engine. Step (4) The host Agent manages service state transitions based on a fine-grained state machine. Step (5) The host Agent controls abnormal services to perform recovery operations.

[0007] Further, the registration module in the service Agent performs a service registration process, including: Step S101: The service Agent starts and triggers a 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 the host Agent receives the registration request, it performs "legitimacy + integrity" dual verification. Step S105: After verification, the host Agent updates service directory information. Step S106: The host Agent feeds back the registration result to the service Agent, including monitoring configuration parameters, to guide the service Agent to report the state regularly.

[0008] Further, the heartbeat module of the service Agent and the heartbeat monitor, the service controller, and the health checker of the host Agent cooperate to perform a service heartbeat control process, including: Step S201: The service Agent initializes heartbeat information, sets the heartbeat sending interval, and specifies the range of incremental running data that needs to be reported. Step S202: Construct a heartbeat message packet. Step S203: Send the heartbeat packet 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 analyzes data to detect abnormalities. Step S206: Combine the last active timestamp with the system-configured heartbeat timeout threshold to determine whether to trigger an abnormal deep processing process. If it is not overdue, go to Step S207; if it is overdue, go to Step S208. Step S207: If the heartbeat timestamp is not overdue and the index analysis is normal, the host Agent marks the service as "healthy state" in the service registration table, updates the "last normal running time", 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.

[0009] Furthermore, the service catalog index constructed by the service registry of the host agent supports classification by "service type, function label", providing data support for the intelligent routing of the unified entrance of user-level services. The intelligent routing decision engine integrates multi-dimensional factors such as service health, load status, performance indicators, etc., calculates the service priority score, and matches the optimal service agent for the user request.

[0010] Furthermore, the semantic service description submitted by the registration module of the service agent includes a detailed description of the service capabilities, so that the host agent can perceive the service capabilities from the functional characteristics dimension and realize the dynamic observability of the service capabilities in combination with the operation status monitoring data.

[0011] Furthermore, the incremental heartbeat information sent by the heartbeat module of the service agent only includes the operating indicators that have changed compared with the last time.

[0012] Furthermore, 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 combining heart rate increment data and active detection results; (2) The service control process supports smooth state migration, such as gradual recovery attempts in an isolated state; (3) State transition rules reflect fine-grained management.

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

[0014] Furthermore, the deep detection request initiated by the health checker of the host agent, in addition to obtaining the internal status of the service and the status of key dependencies, can also be customized to collect specific operating indicators according to different service types.

[0015] The distributed agent-based service monitoring and management system provided by this invention utilizes an innovative host-agent architecture to construct a novel monitoring and management system for large-scale 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, enabling the host agent to intelligently aggregate available service functions and provide a unified and reliable service portal for upper-layer applications. This technology is widely applicable to large-scale application scenarios such as intelligent customer service, content generation, and data analysis, effectively resolving the management challenges associated with the fragmentation of functional agents. It also offers the following advantages: 1. Dynamic observability model for service capabilities: This standardizes service function description and operational status monitoring through standardized interfaces. During the registration phase, the functional agent must provide a semantic capability description (such as service type, processing scope, and response time) and standardized monitoring indicator interfaces (such as CPU usage, error rate, and concurrency). This allows the host agent to fully perceive service capabilities from both functional characteristics and operational status. For example, in an intelligent customer service scenario, the Q&A agent must register the "sentiment analysis" function tag and business indicators such as "intent recognition accuracy" to enable linked evaluation of functional availability and performance indicators.

[0016] 2. Efficient heartbeat protocol based on incremental updates: The service agent only carries metrics that have changed since the last heartbeat (for example, reporting specific values ​​when response latency exceeds a threshold). The host agent then rapidly updates the service status through incremental parsing. Field tests have shown that this mechanism can reduce monitoring data transmission by over 60%, making it suitable for edge computing environments with limited network bandwidth. It significantly reduces monitoring overhead while ensuring real-time performance.

[0017] 3. Fine-grained service state machine management: Define multiple states, including "pending inspection - healthy - pending confirmation - isolated - recovering," along with 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 "isolated" state, the basic communication channel is retained for sending recovery commands, avoiding service jitter and supporting smooth service state transition and automatic recovery.

[0018] 4. Intelligent service routing decision engine: This engine integrates multiple factors, including service health, load, and performance metrics, with a built-in decision model and dynamically adjusts weights. For content generation scenarios with high real-time requirements, it prioritizes services with low response latency. For data analysis scenarios, it prioritizes services with low resource utilization. Custom policies are also supported, such as allocating high-SLA service nodes to paying users, ensuring optimal utilization of service resources.

[0019] The above-mentioned innovative synergy solves the contradiction between functional fragmentation and demand integration in the large-scale model service ecosystem. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 A module block diagram of a service monitoring and management system based on a distributed Agent according to the present application; Figure 2 A service registration flowchart in a service monitoring and management system based on a distributed Agent according to the present application; Figure 3 A service heartbeat control flowchart in a service monitoring and management system based on a distributed Agent according to the present application. DETAILED DESCRIPTION

[0021] The present application will be further described in detail below according to the accompanying drawings and embodiments. The described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0022] The present application provides a service monitoring and management system based on a distributed Agent. Specifically, three technical mechanisms are designed: first, a semantic registration mechanism of service capability, each functional Agent reports not only basic service information but also complete semantic capability description and service level commitment when starting; second, a two-way health perception mechanism, a multi-dimensional service health evaluation model is constructed by combining passive heartbeat and active detection; most importantly, a dynamic service binding mechanism, the host Agent dynamically adjusts the exposed service function set according to real-time monitoring data, ensuring that only healthy and available functional Agents are included in the service directory.

[0023] As shown in Figure 1 The present application provides a service monitoring and management system based on a distributed Agent, which includes a user layer, a host Agent, and a service Agent three-layer architecture, wherein: The user layer is provided with a unified service entrance for receiving user's calling demand for large model services, and relying on the intelligent decision of the host Agent, accurately forwarding the user request to the available service Agent; The host Agent is at least one, serving as a unified entrance for service scheduling, integrating a service registration table, a heartbeat monitor, a service controller, and a health checker, and realizing full life cycle management of the service Agent, specifically: The service registration table is used to store the metadata (including service type, function description, monitoring endpoint, historical running index, etc.) of all registered service Agents, build a service directory index, and provide data basis for user layer request routing and service state analysis; The heartbeat monitor is used to receive the 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 abnormality patterns, and trigger health checks or service isolation processes; 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 migration of the service state machine, and ensure rapid response and self-healing when the service is abnormal; The health checker is used to proactively initiate probe requests to the service agent to obtain the actual operating status of the service, verify anomalies discovered by the heartbeat monitor, and provide "secondary confirmation" for the service controller's decision. The deep probe request initiated by the host agent's health checker not only obtains the internal status of the service and the status of key dependencies, but can also be customized to 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) based on different service types, further improving the accuracy of service anomaly diagnosis. There are multiple service agents, which are the units that actually provide large model service functions. They integrate registration modules, heartbeat modules, control interface modules, and health check modules to achieve a closed loop of "functional services" and "status reporting". Specifically: The registration module is used to submit the "semantic service description" (including service name, functional boundaries, SLA commitment, etc.) and "standardized monitoring interface" (heartbeat / health check endpoint definition) to the host agent's service registry when the service is started, completing the service "admission" process; The heartbeat module is used to send incremental heartbeat data (including only change indicators) to the host agent heartbeat monitor according to the configured period, carrying the real-time reporting of "service survival status" and "key operation indicators"; The control interface module is used to receive instructions from the service controller of the host agent, execute service lifecycle operations, and feedback the operation results, so as to support the host agent to accurately control the service status; The health check module responds to the host agent's health checker's probe requests and returns "deep running status" (such as business logic health, resource leak detection, etc.), supplementing the "lightweight monitoring" of the heartbeat module. The system also includes: The service registration mechanism is used for the service agent to register service capabilities with the host agent, including: (1) Standardized representation of functional description information, including semantic description of service capabilities and monitoring interface definition; (2) Automatic discovery of monitoring endpoints; (3) Metadata management of service capabilities; Heartbeat monitoring mechanism, for the service Agent to send heartbeat signals periodically, including: (1) The service Agent sends heartbeat signals containing incremental update indicators periodically; (2) The host Agent tracks the last active time and parses incremental data; (3) Automatically detect abnormal terminated services, greatly reduce monitoring data transmission overhead; Dynamic directory management, for the host Agent to update or manage available service directory according to monitoring status, including: (1) Real-time evaluation of service health status based on fine-grained state machine; (2) Automatic isolation and state marking of abnormal services; (3) Automatic detection of service recovery and state smooth migration.

[0024] Directory management specific implementation includes: (1) Real-time evaluation of health status A. The host Agent sends a request to the health check endpoint of the service Agent; B. The service Agent returns the health status containing running indicators; C. The host Agent judges the real status of the service according to the response.

[0025] (2) Main process of service control A. Send operation start / stop / restart instructions to the control endpoint of the target service; B. The service Agent executes the requested operation and returns the result; C. The host Agent records the operation result and updates the service status.

[0026] (3) State transition rules A. New registered service→to-be-checked state B. Check passed→healthy state C. Heartbeat loss→to-be-confirmed state D. Confirm abnormal→isolated state E. Recovery check→to-be-checked state.

[0027] In addition, the embodiment also provides a service monitoring method of the system, including the following steps: Step (1) The service Agent registers service information containing semantic capability description to the host Agent; Step (2) The service Agent sends incremental update heartbeat messages to the host Agent periodically; Step (3) The host Agent dynamically adjusts service routing through an intelligent routing decision engine. Step (4) The host Agent manages service state transition based on fine-grained state machine; Step (5) The host Agent controls abnormal services to perform recovery operations.

[0028] As Figure 2 shown, the service registration process performed by the registration module in the service Agent in this embodiment includes: Step S101: The service Agent is started, triggering the registration process; Step S102: Collect service metadata (service name, function description, service type, version number, etc.) and monitoring endpoint information (network address of heartbeat endpoint, control endpoint, health check endpoint, etc.); Step S103: Construct a standardized registration request (containing service unique identifier, function semantic description, network address of each monitoring endpoint, initial running index, etc.) and send it to the host Agent; Step S104: After receiving the registration request, the host Agent performs "legality + integrity" dual verification, including checking whether the service metadata conforms to the system specification, verifying the accessibility of the monitoring endpoint, ensuring that the registration request contains necessary fields, and matching the "service type-monitoring dimension" mapping preset by the system; Step S105: After verification, the host Agent updates the service directory information; that is, the host Agent writes the metadata, monitoring endpoint, and initial state of the service Agent into the service registration table, establishes service index, associates monitoring dimension, and marks the initial state (to be checked); Step S106: The host Agent feeds back the registration result to the service Agent, including monitoring configuration parameters (heartbeat period, heartbeat index range, health check trigger condition, etc.), guiding the service Agent to report state in a standard manner.

[0029] The heartbeat module of the service Agent in this embodiment cooperates with the heartbeat monitor, the service controller, and the health checker of the host Agent to perform the service heartbeat control process, which includes: (1) The function Agent initializes the heartbeat timer; (2) Construct a heartbeat message packet; (3) Send it to the host Agent through a persistent connection; (4) The host Agent updates the last active timestamp after receiving it; (5) Analyze the index data to detect abnormal patterns; (6) Trigger health check if no heartbeat is received beyond the threshold.

[0030] AsFigure 3 The specific steps are as follows: Step S201: The service Agent initializes heartbeat information, sets heartbeat sending interval, and specifies the range of incremental running data to be reported; Step S202: Construct a heartbeat message packet; that is, collect incremental running indicators (such as response delay change and error rate change) according to the initialization configuration, and encapsulate them into a standardized heartbeat packet (containing service unique identifier, incremental indicator data, and heartbeat sending timestamp); Step S203: Send the heartbeat packet to the heartbeat monitor of the host Agent through a persistent network connection (such as HTTP long connection, MQTT, etc.); Step S204: After receiving the heartbeat packet, the host Agent updates the "last active time" of the service Agent in the service registry and stores the incremental indicator data; Step S205: Based on the stored historical incremental indicators, start a "multi-dimensional anomaly detection model" to analyze indicator anomalies (identify business performance anomalies by comparing preset thresholds) and behavior anomalies (analyze heartbeat packet time interval and data integrity to identify the failure of the service Agent); Step S206: In combination with the last active timestamp and the heartbeat timeout threshold configured by the system, determine whether to trigger an abnormal deepening process. If not, go to step S207; if yes, go to step S208; Step S207: If the heartbeat timestamp is not overdue and the indicator analysis is normal, the host Agent marks the service as "healthy state" in the service registry, updates the "recent normal running time", and includes the service in the candidate set of the "intelligent routing decision engine"; Step S208: If the heartbeat is overdue, the host Agent triggers the health checker to send a deep probe request to the "health check endpoint" of the service Agent to obtain the internal state and key dependency state of the service; Step S209: If the health check confirms that the service is abnormal, the service controller of the host Agent sends an instruction (preferably a soft restart) to the "control interface" of the service Agent. If the soft restart fails, the service is marked as "isolated state" and removed from the service directory, and fault logs and recovery operations are recorded.

[0031] As an optimization of the embodiment, the service directory index constructed by the service registry of the host Agent supports classification according to "service type and function label", provides data support for intelligent routing of the unified entrance of user layer services, and the intelligent routing decision engine calculates the service priority score by comprehensively considering service health degree, load status, performance indicators, and other multi-dimensional factors, so as to match the optimal service Agent for user requests.

[0032] The semantic service description submitted by the registration module of the service agent includes a detailed description of the service capabilities (such as the upper limit of the number of generated words for the text generation service and the supported emotion categories for the sentiment analysis service), so that the host agent can perceive the service capabilities from the perspective of functional characteristics and realize the dynamic observability of the service capabilities in combination with the operation status monitoring data.

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

[0034] In this embodiment, 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 combining heart rate increment data and active detection results; (2) The service control process supports smooth state migration, such as gradual recovery attempts in an isolated state; (3) State transition rules reflect fine-grained management; A. Newly registered service → pending inspection status (performing multi-dimensional initialization inspection) B. Check passed → Healthy status (included in the intelligent routing candidate set) C. Heartbeat lost → pending confirmation (initiate incremental data retransmission mechanism) D. Confirm the abnormality → Isolate the state (keep the basic communication channel for recovery) E. Resume inspection → Waiting for inspection status (perform differentiated re-inspection process) 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 the "pending confirmation" state, the host agent first attempts to retransmit incremental data instead of directly marking an exception; after entering the "isolated state", the basic communication channel is still retained for sending recovery instructions to avoid service jitter caused by state jumps.

[0035] 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, services with low response latency are given priority. In data analysis scenarios, services with low resource utilization are prioritized. Custom strategies are also supported (such as allocating service nodes with higher SLAs to paying users) to achieve optimal utilization of service resources.

[0036] likeFigure 1 As shown in the figure, as a further explanation of the system modules in this solution, the system architecture is divided into three levels: user layer, host agent layer, and service agent layer: User layer: Receives user requests through the "unified service portal", relies on the host agent intelligent routing decision engine, shields the underlying service agent deployment details, provides users with a one-stop service call experience, and accurately forwards requests to available service agents.

[0037] The host agent layer integrates the service registry, heartbeat monitor, health checker, service controller, and intelligent routing decision engine. The service registry stores service agent metadata and builds a service catalog index. The heartbeat monitor receives incremental heartbeat data, tracks service status, and analyzes anomalies. The service controller issues commands to manage the service lifecycle and update status. The health checker proactively detects the actual service status. The intelligent routing decision engine calculates service priorities based on multi-dimensional indicators and matches the optimal service agent.

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

[0039] like Figure 2 As shown in the figure, as a further explanation of the service registration process in this system, service registration is the basis for the service agent to access the system and achieve dynamic observability. The steps are as follows: Step S101: The service agent is started, triggering the registration process, and entering the access system ecosystem preparation stage from the independent operation state.

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

[0041] 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 achieve the first handshake between the service agent and the host agent.

[0042] Step S104: After receiving the request, the host Agent verifies the legality (whether it conforms to the specification, whether the endpoint is accessible) and integrity (whether it contains necessary fields, matches the monitoring dimension mapping) of the service metadata. If the verification fails, an error code is returned to guide correction. If the verification passes, the subsequent process is entered.

[0043] Step S105: After verification, the host Agent writes the service Agent information into the service registry, establishes a service index (by type, function label), 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.

[0044] Step S106: The host Agent feeds back the registration result to the service Agent, including monitoring configuration parameters such as heartbeat period, heartbeat indicator range, and health check trigger conditions, guiding the service Agent to report the state according to the rules. The service Agent starts heartbeat sending and endpoint listening according to the rules, and formally accesses the monitoring and control.

[0045] As shown in Figure 3 , as a further explanation of the service heartbeat control process in the system in this scheme, service heartbeat control is the core logic to achieve dynamic perception of service state and intelligent handling of exceptions. The process is as follows: Step S201: After completing registration, the service Agent starts the heartbeat management module, sets the heartbeat sending interval (such as 5 seconds / time) according to the monitoring configuration returned by the host Agent, and clearly defines the range of incremental running data to be reported (such as only the changed items), laying the foundation for lightweight and efficient heartbeat reporting.

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

[0047] Step S203: Through a persistent network connection (such as HTTP long connection), send the heartbeat message to the host Agent heartbeat monitor, ensuring real-time and reliable data transmission.

[0048] Step S204: After receiving the message, the host Agent updates the "last active time" of the service Agent in the service registry, stores the incremental indicator data, and keeps track of the service survival state and running trend in real time.

[0049] Step S205: Based on historical incremental indicators, start a multi-dimensional anomaly detection model to analyze indicator anomalies (identify business performance anomalies by comparing threshold values) and behavior anomalies (analyze message intervals and integrity to identify Agent failures), accurately locate service anomalies, and deeply apply service capability dynamic observability.

[0050] Step S206: Combine the "last active timestamp" with the heartbeat timeout threshold (e.g. 30 seconds without receiving a heartbeat to determine an abnormality), determine whether to trigger an abnormal deepening process, and if not, proceed to step S207, if yes, proceed to step S208.

[0051] Step S207: Heartbeat is not overdue and indicators are normal, host Agent marks the service as "healthy state", updates the "last normal running time", and includes the service in the intelligent routing candidate set to ensure user request scheduling.

[0052] Step S208: Heartbeat is overdue, host Agent triggers health checker, sends a deep probe request to the service Agent health check endpoint, obtains the service internal (business thread, memory) and key dependency (large model inference engine) state, and distinguishes between network jitter and true failure.

[0053] Step S209: Health check confirms abnormality, service controller sends instructions (preferably soft restart) to the service Agent control interface, and if soft restart fails, marks it as "isolated state" and removes it from the service directory, records fault logs and recovery operations, implements self-healing of abnormal services, and performs fine-grained service state machine management.

[0054] The above only describes the embodiments of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made by those skilled in the art within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A service monitoring and management system based on distributed agent, characterized in that: It includes a three-layer architecture consisting of user layer, host agent, and service agent, where: The user layer is equipped with a unified service entrance for receiving user requests for large model services and accurately forwarding user requests to available service agents based on the intelligent decision-making of the host agent. There is at least one host agent, which serves as a unified entry point for service scheduling, integrating the service registry, heartbeat monitor, service controller, and health checker to achieve full life cycle management of the service agent, specifically: The service registry is used to store metadata of all registered service agents, build a service directory index, and provide a data basis for user layer request routing and service status analysis; The heartbeat monitor is used to receive the incremental heartbeat data sent by the service agent in real time, track the last active timestamp of the service agent, analyze the service abnormality pattern in combination with historical heartbeat data, and trigger the health check or service isolation process; The service controller is used to send instructions to the service agent, link the service registry to update the service status, drive the smooth migration of the service state machine, and ensure rapid response and self-healing when the service is abnormal; The health checker is used to proactively check the health status of the service: There are multiple service agents, which are the units that actually provide large model service functions, integrating registration module, heartbeat module, control interface module, and health check module. Specifically: The registration module is used to register service information including semantic capability description with the host agent; The heartbeat module is used to periodically send incrementally updated heartbeat messages to the host Agent; The control interface module is used to receive instructions from the service controller of the host agent and perform service life cycle operations; The health check module is used to provide the health status and operation indicators of this service; Also includes: A service registration mechanism, used for the service agent to register service capabilities with the host agent; Heartbeat monitoring mechanism, used for the service agent to send heartbeat signals regularly; Dynamic catalog management is used by the host agent to update or manage the available service catalog based on the monitoring status.

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

3. A distributed agent-based service monitoring and management system 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 double verification of "legitimacy + integrity"; Step S105: After verification, the host agent updates the service directory information; Step S106: the host agent feeds back the registration result to the service agent, including monitoring configuration parameters, and instructs the service agent to report status in a standardized manner.

4. A distributed agent-based service monitoring and management system according to claim 1 or 2, characterized in that: The heartbeat module of the service agent collaborates with the heartbeat monitor, the service controller, and the health checker of the host agent to execute a service heartbeat control process, including: Step S201: the service agent initializes heartbeat information, sets the heartbeat sending interval, and specifies the range of incremental operation data to be reported; Step S202: constructing a heartbeat message; Step S203: sending the heartbeat message to the heartbeat monitor of the host Agent through the persistent network connection; Step S204: the host agent updates the heartbeat timestamp; Step S205: the host agent analyzes the data and detects anomalies; Step S206: Combine the last active timestamp with the heartbeat timeout threshold configured in the system to determine whether the abnormality in-depth processing process is triggered. If it has not timed out, proceed to step S207; if it has timed out, proceed to step S208; Step S207: If the heartbeat timestamp has not timed out and the indicator analysis shows no abnormalities, the host agent marks the service as "healthy" in the service registry, updates the "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. The distributed agent-based service monitoring and management system according to claim 1, characterized in that: 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 the intelligent routing of the unified entrance of user-level services. The intelligent routing decision engine comprehensively considers multiple factors such as service health, load status, and performance indicators to calculate the service priority score and match the optimal service agent for user requests.

6. A distributed agent-based service monitoring and management system according to claim 1, characterized in that: The semantic service description submitted by the registration module of the service agent includes a detailed description of the service capabilities, so that the host agent can perceive the service capabilities from the functional characteristics dimension and realize the dynamic observability of the service capabilities in combination with the operation status monitoring data.

7. A distributed agent-based service monitoring and management system according to claim 1, characterized in that: The incremental heartbeat information sent by the heartbeat module of the service agent only includes the operating indicators that have changed compared with the last time.

8. A distributed agent-based service monitoring and management system 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 combining heart rate increment data and active detection results; (2) The service control process supports smooth state migration, such as gradual recovery attempts in an isolated state; (3) State transition rules reflect fine-grained management.

9. A distributed agent-based service monitoring and management system 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, and gives priority to services with low response delay in content generation scenarios with high real-time requirements.

10. The distributed agent-based service monitoring and management system according to claim 1, characterized in that: The deep detection request initiated by the health checker of the host agent, in addition to obtaining the internal status of the service and the status of key dependencies, can also be customized to collect specific operating indicators according to different service types.

Images