Channel division-based operation anomaly diagnosis method, device, equipment and medium
Patent Information
- Application Number
- CN202611246054.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-17
- Publication Date
- 2026-10-16
AI Technical Summary
[0005]本发明的主要目的在于提供一种基于通道划分的运行异常诊断方法、装置、设备及存储介质,旨在解决现有技术采用统一阈值对不同消息通道进行异常判断,难以兼顾未配置监控阈值且具有特定业务时段和历史运行规律的消息通道,导致异常诊断准确性不足的技术问题
[0010] Beneficial Effects: This invention relates to the field of software monitoring technology and discloses a method, apparatus, device, and medium for diagnosing operational anomalies based on channel division. The method includes: acquiring monitoring configuration data containing business time period characteristics and explicit monitoring thresholds; collecting and filtering operational data from each message channel to obtain effective operational data; dividing message channels into a first type of message channel and a second type of message channel based on the configuration of explicit monitoring thresholds; performing threshold analysis on the first type of message channel and analyzing the second type of message channel based on historical operational data, change record data, and business time period characteristics, generating status analysis results respectively, and generating anomaly diagnosis information accordingly. This invention can be applied to business scenarios such as fintech and healthcare. By distinguishing between message channels with and without configured explicit monitoring thresholds, and employing threshold analysis and channel knowledge analysis respectively, it reduces misjudgments and omissions caused by uniform thresholds, and improves the accuracy of identifying and diagnosing operational anomalies of different message channels, including message backlog anomalies and message processing delay anomalies.
Smart Images

Figure CN122926089A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software monitoring technology, and in particular to a method, apparatus, equipment and medium for diagnosing operational anomalies based on channel division. Background Technology
[0002] As business scales up, significant differences emerge among different message channels in the message middleware regarding business hours, message writing frequency, and operational patterns. Some message channels have clearly defined monitoring thresholds, while others lack directly applicable thresholds. Existing technologies typically analyze the operational status of each message channel using uniform thresholds or a single judgment method, which struggles to account for the operational differences between different message channels. This can easily lead to the misidentification of normal periodic fluctuations or intermittent message writing as anomalies, and may also result in the omission of genuine messages, backlogs, and processing delays, leading to insufficient accuracy in anomaly diagnosis.
[0003] In the fintech business sector, payment transactions, securities brokerage, account bookkeeping, fund clearing, risk control, and insurance claims exhibit significant differences in business hours. Different message channels display different message writing and processing patterns during peak trading hours, batch clearing, end-of-day reconciliation, and non-trading periods. Existing unified monitoring methods struggle to simultaneously and accurately identify both high-frequency financial business channels with clearly defined monitoring thresholds and low-frequency financial business channels lacking such thresholds. This can easily lead to misjudgments of normal business hour changes or failure to promptly identify genuine message backlog anomalies.
[0004] In the healthcare sector, the generation time and transmission frequency of data such as electronic medical records, test results, medical orders, image indexes, and medical expense settlement vary significantly. Some message channels continuously transmit data, while others only generate data during peak outpatient hours, concentrated testing periods, or batch archiving. Existing unified monitoring methods struggle to accurately distinguish between normal fluctuations and operational anomalies based on the operational patterns of different healthcare channels, particularly in effectively diagnosing message channels without clearly defined monitoring thresholds. Summary of the Invention
[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for diagnosing operational anomalies based on channel segmentation. This invention aims to solve the technical problem that existing technologies use a uniform threshold to judge anomalies in different message channels, which makes it difficult to take into account message channels that are not configured with monitoring thresholds and have specific business periods and historical operating patterns, resulting in insufficient accuracy in anomaly diagnosis.
[0006] To achieve the above objectives, the present invention provides a method for diagnosing operational anomalies based on channel partitioning, comprising: Retrieve monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; Based on the monitoring configuration data, the operation data of each message channel is collected, and the operation data is filtered to obtain valid operation data; The message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold are classified as the first type of message channels, and the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold are classified as the second type of message channels. Based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, a status analysis is performed to generate the first type of status analysis results; Obtain historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel; Anomaly diagnostic information is generated based on the results of the first type of state analysis and the results of the second type of state analysis.
[0007] Furthermore, to achieve the above objectives, the present invention provides a channel-based operational anomaly diagnosis device, comprising: The monitoring configuration module is used to obtain monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; The data collection and filtering module is used to collect operational data from each message channel based on the monitoring configuration data, and to filter the operational data to obtain valid operational data. The message channel classification module is used to classify the message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold into the first type of message channels, and classify the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold into the second type of message channels. The explicit threshold analysis module is used to perform status analysis based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, and generate the first type of status analysis results. The channel knowledge analysis module is used to acquire historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel. An anomaly diagnosis output module is used to generate anomaly diagnosis information based on the first type of state analysis results and the second type of state analysis results.
[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a channel-based runtime anomaly diagnostic program stored in the memory and executable on the processor, wherein when the channel-based runtime anomaly diagnostic program is executed by the processor, it implements the steps of the channel-based runtime anomaly diagnostic method as described above.
[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a channel-based runtime anomaly diagnosis program, wherein when the channel-based runtime anomaly diagnosis program is executed by a processor, it implements the steps of the channel-based runtime anomaly diagnosis method as described above.
[0010] Beneficial Effects: This invention relates to the field of software monitoring technology and discloses a method, apparatus, device, and medium for diagnosing operational anomalies based on channel division. The method includes: acquiring monitoring configuration data containing business time period characteristics and explicit monitoring thresholds; collecting and filtering operational data from each message channel to obtain effective operational data; dividing message channels into a first type of message channel and a second type of message channel based on the configuration of explicit monitoring thresholds; performing threshold analysis on the first type of message channel and analyzing the second type of message channel based on historical operational data, change record data, and business time period characteristics, generating status analysis results respectively, and generating anomaly diagnosis information accordingly. This invention can be applied to business scenarios such as fintech and healthcare. By distinguishing between message channels with and without configured explicit monitoring thresholds, and employing threshold analysis and channel knowledge analysis respectively, it reduces misjudgments and omissions caused by uniform thresholds, and improves the accuracy of identifying and diagnosing operational anomalies of different message channels, including message backlog anomalies and message processing delay anomalies. Attached Figure Description
[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a channel-based operation anomaly diagnosis method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the operational anomaly diagnosis method based on channel partitioning of the present invention. Figure 3 for Figure 2 A detailed flowchart of step S10; Figure 4 for Figure 2 A detailed flowchart of step S20; Figure 5 for Figure 2 A detailed flowchart of step S30; Figure 6 for Figure 2 A detailed flowchart of step S40; Figure 7 for Figure 2 A detailed flowchart of step S50; Figure 8 for Figure 2 A detailed flowchart of step S60; Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the operation anomaly diagnosis device based on channel division of the present invention; Figure 10 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 11 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation
[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.
[0013] The operation anomaly diagnosis method based on channel partitioning provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can obtain monitoring configuration data containing business time period characteristics and explicit monitoring thresholds from the client, collect and filter the operational data of each message channel to obtain effective operational data; based on the configuration of explicit monitoring thresholds, the message channels are divided into a first type of message channel and a second type of message channel; threshold analysis is performed on the first type of message channel, and analysis is performed on the second type of message channel based on historical operational data, change record data, and business time period characteristics, generating status analysis results respectively, and generating abnormal diagnosis information accordingly. This invention can be applied to business scenarios such as fintech and healthcare. By distinguishing between message channels with and without configured explicit monitoring thresholds, and using threshold analysis and channel knowledge analysis respectively, it reduces misjudgments and omissions caused by uniform thresholds, and improves the accuracy of operational anomaly diagnosis. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster composed of multiple servers. The invention will be described in detail below through specific embodiments.
[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the channel-based operational anomaly diagnosis method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0015] like Figure 2 As shown, the operational anomaly diagnosis method based on channel partitioning proposed in this invention includes the following steps: S10, obtain monitoring configuration data containing business time period characteristics and explicit monitoring thresholds; In this embodiment, the business time period characteristics are generated by time parameters in the business calendar, task scheduling configuration, or message writing plan. These parameters include at least business time period boundaries and may also include periodic markers, cross-day markers, and intermittent message writing markers. After time zone conversion, time format standardization, and interval conflict verification, the time parameters are associated with the corresponding message channel identifier to describe the message writing patterns of the message channel within different time ranges.
[0016] Explicit monitoring thresholds are read from the configuration center, configuration database, or message middleware management interface, including configured thresholds from message processing rate thresholds and message backlog thresholds. After unit standardization and validity verification, the threshold data is associated with the corresponding message channel identifier, applicable time period, and effective version. When different thresholds are configured for the same message channel in different business time periods, the time interval corresponding to each threshold is recorded separately.
[0017] Business time period characteristics and explicit monitoring thresholds are aggregated according to message channel identifiers to generate monitoring configuration data. Monitoring configuration data can be stored using structured configuration objects, key-value records, or relational data tables. Message channels without explicitly set monitoring thresholds are marked with an "unconfigured" flag to distinguish between missing thresholds and configuration read failures.
[0018] When business time parameters and threshold parameters are stored centrally, the configuration center stores message channel identifiers, business time period boundaries, period markers, message processing rate thresholds, and message backlog thresholds. The corresponding parameters are read through configuration queries, and after time format verification, threshold unit conversion, and message channel identifier verification, monitoring configuration data is formed.
[0019] When business time parameters and threshold parameters are stored separately, a message channel identifier and configuration effective time are used to associate business calendar records and threshold configuration records. When multiple configuration versions exist for the same message channel, the currently valid version is selected according to its effective time, and the version identifier and update time are retained.
[0020] When a business period spans two calendar days, a cross-day marker can be used to save the complete time interval, or the time interval can be split into two adjacent date intervals. When message writing is triggered by a business event, an intermittent message writing marker can be generated based on the event type, trigger period, and effective time window, and associated with the corresponding message channel identifier.
[0021] In the fintech business, the securities order message channel can read the opening and closing times from the trading calendar, and read the message processing rate threshold and message backlog threshold from the configuration database; the funds clearing message channel can generate intermittent message write markers based on the end-of-day clearing batches, and associate them with the corresponding threshold versions.
[0022] In the field of healthcare, the regional health data platform can generate continuous business periods based on the health monitoring data upload plan, generate periodic business periods based on the medical expense settlement batches, and read the message processing rate threshold and message backlog threshold corresponding to each message channel from the configuration center to form monitoring configuration data corresponding to different data transmission patterns.
[0023] This embodiment unifies the time format, data unit, and message channel correspondence of business time period characteristics and explicit monitoring thresholds, enabling time characteristics and threshold parameters to be accurately attributed to the corresponding message channels. It also uses an unconfigured flag to distinguish between missing thresholds and configuration read failures, thereby improving the completeness and accuracy of monitoring configuration data.
[0024] S20, collect the operation data of each message channel based on the monitoring configuration data, and filter the operation data to obtain valid operation data; In this embodiment, the message channel identifier, collection range, connection parameters, and time information in the monitoring configuration data are used to determine the message channels and collection boundaries that need to be collected. The collection range can be set according to the message middleware instance, message channel set, business time interval, or deployment area to avoid reading data not included in the monitoring range. The connection parameters are used to establish a data access connection, and the time information is used to determine the collection cycle, collection time window, and data time base.
[0025] Operational data for each message channel can be read from the message middleware management interface, monitoring metrics interface, or operation logs. The collected data includes information reflecting message writing, message processing, message backlog, and partition status, along with the message channel identifier and collection time to maintain a correspondence between data from different message channels and at different times. The collection cycle can be fixed or adjusted according to business periods, shortening the interval during high-load periods and lengthening it during low-load periods.
[0026] Operational data is filtered based on monitoring scope, message channel status, time validity, and data integrity. Data that is outside the monitoring scope, has a disabled message channel, has expired collection time, or has missing identifiers or incomplete content is excluded; duplicate data is deduplicated based on message channel identifiers and collection time. The retained data is consistent with the message channel and time range in the monitoring configuration data, forming valid operational data.
[0027] When the message middleware provides a monitoring metric interface, a periodic query method is used to read the metric data of each message channel. The query request carries the message channel identifier and time range. After the returned data undergoes timestamp verification, identifier verification, and duplicate data deletion, only the data within the monitoring range is retained.
[0028] When there are many message channels and the data changes frequently, an indicator push method is used to receive operational data. Each data record carries a message channel identifier, collection time, and operational status. The receiving end establishes a set of allowed message channels based on the monitoring configuration data and filters out data outside the set, expired data, and data with missing fields.
[0029] When some operational data originates from logs, log parsing is used to identify message channel identifiers, data timestamps, and operational metrics. Log records are matched against monitoring configuration data; records whose message channel affiliation cannot be determined or which are outside the configured time range are not included in the valid operational data.
[0030] In the fintech business, payment transactions, fund clearing, and account reconciliation correspond to different message channels. During peak promotional payment periods, the data collection interval for payment transaction channels is shortened, while during the end-of-day clearing period, data from fund clearing channels is collected according to the clearing time window, excluding data from deactivated channels, duplicate records, and data outside of business hours.
[0031] In the healthcare sector, regional health data platforms can collect operational data from message channels corresponding to health monitoring data, laboratory test data, and medical expense settlement data. The collection frequency is increased during peak upload periods from wearable devices, and data with missing identifiers, expired dates, or not included in the monitoring scope is filtered to generate valid operational data corresponding to each data channel.
[0032] This embodiment constrains the collection object, collection range, and collection time by monitoring configuration data, so that the running data can accurately correspond to the corresponding message channel; it filters out data that is out of range, invalid in status, expired in time, duplicate, or incomplete, reducing the interference of invalid data on subsequent analysis and improving the accuracy and usability of effective running data.
[0033] S30, the message channels in the message channels corresponding to the effective operating data that are configured with the explicit monitoring threshold are classified as first-class message channels, and the message channels in the message channels corresponding to the effective operating data that are not configured with the explicit monitoring threshold are classified as second-class message channels; In this embodiment, valid operational data carries a message channel identifier. Based on the message channel identifier, the corresponding explicit monitoring threshold configuration is searched in the monitoring configuration data. The search scope only covers the message channels associated with the valid operational data, avoiding the inclusion of message channels that have been filtered out or not included in the monitoring scope in the classification results.
[0034] Whether an explicit monitoring threshold has been configured can be determined by whether a readable and effective threshold parameter exists in the corresponding configuration item. When a configuration item has a valid threshold parameter, the corresponding message channel is marked as configured; when a configuration item is empty, lacks a threshold parameter, or is marked as unconfigured, the corresponding message channel is marked as unconfigured. If the configuration value format is abnormal or exceeds the allowed value range, a configuration anomaly flag can be recorded to avoid mistakenly interpreting a read failure as unconfigured.
[0035] The first category of message channels consists of message channels with configured tags, while the second category consists of message channels without configured tags. The classification results retain the message channel identifier and threshold configuration status, ensuring that the same message channel is assigned to only one category and that all message channels corresponding to valid runtime data have clear classification results.
[0036] When the number of message channels is small and threshold configurations are centrally stored, a channel-by-channel query method is used to read the threshold configuration status of each message channel. The query results are matched item by item with the message channel identifiers in the valid operating data. Message channels with valid threshold parameters are written into the first type of channel set, and the remaining message channels are written into the second type of channel set.
[0037] When dealing with a large number of message channels, a batch query method is used to read the threshold configuration table and establish a mapping relationship between message channel identifiers and threshold configuration statuses. Message channel identifiers in the valid running data are categorized through this mapping relationship, reducing the query overhead caused by repeated accesses to the configuration storage.
[0038] In cases where threshold configurations have changed, the currently valid threshold record is selected based on the configuration's effective time and version identifier. Older version thresholds, thresholds that have not yet taken effect, and expired thresholds are not considered as configured. The classification result record uses the configuration version to ensure consistency between the classification status and the current configuration.
[0039] In the fintech business, payment transaction channels, securities brokerage channels, and fund clearing channels all generate valid operational data. Payment transaction channels and securities brokerage channels have saved effective explicit monitoring thresholds and are classified as Category I message channels; fund clearing channels have not saved effective thresholds and are classified as Category II message channels, thus clarifying the threshold configuration status of different financial business channels.
[0040] In the healthcare business, health monitoring data channels, test result channels, and medical expense settlement channels are linked to effective operational data. Health monitoring data channels are configured with an effective threshold and are categorized as first-class message channels; test result channels and medical expense settlement channels are not configured with an effective threshold and are categorized as second-class message channels, ensuring that different data channels obtain clear and mutually exclusive classification results.
[0041] This embodiment matches the message channels corresponding to valid operating data with the explicit monitoring threshold configuration one by one, and forms two mutually exclusive message channels based on the valid configuration status of the threshold parameters. This avoids invalid message channels from participating in the classification, reduces misclassification caused by threshold reading anomalies, and improves the accuracy and completeness of message channel classification results.
[0042] S40, perform status analysis based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, and generate the first type of status analysis result; In this embodiment, the first type of message channel and valid operational data are associated through message channel identifiers, enabling each set of operational indicators to be located in the corresponding message channel. Configured explicit monitoring thresholds must have valid parameters, a unified data unit, and a clearly defined effective time; when only some thresholds are configured for the same message channel, only the operational indicators corresponding to the configured thresholds are analyzed.
[0043] Status analysis compares message processing rate, message backlog, or other operational metrics in valid operational data with corresponding explicit monitoring thresholds. Based on whether the operational metrics reach the thresholds, it generates status markers and threshold comparison data. The first type of status analysis results may include the first type of message channel identifier, status marker, operational metrics that triggered the status change, threshold comparison data, and status generation time, thus preserving the basis for status judgment and message channel attribution.
[0044] When only one set of explicit monitoring thresholds is configured for each first-class message channel, the message channel identifier is used to associate valid operating data with threshold parameters, each operating indicator is directly compared with the corresponding threshold, and the first-class status analysis results are generated based on the comparison results.
[0045] When multiple sets of explicit monitoring thresholds are configured for different time periods on the same first-type message channel, the current effective threshold parameters are matched with the status generation time, and then the valid operational data is compared. Thresholds not in their effective time period are not included in the analysis.
[0046] When multiple operational indicators are configured with thresholds, a status label for each operational indicator is generated by comparing each indicator individually. Then, the status labels are aggregated according to the message channel identifier to form the corresponding first-class status analysis results.
[0047] In the fintech business, after configuring message processing rate thresholds and message backlog thresholds for payment transaction message channels, the effective operational data collected during promotional activities can be compared with the currently effective thresholds to generate a first-class status analysis result that includes payment transaction channel identifiers, abnormal operation indicators, and status generation time.
[0048] In the field of healthcare, after configuring the message processing rate threshold for the wearable health data upload channel, the effective operational data during the concentrated upload period can be compared with the corresponding threshold; when the health data processing rate reaches the threshold, the first type of status analysis result corresponding to the health data upload channel is generated.
[0049] This embodiment accurately matches the valid operational data of the first type of message channel with the explicit monitoring thresholds that are in effect and have consistent units, and only analyzes the operational indicators corresponding to the configured thresholds. This reduces the occurrence of threshold mismatch and invalid thresholds participating in the status judgment, so that the first type of status analysis results can accurately reflect the deviation between the operational indicators and the thresholds.
[0050] S50, acquire historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate a second type of status analysis result based on the channel knowledge data and the valid operation data corresponding to the second type of message channel; In this embodiment, the second type of message channel lacks directly applicable explicit monitoring thresholds. Historical operational data can be read from the monitoring database, indicator storage, or log parsing results, and organized according to the message channel identifier and collection time to reflect changes in message writing, message processing, and message backlog over different time periods. Change record data can originate from the configuration center, version records, or message middleware management records, and is used to record message channel configuration adjustments, partition changes, and related effective times.
[0051] Historical operational data and change record data are associated with message channel identifiers and time information, and then divided into continuous operation segments, periodic operation segments, and intermittent operation segments based on business time period characteristics. The resulting channel knowledge data can record the operational distribution, change trends, periodic patterns, and state differences before and after configuration changes within each business time period, avoiding the identification of normal changes caused by business time period switching or configuration adjustments as anomalies.
[0052] The second type of message channel's valid operational data is matched with channel knowledge data, and the comparison criteria can be selected according to the same business period, similar time location, or the same configuration version. When the current operating status deviates from the corresponding operating pattern, the deviation indicator, deviation direction, and status generation time are recorded to form the second type of status analysis results.
[0053] When historical data is continuous and the collection cycle is stable, time windows are used to collect operational data of the same message channel within the same business period, and channel knowledge data is formed based on the data distribution of each time window. The current valid operational data is compared with historical data of the same business period to determine the operational status.
[0054] In situations with frequent configuration adjustments, historical operational data is divided into multiple valid configuration intervals based on the change time, and channel knowledge data corresponding to each valid configuration interval is generated. Current valid operational data is assigned to the corresponding interval based on the current configuration version, reducing interference from older configuration operational data on status analysis.
[0055] When message channels generate data only based on business events, historical operational data is aggregated using business event types and effective time windows. Time periods where no corresponding business event occurred are not included in the comparison, and currently valid operational data is only matched with channel knowledge data under the same event type.
[0056] In the fintech business, the funds clearing message channel only generates centralized data in the end-of-day batch. Historical operational data can be aggregated according to clearing batch and configuration change time. The valid operational data of the current clearing batch is compared with the channel knowledge data corresponding to the same batch type and current configuration version to identify operational states that deviate from normal clearing patterns.
[0057] In the healthcare sector, the health monitoring data channel within the regional health data platform generates centralized data during fixed daily upload periods. Historical operational data is aggregated according to upload time and interface configuration version, and currently valid operational data is matched with channel knowledge data for the corresponding time period to distinguish between normal centralized uploads and abnormal message backlogs.
[0058] This embodiment organizes historical operational data, change record data, and business time period characteristics according to message channels and time relationships to form channel knowledge data that reflects periodic patterns, time period differences, and configuration changes. Then, the channel knowledge data is used to analyze the effective operational data of the second type of message channels, thereby reducing misjudgments of the status caused by a unified judgment benchmark when there is a lack of explicit monitoring thresholds and improving the accuracy of the second type of status analysis results.
[0059] S60, generate abnormal diagnostic information based on the first type of state analysis results and the second type of state analysis results.
[0060] In this embodiment, the first type of state analysis results and the second type of state analysis results are aggregated according to the message channel identifier, state generation time, and result category, so that the state data of the same message channel can be distinguished by source. The first type of state analysis results reflects the state obtained based on explicit monitoring thresholds, and the second type of state analysis results reflects the state obtained based on channel knowledge data. The two types of results may include different message channels at the same time, or they may only include one type of message channel.
[0061] The aggregated status data identifies abnormal message channels based on status tags and status indicators, and determines the anomaly category and diagnostic criteria. Anomaly diagnostic information may include message channel identifier, result category, anomaly category, anomaly indicator, status generation time, and corresponding diagnostic criteria. When multiple status results point to the same message channel, the latest result is retained according to the status generation time, or they are merged into a single diagnostic record according to the degree of anomaly, avoiding duplicate output.
[0062] Anomaly diagnostic information can be converted into structured records, alarm events, or interface responses. The output location can be a monitoring interface, message queue, diagnostic data storage area, or external notification interface. During the output process, the message channel identifier and result category are retained, enabling the receiving end to identify the channel to which the anomaly belongs and the source of the diagnosis.
[0063] When both types of state analysis results contain abnormal message channels, a classification index is established using result category and message channel identifier. The two types of abnormal data are then organized separately and grouped into abnormal diagnostic information according to the state generation time to avoid confusion between different judgment criteria.
[0064] When multiple status analysis results are generated consecutively in the same message channel, adjacent diagnostic records are merged using a time window. When the anomaly category and anomaly indicator remain consistent, the duration and latest indicator are updated; when the anomaly category changes, the new, independent diagnostic record is retained.
[0065] When diagnostic results need to be used by different receiving ends, a unified field is used to organize the abnormal diagnostic information, and then it is converted into monitoring interface records, alarm messages or interface return data respectively, to ensure that the message channel identifier, abnormal category and diagnostic basis are consistent in different output forms.
[0066] In the fintech business, payment transaction channels are identified as abnormal based on explicit monitoring thresholds, while fund clearing channels are identified as abnormal based on business periods and historical operating patterns. The diagnostic sources for both types of results are retained, and abnormal diagnostic information including channel identifier, abnormal category, abnormal indicators, and status time is generated.
[0067] In the field of healthcare, the health monitoring data channel and the medical expense settlement channel use different status judgment criteria to generate analysis results. During the collection process, the source of diagnosis is distinguished according to the message channel identifier and result category, and the diagnostic information is output to the monitoring interface of the regional health data platform.
[0068] This embodiment retains the message channel affiliation, result category, and status time of the two types of status analysis results, and merges duplicate statuses, so that the anomaly diagnosis information can accurately reflect the message channel to which the anomaly belongs and the corresponding judgment basis; after being structured and organized, the output can reduce the confusion of statuses from different sources and duplicate diagnosis, and improve the accuracy and identifiability of anomaly diagnosis information.
[0069] In one embodiment, such as Figure 3 As shown, step S10 above includes: S101, obtain the middleware identifier of the message to be monitored, the connection configuration data, and the message channel identifier corresponding to each message channel; according to the attribution relationship between the middleware identifier of the message to be monitored and the message channel identifier, associate the middleware identifier of the message to be monitored, the connection configuration data, and the message channel identifier to generate monitoring object data; S102, obtain the monitoring range corresponding to the message middleware identifier to be monitored and the channel operation status flag corresponding to each message channel, and write the monitoring range and the channel operation status flag into the monitoring object data according to the message middleware identifier to be monitored and the message channel identifier to generate channel configuration data; S103, obtain the business operation time data corresponding to each message channel, extract the business time period boundary and intermittent message writing mark from the business operation time data, and associate the business time period boundary and the intermittent message writing mark according to the message channel identifier to generate business time period features; S104, obtain the threshold configuration data corresponding to each message channel, extract the configured threshold from the message processing rate threshold and message backlog threshold from the threshold configuration data, and organize the configured threshold according to the message channel identifier to generate an explicit monitoring threshold; S105, generate monitoring configuration data by associating the channel configuration data, the service time period characteristics, and the explicit monitoring threshold with the middleware identifier to be monitored and the message channel identifier.
[0070] In this embodiment, the identifier of the message middleware to be monitored can be read from the configuration center, asset registration data, or message middleware management interface, and is used to distinguish different message middleware instances. Connection configuration data includes access address, port, authentication parameters, protocol parameters, and connection timeout parameters, used to establish a data access relationship with the target message middleware. Message channel identifiers can be returned by the message middleware management interface or read from the configuration storage, and are used to distinguish different message channels under the same message middleware. Based on the attribution relationship between the message middleware identifier and the message channel identifier, the connection configuration data is written to the configuration record of the corresponding message middleware, and each message channel identifier is attached to the corresponding message middleware identifier, forming monitoring object data that can indicate the attribution relationship of the message middleware, connection parameters, and message channels.
[0071] The monitoring scope is used to determine the message middleware instances, message channel sets, or logical business groups participating in the monitoring. It can be obtained from the monitoring object list, message channel whitelist, or deployment region configuration in the configuration center. The channel operation status flag indicates whether the message channel is currently running, disabled, under testing, or under maintenance. This can be provided by the message middleware management interface, configuration database, or operation and maintenance status records. Based on the message middleware identifier and message channel identifier to be monitored, the monitoring scope and channel operation status flag are written to the corresponding monitoring object data, ensuring that each message channel simultaneously has attribution information, monitoring boundaries, and operation status, generating channel configuration data. During the writing process, it is possible to verify whether the message channel identifier belongs to the corresponding message middleware, avoiding incorrect associations between the monitoring scope or operation status.
[0072] Business runtime data can originate from task scheduling configurations, business calendars, message writing plans, or periodic task records, including time intervals, periodic information, trigger types, and effective dates. Business time period boundaries indicate the start and end times of message channel generation or processing of business messages, and can represent continuous time intervals, cross-day time intervals, or periodic time intervals. Intermittent message writing markers indicate that the message channel generates messages only during specific tasks, batches, or events. After standardizing the time format, converting the time zone, and validating the intervals, the business runtime data is processed. Business time period boundaries and intermittent message writing markers are then extracted and associated with the corresponding message channels according to the message channel identifier, generating business time period characteristics. When multiple business time periods exist for the same message channel, each time interval and its effective conditions can be saved separately.
[0073] Threshold configuration data can be read from the configuration center, monitoring parameter storage area, or message middleware management records. The message processing rate threshold represents the allowable range of message processing volume per unit time, while the message backlog threshold represents the boundary of the number of unprocessed messages. During extraction, the system identifies whether valid parameters are recorded for threshold configuration items and verifies the data type, data unit, value range, and effective time of the thresholds. If only one threshold is recorded, the configured threshold and its corresponding indicator type are retained; if both thresholds are recorded, each threshold is saved separately; if neither is recorded, the unconfigured state is retained. The extracted configured thresholds are organized according to message channel identifiers to form explicit monitoring thresholds, enabling each threshold to be located at its corresponding message channel and operational indicator.
[0074] Channel configuration data, business time period characteristics, and explicit monitoring thresholds are associated based on the message middleware identifier and message channel identifier to be monitored. During the association process, the message middleware instance is determined by the message middleware identifier, and the specific message channel under that instance is determined by the message channel identifier. Then, the monitoring scope, channel running status flags, business time period boundaries, intermittent message write flags, and configured thresholds are written to the same message channel configuration record. Monitoring configuration data can be stored using structured configuration objects, key-value data, or relational data tables, and the configuration version and effective time are recorded to distinguish different versions when the configuration of the same message channel changes.
[0075] This embodiment establishes an attribution relationship between the middleware identifier of the message to be monitored and the message channel identifier, and associates the monitoring scope, channel operating status, business time period characteristics and explicit monitoring thresholds according to a unified identifier. This can reduce mismatches in connection parameters, time information and threshold parameters. By verifying the business time period boundary, threshold validity and configuration effective time, the integrity and accuracy of monitoring configuration data can be improved, so that different message channels can obtain monitoring parameters corresponding to their own operating status, business time and threshold configuration.
[0076] In one embodiment, such as Figure 4 As shown, step S20 above includes: S201, extract the middleware identifier of the message to be monitored, connection configuration data, monitoring range, channel operation status flag, and message channel identifier corresponding to each message channel from the monitoring configuration data; establish collection task entries corresponding to each message channel identifier according to the attribution relationship between the middleware identifier of the message to be monitored and the message channel identifier; and write the middleware identifier of the message to be monitored, the message channel identifier, the preset collection period, the monitoring range, and the channel operation status flag into the corresponding collection task entries to generate collection task data; S202, establish a data acquisition connection with the message middleware corresponding to the message middleware identifier to be monitored based on the connection configuration data, and collect the number of messages written and processed in each message channel within the preset acquisition period according to the acquisition task data through the data acquisition connection, and collect the partition end offset position, message processing end submission offset position, message backlog and partition status data of each message channel to generate raw running data; S203, generate a message write rate based on the number of messages written and the preset collection period, generate a message processing rate based on the number of messages processed and the preset collection period, generate a message processing end lag based on the difference between the partition end offset position and the corresponding message processing end submission offset position, generate a partition running status based on the partition status data, and combine the message write rate, the message processing rate, the message backlog, the message processing end lag, and the partition running status according to the message channel identifier to generate running data corresponding to each message channel; S204, determine whether each message channel is within the monitoring range according to the middleware identifier of the message to be monitored and the message channel identifier, and whether the corresponding channel running status flag is running, and generate a data filtering identifier; S205, based on the data filtering identifier, filter the running data corresponding to each message channel, retain the running data of the corresponding message channel that is within the monitoring range and whose corresponding channel running status is marked as running, and obtain valid running data.
[0077] In this embodiment, the monitoring middleware identifier, connection configuration data, monitoring range, channel operation status flag, and message channel identifier are read from the monitoring configuration data, and the integrity, uniqueness, and attribution of the fields are verified. The monitoring middleware identifier is used to locate the specific message middleware instance. The connection configuration data includes the access address, port, authentication parameters, communication protocol, and connection timeout parameters. The monitoring range is used to record the set of message channels included in the data collection. The channel operation status flag is used to distinguish between running, disabled, or maintenance states. According to the attribution relationship between the message middleware instance and the message channel, an independent collection task entry is established for each message channel, and the message middleware identifier, message channel identifier, preset collection period, monitoring range, and channel operation status flag are written into it. The preset collection period can be provided by the collection scheduling parameters and is used to determine the time length between two adjacent collections. Each collection task entry is organized according to the message channel identifier to form collection task data.
[0078] A data acquisition connection is established based on the connection configuration data. Operational metrics can be read through the message middleware management interface, monitoring metric interface, or consumer group status interface. After the data acquisition connection is established, message channels are located one by one according to the acquisition task data, and the number of messages written and processed is accumulated within the time window corresponding to the preset acquisition cycle. The partition end offset position indicates the position of the latest message within the partition, the message processing end commit offset position indicates the position where the message processing end has confirmed completion of processing, the message backlog indicates the number of messages that have not yet been processed, and the partition status data records the partition availability status, primary partition status, and replica status. The acquisition results are appended with the message middleware identifier, message channel identifier, and acquisition time to form the raw operational data.
[0079] The number of messages written is converted into the message write rate per unit time according to the duration of a preset collection period, and the number of messages processed is converted into the message processing rate according to the same period. The offset position at the end of a partition is matched item by item with the corresponding message processing endpoint submission offset position according to the partition identifier; the difference between the two forms the message processing endpoint lag for each partition. When a message channel contains multiple partitions, the lag for each partition can be aggregated to form the message processing endpoint lag for the corresponding message channel. Partition status data is parsed through the status field to generate the partition running status. Message write rate, message processing rate, message backlog, message processing endpoint lag, and partition running status are aggregated according to the message channel identifier to form the running data corresponding to each message channel.
[0080] The middleware identifier for monitored messages is used to determine the instance to which the message channel belongs, while the message channel identifier is used to find the corresponding record within the monitoring scope. A valid data filtering identifier is generated when the message channel identifier exists within the monitoring scope and the corresponding channel's running status is marked as running; an invalid data filtering identifier is generated when the message channel is outside the monitoring scope, or when the channel's running status indicates it is disabled, under testing, or under maintenance. The data filtering identifier is associated with the corresponding message channel identifier to avoid confusion between filtering results from different message channels.
[0081] The operational data of each message channel is filtered according to data filtering identifiers. Operational data corresponding to valid data filtering identifiers is retained, while operational data corresponding to invalid data filtering identifiers is excluded. The retained data continues to carry the message middleware identifier, message channel identifier, collection time, and various operational indicators, forming valid operational data. This ensures that the subsequent data usage scope is consistent with the monitoring scope and channel operational status in the monitoring configuration data.
[0082] This embodiment establishes collection task entries according to the attribution relationship between message middleware and message channels, which can accurately correspond the collection cycle, monitoring scope, and operating status to specific message channels. By obtaining the number of messages, offset position, backlog, and partition status within a unified collection cycle and generating operating indicators with the same time base, data deviation caused by different collection times can be reduced. By filtering the operating data through the monitoring scope and channel operating status, data from disabled channels and outside the monitoring scope can be excluded, thereby improving the accuracy and consistency of effective operating data.
[0083] In one embodiment, such as Figure 5 As shown, step S30 above includes: S301, extract the message channel identifier corresponding to each message channel from the valid operating data, and collect the extracted message channel identifiers to generate a set of channel identifiers to be classified. S302, according to the set of channel identifiers to be classified, obtain the explicit monitoring threshold configuration items corresponding to each message channel identifier from the monitoring configuration data. The explicit monitoring threshold configuration items include message processing rate threshold configuration items and message backlog threshold configuration items. S303, determine whether threshold data is recorded in the message processing rate threshold configuration item and the message backlog threshold configuration item. When at least one of the message processing rate threshold configuration item and the message backlog threshold configuration item records threshold data, generate a configured flag. When neither the message processing rate threshold configuration item nor the message backlog threshold configuration item records threshold data, generate an unconfigured flag. S304, Associate the configured identifier and the unconfigured identifier with the corresponding message channel identifier respectively to generate a threshold configuration result; S305, based on the threshold configuration result, the message channel associated with the configured identifier is classified into a first type of message channel, and the message channel associated with the unconfigured identifier is classified into a second type of message channel.
[0084] In this embodiment, valid operational data is read according to message channel identifiers. The corresponding message channel identifier is obtained from each data record, and duplicate identifiers are removed. The aggregation process only retains message channel identifiers that actually contain valid operational data, without adding message channels that have been filtered out or have not generated valid operational data, thus forming a set of channel identifiers to be classified.
[0085] The monitoring configuration data is queried item by item according to the set of channel identifiers to be classified, locating the explicit monitoring threshold configuration items corresponding to each message channel. Explicit monitoring threshold configuration items store message processing rate thresholds and message backlog thresholds, and can include threshold values, data units, configuration status, and effective version. When multiple configuration versions exist, the currently valid configuration record can be selected based on its effective time to avoid invalid thresholds being included in the classification.
[0086] The recording status of threshold data is determined based on whether a readable threshold parameter exists in the configuration item. A configured flag is generated when at least one of the message processing rate threshold configuration item or message backlog threshold configuration item records threshold data; a non-configured flag is generated when neither configuration item records threshold data. A threshold value of zero is still considered recorded threshold data. Null values, missing fields, and unconfigured placeholders are not treated as threshold data to avoid misjudging valid zero values as non-configured.
[0087] The configured and unconfigured identifiers are associated with the message channel identifier that generated the judgment result, forming the threshold configuration result. The threshold configuration result records at least the message channel identifier, the configuration identifier, and the configuration item type that records the threshold data, so that each message channel corresponds to only one configuration state, and can distinguish between the cases where only the message processing rate threshold is configured, only the message backlog threshold is configured, and both thresholds are configured.
[0088] Based on the threshold configuration results, message channels with configured identifiers are classified into Category 1 message channels, and message channels without configured identifiers are classified into Category 2 message channels. Both categories originate from the same set of channel identifiers to be classified. The same message channel will not be assigned to both categories repeatedly, and each message channel in the set of channel identifiers to be classified has a clear classification result.
[0089] This embodiment avoids invalid message channels and erroneous thresholds from being included in the classification by only aggregating message channels corresponding to valid operating data and accurately matching explicit monitoring threshold configuration items according to the message channel identifier. By classifying message channels with at least one configured threshold into the first category of message channels and message channels with neither threshold configured into the second category of message channels, it can fully cover both partial threshold configuration and no threshold configuration states, reducing message channel omissions, duplicate classifications, and misjudgments of configuration states, and improving the accuracy and consistency of message channel classification results.
[0090] In one embodiment, such as Figure 6 As shown, step S40 above includes: S401, extract the first type of message channel identifier, message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operation data corresponding to the first type of message channel, and extract the configured explicit monitoring threshold corresponding to the first type of message channel identifier from the monitoring configuration data, and associate the message write rate, message processing rate, message backlog, message processing terminal lag, partition operation status, and configured explicit monitoring threshold with the first type of message channel identifier respectively to generate first type of channel analysis data; S402, determine the message processing status based on the message processing rate in the first type of channel analysis data, the message processing status includes a message processing status and a message processing non-message status; S403, when the message processing state is no message processing state, generate no message processing state determination data based on the message writing rate, the message backlog, the message processing terminal lag and the partition running state, and generate a first type of state analysis result based on the no message processing state determination data. S404, when the message processing status is message processing status, determine the running indicators to be compared according to the configured explicit monitoring threshold, compare the running indicators to be compared with the corresponding configured threshold, generate threshold comparison results, and generate threshold status determination data based on the threshold comparison results, the message processing terminal lag amount and the partition running status, and generate the first type of status analysis results based on the threshold status determination data.
[0091] In this embodiment, based on the first type of message channel identifier, message write rate, message processing rate, message backlog, message processing latency, and partition operation status are read from valid operational data. The explicit monitoring threshold corresponding to the same first type of message channel identifier is then searched from the monitoring configuration data. The read data is verified according to the collection time, data unit, and message channel affiliation to avoid data mismatches between different time periods or different message channels. After associating each operational indicator, explicit monitoring threshold, and first type of message channel identifier, first type of channel analysis data is formed.
[0092] The message processing status is determined based on the message processing rate. A message processing rate of zero indicates no message processing; a rate greater than zero indicates message processing. To exclude data acquisition fluctuations, a minimum effective processing rate can be set, and data below this rate will be classified as no message processing. The message processing status is associated with and stored as the identifier of the first-type message channel, ensuring each first-type message channel has an independent status determination.
[0093] When in a no-message processing state, the message write rate is used to determine whether there are still messages being written to the message channel, the message backlog reflects the number of messages to be processed, the message processing end lag reflects the offset difference between the partition end position and the submitted processing position, and the partition running status reflects whether the partition is available. When the message write rate is greater than zero and the message backlog or message processing end lag continues to increase, the state of continuous message writing but not being processed can be recorded; when the message write rate is zero and there is no message backlog, the state of no message writing and no pending messages can be recorded; when the partition running status is abnormal, the partition abnormal information can be written into the no-message processing state determination data. The no-message processing state determination data includes the running indicators involved in the judgment, the indicator status, and the judgment time, and forms the first type of state analysis results based on this.
[0094] When a message processing state is active, the operational metric to be compared is determined based on the threshold type actually recorded in the explicit monitoring thresholds. If only the message processing rate threshold is configured, the message processing rate is determined as the operational metric to be compared; if only the message backlog threshold is configured, the message backlog amount is determined as the operational metric to be compared; if both thresholds are configured, both the message processing rate and the message backlog amount are determined as operational metrics to be compared. Each operational metric to be compared is matched against the configured thresholds for the same message channel, the same metric type, and the same effective time period.
[0095] Threshold comparisons are performed according to the comparison direction recorded in the threshold configuration. The message processing rate threshold serves as a lower limit to determine if message processing capacity has decreased; the message backlog threshold serves as an upper limit to determine if the number of messages to be processed exceeds the allowable range. The threshold comparison results record whether the indicator has reached the threshold, the direction of deviation, the magnitude of deviation, and the corresponding threshold version. The message processing latency and partition operation status are written together with the threshold comparison results into the threshold status determination data, so that the threshold status determination data simultaneously reflects indicator deviation, processing location latency, and partition availability.
[0096] The no-message-processing state determination data and the threshold state determination data correspond to two different message processing states, respectively, and use a consistent data structure to record the first-type message channel identifier, state type, state index, and state generation time. The resulting first-type state analysis results can clearly distinguish the operational status under the no-message-processing state and the threshold deviation under the message-processing state.
[0097] This embodiment first distinguishes between message processing status and no message processing status based on message processing rate, which avoids relying solely on threshold comparison to make a judgment when messages are not processed at all. By comprehensively considering message write rate, message backlog, message processing terminal lag, and partition operation status in the no message processing status, and only selecting the operation indicators corresponding to the configured thresholds for comparison in the message processing status, it can reduce the status error caused by missing thresholds, indicator mismatch, or single indicator judgment, and improve the accuracy of the first type of status analysis results.
[0098] In one embodiment, such as Figure 7 As shown, step S50 above includes: S501 extracts the second-type message channel identifier, historical message write rate, historical message processing rate, historical message backlog, and collection time corresponding to each second-type message channel from historical monitoring records to generate historical operation data; S502, extract the message channel configuration change data, message middleware topology adjustment data and change time corresponding to the second type of message channel identifier from the configuration management record, and generate change record data; S503, based on the second type of message channel identifier, the collection time and the change time, perform time-series association on the historical operation data and the change record data, add business time period markers to the time-series associated data according to the business time period characteristics, and generate channel knowledge data; S504, Based on the channel knowledge data, generate channel operation benchmark data, which includes message write rate change trend, message processing rate change trend, message backlog change trend, business period operation characteristics, change impact characteristics, dynamic message processing rate threshold, and dynamic message backlog threshold; S505, extract message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operating data corresponding to the second type of message channel; generate message write status data based on the message write rate, the message write rate change trend, and the change impact characteristics; generate message processing status data based on the message processing rate, the message processing rate change trend, the message processing terminal lag, the partition operation status, the message write status data, the business period operation characteristics, the change impact characteristics, and the dynamic message processing rate threshold; and generate message backlog status data based on the message backlog, the message backlog change trend, the dynamic message backlog threshold, the message write status data, the message processing status data, and the change impact characteristics. S506, a second type of status analysis result is generated based on the message writing status data, the message processing status data, and the message backlog status data.
[0099] In this embodiment, historical message write rate, historical message processing rate, historical message backlog, and collection time are read from historical monitoring records according to the second type of message channel identifier. The collection time is used to restore the time sequence of various historical indicators, and the second type of message channel identifier is used to isolate data from different message channels. Records with different collection periods are standardized in terms of time granularity, and records with missing time, duplicate time, or abnormal indicator format are excluded to generate historical operation data that reflects the operational changes of each second type of message channel.
[0100] The configuration management records are used to retrieve message channel configuration change data, message middleware topology adjustment data, and change times according to the second-type message channel identifier. Message channel configuration change data includes changes to the number of partitions, data retention parameters, or message processing terminal configurations. Message middleware topology adjustment data includes node additions / removals, partition migrations, or replica relationship changes. The change time is used to determine when the changes began to affect operational metrics. Each change is associated with its corresponding second-type message channel identifier to generate change record data.
[0101] Historical operational data and change records for the same message channel are aggregated based on the second type of message channel identifier, and then a time correspondence is established between the collection time and the change time. Historical operational data collected after the change time is associated with the corresponding change content. When multiple changes occur consecutively, they are associated separately according to the effective period of each change content. Business time period characteristics are used to add business time period tags to the associated data, enabling each data entry to distinguish between continuous operation periods, periodic operation periods, and intermittent message writing periods, generating channel knowledge data.
[0102] Channel knowledge data is collected according to the second type of message channel identifier, business time period marker, and configuration effective interval. Historical message write rate, historical message processing rate, and historical message backlog are arranged according to the collection time, and the message write rate change trend, message processing rate change trend, and message backlog change trend are generated through smoothing with moving time windows, statistical analysis of change amplitude, and identification of continuous change direction. Business time period operation characteristics are generated based on the distribution range and periodic changes of various historical indicators within the same business time period, and are used to record the operating status range corresponding to different business time periods.
[0103] The impact characteristics of the change are generated based on the changes in various historical indicators within adjacent time windows before and after the change, and may include the affected indicators, the direction of change, the magnitude of change, and the duration. The stable indicator range generated after configuration change or topology adjustment can be used as a reference for subsequent status judgment. Data with short-term fluctuations that recover to the original range can be recorded as transient changes, while data that continuously deviates from the original range can be recorded as continuous changes.
[0104] The dynamic message processing rate threshold is generated based on historical message processing rates within the same business period and the same configuration effective interval. The allowable lower limit can be determined using historical percentile intervals, moving average values, and dispersion. The dynamic message backlog threshold is generated based on the distribution range, growth duration, and decline of historical message backlog. It can be determined using historical upper limits and allowable fluctuation ranges. The dynamic thresholds change with the business period or configuration effective interval, providing corresponding status judgment criteria for different operational phases.
[0105] The message write rate, message processing rate, message backlog, message processing latency, and partition operation status are read from the valid operational data corresponding to the second type of message channel, and matched with the corresponding channel operation baseline data according to the second type of message channel identifier. The current message write rate is compared with the message write rate change trend, and the change impact characteristics are referenced to determine whether the current write rate conforms to the change pattern of the corresponding time period and configuration range, generating message write status data.
[0106] The current message processing rate is compared with the message processing rate trend and the dynamic message processing rate threshold. Message processing status data is generated by integrating factors such as message processing latency, partition operation status, message write status data, business time period operation characteristics, and change impact characteristics. When the message processing rate decreases and the message processing latency continues to increase, a decrease in processing capacity can be recorded. When the change is consistent with the stable range after business time period switching or configuration adjustment, a time period change status or change impact status can be recorded.
[0107] The current message backlog is compared with the message backlog trend and the dynamic message backlog threshold. Combined with message write status data, message processing status data, and change impact characteristics, message backlog status data is generated. A backlog growth status can be recorded when the message write rate increases, the message processing rate decreases, and the message backlog continues to increase; a backlog reduction status can be recorded when the message processing rate recovers and the message backlog continues to decrease.
[0108] Message write status data, message processing status data, and message backlog status data are associated according to the second type of message channel identifier to form the second type of status analysis results. The second type of status analysis results can record status type, status indicators, business time period markers, change impact content, and status generation time, so that each status has a clear data source and judgment basis.
[0109] This embodiment can distinguish business cycle changes, configuration changes, and deviations in operating indicators by correlating historical operating data with configuration changes, topology adjustments, and business periods. By generating channel operating baseline data that varies with business periods and configuration intervals, and comparing the current message writing, message processing, and message backlog status with corresponding trends and dynamic thresholds, it can form a status judgment basis that matches the operating rules of each second type of message channel in the absence of explicit monitoring thresholds, thereby improving the accuracy of the second type of status analysis results.
[0110] In one embodiment, such as Figure 8 As shown, step S60 above includes: S601, extract the first type of message channel identifier, the first type of status identifier, the first type of status index data and the first type of status generation time from the first type of status analysis results, filter the first type of abnormal message channels and determine the first type of abnormality, and generate the first type of abnormality identification data. S602, extract the second type of message channel identifier, second type of status identifier, second type of status index data and second type of status generation time from the second type of status analysis results, filter the second type of abnormal message channels and determine the second type of abnormality type, and generate the second type of abnormality identification data; S603, for each first type of abnormal message channel, obtain the corresponding first type of status identifier from the first type of abnormal identification data, and extract the no message processing status judgment data or threshold status judgment data corresponding to the first type of status identifier from the first type of status analysis results to generate first type of abnormal cause data. S604, for each second type of abnormal message channel, obtain the corresponding second type of status identifier from the second type of abnormal identification data, and extract at least one of message writing status data, message processing status data and message backlog status data corresponding to the second type of status identifier from the second type of status analysis results to generate second type of abnormal cause data; S605, Generate a first type of exception handling suggestion based on the first type of exception type and the first type of exception cause data, and generate a second type of exception handling suggestion based on the second type of exception type and the second type of exception cause data; S606, Based on each first-type abnormal message channel, and the first-type abnormal type, first-type abnormal cause data, first-type abnormal handling suggestions and first-type status generation time corresponding to each first-type abnormal message channel, generate first-type abnormal diagnostic data; S607, Based on each second type of abnormal message channel, and the second type of abnormality type, second type of abnormality cause data, second type of abnormality handling suggestions and second type of status generation time corresponding to each second type of abnormal message channel, generate second type of abnormality diagnostic data; S608, combine the first type of abnormality diagnostic data and the second type of abnormality diagnostic data to generate abnormality diagnostic information and output it.
[0111] In this embodiment, the first-class state identifier, first-class state indicator data, and first-class state generation time are read from the first-class state analysis results according to the first-class message channel identifier. The first-class state identifier is used to distinguish between no-message processing state and threshold state. The first-class state indicator data is used to record the message write rate, message processing rate, message backlog, message processing terminal lag, or partition operation status that triggers state changes. The first-class state generation time is used to determine the time point when the state data is generated. Message channels corresponding to normal states are filtered out based on the first-class state identifier, and the first-class anomaly type is determined based on the abnormal indicator type and deviation of the first-class state indicator data. First-class anomaly identification data associated with each first-class abnormal message channel is generated.
[0112] From the analysis results of the second type of status, the second type of status identifier, second type of status indicator data, and second type of status generation time are read according to the second type of message channel identifier. The second type of status identifier is used to distinguish between message writing anomalies, message processing anomalies, and message backlog anomalies. The second type of status indicator data is used to record the deviation of the current operating indicator from the changing trend, business period operating characteristics, or dynamic threshold. Based on the second type of status identifier, second type of abnormal message channels are filtered, and the type of second type of anomaly is determined according to the type of abnormal indicator, the direction of deviation, and the persistence status. Second type of anomaly identification data associated with each second type of abnormal message channel is generated.
[0113] For each Category I abnormal message channel, the corresponding Category I status identifier is read from the Category I abnormal identification data. When the Category I status identifier indicates a no-message processing state, the corresponding no-message processing state determination data is read from the Category I status analysis results, and the cause of the abnormality is determined based on message writing status, message backlog status, message processing end lag status, and partition operation status. When the Category I status identifier indicates a threshold status, the corresponding threshold status determination data is read from the Category I status analysis results, and the cause of the abnormality is determined based on the operation indicators that have reached the threshold, the direction of deviation, and the partition status, generating Category I abnormality cause data for each Category I abnormal message channel.
[0114] For each second-type abnormal message channel, the corresponding second-type status identifier is read from the second-type abnormal identification data. Based on the second-type status identifier, at least one of message write status data, message processing status data, and message backlog status data is selected from the second-type status analysis results. When the second-type status identifier indicates that multiple abnormal states exist simultaneously, multiple status data can be selected at the same time, and the cause corresponding to message write anomaly, decreased processing capacity, or increased backlog is determined based on the relationship between the status data, generating second-type abnormal cause data for each second-type abnormal message channel.
[0115] The first type of exception and its cause data are associated one-to-one according to the first type of exception message channel, and a first-type exception handling suggestion is generated based on the processing object corresponding to the exception type and the running status indicated by the exception cause. The second type of exception and its cause data are associated one-to-one according to the second type of exception message channel, and a second-type exception handling suggestion is generated. The exception handling suggestion may include adjusting message processing resources, checking the status of the message processing end, restoring the abnormal partition, adjusting the partition configuration, or verifying the message channel configuration, and the specific suggestion should correspond to the exception cause.
[0116] Each Category I anomaly message channel is associated with its Category I anomaly type, Category I anomaly cause data, Category I anomaly handling suggestion, and Category I status generation time to form Category I anomaly diagnostic data. Each Category II anomaly message channel is associated with its Category II anomaly type, Category II anomaly cause data, Category II anomaly handling suggestion, and Category II status generation time to form Category II anomaly diagnostic data. Both types of anomaly diagnostic data are stored using independent category tags, enabling multiple Category I and Category II anomaly message channels to record simultaneously, and ensuring that the anomaly type, cause, suggestion, and time within the same message channel remain consistent.
[0117] The first and second types of anomaly diagnostic data are combined according to the message channel identifier and the status generation time. When the same message channel generates duplicate diagnostic data at adjacent times, the latest status can be retained or consecutive records of the same anomaly type can be merged. Anomaly diagnostic information can be organized into structured data records, including at least the message channel identifier, anomaly category, anomaly cause, anomaly handling suggestions, and status generation time, and output to the monitoring interface, diagnostic data storage area, or alarm interface.
[0118] This embodiment avoids confusion between different analysis bases by filtering abnormal message channels from two types of status analysis results and selecting matching judgment data or status data based on the corresponding status identifier. By associating the abnormality type, abnormality cause, handling suggestions, and status generation time one by one according to the abnormal message channel, the diagnostic content can be kept in accurate correspondence with the specific abnormal channel. By unifying and outputting the two types of abnormal diagnostic data, it can simultaneously cover abnormal message channels with and without explicit monitoring thresholds, thereby improving the completeness and accuracy of abnormal diagnostic information.
[0119] In one embodiment, the monitored objects include a Kafka (distributed messaging system) cluster used for payment transactions, securities brokerage, risk control, fund clearing, and account accounting. The configuration page records the cluster identifier, connection parameters, and identifiers for each topic (message topic), and sets the monitoring scope, operating status, business time period, and explicit monitoring thresholds. The payment order topic can be configured with a lower limit for message processing rate and a higher limit for message backlog, while the end-of-day settlement topic can record the business time period from 21:00 to 22:00 and intermittent message write markers. Development and testing clusters, offline clusters, and deactivated topics are marked by their operating status or monitoring scope.
[0120] Data collection tasks are created for each topic based on the monitoring configuration data. During promotional periods, a 10-second collection cycle can be used for the payment order topic, and a 1-minute collection cycle can be used for the end-of-day settlement topic. Message write count, message processing count, partition end offset, message processing end commit offset, message backlog, and partition status data are read through the Kafka management interface and consumer group status interface, and message write rate, message processing rate, and lag (consumption delay) are generated. Data for topics not within the monitoring scope, offline, or under maintenance is excluded; the retained data forms the valid operational data.
[0121] Topics are categorized based on their explicit monitoring threshold configurations. The payment order topic has both message processing rate and message backlog thresholds configured, while the securities transaction report topic only has a message backlog threshold configured; both are classified as Category 1 message channels. The end-of-day settlement and account reconciliation topics do not have fixed thresholds configured and are classified as Category 2 message channels.
[0122] For the first type of message channel, when the message processing rate is 0, further analysis is performed on the message write rate, message backlog, lag, and partition operation status. If the payment order topic is continuously writing messages, the message processing rate is 0, the message backlog is continuously increasing, and the partitions are functioning normally, it can be determined that the consumer is not processing messages correctly. If the topic is offline, no abnormal diagnosis is generated. When the message processing rate is greater than 0, the operation indicators corresponding to the configured thresholds are compared with the thresholds. For example, if the message processing rate of the payment order topic is less than 5000 messages / second, or the message backlog exceeds 100,000 messages, the first type of status analysis results are generated by combining lag and partition status.
[0123] For the second type of message channel, historical message write rate, historical message processing rate, historical message backlog, and collection time are extracted from monitoring records of the most recent 7 days or multiple recent business cycles. Change records such as topic partition adjustments, consumer group configuration changes, cluster expansion, partition migration, and replica adjustments are also summarized. Historical data and change times are sequentially associated according to topic identifiers, and business time period markers are added based on clearing batches, trading days, non-trading days, and end-of-day periods to form channel knowledge data.
[0124] End-of-day clearing topics typically see a concentrated message write activity after 21:00, with message backlog briefly increasing before gradually decreasing. Based on data from multiple clearing cycles, trends in message write rate, message processing rate, message backlog, change impact characteristics, and dynamic thresholds can be generated. If the current message write rate conforms to historical patterns, but the message processing rate significantly decreases, lag continues to increase, and the message backlog exceeds the dynamic threshold, message processing anomalies and message backlog anomalies can be generated. If the rate change coincides with partition expansion or migration time, the change impact is incorporated into the status analysis to avoid directly classifying short-term fluctuations during configuration adjustments as anomalies.
[0125] Based on the results of the first type of status analysis, identify the first type of abnormal message channels, such as payment order topics and securities transaction report topics, and determine the cause of the anomaly based on the no-message processing status judgment data or threshold status judgment data. Based on the results of the second type of status analysis, identify the second type of abnormal message channels, such as end-of-day settlement topics and account reconciliation topics, and determine the cause of the anomaly based on message write status data, message processing status data, and message backlog status data.
[0126] When the payment order topic continues to produce messages but the message processing rate is 0, anomaly handling suggestions may include checking the consumer group status, restarting the consumer, or adding consumer instances. When the accounting reconciliation topic's processing rate decreases and the backlog continues to grow, anomaly handling suggestions may include increasing Flink (a streaming framework) parallelism, checking partition configuration, or checking recent topology adjustments. Each anomaly message channel is associated with anomaly type, anomaly cause, handling suggestions, and status generation time, combined to generate anomaly diagnostic information, which is then output to the financial business monitoring interface or alarm interface.
[0127] In one embodiment, a channel-based operation anomaly diagnosis device is provided, which corresponds one-to-one with the channel-based operation anomaly diagnosis method described in the above embodiments. (Refer to...) Figure 9 , Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the operation anomaly diagnosis device based on channel partitioning of the present invention. The operation anomaly diagnosis device based on channel partitioning includes: a monitoring configuration module 10, an operation data acquisition and filtering module 20, a message channel classification module 30, an explicit threshold analysis module 40, a channel knowledge analysis module 50, and an anomaly diagnosis output module 60. Detailed descriptions of each functional module are as follows: The monitoring configuration module 10 is used to obtain monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; The data collection and filtering module 20 is used to collect operational data from each message channel based on the monitoring configuration data, and to filter the operational data to obtain valid operational data. The message channel classification module 30 is used to classify the message channels in the message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold into the first type of message channels, and classify the message channels in the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold into the second type of message channels. The explicit threshold analysis module 40 is used to perform status analysis based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, and generate the first type of status analysis results. The channel knowledge analysis module 50 is used to acquire historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate a second type of status analysis result based on the channel knowledge data and the valid operation data corresponding to the second type of message channel. The anomaly diagnosis output module 60 is used to generate anomaly diagnosis information based on the first type of state analysis results and the second type of state analysis results.
[0128] In one embodiment, the monitoring configuration module 10 is specifically used for: Obtain the middleware identifier, connection configuration data, and message channel identifier corresponding to each message channel of the message to be monitored. According to the attribution relationship between the middleware identifier and the message channel identifier, associate the middleware identifier, the connection configuration data, and the message channel identifier to generate monitoring object data. Obtain the monitoring range corresponding to the middleware identifier to be monitored and the channel operation status flag corresponding to each message channel. Write the monitoring range and the channel operation status flag into the monitoring object data according to the middleware identifier to be monitored and the message channel identifier to generate channel configuration data. Obtain the business operation time data corresponding to each message channel, extract the business time period boundary and intermittent message writing mark from the business operation time data, and associate the business time period boundary and the intermittent message writing mark according to the message channel identifier to generate business time period features; Obtain the threshold configuration data corresponding to each message channel, extract the configured thresholds from the message processing rate threshold and message backlog threshold from the threshold configuration data, and organize the configured thresholds according to the message channel identifier to generate explicit monitoring thresholds; Monitoring configuration data is generated by associating the channel configuration data, the business time period characteristics, and the explicit monitoring threshold with the middleware identifier of the message to be monitored and the message channel identifier.
[0129] In one embodiment, the data acquisition and filtering module 20 is specifically used for: Extract the middleware identifier, connection configuration data, monitoring range, channel operation status marker, and message channel identifier corresponding to each message channel from the monitoring configuration data. Establish collection task entries corresponding to each message channel identifier according to the attribution relationship between the middleware identifier and the message channel identifier. Write the middleware identifier, the message channel identifier, the preset collection period, the monitoring range, and the channel operation status marker into the corresponding collection task entries to generate collection task data. Based on the connection configuration data, a data acquisition connection is established with the message middleware corresponding to the message middleware identifier to be monitored. Through the data acquisition connection, the number of messages written and processed in each message channel within the preset acquisition period is collected according to the acquisition task data. The partition end offset position, message processing end submission offset position, message backlog and partition status data of each message channel are also collected to generate raw running data. A message write rate is generated based on the number of messages written and the preset collection period. A message processing rate is generated based on the number of messages processed and the preset collection period. A message processing end lag is generated based on the difference between the partition end offset position and the corresponding message processing end submission offset position. A partition running status is generated based on the partition status data. The message write rate, message processing rate, message backlog, message processing end lag, and partition running status are combined according to the message channel identifier to generate running data corresponding to each message channel. Based on the middleware identifier of the message to be monitored and the message channel identifier, determine whether each message channel is within the monitoring range, and whether the corresponding channel running status flag is running, and generate a data filtering identifier; Based on the data filtering identifier, the running data corresponding to each message channel is filtered, and the running data of the corresponding message channel that is within the monitoring range and whose corresponding channel running status is marked as running is retained, thus obtaining valid running data.
[0130] In one embodiment, the message channel classification module 30 is specifically used for: Extract the message channel identifiers corresponding to each message channel from the valid operating data, and aggregate the extracted message channel identifiers to generate a set of channel identifiers to be classified. According to the set of channel identifiers to be classified, obtain the explicit monitoring threshold configuration items corresponding to each message channel identifier from the monitoring configuration data. The explicit monitoring threshold configuration items include message processing rate threshold configuration items and message backlog threshold configuration items. Determine whether threshold data is recorded in the message processing rate threshold configuration item and the message backlog threshold configuration item. If at least one of the message processing rate threshold configuration item and the message backlog threshold configuration item records threshold data, a configured flag is generated. If neither the message processing rate threshold configuration item nor the message backlog threshold configuration item records threshold data, an unconfigured flag is generated. Associate the configured identifier and the unconfigured identifier with their respective message channel identifiers to generate a threshold configuration result; Based on the threshold configuration results, the message channels associated with the configured identifier are classified into the first type of message channels, and the message channels associated with the unconfigured identifier are classified into the second type of message channels.
[0131] In one embodiment, the explicit threshold analysis module 40 is specifically used for: Extract the first type of message channel identifier, message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operating data corresponding to the first type of message channel. Extract the configured explicit monitoring threshold corresponding to the first type of message channel identifier from the monitoring configuration data. Assign the message write rate, message processing rate, message backlog, message processing terminal lag, partition operation status, and configured explicit monitoring threshold to the first type of message channel identifier to generate first type of channel analysis data. The message processing status is determined based on the message processing rate in the first type of channel analysis data, and the message processing status includes a message processing status and a message processing non-message status. When the message processing status is no message processing status, no message processing status determination data is generated based on the message write rate, the message backlog, the message processing terminal lag, and the partition operation status, and a first type of status analysis result is generated based on the no message processing status determination data. When the message processing status is message processing status, the running indicators to be compared are determined according to the configured explicit monitoring thresholds. The running indicators to be compared are compared with the corresponding configured thresholds to generate threshold comparison results. Threshold status determination data is generated based on the threshold comparison results, the message processing terminal lag amount and the partition running status. The first type of status analysis results are generated based on the threshold status determination data.
[0132] In one embodiment, the channel knowledge analysis module 50 is specifically used for: Extract the second-type message channel identifier, historical message write rate, historical message processing rate, historical message backlog, and collection time corresponding to each second-type message channel from historical monitoring records to generate historical operation data; Extract the message channel configuration change data, message middleware topology adjustment data, and change time corresponding to the second type of message channel identifier from the configuration management records, and generate change record data; Based on the second type of message channel identifier, the collection time and the change time, the historical operation data and the change record data are time-series correlated, and business time period tags are added to the time-series correlated data according to the business time period characteristics to generate channel knowledge data; Based on the channel knowledge data, channel operation benchmark data is generated, which includes message write rate change trend, message processing rate change trend, message backlog change trend, business period operation characteristics, change impact characteristics, dynamic message processing rate threshold, and dynamic message backlog threshold. Extract message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operational data corresponding to the second type of message channel. Generate message write status data based on the message write rate, the message write rate change trend, and the change impact characteristics. Generate message processing status data based on the message processing rate, the message processing rate change trend, the message processing terminal lag, the partition operation status, the message write status data, the business period operation characteristics, the change impact characteristics, and the dynamic message processing rate threshold. Generate message backlog status data based on the message backlog, the message backlog change trend, the dynamic message backlog threshold, the message write status data, the message processing status data, and the change impact characteristics. A second type of status analysis result is generated based on the message write status data, the message processing status data, and the message backlog status data.
[0133] In one embodiment, the anomaly diagnosis output module 60 is specifically used for: Extract the first type of message channel identifier, first type of status identifier, first type of status index data and first type of status generation time from the first type of status analysis results, filter the first type of abnormal message channels and determine the first type of abnormality, and generate the first type of abnormality identification data. Extract the second type of message channel identifier, second type of status identifier, second type of status index data and second type of status generation time from the second type of status analysis results, filter the second type of abnormal message channels and determine the second type of abnormality, and generate the second type of abnormality identification data. For each first-type abnormal message channel, obtain the corresponding first-type status identifier from the first-type abnormal identification data, and extract the no-message processing status judgment data or threshold status judgment data corresponding to the first-type status identifier from the first-type status analysis results to generate first-type abnormal cause data. For each second type of abnormal message channel, the corresponding second type of status identifier is obtained from the second type of abnormal identification data, and at least one of message writing status data, message processing status data and message backlog status data corresponding to the second type of status identifier is extracted from the second type of status analysis results to generate second type of abnormal cause data; A first type of anomaly handling suggestion is generated based on the first type of anomaly type and the first type of anomaly cause data; a second type of anomaly handling suggestion is generated based on the second type of anomaly type and the second type of anomaly cause data. Based on each first-type abnormal message channel, and the first-type abnormal type, first-type abnormal cause data, first-type abnormal handling suggestions and first-type status generation time corresponding to each first-type abnormal message channel, first-type abnormal diagnostic data is generated. Based on each type of second-class anomaly message channel, and the type of second-class anomaly, cause data, handling suggestions, and generation time of the second-class status corresponding to each type of second-class anomaly message channel, second-class anomaly diagnostic data is generated. Combine the first type of abnormality diagnostic data and the second type of abnormality diagnostic data to generate abnormality diagnostic information and output it.
[0134] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a channel-based runtime anomaly diagnosis method on the server side.
[0135] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a channel-based runtime anomaly diagnosis method.
[0136] In one embodiment, a computer device is provided, 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 perform the following steps: Retrieve monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; Based on the monitoring configuration data, the operation data of each message channel is collected, and the operation data is filtered to obtain valid operation data; The message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold are classified as the first type of message channels, and the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold are classified as the second type of message channels. Based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, a status analysis is performed to generate the first type of status analysis results; Obtain historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel; Anomaly diagnostic information is generated based on the results of the first type of state analysis and the results of the second type of state analysis.
[0137] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Retrieve monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; Based on the monitoring configuration data, the operation data of each message channel is collected, and the operation data is filtered to obtain valid operation data; The message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold are classified as the first type of message channels, and the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold are classified as the second type of message channels. Based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, a status analysis is performed to generate the first type of status analysis results; Obtain historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel; Anomaly diagnostic information is generated based on the results of the first type of state analysis and the results of the second type of state analysis.
[0138] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.
[0139] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0140] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0141] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.
[0142] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A method for diagnosing operational anomalies based on channel partitioning, characterized in that, Includes the following steps: Retrieve monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; Based on the monitoring configuration data, the operation data of each message channel is collected, and the operation data is filtered to obtain valid operation data; The message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold are classified as the first type of message channels, and the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold are classified as the second type of message channels. Based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, a status analysis is performed to generate the first type of status analysis results; Obtain historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel; Anomaly diagnostic information is generated based on the results of the first type of state analysis and the results of the second type of state analysis.
2. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, Retrieve monitoring configuration data containing business time period characteristics and explicit monitoring thresholds, including: Obtain the middleware identifier, connection configuration data, and message channel identifier corresponding to each message channel of the message to be monitored. According to the attribution relationship between the middleware identifier and the message channel identifier, associate the middleware identifier, the connection configuration data, and the message channel identifier to generate monitoring object data. Obtain the monitoring range corresponding to the middleware identifier to be monitored and the channel operation status flag corresponding to each message channel. Write the monitoring range and the channel operation status flag into the monitoring object data according to the middleware identifier to be monitored and the message channel identifier to generate channel configuration data. Obtain the business operation time data corresponding to each message channel, extract the business time period boundary and intermittent message writing mark from the business operation time data, and associate the business time period boundary and the intermittent message writing mark according to the message channel identifier to generate business time period features; Obtain the threshold configuration data corresponding to each message channel, extract the configured thresholds from the message processing rate threshold and message backlog threshold from the threshold configuration data, and organize the configured thresholds according to the message channel identifier to generate explicit monitoring thresholds; Monitoring configuration data is generated by associating the channel configuration data, the business time period characteristics, and the explicit monitoring threshold with the middleware identifier of the message to be monitored and the message channel identifier.
3. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, Based on the monitoring configuration data, operational data from each message channel is collected, and the operational data is filtered to obtain valid operational data, including: Extract the middleware identifier, connection configuration data, monitoring range, channel operation status marker, and message channel identifier corresponding to each message channel from the monitoring configuration data. Establish collection task entries corresponding to each message channel identifier according to the attribution relationship between the middleware identifier and the message channel identifier. Write the middleware identifier, the message channel identifier, the preset collection period, the monitoring range, and the channel operation status marker into the corresponding collection task entries to generate collection task data. Based on the connection configuration data, a data acquisition connection is established with the message middleware corresponding to the message middleware identifier to be monitored. Through the data acquisition connection, the number of messages written and processed in each message channel within the preset acquisition period is collected according to the acquisition task data. The partition end offset position, message processing end submission offset position, message backlog and partition status data of each message channel are also collected to generate raw running data. A message write rate is generated based on the number of messages written and the preset collection period. A message processing rate is generated based on the number of messages processed and the preset collection period. A message processing end lag is generated based on the difference between the partition end offset position and the corresponding message processing end submission offset position. A partition running status is generated based on the partition status data. The message write rate, message processing rate, message backlog, message processing end lag, and partition running status are combined according to the message channel identifier to generate running data corresponding to each message channel. Based on the middleware identifier of the message to be monitored and the message channel identifier, determine whether each message channel is within the monitoring range, and whether the corresponding channel running status flag is running, and generate a data filtering identifier; Based on the data filtering identifier, the running data corresponding to each message channel is filtered, and the running data of the corresponding message channel that is within the monitoring range and whose corresponding channel running status is marked as running is retained, thus obtaining valid running data.
4. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, The message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold are classified as first-category message channels, and the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold are classified as second-category message channels, including: Extract the message channel identifiers corresponding to each message channel from the valid operating data, and aggregate the extracted message channel identifiers to generate a set of channel identifiers to be classified. According to the set of channel identifiers to be classified, obtain the explicit monitoring threshold configuration items corresponding to each message channel identifier from the monitoring configuration data. The explicit monitoring threshold configuration items include message processing rate threshold configuration items and message backlog threshold configuration items. Determine whether threshold data is recorded in the message processing rate threshold configuration item and the message backlog threshold configuration item. If at least one of the message processing rate threshold configuration item and the message backlog threshold configuration item records threshold data, a configured flag is generated. If neither the message processing rate threshold configuration item nor the message backlog threshold configuration item records threshold data, an unconfigured flag is generated. Associate the configured identifier and the unconfigured identifier with their respective message channel identifiers to generate a threshold configuration result; Based on the threshold configuration results, the message channels associated with the configured identifier are classified into the first type of message channels, and the message channels associated with the unconfigured identifier are classified into the second type of message channels.
5. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, Based on the valid operational data corresponding to the first type of message channel and the configured explicit monitoring thresholds, a status analysis is performed to generate the first type of status analysis results, including: Extract the first type of message channel identifier, message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operating data corresponding to the first type of message channel. Extract the configured explicit monitoring threshold corresponding to the first type of message channel identifier from the monitoring configuration data. Assign the message write rate, message processing rate, message backlog, message processing terminal lag, partition operation status, and configured explicit monitoring threshold to the first type of message channel identifier to generate first type of channel analysis data. The message processing status is determined based on the message processing rate in the first type of channel analysis data, and the message processing status includes a message processing status and a message processing non-message status. When the message processing status is no message processing status, no message processing status determination data is generated based on the message write rate, the message backlog, the message processing terminal lag, and the partition operation status, and a first type of status analysis result is generated based on the no message processing status determination data. When the message processing status is message processing status, the running indicators to be compared are determined according to the configured explicit monitoring thresholds. The running indicators to be compared are compared with the corresponding configured thresholds to generate threshold comparison results. Threshold status determination data is generated based on the threshold comparison results, the message processing terminal lag amount and the partition running status. The first type of status analysis results are generated based on the threshold status determination data.
6. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, Obtain historical operational data and change record data of the second type of message channel; generate channel knowledge data based on the historical operational data, the change record data, and the business time period characteristics; and generate a second type of status analysis result based on the channel knowledge data and the valid operational data corresponding to the second type of message channel, including: Extract the second-type message channel identifier, historical message write rate, historical message processing rate, historical message backlog, and collection time corresponding to each second-type message channel from historical monitoring records to generate historical operation data; Extract the message channel configuration change data, message middleware topology adjustment data, and change time corresponding to the second type of message channel identifier from the configuration management records, and generate change record data; Based on the second type of message channel identifier, the collection time and the change time, the historical operation data and the change record data are time-series correlated, and business time period tags are added to the time-series correlated data according to the business time period characteristics to generate channel knowledge data; Based on the channel knowledge data, channel operation benchmark data is generated, which includes message write rate change trend, message processing rate change trend, message backlog change trend, business period operation characteristics, change impact characteristics, dynamic message processing rate threshold, and dynamic message backlog threshold. Extract message write rate, message processing rate, message backlog, message processing terminal lag, and partition operation status from the valid operational data corresponding to the second type of message channel. Generate message write status data based on the message write rate, the message write rate change trend, and the change impact characteristics. Generate message processing status data based on the message processing rate, the message processing rate change trend, the message processing terminal lag, the partition operation status, the message write status data, the business period operation characteristics, the change impact characteristics, and the dynamic message processing rate threshold. Generate message backlog status data based on the message backlog, the message backlog change trend, the dynamic message backlog threshold, the message write status data, the message processing status data, and the change impact characteristics. A second type of status analysis result is generated based on the message write status data, the message processing status data, and the message backlog status data.
7. The operational anomaly diagnosis method based on channel partitioning as described in claim 1, characterized in that, Anomaly diagnostic information is generated based on the results of the first type of state analysis and the results of the second type of state analysis, including: Extract the first type of message channel identifier, first type of status identifier, first type of status index data and first type of status generation time from the first type of status analysis results, filter the first type of abnormal message channels and determine the first type of abnormality, and generate the first type of abnormality identification data. Extract the second type of message channel identifier, second type of status identifier, second type of status index data and second type of status generation time from the second type of status analysis results, filter the second type of abnormal message channels and determine the second type of abnormality, and generate the second type of abnormality identification data. For each first-type abnormal message channel, obtain the corresponding first-type status identifier from the first-type abnormal identification data, and extract the no-message processing status judgment data or threshold status judgment data corresponding to the first-type status identifier from the first-type status analysis results to generate first-type abnormal cause data. For each second type of abnormal message channel, the corresponding second type of status identifier is obtained from the second type of abnormal identification data, and at least one of message writing status data, message processing status data and message backlog status data corresponding to the second type of status identifier is extracted from the second type of status analysis results to generate second type of abnormal cause data; A first type of anomaly handling suggestion is generated based on the first type of anomaly type and the first type of anomaly cause data; a second type of anomaly handling suggestion is generated based on the second type of anomaly type and the second type of anomaly cause data. Based on each first-type abnormal message channel, and the first-type abnormal type, first-type abnormal cause data, first-type abnormal handling suggestions and first-type status generation time corresponding to each first-type abnormal message channel, first-type abnormal diagnostic data is generated. Based on each type of second-class anomaly message channel, and the type of second-class anomaly, cause data, handling suggestions, and generation time of the second-class status corresponding to each type of second-class anomaly message channel, second-class anomaly diagnostic data is generated. Combine the first type of abnormality diagnostic data and the second type of abnormality diagnostic data to generate abnormality diagnostic information and output it.
8. A device for diagnosing operational anomalies based on channel partitioning, characterized in that, The operation anomaly diagnosis device based on channel division includes: The monitoring configuration module is used to obtain monitoring configuration data that includes business time period characteristics and explicit monitoring thresholds; The data collection and filtering module is used to collect operational data from each message channel based on the monitoring configuration data, and to filter the operational data to obtain valid operational data. The message channel classification module is used to classify the message channels corresponding to the valid operating data that are configured with the explicit monitoring threshold into the first type of message channels, and classify the message channels corresponding to the valid operating data that are not configured with the explicit monitoring threshold into the second type of message channels. The explicit threshold analysis module is used to perform status analysis based on the valid operating data corresponding to the first type of message channel and the configured explicit monitoring threshold, and generate the first type of status analysis results. The channel knowledge analysis module is used to acquire historical operation data and change record data of the second type of message channel, generate channel knowledge data based on the historical operation data, the change record data and the business time period characteristics, and generate second type of status analysis results based on the channel knowledge data and the valid operation data corresponding to the second type of message channel. An anomaly diagnosis output module is used to generate anomaly diagnosis information based on the first type of state analysis results and the second type of state analysis results.
9. A computer device, characterized in that, The computer device includes a memory, a processor, and a channel-based runtime anomaly diagnostic program stored in the memory and executable on the processor. When executed by the processor, the channel-based runtime anomaly diagnostic program implements the steps of the channel-based runtime anomaly diagnostic method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a channel-based runtime anomaly diagnosis program, which, when executed by a processor, implements the steps of the channel-based runtime anomaly diagnosis method as described in any one of claims 1-7.