Determination method and device of testability index, storage medium and electronic device

Abstract

The invention discloses an observability index determination method and device, a storage medium and an electronic device, and relates to the technical field of smart home, a scene link identifier sent by a server is used to execute a first query in a target scene link database to obtain a first result, the target scene link database at least comprises a plurality of groups of corresponding relations between established business scene links and business service interfaces; executing a second query in a target monitoring database according to the first result to obtain a second result; and determining an observability index of the business service scene based on the second result. The problems of incomplete system stability observation and low problem positioning efficiency in a complex service scene are solved.

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and more specifically, to a method, device, storage medium and electronic device for determining an observability indicator. Background Art

[0002] With the increasing complexity of business scenarios, especially the widespread application of cloud computing, big data and artificial intelligence technologies, modern information systems are increasingly adopting microservice architecture and containerization technology to achieve rapid deployment, high availability and scalability. In this architecture, the system consists of multiple decentralized and collaborative microservices, each of which is responsible for a specific business function and interacts through API interfaces. Although this architecture improves the maintainability and flexibility of the system, it also brings new challenges, especially in terms of system stability and performance observation. Traditional system monitoring mainly focuses on the status of a single component or interface, such as CPU usage, memory usage, I / O operations, etc., which is not enough in the microservice architecture. Because business requests may go through multiple levels of service calls in the system, the monitoring data of a single component cannot fully reflect the stability of the entire business process. For example, a user login request may involve the interaction of multiple microservices such as user authentication service, database query service, cache service, etc. Performance problems or failures in any microservice may affect the final user experience.

[0003] In view of the problems in related technologies of incomplete observation of system stability and inefficient problem location in complex business scenarios, no effective solution has yet been proposed. Summary of the invention

[0004] The embodiments of the present application provide a method, device, storage medium and electronic device for determining an observability indicator, so as to at least solve the problems in the related art of incomplete observation of system stability and inefficient problem location in complex business scenarios.

[0005] According to an embodiment of the embodiments of the present application, a method for determining an observability indicator is provided, including: using a scenario link identifier sent by a server to execute a first query in a target scenario link database to obtain a first result, wherein the target scenario link database includes at least: a correspondence between multiple groups of established business scenario links and business service interfaces; executing a second query in a target monitoring database according to the first result to obtain a second result; determining the observability indicator of the business service scenario based on the second result, wherein the observability indicator is used to indicate the target value of each business service interface operating parameter.

[0006] In an exemplary embodiment, before executing the first query in the scene link database using the scene link identifier sent by the server, the above method also includes: receiving a link creation request issued by the target object, and parsing the business scenario information in the link creation request, wherein the business scenario information includes at least: scene name, scene description, and expected business process path; creating a business scenario link based on the business scenario information, and establishing a corresponding relationship between the business scenario link and the business service interface, synchronizing the business scenario link and the corresponding relationship to the database for storage, and obtaining a target scene link database.

[0007] In an exemplary embodiment, the business scenario link and the corresponding relationship are synchronized to the database for storage. After the target scenario link database is obtained, the above method also includes: testing and verifying the corresponding relationship between the business scenario link and the business service interface to obtain the test result; comparing the test result with the expected result, and determining whether the corresponding relationship between the business scenario link and the business service interface is correct based on the comparison result.

[0008] In an exemplary embodiment, whether the correspondence between the business scenario link and the business service interface is correct is determined based on the comparison result, including: when the comparison result indicates that the correspondence is correct, allowing the business scenario link to participate in the data call of the target scenario link database; when the comparison result indicates that the correspondence is incorrect, analyzing and processing the link nodes on the business scenario link.

[0009] In an exemplary embodiment, a second query is executed in a target monitoring database according to the first result, and before obtaining the second result, the method further includes: configuring a first log component in a business service to obtain a second log component; using the second log component to collect monitoring data to obtain first monitoring data, wherein the monitoring data is data generated in the process of calling a business service interface; preprocessing the first monitoring data to obtain second monitoring data, wherein the preprocessing includes at least one of the following: data conversion, data cleaning, and removal of redundant information; synchronously storing the second monitoring data in a preset monitoring database to generate a target monitoring database, wherein the target monitoring database includes at least: interface service, interface uniform resource locator, interface call time, and interface response time.

[0010] In an exemplary embodiment, a second query is executed in the target monitoring database according to the first result to obtain a second result, including: when an interface list has been obtained, receiving a query statement constructed by the server based on the interface list, wherein the interface list includes at least: an interface identifier, an interface uniform resource locator; querying the target monitoring database based on the query statement to obtain a second result including the target monitoring data corresponding to each interface in the interface list.

[0011] In an exemplary embodiment, determining the observability index of the business service scenario based on the second result includes: grouping the second result according to different dimensions to obtain a first processing result; aggregating the first processing result to obtain a second processing result; and displaying the second processing result on a visualization interface.

[0012] According to another aspect of an embodiment of the present application, a device for determining an observability indicator is also provided, including: a first query module, used to use the scenario link identifier sent by the server to execute a first query in a target scenario link database to obtain a first result, wherein the target scenario link database at least includes: a correspondence between multiple groups of established business scenario links and business service interfaces; a second query module, used to execute a second query in a target monitoring database according to the first result to obtain a second result; a determination module, used to determine the observability indicator of the business service scenario based on the second result, wherein the observability indicator is used to indicate the target value of each business service interface operating parameter.

[0013] According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for determining the observability indicator at runtime.

[0014] According to another aspect of an embodiment of the present application, there is also provided an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the method for determining the observability indicator through the computer program.

[0015] In an embodiment of the present application, a first query is performed in a target scenario link database using a scenario link identifier sent by the server to obtain a first result, wherein the target scenario link database includes at least: a correspondence between multiple groups of established business scenario links and business service interfaces; a second query is performed in a target monitoring database according to the first result to obtain a second result; based on the second result, the observability index of the business service scenario is determined, wherein the observability index is used to indicate the target value of each business service interface operating parameter. The above technical solution is adopted to solve the problems of incomplete observation of system stability and inefficient problem location in complex business scenarios. Furthermore, the scenario link database and the monitoring database are queried by the server to obtain and analyze the response time, number of successes, number of exceptions and success rate of the business service interface to determine the observability index of the entire business scenario and realize comprehensive monitoring and evaluation of the stability of the business service. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 It is a hardware environment diagram of a method for determining an observability indicator according to an embodiment of the present application;

[0019] Figure 2 is a flowchart of a method for determining an observability indicator according to an embodiment of the present application;

[0020] Figure 3 is a schematic diagram of a stability observable system structure based on a business scenario according to an embodiment of the present application;

[0021] Figure 4 It is a flowchart of a stability observable method based on a business scenario according to an embodiment of the present application;

[0022] Figure 5 It is a structural block diagram of a device for determining an observability indicator according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] According to one aspect of an embodiment of the present application, a method for determining an observability index is provided. The method for determining the observability index is widely used in smart factories, smart homes, smart homes, smart home device ecosystems, smart residential (Intelligence House) ecosystems and other whole-house intelligent digital control application scenarios. Optionally, in this embodiment, the above-mentioned method for determining the observability index can be applied to Figure 1 In the hardware environment composed of the terminal device 102 and the server 104 shown in FIG. Figure 1 As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0026] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal device 102 may be but is not limited to a smart factory handheld device, PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projection equipment, smart TV, smart clothes drying rack, smart curtain, smart audio and video, smart socket, smart audio, smart speaker, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart sweeping robot, smart window cleaning robot, smart mopping robot, smart air purification equipment, smart steamer, smart microwave oven, smart kitchen treasure, smart purifier, smart water dispenser, smart door lock, etc.

[0027] In this embodiment, a method for determining an observability indicator is provided, which is applied to the above terminal device. Figure 2 : is a flowchart of a method for determining an observability indicator according to an embodiment of the present application, and the process includes the following steps:

[0028] Step S202, using the scene link identifier sent by the server to perform a first query in a target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence between multiple groups of established business scene links and business service interfaces;

[0029] Optionally, when the server receives a specific scene link identifier, it performs a first query operation in the target scene link database in order to collect a list of all interfaces related to the scene link identifier, i.e., a first result.

[0030] Step S204, executing a second query in the target monitoring database according to the first result to obtain a second result;

[0031] Optionally, the second result includes monitoring data related to each interface in the interface list, which generally include but are not limited to performance indicators such as the number of interface calls, average response time, success rate, and statistics of abnormal situations.

[0032] Step S206: determine the observability index of the business service scenario based on the second result, wherein the observability index is used to indicate a target value of an operating parameter of each business service interface.

[0033] Optionally, the above-mentioned operating parameters can be the response time of each business service interface, the number of successful responses of each business service interface, the number of abnormal responses of each business service interface, or the success rate of each business service interface. That is, through the above-mentioned method, the target values ​​corresponding to the operating parameters of different business service interfaces and the operating parameters of the business service interfaces are used as observability indicators, so that the operation process of the business service scenario in the actual scenario can be clearly recorded, thereby improving the accuracy of subsequent evaluation of business services.

[0034] Through the above steps, the scenario link identifier sent by the server is used to perform a first query in the target scenario link database to obtain a first result, wherein the target scenario link database includes at least: a correspondence between multiple groups of established business scenario links and business service interfaces; a second query is performed in the target monitoring database according to the first result to obtain a second result; based on the second result, the observability index of the business service scenario is determined, wherein the observability index is used to indicate the target value of each business service interface operating parameter. The above technical solution is adopted to solve the problems of incomplete observation of system stability and inefficient problem location in complex business scenarios. Furthermore, the scenario link database and the monitoring database are queried by the server to obtain and analyze the response time, number of successes, number of exceptions and success rate of the business service interface to determine the observability index of the entire business scenario and realize comprehensive monitoring and evaluation of the stability of business services.

[0035] Optionally, in a business scenario of an e-commerce website, there is a "user placing an order" process, which involves multiple microservice interfaces, such as a product query interface, an inventory check interface, a payment interface, and an order generation interface. When the system has a stability problem, the operation and maintenance personnel can select the "user placing an order" scenario link identifier from the stability observation service and send it to the server. After receiving the identifier, the server queries the first result corresponding to all microservice interfaces related to the "user placing an order" scenario in the target scenario link database. After obtaining the first result, the server continues to perform a second query in the target monitoring database to obtain monitoring data such as the response time, number of successes, number of exceptions, and success rate of these interfaces. By analyzing these data, the operation and maintenance personnel can clearly see that during the order generation process, the response time of the product query and payment interfaces is long, the number of exceptions of the payment interface is high, and the success rate is lower than expected, so as to quickly locate the problem in the payment link, which may be caused by the processing capacity of the payment interface or the instability of the third-party payment service, and then take corresponding measures to optimize or troubleshoot.

[0036] In an exemplary embodiment, before executing the first query in the scene link database using the scene link identifier sent by the server, the above method also includes: receiving a link creation request issued by the target object, and parsing the business scenario information in the link creation request, wherein the business scenario information includes at least: scene name, scene description, and expected business process path; creating a business scenario link based on the business scenario information, and establishing a corresponding relationship between the business scenario link and the business service interface, synchronizing the business scenario link and the corresponding relationship to the database for storage, and obtaining a target scene link database.

[0037] Optionally, in an e-commerce system, developers want to establish a business scenario link of "purchase process" to observe the whole process from product browsing to order generation. First, developers submit a link creation request through the stability observation service interface. The request includes: scenario name: "Purchase process stability observation", scenario description: "Monitor the whole process from user browsing products to completing payment to ensure the stability and efficiency of the purchase process", and expected business process path: product browsing interface → shopping cart adding interface → order generation interface → payment interface. After receiving the request, the stability observation service parses and creates the "Purchase process stability observation" scenario link, and establishes the corresponding relationship between the scenario and the product browsing interface, shopping cart adding interface, order generation interface and payment interface. This information is then stored in the target scenario link database. In this way, once an exception occurs in the "purchase process", such as the payment interface response time is too long or there is a fault that causes the order generation to fail, the operation and maintenance personnel can quickly query the target scenario link database, find all interfaces related to the "Purchase process stability observation" scenario, and view their status and performance indicators, such as response time, number of successes, number of exceptions and success rate, so as to quickly locate the problem link and perform targeted optimization or repair. Through this process, developers and operation and maintenance personnel can manage the stability of business scenarios in a more systematic and targeted manner, improve user experience, and ensure business continuity.

[0038] In an exemplary embodiment, the business scenario link and the corresponding relationship are synchronized to the database for storage. After the target scenario link database is obtained, the above method also includes: testing and verifying the corresponding relationship between the business scenario link and the business service interface to obtain the test result; comparing the test result with the expected result, and determining whether the corresponding relationship between the business scenario link and the business service interface is correct based on the comparison result.

[0039] In an exemplary embodiment, whether the correspondence between the business scenario link and the business service interface is correct is determined based on the comparison result, including: when the comparison result indicates that the correspondence is correct, allowing the business scenario link to participate in the data call of the target scenario link database; when the comparison result indicates that the correspondence is incorrect, analyzing and processing the link nodes on the business scenario link.

[0040] Optionally, in a bank online transfer system, it is necessary to verify the correspondence between the "inter-bank transfer" business scenario link and the business service interface. The business process is expected to include: user identity authentication interface → account query interface → transfer amount verification interface → inter-bank transfer execution interface → transaction confirmation interface → user notification interface. By simulating user operations, using automated testing tools or manual simulation, the "inter-bank transfer" process is fully executed from user login to receiving the transfer completion notification. During the simulation operation, the monitoring system will collect the execution status of each business service interface, including whether it is called, the calling order, the response time, the execution result, etc. The collected test data is compared in detail with the expected business process to check whether each interface is correctly called in the expected order, whether the response time meets the performance requirements, and whether there are abnormal execution situations. If the test results are inconsistent with expectations, such as finding that the "transfer amount verification interface" is called before the "account query interface", or the "transaction confirmation interface" has a high execution failure rate, this indicates that there may be errors in the business scenario link configuration or interface logic. At this point, developers will adjust the business scenario link based on the test results, correct the interface logic or optimize performance, and then test and verify again until the calling order and execution of all interfaces match the expected results. Through this verification process, the bank's online transfer system can ensure the accuracy and reliability of the "inter-bank transfer" business scenario link. In actual user operations, if problems are encountered, such as transfer delays or transaction failures, operation and maintenance personnel can quickly locate the specific links based on accurate business scenario link configuration, so as to take effective measures to optimize user experience and ensure business continuity.

[0041] In an exemplary embodiment, a second query is executed in a target monitoring database according to the first result, and before obtaining the second result, the method further includes: configuring a first log component in a business service to obtain a second log component; using the second log component to collect monitoring data to obtain first monitoring data, wherein the monitoring data is data generated in the process of calling a business service interface; preprocessing the first monitoring data to obtain second monitoring data, wherein the preprocessing includes at least one of the following: data conversion, data cleaning, and removal of redundant information; synchronously storing the second monitoring data in a preset monitoring database to generate a target monitoring database, wherein the target monitoring database includes at least: interface service, interface uniform resource locator, interface call time, and interface response time.

[0042] Optionally, in an e-commerce website, in order to monitor the stability of the "goods ordering" business scenario, the developer configures a second log component in the business service layer. When the user performs a product ordering operation, the second log component automatically records and collects information such as the call time and response time of the relevant interface to generate the first monitoring data. In order to improve the quality and efficiency of the data, the system preprocesses the collected first monitoring data, including data cleaning (removing invalid or erroneous data records), data conversion (converting timestamps to readable format time) and removing redundant information (such as deleting unnecessary log level information). The preprocessed second monitoring data is synchronized in real time to the preset monitoring database, which stores standardized monitoring data, including key fields such as interface service name, interface uniform resource locator (URL), interface call time, interface response time, etc., forming a target monitoring database. Through this process, the e-commerce website can monitor the stability of the product ordering business scenario in real time. Once a performance bottleneck or abnormal situation is found, such as a long response time of the payment interface, the operation and maintenance or developers can quickly obtain relevant data from the target monitoring database, analyze and locate the problem, and take timely measures to optimize system performance and improve user experience. In addition, the standardized monitoring database also provides efficient data support for system operation and maintenance management and troubleshooting, reflecting the importance and value of configuration and preprocessing steps.

[0043] In an exemplary embodiment, a second query is executed in the target monitoring database according to the first result to obtain a second result, including: when an interface list has been obtained, receiving a query statement constructed by the server based on the interface list, wherein the interface list includes at least: an interface identifier, an interface uniform resource locator; querying the target monitoring database based on the query statement to obtain a second result including the target monitoring data corresponding to each interface in the interface list.

[0044] Optionally, a business scenario of "shopping cart settlement" on an e-commerce platform involves multiple key interfaces, including UserAuthentication, CartItems Query, Stock Check, Payment Processing, Order Confirmation, etc. Each interface has its unique interface identifier and uniform resource locator (URL), for example, the URL of UserAuthentication is / api / v1 / auth / login, and the URL of Payment Processing is / api / v1 / payment / process. Based on the above interface list, the server constructs an SQL query statement, such as: "SELECT * FROM monitor_logs WHERE interface_id IN('UserAuthentication','CartItemsQuery','StockCheck','PaymentProcessing','OrderConfirmation') AND timestamp BETWEEN'2023-06-01 00:00:00' AND'2023-06-01 23:59:59';". This ensures that the monitoring data of all key interfaces within a specific date is retrieved. The second query module receives the above query statement, executes a query on the monitoring database, and obtains the monitoring data corresponding to each interface call, including the number of calls, average response time, call success rate, error log, etc. These data constitute the second result.

[0045] In an exemplary embodiment, determining the observability index of the business service scenario based on the second result includes: grouping the second result according to different dimensions to obtain a first processing result; aggregating the first processing result to obtain a second processing result; and displaying the second processing result on a visualization interface.

[0046] Optionally, in the above embodiment, the second result is grouped and processed according to different dimensions, and the monitoring data of each interface call is grouped using a data query and analysis tool (such as Elasticsearch's DSL or SQL) to obtain the first processing result. Among them, the grouping dimensions include but are not limited to: interface name, service node, time span, user behavior, etc., to meet the analysis needs at different levels. Based on the first processing result, an aggregation operation is performed, such as calculating the average response time, success rate, number of exceptions, etc., to obtain the second processing result. The aggregated data is displayed through a data visualization tool (such as Grafana, Kibana, etc.) or a custom dashboard, and presented in the form of charts, dashboards, etc. For example, use Grafana to create a visualization panel to display the average response time and success rate of the / api / cart and / api / payment interfaces on each working day. Through the chart, you can intuitively see that the performance of a certain interface suddenly drops on a specific date, so that measures can be taken quickly.

[0047] In order to better understand the process of the method for determining the above-mentioned observability indicators, the implementation method flow of determining the above-mentioned observability indicators is described below in combination with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.

[0048] In related technologies, as business systems become more complex, business topologies become more and more complex, involving interactions between multiple microservices, components, and interfaces. The traditional single-point or single-interface observation method can no longer meet the needs. Specifically, the stability observation of a single interface often only focuses on the function and performance of the interface itself, while ignoring the interaction and dependency between the interface and other system components or interfaces; the stability observation of a single interface is often carried out in an isolated environment and cannot fully simulate the real business scenario; in a complex system, there is often a close collaborative relationship between multiple interfaces. The stability observation of a single interface may not be able to discover and solve collaborative problems between interfaces, such as inconsistent data, incorrect interface call order, etc.

[0049] In order to solve the above problems, the optional embodiment of the present application proposes a stability observable method based on business scenarios. Specifically, log components are integrated in different microservices of business services, and monitoring data of interface calls are automatically collected, and the collected monitoring data will be stored in an efficient data storage system. Through the stability observation service, the correspondence between the business scenario link and the specific interface is created and maintained to form a mapping between the scenario and the interface. According to the maintained scenario link, the monitoring data associated with the scenario is aggregated from the data storage system, and these data are used to generate key performance indicators such as response time, number of successes, number of exceptions, success rate, etc., to achieve a quantitative evaluation of the stability of the business scenario. Finally, the generated stability indicators are intuitively displayed through the front-end page, providing operation and maintenance and developers with a real-time and comprehensive view of the health status of the business process, so as to quickly locate problems, optimize system performance, and ensure the continuity and efficient operation of the business. Through automated data collection, intelligent scenario association and efficient data aggregation analysis, full-link and multi-dimensional observation of the stability of complex business systems is achieved, which significantly improves the efficiency of fault detection and resolution.

[0050] Optional, Figure 3 It is a schematic diagram of the structure of a stability observable system based on a business scenario according to an embodiment of the present application. The above system at least includes: a business service 32, a log component 34, and a stability observation service 36.

[0051] Optionally, business service 32. The business service layer consists of multiple microservice components, such as business service 1, business service 2, business service 3, etc. These microservices execute specific business logic and are the core of the system for processing user requests and executing internal business processes. Under the cloud native architecture, business services can be dynamically created, expanded, and migrated to achieve efficient use of resources and rapid response to user needs.

[0052] Optionally, a log component 34. The log component is integrated into the business service and is used to automatically collect monitoring data of the business service in real time. These data include, but are not limited to, key performance indicators such as interface service name, interface URL, interface execution status (such as success or failure), and interface response time. By setting an interceptor at the interface layer of the business service, the log component can automatically record and track the detailed execution process of each business request, providing detailed data records for subsequent data analysis and fault location. The collected monitoring data will be sent to the ES data source for storage.

[0053] Optional, ES data source, that is, Elasticsearch data source, is a high-performance database for storing monitoring data. It can efficiently process and store a large amount of real-time monitoring data, providing high availability and fast retrieval capabilities. The ES data source receives monitoring data from the log component and provides a basis for data query and aggregation for the stability observation service. This data can be stored for a long time, facilitating the analysis of historical data and future optimization decisions.

[0054] Optional, stability observation service 36. The stability observation service is responsible for building the correspondence between business scenario links and interfaces, and realizing multi-dimensional monitoring of system stability under business scenarios. Operation and maintenance and developers can create specific business scenarios through the stability observation service, such as user login processes, and then maintain the correspondence between all interfaces involved in the scenario. Based on this information, the stability observation service can query and aggregate relevant monitoring data from the ES data source, generate performance indicators such as response time, number of successes, number of exceptions, and success rate, and visualize them through the front-end page. This business scenario-based observation method not only focuses on the performance of a single interface, but also focuses on the stability and user experience of the entire business process, providing operation and maintenance and development teams with effective tools to quickly locate problems and optimize system performance.

[0055] Optional, Figure 4 It is a flowchart of a stability observable method based on a business scenario according to an embodiment of the present application; the specific steps are as follows:

[0056] Step 1: Introduce the log component. Developers introduce the log component into the business service, which can automatically capture and record the execution details of the business interface, and realize the ability to automatically collect monitoring data for the business service interface in real time, including the interface name, URL, execution status (successful or not), response time and other key monitoring information. This step is the basis for collecting operation data in business scenarios, ensuring that detailed interface execution status can be obtained later.

[0057] Step 2: Monitoring data collection. When the user interacts with the system and operates a specific function, the business service begins to execute and triggers the corresponding interface. At this stage, the log component automatically intercepts and collects the execution monitoring data of the interface in real time, such as interface service, interface URL, whether the interface execution is successful, interface response time and other basic indicator data. This data is then stored in the ES data source, and one piece of monitoring data is stored each time it is executed to ensure the real-time and integrity of the data.

[0058] Step 3: Visualization of stability observation. The operation and maintenance or developer defines the business scenario link in the stability observation service, such as "user login process", and maintains a list of interfaces related to the scenario. For example, the user login scenario is associated with the interfaces: / admin / login and / admin / userDetail interfaces, and the basic data of the scenario and interface are also stored in the ES data source. In the ES data source, the monitoring data of these interfaces are marked and indexed, so that in this step, the stability observation service can query the relevant interface monitoring data according to the scenario ID, and perform aggregate analysis to calculate performance indicators such as average response time, request success rate, and number of exceptions. The stability observation service displays the performance indicators after aggregate analysis in a visual way on the front-end page, including but not limited to charts, dashboards, etc., so as to be intuitively presented to the operation and maintenance or developer.

[0059] It should be noted that when integrating log components in different microservices, it is necessary to ensure that the log components are compatible with the technology stack of each microservice to avoid incomplete data collection or performance impact due to technical differences. Ensure that the collected data contains all key indicators, such as response time, call status, error type, and user information, so as to comprehensively evaluate the stability of the business scenario. Accurately define the business scenario links to ensure that all key business processes are covered and avoid monitoring blind spots. During the implementation of the entire solution, continue to pay attention to data security and compliance issues to ensure that all processed, stored, and displayed monitoring data comply with legal and regulatory requirements, especially those regarding data protection and privacy.

[0060] In summary, this application introduces a log component to prepare for monitoring data collection; when the user operates a function, the interface execution of the business service will be triggered, and the log component will automatically collect monitoring data for the interface and store the monitoring data in the ES data source; developers or operation and maintenance colleagues can create new scenarios in the stability observation service, maintain the corresponding relationship between the scenario and the interface, and with the corresponding relationship between the scenario and the interface, the monitoring data of the ES data source can be aggregated and counted, and the statistical stability indicators can be returned to the front-end page to realize the visualization of stability indicators based on business scenarios. Specifically, by defining the business scenario link, not only the performance of a single interface is paid attention to, but also the overall business process is monitored, covering the interaction between multiple microservices, components and interfaces, so that the stability of the system can be evaluated more comprehensively. The log component is used to realize the collection of real-time monitoring data, and the data is efficiently stored in data sources such as Elasticsearch to ensure the timeliness and availability of the data. By aggregating monitoring data related to business scenarios, a variety of performance indicators are generated, such as response time, success rate, number of exceptions, etc., to provide a quantitative basis for stability evaluation. The calculated performance indicators are intuitively displayed on the front-end page, which is convenient for developers and operation and maintenance personnel to quickly understand the system status and locate and solve problems in a timely manner. Through real-time, comprehensive monitoring data collection and efficient storage, the accuracy and response speed of system stability monitoring are significantly enhanced, and the fault detection and resolution time is effectively shortened.

[0061] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0062] Figure 5 is a structural block diagram of a device for determining an observability indicator according to an embodiment of the present application; Figure 5 As shown, including:

[0063] A first query module 52 is used to perform a first query in a target scenario link database using the scenario link identifier sent by the server to obtain a first result, wherein the target scenario link database at least includes: a correspondence relationship between multiple groups of established business scenario links and business service interfaces;

[0064] A second query module 54, configured to execute a second query in the target monitoring database according to the first result to obtain a second result;

[0065] The determination module 56 is used to determine the observability index of the business service scenario based on the second result, wherein the observability index is used to indicate the target value of each business service interface operation parameter.

[0066] Through the above-mentioned device, the scene link identifier sent by the server is used to perform a first query in the target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence between multiple groups of established business scene links and business service interfaces; a second query is performed in the target monitoring database according to the first result to obtain a second result; based on the second result, the observability index of the business service scene is determined, wherein the observability index is used to indicate the target value of each business service interface operating parameter. The above-mentioned technical solution is adopted to solve the problem of incomplete observation of system stability and inefficient problem location in complex business scenarios. Furthermore, the scene link database and the monitoring database are queried by the server to obtain and analyze the response time, number of successes, number of exceptions and success rate of the business service interface to determine the observability index of the entire business scene and realize comprehensive monitoring and evaluation of the stability of business services.

[0067] In an exemplary embodiment, the above-mentioned device also includes: a receiving module, which is used to receive a link creation request issued by the target object before executing the first query in the scene link database using the scene link identifier sent by the server, and parse the business scenario information in the link creation request, wherein the business scenario information includes at least: scene name, scene description, and expected business process path; create a business scenario link based on the business scenario information, and establish a corresponding relationship between the business scenario link and the business service interface, synchronize the business scenario link and the corresponding relationship to the database for storage, and obtain a target scene link database.

[0068] In an exemplary embodiment, the above-mentioned receiving module also includes: a verification unit, which is used to synchronize the business scenario link and the corresponding relationship to the database for storage, and after obtaining the target scenario link database, test and verify the correspondence between the business scenario link and the business service interface to obtain the test result; compare the test result with the expected result, and determine whether the correspondence between the business scenario link and the business service interface is correct based on the comparison result.

[0069] In an exemplary embodiment, the above-mentioned verification unit is also used to allow the business scenario link to participate in the data call of the target scenario link database when the comparison result indicates that the corresponding relationship is correct; when the comparison result indicates that the corresponding relationship is incorrect, the link nodes on the business scenario link are analyzed and processed.

[0070] In an exemplary embodiment, the above-mentioned device also includes: a configuration module, which is used to execute a second query in a target monitoring database according to the first result, and before obtaining the second result, configure the first log component in the business service to obtain a second log component; use the second log component to collect monitoring data to obtain first monitoring data, wherein the monitoring data is data generated in the process of calling the business service interface; pre-process the first monitoring data to obtain second monitoring data, wherein the pre-processing includes at least one of the following: data conversion, data cleaning, and removal of redundant information; synchronously store the second monitoring data in a preset monitoring database to generate a target monitoring database, wherein the target monitoring database includes at least: interface service, interface uniform resource locator, interface call time, and interface response time.

[0071] In an exemplary embodiment, the above-mentioned second query module is also used to receive a query statement constructed by the server based on the interface list when the interface list has been obtained, wherein the interface list at least includes: an interface identifier, an interface uniform resource locator; based on the query statement, the target monitoring database is queried to obtain a second result including the target monitoring data corresponding to each interface in the interface list.

[0072] In an exemplary embodiment, the above-mentioned determination module is also used to group the second results according to different dimensions to obtain the first processing results; aggregate the first processing results to obtain the second processing results; and display the second processing results on the visualization interface.

[0073] An embodiment of the present application further provides a storage medium, which includes a stored program, wherein the program executes any of the above methods when it is run.

[0074] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0075] S1, using the scene link identifier sent by the server to perform a first query in a target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence between multiple groups of established business scene links and business service interfaces;

[0076] S2, executing a second query in the target monitoring database according to the first result to obtain a second result;

[0077] S3. Determine an observability indicator of the business service scenario based on the second result, wherein the observability indicator is used to indicate a target value of an operating parameter of each business service interface.

[0078] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0079] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0080] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0081] S1, using the scene link identifier sent by the server to perform a first query in a target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence between multiple groups of established business scene links and business service interfaces;

[0082] S2, executing a second query in the target monitoring database according to the first result to obtain a second result;

[0083] S3. Determine an observability indicator of the business service scenario based on the second result, wherein the observability indicator is used to indicate a target value of an operating parameter of each business service interface.

[0084] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0085] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0086] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0087] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining an observability index, characterized in that: include: Using the scene link identifier sent by the server, a first query is performed in a target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence relationship between multiple groups of established business scene links and business service interfaces; Execute a second query in the target monitoring database according to the first result to obtain a second result; An observability indicator of the business service scenario is determined based on the second result, wherein the observability indicator is used to indicate a target value of an operating parameter of each business service interface.

2. The method for determining observability indicators according to claim 1, characterized in that: Before executing the first query in the scene link database using the scene link identifier sent by the server, the method further includes: receiving a link creation request sent by the target object, and parsing the business scene information in the link creation request, wherein the business scene information includes at least: a scene name, a scene description, and an expected business process path; A business scenario link is created based on the business scenario information, and a corresponding relationship between the business scenario link and the business service interface is established. The business scenario link and the corresponding relationship are synchronized to a database for storage to obtain the target scenario link database.

3. The method for determining observability indicators according to claim 2, characterized in that: After synchronizing the business scenario link and the corresponding relationship into a database for storage and obtaining the target scenario link database, the method further includes: Testing and verifying the correspondence between the business scenario link and the business service interface to obtain a test result; The test result is compared with the expected result, and whether the corresponding relationship between the business scenario link and the business service interface is correct is determined based on the comparison result.

4. The method for determining observability indicators according to claim 3, characterized in that: Determining whether the correspondence between the business scenario link and the business service interface is correct according to the comparison result includes: When the comparison result indicates that the corresponding relationship is correct, allowing the business scenario link to participate in the data call of the target scenario link database; When the comparison result indicates that the corresponding relationship is incorrect, the link nodes on the business scenario link are analyzed and processed.

5. The method for determining observability indicators according to claim 1, characterized in that: Before executing a second query in the target monitoring database according to the first result and obtaining the second result, the method further includes: Configure the first log component in the business service to obtain the second log component; Using the second log component to collect monitoring data to obtain first monitoring data, wherein the monitoring data is data generated during the process of calling the business service interface; Preprocessing the first monitoring data to obtain second monitoring data, wherein the preprocessing includes at least one of the following: data conversion, data cleaning, and removing redundant information; The second monitoring data is synchronously stored in a preset monitoring database to generate the target monitoring database, wherein the target monitoring database at least includes: interface service, interface uniform resource locator, interface call time, and interface response time.

6. The method for determining observability indicators according to claim 1, characterized in that: Execute a second query in the target monitoring database according to the first result to obtain a second result, including: In the case where the interface list has been obtained, receiving a query statement constructed by the server based on the interface list, wherein the interface list at least includes: an interface identifier and an interface uniform resource locator; The target monitoring database is queried based on the query statement to obtain a second result including the target monitoring data corresponding to each interface in the interface list.

7. The method for determining observability indicators according to claim 1, characterized in that: Determining the observability index of the business service scenario based on the second result includes: The second results are grouped according to different dimensions to obtain first processing results; Performing aggregation processing on the first processing result to obtain a second processing result; The second processing result is displayed on a visual interface.

8. A device for determining an observability index, characterized in that: include: A first query module, configured to use the scene link identifier sent by the server to perform a first query in a target scene link database to obtain a first result, wherein the target scene link database at least includes: a correspondence between multiple groups of established business scene links and business service interfaces; A second query module, used to execute a second query in the target monitoring database according to the first result to obtain a second result; A determination module is used to determine the observability index of the business service scenario based on the second result, wherein the observability index.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images