Marketing operation and maintenance abnormity positioning system based on business and technical index fusion

Abstract

The invention discloses a marketing operation and maintenance abnormity positioning system based on business and technical index fusion. A configuration information acquisition module is used for establishing a mapping association basis of business indexes and technical indexes; the index data acquisition module is used for acquiring technical architecture operation indexes and business process key node indexes in parallel based on the mapping association basis established by the configuration information acquisition module to form a fusion type index data set and storing the fusion type index data set to a monitoring database; the monitoring display module is used for calling the fusion type index data set in the monitoring database, and displaying the dynamic association relationship between the business indexes and the corresponding technical indexes in a linkage manner through the same view; the alarm module performs linkage verification based on the association relationship displayed by the monitoring display module, triggers an alarm and pushes the alarm to related personnel; the anomaly positioning module is used for performing traceability analysis on the associated indexes in the fusion type index data set and positioning the source corresponding to the anomaly; according to the invention, the problems of weak association, difficult analysis, slow positioning and the like caused by service and index separation in the prior art can be solved.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance monitoring technology, and more specifically to a marketing operation and maintenance anomaly location system based on the integration of business and technical indicators. Background Technology

[0002] Currently, in the current marketing operations and maintenance work, the separation between business indicators and technical indicators is becoming increasingly prominent, bringing many problems to the stable operation and efficient maintenance of the marketing management system, and the demand for operation and maintenance technology that can integrate the two is becoming more and more urgent.

[0003] The lack of an effective mapping mechanism between business metrics and technical metrics has created a formidable information barrier. Business metrics such as marketing campaign engagement and order conversion rates, which are monitored by the business department, are independent of technical metrics such as server load and database response time, lacking a direct correlation. When business metrics experience abnormal fluctuations, operations personnel often find themselves in a predicament, struggling to quickly pinpoint the related technical factors. For example, when engagement in an online marketing campaign suddenly drops sharply, operations personnel cannot quickly determine whether it's due to insufficient server bandwidth causing slow page loading or inefficient database queries affecting the timely retrieval of user data. This information disconnect severely delays problem-solving and can potentially cause significant business losses.

[0004] The inefficiency of anomaly localization is a major pain point in existing marketing operations and maintenance systems. When business anomalies occur, due to the lack of integrated indicator datasets and effective source tracing algorithms, operations and maintenance personnel often have to rely on personal experience to troubleshoot step by step through complex technical architectures and cumbersome business processes. This process is time-consuming, labor-intensive, and its accuracy is difficult to guarantee. For example, when customers report order processing delays, operations and maintenance personnel need to check multiple aspects in turn, such as whether there are vulnerabilities in the business logic, whether there are abnormalities in database operations, and whether network transmission is smooth. However, it is difficult to quickly determine whether the root cause of the problem is a database deadlock, network congestion, or a logical error in the business code. This seriously affects the normal operation of the business and customer experience.

[0005] Therefore, how to improve the operational efficiency and stability of the marketing management system by integrating business and technical indicators is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] In view of this, the present invention provides a marketing operation and maintenance anomaly location system based on the integration of business and technical indicators, which can solve the problems of weak correlation, difficult analysis, and slow location caused by the separation of business and indicators in the prior art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A marketing operations and maintenance anomaly location system based on the integration of business and technical indicators includes a configuration information acquisition module, an indicator data collection module, a monitoring and display module, an alarm module, and an anomaly location module.

[0009] The configuration information acquisition module is used to synchronously acquire the technical architecture configuration information of the marketing management system and the database monitoring configuration information associated with the business processes, and to establish a mapping and association basis between business indicators and technical indicators.

[0010] The indicator data acquisition module is used to collect technical architecture operation indicators and key node indicators of business processes in parallel based on the mapping and association established by the configuration information acquisition module, forming a fusion indicator dataset and storing it in the monitoring database.

[0011] The monitoring and display module is used to retrieve the integrated indicator dataset from the monitoring database and display the dynamic relationship between business indicators and corresponding technical indicators through the same view, providing a basis for integrated analysis for alarm judgment and anomaly location.

[0012] The alarm module is used to link abnormal business indicators with corresponding technical indicator thresholds based on the correlation displayed by the monitoring and display module, trigger multi-level alarms and push them to relevant personnel.

[0013] The anomaly location module is used to receive the alarm information from the alarm module and then perform source tracing analysis on the related indicators in the fusion indicator dataset using a preset algorithm to locate the technical root cause of the business anomaly.

[0014] Preferably, the configuration information acquisition module includes an automatic acquisition submodule, a manual configuration submodule, and a configuration storage submodule;

[0015] The automatic acquisition submodule is used to retrieve the configuration information of the marketing management system's host, microservice instances, and application load from the configuration management center via an interface protocol;

[0016] The manual configuration submodule is used to receive business database connection information, monitoring statements corresponding to business monitoring indicators, monitoring statements corresponding to technical monitoring indicators, monitoring statements corresponding to security monitoring indicators, and network link detection parameters input by operation and maintenance personnel.

[0017] The configuration storage submodule is used to integrate automatically acquired and manually configured information into application infrastructure information, store it in a local database, and synchronize it to the indicator data acquisition module.

[0018] Preferably, the manual configuration submodule includes an indicator statement verification unit, which is used to perform syntax verification and execution testing on the input monitoring statement to ensure that the statement can normally obtain indicator data such as automatic meter reading rate, fee calculation rate, and number of long transactions from the business database.

[0019] Preferably, the indicator data acquisition module includes a task scheduling submodule, a multi-source acquisition submodule, and a data cleaning submodule;

[0020] The task scheduling submodule is used to set the collection period according to the indicator type in the configuration information and generate timed collection tasks.

[0021] The multi-source acquisition submodule is used to acquire microservice application metrics by simulating access, acquire business metrics, technical metrics, and security metrics by querying the database, and acquire network routing and latency data by network detection tools, according to the acquisition task.

[0022] The data cleaning submodule is used to standardize the format of the collected raw data, remove invalid values, and then write the data into the monitoring database.

[0023] Preferably, the multi-source acquisition submodule includes an abnormal retry unit. When the acquisition task fails, the retry mechanism is automatically triggered. If it still fails, the failure log is recorded and pushed to the alarm module.

[0024] Preferably, the monitoring and display module includes an indicator visualization submodule and a scene aggregation submodule;

[0025] The indicator visualization submodule is used to convert single-dimensional indicators such as host CPU utilization and network packet loss rate into line charts and dashboard charts to show the trend of indicator changes over time.

[0026] The scenario aggregation submodule is used to integrate related business layer indicators, application layer indicators, and infrastructure layer indicators into a panoramic view based on the core business scenarios of meter reading and billing and electricity fee collection.

[0027] Preferably, the alarm module includes a threshold configuration submodule, a level classification submodule, and a notification distribution submodule;

[0028] The threshold configuration submodule is used to receive the response time upper limit and consecutive anomaly number threshold parameters set by the user, and supports individual configuration according to the indicator type.

[0029] The classification submodule is used to classify alarm information according to the degree of anomaly;

[0030] The notification distribution submodule is used to send alarm information of different levels to the corresponding operation and maintenance personnel and business personnel through the SMS interface. Emergency alarms will trigger telephone voice notifications at the same time.

[0031] Preferably, the anomaly localization module includes a correlation analysis submodule, a root cause diagnosis submodule, and a treatment suggestion submodule;

[0032] The correlation analysis submodule is used to retrieve indicator data before and after the alarm time point and establish the correlation between business indicators and technical indicators.

[0033] The root cause diagnosis submodule is used to analyze the associated data using a decision tree algorithm and output possible causes of anomalies.

[0034] The handling suggestion submodule is used to provide targeted solutions for the diagnosed root causes based on historical fault handling records.

[0035] Preferably, the mapping relationship established by the configuration information acquisition module includes a dynamic update mechanism, which automatically identifies the changes and adjusts the mapping relationship between business indicators and technical indicators when the business process or technical architecture of the marketing management system changes.

[0036] As can be seen from the above technical solution, compared with the prior art, the marketing operation and maintenance anomaly location system disclosed in this invention has the following beneficial effects:

[0037] By establishing a mapping relationship between business metrics and technical metrics through a configuration information acquisition module, and combining this with a dynamic update mechanism, the problem of the two being independent and isolated in traditional operations and maintenance is solved. When business processes or technical architectures change, the system can automatically adjust the mapping relationship to ensure the real-time accuracy of the association. This association allows fluctuations in business metrics to be directly traced to the corresponding technical metrics, providing a clear path for anomaly localization.

[0038] The indicator data acquisition module collects indicators in parallel based on mapping and association, combining a timestamp synchronization mechanism with data cleaning and processing to form a high-quality, integrated indicator dataset. The exception retry mechanism of the multi-source acquisition submodule ensures data integrity and avoids analytical gaps caused by acquisition failures. This dataset provides a unified data foundation for the linked analysis of business and technical indicators, solving the problems of single acquisition dimensions and data asynchrony in traditional methods.

[0039] The alarm module performs linkage verification based on the correlation between indicators, and combines threshold configuration and level classification mechanism to avoid the false alarm and missed alarm problems of traditional single indicator alarms.

[0040] The monitoring and display module dynamically shows the correlation between business and technical indicators through a unified view. The scenario aggregation submodule integrates multi-level indicators to form a panoramic view for core business scenarios. Operations personnel no longer need to switch between multiple interfaces; they can directly grasp the correlation trend through visual charts, improving the efficiency of overall judgment of system operating status.

[0041] The anomaly localization module establishes correlations between indicators through the correlation analysis submodule and uses a decision tree algorithm to perform source tracing analysis on the fused dataset, providing solutions in conjunction with historical handling records. This mechanism transforms traditional "experience-based troubleshooting" into "data-driven localization." For example, "electricity bill collection blockage" can be quickly traced back to "bank-electricity network interface response delay," significantly shortening the time from business anomaly to technical root cause localization, improving fault handling efficiency, and ensuring the continuity and stability of marketing operations. Attached Figure Description

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

[0043] Figure 1 This is a schematic diagram of a marketing operation and maintenance anomaly location system based on the integration of business and technical indicators, provided as an embodiment of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] like Figure 1 This invention discloses a marketing operation and maintenance anomaly location system based on the integration of business and technical indicators, including a configuration information acquisition module, an indicator data collection module, a monitoring and display module, an alarm module, and an anomaly location module;

[0046] The configuration information acquisition module is used to synchronously acquire the technical architecture configuration information of the marketing management system and the database monitoring configuration information associated with business processes, and to establish the basis for the mapping and association between business indicators and technical indicators.

[0047] The indicator data acquisition module is used to collect technical architecture operation indicators and key node indicators of business processes in parallel based on the mapping and association established by the configuration information acquisition module, forming a fusion indicator dataset and storing it in the monitoring database.

[0048] The monitoring and display module is used to retrieve the integrated indicator dataset from the monitoring database and display the dynamic relationship between business indicators and corresponding technical indicators through the same view, providing a basis for integrated analysis for alarm judgment and anomaly location.

[0049] The alarm module is used to link abnormal business indicators with corresponding technical indicator thresholds based on the correlation displayed by the monitoring and display module, trigger multi-level alarms and push them to relevant personnel;

[0050] The anomaly localization module receives alarm information from the alarm module and uses a preset algorithm to perform source analysis on the related indicators in the fusion indicator dataset to locate the technical root cause of the business anomaly.

[0051] In this embodiment, a comprehensive mechanism for "integrating business and technical metrics" is constructed to systematically address the core problem of the separation between business and technical metrics in traditional operations and maintenance. First, the configuration information acquisition module synchronously collects technical architecture configuration and business database monitoring configuration, establishing a mapping relationship between business and technical metrics and breaking down information barriers. Then, the metric data acquisition module, based on this mapping relationship, collects technical operation metrics and key business node metrics in parallel, forming a fused dataset to solve the problem that single-dimensional collection cannot support correlation analysis. Next, the monitoring and display module presents the dynamic relationship between the two through a unified view, providing intuitive evidence for alarms and fault location, avoiding analytical gaps. Then, the alarm module, based on the view's correlation relationship, verifies business anomalies in conjunction with corresponding technical metric thresholds, reducing false alarms and missed alarms. Finally, after receiving the linked alarms, the anomaly location module uses a preset algorithm to trace the source of the fused dataset, tracing the technical root cause through business anomalies, forming a complete closed loop. This mechanism not only significantly improves operational efficiency by directly connecting business anomalies with their technical root causes, shortening fault location time, but also enhances business continuity.

[0052] To further implement the above technical solution, the configuration information acquisition module includes an automatic acquisition submodule, a manual configuration submodule, and a configuration storage submodule;

[0053] The automatic acquisition submodule is used to retrieve the configuration information of the marketing management system's host, microservice instances, and application load from the configuration management center via the interface protocol;

[0054] The manual configuration submodule is used to receive business database connection information, monitoring statements corresponding to business monitoring indicators, monitoring statements corresponding to technical monitoring indicators, monitoring statements corresponding to security monitoring indicators, and network link detection parameters between the network and the province / region, input by the operation and maintenance personnel.

[0055] The configuration storage submodule is used to integrate automatically acquired and manually configured information into application infrastructure information, store it in a local database, and synchronize it to the indicator data acquisition module.

[0056] Furthermore, the manual configuration submodule includes an indicator statement verification unit, which performs syntax verification and execution tests on the input monitoring statements to ensure that the statements can correctly obtain indicator data such as automatic meter reading rate, fee calculation rate, and number of long transactions from the business database.

[0057] For example, taking the core business scenario of "automatic deduction of electricity fees" as an example, the process of establishing the basic mapping relationship is as follows:

[0058] The automatic acquisition submodule retrieves technical architecture information from the configuration management center via a RESTful interface. This information includes: the microservice instance responsible for batch deduction services (e.g., "payment-service-01" deployed on host 192.168.1.101), application load balancing strategies (request allocation rules for port 8080 corresponding to this microservice), and database cluster configuration (master database 192.168.2.201, slave database 192.168.2.202). This information is automatically tagged as "technical configuration items," forming structured data.

[0059] The manual configuration submodule receives service configuration information input by operations and maintenance personnel:

[0060] Business database connection information:

[0061] (jdbc:mysql: / / 192.168.2.201:3306 / electric_bill);

[0062] Business monitoring statements:

[0063] The function "select count(*) from batch_deduct where status = 'FAIL' and create_time>now()-interval1hour" is used to count the number of batch deduction failures within one hour.

[0064] Technical monitoring statements:

[0065] The command "showprocesslistwheredb='electric_bill'andtime>60" is used to monitor long database transactions.

[0066] Network link parameters (in the three-level network-province-region link, the "province-region" segment probes the IP address as 10.0.0.5, with a probe frequency of 5 minutes / time).

[0067] This information is labeled as "business configuration items" and stored in structured form as follows:

[0068] {“Business Configuration ID”:“B001”,“Type”:“Monitoring Statement”,“Value”:“selectcount(*)frombatch_deduct...”,“Associated Business Scenario”:““Electricity Fee Batch Deduction”}.

[0069] Configure the storage submodule to start the integration process:

[0070] Identify association rules: Match the corresponding technical configuration item (microservice "payment-service-01" is responsible for electricity bill deduction business) through the "Associated business scenario" field of "Business Configuration ID=B001".

[0071] Establish mapping relationships: Generate mapping table: {"Mapping ID":"M001","Business Configuration ID":"B001","Technical Configuration ID":"T001","Association Type":"Business-Microservice"};

[0072] Generate application infrastructure information: Package the technical configuration items, business configuration items, and mapping tables, store them in JSON format (containing a three-level structure of "technical layer", "business layer" and "relationship layer"), and synchronize them to the front cache of the indicator data collection module.

[0073] At this point, the business metric "number of failed deduction orders within 1 hour" has been bound to technical metric carriers such as the "payment-service-01" microservice and the 192.168.2.201 database through a mapping relationship, providing a precise basis for subsequent collection of integrated data such as "microservice response time when the number of failed deduction orders surges" and "number of long transactions in the database".

[0074] In this embodiment, the core business scenarios include meter reading and billing scenarios, batch deduction generation scenarios, spot trading scenarios, and electricity fee collection scenarios.

[0075] Furthermore, the mapping relationship established by the configuration information acquisition module includes a dynamic update mechanism. When the business processes or technical architecture of the marketing management system change, the changes are automatically identified and the mapping relationship between business indicators and technical indicators is adjusted.

[0076] For example, when a new microservice instance, "payment-service-02," is added to the system (deployed on host 192.168.1.102) to share the batch deduction business load with the original instance, the following steps are taken: The automatic acquisition submodule captures the configuration information (including instance ID, deployment host, port, etc.) of the new microservice in real time through the change notification interface of the configuration management center; the dynamic update mechanism identifies the expansion change of the "microservice cluster" in the technical architecture and automatically includes the technical indicators of "payment-service-02" (such as response time and concurrency) in the mapping association scope; the configuration storage submodule updates the application infrastructure information and adds a mapping relationship: "Number of failed batch deduction orders in 1 hour" → "Response time of payment-service-02", while retaining the association relationship of the original instance to ensure that the business indicators can be associated with all technical nodes that process the business.

[0077] When a business department adds a "automatic retry for batch deduction failure" process, it needs to monitor the new business indicator "cumulative number of retries within 24 hours". This indicator depends on the "retry_log" data table (stored in the slave database 192.168.2.202). The submodule is manually configured to receive the new business indicator monitoring statement ("select count(*) from retry_log where deduct_id in (select id from batch_deduct where status = 'FAIL')") and related database information input by the operation and maintenance personnel.

[0078] The dynamic update mechanism identifies changes to "new monitoring metrics" in the business process and automatically matches the metric with the slave database 192.168.2.202 that stores its data.

[0079] Configure the storage submodule to add a new mapping relationship: "Cumulative number of retries in 24 hours" → "Database query time of 192.168.2.202" and "Retry interface response time of payment-service-01 / 02", and synchronize it to the indicator data collection module to ensure that the new business indicators can be associated with the corresponding technical indicators in real time.

[0080] To further implement the above technical solution, the indicator data acquisition module includes a task scheduling submodule, a multi-source acquisition submodule, and a data cleaning submodule.

[0081] The task scheduling submodule is used to set the collection period according to the indicator type in the configuration information and generate scheduled collection tasks; the multi-source collection submodule is used to obtain microservice application indicators by simulating access according to the collection tasks, obtain business indicators, technical indicators, and security indicators by querying the database, and obtain network routing and latency data by network detection tools; the data cleaning submodule is used to standardize the format of the collected raw data, remove invalid values, and write it to the monitoring database.

[0082] Furthermore, the multi-source acquisition submodule includes an exception retry unit. When an acquisition task fails, the retry mechanism is automatically triggered. If it still fails, a failure log is recorded and pushed to the alarm module.

[0083] For example, based on the established mapping relationship in the "automatic batch deduction of electricity fees" scenario, the specific workflow of the indicator data collection module is as follows:

[0084] The task scheduling submodule first parses the application infrastructure information synchronized by the configuration storage submodule to identify the metric types in the "batch deduction of electricity fees" scenario: business metrics (number of failed batch deduction orders within 1 hour), technical metrics (microservice response time, number of long database transactions), security metrics (number of failed database logins), and network metrics (province-to-region link latency). Then, it sets the collection period based on the metric characteristics: business and technical metrics require high-frequency monitoring, so the collection period is set to 1 minute; security and network metrics are relatively stable, so the collection period is set to 5 minutes. Finally, a scheduled task queue is generated, for example, {"Task ID":"TASK001","metric type":"business metric","period":60 seconds,"associated configuration ID":"B001"}, etc.

[0085] The multi-source acquisition submodule performs acquisition according to the task queue:

[0086] For microservice application metrics, simulate HTTP requests to the / health interface of "payment-service-01" to obtain data such as the average response time (e.g., 200ms) and concurrent processing count (e.g., 150) of the microservice.

[0087] For business metrics, execute the manually configured business monitoring statement "select count(*) from batch_deduct where status = 'FAIL' and create_time > now() - interval 1 hour" to get the number of batch deduction failure orders within 1 hour (e.g., 30 orders);

[0088] In terms of technical indicators, executing the technical monitoring statement "showprocesslistwheredb='electric_bill'andtime>60" will count the number of long transactions in the database (e.g., 2).

[0089] Security metrics are obtained by querying the database audit logs to get the number of login failures (e.g., 1 time) in the past 5 minutes;

[0090] The network metrics are obtained by using the ping tool to probe the "province-region" segment IP 10.0.0.5 and obtaining the link latency (e.g., 20ms).

[0091] If a query times out due to temporary database connection congestion during a database long transaction count collection, the abnormal retry unit of the multi-source collection submodule will be triggered immediately: it will automatically retry twice after a 3-second interval. If it still fails, a failure log ({"Task ID":"TASK002","Failure Reason":"Database Connection Timeout","Time":"2025-08-1210:05:30"}) will be generated and pushed to the alarm module.

[0092] After receiving the raw data collected from various channels, the data cleaning submodule performs standardization processing: converting the microservice response time "200ms" and network latency "20ms" into a unified "millisecond value" format; removing the unit from the batch deduction failure order count "30", retaining the integer "30"; and removing invalid network latency data such as "-1ms" caused by network fluctuations. After processing, the standardized data (such as {"timestamp":"2025-08-12 10:06:00","metric type":"business metric","value":30,"associated task ID":"TASK001"}) is written to the monitoring database, providing a clean and unified data source for subsequent monitoring display, alarms, and anomaly location.

[0093] To further implement the above technical solutions, the monitoring and display module includes an indicator visualization sub-module and a scene aggregation sub-module;

[0094] The indicator visualization submodule is used to convert single-dimensional indicators such as host CPU utilization and network packet loss rate into line charts and dashboard charts to show the trend of the indicators over time.

[0095] The scenario aggregation submodule is used to integrate related business layer indicators, application layer indicators, and infrastructure layer indicators into a panoramic view based on the core business scenarios of meter reading and billing and electricity fee collection.

[0096] To further implement the above technical solution, the alarm module includes a threshold configuration submodule, a level classification submodule, and a notification distribution submodule. The threshold configuration submodule is used to receive user-set response time upper limit and consecutive anomaly count threshold parameters, and supports individual configuration according to indicator type. The level classification submodule is used to classify alarm information according to the degree of anomaly. The notification distribution submodule is used to send alarm information of different levels to the corresponding operation and maintenance personnel and business personnel through SMS interface, and emergency alarms trigger telephone voice notifications at the same time.

[0097] To further implement the above technical solution, the anomaly localization module includes a correlation analysis submodule, a root cause diagnosis submodule, and a handling suggestion submodule. The correlation analysis submodule is used to retrieve indicator data before and after the alarm time point and establish the correlation between business indicators and technical indicators. The root cause diagnosis submodule is used to analyze the correlation data through a decision tree algorithm and output possible causes of anomalies. The handling suggestion submodule is used to provide targeted solutions for the diagnosed root causes based on historical fault handling records.

[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0099] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A marketing operations and maintenance anomaly location system based on the integration of business and technical indicators, characterized in that, It includes a configuration information acquisition module, an indicator data collection module, a monitoring and display module, an alarm module, and an anomaly location module; The configuration information acquisition module is used to synchronously acquire the technical architecture configuration information of the marketing management system and the database monitoring configuration information associated with the business processes, and to establish a mapping and association basis between business indicators and technical indicators. The indicator data acquisition module is used to collect technical architecture operation indicators and key node indicators of business processes in parallel based on the mapping association established by the configuration information acquisition module, form a fusion indicator dataset and store it in the monitoring database. The monitoring and display module is used to retrieve the integrated indicator dataset from the monitoring database and display the dynamic relationship between business indicators and corresponding technical indicators through the same view, providing a basis for integrated analysis for alarm judgment and anomaly location. The alarm module is used to perform linkage verification between abnormal business indicators and corresponding technical indicator thresholds based on the correlation displayed by the monitoring and display module, trigger multi-level alarms and push them to relevant personnel; The anomaly location module is used to receive the alarm information from the alarm module and then use a preset algorithm to perform source analysis on the related indicators in the fusion indicator dataset to locate the technical root cause of the business anomaly.

2. The marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The configuration information acquisition module includes an automatic acquisition submodule, a manual configuration submodule, and a configuration storage submodule; The automatic acquisition submodule is used to retrieve the configuration information of the marketing management system's host, microservice instances, and application load from the configuration management center via an interface protocol; The manual configuration submodule is used to receive business database connection information, monitoring statements corresponding to business monitoring indicators, monitoring statements corresponding to technical monitoring indicators, monitoring statements corresponding to security monitoring indicators, and network link detection parameters input by operation and maintenance personnel. The configuration storage submodule is used to integrate automatically acquired and manually configured information into application infrastructure information, store it in a local database, and synchronize it to the indicator data acquisition module.

3. The marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 2, characterized in that, The manual configuration submodule includes an indicator statement verification unit, which is used to perform syntax verification and execution testing on the input monitoring statements.

4. The marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The indicator data acquisition module includes a task scheduling submodule, a multi-source acquisition submodule, and a data cleaning submodule; The task scheduling submodule is used to set the collection period according to the indicator type in the configuration information and generate timed collection tasks. The multi-source acquisition submodule is used to acquire microservice application metrics by simulating access, acquire business metrics, technical metrics, and security metrics by querying the database, and acquire network routing and latency data by network detection tools, according to the acquisition task. The data cleaning submodule is used to standardize the format of the collected raw data, remove invalid values, and then write the data into the monitoring database.

5. A marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 4, characterized in that, The multi-source acquisition submodule includes an exception retry unit. When the acquisition task fails, the retry mechanism is automatically triggered. If it still fails, the failure log is recorded and pushed to the alarm module.

6. A marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The monitoring and display module includes an indicator visualization sub-module and a scene aggregation sub-module; The indicator visualization submodule is used to convert single-dimensional indicators such as host CPU utilization and network packet loss rate into line charts and dashboard charts to show the trend of indicator changes over time. The scenario aggregation submodule is used to integrate related business layer indicators, application layer indicators, and infrastructure layer indicators into a panoramic view based on the core business scenarios of meter reading and billing and electricity fee collection.

7. A marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The alarm module includes a threshold configuration submodule, a level classification submodule, and a notification distribution submodule; The threshold configuration submodule is used to receive the response time upper limit and consecutive anomaly number threshold parameters set by the user, and supports individual configuration according to the indicator type. The classification submodule is used to classify alarm information according to the degree of anomaly; The notification distribution submodule is used to send alarm information of different levels to the corresponding operation and maintenance personnel and business personnel through the SMS interface. Emergency alarms will trigger telephone voice notifications at the same time.

8. A marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The anomaly localization module includes a correlation analysis submodule, a root cause diagnosis submodule, and a treatment suggestion submodule. The correlation analysis submodule is used to retrieve indicator data before and after the alarm time point and establish the correlation between business indicators and technical indicators. The root cause diagnosis submodule is used to analyze the associated data using a decision tree algorithm and output possible causes of anomalies. The handling suggestion submodule is used to provide targeted solutions for the diagnosed root causes based on historical fault handling records.

9. A marketing operation and maintenance anomaly location system based on the fusion of business and technical indicators as described in claim 1, characterized in that, The mapping relationship established by the configuration information acquisition module includes a dynamic update mechanism. When the business process or technical architecture of the marketing management system changes, the changes are automatically identified and the mapping relationship between business indicators and technical indicators is adjusted.

Images