TWI893528B - Server and error diagnosis method thereof - Google Patents

Abstract

The present invention provides a server error analysis method, comprising the following steps: confirming a first error occurring in a first service server, the first service server being one of a plurality of service servers that perform service calls with each other; determining whether the first error has call dependency based on type information of the first error; selecting at least a portion of error history information and resource history information of the plurality of service servers as analysis target information based on whether the first error has the aforementioned call dependency; and confirming the cause of the first error based on the analysis target information.

Description

Server and error analysis method thereof

The present invention relates to a method for finding the cause of an error occurring in a service server performing a service call between the servers and a server implementing the method.

Most recent Internet services are implemented using a microservice architecture. The microservice architecture described above may refer to a structure that has multiple service servers that implement small functions, and that perform chained service calls with each other to implement an overall large service. In a structure where chained service calls occur as described above, it is difficult to find the root cause of any service failure. That is, when a specific error occurs, engineers need to dive deep into the problem directly to confirm which previous error caused the specific error. As described above, in a microservice architecture, it is necessary to rely on the individual capabilities of engineers to find the root cause of the error, which may become a significant disadvantage in terms of service maintenance and management. Therefore, it is necessary to solve the problems described above.

For related information, please refer to previous literature such as KR10-1684405B1.

[Identify the problem you want to solve]

The disclosed embodiments provide a server and an error analysis method thereof. Specifically, one of the purposes is to automatically analyze the causes of errors that occur in chained service calls between service servers in a microservice architecture that perform service calls between each other.

The technical issues to be achieved by this embodiment are not limited to the technical issues described above; other technical issues can be inferred based on the following embodiments. [Technical Means for Solving the Problem]

One aspect of the present invention may include an error analysis method, which is performed by a server and includes the following steps: confirming a first error occurring in a first service server, where the first service server is one of a plurality of service servers that perform service calls with each other; based on type information of the first error, determining whether the first error has call dependency; based on whether the first error has the call dependency, selecting at least a portion of error history information and resource history information of the plurality of service servers as analysis target information; and based on the analysis target information, confirming the cause of the first error.

In one embodiment of the present invention, an error analysis method may be included, wherein the step of selecting the above-mentioned analysis target information is to select the following two types of information as the above-mentioned analysis target information if it is confirmed that the above-mentioned first error has the above-mentioned call dependency: (i) second attribute information of at least one second error, which is the attribute information of multiple errors included in the above-mentioned error history information based on the above-mentioned second attribute information; and (ii) second resource information of at least a portion of the second error, which is computing resource-related data of a second service server where the second error occurs, corresponding to the occurrence of at least a portion of the second error, and the computing resource-related data is included in the resource history information.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the first attribute information includes a tracking ID (identifier) of the first error, occurrence time, input parameters, API (application programming interface) path, server IP (Internet Protocol), exception handling method, error message, and at least a portion of the above-mentioned type information.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the second error is selected by calculating the similarity between at least a portion of the attribute information of the plurality of errors and at least a portion of the first attribute information, and confirming that the similarity is above a critical value.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the step of confirming the above-mentioned cause is based on at least a part of the above-mentioned second attribute information, deriving the call relationship between the above-mentioned first and second errors, and analyzing the above-mentioned call relationship, and confirming the specific error in the above-mentioned second error that occurs first in the above-mentioned call relationship and induces other errors as the above-mentioned cause.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the step of confirming the above-mentioned cause is to additionally confirm as a reference factor a specific service of a resource that generates a critical value before the above-mentioned specific error occurs, and the specific service is confirmed based on specific resource information corresponding to the above-mentioned specific error, and the specific resource information is at least a part of the above-mentioned second resource information.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the step of selecting the above-mentioned analysis object information is to select the first resource information corresponding to the occurrence of the above-mentioned first error from the computing resource-related data of the above-mentioned first service server included in the above-mentioned resource history information when it is confirmed that the above-mentioned first error does not have the above-mentioned call dependency as the above-mentioned analysis object information; and the step of confirming the cause is to confirm the above-mentioned first error as the above-mentioned cause.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the step of confirming the cause information is to additionally confirm a specific service of a resource that generated a critical value before the first error occurred as a reference factor, and the specific service is confirmed based on the first resource information.

Furthermore, one embodiment of the present invention may include an error analysis method, which further includes the following steps: based on at least a portion of the analysis object information, generating report information of the above cause and transmitting it to a management terminal.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the report information is generated based on attribute information of the cause and resource information of the corresponding cause occurrence, and the attribute information and resource information of the corresponding cause occurrence are confirmed based on the error history information and at least a portion of the resource history information.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein if the first error is determined to have the call dependency based on the type information, the report information is further generated based on the call relationship between the cause and the first error.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein when the type information of the cause indicates a database error, the report information is further generated based on computing resource-related data of the database associated with the cause at the time when the corresponding cause occurred.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein when a reference factor is additionally identified in addition to the aforementioned cause, the report information is further generated based on attribute information of the reference factor and relationship information between the reference factor and the aforementioned cause.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein hourly frequency information of a specific error confirmed as the cause of the first error is received, and only when the hourly frequency information is above a critical value, the report information is transmitted to the administrator terminal.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the report information further includes information of at least one attention error identified as the most common cause within a specified time period.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the error history information includes attribute information of errors occurring on each service server in chronological order of the errors, and errors that occurred more than a critical time later are deleted from the error history information.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the resource history information includes data obtained by recording at least a portion of the CPU (central processing unit), memory, and network data of each service server according to a specified period.

Furthermore, one embodiment of the present invention may include an error analysis method, wherein the resource history information further includes data obtained by recording the CPU, memory, network data of the database and at least a portion of the data requests received by the database according to a specified period, and the database is linked to at least a portion of the service servers mentioned above to perform operations.

Another aspect of the present invention may provide a server for analyzing errors, comprising a memory for storing commands and a processor configured as follows: connected to the memory, confirming a first error occurring in a first service server, the first service server being one of a plurality of service servers that perform service calls with each other; determining whether the first error is call-dependent based on type information of the first error; selecting at least a portion of error history information and resource history information of the plurality of service servers as analysis target information based on whether the first error is call-dependent; and confirming the cause of the first error based on the analysis target information.

Another aspect of the present invention can provide a non-transitory computer-readable recording medium that records a program for executing the above-mentioned information providing method on a computer.

Specific details of other embodiments are included in the detailed description and drawings. [Effects of the Invention]

According to the proposed embodiments, one or more of the following effects can be expected.

According to the embodiments of this specification, historical information about errors that occurred in each server and data related to computing resources at the time of the error can be automatically analyzed to identify the root cause of the failure and perform diagnosis.

Furthermore, according to the embodiments of this specification, the cause of the error can also be analyzed by the following case-by-case optimized analysis method. In the case of call-dependent errors, the analysis is centered on historical error information, and in the case of non-call-dependent errors, the analysis is centered on data information related to computing resources.

Furthermore, according to the embodiments of this specification, the root cause of the diagnosed fault phenomenon can be communicated to the user so that measures can be taken to address the root cause.

The effects of the invention are not limited to the effects mentioned above. A person skilled in the art can clearly understand other effects not mentioned based on the description of the patent application.

The terms used in the embodiments are selected from commonly used terms, as much as possible, taking into account the functions of the present invention. However, they may vary depending on the intentions of those skilled in the art, precedents, the emergence of new technologies, and so on. Furthermore, in certain cases, there may be terms arbitrarily selected by the applicant. In such cases, their meanings will be described in detail in the corresponding description. Therefore, the terms used in this invention should be defined based on the meaning of the terms and the overall content of the invention, rather than simply based on the names of the terms.

When it is mentioned throughout the specification that a certain constituent element “includes” another constituent element, unless there is any special description to the contrary, it means that the other constituent elements may be included rather than excluded.

The expression "at least one of a, b, and c" described throughout the specification may include "a alone," "b alone," "c alone," "a and b," "a and c," "b and c," or "all three of a, b, and c."

The "terminal" mentioned below can be implemented as a computer or portable terminal, which can be connected to a server or other terminal via a network. Here, computers include, for example, laptops, desktops, and the like equipped with a web browser. Portable terminals are wireless communication devices that ensure portability and mobility, and can include, for example, IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), LTE (Long Term Evolution), and other communication terminals, as well as all types of handheld wireless communication devices such as smartphones and tablets.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement the present invention. However, the present invention can be implemented in various forms and is not limited to the embodiments described herein.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a diagram illustrating an example of analyzing an erroneous server and its associated relationships according to an embodiment.

Referring to Figure 1 , server 100 operates in conjunction with an error history database (DB) 300 and a resource history database 400. Error history database 300 stores error information from service servers 210 , 220 , and 230 , while resource history database 400 stores resource usage information from service servers 210 , 220 , 230 and service database 240 . Meanwhile, Figure 1 only illustrates components relevant to this embodiment. Therefore, those skilled in the art will appreciate that this embodiment may include other commonly used components in addition to those shown in Figure 1 .

Service servers 210, 220, and 230 may be at least a portion of the service servers that comprise a microservices architecture. Specifically, at least a portion of the service servers that implement small services and provide services may be servers that call services between each other. For example, when a user enters the Search Detail Page (SDP) on a shopping mall website, the server communicating with the user's terminal may call microservices required to implement security services, product price calculation services, and checkout services, and send the call result information to the user terminal. As described above, the called microservice can call another service. In FIG1 , the following structure is an example of the call structure described above: service server 210 calls another service server 220, and service server 220 calls yet another service server 230. Furthermore, databases such as service DB 240 can also be used by service server 210. The example call structure in FIG1 is merely an example; the error analysis method of the present invention can be applied to any microservice architecture with a different call structure.

At this time, the error history DB 300 and the resource history DB 400 can be databases containing error history information and resource history information, respectively. First, the error history DB 300 will be described. It can be a database that receives error messages from service servers 210, 220, and 230 upon their publication and stores the error attribute information in a first-in, first-out format, such as a queue. Alternatively, similar to but slightly different from the queue format, error history DB 300 can include attribute information of errors occurring in each service server 210, 220, and 230 in the error history information in chronological order of error occurrence. Errors that have occurred for a time exceeding a threshold value can be deleted from the error history information. Here, the threshold value can be a value set to analyze the call relationship of the service. According to one embodiment, in a microservices architecture, it can be set slightly longer than the time interval of data sent and received based on the service call. Furthermore, each item of attribute information may include each error's tracking ID, occurrence time, input parameters, service name, API path, IP address, error message, exception handling method, and type information. The tracking ID may be the trace ID of the entire service implemented by the microservice, and the input parameters may refer to the input parameters of the corresponding service. The occurrence time may refer to the time when each error occurred, the service name may refer to the name of the corresponding microservice, and the IP address may refer to the IP address of the corresponding service server. The error message may refer to the system message of the corresponding error, and the exception handling method may be information indicating how the exception was handled after the corresponding error occurred. Type information indicates whether the error falls into a certain category. Some types can be set to indicate a call dependency on another service. Specifically, if an error occurs due to a call to another service but that service is not functioning properly, it can be considered a call dependency error. Examples of type information include, but are not limited to, Call Dependency Service Timeout, Call Dependency Service Internal Error, Call Dependency Service Invalid Request, Access Database Error, and Access Cache Error. According to one embodiment, the error types with call dependencies in the aforementioned type information may include call dependency service timeouts and call dependency service internal errors, while other types may be determined to be non-call dependent. Furthermore, errors such as database access errors may be determined to be errors related to the database.

Next, the resource history database 400 will be described. It can be a database that stores infrastructure metrics data for service servers 210, 220, and 230 and service database 240, namely, data related to the usage history of computing resources, as resource history information. According to one embodiment, the resource history information may include data obtained by recording at least a portion of the CPU, memory, and network data of at least a portion of each service server 210, 220, and 230 and service database 240 at specified intervals. In the case of service database 240, information regarding received data requests may also be included in the resource history information. Here, according to one embodiment, CPU, memory, and network data may refer to usage, but this is not a limitation. Alternatively, as another embodiment, the corresponding data of the corresponding service server or service DB may be stored in the resource history DB 400 only at the time when the error occurs.

The following describes an error analysis method according to an embodiment of the present invention.

FIG2 is a flow chart illustrating an error analysis method according to an embodiment.

Referring to Figure 2, in S210, server 100 may confirm a first error occurring in a first service server, which is one of a plurality of service servers that are engaged in a service call. In S220, based on the type information of the first error, it may be determined whether the first error is call-dependent. In S230, based on whether the first error is call-dependent, at least a portion of the error history information and resource history information of the plurality of service servers may be selected as analysis target information. In S240, based on the analysis target information, the cause of the first error may be determined. Each step is described in detail below.

First, if a first error occurs on the first service server, server 100 can confirm the error. As described above, if an error message is issued from the first service server in response to the occurrence of the first error, the error message is immediately sent to error history database 300. The error history information stored in the error message includes the first attribute information of the first error. At this point, server 100 can obtain the first attribute information described above from error history database 300.

Thereafter, server 100 can determine whether there is call dependency based on the type information of the first error. As described above, the first attribute information may include the type information of the first error, and specific types such as a call dependency service timeout and a call dependency service internal error may indicate that the first error is call dependent. Based on the type information described above, server 100 can determine whether the error occurred because the first error called another service but the other service did not operate normally, that is, whether there is call dependency. Based on whether there is call dependency as described above, server 100 can select at least a portion of the error history information and resource history information of multiple service servers as analysis target information. The following describes each process based on whether it is call-dependent.

Specifically, if the first error is determined to be call-dependent, server 100 may first select second attribute information of at least one second error as analysis target information. This second attribute information is selected based on at least a portion of the first attribute information of the first error from the attribute information of the plurality of errors included in the error history information. This operation can be performed by linking server 100 with error history database 300. Here, the second error can be selected by calculating the similarity between at least a portion of the attribute information of the plurality of errors and at least a portion of the first attribute information, and then confirming that the similarity exceeds a threshold value. Specifically, at least a portion of the aforementioned attribute information, namely the error tracking ID, occurrence time, input parameters, service name, API path, IP address, error message, exception handling method, and type information, is vectorized. After weighting each component, similarity is calculated between vectors. Errors exceeding a preset threshold are identified as second errors. Alternatively, only tracking IDs may be compared, and errors with the same tracking ID as the first error are identified as second errors.

Additionally, if the second error has been confirmed, the server 100 may select, from the computing resource-related data of the service server where the second error occurred, at least a portion of the second resource information corresponding to at least a portion of the occurrence of the second error as analysis target information. This computing resource-related data is included in the resource history information. In other words, the CPU, memory, or network-related data at the time of the second error may be selected as analysis target information. When the second error type information indicates a database-related error, such as a database access error, resource information related to the database associated with the corresponding service server and performing the operation may also be selected as the second resource information along with the resource information of the service server. According to one embodiment, the second resource information described above may also be selected as the analysis target information.

According to one embodiment, server 100 can identify the cause of the first error based on analysis target information including the second attribute information described above. First, server 100 can derive a call relationship between the first and second errors based on at least a portion of the second attribute information, analyze the call relationship, and identify the specific error in the second error that occurred first in the call relationship and triggered the other errors as the cause. According to one embodiment, the occurrence time information of each error in the second attribute information can be confirmed, and the first error in the second error can be identified as the specific error, and the specific error can be identified as the cause of the first error. According to another embodiment, based on whether at least a portion of the API path, input parameters, occurrence time, and type information in the second attribute information has call dependencies, a call tree can be generated by understanding the call relationships between them. The specific error at the top of the call tree is then identified as the cause of the first error. Refer to FIG3 for an embodiment of the above scenario.

FIG3 is an exemplary diagram showing the call relationship between the first error and the second error related thereto according to an embodiment.

3 , it can be confirmed that the first error occurred at 14:45:28 on September 21. If the first attribute information of the first error is obtained, the server 100 can confirm the second attribute information 310 and 320 of the second error related to the first error as described above. Based on the first attribute information 110 and the second attribute information 310 and 320, all trace IDs are the same: A3547D58. This indicates that the earlier of the first and second errors, occurring at 2:45:11 PM (corresponding to 310), is call-dependent. However, the later of the second errors (corresponding to 320) is not call-dependent and is confirmed to have occurred the fastest. In this case, the specific error that caused the first error can be confirmed to be the error corresponding to 320.

Furthermore, according to one embodiment, the server 100 can confirm the specific resource information corresponding to the specific error based on the analysis object information further including the second resource information. Furthermore, the server 100 can additionally confirm as a reference factor a specific service that generates resources exceeding a critical value before the specific error occurs based on the specific resource information. Here, the critical value can be set as the CPU, memory, or network usage set on the system, which is the amount that may cause a burden on the server. Furthermore, for a specific time range before the specific error occurs, the specific service described above can be explored. As described above, by confirming as a reference factor the specific service that caused a burden on the server before the specific error occurs.

The following describes an embodiment in which it is determined that the first error does not have call dependency. According to one embodiment, when the first error is determined to not have call dependency, the first resource information corresponding to the occurrence of the first error can be selected as the analysis target information from the computing resource-related data of the first server included in the resource history information. If the type information of the first error indicates a database-related error, such as a database access error, resource information corresponding to the database associated with the corresponding first service server and performing operations can also be selected as the first resource information along with the resource information of the first service server. According to one embodiment, the first resource information described above may also be selected as analysis target information.

Afterward, according to one embodiment, server 100 can identify the first error as the cause. That is, it can be confirmed that the first error itself is a problem, and not caused by the chained structure of service calls. Furthermore, based on the first resource information, server 100 can additionally identify the specific service that generated resources exceeding the critical value as a reference factor. Similar to the reference factor identification process described above when the first error is call-dependent, specific services that placed a burden on the server before the first error occurred can be identified as reference factors.

As described above, according to one embodiment, if the cause is determined based on whether or not there is call dependency, server 100 can generate and transmit cause report information to the administrator terminal based on at least a portion of the analysis target information. Specifically, since analysis target information has been extracted from error history DB 300 and resource history DB 400, report information on the determined cause can be generated and transmitted to the administrator terminal based on at least a portion of the analysis target information described above.

According to one embodiment, the report information may be generated based on attribute information of a cause and resource information of a situation in which the cause occurs, wherein the attribute information of the cause and the resource information of the situation in which the cause occurs are confirmed based on at least a portion of the error history information and the resource history information. According to one embodiment, when the first error is not call-dependent, the report information may include the first attribute information of the first error, i.e., at least a portion of the error tracking ID, occurrence time, input parameters, service name, API path, IP address, error message, exception handling method, and type information. It may also include the first resource information of the first error, i.e., information such as the CPU, memory, and network data of the first service server at the time the first error occurred.

According to one embodiment, when the first error has a call dependency, the report information can be further generated based on the call relationship between the cause and the first error. That is, based on the call relationship between the cause and the first error, information about the services and API paths affected by the cause can be included. To maintain a unified format, even when there is no call dependency, the report information can include information about the affected services and API paths (but the service names and API paths included in the first attribute information are the same). Refer to Figure 4 for an example of this scenario.

FIG4 is an example diagram of report information according to an embodiment.

As described above with reference to FIG. 4 , the report information may include at least a portion of the first attribute information, namely, the occurrence time (timestamp), input parameters (input), service name (Error Cause Service), API path (Error Cause API), IP address (Error Cause Host IP), and error type information (Error Cause Reason). Furthermore, the report information may include information about affected services (Impacted Services), affected API paths (Impacted APIs), and resource information (Error Cause Infrastructure Metrics Data). In this case, as an example of generating report information based on the example in Figure 3, as described above, the cause is an error in service 230. Therefore, most of the content is generated based on the attribute information and resource information of service 230, and the affected services and affected API paths may include all content of services 210, 220, and 230.

According to one embodiment, when the cause type information indicates a database error, the report information can be further generated based on the calculated resource-related data of the database associated with the cause at the time the cause occurred, that is, the first or second resource information selected above. In other words, the corresponding data can also be included in the report information.

According to one embodiment, when the aforementioned reference factor has been confirmed, report information can be generated based on the attribute information of the reference factor and the relationship information between the reference factor and the cause. Specifically, since the reference factor is a service, it may store information similar to the attribute information of the aforementioned error. Therefore, the report information can further include information such as the reference factor's tracking ID, service execution time, input parameters, service name, API path, and IP address. Furthermore, the relationship information between the cause and the reference factor can also be included in the report information. For example, numerical information such as the difference in occurrence/execution time between the cause and the reference factor, as well as information such as whether the reference factor is a preceding service for which the cause was the cause, can be included.

According to one embodiment, when the first error described above occurs, the hourly frequency information of the specific error identified as the cause of the first error is confirmed. A report is transmitted to the administrator terminal only when the hourly frequency information exceeds a critical value, rather than immediately transmitting the report to the administrator terminal. Because errors are often resolved automatically due to other factors such as load reduction, administrator calls are only made in critical situations where they cannot be resolved automatically.

According to one embodiment, the report information may further include information on at least one attention error identified as the most common cause within a specified time period. For example, information may be included on the top 10 attention errors identified as the most common causes. The above-described order can be derived based on error type information or by the services that caused the errors. See Figures 5a and 5b for a more detailed description of the various embodiments described above.

FIG5a and FIG5b are diagrams illustrating examples of error-noticing information in various embodiments.

First, it can be seen that Figure 5a illustrates an example of deriving attention errors based on error type information and selecting them in order of the number of times they were identified as the cause. In the example of Figure 5a, it can be seen that Call Dependency Internal Error caused the most errors, with 164, followed by Call Dependency Timeout, with 85. If other errors occur, as described above, server 100 can report the error type with the highest number of errors as the cause to the administrator as an attention error.

Next, Figure 5b shows an example of a scenario where attention errors are generated for each service and selected in order of the number of times they were identified as a cause. In the example of Figure 5b, it can be confirmed that service 230 caused the most errors, with 147, followed by service ZZZ, and then AAA. Information about these attention errors can be included in the report information.

The report information described above can be transmitted to a portion of administrator terminals selected from the administrators. That is, according to one embodiment, it can be transmitted only to the administrator terminal responsible for the service server that is the cause of the corresponding failure, or it can be transmitted to the administrator terminals responsible for all corresponding servers of all affected services.

FIG6 is a block diagram showing a server according to an embodiment.

According to one embodiment, server 100 may include memory 101 and processor 103. The server 100 shown in FIG6 only illustrates components relevant to this embodiment. Therefore, those skilled in the art will understand that, in addition to the components shown in FIG6 , other common components may be included. In one embodiment, processor 103 may include a controller.

Processor 102 controls the overall operation of server 100 and processes data and signals. Processor 102 may be configured as at least one hardware unit. Furthermore, processor 102 may operate by executing one or more software modules generated by program code stored in memory 101. Processor 102 may include memory and execute program code stored in the memory to control the overall operation of server 100 and process data and signals.

The processor 102 may be configured as follows: confirming a first error occurring in a first service server, which is one of a plurality of service servers that perform service calls with each other; determining whether the first error is call-dependent based on type information of the first error; selecting at least a portion of error history information and resource history information of the plurality of service servers as analysis target information based on whether the first error is call-dependent; and confirming a cause of the first error based on the analysis target information.

According to an embodiment, the server 100 may additionally include a transceiver for implementing wired/wireless communication. The server 100 may utilize the transceiver to communicate with an external electronic device. The external electronic device may be a terminal or a server. Furthermore, the communication technologies utilized by the transceiver may include GSM (global system for mobile communication), CDMA (code division multiple access), LTE (long term evolution), 5G (5th Generation Mobile Communication Technology), WLAN (wireless LAN), Wi-Fi (wireless-fidelity), Bluetooth™, RFID (radio frequency identification), infrared data association (IrDA), ZigBee, and NFC (near field communication).

The electronic device or terminal of the above-described embodiment may include a processor, a memory for storing and executing program data, a permanent storage such as a disk drive, a communication port for communicating with external devices, and a purchaser interface device such as a touch panel, keys, or buttons. The method implemented by the software module or algorithm may be stored on a computer-readable recording medium as computer-readable code or program commands executable on the processor. Here, computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disks, hard disks, etc.) and optical readable media (e.g., compact disc read-only memory (CD-ROM) and digital versatile discs (DVD)). Computer-readable recording media are distributed across computer systems connected to a network, enabling the storage and execution of computer-readable code in a distributed manner. The media can be read by the computer, stored in memory, and executed by the processor.

The present embodiment may be represented by a functional block structure and various processing steps. These functional blocks may be implemented by a different number of hardware and/or software components that perform specific functions. For example, the embodiment may be implemented using an integrated circuit structure that can perform various functions, such as memory, processing, logic, look-up tables, etc., under the control of one or more microprocessors or other control devices. Components may be implemented by software programs or software components. Similarly, the present embodiment includes algorithms implemented as a combination of data structures, programs, routines, or other program structures, and thus may be implemented using programming or scripting languages such as C, C++, Java, and assemblers. Functionally, this can be achieved through algorithms executed on one or more processors. Furthermore, this embodiment can utilize existing technologies for electronic environment configuration, signal processing, and/or data processing. Terms such as "mechanism," "element," "mechanism," and "configuration" are used broadly and are not limited to mechanical or physical configurations. These terms can be associated with processors and the like and include software routines.

The above embodiment is merely an example, and other embodiments may be implemented within the scope of the invention application described below.

100: Server 101: Memory 102: Processor 110: First attribute information 210: Service server 220: Service server 230: Service server 240: Service database 300: Error history database 310: Second attribute information 320: Second attribute information 400: Resource history database S210: Step S220: Step S230: Step S240: Step

Figure 1 shows a server and its associated relationships for error analysis according to one embodiment. Figure 2 is a flow chart illustrating an error analysis method according to one embodiment. Figure 3 is an example diagram illustrating the call relationship between a first error and its associated second error according to one embodiment. Figure 4 is an example diagram illustrating report information according to one embodiment. Figures 5a and 5b are examples of error information according to various embodiments. Figure 6 is a block diagram illustrating a server according to one embodiment.

100: Server 210: Service Server 220: Service Server 230: Service Server 240: Service DB 300: Error History DB 400: Resource History DB

Claims (20)

An error analysis method, performed by a server, comprises the following steps: Identifying a first error occurring in a first service server, the first service server being one of a plurality of service servers that are engaged in a service call; Determining whether the first error has call dependency based on type information of the first error; Based on whether the first error has call dependency, selecting at least a portion of error history information and resource history information of the plurality of service servers as analysis target information; and Identifying a cause of the first error based on the analysis target information. In the error analysis method of claim 1, the step of selecting the above-mentioned analysis object information is to select the following two types of information as the above-mentioned analysis object information if it is confirmed that the above-mentioned first error has the above-mentioned call dependency: (i) second attribute information of at least one second error, which is the attribute information of multiple errors included in the above-mentioned error history information based on the above-mentioned first error; and (ii) second resource information of at least a portion of the second error, which is computing resource-related data of a second service server where the second error occurs, corresponding to the occurrence of at least a portion of the second error, the computing resource-related data being included in the resource history information. The error analysis method of claim 2, wherein the first attribute information includes at least a portion of the tracking ID, occurrence time, input parameters, API path, server IP address, exception handling method, error message, and the type information of the first error. The error analysis method of claim 2, wherein the second error is selected by calculating the similarity between at least a portion of the attribute information of the plurality of errors and at least a portion of the first attribute information, and confirming that the similarity is above a critical value. As in the error analysis method of claim 2, the step of confirming the above-mentioned cause is based on at least a part of the above-mentioned second attribute information, deriving the call relationship between the above-mentioned first and second errors, and analyzing the above-mentioned call relationship, and confirming the specific error in the above-mentioned second error that occurs first in the above-mentioned call relationship and induces other errors as the above-mentioned cause. As in the error analysis method of claim 5, the step of confirming the above-mentioned cause is to additionally confirm as a reference factor a specific service of a resource that generated a critical value before the above-mentioned specific error occurred, and the specific service is confirmed based on specific resource information corresponding to the above-mentioned specific error, and the specific resource information is at least a part of the above-mentioned second resource information. In the error analysis method of claim 1, the step of selecting the analysis target information comprises, when it is determined that the first error does not have the call dependency, selecting, from the computing resource-related data of the first service server included in the resource history information, the first resource information corresponding to the occurrence of the first error as the analysis target information; The step of determining the cause comprises determining the first error as the cause. In the error analysis method of claim 7, the step of confirming the cause information is to additionally confirm a specific service of a resource that generated a critical value before the occurrence of the first error as a reference factor, and the specific service is confirmed based on the first resource information. The error analysis method of claim 1 further includes the following steps: Based on at least a portion of the analysis target information, generating report information indicating the cause and transmitting it to a management terminal. As in claim 9, the error analysis method, wherein the report information is generated based on the attribute information of the cause and the resource information of the occurrence of the corresponding cause, and the attribute information and the resource information of the occurrence of the corresponding cause are confirmed based on the error history information and at least a portion of the resource history information. In the error analysis method of claim 10, if it is determined based on the type information that the first error has the call dependency, the report information is further generated based on the call relationship between the cause and the first error. In the error analysis method of claim 10, when the type information of the cause indicates a database error, the report information is further generated based on computing resource-related data of the database related to the cause at the time when the corresponding cause occurred. For example, in the error analysis method of claim 10, when additional reference factors are identified in addition to the aforementioned causes, the aforementioned report information is further generated based on the attribute information of the aforementioned reference factors and the relationship information between the aforementioned reference factors and the aforementioned causes. In the error analysis method of claim 9, information on the number of times per hour that the specific error that is the cause of the first error is confirmed as the cause is transmitted to the management terminal only when the number of times per hour exceeds a critical value. The error analysis method of claim 14, wherein the report information further includes information on at least one attention error identified as the most common cause within a specified time period. The error analysis method of claim 1, wherein the error history information includes attribute information of errors occurring on each service server in chronological order of the errors, and errors that occurred more than a threshold amount of time after their occurrence are deleted from the error history information. The error analysis method of claim 1, wherein the resource history information includes data obtained by recording at least a portion of the CPU, memory, and network data of each service server according to a specified period. As in the error analysis method of claim 17, the resource history information further includes recording the CPU, memory, network data of the database at a specified period, and data obtained from at least a portion of the data requests received by the database, and the database is linked to at least a portion of the service servers to perform operations. A non-transitory computer-readable recording medium records a program for executing the method of any one of claims 1 to 18 on a computer. A server for analyzing errors includes a memory for storing commands and a processor configured as follows: Connected to the memory, the processor identifies a first error occurring in a first service server, the first service server being one of a plurality of service servers that are engaged in a service call; based on type information of the first error, determines whether the first error is call-dependent; based on whether the first error is call-dependent, selects at least a portion of error history information and resource history information of the plurality of service servers as analysis target information; and identifies a cause of the first error based on the analysis target information.