Triggering diagnostic data generation and aggregation across multiple systems to reduce compute resources
By generating and transmitting identifiers corresponding to requests on both the server and client sides, diagnostic data is generated only when a problem occurs and stored in a single storage system, thus solving the problem of scattered storage of diagnostic data and achieving resource savings and simplified data acquisition.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-06-12
- Publication Date
- 2026-03-24
AI Technical Summary
In a client/server architecture, the generation and storage of diagnostic data are scattered across multiple data stores. This forces users to access multiple stores to piece together the diagnostic data, a process that is cumbersome and prone to errors. In addition, unnecessary transmission of diagnostic data consumes bandwidth and computing resources.
The server generates a corresponding identifier for the client request and stores the request and identifier in a cache. Diagnostic data is generated and transmitted to the supporting data storage system only when a problem occurs. The client also generates and transmits its diagnostic data along with the identifier, allowing users to access a single storage system to obtain an aggregated view through the identifier.
It saves computing resources such as processing time, memory utilization, and network bandwidth, simplifies the process of acquiring diagnostic data, and reduces unnecessary data transfer and generation overhead.
Smart Images

Figure CN114286982B_ABST
Abstract
Description
Background Technology
[0001] Computer systems are now widely used. Some computer systems operate in a client / server architecture. In such an architecture, a server in a remote server environment provides services that can be accessed by client computing systems.
[0002] In these types of computing systems, it's not uncommon for services to be executed in problematic ways. For example, errors or other failures may exist within the server logic units that enable the service's performance. In such cases, end users often provide input indicating that a problem has occurred. For instance, an end user can initiate a link that can be used to report the problem to support engineers or other support personnel.
[0003] The above discussion is provided only for general background information and is not intended to help determine the scope of the subject matter for which protection is claimed. Summary of the Invention
[0004] The server implementing the service receives a request from the client computing system and stores the request along with a relevant identifier in a cache. The server returns a response to the request along with the relevant identifier (ID). When a trigger input indicating a problem has been encountered at the client computing system is received, a diagnostic data generation system on the service accesses the cache and generates diagnostic data for the request corresponding to the relevant ID. The diagnostic data corresponding to the relevant ID is then provided to a supporting data storage system, where it can be combined with the diagnostic data from the client computing system.
[0005] This summary is provided to present a simplified description of the selected concepts, which will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that address any or all of the shortcomings mentioned in the background. Attached Figure Description
[0006] Figure 1 This is a block diagram of an example computing system architecture.
[0007] Figure 2 It shows more details in Figure 1 The diagram shows the architecture.
[0008] Figure 3A and Figure 3B (Hereinafter referred to as Figure 3) shows an example of the operation of the architecture illustrated in the previous figures.
[0009] Figure 4 This is a block diagram illustrating an example of an architecture deployed in a cloud computing architecture, as shown in the previous diagram.
[0010] Figure 5 This is a block diagram illustrating an example of a computing environment that can be used in the architecture shown in the previous figure. Detailed Implementation
[0011] As discussed above, it is not uncommon for client computing systems to encounter problems when using services in a client / server architecture. These problems may be caused by errors in the service, logical failures within the service, or other reasons. This can be detected by the end user or an automated system. In such cases, the end user (or an automated component on the client computing system) can provide input indicating that the service's performance is inadequate to some extent. For example, the end user can initiate a link instructing a request to report the problem to a support engineer or other support personnel.
[0012] To resolve reported issues, support personnel often need to access various different data stores that store diagnostic data. For example, a server implementing the service might generate server diagnostic data and store it in one data store. However, a client computing system might generate client diagnostic data and store it in a different data store. Similarly, multiple different services may have performed operations in response to the same request. Each of those services can generate server diagnostic data and store it in yet another data store. Therefore, when support users (e.g., support engineers) want to analyze diagnostic data to resolve issues reported by clients, they often have to access multiple different data stores to try to piece together diagnostic data corresponding to the reported problem. This can be cumbersome, time-consuming, and error-prone.
[0013] To address this issue, some current systems generate diagnostic data each time they respond to a client request. This diagnostic data is sent to the client and embedded in the payload of the client data returned in response to the request. However, this diagnostic data can be very large. Therefore, this unnecessarily consumes bandwidth as the diagnostic data is sent with every request (regardless of whether a problem has occurred), and also incurs computational overhead in generating the diagnostic data, which is never actually used. Furthermore, in current systems where the diagnostic data is not generated by the server, the server has already lost the ability to generate at least some of the diagnostic data when a user reports a problem with a previous request.
[0014] This description is therefore directed to a system in which: a server generates a relevant identifier (ID) corresponding to a request received from a client computing system and stores the request and the relevant ID in a cache. The server then generates a response to the request and returns the response, along with the relevant ID, to the client computing system. If a problem is encountered, the client computing system sends an indication of the problem to the server along with the relevant ID. The server then accesses the cache and identifies the request corresponding to the relevant ID, and generates diagnostic data for that request. The diagnostic data is then sent to a support data storage system, where it can be stored (or indexed by) the relevant ID. Similarly, the client computing system sends its diagnostic data, along with the relevant ID, to the support data storage system. Thus, client diagnostic data is stored together with server diagnostic data and the relevant ID. Therefore, support users (such as support engineers) can use the relevant ID to access a single data storage (e.g., the support data storage system) and obtain an aggregated view of both client and server diagnostic data. This saves computational resources, such as processing time, memory utilization, and / or network bandwidth.
[0015] Figure 1 This is a block diagram illustrating an example of a computing system architecture 100. Architecture 100 shows multiple service computing systems 102-104 accessible via a network 110 by one or more different client computing systems 106-108. Each service computing system 102-104 can implement different services that can be used by the different computing systems 106-108. Therefore, each service computing system 102-104 can expose an interface accessible by the client computing systems 106-108 via the network 110. The network 110 can therefore be any network of many different types, such as a wide area network, a local area network, a near-field communication network, a cellular communication network, or a combination of other networks.
[0016] In one example Figure 1 It is also shown that the client computing system 106 can generate a user interface 111, which has a user input mechanism 112 for user 114 to interact with. Thus, user 114 interacts with the user input mechanism 112 on the user interface 111 to control and manipulate parts of the client computing system 106 and the service computing systems 102-104 accessed by it.
[0017] Similarly, the client computing system 108 illustratively generates a user interface 116, which has a user input mechanism 118 for user 120 to interact with. User 120 illustratively interacts with the user interface mechanism 118 to control and manipulate portions of the client computing system 108 and the service computing systems 102-104 with which it interacts.
[0018] User 114 may be dissatisfied with the performance of the service provided by either service computing system 102 or 104 (or both). For example, suppose user 114 has interacted with user input mechanism 112 to cause client computing system 106 to generate a request for a service implemented by service computing system 102. After receiving a response to this request, user 114 may be dissatisfied with the performance of service computing system 102. Therefore, user 114 can provide input through user input mechanism 112 to indicate that a problem has occurred. For example, user 114 may actuate an actuator on user input mechanism 112 to indicate that user 114 wishes to report the problem to support users (such as support engineers). Similarly, problems can also be detected and reported automatically.
[0019] therefore, Figure 1 An interface 123 is shown to expose the supporting data storage system 122, allowing the system 122 to be accessed via network 110 by client computing systems 106-108, service computing systems 102-104, and supporting computing system 124. Similarly, supporting computing system 124 can generate a supporting user interface 126 for interaction by supporting user 128. For example, supporting user 128 could be a supporting engineer.
[0020] In summary, when a service computing system (such as system 102) generates a response to a request received from a client computing system (such as system 106), service computing system 102 also generates a relevant identifier and returns this identifier, along with the response generated in response to the request received from client computing system 106, to client computing system 106. Then, when user 114 provides input indicating that a problem has occurred, client computing system 106 provides such indication, along with a relevant ID corresponding to the request that caused the problem, to service computing system 102. Service computing system 102 then generates service diagnostic data corresponding to this relevant ID and provides the service diagnostic data, along with the relevant ID, to support data storage system 122. Client computing system 106 also generates client diagnostic data corresponding to the request and provides the client diagnostic data, along with the relevant ID, to support data storage system 122. Support data storage system 122 therefore stores the client diagnostic data and the service diagnostic data in a data storage system and indexes them using the relevant ID. Support user 128 can then use support user interfaces 126 and 123 to access both the client diagnostic data and the service diagnostic data in support data storage system 122 using the relevant ID. Therefore, support user 128 obtains an aggregated view of all diagnostic data for the reported problem by accessing only a single data storage system 122.
[0021] Similarly, when client computing system 106 submits a request to the service, multiple different service computing systems 102-104 may respond to the request and perform operations. The relevant ID for the request will be shared among all service computing systems 102-104, thereby enabling the generation of diagnostic data for the corresponding relevant ID from all service computing systems 102-104 and providing it to the supporting data storage system 122, where it can all be stored and indexed by the same relevant ID.
[0022] By enabling service computing systems 102-104 to generate diagnostic data only when a problem occurs, costly processing overhead is saved. Otherwise, diagnostic data would need to be generated for every client request, regardless of whether it has ever been used (e.g., whether a problem has been reported for that request). Similarly, because diagnostic data is generated and provided to support data storage system 122 only when a problem is reported, bandwidth consumed in architecture 100 when diagnostic data is never used, such as sending diagnostic data back and forth between the service computing system and the client computing system, is saved. Furthermore, because both client and service diagnostic data are stored together and indexed in support data storage system 122 using a single associated ID, the burden on support user 128 to access data is significantly reduced. Support user 128 only needs to access a single support data storage system 122, where aggregated diagnostic data can be displayed to support user 128.
[0023] Figure 2 A block diagram of architecture 100 is shown, in which some items in architecture 100 are shown in more detail. Figure 2 Some projects in the project and in Figure 1 The items shown are similar and are numbered similarly. Before describing the overall operation of Architecture 100 in more detail, a brief description of some additional items shown in Architecture 100 and their operation will be provided first.
[0024] The service computing system 102 illustratively includes one or more processors or servers 130, a service execution logic unit 133 (which may include a front-end system 132 and a back-end system 134), a data storage 136, a related ID generator logic unit 138, a cache interaction logic unit 140, a cache 142, a diagnostic data generation system 144, and may include various other items 146. The cache 142 may include multiple records 148-150 and other items 152. Each record in records 148-150 may include a request received from the client computing system and a related identifier generated by the related ID generator logic unit 138 for that request.
[0025] The client computing system 106 may include one or more processors or servers 156, data storage 158, support trigger detectors 160, service interaction logic unit 162, diagnostic data generation system 164, communication system 166, user interface logic unit 168, and may include other items 170.
[0026] The supporting data storage system 122 may also include one or more processors or servers 172 to generate interface 123, and may include supporting data storage 174. Supporting data storage 174 may include multiple different supporting records 176-178, and may include other items 180. Each supporting record 176 may include an associated ID 182, server diagnostic data 184 corresponding to the associated ID 182, client diagnostic data 186 corresponding to the associated ID 182, and may include other items 188.
[0027] In summary, by way of overview, the front-end system 132 and the service computing system 102 can expose interfaces that can be invoked by the service interaction logic unit 162 in the client computing system 106. The logic unit 162 can therefore submit a request 190 to the front-end system 132 via network 110. The front-end system 132 can interact with the back-end system 134, which itself interacts with data (e.g., customer data) in the data storage 136 to generate a response to request 190. When request 190 is received, the relevant ID generator logic unit 138 generates a relevant identifier corresponding to the request. This can be a GUID or other unique identifier. Then, the cache interaction logic unit 140 stores the request along with the corresponding relevant ID as records 148-150 in cache 142.
[0028] When the backend system 134 has generated a response to request 190, it provides it to the frontend system 132. The frontend system 132 appends the relevant ID to the response and returns the response and the relevant ID 192 to the service interaction logic unit 162 in the client computing system 106 that generated the request.
[0029] Service interaction logic unit 162 then displays a response (or the result of a request) to user 114. User 114 may determine at some point that there is a problem with the service. This could be due to an error in the service, a runtime error, or other errors in the service's functionality. In this case, user 114 provides input indicating that a problem has occurred through user input mechanism 112. User interface logic unit 168 generates user interface 111 and detects user interactions with user interface mechanism 112. When the user provides input indicating that a problem has occurred, support trigger detector 160 detects that a problem has occurred and controls service interaction logic unit 162 to provide input indicating that a problem has occurred to service computing system 102, and also indicates the relevant ID corresponding to the problem. This is provided by Figure 2The box 194 in the diagram is used for indication. Simultaneously, the diagnostic data generation system 164 generates any client-side diagnostic data that can be generated on the client computing system 106 based on the reported errors. The communication system 166 then transmits the client-side diagnostic data along with the associated ID to the supporting data storage system 122. Therefore, the communication system 166 can be configured to communicate via the network 110 using interface 123.
[0030] When the service computing system 102 receives a problem notification and a related ID 194, the cache interaction logic unit 140 obtains a request corresponding to the related ID from the cache 142 and provides it to the server diagnostic data generation system 144. The server diagnostic data generation system 144 then generates server diagnostic data that can be generated by the service computing system 102 based on the request. In one example, the request is resubmitted to the service execution logic unit 133, and information is obtained based on the action taken by the service computing system 102 in response to the request. Diagnostic data can also be generated in various other ways. The server diagnostic data generation system 144 then provides the service diagnostic data and the related ID to the supporting data storage system 122 via interface 123.
[0031] When client diagnostic data and service diagnostic data are received at support data storage system 122, processor and / or server 172 determines that the diagnostic data corresponds to the same relevant ID (and therefore the same problem reported by user 114). Therefore, the diagnostic data is stored as a support record (e.g., support record 176) in support data storage 174. Each support record 176 thus illustratively includes a relevant ID 182, server diagnostic data 184 corresponding to that relevant ID, and client diagnostic data 186 corresponding to that relevant ID.
[0032] The support computing system 124 can also receive a notification from the client computing system 106 indicating that the support trigger detector 160 has detected input that triggers a support operation. The notification will illustratively include the relevant ID, enabling the support user 128 to access the support record 176 (via interface 123) in the support data storage 174, corresponding to the relevant ID, using the support user interface 126 and the support computing system 124. In this way, both server diagnostic data 184 and client diagnostic data 186 can be easily accessed and displayed to the support computing system 124 for the same problem, allowing the support user 128 to analyze the data to resolve the reported problem.
[0033] It will be noted that interface 123 may actually include several different interfaces (for example, the interface for read operations from supporting user 128 may be different from the interface for write operations from other computing systems). Configurations and implementations of these and other interfaces for the interfaces discussed herein are envisioned.
[0034] Figure 3A and Figure 3B (Hereinafter referred to as Figure 3) shows a flowchart illustrating an example of the operation of architecture 100 in more detail. First, it is assumed that... Figure 1 and Figure 2 The client / server architecture illustrated in Figure 3 is operable, enabling client computing systems 106-108 to request one or more service computing systems 102-104 and receive responses to those requests. This is indicated by box 200 in the flowchart of Figure 3.
[0035] This discussion will continue with the client computing system 106 submitting requests to the service computing system 102. However, it will be noted that other client computing systems may also submit requests to the service computing system, and / or multiple service computing systems may be able to generate responses to requests submitted by client computing systems (e.g., services may be pipelined or responses may be generated simultaneously).
[0036] At a certain moment, client computing system 106 submits request 190 to service computing system 102. This is indicated by box 202 in the flowchart of Figure 3. As discussed above, front-end system 132 can expose an interface that is called by client computing system 106 (e.g., by service interaction logic unit 162 in client computing system 106) to submit the request. Submitting the request through the exposed interface exposed by front-end system 132 is indicated by box 204. The request can also be submitted in other ways, and this is indicated by box 206. Front-end system 132 then provides an indication to relevant ID generator logic unit 138 that the request has been received. Logic unit 138 generates a relevant ID corresponding to the request. This is indicated by box 208. The relevant ID can be any identifier from a variety of unique identifiers that can be used to identify different requests and distinguish them from each other. Cache interaction logic unit 140 then stores the relevant ID along with request 190 in cache 142. This is indicated by box 210. The cache 142 can operate in various ways. It can store records for a predetermined, default, or configurable amount of time. It can store a given number of records in a first-in, first-out (FIFO) manner, such that the oldest received record is removed from the cache when a new record is stored, or it can store records with configurable retention in other ways.
[0037] The front-end system 132 also provides request 190 to the back-end system 134, which generates a response to the request. In doing so, user data in data storage 136 can be accessed, or other operations can be performed based on request 190. The generation of a response to the request is indicated by box 212 in the flowchart of Figure 3.
[0038] The front-end system 132 then provides the response and the associated ID 192 back to the requesting client computing system 106. This is indicated by box 214.
[0039] If the response is without issue or other issues, as indicated by box 216, the process simply returns to box 202, where the client computing system 106 can submit other requests to the service computing system 102.
[0040] However, the support trigger detector 160 may detect a support trigger at box 216 in FIG3. The support trigger can be detected in a variety of different ways. For example, there may be an automatic support trigger generator in the client computing system 106 that automatically generates support triggers. For example, if the service computing system 102 takes too long to respond to request 190, this might generate an automatic trigger to notify the support computing system 124 that there may be a problem with the service computing system 102. In another example, the support trigger is detected based on user input from user 114. For example, user 114 may observe that the performance of the service computing system 102 is impaired in some way (e.g., response time is too long, response is not as expected or correct, etc.). In this case, user 114 can provide input via user input mechanism 112, which causes the support trigger detector 160 to detect a support trigger. In one example, user 114 can actuate a link (or other user interface actuator) to send a message at the support computing system 124 or otherwise initiate communication with support user 128. The actuation can be detected as supported by the trigger detector 160.
[0041] If a support trigger is detected at box 216 (in the flowchart of FIG. 3), the service interaction logic unit 162 sends an indication or notification 194 that a problem has occurred (e.g., a support trigger has been detected), along with a related ID of a response 192 corresponding to the reported problem (or for which a support trigger has been generated). Sending the problem notification and the related ID 194 to the service computing system 102 is indicated by box 218 in the flowchart of FIG. 3.
[0042] Similarly, when the support trigger detector 160 detects a support trigger, it indicates this to the diagnostic generation system 164, which generates client diagnostic data on the client computing system 106. The generation of this client diagnostic data is indicated by box 220 in the flowchart of Figure 3. System 164 is capable of generating various different types of diagnostic data. This can depend on the type of service to which request 190 is sent. It may include, for example, the delay between when request 190 is sent and when response 192 is received. It may also include a wide variety of other diagnostic information.
[0043] The communication system 166 then sends the client diagnostic data along with the corresponding relevant ID to the supporting data storage system 122. This is indicated by box 222 in the flowchart of Figure 3.
[0044] Similarly, when a problem notification 194 and a related ID are received at service computing system 102, cache interaction logic unit 140 accesses cache 142 to obtain a request corresponding to the related ID received along with the problem notification 194. It provides this request to diagnostic data generation system 144, which generates diagnostic data corresponding to the request. This can be done by resubmitting the request (e.g., to front-end system 132 and / or back-end system 134) via service execution logic unit 133 and recording the diagnostic data generated during processing the request. Various other diagnostic data generation operations can also be performed. Generating server diagnostic data for request 190 corresponding to the related ID is indicated by box 224. Accessing cache 142 using the related ID to obtain the request is indicated by box 226. Replaying the request via front-end system 132 and / or back-end system 134 is indicated by box 228. Performing other diagnostic operations is indicated by box 230. The server diagnostic data can also be generated in many other ways, and this is indicated by box 232.
[0045] The diagnostic data generation system 144 then sends the server diagnostic data, along with its corresponding associated ID, to the support data storage system 122. This is indicated by box 234 in the flowchart of Figure 3. The processor / server 172 in the support data storage system 122 then uses the associated ID corresponding to the diagnostic data to store the client diagnostic data and the server diagnostic data in a support record in the support data storage system 174. This is indicated by box 236 in the flowchart of Figure 3. In one example, the client and server diagnostic data in the support record are indexed using the associated ID. The support record can then be displayed for access by the support computing system 124. This is indicated by box 238.
[0046] In this manner, when support user 128 receives an indication that user 114 has reported a problem, the indication will descriptively include the relevant ID. User 128 can then use interface 123 to obtain server diagnostic data and client diagnostic data for that relevant ID from the appropriate support record in support data store 174. This information can be displayed by support computing system 124 on support user interface 126 for support user 128. In this way, support user 128 can obtain an aggregated set of diagnostic data (diagnostic data generated on client computing system 106 and diagnostic data generated on service computing system 102) by accessing a single data store. Similarly, because diagnostic data is only generated on service computing system 102 and provided to support data store system 122 when a problem is reported or automatically detected, this saves the expensive processing overhead that would otherwise be used to generate the diagnostic data. It also saves bandwidth consumed when transmitting unnecessary diagnostic data.
[0047] It will be noted that the above discussion has described a variety of different systems, components, and / or logical units. It will be appreciated that such systems, components, and / or logical units can consist of hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components, and / or logical units. Additionally, the systems, components, and / or logic can consist of software loaded into memory and subsequently run by a processor, server, or other computing component, as described below. The systems, components, and / or logical units can also be composed of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are merely some examples of the different structures that can be used to form the systems, components, and / or logical units described above. Other structures can also be used.
[0048] Processors and servers have been mentioned in this discussion. In one embodiment, the processor and server include a computer processor with associated memory and timing circuitry, not shown separately. It is a functional part of the system or device to which it belongs and is activated or facilitated by the functionality of other components or items in those systems.
[0049] Similarly, many user interface displays have been discussed. They can take many different forms and can feature a variety of user-actuable input mechanisms. For example, these user-actuable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in various ways. For example, they can be actuated using clicking devices (such as trackballs or mice). They can be actuated using hardware buttons, switches, joysticks or keyboards, thumb switches or thumb pads, etc. They can also be actuated using virtual keyboards or other virtual actuators. Furthermore, if the display screen is touch-sensitive, it can be actuated using touch gestures. Likewise, if the display device has a voice recognition component, it can be actuated using voice commands.
[0050] Many data stores have already been discussed. It will be noted that each of these can be broken down into multiple data stores. For accessing their respective systems, all data stores can be local or remote, or some can be local while others are remote. This article covers all of these configurations.
[0051] Similarly, the accompanying diagram illustrates multiple boxes with functions belonging to each box. It will be noted that fewer boxes can be used, thus requiring fewer components to perform the functions. Likewise, more boxes can be used with functions distributed among more components.
[0052] Figure 4 Is Figure 1 The block diagram of architecture 100 shown differs in that its components are arranged within a cloud computing architecture 500. Cloud computing provides computing, software, data access, and storage services without requiring end users to know the physical location or configuration of the system providing the services. In various embodiments, cloud computing delivers services over a wide area network (WAN) such as the Internet using appropriate protocols. For example, cloud computing providers deliver applications over a WAN, which can be accessed via a web browser or any other computing component. The software or components of architecture 100, along with their corresponding data, can be stored on servers in remote locations. The computing resources in a cloud computing environment can be consolidated at remote data center locations, or they can be distributed. Cloud computing infrastructure can deliver services over shared data centers, even if it appears to the user as a single access point. Therefore, the components and functions described herein can be provided from service providers in remote locations using a cloud computing architecture. Alternatively, they can be provided from conventional servers, or they can be installed directly on client devices, or otherwise.
[0053] The description is intended to include both public and private cloud computing. (Both public and private) cloud computing provides essentially seamless resource pooling and reduces the need to manage and configure the underlying hardware infrastructure.
[0054] Public clouds are managed by a vendor and typically support multiple consumers using the same infrastructure. Similarly, unlike private clouds, public clouds free end users from managing hardware. Private clouds can be managed by the organization itself, and the infrastructure is usually not shared with other organizations. The organization still maintains the hardware to some extent, such as installation and maintenance.
[0055] exist Figure 4 In the example shown, some items are related to Figure 1 Those shown are similar and are numbered similarly. Figure 4 Specifically, service computing systems 102 and 104 can reside in cloud 502 (which can be public, private, or a combination of parts public and other parts private). Therefore, users 114 and 120 access those systems via cloud 502 using user devices 504 and 506. Figure 4 It is also shown that the data storage system 122 can also reside in the cloud 502. Users 128 can access the data storage system 122 using the supporting computing system 124.
[0056] Figure 4 It also depicts another example of cloud architecture. Figure 4 The diagram also illustrates that some components of architecture 100 can be located within cloud 502, while others cannot. By way of example, supporting data storage system 122 can be located outside of cloud 502 and accessed through cloud 502. Regardless of its location, it can be directly accessed by devices 504 and 506 and system 124 via a network (WAN or LAN), it can be hosted as a service at a remote site, or it can be provided as a service via the cloud or accessed via a connectivity service residing in the cloud. All these architectures are envisioned herein.
[0057] It will also be noted that architecture 100, or parts thereof, can be deployed on a variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices such as handheld computers, mobile phones, smartphones, multimedia players, personal digital assistants, etc.
[0058] Figure 5 This is, for example, an example of a computing environment capable of deploying architecture 100 or a portion thereof. (See reference) Figure 5An exemplary system for implementing some embodiments includes a computing device in the form of a computer 810 configured to operate as described above. Components of computer 810 may include, but are not limited to: a processing unit 820 (capable of including a processor or server from previous figures), system memory 830, and a system bus 821 that couples various system components, including system memory, to the processing unit 820. System bus 821 can be any of several types of bus architectures, including a memory bus or memory controller using any of a variety of bus architectures, peripheral buses, and local buses. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses (also referred to as mezzanine buses). Regarding Figure 1 The described memory and program can be deployed in Figure 5 In the corresponding part.
[0059] Computer 810 typically includes a variety of computer-readable media. Computer-readable media can be any available medium accessible to computer 810, and includes both volatile and non-volatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media are distinct from and do not include modulated data signals or carrier waves. They include hardware storage media, including volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium capable of storing desired information and accessible by computer 810. Communication media typically embody computer-readable instructions, data structures, program modules, or other data in a transmission mechanism, and includes any information delivery medium. The term "modulated data signal" means a signal whose characteristics are set or altered in such a way as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.
[0060] System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. Basic input / output system 833 (BIOS) contains basic routines that facilitate the transfer of information between various components within computer 810 (such as during startup); this BIOS is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that can be immediately accessed and / or operated by processing unit 820. By way of example and not limitation, Figure 5 The diagram illustrates the operating system 834, application program 835, other program modules 836, and program data 837.
[0061] Computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. This is by way of example only. Figure 5 The illustration shows a hard disk drive 841 that reads from or writes to a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads from or writes to a removable, non-volatile optical disk 856 (such as a CD-ROM or other optical media). Other removable / non-removable, volatile / non-volatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cartridges, flash memory cards, digital multifunction disks, digital videotapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.
[0062] Alternatively or additionally, the functions described herein can be performed at least in part by one or more hardware logic components. Exemplary types of hardware logic components that can be used include, for example but not limited to, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), etc.
[0063] The above discussion and Figure 5 The drive and its associated computer storage media illustrated in the diagram provide storage for computer-readable instructions, data structures, program modules, and other data for the computer 810. Figure 5For example, hard disk drive 841 is illustrated as storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to indicate that they are at least different copies.
[0064] Users can input commands and information into computer 810 through input devices such as keyboard 862, microphone 863, and pointing device 861 such as mouse, trackball, or touchpad. Other input devices (not shown) may include joysticks, game controllers, satellite antennas, scanners, etc. These and other input devices are typically connected to processing unit 820 via user input interface 860 coupled to the system bus, but may be connected via other interfaces and bus structures such as parallel ports, game ports, or Universal Serial Bus (USB). Visual display 891 or other types of display devices are also connected to system bus 821 via an interface such as video interface 890. In addition to a monitor, the computer may include other peripheral output devices, such as speakers 897 and printer 896, which may be connected via output peripheral interface 895.
[0065] Computer 810 operates in a network environment using logical connections to one or more remote computers (such as remote computer 880). Remote computer 880 can be a personal computer, handheld device, server, router, network PC, peer-to-peer device, or other public network node, and typically includes many or all of the elements described above regarding computer 810. Figure 5 The logical connections described include Local Area Networks (LANs) 871 and Wide Area Networks (WANs) 873, but may also include other networks. Such network environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.
[0066] When used in a LAN network environment, computer 810 is connected to LAN 871 via a network interface or adapter 870. When used in a WAN network environment, computer 810 typically includes a modem 872 or other unit for establishing communication over a WAN 873 (such as the Internet). The modem 872, which may be internal or external, may be connected to system bus 821 via user input interface 860 or other suitable means. In a networked environment, program modules or portions thereof depicted with respect to computer 810 may be stored in a remote memory storage device. This is by way of example and not limitation. Figure 5The remote application 885 is shown residing on the remote computer 880. It will be appreciated that the network connection shown is exemplary and other methods can be used to establish a communication link between computers.
[0067] It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of these are conceived in this paper.
[0068] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.
[0069] Example 1 is a computing system that includes:
[0070] At least one processor;
[0071] A service execution logic unit, run by the at least one processor, receives client requests generated by the client computing system and generates responses to the client requests;
[0072] A related identifier (ID) generator logic unit, run by the at least one processor, generates a related ID corresponding to the client request, and the service execution logic unit sends the response and the related ID to the client computing system;
[0073] A cache interaction logic unit, operated by the at least one processor, generates a memory record including the client request and a corresponding associated ID for storage in memory; and
[0074] A server diagnostic data generation system receives the relevant ID and a problem indication indicating that a problem was detected at the client computing system in response to the response. The server diagnostic data generation system generates server diagnostic data based on the request stored in the memory and the corresponding relevant ID, and sends the server diagnostic data together with the corresponding relevant ID to a supporting data storage system.
[0075] Example 2 is any or all of the computing systems described in the foregoing examples, wherein the service operation logic unit includes:
[0076] A front-end system that exposes an interface for receiving requests from the client.
[0077] Example 3 is any or all of the computing systems described in the foregoing examples, wherein the service operation logic unit includes:
[0078] A backend system receives instructions for the client request from the frontend system and performs service operations based on the client request to generate the response.
[0079] Example 4: Any or all of the computing systems described in the preceding examples, wherein the server diagnostic data generation system is configured to: receive the problem indication and the relevant ID to access the memory using the cache interaction logic unit.
[0080] Example 5 is any or all of the computing systems described in the foregoing examples, wherein the server diagnostic data generation system is configured to: use the interaction logic unit to access the memory, obtain an indication of the client request from the cache memory based on the relevant ID, and generate the server diagnostic data based on the indication of the client request.
[0081] Example 6 is any or all of the computing systems described in the foregoing examples, wherein the server diagnostic data generation system is configured to generate the server diagnostic data by resubmitting the client request obtained from the memory to the service running logic unit.
[0082] Example 7 is any or all of the computing systems described in the foregoing examples, wherein the memory includes a cache memory that can be configured to change the retention of the client request.
[0083] Example 8 is a computer-implemented method that includes:
[0084] Utilize at least one processor to receive client requests generated by the client computing system;
[0085] A response to the client request is generated using a service execution logic unit implemented by the at least one processor;
[0086] The relevant identifier (ID) generator logic unit generates a relevant ID corresponding to the client request;
[0087] Send the response and the relevant ID to the client computing system;
[0088] The at least one processor is used to generate a memory record, the memory record including the client request and the corresponding related ID for storage in memory;
[0089] The server diagnostic data generation system receives the relevant ID and a problem indication indicating that a problem was detected at the client computing system in response to the response.
[0090] The server diagnostic data generation system generates server diagnostic data based on the requests stored in the memory and the corresponding related IDs; and
[0091] The server diagnostic data, along with the corresponding relevant ID, is sent to the supporting data storage system.
[0092] Example 9 is a computer-implemented method of any or all of the foregoing examples, wherein receiving a client request includes:
[0093] The front-end system exposes an interface for receiving client requests from the client computing system.
[0094] Example 10 is any or all of the computer-implemented methods described in the foregoing examples, wherein generating the response includes:
[0095] At the backend system, an instruction for the client request is received from the frontend system; and
[0096] Based on the client request, the backend system performs service operations to generate the response.
[0097] Example 11 is a computer-implemented method of any or all of the foregoing examples, wherein generating server diagnostic data includes:
[0098] Access the memory record based on the problem indication and the relevant ID to obtain the client request corresponding to the relevant identifier from the memory.
[0099] Example 12 is any or all of the computer-implemented methods described in the foregoing examples, wherein generating the server diagnostic data includes:
[0100] Receive an indication of the client's request from the memory; and
[0101] The server diagnostic data is generated based on the instruction given in response to the client request.
[0102] Example 13: Any or all of the computer-implemented methods described in the foregoing examples, generating the server diagnostic data includes:
[0103] The client request obtained from the memory is resubmitted to the service operation logic unit.
[0104] Example 14 is a computer-implemented method of any or all of the foregoing examples, wherein generating a memory record includes:
[0105] Generate a memory record for storage in a cache memory, which can be configured to change the retention of the memory record.
[0106] Example 15 is a computer-implemented method that includes:
[0107] Receive server diagnostic data generated by the first service computing system based on a client request received from the client computing system, wherein the client request has a corresponding related identifier;
[0108] The client computing system receives client diagnostic data and the relevant identifiers, wherein the client diagnostic data is generated by the client computing system based on the client request and the response from the first service computing system;
[0109] The server diagnostic data and the client diagnostic data from the first service computing system are stored in a data storage system, and the server diagnostic data and the client diagnostic data are indexed by the relevant identifiers; and
[0110] Based on the relevant identifier and the access request, an interface for receiving access requests from the supporting computing system is exposed, and based on the relevant identifier and the access request, access to the stored server diagnostic data and the client diagnostic data is provided to the supporting computing system.
[0111] Example 16 is any or all of the computer-implemented methods described in the foregoing examples, and further includes:
[0112] Based on the client request received from the client computing system at the first service computing system, the system receives server diagnostic data generated by the second service computing system and the relevant identifier; and
[0113] The server diagnostic data from the second service computing system is stored in the data storage, and the server diagnostic data is indexed by the relevant identifier.
[0114] Example 17 is any or all of the computer-implemented methods described in the foregoing examples, wherein the exposed interface includes:
[0115] The interface is exposed for receiving the access request from the supporting computing system, and the supporting computing system is provided with access to the server diagnostic data stored from the first service computing system, the server diagnostic data from the second computing system, and the client diagnostic data based on the relevant identifier and the access request.
[0116] Example 18 is a computer-implemented method that includes:
[0117] Send a service request to the service computing system;
[0118] Receive a response to the service request and a corresponding identifier from the service computing system;
[0119] The detection supports triggering;
[0120] Based on the detected support trigger, a support notification and the relevant identifier are sent to the server computing system;
[0121] Generate client diagnostic data based on the service request and the response; and
[0122] The client diagnostic data and the relevant identifiers are sent to the supporting data storage system.
[0123] Example 19 is any or all of the computer-implemented methods described in the foregoing examples, wherein the detection of support triggers includes:
[0124] Detect user actuations that support request actuators on the user interface.
[0125] Example 20 is any or all of the computer-implemented methods described in the foregoing examples, wherein the detection of support triggers includes:
[0126] The detection is automatically generated and supports triggering.
Claims
1. A computing system, comprising: At least one processor; A service execution logic unit, run by the at least one processor, receives client requests generated by the client computing system and generates responses to the client requests; A related identifier ID generator logic unit, run by the at least one processor, generates a related ID corresponding to the client request, and the service execution logic unit sends the response and the related ID to the client computing system; A cache interaction logic unit, operated by the at least one processor, generates a memory record, the memory record including the client request and a corresponding related ID for storage in memory; as well as A server diagnostic data generation system receives the relevant ID and problem indication from the client computing system, wherein the problem indication indicates that a problem was detected at the client computing system in response to the response sent to the client computing system. The server diagnostic data generation system generates server diagnostic data based on the client request stored in the memory and the corresponding relevant ID by resubmitting the client request obtained from the memory to the service running logic unit, and sends the server diagnostic data together with the corresponding relevant ID to the supporting data storage system.
2. The computing system according to claim 1, wherein, The service operation logic unit includes: The front-end system exposes an interface for receiving requests from the client.
3. The computing system according to claim 2, wherein, The service operation logic unit includes: A backend system receives instructions on the client request from the frontend system and performs service operations based on the client request to generate the response.
4. The computing system according to claim 3, wherein, The server diagnostic data generation system is configured to receive the problem indication and the relevant ID, and to use the cache interaction logic unit to access the memory.
5. The computing system according to claim 4, wherein, The server diagnostic data generation system is configured to: use the cache interaction logic unit to access the memory, obtain an indication of the client request from the memory based on the relevant ID, and generate the server diagnostic data based on the indication of the client request.
6. The computing system according to claim 1, wherein, The memory includes a cache memory that can be configured to change the retention of client requests.
7. A computer-implemented method, comprising: Utilize at least one processor to receive client requests generated by the client computing system; The service execution logic unit implemented by the at least one processor is used to generate a response to the client request; The relevant identifier ID generator logic unit is used to generate a relevant ID corresponding to the client request; Send the response and the relevant ID to the client computing system; The at least one processor is used to generate a memory record, the memory record including the client request and a corresponding related ID for storage in memory; The relevant ID and problem indication are received from the client computing system at the server diagnostic data generation system, wherein the problem indication indicates that a problem was detected at the client computing system in response to the response sent to the client computing system; The server diagnostic data generation system generates server diagnostic data based on the client request stored in the memory and the corresponding related ID by resubmitting the client request obtained from the memory to the service operation logic unit; and The server diagnostic data, along with the corresponding relevant ID, is sent to the supporting data storage system.
8. The computer-implemented method according to claim 7, wherein, Receiving client requests includes: The front-end system exposes an interface for receiving client requests from the client computing system.
9. The computer-implemented method according to claim 8, wherein, Generating the response includes: The backend system receives an instruction from the frontend system regarding the client request; and Based on the client request, the backend system performs service operations to generate the response.
10. The computer-implemented method according to claim 9, wherein, The generated server diagnostic data includes: Access the memory record based on the problem indication and the relevant ID to obtain the client request corresponding to the relevant identifier from the memory.
11. The computer-implemented method according to claim 10, wherein, Generating the server diagnostic data includes: Receive an indication of the client's request from the memory; and The server diagnostic data is generated based on the instruction given in response to the client request.
12. A computer-implemented method, comprising: Receive server diagnostic data generated by the first service computing system based on a client request received from the client computing system, as described in claim 7, wherein the client request has a corresponding related identifier; The client computing system receives client diagnostic data and the relevant identifier, wherein the client diagnostic data is generated by the client computing system based on the client request and the response from the first service computing system; The server diagnostic data and the client diagnostic data from the first service computing system are stored in a data storage, and the server diagnostic data and the client diagnostic data are indexed by the relevant identifiers; as well as An interface is exposed for receiving access requests from the supporting computing system, and access to the stored server diagnostic data and client diagnostic data is provided to the supporting computing system based on the relevant identifier and the access request.
13. A computer-implemented method, comprising: Send a service request to the service computing system; Receive a response to the service request and a corresponding identifier from the service computing system; The detection supports triggering; Based on the detected support trigger, a support notification and the relevant identifier are sent to the service computing system. Generate client diagnostic data based on the service request and the response; as well as The server diagnostic data, the client diagnostic data, and the relevant identifier obtained by the method according to claim 7 are sent to the supporting data storage system.
Citation Information
Patent Citations
Correlating performance data
US20160226731A1