Agency service management methods, devices, storage media and computer equipment

Abstract

This application relates to the field of Internet technology and discloses a proxy service management method, apparatus, storage medium, and computer equipment. The method includes: parsing a proxy service configuration file to obtain proxy service configuration information; extracting a proxy target address from the proxy service configuration information; associating the proxy target address with an infrastructure management system to obtain corresponding infrastructure information; detecting the access status of a front-end access point based on the proxy service configuration information; and visually displaying the proxy service configuration information, the infrastructure information, and the access status. Through this method, this application achieves automated parsing and intelligent management of proxy service configurations, and provides a visual management interface, facilitating problem localization and impact analysis, significantly improving operational efficiency, reducing operational costs, and possessing high reliability and maintainability, capable of meeting the proxy service management needs of different scales and complexities.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus, storage medium and computer equipment for managing proxy services. Background Technology

[0002] In the distributed system architecture of large internet companies, Nginx, as a high-performance reverse proxy server, is widely used in traffic distribution and load balancing scenarios. Currently, the common technical approach involves operations and maintenance personnel performing distributed maintenance on Nginx configuration files across each node to meet the dynamic adjustment needs of the business. Regarding operations and maintenance monitoring, existing mainstream solutions mostly use general-purpose monitoring tools, focusing on monitoring the resource utilization of the proxy server and the connectivity of service ports to ensure the availability of basic services. This approach, based on manual configuration file maintenance combined with basic monitoring, constitutes the current mainstream technical status of large-scale Nginx proxy service management.

[0003] However, with the expansion of business scale and the prevalence of multi-cluster and multi-cloud environments, this decentralized management approach leads to a lack of a unified view of configuration information and insufficient information transparency. Existing monitoring solutions focus on service liveness monitoring, lacking the ability to deeply analyze and correlate the internal structure of proxy configurations, target server information, and business attribution relationships. In particular, in the interaction between proxy configurations and underlying infrastructure information, existing technologies struggle to automatically and intelligently associate Internet Protocol addresses (IP addresses), domain names, virtual machine information, and business responsible parties in the configuration. This disconnect between proxy configurations and the underlying infrastructure necessitates significant manual effort for cross-system information retrieval and comparison during configuration changes or troubleshooting, resulting in low management efficiency and hindering rapid problem localization and root cause analysis. Summary of the Invention

[0004] This application mainly provides a method, apparatus, storage medium, and computer equipment for managing agency services, aiming to solve the technical problem of low efficiency in existing agency service management methods.

[0005] To address the aforementioned technical problems, this application adopts the following technical solution: providing a proxy service management method. This proxy service management method includes: parsing a proxy service configuration file to obtain proxy service configuration information; extracting a proxy target address from the proxy service configuration information; associating the proxy target address with an infrastructure management system to obtain corresponding infrastructure information; detecting the access status of the front-end access entry point based on the proxy service configuration information; and visually displaying the proxy service configuration information, the infrastructure information, and the access status.

[0006] In some embodiments, the proxy service configuration information includes a proxy target field and a domain name configuration field; parsing the proxy service configuration file to obtain the proxy service configuration information includes: scanning the configuration file directory and identifying service block configuration items in the proxy service configuration file; for each service block configuration item, using a state machine algorithm to track the state of the parsing process, and using a curly brace matching algorithm to parse the nested block structure, and extracting the proxy target field and the domain name configuration field from the service block configuration item.

[0007] In some embodiments, extracting the proxy target address from the proxy service configuration information includes: matching multiple preset regular expression patterns in priority order according to the proxy target field; in response to any regular expression pattern being successfully matched, extracting a character sequence conforming to the Internet Protocol address format as the proxy target address; in response to all regular expression patterns failing to match, determining the proxy target field as a non-Internet Protocol address format and filtering it.

[0008] In some embodiments, the access status includes accessibility, login authentication requirements, and response time; detecting the access status of the front-end access entry based on the proxy service configuration information includes: constructing a Uniform Resource Locator (URL) based on the domain name configuration field and initiating an access request; determining the accessibility of the front-end access entry based on the response status code of the access request; analyzing the response content of the access request and detecting whether there are preset login features in the response content to determine whether the front-end access entry has the login authentication requirement; and recording the time interval from initiation of the access request to receipt of the response as the response time.

[0009] In some embodiments, associating the proxy target address with the infrastructure management system to obtain the corresponding infrastructure information includes: calling the application programming interface of the infrastructure management system and using the proxy target address as a query parameter; receiving virtual machine instance information returned by the infrastructure management system that corresponds to the proxy target address; and extracting at least one of the following from the virtual machine instance information: business affiliation information, responsible person information, hostname, data center location, and operating status, as the infrastructure information.

[0010] In some embodiments, visualizing the proxy service configuration information, the infrastructure information, and the access status includes: associating and integrating the proxy service configuration information, the infrastructure information, and the access status to form a service link view; and displaying the service link view on the application interface.

[0011] In some embodiments, the proxy service management method further includes: persistently storing the proxy service configuration information, the infrastructure information, and the access status, wherein the persistent storage adopts a dual storage mechanism to support incremental data updates.

[0012] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a proxy service management device, which includes: a configuration parsing module for parsing a proxy service configuration file to obtain proxy service configuration information; an address extraction module for extracting a proxy target address from the proxy service configuration information; an information association module for associating the proxy target address with an infrastructure management system to obtain corresponding infrastructure information; a status detection module for detecting the access status of the front-end access entry based on the proxy service configuration information; and a visualization management module for visually displaying the proxy service configuration information, the infrastructure information, and the access status.

[0013] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a storage medium on which program data is stored, characterized in that the program data, when executed by a processor, implements the steps of the above-described proxy service management method.

[0014] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a computer device, which includes a processor and a memory connected to each other, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the agent service management method described above.

[0015] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a proxy service management method, apparatus, storage medium, and computer equipment. This application automatically parses proxy service configuration files and extracts key configuration information, associates it with infrastructure information, and simultaneously detects the access status of the front-end access point, visually displaying this information. This effectively solves the problems of existing proxy service management methods, such as the lack of a unified view of configuration information, insufficient information transparency, and difficulty in deep analysis and correlation. When facing large-scale and complex proxy service management needs, this method can quickly and accurately locate the root cause of problems, achieving comprehensive and refined management of proxy services. This improves the reliability and maintainability of large-scale distributed systems, realizes unified, transparent, and efficient management of proxy services, significantly enhances the automation and intelligence level of proxy service management, improves management efficiency, monitoring capabilities, and ease of operation and maintenance, reduces fault detection time and operation and maintenance costs, and is conducive to promoting the stable operation of distributed systems during enterprise digital transformation, providing strong support for the continuous development of enterprise business. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the agency service management method provided in this application; Figure 2 This is a schematic diagram of an embodiment of the agency service management device provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] This application provides a method for managing agency services, see reference. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the proxy service management method provided in this application. The proxy service management method includes: Step 10: Parse the proxy service configuration file to obtain the proxy service configuration information.

[0021] In this embodiment, the proxy service configuration file is a file that defines the behavior rules of the proxy server. It stores configuration instructions and structured block definitions for core business logic such as traffic distribution, load balancing, and access control. In a large-scale distributed environment, such configuration files are typically stored in specific directories across multiple computing nodes and can be obtained through file system interfaces, network transmission protocols, or configuration management tools. The proxy service configuration information is a collection of core structured data extracted from the aforementioned configuration file and directly related to the proxy service instance. This configuration information accurately reflects key attributes of the proxy service, such as its listening port, forwarding rules, and upstream server address, serving as the data foundation for subsequent infrastructure association, status detection, and visual management.

[0022] In this embodiment, parsing the proxy service configuration file is a transformation process from raw text to structured data. This process uses file traversal, text analysis, and rule mapping to locate and extract the configuration rules scattered throughout the file. During parsing, text analysis can be performed using techniques such as state machine algorithms, recursive descent algorithms, or regular expression matching. For example, in one embodiment, one or more preset storage paths can be traversed first to locate the physical location of all proxy service configuration files. Then, the file content is analyzed using a combination of lexical and syntactic analysis to identify syntactic elements such as keywords, delimiters, comment symbols, and markers defining context blocks. Next, based on the syntactic rules of the proxy service configuration file, the identified syntactic elements are structured and mapped. For example, if a service configuration block is identified and instructions defining a domain name and a proxy target are found within it, the parameter values ​​of these two instructions are extracted as key fields required for subsequent processing. Finally, the extracted key information is assembled and stored according to a preset data model to obtain each proxy service configuration information record.

[0023] In this embodiment, to more clearly illustrate the parsing process, we will specifically use the parsing of the Nginx proxy server's configuration file as an example. The Nginx configuration file typically consists of a main configuration file and multiple imported sub-configuration files. Its syntax structure presents a clear hierarchical relationship. The outermost layer is the Hypertext Transfer Protocol context, which contains multiple service contexts. Each service context defines a virtual host, and multiple location contexts can be nested within it to define specific routing matching rules. During the parsing process, the service block configuration items in the file can be located and identified first, treating them as an independent parsing unit. Subsequently, within this parsing unit, key information for identifying the service access entry point is extracted by matching hostname instructions, and key information for identifying the forwarding target is extracted by matching proxy forwarding instructions. For proxy forwarding instructions, they may appear at the root level of the service block or in deeply nested location or condition blocks. The parsing process needs to traverse all levels of the block structure to ensure the integrity of the information. Finally, each parsed proxy service configuration information contains at least the aforementioned key information identifying the access entry point and forwarding target, and is associated with its source file identifier and nested path, forming a complete proxy service record.

[0024] In this embodiment, the above process can automatically and in batches extract and convert the proxy service rules that were originally scattered in various configuration files into structured data in a unified format, laying a solid data foundation for the centralized management, transparent display and intelligent analysis of proxy configurations.

[0025] Optionally, in some embodiments, the proxy service configuration information includes a proxy target field and a domain name configuration field.

[0026] In this optional embodiment, the domain name configuration field is a data field used to identify the name of the front-end entry point for the proxy service to provide external access. The value of this field is derived from parsing and extracting the hostname directive in the configuration file. The specific form of this field value is not limited to a single domain name; it can also include wildcard domain names, domain names matched by regular expressions, Internet Protocol address strings, or specific reserved values. Its core purpose is to route the request to the corresponding virtual server instance by matching the host field in the request header when a client request is received. The proxy target field is a data field used to identify the address information of the back-end server to which the request is forwarded. The value of this field is derived from parsing and extracting the proxy forwarding directive in the configuration file. This field value is a composite string that may contain a protocol identifier, network address, port number, and an optional Uniform Resource Identifier path suffix. Its core purpose is to define "where the request is forwarded," forming the core mapping relationship of the proxy service together with the domain name configuration field. These two fields are the most crucial components of the proxy service configuration information; their accurate extraction provides the prerequisites for subsequent service link analysis, Internet Protocol address extraction, infrastructure association, and access status detection.

[0027] Optionally, in some embodiments, parsing the proxy service configuration file to obtain proxy service configuration information includes: scanning the configuration file directory and identifying service block configuration items in the proxy service configuration file; for each service block configuration item, using a state machine algorithm to track the state of the parsing process, and using a curly brace matching algorithm to parse the nested block structure, and extracting the proxy target field and domain name configuration field from the service block configuration item.

[0028] This optional embodiment provides a highly robust and automated configuration parsing implementation scheme, aiming to solve parsing problems such as nested structures and comment interference in configuration files. The entire process consists of three main stages: The first stage is the scanning and identification stage. The parsing process begins with a file scanning step, traversing one or more pre-defined configuration file directories. This traversal process uses file traversal algorithms such as depth-first or breadth-first search to recursively access the files in the directories and filters out the proxy service configuration files to be parsed based on file extensions or filename characteristics. Subsequently, service block configuration items are identified in the file content. Service block configuration items specifically refer to independent context blocks in the configuration syntax that begin with a specific keyword and are enclosed in curly braces; one such block typically represents a virtual server instance.

[0029] The second stage, state tracking and structure parsing, is crucial for ensuring parsing accuracy. Since configuration files often contain complex nested structures, mixed comments, and string literals, simple text matching can easily fail. Therefore, a state machine algorithm is introduced to track the state of the parsing process. This algorithm defines a finite number of states, such as: "Global State" (outside any block), "Service Block State" (inside a service block), "Location Block State" (inside a location block), "String State" (within a quoted string literal), and "Comment State" (after a comment symbol, up to the end of the line). The parsing engine reads the file content character by character, transitioning between characters and the current state. For example, encountering double quotes in the "Block State" transitions to the "String State." Any character encountered in the "String State" (including comment symbols and curly braces) is considered string content until a matching closing quote is encountered. This mechanism accurately distinguishes between configuration instructions, string literals, and comments, avoiding parsing errors caused by interference from comments or string content. Simultaneously, a curly brace matching algorithm is used to correctly handle multi-level nested block structures. This algorithm maintains a nesting depth counter, initially set to zero. During parsing, a counter is incremented for each valid left curly brace encountered (which must be verified by the state machine to be outside the "comment state" or "string state"); and decremented for each valid right curly brace encountered (again excluding comment and string states). When the counter reaches zero, it indicates the end of the outermost block structure. This counter allows for precise location of the boundaries of nested blocks at arbitrary depths, ensuring that the extracted configuration information is complete and closed.

[0030] The third stage is the field extraction stage. After completing state tracking and block boundary delineation, the parsing process enters the specific field extraction phase. This extraction process combines regular expression matching with contextual information recorded by the state machine. For example, when the state machine is in the "service block state" and the nesting depth is a preset level, the instruction matching algorithm is used to locate the hostname instruction, and the string following it (up to the semicolon) is extracted as the value of the domain name configuration field. For the proxy target field, since the proxy forwarding instruction may appear at the root level of the service block, or in deeply nested location or conditional blocks, the parser needs to recursively or iteratively search for the proxy forwarding instruction in all sub-blocks of the current service block (at the levels determined by the brace matching algorithm). Whenever a proxy forwarding instruction is found within a block at a certain level, its parameter value is extracted as a proxy target record, and associated with the context information of that level. Ultimately, a service block may generate one or more proxy service configuration records, each containing a clearly defined domain name configuration field and proxy target field. Through the collaborative work of the state machine algorithm and the brace matching algorithm, complex and ever-changing configuration files in the production environment are effectively parsed, ensuring the accuracy and completeness of the obtained information.

[0031] Optionally, in some embodiments, after using a state machine algorithm to track the state of the parsing process, the method further includes: using a recursive descent parsing algorithm to extract configuration information from nested blocks layer by layer, starting from the service block configuration item.

[0032] In this optional embodiment, the method for extracting configuration information from deeply nested blocks is further refined to ensure that no configuration item at any level is missed. The recursive descent parsing algorithm used is a top-down syntax analysis method, whose principle is well-suited for processing data with a clear hierarchical grammar, such as configuration files. In specific implementation, a parsing function can be defined that takes a complete block text (such as the text content of a service block or a location block) as input. Internally, the function first performs an instruction extraction operation at the root level of the current block to obtain the domain name configuration or other instructions at that level. Then, the function searches for the existence of a sub-block's starting identifier within the current block text. If it exists, the aforementioned brace matching algorithm is used to extract the complete text content of the sub-block. Next, the parsing function itself is recursively called, passing this sub-block text as a new parameter for processing. During the recursive call, the function attempts to extract specific instructions (such as proxy forwarding instructions) within the sub-block. If there are deeper nested blocks within the sub-block, the recursive process continues downwards until the lowest-level block is processed. The return result of the recursive call (the extracted instruction information) is merged or associated with the context information of the previous level. By recursively traversing all substructures from the top-level block downwards, it is possible to comprehensively and systematically extract proxy rules at any depth in the configuration file. This is particularly suitable for large-scale proxy service application scenarios with complex configuration structures and numerous routing rules.

[0033] Optionally, in some embodiments, after using a state machine algorithm to track the state of the parsing process, the method further includes: using a smart annotation removal algorithm to distinguish between annotation content and string content by tracking the string state, and removing the annotation content.

[0034] This optional embodiment provides a specific preprocessing method to clean up interfering information and improve parsing accuracy during the parsing process. In many configuration file syntaxes, comment symbols have dual semantics: they can be the start character of a line comment, indicating that the content after the symbol to the end of the line is a comment and should be ignored; or they can be an ordinary character in a string literal that needs to be retained. If not handled properly, valid characters in configuration values ​​may be mistakenly deleted, or comment symbols within a string may be mistakenly taken as the start of a comment, leading to parsing errors. The intelligent comment removal algorithm is designed to solve this problem, and its core relies on the "string state" flag maintained by the state machine algorithm. The working mechanism of the algorithm is as follows: In the character-by-character parsing process driven by the state machine, when a comment symbol is encountered, the algorithm does not take immediate action, but first queries the current state flag. If the current state flag indicates that the parser is inside the "string state" (i.e., it has previously encountered an unclosed quotation mark), the algorithm determines that the comment symbol character is part of the string content, belongs to a valid configuration value, and retains it without any processing, and the parser continues to be in the "string state". If the current state flag indicates that the parser is not in the "string state", the algorithm determines that the comment symbol character is the start character of a line comment. At this point, the algorithm identifies all characters from that position up to the end of the current line as comment content. It can choose to mark them as ignored or filter them directly from the generated intermediate data structure. The parser then enters "comment state" or skips the remaining line content. Through this context-based intelligent judgment, the algorithm can effectively eliminate purely comment text while fully preserving legal special characters in the string when extracting instruction values. This process significantly improves the accuracy and reliability of the parsing results, providing a semantically correct textual foundation for subsequent field extraction.

[0035] Step 20: Extract the proxy target address from the proxy service configuration information.

[0036] In this embodiment, the proxy target address specifically refers to the Internet Protocol (IP) address used to identify the network location of the backend server, which is further parsed and extracted from the "Proxy Target Field" of the proxy service configuration information. The value of the proxy target field comes from various sources; it may be a string containing a complete Uniform Resource Locator (URI), a string containing only the IP address and port, a dynamic expression using variables, or even a domain name. The core objective of this step is to accurately identify and extract the IP address portion conforming to the IP address format (such as the dotted decimal format of IPv4) from these diverse formats. Extracting the IP address is a crucial bridge connecting application-layer proxy configuration and underlying infrastructure information management. In most enterprise infrastructure management systems, the IP address is the most direct and stable key value for querying and identifying computing resources such as virtual machines and physical servers. By extracting the IP address, in-depth management of backend server resource location, responsible party association, and status monitoring can be achieved. Simultaneously, this step also needs to identify and filter proxy targets that are not in the IP address format (such as domain names, upstream server names, and expressions containing variables) to avoid passing invalid information to subsequent association processes. The extraction process employs an algorithm based on preset pattern matching, which balances accuracy, comprehensiveness, and efficiency, and also provides core network layer identifiers for the subsequent construction of an end-to-end service link view.

[0037] Optionally, in some embodiments, extracting the proxy target address from the proxy service configuration information includes: matching multiple preset regular expression patterns in order of priority according to the proxy target field; in response to any regular expression pattern matching successfully, extracting a character sequence that conforms to the Internet Protocol address format as the proxy target address; in response to all regular expression patterns failing to match successfully, determining the proxy target field as a non-Internet Protocol address format and filtering it.

[0038] This optional embodiment details the specific execution logic and process of the multi-pattern matching algorithm for intelligent extraction of Internet Protocol addresses. The core idea of ​​this algorithm is to predefine a set of regular expression patterns that can cover common proxy target formats, especially those containing Internet Protocol addresses, and attempt to match them sequentially according to a certain priority order. The principle of priority setting is usually from more specific and common formats to more general and less common formats to improve matching efficiency. For example, the algorithm can define the following four patterns to be executed sequentially: First, matching cases that explicitly use Hypertext Transfer Protocol (HTTP) and contain Internet Protocol addresses (e.g., http: / / 192.168.1.1:8080). This pattern requires the string to begin with a preset protocol header, followed by an Internet Protocol address structure separated by dots, and optionally a port number. Second, matching cases that explicitly use Secure Hypertext Transfer Protocol (HTTPS) and contain Internet Protocol addresses (e.g., https: / / 192.168.1.1). Similar to the previous pattern, but requiring it to begin with a secure protocol header. Secondly, it matches cases where dynamic protocol variables are used and internet protocol addresses are included (e.g., $scheme: / / 192.168.1.1:$server_port). This pattern can handle configurations where the protocol portion is defined by variables. Finally, it matches general internet protocol address formats (192.168.1.1:80), without requiring a protocol prefix, and is used to capture independent address structures within the string.

[0039] In this optional embodiment, the algorithm can attempt patterns sequentially according to the aforementioned priority order during execution. For each pattern, the search function of regular expressions is used to match the string of the proxy target field. If a pattern matches successfully, the content of the capture group (i.e., the Internet Protocol address portion) is directly extracted from the matching result as the proxy target address, and the matching process ends immediately. If all preset patterns fail to match the target string, the algorithm determines that the proxy target field does not contain a string that conforms to the Internet Protocol address. In this case, the field may be a domain name, an upstream server name, or a complex expression composed of variables. The algorithm marks the field as "non-Internet Protocol address format" and performs a filtering operation, i.e., it does not perform subsequent infrastructure information association steps. This priority-based matching strategy ensures that the most common explicit protocol formats can be processed quickly, improving overall efficiency; at the same time, by defining multiple patterns, it covers most possible production environment configurations, ensuring the comprehensiveness of the extraction; and the strict Internet Protocol address format requirements enable automatic filtering of non-Internet Protocol address targets such as domain names, ensuring the accuracy of the extraction.

[0040] Optionally, in some embodiments, the preset multiple regular expression patterns include patterns that match at least two of the following protocol formats: Hypertext Transfer Protocol format, Secure Hypertext Transfer Protocol format, Dynamic Protocol format, and Pure Internet Protocol address format, and each of the regular expression patterns supports address formats with or without port numbers.

[0041] In this optional embodiment, the design of the regular expression pattern library is expanded and explained from two dimensions to ensure that the algorithm can adapt to various possible configuration writing habits and edge scenarios. Specifically: The first dimension is the diversity of protocol formats. Several preset regular expression patterns can cover at least the following protocol format types: first, matching formats that begin with a Hypertext Transfer Protocol followed by an Internet Protocol address; second, matching formats that begin with a Secure Hypertext Transfer Protocol followed by an Internet Protocol address; third, matching formats that begin with a dynamic protocol variable followed by an Internet Protocol address; and fourth, matching formats that do not specify a protocol prefix and simply use the Internet Protocol address string. The use of this pattern combination can identify various writing conventions in the proxy target field, such as explicitly stating the protocol, using variable protocols, or only writing the address.

[0042] The second dimension is compatibility with address format variations. The pattern design further considers port number optionality, Uniform Resource Identifier (URI) path compatibility, and future support for more versions of IoT protocol addresses (e.g., generally considering IPv4 addresses but compatible with IPv6 addresses). Regarding port number optionality, the port number matching portion in each regular expression pattern uses an optional modifier, indicating that the colon and the following port number may or may not appear. This ensures correct matching and extraction for both cases with and without ports. Regarding URI path compatibility, the value of the proxy target field may follow the Internet Protocol address and port number with a path. In the design pattern, the content after the Internet Protocol address and port number matching portion is not limited, therefore it does not affect the overall matching success, thus achieving compatibility for such path-based scenarios.

[0043] In this optional embodiment, for the automatic filtering of variables and domain names, proxy targets consisting entirely of variables or containing domain names will be automatically filtered out because their string content does not conform to the requirements of the corresponding Internet Protocol format. This is precisely the implementation principle of the algorithm's "automatic filtering of proxy targets in the form of domain names". By constructing a multi-layered and scalable regular expression pattern library from two dimensions—protocol format type and address format variant—the Internet Protocol address extraction algorithm exhibits high adaptability and robustness, capable of handling complex and diverse configuration practices in production environments, and ensuring the accuracy and coverage of the extraction results.

[0044] Step 30: Associate the proxy target address with the infrastructure management system to obtain the corresponding infrastructure information.

[0045] In this embodiment, the infrastructure management system refers to an enterprise's internal information platform used for unified management, monitoring, and maintenance of computing resources (such as physical servers, virtual machine instances, containers, network devices, etc.). Typical examples include configuration management databases, resource management console interfaces provided by cloud service providers, and self-developed asset management systems. These systems typically maintain detailed attribute information for each resource instance, including but not limited to its Internet Protocol address, hostname, business line or project group, operations manager, deployed physical data center or cloud availability zone, and current operating status. The core purpose of this step is to use the proxy target address (i.e., the Internet Protocol address) extracted from the proxy configuration in step 20 as a query key to call the external data access interface provided by the infrastructure management system to query and obtain complete detailed information about the underlying computing resources corresponding to that Internet Protocol address. This association is a key technical means to break down the information silos between the "application configuration view" and the "infrastructure resource view." Through this association, operations personnel or automated processes can not only know which network address a certain proxy rule configuration points to, but also immediately understand which business department the specific server behind that address belongs to, which engineer is responsible for it, which geographical data center it is located in, and whether the current resource status is healthy, among other key operations context information. This provides indispensable core data support for advanced operation and maintenance scenarios such as rapid fault determination, impact analysis of changes, resource planning and cost allocation.

[0046] Optionally, in some embodiments, the proxy target address is associated with the infrastructure management system to obtain the corresponding infrastructure information, including: calling the application programming interface of the infrastructure management system and using the proxy target address as a query parameter; receiving virtual machine instance information corresponding to the proxy target address returned by the infrastructure management system; and extracting at least one of the following from the virtual machine instance information: business ownership information, person in charge information, hostname, data center location, and operating status, as the infrastructure information.

[0047] This optional embodiment describes in detail the specific implementation method and technical details of the association process. Specifically, it includes: (1) Calling the application programming interface (API) of the infrastructure management system. This interface typically follows a descriptive state transition style and requests access via Hypertext Transfer Protocol (HTTP). The interface's Uniform Resource Locator (URL) contains query parameters. The query parameters are designed with the "proxy target address" (i.e., Internet Protocol address) as the core key-value pair. For example, the parameter name for a virtual machine information query interface could be set to LAN Internet Protocol address query, and the parameter value would be replaced with the specific extracted Internet Protocol address. For security reasons, the request may need to carry authentication information, such as an API key, access token, or an authentication field placed in the request header.

[0048] (2) Receive response data returned by the application programming interface. If the query is successful, the response body is typically structured data in a lightweight data exchange format (such as JSON) or Extensible Markup Language (XML) format, containing detailed information about the queried virtual machine instance. For example, a successful response may contain the following fields: hostname, business relationship name (such as "payment platform group"), responsible person's name or employee ID, data center name (such as a data center location), usage status (such as "running" or "stopped"), product name, operating system type, creation time, etc.

[0049] (3) Extract key information from the returned structured data. The fields to extract can be determined based on actual management needs and analysis objectives. Core extraction items include: Business affiliation information (extracting the business relationship field to identify the business line, project group, or department to which the server belongs, serving as the primary basis for problem identification and impact assessment); Responsible person information (extracting the responsible person field to record the primary person responsible for the server or the operations and maintenance manager, facilitating direct contact in case of problems); Hostname (extracting the hostname field, the server's logical name, which is easier to identify and remember than the Internet Protocol address); Data center location (extracting the data center name field, indicating the physical data center or cloud availability zone where the server is located, which is of significant reference value for network latency analysis, cross-data center disaster recovery assessment, and network fault diagnosis); and Operating status (extracting the usage status field, indicating the server's current operating status, directly affecting service availability judgment).

[0050] In this optional embodiment, the extracted fields collectively constitute the infrastructure information corresponding to the proxy target address. This information will then be appended, updated, or merged into the corresponding proxy service configuration information record, forming a data record containing a complete chain from "domain name to Internet Protocol address to infrastructure details." If the application programming interface (API) query returns empty or an error (indicating that the Internet Protocol address is not registered in the management system or the query failed), the "infrastructure information" field of the proxy target address can be set to empty and marked as "not associated" or "query failed" for subsequent manual verification or data governance. Automated and batch-based association queries through API integration are highly efficient and real-time, ensuring the relative accuracy and up-to-dateness of the associated information. This is a core technical means to achieve deep integration of proxy services and infrastructure.

[0051] Step 40: Based on the proxy service configuration information, check the access status of the front-end access entry point.

[0052] In this embodiment, the front-end access entry point refers to the network access entry point defined in the "domain name configuration field" of the proxy service configuration information. Access status refers to a set of dynamic indicators reflecting service availability and health, observed from the perspective of the end user or client when actually accessing the domain name entry point. This step actively simulates client access behavior to periodically or on-demand probe each proxy service's front-end entry point, thereby obtaining its true operating status. This is an active probing step that surpasses traditional passive monitoring (which only monitors the server's local resource utilization, process liveness, or port connectivity). The content of the probe and detection typically includes, but is not limited to: accessibility (indicators reflecting service availability, such as whether the domain name can be successfully accessed, whether the network is connected, and whether the service is reachable), response performance (key indicators reflecting service quality and user experience, such as how long it takes to access the domain name and whether the response speed is within the normal range), and access characteristics (indicators that distinguish between public services and internal management systems, such as whether authentication obstacles were encountered when accessing the domain name, and whether login was required).

[0053] This embodiment stores, displays, and manages the detected access status along with static configuration information and associated infrastructure information. Operation and maintenance personnel can intuitively perceive the health of each proxy service from the perspective of the end user, and promptly discover access anomalies caused by backend service downtime, network failures, configuration errors, certificate problems, or changes in authentication requirements. This achieves a leap from "infrastructure monitoring" to "business service monitoring," significantly improving the timeliness of fault discovery and troubleshooting efficiency.

[0054] Optionally, in some embodiments, the access status includes accessibility, login authentication requirements, and response time.

[0055] In this optional embodiment, three core and representative dimensions of the access status are clearly defined. Among them: Accessibility is a Boolean metric that directly answers the question, "Is the service currently available to the user?" Its determination is primarily based on the Hypertext Transfer Protocol (HTTP) response status codes. These status codes follow the protocol standards established by the Internet Engineering Task Force (IETF) and can be categorized as follows: Accessible: Success status codes (e.g., "200 OK") and redirection status codes (e.g., "301 Moved Permanently", "302 Found") indicate that the request has been successfully processed or redirected to a valid resource. Inaccessible: Client errors such as "404 Not Found" typically indicate that the resource does not exist; server error status codes (e.g., "500 Internal Server Error") indicate that the backend service or gateway is experiencing an anomaly. Special accessibility: While status codes "401 Unauthorized" and "403 Forbidden" indicate that access is denied, the server itself has responded, meaning the network and service processes are active. These two status codes are usually marked as "accessible" but are also associated with the "login authentication requirement" metric.

[0056] Login authentication requirements, also a Boolean indicator, determine whether a user needs to log in, enter credentials, or complete some authentication process before accessing actual content. This is crucial for distinguishing between public websites (such as promotional pages) and internal systems requiring permissions (such as administrative backends). The judgment criteria are multi-dimensional and heuristic: status code prompts, directly based on "401" or "403" status codes; content characteristics, analyzing the content of the Hypertext Transfer Protocol (HTTP) response body, such as whether the page title, page body, and HTTP structure contain characteristic keywords such as "login," "username," and "password," or whether there is a form structure containing a password input box.

[0057] Response time, a numerical performance metric typically measured in milliseconds, measures the total time elapsed from initiating a Hypertext Transfer Protocol (HTTP) request to receiving the response header or body. This time comprehensively includes network round-trip latency, domain name resolution time, proxy server processing time, and backend application computation time, making it a key indicator of end-to-end server performance. Abnormally high response times may indicate network congestion, server overload, or performance bottlenecks in the backend processing logic. These three dimensions collectively outline the basic status profile of a front-end access point at a specific moment, fulfilling the core operational monitoring needs in terms of "availability," "features," and "performance," providing a data foundation for subsequent alerting, analysis, and optimization.

[0058] Optionally, in some embodiments, the access status of the front-end access entry is detected based on the proxy service configuration information, including: constructing a Uniform Resource Locator based on the domain name configuration field and initiating an access request; determining the accessibility of the front-end access entry based on the response status code of the access request; analyzing the response content of the access request and detecting whether there are preset login features in the response content to determine whether the front-end access entry requires login authentication; and recording the time interval from the initiation of the access request to the receipt of the response as the response time.

[0059] This optional embodiment specifically describes a complete and structured execution flow for state detection, which may include: (1) Construct a Uniform Resource Locator (URL) and initiate an access request. The construction logic first constructs a complete URL for testing based on the value of the "Domain Configuration Field". If the field value itself is a complete URL, it is used directly. Otherwise, the "Proxy Target Field" in the same proxy service configuration information is referenced to determine the protocol to be used. For example, if the value of the Proxy Target Field begins with Secure Hypertext Transfer Protocol, the detected URL should be constructed in the Secure Protocol format; if the Proxy Target Field begins with Ordinary Hypertext Transfer Protocol or cannot be determined, it is constructed in the Ordinary Protocol format by default. This strategy ensures that the protocol used for detection is consistent with the protocol actually forwarded by the proxy, improving the accuracy of detection. When initiating a request, a retrieval request is initiated using an Hypertext Transfer Protocol client. To simulate real user access, the request should have a reasonable timeout (e.g., connection timeout and read timeout are each preset in seconds), and common browser user agent strings and request headers should be set. The request is usually set to allow automatic follow-up redirects to obtain the final response. The request header can simulate a real browser access, setting complete Hypertext Transfer Protocol request headers, such as user agent, accept type, accept language, etc., to avoid being identified as a crawler by the server and denied access. It also supports content compression and Chinese / English language preferences.

[0060] (2) Determine accessibility. Obtain the Hypertext Transfer Protocol (HTTP) response status code. Determine accessibility according to the aforementioned classification rules. For example, define an "accessible status code list" containing success and redirection status codes. If the response status code is in this list, accessibility is determined. If the status code is "404", accessibility is determined, and the error reason is recorded as "page does not exist". If the status code is greater than or equal to "500", accessibility is determined, and "server error" is recorded. For "401" and "403", accessibility is determined, but marked as "login authentication required".

[0061] (3) Determining Login Authentication Requirements. This is a multi-layered detection process designed to balance efficiency and accuracy. First, status code detection is performed. As mentioned earlier, "401" and "403" status codes serve as strong signals indicating the need for login authentication. Second, page title keyword detection is performed, using regular expressions to extract the title tag content from the response body. The extracted title is then cleaned (removing HTML entity codes and extra whitespace). Next, a matching process is conducted within a pre-defined login keyword database. This database should cover common Chinese and English words. For example, English keywords could include "login", "signin", "sign in", "username", "password", "authentication", "auth", "captcha", etc., while Chinese keywords could include "login", "user login", "username", "password", "verification code", "authentication", "identity verification", etc. If the title contains any of these keywords, login is required. Third, page content keyword detection is performed. If no keywords are found in the title, the database is searched throughout the entire response body text. If found, login is required. Finally, login form structure detection is performed, which is a more fundamental feature detection process. Use regular expressions or a Hypertext Markup Language (HTML) parser to search the response body for an HTML structure that matches the login form pattern. Typical patterns include searching for form tags and then looking within them for an input element of type "password" or named "password". If a match is found, login is required. Only if none of the above steps trigger a "login required" check is the login authentication request ultimately denied.

[0062] (4) Record response time. Before sending a Hypertext Transfer Protocol (HTTP) request, record a high-precision timestamp as the start time. After receiving an HTTP response, record a timestamp as the end time. Calculate the difference and convert it to milliseconds. If the request fails due to timeout, connection error, or other exceptions, the response time can be recorded as empty or a specific error identifier, and the error information can be recorded. The timeout setting defaults to a preset number of seconds. After the timeout, an error message is returned, and the response time is not recorded. Through this structured, multi-layered detection process, comprehensive and intelligent multi-dimensional status information such as accessibility, authentication requirements, and performance indicators of the front-end access point can be obtained.

[0063] Optionally, in some embodiments, constructing a Uniform Resource Locator (URL) based on the domain name configuration field and initiating an access request includes: using a thread pool to concurrently construct multiple URLs and controlling the maximum concurrency, and concurrently initiating access requests to multiple front-end access points.

[0064] In this optional embodiment, for large-scale proxy service management scenarios requiring status checks on hundreds or even thousands of domains, a concurrent detection mechanism is introduced to significantly improve execution efficiency. Serial detection, where each domain is checked individually, results in a total time consumption equal to the sum of the times of each individual detection, failing to meet the timeliness requirements of periodic health checks. The core of concurrent detection is utilizing multi-threading or asynchronous input / output techniques. One specific implementation uses thread pool technology. First, a list of proxy service information to be detected is prepared, with each element containing at least a "domain configuration field" and related "proxy target field" information. Then, a fixed-size thread pool is created, and the maximum number of concurrent worker threads is set. This parameter needs to be comprehensively considered based on network bandwidth, target server capacity, and the resources of the detection machine to avoid excessive pressure on the detected service or exhaustion of its own resources. The task of detecting a single domain is defined as a function, which encapsulates logic such as Uniform Resource Locator (URI) construction, Hypertext Transfer Protocol (HTTP) requests, response analysis, and result recording. This function is paired with each element in the list and submitted as a task to the thread pool for concurrent execution. The mechanism provided by the thread pool is used to obtain and aggregate the results of completed tasks. In a multi-threaded environment, if multiple threads need to update shared statistical variables (such as success counters), thread locks or atomic operations are required to ensure data consistency. Concurrent detection significantly reduces the overall detection time from the sum of all detection times to nearly the time of the slowest single detection, resulting in a substantial efficiency improvement. This makes it possible to perform minute-level periodic status scans on large-scale proxy service clusters, greatly enhancing the real-time performance and coverage of monitoring.

[0065] Optionally, in some embodiments, detecting whether there are preset login features in the response content includes: extracting the page title and detecting whether there are preset login keywords in the page title; if there are no login keywords in the page title, detecting whether there are login keywords in the page content; if there are no login keywords in the page content, detecting whether there is a form structure containing a password input box in the page.

[0066] In this optional embodiment, the detection logic for login authentication requirements is hierarchically structured and prioritized, forming an optimized detection pipeline from "efficient coarse detection" to "comprehensive detailed examination." Specifically, the first layer is page title keyword detection. The page title usually highly summarizes the core function of the page and is a strong signal for judging "login page." The algorithm performs this operation first because extracting and matching title text is inexpensive and fast. If the title directly matches keywords such as "login," a conclusion can be quickly reached. The second layer is page content keyword detection. If the first layer fails, the search scope is expanded to the entire response text. This step can detect cases where the title does not explicitly indicate login guidance text or form prompts are included in the page content. Although the overhead is greater than the first layer, it can improve the detection coverage. The third layer is login form structure detection. This is the lowest level and the most essential feature detection. It does not rely on specific languages ​​or scripts but directly detects the functional structure of the page—whether there is a form that requires the user to enter a password. This method is particularly effective for internationalized, custom-styled, or very brief login pages. By parsing the hypertext markup language structure, the final determination can be made by searching whether the form elements contain password-type input elements.

[0067] This layered strategy in this optional embodiment can quickly yield results through the first or second layer in most cases, ensuring detection efficiency. For edge cases that are difficult to determine, a third layer of structured detection serves as a fallback, ensuring comprehensiveness and accuracy. The final judgment provides a reliable basis for operations and maintenance personnel to clearly distinguish between public services and services requiring authentication.

[0068] Step 50: Visualize the proxy service configuration information, infrastructure information, and access status.

[0069] In this embodiment, the visualization is the final output and interactive layer of the entire proxy service management method for users. It aims to present information obtained after parsing, correlation, and detection—information scattered across multiple sources and possessing multiple dimensions—in a unified, intuitive, easy-to-understand, and interactive manner on the management interface (usually a web page). Its core objective is to solve the problems of scattered configuration files, missing related information, and fragmented status monitoring in traditional operations and maintenance, which lead to heavy cognitive burdens and low efficiency in problem localization. By constructing an integrated "management dashboard" or "service catalog view," the key information chain of a proxy service instance—from "what the user accesses" (front-end domain entry point), "how traffic is forwarded" (proxy target and Internet Protocol address), "who the back-end server is" (infrastructure ownership), to "whether the current service is normal" (real-time access status)—is aggregated and displayed in a single interface element (such as table rows, cards, or detail panels). Furthermore, the visualization interface also supports functions such as searching, filtering, pagination, and batch operations, allowing users to quickly locate services of interest through corresponding interactive operations and easily view complete related information. Visualization is not just a simple listing of data, but a graphical expression and presentation of the concept of "service chain". Its purpose is to help operations and maintenance personnel quickly establish a global understanding of large-scale proxy service clusters, and when problems occur, they can quickly locate the root cause or responsible person along a clear information chain (domain name, Internet protocol address, business person in charge, server status) to achieve "one-stop" problem discovery and troubleshooting.

[0070] Optionally, in some embodiments, the proxy service configuration information, infrastructure information, and access status are visualized, including: associating and integrating the proxy service configuration information, infrastructure information, and access status to form a service link view; and displaying the service link view on the application interface.

[0071] In this optional embodiment, a core visualization model called "Service Link View" is proposed. The Service Link View is a logically hierarchical and data-integrated information aggregation. Using a proxy service instance as the smallest display unit, it clearly depicts the complete data flow and dependencies from the user request entry point to the backend infrastructure carrier.

[0072] In this optional embodiment, data integration is a crucial step in constructing this view, with the proxy target address serving as the link and association key connecting the data at each layer. The specific integration process may include: First, using the proxy service configuration information record output in steps 10 and 20 as the basic data skeleton, this record already contains domain name configuration, proxy target string, and extracted Internet Protocol address. Second, using this Internet Protocol address, a search and match is performed in the infrastructure information result set obtained in step 30. If a match is successful, the detailed information of the virtual machine or server corresponding to the Internet Protocol address (such as business affiliation, responsible person, hostname, location, and status) is merged into the proxy service record as a nested data object. Finally, the real-time access status information of the domain name entry point detected in step 40 is also merged into the proxy service record as a nested data object. Ultimately, each data record used for display is a nested structure containing three layers of information: the application layer, derived from the proxy configuration, including domain name, proxy target, configuration source file, etc.; the infrastructure layer, derived from the Internet Protocol address association, including business line, responsible person, hostname, Internet data center location, etc.; and the status layer, derived from real-time detection, including accessibility, response time, and whether login is required, etc.

[0073] In this optional embodiment, the service link view can be displayed in various forms on the application interface (such as a web page front-end). A typical approach is a list view, where each row represents a service link, displaying key summary information side-by-side: domain name, proxy target Internet Protocol address, affiliated business, responsible person, access status (identified by different colored icons or text), and response time. Users can expand a row to view complete three-layer details. Another approach is a card view, where each card displays the complete link of a service. More visual elements such as charts and topology diagrams can also be incorporated. This view organically integrates information originally scattered across configuration files, configuration management database systems, and monitoring alarms, forming a complete "service profile," allowing operations and maintenance personnel to clearly understand the configuration, affiliation, and real-time health status of any proxy service.

[0074] Optionally, in some embodiments, the proxy service configuration information, infrastructure information, and access status are associated and integrated to form a service link view, including: using the proxy target address as the association key, associating the domain name configuration field in the proxy service configuration information with the virtual machine instance information in the infrastructure information; associating the access status with the corresponding proxy service configuration information; and organizing the associated information in a hierarchical structure, wherein the top layer is the proxy service configuration information, the middle layer is the association result between the proxy target address and the infrastructure information, and the bottom layer is the access status.

[0075] This optional embodiment elaborates more specifically on the data construction logic, association mechanism, and organizational structure of the service link view. Specifically, in a proxy service scenario, the proxy forwarding instruction acts as a bridge connecting front-end requests and back-end services, and the Internet Protocol address (IPA) resolved from it is the unique identifier of the back-end server at the network layer. Furthermore, in most infrastructure management systems (such as configuration management databases), the IPA is also a key index field for virtual machine or physical server resources. Therefore, the IPA naturally becomes the link between the "application configuration domain" and the "infrastructure resource domain." In contrast, while domain names may correspond to multiple back-end servers through load balancing and hostnames may change, the IPA is relatively stable and can directly point to resource instances.

[0076] In this optional embodiment, the association process is an iterative process that traverses all generated proxy service configuration information records. Specifically, for each record, if its "Internet Protocol Address" field is not empty, the infrastructure information query interface can be called or a cached infrastructure dataset can be retrieved using its address as a parameter. If the query is successful, the returned virtual machine instance information dictionary is embedded as a whole object into the proxy service record; if the query fails or there is no address, the field is set to empty. Access status information is generated independently for each domain name during the detection phase, and then matched and associated with the proxy service record through the domain name, and embedded as a whole object into the record.

[0077] In this optional embodiment, the final data structure clearly presents the logical dependencies of the three layers of information: the top layer (application configuration layer) contains static configuration data parsed from the proxy service configuration file, defining the service access entry and routing rules, and is the starting point from the user's perspective; the middle layer (infrastructure layer) stores dynamic operation and maintenance context data obtained through Internet Protocol address association, revealing the resource ownership, responsible person, and physical location of the service, and is the core basis for operation and maintenance management; the bottom layer (real-time status layer) records dynamic health data obtained through active detection, reflecting the current actual performance of the service, and is the direct basis for monitoring, alarms, and troubleshooting. This hierarchical structure not only facilitates layered rendering and display of the front-end interface, but more importantly, it logically perfectly maps the thought process of operation and maintenance engineers in troubleshooting service failures: when a service anomaly is discovered, first check the status layer to confirm the problem phenomenon, then check whether the application layer configuration is correct, and finally delve into the infrastructure layer to verify whether the server resources are healthy. This provides operation and maintenance personnel with an efficient problem location navigation map, significantly shortening the time from fault discovery to root cause location.

[0078] Optionally, in some embodiments, the proxy service management method further includes: persistently storing proxy service configuration information, infrastructure information, and access status, wherein the persistent storage adopts a dual storage mechanism to support incremental data updates.

[0079] This optional embodiment emphasizes the importance of reliably storing all processed information to provide a data foundation for historical analysis, audit traceability, and long-term monitoring. Persistent storage refers to the process of saving processed structured data in memory as files to non-volatile storage media (such as hard disks).

[0080] In this optional embodiment, to ensure data security, availability, and ease of processing, a dual storage mechanism is adopted. Specifically, two complementary data formats can be used for storage: one is a structured data format, used to store complete, structured data, which has the advantages of self-description, good readability, and ease of parsing and generation by various programming languages. It is very suitable as the main working data storage format for programs and also facilitates data transfer between different systems, such as JSON format; the other is a tabular data format, used to export key field data into a general, simple tabular form. Its biggest advantage is that it can be directly opened by general data processing software (such as spreadsheet software), making it convenient for maintenance personnel to view offline, perform data pivoting, statistical analysis, generate reports, or share data with non-technical personnel, meeting diverse data processing needs, such as CSV format. Through this dual storage mechanism, the appropriate data format can be flexibly selected for operation in different scenarios, ensuring both structured data management and data universality and ease of use.

[0081] In this optional embodiment, "supporting incremental data updates" means that the storage mechanism does not simply overwrite the old file every time it runs, but intelligently identifies data changes and only updates the changed parts. Specifically, the implementation employs the following strategy: Existing data files (e.g., JSON files) are read and their contents deserialized into an in-memory data structure. For newly generated data records, a unique identifier (e.g., a combination of "domain name" and "proxy target path," or directly using the extracted "Internet Protocol address") is compared with existing records in memory. If it's a newly added proxy configuration, the new record is appended to the in-memory data structure. If it's an existing configuration, its associated infrastructure information or the latest access status field is updated. Finally, the updated in-memory data structure is reserialized and written back to the file, overwriting the original file. Simultaneously, based on the latest data, records are regenerated or appended to the corresponding table file (e.g., a CSV file). This incremental update mechanism reduces the complexity of file input / output operations, preserves the data change history, and makes the data traceable. Through standardized data models and standardized read / write processes, the dual storage mechanism ensures data consistency and durability, ensuring that management data is not lost due to program restarts, and provides a solid and reliable data foundation for establishing long-term service configuration baselines, analyzing access status trends, and auditing configuration change history.

[0082] Optionally, in some embodiments, the agent service management method further includes: performing information association, status detection, and visualization operations in batches through a batch processing engine.

[0083] In this optional embodiment, a batch processing mechanism is introduced to improve overall management efficiency to meet the actual needs of large-scale proxy service management. Specifically, the batch processing engine adopts a thread pool concurrency model. First, the system creates a fixed-size thread pool based on the list of proxy service configuration information to be processed and sets the maximum number of concurrent worker threads. This value can be dynamically adjusted according to server performance, network bandwidth, and target system load to achieve a balance between efficiency and stability. Second, the aforementioned single tasks such as "information association" and "status detection" are defined as independently executable function units. These functions encapsulate complete logic such as calling APIs, initiating HTTP requests, analyzing responses, and storing results. Next, the engine submits each proxy service configuration information item as a task to the thread pool for concurrent execution. The scheduler inside the thread pool is responsible for managing the distribution, execution, and result collection of tasks. To ensure the consistency of shared data (such as global statistical counters and storage files) in a concurrent environment, thread locks or atomic operations are used for synchronization control when updating these shared resources. Finally, the engine can also summarize the execution results of each thread to generate a batch processing report. This concurrent batch processing mechanism significantly reduces the overall execution time of association and detection tasks, which originally required sequential execution and had a total execution time equal to the sum of the execution times of each task, to a level close to that of the slowest single task. This significantly improves processing efficiency and response speed in large-scale service clusters, making periodic full status updates and real-time impact analysis possible.

[0084] See Figure 2 , Figure 2 This is a schematic diagram of an embodiment of the proxy service management device provided in this application. The proxy service management device 60 includes: a configuration parsing module 61, used to parse the proxy service configuration file and obtain proxy service configuration information; an address extraction module 62, used to extract the proxy target address from the proxy service configuration information; an information association module 63, used to associate the proxy target address with the infrastructure management system and obtain the corresponding infrastructure information; a status detection module 64, used to detect the access status of the front-end access entry based on the proxy service configuration information; and a visualization management module 65, used to visualize the proxy service configuration information, infrastructure information, and access status.

[0085] Optionally, in some embodiments, the proxy service configuration information includes a proxy target field and a domain name configuration field.

[0086] Optionally, in some embodiments, the configuration parsing module 61 is further configured to: scan the configuration file directory, identify service block configuration items in the proxy service configuration file; for each service block configuration item, use a state machine algorithm to track the state of the parsing process, and use a curly brace matching algorithm to parse the nested block structure, and extract the proxy target field and domain name configuration field from the service block configuration item.

[0087] Optionally, in some embodiments, the configuration parsing module 61 is further configured to: employ a recursive descent parsing algorithm to extract configuration information from nested blocks, starting from the service block configuration item and working downwards layer by layer.

[0088] Optionally, in some embodiments, the configuration parsing module 61 is further configured to: employ an intelligent annotation removal algorithm to distinguish between annotation content and string content by tracking the string status, and remove the annotation content.

[0089] Optionally, in some embodiments, the address extraction module 62 is further configured to: match multiple preset regular expression patterns in order of priority according to the proxy target field; in response to any regular expression pattern being successfully matched, extract the character sequence that conforms to the Internet Protocol address format as the proxy target address; in response to all regular expression patterns failing to match, determine the proxy target field as a non-Internet Protocol address format and filter it.

[0090] Optionally, in some embodiments, the preset multiple regular expression patterns include patterns that match at least two of the following protocol formats: Hypertext Transfer Protocol format, Secure Hypertext Transfer Protocol format, Dynamic Protocol format, and Pure Network Protocol address format. Each of the regular expression patterns supports address formats with or without port numbers.

[0091] Optionally, in some embodiments, the address extraction module 62 is further configured to: verify the validity of the extracted proxy target address and determine whether each segment of the proxy target address is within the value range of 0 to 255.

[0092] Optionally, in some embodiments, the information association module 63 is further configured to: call the application programming interface of the infrastructure management system, using the proxy target address as a query parameter; receive virtual machine instance information returned by the infrastructure management system corresponding to the proxy target address; and extract at least one of the following from the virtual machine instance information: business ownership information, person in charge information, hostname, data center location, and operating status, as infrastructure information.

[0093] Optionally, in some embodiments, the access status includes accessibility, login authentication requirements, and response time.

[0094] Optionally, in some embodiments, the status detection module 64 is further configured to: construct a Uniform Resource Locator based on the domain name configuration field and initiate an access request; determine the accessibility of the front-end access entry based on the response status code of the access request; analyze the response content of the access request and detect whether there are preset login features in the response content to determine whether the front-end access entry has login authentication requirements; and record the time interval from the initiation of the access request to the receipt of the response as the response time.

[0095] Optionally, in some embodiments, the state detection module 64 is further configured to: construct multiple Uniform Resource Locators concurrently using a thread pool, control the maximum concurrency, and concurrently initiate access requests to multiple front-end access points.

[0096] Optionally, in some embodiments, the state detection module 64 is further configured to: extract the page title and detect whether there is a preset login keyword in the page title; if there is no login keyword in the page title, detect whether there is a login keyword in the page content; if there is no login keyword in the page content, detect whether there is a form structure containing a password input box in the page.

[0097] Optionally, in some embodiments, the visualization management module 65 is further used to: associate and integrate the proxy service configuration information, infrastructure information and access status to form a service link view; and display the service link view on the application interface.

[0098] Optionally, in some embodiments, the visualization management module 65 is further configured to: associate the domain name configuration field in the proxy service configuration information with the virtual machine instance information in the infrastructure information using the proxy target address as the association key; associate the access status with the corresponding proxy service configuration information; and organize the associated information in a hierarchical structure, wherein the top layer is the proxy service configuration information, the middle layer is the association result between the proxy target address and the infrastructure information, and the bottom layer is the access status.

[0099] Optionally, in some embodiments, the proxy service management device 60 further includes a data storage module 66, which is used to persistently store proxy service configuration information, infrastructure information and access status. The persistent storage adopts a dual storage mechanism to support incremental data updates.

[0100] Optionally, in some embodiments, the agent service management device 60 further includes a batch processing module, which is used to perform information association, status detection and visualization operations in batches through a batch processing engine.

[0101] Since the embodiments of the device part correspond to the embodiments of the above method, the description of the agent service management device 60 provided in the embodiments of the present invention should refer to the above method embodiments. The embodiments of the present invention will not be described again here, but have the same beneficial effects as the above agent service management method.

[0102] See Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the storage medium provided in this application.

[0103] The storage medium 70 stores program data 71, which, when executed by the processor, implements, as follows: Figure 1 The described agency service management method.

[0104] The program data 71 is stored in a storage medium 70 and includes several instructions for causing a network device (such as a router, personal computer, or server) or processor to execute all or part of the steps of the methods described in the various embodiments of this application.

[0105] Optionally, the storage medium 70 can be any medium capable of storing program data 71, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), disk, or optical disc.

[0106] See Figure 4 , Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application.

[0107] The computer device 80 includes a processor 82 and a memory 81 interconnected. The memory 81 stores a computer program, and when the processor 82 executes the computer program, it implements, for example, Figure 1 The described agent service management method. The memory 81 may include the storage medium 70, or it may be another separately developed memory.

[0108] Unlike existing technologies, this application discloses a proxy service management method, apparatus, storage medium, and computer equipment. By automatically parsing proxy service configuration files and extracting key configuration information, associating it with infrastructure information, and simultaneously detecting the access status of the front-end access point, this method effectively solves the problems of lack of a unified view of configuration information, insufficient information transparency, and difficulty in deep parsing and correlation analysis in existing proxy service management methods. When facing large-scale and complex proxy service management needs, this method can quickly and accurately locate the root cause of problems, achieve comprehensive and refined management of proxy services, improve the reliability and maintainability of large-scale distributed systems, realize unified, transparent, and efficient management of proxy services, significantly improve the automation and intelligence level of proxy service management, enhance management efficiency, monitoring capabilities, and ease of operation and maintenance, reduce fault detection time and operation and maintenance costs, and promote the stable operation of distributed systems during enterprise digital transformation, providing strong support for the continuous development of enterprise business.

[0109] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments, storage medium embodiments, and computer device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0110] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for managing agency services, characterized in that, include: Parse the proxy service configuration file to obtain the proxy service configuration information; Extract the proxy target address from the proxy service configuration information; The proxy target address is associated with the infrastructure management system to obtain the corresponding infrastructure information; Based on the proxy service configuration information, detect the access status of the front-end access entry point; The proxy service configuration information, the infrastructure information, and the access status are displayed visually.

2. The agency service management method according to claim 1, characterized in that, The proxy service configuration information includes a proxy target field and a domain name configuration field; The step of parsing the proxy service configuration file to obtain proxy service configuration information includes: Scan the configuration file directory to identify service block configuration items in the proxy service configuration file; For each of the service block configuration items, a state machine algorithm is used to track the state of the resolution process, and a curly brace matching algorithm is used to parse the nested block structure, extracting the proxy target field and the domain name configuration field from the service block configuration items.

3. The agency service management method according to claim 2, characterized in that, Extracting the proxy target address from the proxy service configuration information includes: Based on the target field of the proxy, multiple preset regular expression patterns are used for matching in order of priority; In response to a successful match of any of the regular expression patterns, a character sequence conforming to the Internet Protocol address format is extracted as the proxy target address; In response to the failure of all the regular expression patterns to match, the proxy target field is determined to be a non-Internet Protocol address format and filtered.

4. The agency service management method according to claim 2, characterized in that, The access status includes accessibility, login authentication requirements, and response time; The step of detecting the access status of the front-end access entry point based on the proxy service configuration information includes: A Uniform Resource Locator (URL) is constructed based on the domain name configuration fields, and an access request is initiated. The accessibility of the front-end access entry is determined based on the response status code of the access request. Analyze the response content of the access request and detect whether there are preset login features in the response content to determine whether the front-end access entry has the login authentication requirement; The time interval from the initiation of the access request to the receipt of the response is recorded as the response time.

5. The agency service management method according to claim 1, characterized in that, The step of associating the proxy target address with the infrastructure management system to obtain the corresponding infrastructure information includes: Call the application programming interface of the infrastructure management system, using the proxy target address as a query parameter; Receive virtual machine instance information corresponding to the proxy target address returned by the infrastructure management system; Extract at least one of the following from the virtual machine instance information: business ownership information, person in charge information, hostname, data center location, and operating status, as the infrastructure information.

6. The agency service management method according to claim 1, characterized in that, The visualization of the proxy service configuration information, the infrastructure information, and the access status includes: The proxy service configuration information, the infrastructure information, and the access status are associated and integrated to form a service link view; The service chain view is displayed on the application interface.

7. The agency service management method according to claim 1, characterized in that, The agent service management method also includes: The proxy service configuration information, the infrastructure information, and the access status are persistently stored, wherein the persistent storage adopts a dual storage mechanism to support incremental data updates.

8. An agency service management device, characterized in that, include: The configuration parsing module is used to parse the proxy service configuration file and obtain the proxy service configuration information; The address extraction module is used to extract the proxy target address from the proxy service configuration information; The information association module is used to associate the proxy target address with the infrastructure management system to obtain the corresponding infrastructure information; The status detection module is used to detect the access status of the front-end access entry based on the proxy service configuration information; The visualization management module is used to visually display the proxy service configuration information, the infrastructure information, and the access status.

9. A storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, it implements the steps of the proxy service management method as described in any one of claims 1 to 7.

10. A computer device, characterized in that, It includes an interconnected processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the steps of the agent service management method as described in any one of claims 1 to 7.

Images