Network asset management-oriented monitoring index query method and electronic device

Abstract

The application provides a monitoring index query method for network asset management and an electronic device. The method comprises the following steps: maintaining an asset monitoring label mapping table in a network asset database; the mapping table comprises a plurality of records, each record stores a corresponding relationship between an asset identifier and a label key-value pair; there are at least two heterogeneous collector label key-value pairs for the same asset identifier, and the at least two heterogeneous collectors use different label key names to identify assets; receiving a single application programming interface request; for each index element, searching for a generated label filtering condition in the mapping table according to the asset identifier and constructing a query statement; merging each monitoring index data obtained by query to obtain a response data packet and returning. The application can solve the problems of high manual maintenance cost of multiple heterogeneous identification systems, new device mapping lag, and single request not supporting multiple index independent configuration in the multiple heterogeneous collector scene of the network management system.

Description

Technical Field

[0001] This invention relates to the field of monitoring data query technology, and in particular to a method and electronic device for querying monitoring indicators for network asset management. Background Technology

[0002] In modern data center and intelligent computing network management scenarios, multiple monitoring collectors are often deployed simultaneously, each responsible for collecting metrics from different types of devices and resources. Each collector uses a different tagging system to identify the monitored objects. The Network Manager System (NMS) uses asset identifiers as the core identifier to uniformly manage the business information of all devices.

[0003] In existing technologies, there are several main solutions for querying monitoring metrics: First, direct PromQL queries, where users need to manually write PromQL (Prometheus query language) or MetricsQL (VictoriaMetrics query language) statements to query the time-series database. Each request corresponds to only one metric, and the front end needs to make multiple independent requests to obtain complete panel data. Second, visualization platforms such as Grafana, which achieve multi-query concurrency by configuring Dashboard and Panel, but Panel configuration is strongly coupled with query statements, making configuration complex and inflexible. Third, existing tag management solutions, although providing a list of tags for users to select filtering conditions, still operate on tags as the object of operation. Users need to understand the underlying tag key-value pairs, and it is impossible to shield the tag system from the perspective of business assets. Moreover, each request still corresponds to a single metric and does not support mixed queries of multiple metrics. Fourth, dimension grouping batch query solutions, which achieve aggregation of metrics of the same dimension by establishing multi-level mapping caches through scenario coding and metric dimensions. However, its dimensions are statically pre-configured and cannot dynamically drive tag parsing based on business asset identifiers at runtime. Furthermore, all metrics in the same batch must share the same dimension and do not support specifying aggregation algorithms and time ranges for each metric independently.

[0004] Therefore, existing solutions have failed to solve the problem of automatic bridging of asset identifiers and heterogeneous monitoring tags, and are also unable to achieve mixed queries with independently configured indicators in a single request. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method and electronic device for querying monitoring indicators for network asset management, in order to eliminate or improve one or more defects existing in the prior art.

[0006] One aspect of the present invention provides a method for querying monitoring indicators for network asset management, the method comprising: An asset monitoring tag mapping table is maintained in the network asset database; wherein, the asset monitoring tag mapping table contains multiple records, each record storing the correspondence between an asset identifier and a tag key-value pair; and for the same asset identifier, the asset monitoring tag mapping table contains tag key-value pairs corresponding to at least two heterogeneous collectors, and at least two heterogeneous collectors use different tag key names to identify assets; Receive a single application programming interface (API) request containing an array of indicator configurations; wherein the indicator configuration array includes multiple indicator elements, and the indicator elements include asset identifiers and aggregation algorithms; For each indicator element in the indicator configuration array, a set of tag key-value pairs is retrieved from the asset monitoring tag mapping table according to the asset identifier corresponding to each indicator element, and tag filtering conditions corresponding to each indicator element are generated. Based on the label filtering conditions, construct query statements corresponding to each of the indicator elements; based on each of the query statements, concurrently query to obtain the monitoring indicator data corresponding to each of the indicator elements; merge the monitoring indicator data to obtain the response data packet corresponding to the API request and return it.

[0007] In some embodiments of the present invention, maintaining the asset monitoring tag mapping table in the network asset database includes at least one of the following: When writing or updating data to the asset database, a tag key-value pair is generated according to the collector type registry, and the tag key-value pair is written to the asset monitoring tag mapping table. Periodically query the asset monitoring tag mapping table to find the list of tag values ​​corresponding to assets with an empty status; write the tag key-value pairs that match the asset fields in the network asset database into the asset monitoring tag mapping table with an pending confirmation status.

[0008] In some embodiments of the present invention, the collector type registry is maintained in the network asset database, and the collector type registry records the mapping rules between the tag name and asset field of each collector type.

[0009] In some embodiments of the present invention, the indicator element further includes a time range parameter, which includes: supporting relative time range and absolute time range; wherein, the time range parameter corresponding to each indicator element is different.

[0010] In some embodiments of the present invention, after maintaining the asset monitoring tag mapping table in the network asset database, the method further includes: Perform a mapping health check step; wherein the mapping health check step includes at least one of the following: If it is detected that the tag key-value pair in the asset monitoring tag mapping table does not have corresponding indicator data in the network asset database and there is still no indicator data within a preset time period, then the corresponding status of the tag key-value pair is marked as abandoned. If a network asset satisfies the condition that the corresponding tag key-value pair exists in the network asset database and the tag key-value pair does not exist in the asset monitoring tag mapping table, then the network asset is written to the asset monitoring tag mapping table in a pending confirmation state. If the same tag key-value pair is detected to be mapped to multiple different asset identifiers, a conflict alarm message is generated.

[0011] In some embodiments of the present invention, after retrieving the set of tag key-value pairs from the asset monitoring tag mapping table based on the asset identifier corresponding to each of the indicator elements, the method further includes: The retrieved tag key-value pair set is cached in an in-memory database with an expiration date; when a change is detected in the field of the corresponding asset in the network asset database, the cache is automatically invalidated.

[0012] In some embodiments of the present invention, after constructing the query statements corresponding to each of the indicator elements based on the label filtering conditions, the method further includes: Calculate the parameter combination hash value of each indicator element and use it as the pre-stored hash value. Cache the query statement corresponding to the indicator configuration array and the pre-stored hash value corresponding to the query statement in the memory database. When an API request is received, the parameter combination hash value corresponding to the API request is calculated. If the parameter combination hash value is the same as the pre-stored hash value in the memory database, the query statement corresponding to the pre-stored hash value is directly obtained as the query statement of the API request.

[0013] In some embodiments of the present invention, the indicator element further includes a chart type. The step of concurrently querying each indicator element based on each query statement to obtain monitoring indicator data corresponding to each indicator element, merging the monitoring indicator data to obtain the response data packet corresponding to the API request, and returning it includes: The monitoring indicator data corresponding to each indicator element is obtained by concurrently querying each of the aforementioned query statements. The original time series data are format-converted according to the chart type corresponding to each of the aforementioned indicator elements. The converted original time series data are then merged to obtain the response data packet corresponding to the API request and returned. The chart type includes at least one of line chart, bar chart, area chart, dashboard, statistics, heat map, table, and scatter plot.

[0014] In some embodiments of the present invention, it further includes: Based on preset pre-calculation rules, target indicator calculations are performed according to a predetermined cycle to obtain pre-calculation results, and the pre-calculation results are stored as monitoring indicator data in a time-series database; When the indicator name corresponding to the indicator element is the same as the indicator name corresponding to the monitoring indicator data, the pre-calculated result corresponding to the monitoring indicator data is read from the time series database and used as the monitoring indicator data corresponding to the indicator element.

[0015] A second aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned monitoring indicator query method for network asset management.

[0016] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the aforementioned method for querying monitoring metrics for network asset management.

[0017] The fourth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the aforementioned method for querying monitoring metrics for network asset management.

[0018] This application provides a method for querying monitoring indicators for network asset management. The method includes: maintaining an asset monitoring tag mapping table in a network asset database; wherein the asset monitoring tag mapping table contains multiple records, each record storing the correspondence between an asset identifier and a tag key-value pair; and for the same asset identifier, the asset monitoring tag mapping table contains tag key-value pairs corresponding to at least two heterogeneous collectors, and the at least two heterogeneous collectors use different tag key names to identify the asset; receiving a single application programming interface (API) request containing an indicator configuration array; wherein the indicator configuration array includes multiple indicator elements, and the indicator elements include asset identifiers and aggregation algorithms; for each indicator element in the indicator configuration array, retrieving a set of tag key-value pairs from the asset monitoring tag mapping table according to the asset identifier corresponding to each indicator element, generating tag filtering conditions corresponding to each indicator element; constructing query statements corresponding to each indicator element based on the tag filtering conditions; concurrently querying the monitoring indicator data corresponding to each indicator element based on each query statement, merging the monitoring indicator data to obtain the response data packet corresponding to the API request, and returning it. By designing an automatic mapping mechanism for monitoring tags, hybrid queries driven by asset identifiers can be achieved, lowering the barrier to entry. Through automatic mapping, pre-calculation, and unified format conversion on the backend, query logic is centrally managed, reducing client development and maintenance complexity and improving query performance. By caching asset tag mapping results in an in-memory database, high-frequency database queries are avoided, reducing query latency, and a continuous inspection mechanism is designed to ensure the validity of the mapping relationship. Users do not need to understand the details of heterogeneous tags; asset IDs can be queried with one click, and multi-indicator hybrid queries can be completed in a single request, lowering the barrier to entry and reducing the number of network requests.

[0019] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0020] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a monitoring indicator query method for network asset management according to one embodiment of this application.

[0022] Figure 2 This is a flowchart automatically generated by the system, as exemplified in one of the examples in this application.

[0023] Figure 3 This is a flowchart illustrating the automatic discovery process in one example of this application.

[0024] Figure 4 This is a flowchart illustrating a multi-indicator mixed query example from this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0026] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0027] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0028] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0029] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0030] Currently, existing technologies have the following drawbacks: 1. In NMS scenarios, asset identifiers and monitoring tags exhibit structural heterogeneity, and existing solutions cannot automatically bridge them: In a network asset management system, the same physical asset is often collected simultaneously by multiple heterogeneous collectors, each using a completely different tagging system to identify the same asset. node_exporter (Prometheus' official server operating system metrics collector) uses instance names in the form of IP addresses, i.e., port numbers, as tags to identify hosts. ); dcgm_exporter (NVIDIA's official Graphics Processing Unit (GPU) metrics collector) uses hostname And a universally unique identifier (UUID). Identify the GPU; Self-developed data collectors may use Identification switch.

[0031] The aforementioned tag keys and tag value sources (Internet Protocol (IP), hostname, UUID, serial number) are all different, and these values ​​are scattered across different fields in the NMS asset database. Existing tag management solutions only maintain a list of available tags and cannot perceive the cross-system mapping relationship of "which asset corresponds to which tag value of which collector." Furthermore, the dimensions in existing dimensional grouping solutions are statically pre-configured, making it impossible to dynamically derive tag filtering conditions for heterogeneous collectors at runtime based on asset identifiers (identity, ID). Therefore, operations and maintenance personnel must manually search for and enter the correct tag values ​​when querying, which is highly error-prone, and requires manual synchronization of the query configuration in scenarios such as asset IP changes or GPU replacements.

[0032] Second shortcoming: A single request only supports a single metric or a single configuration. Existing monitoring application programming interfaces (APIs) typically support only one query per request, returning data for only one metric per API call. When a front-end dashboard needs to display an asset's CPU usage, memory usage, and network traffic (three different chart types and different time ranges), three independent requests are required, increasing network overhead and front-end complexity. While existing batch query solutions support aggregation of metrics within the same dimension, they require metrics in the same batch to share the same dimension and time range, and do not support specifying aggregation algorithms, time ranges, and chart types for each metric independently.

[0033] Third shortcoming: Complex aggregated metrics are difficult to query. Some business metrics (such as "GPU memory utilization = used memory / total memory × 100%)" require multiple calculations on the original metrics. Directly querying the time-series database requires performing a complete aggregation calculation each time, resulting in high query latency.

[0034] Shortcoming 4: The logic for converting chart types and data formats is scattered. The front-end needs to process the same raw time-series data in different formats for different chart types such as line charts, bar charts, and dashboards. The logic is scattered in the front-end code and is difficult to reuse.

[0035] Therefore, in order to address the problems of high manual maintenance costs of multiple heterogeneous identification systems, delayed mapping of new devices, and lack of support for independent configuration of multiple indicators in a single request in the context of multiple heterogeneous collectors in network management systems, the embodiments of this application provide a monitoring indicator query method, electronic device, computer-readable storage medium, and computer program product for network asset management, respectively, to reduce network requests and improve query performance, and realize multi-indicator hybrid query driven by asset identification.

[0036] The following examples will provide a detailed description.

[0037] Based on this, embodiments of this application provide a method for querying monitoring indicators for network asset management that can be executed by a monitoring indicator query device for network asset management. See [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Maintain an asset monitoring tag mapping table in the network asset database; wherein the asset monitoring tag mapping table contains multiple records, each record storing the correspondence between an asset identifier and a tag key-value pair; and for the same asset identifier, the asset monitoring tag mapping table contains tag key-value pairs corresponding to at least two heterogeneous collectors, and at least two heterogeneous collectors use different tag key names to identify assets.

[0038] Specifically, the asset monitoring label mapping table (asset_metric_labels) records the label correspondence between each asset and each type of collector. It includes the following fields: primary key ID, asset ID (asset_id, foreign key), collector type, label key (label_key), label value (label_value), source (AUTO_DISCOVERED and SYSTEM_GENERATED), status (ACTIVE, PENDING_CONFIRM, and DEPRECATED), creation time, and update time, as shown in Table 1. Besides relational databases, the mapping table can also be stored using graph databases (such as Neo4j) to store the relationships between assets and collector instances, offering higher query efficiency and equivalent results.

[0039] Table 1 Asset Monitoring Tag Mapping Table Step 200: Receive a single application programming interface (API) request containing an array of indicator configurations; wherein the indicator configuration array includes multiple indicator elements, and the indicator elements include asset identifiers and aggregation algorithms.

[0040] It should also be noted that the defined query API request accepts an array of metric configurations as the request body. Each metric element in the array includes: metric name (metricName), asset ID (assetId), chart type (chartType, which can be line chart, bar chart, area chart, dashboard, statistics, heatmap, table, scatter plot, etc., as shown in Table 2), aggregation algorithm (aggregation, which can be avg, sum, max, min, last, count, "p50 / p90 / p95 / p99", rate, and increase, etc., as shown in Table 3), time range (supports relative and absolute time), and optional additional label filters (labelFilters). The number of chart types and aggregation algorithms can be expanded according to actual needs, while the technical framework remains unchanged.

[0041] Table 2 Chart Types Table 3 Aggregation Algorithm Step 300: For each indicator element in the indicator configuration array, retrieve the set of tag key-value pairs from the asset monitoring tag mapping table according to the asset identifier corresponding to each indicator element, and generate the tag filtering conditions corresponding to each indicator element.

[0042] Understandably, by maintaining an asset monitoring tag mapping table in the asset database, asset identifiers are translated into tag filtering conditions required by the time-series database, thus shielding users from the underlying details. In the indicator data storage backend, such as Prometheus or VictoriaMetrics, indicator queries require using the indicator name (metricsName) plus a set of tag filters. Multiple combinations of label_key=label_value pairs (i.e., a set of tag key-value pairs) are used to filter out monitoring indicator sequences that meet the conditions. Therefore, in multi-indicator mixed queries, the setting of the tag key-value combination determines the final sequence of monitoring indicators retrieved. How to configure the tag key-value combination is a crucial aspect of monitoring query display.

[0043] Step 400: Construct query statements corresponding to each of the indicator elements based on the label filtering conditions; concurrently query the monitoring indicator data corresponding to each of the indicator elements based on each of the query statements; merge the monitoring indicator data to obtain the response data packet corresponding to the API request and return it.

[0044] Specifically, the response body (i.e., the response data) contains a result array that corresponds one-to-one with the indicator configuration array in the request. Each result element contains the indicator name, asset ID, chart type, and data fields. The structure of the data fields is determined by the chart type: time-series charts (line charts, bar charts, area charts) return an array of timestamps and multiple time-series sequences, each sequence containing a set of labels and a corresponding array of values; single-value charts (dashboards, statistics) return a single aggregate value and unit; two-dimensional charts (heatmaps) return a time axis, a label axis, and a value matrix; and tabular charts return column definitions and row data.

[0045] As described above, the monitoring indicator query method for network asset management provided in this application embodiment enables hybrid queries driven by asset identifiers by designing an automatic mapping mechanism for monitoring tags, thus lowering the barrier to entry. Through automatic mapping, pre-calculation, and unified backend format conversion, the query logic is centrally managed, reducing client development and maintenance complexity and improving query performance. By caching the asset tag mapping results in an in-memory database, high-frequency database queries are avoided, reducing query latency, and a continuous inspection mechanism is designed to ensure the validity of the mapping relationship. Users do not need to understand the details of heterogeneous tags; asset IDs can be queried with one click, and a single request completes a hybrid query of multiple indicators, lowering the barrier to entry and reducing the number of network requests.

[0046] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, in a monitoring indicator query method for network asset management provided in this application embodiment, step 100, which involves maintaining an asset monitoring tag mapping table in the network asset database, specifically includes at least one of the following: When writing or updating data to the asset database, a tag key-value pair is generated according to the collector type registry, and the tag key-value pair is written to the asset monitoring tag mapping table. Periodically query the asset monitoring tag mapping table to find the list of tag values ​​corresponding to assets with an empty status; write the tag key-value pairs that match the asset fields in the network asset database into the asset monitoring tag mapping table with an pending confirmation status.

[0047] Specifically, there are two ways to establish the asset monitoring tag mapping table: Method 1 (automatic system generation): When a write or update event occurs in the asset database, all ONE_TO_ONE types in the collector type registry are traversed, and tag key-value pairs are generated according to the template rules. These pairs are then written to the mapping table (status=ACTIVE), and the corresponding entries in the in-memory database (such as Redis) cache are invalidated. This method ensures that the mapping relationship is automatically synchronized after operations such as asset IP changes. Method 2 (automatic discovery): A scheduled task queries the mapping table to find assets without ACTIVE entries. It queries the label_value interface of the monitoring data storage backend that supports tag value queries to obtain a list of all existing instance names or hostnames. These values ​​are then matched with asset fields (IP, hostname, etc.) (IP for exact matching or hostname for case-insensitive matching). Successfully matched entries are written to the mapping table with status=PENDING_CONFIRM and displayed to the operations and maintenance personnel for confirmation on the NMS interface. After confirmation, the status is updated to ACTIVE. In addition to Redis, the mapping results can also be cached using local memory caching (such as in-process caching), which is equivalent in a single-instance deployment scenario.

[0048] In one example, the system automatically generates a process such as Figure 2 As shown, the automatic discovery process is as follows: Figure 3 As shown.

[0049] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, in a monitoring indicator query method for network asset management provided in this application embodiment, the collector type registry is maintained in the network asset database, and the collector type registry records the mapping rules between the tag names of each collector type and the asset fields.

[0050] Specifically, it includes a pre-configured and expandable collector type registry. Each collector type includes: a type name (collector_type), a label name (label_name), a mapping rule from the label name to the asset field (label_mapping_rules), and an asset correspondence (one-to-one), supporting template expressions such as "{asset.ip}:9100". For example, the instance label value for node_exporter consists of the asset IP field plus the port; the Hostname label value for dcgm_exporter corresponds to the asset hostname field, and the gpu_uuid label needs to be manually configured. Here, switch represents a switch, and switch_id is the unique identifier for the switch.

[0051] Table 4. Collector Type Registry To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid query driven by asset identifiers, a monitoring indicator query method for network asset management provided in this application embodiment includes a time range parameter for each indicator element. The time range parameter supports both relative and absolute time ranges. The time range parameter is different for each indicator element.

[0052] Specifically, when different time ranges are specified for each metric configuration element, the backend independently assigns its time range context (start time, end time, and time interval step) to each metric during concurrent execution. The query results for each metric are returned independently based on its own time range. The query results for each metric element in the response body carry metadata about the actual queried time range. Furthermore, the result data includes a timestamp and the corresponding time point, and the corresponding timestamp must fall within the queried time range. The frontend can directly render and display based on the timestamp range, or it can extract the start, end, or step as parameters for the dashboard. This feature of inconsistent time ranges makes the entire monitoring dashboard more flexible, allowing some metrics to display 24 hours of data while others may only require the most recent 30 minutes. This supports displaying metrics with different time granularities on the same dashboard simultaneously (such as the CPU real-time curve for the past hour and the disk usage trend for the past 30 days).

[0053] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, the monitoring indicator query method for network asset management provided in this application embodiment includes the following specific content after step 100 and after maintaining the asset monitoring tag mapping table in the network asset database: Perform a mapping health check step; wherein the mapping health check step includes at least one of the following: If it is detected that the tag key-value pair in the asset monitoring tag mapping table does not have corresponding indicator data in the network asset database and there is still no indicator data within a preset time period, then the corresponding status of the tag key-value pair is marked as abandoned. If a network asset satisfies the condition that the corresponding tag key-value pair exists in the network asset database and the tag key-value pair does not exist in the asset monitoring tag mapping table, then the network asset is written to the asset monitoring tag mapping table in a pending confirmation state. If the same tag key-value pair is detected to be mapped to multiple different asset identifiers, a conflict alarm message is generated.

[0054] Specifically, regular health checks are performed to detect three types of anomalies: First, isolated mappings: mappings exist but there is no corresponding indicator data in the time series database within 30 days, and the status is marked as DEPRECATED; second, isolated assets: assets exist in the asset database but there are no collector mappings in the mapping table, triggering automatic discovery or generating pending tasks; third, tag conflicts: the same tag key-value pair is mapped to multiple different asset IDs, generating conflict alarms that require manual adjudication.

[0055] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, in a monitoring indicator query method for network asset management provided in this application embodiment, after retrieving the set of tag key-value pairs from the asset monitoring tag mapping table according to the asset identifiers corresponding to each indicator element in step 300, the method further includes the following: The retrieved tag key-value pair set is cached in an in-memory database with an expiration date; when a change is detected in the field of the corresponding asset in the network asset database, the cache is automatically invalidated.

[0056] Specifically, forward queries take asset_id and optional collector_type as input and return a list of corresponding label filters. The query results are cached in an in-memory database (Time To Live, TTL, i.e., validity period = 5 minutes). A reverse query is also set up, taking label_key and label_value as input and returning the corresponding asset_id for reverse tracing scenarios such as alarm notification (Trap) processing and alarm correlation.

[0057] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, in a monitoring indicator query method for network asset management provided in this application embodiment, after constructing the query statements corresponding to each indicator element based on the tag filtering conditions in step 400, the method further includes the following: Step 410: Calculate the parameter combination hash value of each indicator element and use it as the pre-stored hash value. Cache the query statement corresponding to the indicator configuration array and the pre-stored hash value corresponding to the query statement in the memory database. Step 420: When an API request is received, calculate the parameter combination hash value corresponding to the API request. If the parameter combination hash value is the same as the pre-stored hash value in the memory database, then directly obtain the query statement corresponding to the pre-stored hash value as the query statement of the API request.

[0058] Specifically, hybrid queries employ query caching. For the same combination of metric parameters and the query time range (timeRange), the resulting MetricsQL query, after label mapping and statement construction, is cached in an in-memory database using the hash value of the request parameters as the key. The TTL is consistent with the label mapping cache. Subsequent identical requests directly reuse the cached query, skipping the label mapping and statement construction steps, reducing CPU parsing overhead. This is particularly effective for high-frequency repetitive requests (such as timed dashboard refreshes). Concurrent execution of hybrid queries can be achieved using asynchronous coroutines (such as Gogoroutines or Python asyncio) in addition to thread pools, with equivalent results.

[0059] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, a monitoring indicator query method for network asset management provided in this application embodiment includes a chart type as an indicator element in step 400. The method involves concurrently querying each indicator element based on its respective query statement to obtain monitoring indicator data corresponding to each indicator element, merging the monitoring indicator data to obtain the response data packet corresponding to the API request, and returning it. Specifically, this includes the following: Step 430: Based on each of the query statements, concurrently query to obtain the monitoring indicator data corresponding to each of the indicator elements; Step 440: Convert the format of each original time series data according to the chart type corresponding to each of the indicator elements, merge the converted original time series data to obtain the response data packet corresponding to the API request and return it; wherein, the chart type includes at least one of line chart, bar chart, area chart, dashboard, statistics, heat map, table and scatter plot.

[0060] Specifically, this involves multimodal result post-processing driven by chart type. Different chart types have fundamentally different requirements for data structure: line charts, bar charts, and area charts require timestamp arrays plus multiple time series; dashboards and statistics require single aggregate values; heatmaps require a two-dimensional time-label matrix; and tables require a row-column structure. An independent result converter is implemented for each chart type on the backend. The query results for each indicator are processed by the corresponding converter before being returned, and finally merged into a single response. The frontend can obtain the data structures required for different charts of multiple indicators for the same asset with a single request, eliminating the need for data format conversion on the client side. The chart format conversion logic is migrated from the frontend to the backend; the frontend only needs to call the standard rendering interface, without needing to write format conversion code for different chart types, thus reducing the complexity of client-side development and maintenance.

[0061] Understandably, upon receiving a request, the backend executes the following sequentially: receiving the API request, generating tag filtering conditions based on the asset monitoring tag mapping table, constructing the query statement, concurrently querying to obtain monitoring metric data, converting the format according to the chart type, and merging the results into a unified response body and returning it. The concurrent execution of all metric queries means the total latency depends on the slowest single query, not the sum of all query times.

[0062] In one example, the process for multi-indicator mixed queries is as follows: Figure 4 As shown.

[0063] To further reduce network requests and improve query performance, and to achieve multi-indicator hybrid queries driven by asset identifiers, the monitoring indicator query method for network asset management provided in this application embodiment also specifically includes the following: Step 500: Based on the preset pre-calculation rules, perform target indicator calculations according to a predetermined cycle to obtain pre-calculation results, and store the pre-calculation results as monitoring indicator data in the time series database; Step 600: When the indicator name corresponding to the indicator element is the same as the indicator name corresponding to the monitoring indicator data, the pre-calculated result corresponding to the monitoring indicator data is read from the time series database and used as the monitoring indicator data corresponding to the indicator element.

[0064] Specifically, for complex metrics requiring multi-step computation (such as GPU memory usage), a rule evaluation component (vmalert) is deployed in VictoriaMetrics, and pre-calculated rules (Recording Rules) are configured to pre-calculate and store the data as new metrics, i.e., monitoring metrics. Queries directly read the pre-calculated metrics, achieving the same query performance as new metrics, and remaining completely transparent to the upper-level query API.

[0065] It's understandable that deploying vmalert and configuring Recording Rules in VictoriaMetrics, besides vmalert, can also utilize Prometheus's built-in recording rules functionality, achieving equivalent results in scenarios using Prometheus as the timing library. Example: GPU memory usage = (used / total) * 100, expressed as follows: - record: gpu_memory_usage_percent expr: (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) * 100 Here, DCGM_FI_DEV_FB_USED represents the amount of GPU memory used, DCGM_FI_DEV_FB_TOTAL represents the total amount of GPU memory, and gpu_memory_usage_percent represents the new metric. vmalert executes the above expression periodically according to the configuration and writes the result as the new metric to VictoriaMetrics.

[0066] To further illustrate the above embodiments, this application also provides a specific application example of a monitoring indicator query method for network asset management, which specifically includes the following: This application example aims to provide a hybrid monitoring metric query API for business assets, achieving the following: 1. Maintain the mapping rules between collector types and tag key-value sources in the NMS asset database. Use the asset ID as the runtime input parameter to dynamically derive the tag filtering conditions required by each heterogeneous collector (such as node_exporter, dcgm_exporter, etc.), completely shielding the heterogeneity of the underlying tag system. 2. A single API request carries multiple indicator configuration arrays, with each indicator element independently specifying the chart type, aggregation algorithm, and time range. After concurrent execution by the backend, they are merged into a single response body. 3. By using a pre-computation (Recording Rules) mechanism, the calculation results of complex aggregated indicators are persisted as new indicators, which can be read directly during queries, eliminating the overhead of repeated calculations; 4. Unify chart type mapping and centralize data format processing logic in the backend to simplify frontend implementation.

[0067] The core principle of this application example consists of two layers: The first layer is the automatic mapping from asset IDs to monitoring tags. By maintaining an asset monitoring tag mapping table in the asset database, business asset identifiers are translated into tag filtering conditions required by the time-series database, shielding users from the underlying details. The second layer is a hybrid query execution engine that accepts a single request containing multiple independent indicator configurations. After concurrently querying all indicators, it converts the data according to their respective specified chart types and merges them into a unified response body for return.

[0068] The advantages of this application example compared to existing technologies are as follows: 1. Lower the barrier to entry: Operations and maintenance personnel only need to know the asset ID and metric name, without needing to understand the Prometheus tag system.

[0069] 2. Reduce the number of network requests: Return multiple metrics data in a single request, reducing the number of interactions between the front-end and back-end and improving page loading performance.

[0070] 3. Centralized management of query logic: Chart type mapping, format conversion, and tag parsing are all handled uniformly on the backend, resulting in concise frontend code.

[0071] 4. Cache optimization performance: Asset tag mapping results are cached in an in-memory database to avoid high-frequency database queries and reduce query latency.

[0072] 5. Transparency of complex metrics: Through pre-calculation, the query performance of complex aggregated metrics is the same as that of simple metrics.

[0073] 6. Flexible Expansion: The manual labelFilters overriding mechanism supports special scenarios without disrupting the overall query framework.

[0074] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the monitoring indicator query method for network asset management mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0075] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0076] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the monitoring indicator query method for network asset management in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the monitoring indicator query method for network asset management in the above method embodiments.

[0077] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0078] The one or more modules are stored in the memory, and when executed by the processor, the monitoring indicator query method for network asset management in the embodiment is executed.

[0079] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0080] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0081] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0082] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned monitoring indicator query method for network asset management. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0083] This application also provides a computer program product, specifically including a computer program that, when executed by a processor, implements the steps of the monitoring indicator query method for network asset management mentioned in the foregoing embodiments.

[0084] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0085] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0086] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0087] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for querying monitoring indicators for network asset management, characterized in that, The method includes: An asset monitoring tag mapping table is maintained in the network asset database; wherein, the asset monitoring tag mapping table contains multiple records, each record storing the correspondence between an asset identifier and a tag key-value pair; and for the same asset identifier, the asset monitoring tag mapping table contains tag key-value pairs corresponding to at least two heterogeneous collectors, and at least two heterogeneous collectors use different tag key names to identify assets; Receive a single application programming interface (API) request containing an array of indicator configurations; wherein the indicator configuration array includes multiple indicator elements, and the indicator elements include asset identifiers and aggregation algorithms; For each indicator element in the indicator configuration array, a set of tag key-value pairs is retrieved from the asset monitoring tag mapping table according to the asset identifier corresponding to each indicator element, and tag filtering conditions corresponding to each indicator element are generated. Based on the label filtering conditions, construct query statements corresponding to each of the indicator elements; based on each of the query statements, concurrently query to obtain the monitoring indicator data corresponding to each of the indicator elements; merge the monitoring indicator data to obtain the response data packet corresponding to the API request and return it.

2. The monitoring indicator query method for network asset management according to claim 1, characterized in that, Maintaining the asset monitoring tag mapping table in the network asset database includes at least one of the following: When writing or updating data to the asset database, a tag key-value pair is generated according to the collector type registry, and the tag key-value pair is written to the asset monitoring tag mapping table. Periodically query the asset monitoring tag mapping table to find the list of tag values ​​corresponding to assets with an empty status; write the tag key-value pairs that match the asset fields in the network asset database into the asset monitoring tag mapping table with an pending confirmation status.

3. The monitoring indicator query method for network asset management according to claim 2, characterized in that, The collector type registry is maintained in the network asset database, and the collector type registry records the mapping rules between the tag name and asset field of each collector type.

4. The monitoring indicator query method for network asset management according to claim 1, characterized in that, The indicator elements also include time range parameters, which support both relative and absolute time ranges; wherein, the time range parameters corresponding to each indicator element are different.

5. The monitoring indicator query method for network asset management according to claim 1, characterized in that, After maintaining the asset monitoring tag mapping table in the network asset database, the following is also included: Perform a mapping health check step; wherein the mapping health check step includes at least one of the following: If it is detected that the tag key-value pair in the asset monitoring tag mapping table does not have corresponding indicator data in the network asset database and there is still no indicator data within a preset time period, then the corresponding status of the tag key-value pair is marked as abandoned. If a network asset satisfies the condition that the corresponding tag key-value pair exists in the network asset database and the tag key-value pair does not exist in the asset monitoring tag mapping table, then the network asset is written to the asset monitoring tag mapping table in a pending confirmation state. If the same tag key-value pair is detected to be mapped to multiple different asset identifiers, a conflict alarm message is generated.

6. The monitoring indicator query method for network asset management according to claim 1, characterized in that, After retrieving the set of tag key-value pairs from the asset monitoring tag mapping table based on the asset identifier corresponding to each of the aforementioned indicator elements, the method further includes: The retrieved tag key-value pair set is cached in an in-memory database with an expiration date; when a change is detected in the field of the corresponding asset in the network asset database, the cache is automatically invalidated.

7. The monitoring indicator query method for network asset management according to claim 1, characterized in that, After constructing the query statements corresponding to each of the indicator elements based on the label filtering conditions, the method further includes: Calculate the parameter combination hash value of each indicator element and use it as the pre-stored hash value. Cache the query statement corresponding to the indicator configuration array and the pre-stored hash value corresponding to the query statement in the memory database. When an API request is received, the parameter combination hash value corresponding to the API request is calculated. If the parameter combination hash value is the same as the pre-stored hash value in the memory database, the query statement corresponding to the pre-stored hash value is directly obtained as the query statement of the API request.

8. The monitoring indicator query method for network asset management according to claim 1, characterized in that, The indicator elements also include chart types. The process of concurrently querying each indicator element based on the query statements to obtain monitoring indicator data corresponding to each indicator element, merging the monitoring indicator data to obtain the response data packet corresponding to the API request, and returning it includes: The monitoring indicator data corresponding to each indicator element is obtained by concurrently querying each of the aforementioned query statements. The original time series data are format-converted according to the chart type corresponding to each of the aforementioned indicator elements. The converted original time series data are then merged to obtain the response data packet corresponding to the API request and returned. The chart type includes at least one of line chart, bar chart, area chart, dashboard, statistics, heat map, table, and scatter plot.

9. The monitoring indicator query method for network asset management according to claim 1, characterized in that, Also includes: Based on preset pre-calculation rules, target indicator calculations are performed according to a predetermined cycle to obtain pre-calculation results, and the pre-calculation results are stored as monitoring indicator data in a time-series database; When the indicator name corresponding to the indicator element is the same as the indicator name corresponding to the monitoring indicator data, the pre-calculated result corresponding to the monitoring indicator data is read from the time series database and used as the monitoring indicator data corresponding to the indicator element.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the monitoring indicator query method for network asset management as described in any one of claims 1 to 9.

Images