Method for locating missing root cause of api interface data based on dual-link observability

Abstract

The application discloses a double-link observable-based API interface data loss root cause positioning method, relates to the technical field of data operation and maintenance, and comprises the following steps: acquiring API requests from an API request query link and query request information of the API requests, wherein the query request information comprises first data identifiers and first time identifiers of to-be-queried data; acquiring data generation state information from a data generation link of a data production supply end, wherein the data generation state information comprises second data identifiers and second time identifiers corresponding to data generation tasks; establishing an association relationship between the API requests and the data generation tasks based on the first data identifiers, the first time identifiers, the second data identifiers and the second time identifiers; and if a response result of a target API request is data loss, determining a data loss root cause based on the association relationship, the target API request and a target data generation task. The application improves the positioning efficiency and accuracy of data loss faults.

Description

Technical Field

[0001] This application relates to the field of data operation and maintenance technology, and in particular to a method for locating the root cause of missing API interface data based on dual-link observability. Background Technology

[0002] With the widespread use of APIs (Application Programming Interfaces), their importance in data service operation and maintenance is becoming increasingly prominent.

[0003] Currently, troubleshooting for missing API return data mainly relies on single-link observation using log systems, metric monitoring tools, and application performance management tools, or on multi-link correlation analysis using human experience.

[0004] Therefore, when the interface returns missing data, existing methods have difficulty tracing back to the specific task status, resource load, or billing progress of the data generation chain, which makes the fault location process dependent on manual experience, time-consuming, and prone to missing key factors, resulting in low efficiency in locating the root cause of data loss. Summary of the Invention

[0005] The main objective of this application is to provide a method for locating the root cause of missing data in API interfaces based on dual-link observability, aiming to solve the technical problem of low efficiency in existing methods for locating the root cause of missing data.

[0006] To achieve the above objectives, this application proposes a method for locating the root cause of missing API interface data based on dual-link observability, the method comprising:

[0007] Obtain the API request from the API request query terminal query link and the query request information of the API request, wherein the query request information includes the first data identifier and the first time identifier of the data to be queried;

[0008] Obtain data generation status information from the data generation link of the data production supply side, wherein the data generation status information includes a second data identifier and a second time identifier corresponding to the data generation task;

[0009] Based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier, establish the association between the API request and the data generation task;

[0010] If the response to the target API request is that data is missing, the root cause of the missing data is determined based on the aforementioned relationship, the target API request, and the target data generation task.

[0011] In one embodiment, the step of establishing the association between the API request and the data generation task based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier, includes:

[0012] The first data identifier is combined with the first time identifier to obtain a query association key that represents the API request;

[0013] The second data identifier is combined with the second time identifier to obtain a task association key that characterizes the data generation task;

[0014] If the value corresponding to the query association key and the task association key are successfully matched, an association relationship is established between the API request corresponding to the query association key and the data generation task corresponding to the task association key.

[0015] In one embodiment, the data generation status information further includes the execution status of the data generation task, and the step of determining the root cause of data loss based on the association, the target API request, and the target data generation task includes:

[0016] Based on the aforementioned relationship, the target data generation task associated with the target API request is located;

[0017] Based on the second data identifier corresponding to the target data generation task, determine the billing status information of the data table associated with the second data identifier;

[0018] The first time identifier in the API request is compared with the billing status information, and the root cause of data loss is determined based on the comparison result and the execution status of the target data generation task.

[0019] In one embodiment, the billing period status information includes billing period calculation in progress, and the step of determining the root cause of data missing based on the comparison results and the execution status of the target data generation task includes:

[0020] If the query time point corresponding to the first time identifier is equal to the time point represented by the billing period being calculated, and the execution status of the target data generation task is running, then the root cause of the data missing is determined to be that the data is not ready.

[0021] In one embodiment, the billing period status information includes the latest available billing period, and the step of determining the root cause of data missing based on the comparison results and the execution status of the target data generation task further includes:

[0022] If the query time point corresponding to the first time identifier is after the time point represented by the latest available billing period, then the root cause of the missing data is determined to be a data return anomaly.

[0023] In one embodiment, the step of determining the root cause of missing data based on the association, the target API request, and the target data generation task further includes:

[0024] Obtain the billing period status information of the data table associated with the first data identifier, wherein the billing period status information includes the latest available billing period of the data table;

[0025] If the first time identifier is before the time point represented by the latest available billing period, and the target data generation task associated with the API request cannot be located based on the association, then the root cause of the data missing is determined to be an advanced query.

[0026] In one embodiment, after the step of stating that the response result of the target API request is missing data, the method further includes:

[0027] Based on the aforementioned relationship, the target data generation task associated with the API request is located;

[0028] Obtain the task characteristics of the target data generation task;

[0029] The task features are input into a pre-trained time prediction model to obtain the estimated completion time of the target data generation task;

[0030] Based on the estimated completion time and the preset business timeliness threshold, the delay level of the root cause of data loss is determined.

[0031] In one embodiment, the delay level includes a first level, a second level, a third level, and a fourth level. Following the step of determining the delay level of the data missing root cause based on the estimated completion time and a preset business timeliness threshold, the method includes:

[0032] If the delay level is Level 1, then the estimated completion time is appended to the root cause of the missing data.

[0033] If the delay level is the second level, then analyze the task execution resources and generate resource adjustment suggestions, and use the resource adjustment suggestions as additional root cause information for the data missing root cause;

[0034] If the delay level is level three, then trace the upstream dependent tasks of the target data generation task. If the upstream dependent task fails or is delayed, then update the root cause of the data missing to the anomaly of the preceding task.

[0035] If the delay level is level four, the root cause of the missing data will be updated to an abnormal task execution environment and an alarm will be triggered.

[0036] In one embodiment, after the step of stating that the response result of the target API request is missing data, the method further includes:

[0037] Determine whether there exists a target data generation task that matches both the first data identifier and the first time identifier of the target API request;

[0038] If the target data generation task does not exist, then based on the first data identifier, the data generation task currently processing the data corresponding to the first data identifier is found in the data generation chain and used as the associated data generation task;

[0039] Establish a new association between the associated data generation task and the target API request, and determine the root cause of data loss based on the new association.

[0040] In one embodiment, the root cause of the missing data includes defects in the input data upon which the target data generation task depends, and the method further includes:

[0041] If the execution status of the target data generation task is completed, then obtain the upstream dependent tasks of the target data generation task;

[0042] Obtain the final execution status and output data verification results of the upstream dependent tasks;

[0043] If the final execution status of at least one upstream dependent task is failure, or the output data verification result is not passed, then the root cause of the missing data is determined to be a defect in the input data on which the target data generation task depends.

[0044] Furthermore, to achieve the above objectives, this application also proposes a root cause localization device, the root cause localization device comprising:

[0045] The first acquisition module is used to acquire the API request from the API request query terminal query link and the query request information of the API request, wherein the query request information includes the first data identifier and the first time identifier of the data to be queried;

[0046] The second acquisition module is used to acquire data generation status information from the data generation link of the data production supply side, wherein the data generation status information includes a second data identifier and a second time identifier corresponding to the data generation task.

[0047] A module is established to establish an association between the API request and the data generation task based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier;

[0048] The determination module is used to determine the root cause of data loss based on the association, the target API request, and the target data generation task if the response result of the target API request is data loss.

[0049] Furthermore, to achieve the above objectives, this application also proposes a root cause localization device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the root cause localization method for missing API interface data based on dual-link observables as described above.

[0050] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the API interface missing data root cause localization method based on dual-link observable as described above.

[0051] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the dual-link observable API interface data missing root cause localization method described above.

[0052] One or more technical solutions proposed in this application have at least the following technical effects: by obtaining the data identifier and time identifier of the API request from the query link and the data identifier and time identifier of the data to be queried contained therein, as well as the data identifier and time identifier corresponding to the data generation task from the data generation link, the synchronous collection and aggregation of the status information of the API request query end and the data production supply end are realized, thereby associating the originally isolated query behavior with the data generation process.

[0053] Furthermore, based on the shared data identifier and time identifier of the API request and the data generation task as the association key, the association between the two is established, so that any API request that returns missing data can be directly and accurately associated with the data generation task responsible for generating the data required for that API request, thus establishing a traceable logic for cross-link causal association.

[0054] When the response to the target API request indicates missing data, the root cause of the missing data is determined based on the correlation, the target API request, and the target data generation task. This transforms the inefficient troubleshooting model, which relies on manual querying of logs, task logs, and resource monitoring by operations personnel for empirical inference, into a root cause localization process based on automatic correlation of dual links and real-time analysis of task status. This effectively solves the problems of existing fault localization relying on manual experience, being time-consuming, and easily overlooking key factors, and significantly improves the efficiency and accuracy of locating missing data faults. Attached Figure Description

[0055] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0056] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a flowchart illustrating an embodiment of the API interface data missing root cause localization method based on dual-link observables provided in this application;

[0058] Figure 2 This is a flowchart illustrating another embodiment of the API interface data missing root cause localization method based on dual-link observables provided in this application;

[0059] Figure 3 This is a flowchart illustrating another embodiment of the API interface data missing root cause localization method based on dual-link observables in this application.

[0060] Figure 4 This is a schematic diagram of the module structure of the root cause localization device of this application;

[0061] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the dual-link observable API interface data missing root cause localization method of this application.

[0062] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0063] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0064] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0065] In the field of data operations and maintenance, locating data loss faults mainly relies on manual querying of logs and monitoring charts, troubleshooting layer by layer at the network, service, and database levels. This is time-consuming and experience-dependent. Specifically, one technical solution is to identify the cause of data loss by verifying the consistency of API-transmitted data with predefined metadata templates in terms of field structure, type, and format. Another technical solution is to analyze indicators directly related to service availability, such as API call success rate, response latency, and error code frequency, to identify the cause of data loss. The first solution aims to verify the conformity of data format based on a predefined metadata template; its technical methods and judgment criteria revolve around format, without addressing or perceiving the specific progress and status of data generation (e.g., whether the computation task has started, is running, or has failed). The second solution aims to monitor and evaluate the real-time availability and performance of the interface service. However, because its technical methods rely solely on external call indicators and do not obtain the internal execution status of data production tasks, it cannot distinguish between the more specific causes of data loss, such as "service responds normally but data is not generated" versus "service itself is abnormal."

[0066] This application, by synchronously or asynchronously acquiring and associating query request information in the query chain with task execution status information in the data generation chain, can cover situations where existing solutions determine data loss due to backend production issues, even when services and formats are normal. Although existing solutions are aware that the backend generates data during API queries, the specific problems they address and the technical means they employ (format validation or service monitoring) are different operational goals. Furthermore, their data processing logic and judgment criteria do not require association with the instance status of specific data production tasks to achieve their objectives. This means they have neither the motivation nor the need to establish a connection from query to generation task based on specific data identifiers and time identifiers, and they do not provide technical means for automated root cause classification based on such a connection.

[0067] It should be noted that the executing entity in this embodiment can be a root cause localization device, such as a server, server cluster, cloud server, or dedicated data processing device; it can also be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone; or it can be an electronic device, edge computing node, or distributed system capable of implementing the above functions. The following description uses a root cause localization device as an example to illustrate this embodiment and the subsequent embodiments.

[0068] Based on this, embodiments of this application provide a method for locating the root cause of missing API interface data based on dual-link observability, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the dual-link observable API interface data missing root cause localization method of this application.

[0069] In this embodiment, the API interface data missing root cause localization method based on dual-link observability includes steps S1 to S4:

[0070] Step S1: Obtain the API request and the query request information of the API request from the API request query terminal query link, wherein the query request information includes the first data identifier and the first time identifier of the data to be queried;

[0071] In one feasible embodiment, the root cause localization device obtains the API request from the API request query link and the query request information carried by the API request.

[0072] Alternatively, this application may be for root cause localization performed in response to a query operation.

[0073] Optionally, an API request refers to a data call operation initiated by an external business system, application, or user to a data service interface, with the aim of requesting specific data content.

[0074] Optionally, the API request query end refers to the source client or server system that initiates the API request.

[0075] Optionally, the query chain refers to the complete transmission and processing chain of the network path, gateway, and middleware services that the API request passes through from its issuance to its arrival at the data service interface.

[0076] Optionally, query request information refers to a set of metadata encapsulated within the API request that describes the intent and specific requirements of the query.

[0077] Optionally, the data to be queried refers to the target data content that the API caller hopes to obtain through this request.

[0078] Optionally, the first data identifier is metadata in the query request information, used to uniquely identify and specify the data entity object to be queried. Its full name can be the data table name, such as "user's latest location".

[0079] Optionally, the first time identifier is another metadata in the query request information, which is used to indicate the business time period or version corresponding to the data to be queried. Its full name can be the query period, such as "20250501", which means that the request is to query the data under the period of May 1, 2025.

[0080] Optionally, in addition to the first data identifier and the first time identifier, the query request information may also include other metadata, such as the unique sequence number of the API request, the user identifier of the requester, or the authentication token.

[0081] Step S2: Obtain data generation status information from the data generation link of the data production supply side, wherein the data generation status information includes the second data identifier and the second time identifier corresponding to the data generation task.

[0082] In one feasible embodiment, the root cause localization device acquires data generation status information from the data generation link of the data production supply side.

[0083] Optionally, the data production supply side refers to the backend data processing platform or cluster responsible for performing data calculations, processing, and storage, and providing data results to the API.

[0084] Optionally, the data generation chain refers to the complete production process from the original source of data through extraction, transformation, loading, and computational processing, until it forms target data that can be queried by API.

[0085] Optionally, data generation status information refers to a set of information reflecting the real-time status of data processing operations within the data production supply side.

[0086] Optionally, a data generation task refers to a computational job instance responsible for producing a batch or type of data in the data generation chain.

[0087] Optionally, the second data identifier is a parameter in the data generation status information, used to indicate the data entity processed and produced by the data generation task. Its full name can be the name of the task-related data table, such as "user's latest location", which logically refers to the same data object as the first data identifier.

[0088] Optionally, the second time identifier is another parameter in the data generation status information, used to indicate the target business time period or version corresponding to the data processed by the data generation task. Its full name can be the task target billing period, such as "20250501".

[0089] Step S3: Based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier, establish the association between the API request and the data generation task;

[0090] In one feasible embodiment, the root cause localization device establishes an association between API requests and data generation tasks based on the acquired first data identifier and first time identifier, and a second data identifier and second time identifier.

[0091] Optionally, the root cause localization device achieves the matching of query requirements with production tasks by comparing whether the first data identifier and the second data identifier are the same, and whether the first time identifier and the second time identifier are the same.

[0092] Optionally, the specific association logic is to use "data identifier combined with time identifier" as a composite association key. For example, when the root cause localization device finds that the first data identifier in the query request information of an API request is "the latest location of the user" and the first time identifier is "20250501", it will look for tasks in the status information of all data generation tasks that also have the second data identifier "the latest location of the user" and the second time identifier "20250501", thereby establishing a one-to-one or one-to-many mapping relationship between the two. This association relationship constitutes the basis for dual-link observation collaboration.

[0093] Understandably, this association, through the construction of a dual-link spatiotemporal association model using "data table (i.e., data identifier) ​​+ payment period (i.e., time identifier)" as the association key, achieves a direct mapping between API queries and data generation tasks. Existing technologies, lacking corresponding associations, require manual cross-link and cross-system tracing when locating the root cause of missing data, averaging over 4 hours. This application, through this association, achieves automatic and rapid matching of query requirements and data production status, thereby shortening the root cause location time to less than 10 minutes, effectively solving the problem of low location efficiency in existing technologies.

[0094] Step S4: If the response result of the target API request is that the data is missing, then determine the root cause of the missing data based on the relationship, the target API request, and the target data generation task.

[0095] In one feasible embodiment, if the root cause location device detects that the response result of a target API request is missing data, it finds the target data generation task associated with the target API request based on the established association relationship, and analyzes and determines the root cause of the data missing by combining the query request information of the target API request and the data generation status information of the target data generation task.

[0096] Optionally, the target API request refers to the specific API request instance that needs to be analyzed for root causes and whose response is missing data.

[0097] Optionally, the target data generation task refers to a data processing job instance that corresponds to the target API request, determined through association relationships.

[0098] Optionally, the process of determining the root cause of missing data includes: the root cause location device checking the status of the target data generation task, such as whether it has been started, whether it has failed to run, or whether it has been completed but the data has not been published; optionally, the root cause location device also compares the query time of the target API request with the planned cycle of data production to determine whether it is a "premature query"; the root cause location device can also check the resource load during task execution and classify the analysis results into specific root cause categories such as "data has not reached the generation time", "computation task execution failed", "computation task is delayed due to insufficient resources", and "data generation link interruption".

[0099] Optionally, the root cause of missing data can be fed back to the user through a visual interface, realizing a complete closed loop from observation and correlation to root cause localization.

[0100] It is understandable that the establishment of relationships and the determination of the reasons for missing data can be achieved at different times, or at the same time.

[0101] This embodiment provides a method for locating the root cause of missing API interface data based on dual-link observability. By acquiring the data identifier and time identifier of the API request and its contained queried data from the query link, and the data identifier and time identifier of the data generation task from the data generation link, it achieves synchronous collection and aggregation of status information from the API request query end and the data production supply end, thereby associating the originally isolated query behavior with the data generation process. Furthermore, based on the shared data identifier and time identifier of the API request and the data generation task as the association key, a relationship is established between the two, so that any API request that returns missing data can be directly and accurately associated with the data generation task responsible for generating the data required for that API request, establishing a traceable logic for cross-link causal association. When the response to the target API request indicates missing data, the root cause of the missing data is determined based on the correlation, the target API request, and the target data generation task. This transforms the inefficient troubleshooting model, which relies on manual querying of logs, task logs, and resource monitoring by operations personnel for empirical inference, into a root cause localization process based on automatic correlation of dual links and real-time analysis of task status. This effectively solves the problems of existing fault localization relying on manual experience, being time-consuming, and easily overlooking key factors, and significantly improves the efficiency and accuracy of locating missing data faults.

[0102] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, step S3 may include steps S31 to S33:

[0103] Step S31: Combine the first data identifier with the first time identifier to obtain the query association key used to represent the API request;

[0104] In one feasible embodiment, the root cause localization device combines a first data identifier and a first time identifier from the API request query request information to generate a query association key that uniquely represents the API request.

[0105] Optionally, a combination operation refers to connecting or splicing two or more parameters together according to predetermined rules to form a new key value.

[0106] Optionally, the first data identifier is a parameter used to indicate the data entity to be queried, and its full name can be the name of the target data table.

[0107] Optionally, the first time identifier is a parameter used to indicate the business cycle of the data to be queried, and its full name can be the query period.

[0108] Optionally, the query join key is a composite key, which is composed of the value of the first data identifier and the value of the first time identifier. For example, the data table name "Latest User Location" and the billing period "20250501" are connected by an underscore or a specific separator to form a string such as "Latest User Location_20250501". This query join key can uniquely represent the query requirement of "querying the billing period data of the latest user location table on May 1, 2025".

[0109] Step S32: Combine the second data identifier with the second time identifier to obtain the task association key used to characterize the data generation task;

[0110] In one feasible embodiment, the root cause localization device combines a second data identifier and a second time identifier from the data generation status information from the data production supply side to generate a task association key that uniquely represents the data generation task.

[0111] Optionally, the second data identifier is a parameter used to specify the data entity processed by the data generation task, and its full name can be the name of the task-related data table.

[0112] Optionally, the second time identifier is a parameter used to specify the data business cycle processed by the data generation task, and its full name can be the task target billing period.

[0113] Optionally, the task association key is a composite key, which is composed of the value of the second data identifier and the value of the second time identifier. For example, the data table name "Latest User Location" processed by the task is connected with the task target billing period "20250501" using the same rule to form a string such as "Latest User Location_20250501". This task association key can uniquely represent the specific data generation task of "generating the latest user location table billing data for May 1, 2025".

[0114] Step S33: If the value corresponding to the query association key and the task association key matches successfully, establish the association relationship between the API request corresponding to the query association key and the data generation task corresponding to the task association key.

[0115] In one feasible embodiment, the root cause localization device performs a matching judgment, that is, compares the value of the query association key generated by the API request with the value of the task association key generated by all data generation tasks one by one.

[0116] Optionally, a successful match means that the root cause locator finds that the value of the task association key is exactly the same as the value of the currently queried association key.

[0117] Optionally, if a match is successful, the root cause location device establishes an association between the entity corresponding to the query association key and the task association key, that is, an association between the API request instance corresponding to the query association key and the data generation task instance corresponding to the task association key.

[0118] Optionally, establishing an association means that the root cause localization device records mapping information such as "API request ID is X1, associated with data generation task ID is Y1", thereby providing deterministic data support for subsequent collaborative observation and root cause analysis based on dual links.

[0119] Understandably, the relationship is the foundation for subsequent root cause analysis. It aims to address a query request for a specific target data. If the data corresponding to the query request is missing, the data can be directly traced back to the specific computational task that processed the data corresponding to that query request.

[0120] For example, please refer to Figure 2 , Figure 2This paper presents a flowchart illustrating a dual-link observable API interface data missing root cause localization method. Specifically, it illustrates a partial query link: when an API request is initiated, a first data identifier (such as the target data table name) and a first time identifier (such as the query billing period) are extracted from the API request query information, and these two are combined to generate a global query association key. It also illustrates a partial data generation link: when a background data generation task is executed, it includes a second data identifier (such as the task-related data table name) and a second time identifier (such as the task's target billing period), which are combined to generate a task association key. Only when the query association key and the task association key completely match are the associations established between the API request and the specific data generation task, thus providing cross-link (between the query link and the data generation link) tracing evidence for subsequent accurate localization of the data missing root cause.

[0121] In this embodiment, by combining the target data table name and the query billing period in the API query request to form a query association key, and combining the associated data table name and the target billing period in the data generation task to form a task association key, a precise and stable data association is established between the query chain and the data generation chain. This method utilizes association key matching to automatically and accurately identify the correspondence between API queries serving the same business need and backend calculation tasks. This allows for direct identification of the specific task responsible for generating the data when API query returns missing data, eliminating the need for manual tracing and comparison across multiple operation and maintenance tools, thus significantly shortening the problem-solving path. Because the generation and matching process of association keys is computationally simple, the entire association process has low execution overhead and high reliability.

[0122] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Furthermore, the data generation status information also includes the execution status of the data generation task, and step S4 may include steps D1~D3:

[0123] Step D1: Locate the target data generation task associated with the target API request based on the relationship;

[0124] In one feasible embodiment, the root cause localization device uses established associations to locate the target data generation task that is uniquely associated with the target API request that needs to be analyzed.

[0125] Optionally, the association relationship refers to a data structure or record that represents the mapping relationship between API requests and data generation tasks, such as a mapping table containing the correspondence between API request identifiers and data generation task identifiers.

[0126] Step D2: Generate a second data identifier corresponding to the task based on the target data, and determine the billing status information of the data table associated with the second data identifier;

[0127] In one feasible embodiment, the root cause localization device generates a second data identifier corresponding to the task based on the located target data, and further queries or calculates the billing status information associated with the specific data table pointed to by the second data identifier.

[0128] Optionally, the billing status information of a data table refers to a set of statuses describing the data readiness of the data table in the time dimension, which includes at least the latest available billing period and the billing period being calculated.

[0129] Optionally, the latest available billing period refers to the billing period corresponding to the latest business time period for which the data table has been calculated, stored, and is available for API querying.

[0130] Optionally, "calculating billing period" refers to the billing period corresponding to the business time period for which the data table is currently being processed by the data generation task but has not yet been calculated and published.

[0131] Step D3: Compare the first time identifier in the API request with the billing status information, and determine the root cause of data loss based on the comparison results and the execution status of the target data generation task.

[0132] In one feasible embodiment, the root cause localization device compares and analyzes the first time identifier contained in the query request information of the target API request with the obtained billing status information one by one.

[0133] Optionally, the comparison operation refers to comparing the value identified at the first time with the value of the latest available payment period and the value of the payment period being calculated, respectively, to determine their sequential or equal relationship.

[0134] Optionally, the execution status of the target data generation task refers to the current lifecycle stage of the task, and its full name can be the task execution status, such as "not started", "running", "failed", "successful", etc.

[0135] Optionally, the process of determining the root cause of missing data may include: determining whether the query is ahead of schedule (i.e., the query period is later than the latest available period and not equal to any currently calculated period) or whether the query is targeting data being processed (i.e., the query period is equal to a currently calculated period); then, combining the execution status of the target data generation task (e.g., task failure, task timeout), inferring and determining the specific root cause of the missing data, such as "the query period is ahead of the data production plan," "the corresponding calculation task failed," or "the corresponding calculation task is still in progress." For example, the root cause of missing data may also be determined by combining task execution logs or resource metrics.

[0136] In one feasible implementation, the payment period status information includes that the payment period is being calculated, and step D3 may include:

[0137] If the query time point corresponding to the first time identifier is equal to the time point represented by the billing period being calculated, and the execution status of the target data generation task is running, then the root cause of the missing data is determined to be that the data is not ready.

[0138] In one feasible embodiment, if the root cause localization device finds that the specific query time point corresponding to the first time identifier in the target API request is exactly the same as the specific time point represented by the billing period being calculated in the billing period status information, and at the same time detects that the execution status of the target data generation task associated with the target API request is running, it determines that the root cause of the data missing is that the data is not ready.

[0139] Optionally, the point in time indicated by "calculating the billing period" refers to the target business time point where the data table is currently being processed by a calculation task, but the results are not yet ready for use.

[0140] Optionally, the execution status of the target data generation task being "running" means that the task is in an active execution process and has not yet been successfully completed or failed, i.e., the task is in a running state.

[0141] Alternatively, "data not ready" is a specific root cause category that indicates that the data requested by the user is in the normal computational production process and cannot be provided temporarily because the processing has not yet been completed. It is an expected and temporary data missing state.

[0142] In one feasible implementation, the payment period status information includes the latest available payment period, and step D3 may further include:

[0143] If the query time point corresponding to the first time identifier is after the time point represented by the latest available billing period, then the root cause of the missing data is determined to be an abnormal data return.

[0144] In one feasible embodiment, if the root cause localization device finds that the specific query time point corresponding to the first time identifier in the target API request is later in time than the specific time point represented by the latest available billing period in the billing period status information, it determines that the root cause of the data loss is abnormal data return.

[0145] Optionally, the first time identifier corresponds to the query time point, which refers to the specific time point of the business data that the user wants to query, parsed from the query request information of the API request, i.e., the query billing period time point.

[0146] Optionally, the latest available billing period refers to the business time point corresponding to the latest set of data that has been calculated, stored, and is available for querying in the corresponding data table.

[0147] Optionally, "the query time point corresponding to the first time identifier is after the time point represented by the latest available billing period" means that the query billing period time point is numerically greater than the latest available billing period time point, that is, the user requests to query data from an earlier, past billing period.

[0148] Optionally, data return anomaly is a specific root cause category, indicating that the data billing period requested by the user should not logically be missing (because it is later than the latest available billing period, so theoretically there is data), but it was not actually returned. This indicates that there is an unplanned failure, blockage, or logical error in the data generation chain, which caused the data to fail to be produced as expected, and is an unexpected abnormal state.

[0149] In one feasible implementation, step S4 may include steps S41-S42:

[0150] Step S41: Obtain the billing period status information of the data table associated with the first data identifier, wherein the billing period status information includes the latest available billing period of the data table;

[0151] In one feasible embodiment, the root cause localization device queries and obtains the billing status information corresponding to a specific data table pointed to by the first data identifier in the target API request query request information.

[0152] Optionally, the latest available period of a data table refers to the business time period corresponding to the latest set of data in the data table that has completed all calculation and processing procedures, has been persistently stored, and is available for external query access.

[0153] Step S42: If the first time is identified before the time point represented by the latest available billing period, and the target data generation task associated with the API request cannot be located based on the relationship, then the root cause of the missing data is determined to be an advanced query.

[0154] In one feasible embodiment, the root cause locator first determines whether the query time represented by the first time identifier in the target API request is earlier than the time represented by the latest available billing period obtained from the billing status information. Simultaneously, the root cause locator performs mapping using established associations, but finds that it cannot successfully locate any data generation task associated with the target API request. When both conditions are met, the root cause locator determines that the root cause of the data loss is a premature query.

[0155] Optionally, "identified before the time point represented by the latest available payment period" means that the time point represented by the payment period being queried is numerically less than the time point represented by the latest available payment period. In other words, the user is requesting data that is newer than the current latest data and represents a future payment period.

[0156] Optionally, if the target data generation task associated with the API request cannot be located based on the association relationship, it means that after the root cause location device searches in the mapping relationship it maintains, it fails to find any data generation task whose task association key matches the query association key of the target API request. This indicates that the data production supply side has not arranged or executed the task of producing the data for that period.

[0157] Optionally, ahead query is a specific root cause category, indicating that the data period requested by the user is earlier than the latest data period that is currently available, and no production or calculation tasks have been scheduled for that future period. Therefore, the data does not actually exist, which is a data missing state caused by the query demand exceeding the current data supply.

[0158] For example, please refer to Figure 3 , Figure 3 This document presents a flowchart illustrating a method for locating the root cause of missing data in API interfaces based on dual-link observability. Specifically, if the response to a target API request indicates missing data, the method starts from the target API request, locates and analyzes the data based on correlations, and ultimately determines the root cause of the missing data. Specifically, a first time identifier is extracted from the query request information of the target API request. Based on the previously established correlations, the target API request is mapped to its corresponding target data generation task. Next, based on the second data identifier carried by the target data generation task, the billing status information of the data table corresponding to the second data identifier is obtained. Simultaneously, the execution status of the target data generation task is acquired. Finally, the first time identifier is compared with the billing status information, and combined with the execution status of the target data generation task, the root cause causing the missing data is determined, thus completing the entire root cause location process.

[0159] In this embodiment, by comparing the query period in the API query request with the latest available period and the period currently being calculated in the associated data table, and combining this with the real-time execution status of the task generated by the associated data, the root cause of data loss is automatically classified and determined without relying on manual retrieval of task logs and data table statuses layer by layer. This method reduces the subjective reliance on the personal experience of operations and maintenance personnel and improves the reliability of the root cause judgment process. At the same time, the clear classification of the reasons for data loss provides specific and actionable feedback information to the API request query end, such as indicating whether the data is still being calculated or the query period is ahead of schedule, allowing it to adjust the query time or formulate a waiting plan accordingly.

[0160] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Furthermore, after step S4, if the response result of the target API request is that the data is missing, steps A1 to A4 are also included:

[0161] Step A1: Locate the target data generation task associated with the API request based on the relationship;

[0162] In one feasible embodiment, after the root cause localization device has determined that the response result of the target API request is missing data, it uses the previously established and maintained association relationship to accurately identify the target data generation task that has a mapping relationship with the target API request from among many data generation tasks.

[0163] Optionally, the location operation refers to querying the association mapping table or index based on the identifier (such as ID) of the target API request, thereby retrieving the unique identifier (such as ID) and access path of the target data generation task bound to it.

[0164] Step A2: Obtain the task characteristics of the target data generation task;

[0165] In one feasible embodiment, after successfully locating the target data generation task, the root cause localization device further collects and obtains a set of parameters, i.e., task characteristics, from the monitoring system or task management platform of the data production supply side.

[0166] Optionally, task characteristics are a set of parameters containing multiple dimensions, which are key factors affecting the progress of task execution.

[0167] Optionally, task characteristics may specifically include task type (e.g., batch computing, streaming computing), the size of the data to be processed, the number of computing resources currently allocated to the task (e.g., the number of threads), the real-time load level of the computing cluster where the task is running (e.g., high, medium, low), and the historical average execution time of the task.

[0168] Step A3: Input the task features into the pre-trained time prediction model to obtain the estimated completion time of the target data generation task;

[0169] In one feasible embodiment, the root cause localization device takes the acquired task feature vector, which consists of multi-dimensional parameters, as input data and provides it to a pre-trained machine learning model, namely a time prediction model. The time prediction model calculates and analyzes the input features and finally outputs a time point prediction value, namely the expected completion time of the target data generation task.

[0170] Optionally, a pre-trained time prediction model refers to a mathematical model that is trained using machine learning algorithms (such as Gradient Boosting Regression Tree (GBRT)) by utilizing historical task execution records and their corresponding features and actual completion times, and is capable of learning the complex relationship between task features and time consumption.

[0171] Optionally, the expected completion time is a predicted value for a future time point, representing the time when the target data generation task will end, inferred by the time prediction model based on the current task characteristics, such as "2025 / 5 / 1 10:30".

[0172] Step A4: Determine the delay level of the root cause of data loss based on the estimated completion time and the preset business timeliness threshold.

[0173] In one feasible embodiment, the root cause localization device compares the estimated completion time output by the time prediction model with a time threshold predefined according to business requirements. By assessing the degree to which the predicted completion time of the task deviates from business expectations, the device determines the delay level corresponding to the root cause of the data missing.

[0174] Optionally, the preset business timeliness threshold is one or more time points or time periods determined by business rules, such as the final deadline when data must be ready, or the baseline time for the completion of a data generation task.

[0175] Optionally, the process of determining the delay level includes: calculating the time difference between the estimated completion time and the business timeliness threshold, and classifying the delay into different levels such as "minor delay," "moderate delay," and "serious delay" based on the different intervals in which the time difference falls. For example, ratios, weights, etc., can also be calculated.

[0176] In one feasible implementation, the delay levels include a first level, a second level, a third level, and a fourth level, and steps A41 to A44 are included after step A4:

[0177] Step A41: If the delay level is Level 1, then add the estimated completion time to the root cause of the missing data.

[0178] In one feasible embodiment, when the root cause localization device determines that the delay level corresponding to the current data missing root cause is the first level based on the comparison result of the estimated completion time and the business timeliness threshold, the root cause localization device performs an information appending operation, that is, adds the estimated completion time calculated by the time prediction model to the preliminarily determined data missing root cause description information.

[0179] Optionally, the first level is the lowest severity level in the delay levels, indicating that although there is a delay in the predicted completion time of the data generation task, the delay duration is within the acceptable tolerance range of the business, or the impact on downstream business is very minor.

[0180] Optionally, additional operations refer to adding a field or description to an existing data missing root cause text or data structure to add the estimated completion time.

[0181] Optionally, the estimated completion time is the future moment when the task ends, calculated by the time prediction model based on the target data derived from the current task characteristics.

[0182] Step A42: If the delay level is Level 2, analyze the task execution resources and generate resource adjustment suggestions, and use the resource adjustment suggestions as additional root cause information for the data missing root cause.

[0183] In one feasible embodiment, when the root cause localization device determines that the delay level is Level 2, it initiates an analysis process on the computing resources occupied and available for the target data generation task, and automatically generates a suggestion on how to optimize resource allocation based on the analysis results. Then, this resource adjustment suggestion is used as more detailed supplementary information and associated with the root cause record of the data loss.

[0184] Optionally, the second level is a more severe delay level than the first level, indicating that the task delay has already had a certain impact on the business, and the delay is likely related to insufficient or mismatched computing resources (such as CPU, memory, parallelism).

[0185] Optionally, analyzing task execution resources refers to the root cause localization device collecting and investigating resource indicators during task execution, such as the number of threads allocated to the task, CPU utilization, memory utilization, and waiting status of the cluster queue.

[0186] Optionally, generating resource adjustment suggestions involves the root cause localization device proposing specific improvement measures based on preset resource configuration rules, such as suggesting "add 5 thread instances to the task" or "schedule the task to a cluster node with a lower load".

[0187] Step A43: If the delay level is level 3, trace the upstream dependent tasks of the target data generation task. If the upstream dependent task fails or is delayed, update the root cause of data loss to the anomaly of the preceding task.

[0188] In one feasible embodiment, when the root cause localization device determines that the delay level is level three, it will trace back along the data processing pipeline to explore the status of the upstream tasks on which the target data generation task depends. If it is found that the upstream dependent task itself has failed or has experienced a serious delay, the root cause localization device will update the determination of the root cause of the current data loss and correct the root cause to be an abnormality of the preceding task.

[0189] Alternatively, Level 3 is a more severe delay level, indicating that the delay in the current task is caused by a failure in other, more upstream, or dependent tasks.

[0190] Optionally, tracing upstream dependent tasks refers to the root cause localization device querying the dependency graph of task scheduling to find all previous tasks that provided input data or triggering conditions for the target data generation task.

[0191] Alternatively, upstream dependency task failure or delay refers to these preceding tasks being in a state of "execution failure", "infinite retries" or "running time far exceeding the baseline".

[0192] Optionally, updating the root cause of missing data to an earlier task anomaly means that the root cause localization device replaces or overwrites the initial root cause judgment (such as "task ran too long") with a new, more fundamental fault category, thereby revealing the root cause of the missing data fault more accurately.

[0193] In step A44, if the delay level is level four, update the root cause of the missing data to an abnormal task execution environment and trigger an alarm.

[0194] In one feasible embodiment, when the root cause localization device determines that the delay level is the fourth level, which is the highest severity level, it will comprehensively consider various indicators to infer that there is a problem with the underlying environment on which the task execution depends, and then characterize the root cause of the data loss as an abnormal task execution environment, and at the same time automatically trigger a high-priority alarm notification.

[0195] Optionally, Level 4 is the most severe delay level, indicating that the data generation task has encountered significant obstacles, with long delay times, wide business impact, and the cause usually pointing to failures at the infrastructure level such as clusters, networks, and storage.

[0196] Optionally, an abnormal task execution environment is a root cause category that covers underlying platform issues that prevent tasks from executing normally, such as unavailable computing clusters, network partitions, interruptions in distributed storage services, and failures of critical middleware.

[0197] Optionally, triggering an alarm refers to the root cause location device calling the interface of the monitoring and alarm system to generate an alarm event containing a fault summary, scope of impact, and severity level, and pushing it to relevant maintenance personnel so that emergency response procedures can be initiated immediately.

[0198] In one feasible implementation, after step S4, if the response result of the target API request is that the data is missing, steps B1 to B3 are further included:

[0199] Step B1: Determine whether there is a target data generation task that matches both the first data identifier and the first time identifier of the target API request;

[0200] In one feasible embodiment, after the root cause localization device receives a response of missing data to the target API request, it searches among all its known data generation tasks to determine if there exists a task whose second data identifier value is exactly the same as the first data identifier value in the target API request, and whose second time identifier value is also exactly the same as the first time identifier value in the target API request.

[0201] Optionally, the determination operation refers to the root cause localization device performing the operation by querying its internally maintained relationships or by directly comparing the task status list.

[0202] Optionally, the matching requirement stipulates that the second data identifier and the first time identifier of the data generation task must correspond one-to-one with the first data identifier and the first time identifier in the API request.

[0203] Step B2: If there is no target data generation task, then based on the first data identifier, find the data generation task currently processing the data corresponding to the first data identifier in the data generation chain and use it as the associated data generation task.

[0204] In one feasible embodiment, when the root cause localization device determines that there is no target data generation task that matches perfectly, it will filter out the tasks that are processing the same data table as the first data identifier (i.e., the value of the second data identifier is the same as the value of the first data identifier) ​​from all active tasks on the data production supply side based on the first data identifier in the target API request, and select one of them (e.g. the most recently started or the most important task) as the associated data generation task for this analysis.

[0205] Optionally, "no target data generation task" means that, after retrieval, the root cause localization device failed to find any data generation task that simultaneously satisfies both the data identifier and the time identifier.

[0206] Optionally, searching for the data generation task currently processing the data corresponding to the first data identifier means that the root cause localization device filters out data where the second data identifier is equal to the first data identifier. For example, during the search, the execution status of the data generation task can also be specified as "running" or "waiting".

[0207] Optionally, the associated data generation task refers to an instance of a task that is being executed and is related to the data table entity being queried, which can be used as the associated object for subsequent root cause analysis.

[0208] Step B3 establishes a new association between the associated data generation task and the target API request, and determines the root cause of data loss based on the new association.

[0209] In one feasible embodiment, after finding the associated data generation task, the root cause locator creates a new association record, linking the target API request to the associated data generation task. Subsequently, based on this newly established association (i.e., the data table entities are the same but the billing periods may be different), and combined with the status and billing period information of the associated data generation task, the root cause locator infers and determines the possible root causes that lead to the missing data in the target API request.

[0210] Optionally, establishing a new association means that the root cause localization device adds a mapping relationship based on data entity association, in addition to the original association logic based on precise matching (data identifier and time identifier), and uses this mapping relationship for subsequent analysis.

[0211] Optionally, determining the root cause of missing data based on new relationships refers to the root cause localization device analyzing the progress of the associated data generation task, the relationship between its target billing period and the API request billing period, etc. For example, it may infer that "the data for the API request billing period has not yet started calculation, but the calculation task for this data table has been delayed," thereby characterizing the root cause as "overall delay in data production tasks" or "production plan for a specific billing period has not been started."

[0212] In this embodiment, by introducing a model that predicts completion time based on task characteristics and combining it with preset business timeliness thresholds to classify delays into levels, a quantitative assessment and differentiated processing of the severity of data missing issues is achieved. The method in this embodiment can provide data users with a clear expectation of data readiness time, reducing decision-making delays caused by unknown waiting times. Based on different delay levels, corresponding follow-up actions are automatically executed; this tiered response strategy makes it more effective for issues with severe impact. Simultaneously, by establishing new relationships based on data table entities when there is no precisely matching task, the coverage of root cause analysis is expanded, improving the method's adaptability in complex or non-standard task scheduling scenarios. Therefore, the method described in this embodiment, in addition to achieving root cause localization, further provides the ability to quantitatively assess and stratify the impact of problems.

[0213] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. In addition, the root causes of data missing include defects in the input data on which the target data generation task depends, and the method further includes steps E1 to E3:

[0214] Step E1: If the execution status of the target data generation task is completed, then obtain the upstream dependent tasks of the target data generation task.

[0215] In one feasible embodiment, when the root cause locator finds that the execution status of the target data generation task associated with the target API request is completed, but the target API request still returns a result with missing data, the root cause locator obtains all upstream dependent tasks on which the target data generation task depends.

[0216] Optionally, the execution status of the target data generation task being "completed" means that the task has finished running.

[0217] Optionally, obtaining the upstream dependent tasks of the target data generation task refers to the root cause localization device querying the task dependency graph in the task scheduling platform, or parsing the configuration metadata of the target data generation task, thereby identifying all previously executed tasks that provide the necessary source data, intermediate results, or triggering conditions for it.

[0218] Step E2: Obtain the final execution status and output data verification results of the upstream dependent tasks;

[0219] In one feasible embodiment, after determining the list of upstream dependent tasks, the root cause localization device further obtains the final execution status of each upstream dependent task and the verification result of its output data from logs, task history records, or data quality monitoring modules.

[0220] Optionally, the final execution status of the upstream dependent task refers to the status identifier after the task's last run, such as "success", "failure" or "cancelled".

[0221] Optionally, the output data verification result refers to the result obtained after checking the output dataset generated by the upstream dependent task through preset data quality rules (such as integrity, accuracy, consistency verification, etc.), including "pass" or "fail".

[0222] Step E3: If the final execution status of at least one upstream dependent task is failure, or the output data verification result is not passed, then the root cause of the missing data is determined to be a defect in the input data on which the target data generation task depends.

[0223] In one feasible embodiment, the root cause localization device analyzes the information of all upstream dependent tasks collected. If it finds that at least one upstream dependent task has a failed final execution status or its output data verification result is not passed, it can be determined that although the target data generation task has completed its own process, it cannot produce a valid final result because the input data it depends on has missing or quality problems at the source. Therefore, it is determined that the root cause of the API data missing is that the input data on which the target data generation task depends is defective.

[0224] Optionally, at least one indicates that if any one of the upstream dependent tasks has a problem, the input data will be defective.

[0225] Optionally, the defective input data upon which the target data generation task depends is a specific root cause category, indicating that the data missing is due to a failure in a higher stage of the data production pipeline or a data quality issue, and that valid data cannot be provided even if the current task has been completed.

[0226] In this embodiment, by extending root cause analysis to upstream dependent tasks of completed data generation tasks and the quality of their output data, the method identifies data loss scenarios caused by problems at the source of the data supply chain. Specifically, when an associated data generation task is completed but data is still missing, the method automatically traces its upstream dependent links, checking the final execution status of all upstream tasks and the verification results of their output data one by one. If an upstream task fails to execute or its output data fails quality verification, the root cause can be determined to be a defect in the input data. This process enables the coverage of hidden problems that are difficult to detect in traditional methods that only focus on the current task status, such as abnormal upstream data sources or intermediate data quality issues. Therefore, the method described in this embodiment expands the coverage depth of root cause analysis, enabling the location of faults caused by earlier stages in the data production pipeline and providing a more comprehensive fault tracing capability.

[0227] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the root cause localization method for missing API interface data based on dual-link observables in this application. Any simple variations based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0228] This application also provides a root cause localization device, please refer to... Figure 4 The root cause localization device includes:

[0229] The first acquisition module 10 is used to acquire the API request from the API request query terminal query link and the query request information of the API request, wherein the query request information includes the first data identifier and the first time identifier of the data to be queried;

[0230] The second acquisition module 20 is used to acquire data generation status information from the data generation link of the data production supply side, wherein the data generation status information includes a second data identifier and a second time identifier corresponding to the data generation task.

[0231] The module 30 is configured to establish an association between the API request and the data generation task based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier.

[0232] The determination module 40 is used to determine the root cause of data loss based on the association, the target API request, and the target data generation task if the response result of the target API request is data loss.

[0233] The root cause localization device provided in this application employs the API interface data missing root cause localization method based on dual-link observability in the above embodiments, which can solve the technical problem of low efficiency in existing data missing root cause localization. Compared with the prior art, the beneficial effects of the root cause localization device provided in this application are the same as those of the API interface data missing root cause localization method based on dual-link observability provided in the above embodiments, and other technical features in the root cause localization device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0234] This application provides a root cause localization device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the root cause localization method based on dual-link observable API interface data missing in the first embodiment described above.

[0235] The following is for reference. Figure 5The diagram illustrates a structural schematic suitable for implementing the root cause localization device in the embodiments of this application. The root cause localization device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The root cause localization device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0236] like Figure 5 As shown, the root cause localization device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the root cause localization device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the root cause localization device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show root cause localization devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0237] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0238] The root cause localization device provided in this application employs the dual-link observable API interface data missing root cause localization method described in the above embodiments, which can solve the technical problem of low efficiency in existing data missing root cause localization. Compared with the prior art, the beneficial effects of the root cause localization device provided in this application are the same as those of the dual-link observable API interface data missing root cause localization method provided in the above embodiments, and other technical features of this root cause localization device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0239] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0240] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0241] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the dual-link observable API interface data missing root cause localization method in the above embodiments.

[0242] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0243] The aforementioned computer-readable storage medium may be included in the root cause localization device; or it may exist independently and not assembled into the root cause localization device.

[0244] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0245] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0246] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0247] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for locating the root cause of missing data in API interfaces based on dual-link observability. This method can solve the technical problem of low efficiency in existing data missing root cause localization techniques. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the method for locating the root cause of missing data in API interfaces based on dual-link observability provided in the above embodiments, and will not be repeated here.

[0248] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for locating the root cause of missing API interface data based on dual-link observables.

[0249] The computer program product provided in this application can solve the technical problem of low efficiency in locating the root cause of missing data in existing technologies. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data missing root cause location method based on dual-link observable API interface provided in the above embodiments, and will not be repeated here.

[0250] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for locating the root cause of missing API interface data based on dual-link observability, characterized in that, The method includes: Obtain the API request from the API request query terminal query link and the query request information of the API request, wherein the query request information includes a first data identifier and a first time identifier of the data to be queried, the first data identifier is used to identify the data entity of the data to be queried, and the first time identifier is used to indicate the time or version of the data to be queried; Obtain data generation status information from the data generation link of the data production supply side, wherein the data generation status information includes a second data identifier and a second time identifier corresponding to the data generation task, the second data identifier is used to identify the data entity processed and produced by the data generation task, and the second time identifier is used to identify the time or version corresponding to the data entity processed and produced by the data generation task; Based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier, an association relationship is established between the API request and the data generation task; wherein, the step of establishing the association relationship between the API request and the data generation task based on the first data identifier and the first time identifier, and the second data identifier and the second time identifier, includes: The first data identifier and the first time identifier are combined to obtain a query association key that represents the API request; the second data identifier and the second time identifier are combined to obtain a task association key that represents the data generation task; if the query association key and the value corresponding to the task association key match successfully, an association relationship is established between the API request corresponding to the query association key and the data generation task corresponding to the task association key, wherein the association relationship spans the query link and the data generation link; If the response to the target API request is that data is missing, then the root cause of the data missing is determined based on the association, the target API request, and the target data generation task; wherein, the data generation status information also includes the execution status of the data generation task, and the step of determining the root cause of the data missing based on the association, the target API request, and the target data generation task includes: Based on the association, the target data generation task associated with the target API request is located, wherein the target data generation task is a data generation task uniquely associated with the target API request; based on the second data identifier corresponding to the target data generation task, the billing status information of the data table associated with the second data identifier is determined; the first time identifier in the API request is compared with the billing status information, and based on the comparison result and the execution status of the target data generation task, the root cause of data loss is determined.

2. The method as described in claim 1, characterized in that, The billing period status information includes that the billing period is being calculated. The step of determining the root cause of data missing based on the comparison results and the execution status of the target data generation task includes: If the query time point corresponding to the first time identifier is equal to the time point represented by the billing period being calculated, and the execution status of the target data generation task is running, then the root cause of the data missing is determined to be that the data is not ready.

3. The method as described in claim 1, characterized in that, The payment period status information includes the latest available payment period. The step of determining the root cause of data loss based on the comparison results and the execution status of the target data generation task further includes: If the query time point corresponding to the first time identifier is after the time point represented by the latest available billing period, then the root cause of the missing data is determined to be a data return anomaly.

4. The method as described in claim 1, characterized in that, The step of determining the root cause of data loss based on the association, the target API request, and the target data generation task further includes: Obtain the billing period status information of the data table associated with the first data identifier, wherein the billing period status information includes the latest available billing period of the data table; If the first time identifier is before the time point represented by the latest available billing period, and the target data generation task associated with the API request cannot be located based on the association, then the root cause of the data missing is determined to be an advanced query.

5. The method as described in claim 1, characterized in that, Following the step of determining if the response to the target API request is missing data, the method further includes: Based on the aforementioned relationship, the target data generation task associated with the API request is located; Obtain the task characteristics of the target data generation task; The task features are input into a pre-trained time prediction model to obtain the estimated completion time of the target data generation task; Based on the estimated completion time and the preset business timeliness threshold, the delay level of the root cause of data loss is determined.

6. The method as described in claim 5, characterized in that, The delay levels include a first level, a second level, a third level, and a fourth level. Following the step of determining the delay level of the root cause of data loss based on the estimated completion time and a preset business timeliness threshold, the following is included: If the delay level is Level 1, then the estimated completion time is appended to the root cause of the missing data. If the delay level is the second level, then analyze the task execution resources and generate resource adjustment suggestions, and use the resource adjustment suggestions as additional root cause information for the data missing root cause; If the delay level is level three, then trace the upstream dependent tasks of the target data generation task. If the upstream dependent task fails or is delayed, then update the root cause of the data missing to the anomaly of the preceding task. If the delay level is level four, the root cause of the missing data will be updated to an abnormal task execution environment and an alarm will be triggered.

7. The method as described in claim 1, characterized in that, Following the step of determining if the response to the target API request is missing data, the method further includes: Determine whether there exists a target data generation task that matches both the first data identifier and the first time identifier of the target API request; If the target data generation task does not exist, then based on the first data identifier, the data generation task currently processing the data corresponding to the first data identifier is found in the data generation chain and used as the associated data generation task; Establish a new association between the associated data generation task and the target API request, and determine the root cause of data loss based on the new association.

8. The method as described in claim 1, characterized in that, The root causes of data loss include defects in the input data upon which the target data generation task depends, and the method further includes: If the execution status of the target data generation task is completed, then obtain the upstream dependent tasks of the target data generation task; Obtain the final execution status and output data verification results of the upstream dependent tasks; If the final execution status of at least one upstream dependent task is failure, or the output data verification result is not passed, then the root cause of the missing data is determined to be a defect in the input data on which the target data generation task depends.

Images