CN111901140A - Exception handling method and device, electronic equipment and storage medium - Google Patents
Exception handling method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN111901140A CN111901140A CN202010530993.9A CN202010530993A CN111901140A CN 111901140 A CN111901140 A CN 111901140A CN 202010530993 A CN202010530993 A CN 202010530993A CN 111901140 A CN111901140 A CN 111901140A
- Authority
- CN
- China
- Prior art keywords
- request
- product line
- abnormal
- alarm
- exception
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000002159 abnormal effect Effects 0.000 claims abstract description 177
- 230000015654 memory Effects 0.000 claims description 19
- 238000012545 processing Methods 0.000 claims description 17
- 230000000977 initiatory effect Effects 0.000 claims description 7
- 238000012216 screening Methods 0.000 abstract description 10
- 238000013024 troubleshooting Methods 0.000 abstract description 8
- 230000004044 response Effects 0.000 description 17
- 238000001514 detection method Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000011835 investigation Methods 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000007670 refining Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
- H04L41/0609—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time based on severity or priority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
The application discloses an exception handling method and device, electronic equipment and a storage medium, and relates to the field of cloud computing. The specific implementation scheme is as follows: acquiring an abnormal request; when a pre-configured public abnormal alarm strategy is adopted to detect that a received abnormal request does not belong to an abnormal alarm request of public service logic, a product line identifier corresponding to the abnormal request is obtained; and based on the product line identification, when a pre-loaded and corresponding private abnormity alarm strategy of the product line is adopted to detect that an abnormity request belongs to an abnormity alarm request of the product line, alarming is carried out based on the abnormity request. The method and the device can refine the screening granularity of the abnormal alarm request, effectively remove the abnormal requests which are in expectation of each product line and do not need to be concerned, and only screen the abnormal alarm request of each product line, namely, the abnormal requests which need to be alarmed can be effectively screened, so that the subsequent invalid alarms can be reduced, the accurate positioning of abnormal troubleshooting is facilitated, and the efficiency of the abnormal troubleshooting of the product lines is improved.
Description
Technical Field
The present application relates to computer technologies, and in particular, to the field of cloud computing, and in particular, to an exception handling method and apparatus, an electronic device, and a storage medium.
Background
In the prior art, when a front-end browser and an Application Programming Interface (API) gateway detect an abnormal request, the abnormal request is reported to a cloud. And after receiving the abnormal requests reported by the front-end browser and the API gateway in real time, the cloud detects whether the abnormal requests reach the abnormal requests of the alarm level according to a preset abnormal filtering strategy, and if so, the cloud initiates an alarm.
In the prior art, considering the complexity of the cloud service, the coupling degree of the exception filtering strategy pre-configured in the cloud and the code is very high, and only the detection of a general exception request can be realized, so that the screening granularity is too coarse, more exceptions which are expected and do not need to be paid attention are detected, and more invalid alarms are further generated, thereby seriously affecting the efficiency of exception troubleshooting of a product line.
Disclosure of Invention
In order to solve the technical problem, the application provides an exception handling method, an exception handling device, an electronic device and a storage medium.
According to an aspect of the present disclosure, there is provided an exception handling method, which is applied in a cloud, the method including:
acquiring an abnormal request;
when a pre-configured public abnormal alarm strategy is adopted to detect that a received abnormal request does not belong to an abnormal alarm request of public service logic, a product line identifier corresponding to the abnormal request is obtained;
and based on the product line identification, when a pre-loaded private abnormity alarm strategy of the corresponding product line is adopted to detect that the abnormity request belongs to the abnormity alarm request of the product line, alarming is carried out based on the abnormity request.
According to another aspect of the present disclosure, there is provided an exception handling apparatus, the apparatus being disposed in a cloud, including:
the request acquisition module is used for acquiring an abnormal request;
the system comprises a product line acquisition module, a product line identification acquisition module and a service line identification acquisition module, wherein the product line acquisition module is used for acquiring a product line identification corresponding to an abnormal request when detecting that the received abnormal request does not belong to the abnormal alarm request of the public service logic by adopting a pre-configured public abnormal alarm strategy;
and the alarm module is used for alarming based on the abnormal request when the private abnormal alarm strategy of the corresponding product line loaded in advance is adopted to detect that the abnormal request belongs to the abnormal alarm request of the product line based on the product line identification.
According to still another aspect of the present disclosure, there is provided an electronic device including:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described above.
According to yet another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method as described above.
According to the technology of the application, the screening granularity of the abnormal alarm request can be refined, the abnormal request which is in the expectation of each product line and does not need to be paid attention is effectively removed, and only the abnormal alarm request of each product line is screened, namely the abnormal request which needs to be alarmed can be effectively screened, so that the subsequent invalid alarm can be reduced, the accurate positioning of the abnormal investigation is facilitated, and the efficiency of the abnormal investigation of the product lines is improved.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:
FIG. 1 is a schematic diagram according to a first embodiment of the present application;
FIG. 2 is a schematic diagram according to a second embodiment of the present application;
FIG. 3 is a schematic illustration according to a third embodiment of the present application;
FIG. 4 is a schematic illustration according to a fourth embodiment of the present application;
fig. 5 is a block diagram of an electronic device for implementing an exception handling method according to an embodiment of the present application.
Detailed Description
The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
FIG. 1 is a schematic diagram according to a first embodiment of the present application; as shown in fig. 1, the present embodiment provides an exception handling method, which is applied in a cloud, and specifically includes the following steps:
s101, acquiring an abnormal request;
s102, when a pre-configured public abnormal alarm strategy is adopted to detect that a received abnormal request does not belong to an abnormal alarm request of public service logic, a product line identifier corresponding to the abnormal request is obtained;
s103, based on the product line identification, when the preloaded private abnormity alarm strategy of the corresponding product line is adopted to detect that the abnormity request belongs to the abnormity alarm request of the product line, alarming is carried out based on the abnormity request.
The execution main body of the exception handling method of the embodiment is an exception handling device, and the exception handling device is arranged at the cloud end so as to realize the handling of the exception request at the cloud end.
In this embodiment, two types of abnormal alarm strategies are configured in the cloud. One is a public abnormal alarm strategy, which does not distinguish product line services, and all product line requests are applicable. And the other type of private abnormity alarm strategy is configured for each product line, and the private abnormity alarm strategy applicable to only the product line can be configured based on the characteristics of each product line so as to realize the detection of the individualized abnormity alarm request of the product line.
Specifically, in this embodiment, the exception request received by the exception handling apparatus may be an exception request sent by a front-end browser, an API gateway, or a server. For example, after receiving a request, a front-end browser, an API gateway, or a server may determine whether the request is a normal request or an abnormal request by detecting a response status code in the request, and if the request is an abnormal request, further report the abnormal request to the cloud, and an abnormal processing device in the cloud receives the abnormal request and further processes the abnormal request.
In this embodiment, for any one of the exception requests received by the exception handling apparatus, a pre-configured public exception alert policy may be first adopted to detect whether the received exception request belongs to an exception alert request of a public service logic. That is to say, the public abnormal alarm policy is used for screening abnormal requests of the public service logic which can reach the alarm level, and for abnormal alarm requests which do not belong to the public service logic, the abnormal requests which are in expectation and can not be concerned are considered to belong to, and alarm processing is not needed subsequently. For example, the common exception alarm policy may implement detection of common exception alarm requests, such as a static resource loading failure or a user identity verification failure. For example, a static resource loading failure may be characterized in a response parameter in the exception request, for example, the response parameter in the exception request at this time may be: { "success": false "," message ": Resource not found." }. When the user identity is checked incorrectly, the response parameters in the corresponding abnormal request may be: { "success": false, "message": Access subscribed. Similarly, by using the public exception alarm policy of this embodiment, exception requests of other public service logics that reach the alarm level in all product lines can be screened, which is not described in detail herein for example.
If the received abnormal request is determined not to belong to the abnormal alarm request of the public service logic after the detection of the step S102, the product line identifier corresponding to the abnormal request can be further obtained. And further adopting step S103 to detect whether the abnormal request belongs to the abnormal alarm request of the product line by adopting a pre-loaded and corresponding private abnormal alarm strategy of the product line based on the product line identification, realizing secondary detection of the abnormal request, refining the screening granularity of the abnormal alarm request, accurately screening the abnormal request needing to be alarmed, and improving the screening efficiency. In step S103, when an abnormality alarm request is detected that the abnormality request belongs to a product line, an alarm is given based on the abnormality request. In this embodiment, the private anomaly alarm policy of the plurality of product lines is obtained and loaded in advance, so that the private anomaly alarm requests of the product lines can be detected, the anomaly requests which are in expectation of the product lines and do not need to be paid attention to are removed, only the anomaly requests which need to be paid attention to, that is, the anomaly requests which need to be alarmed are detected, the invalid alarm can be reduced, and the efficiency of troubleshooting the anomaly of the product lines is improved.
In the exception handling method of the embodiment, an exception request is obtained; when a pre-configured public abnormal alarm strategy is adopted to detect that a received abnormal request does not belong to an abnormal alarm request of public service logic, a product line identifier corresponding to the abnormal request is obtained; based on the product line identification, when the preloaded private abnormity alarm strategy of the corresponding product line is adopted to detect that the abnormity request belongs to the abnormity alarm request of the product line, the alarm is carried out based on the abnormity request, and two-stage detection on the abnormity request can be realized at the cloud end.
FIG. 2 is a schematic diagram according to a second embodiment of the present application; the exception handling method of this embodiment further describes the technical solution of the present application in more detail on the basis of the technical solution of the embodiment shown in fig. 1. As shown in fig. 2, the exception handling method of this embodiment may specifically include the following steps:
s201, collecting public service logic information on each product line;
s202, configuring a public abnormal alarm strategy based on public service logic information of each product line;
the step S201 and the step S202 implement configuration of a common anomaly alarm policy. Specifically, in the configuration process, the common service logic information of all product lines can be searched with reference to the common service logic information of each product line, so as to configure the common abnormal alarm strategy. Optionally, in the configuration process, the preset service logic information of each product line that does not need to be alarmed and the service logic information that needs to be alarmed can be referred to accurately configure the public abnormal alarm policy, so that the public abnormal alarm policy can screen out the abnormal request of the abnormal public logic information that needs to be alarmed, and filter out the abnormal request of the abnormal public logic information that does not need to be alarmed.
S203, receiving a private abnormity alarm strategy configured for each product line;
s204, loading a private abnormity alarm strategy configured for each product line;
specifically, the private exception alarm policy configured for each product line may be dynamically configured based on the traffic of each product line. For example, the data can be configured by a research and development staff of each product line through a computer and sent to the cloud, and received by an exception handling device of the cloud and loaded into the cache, so as to be effective. The private exception alarm strategy configured for each product line is only configured with the characteristic that the exception request required to be alarmed on the product line conforms to, and during configuration, the private exception alarm strategy can be configured by referring to the service characteristic of the product line, the invalid exception request and the valid exception request of the product line, so that the private exception alarm strategy configured for the configured product line can filter the invalid exception request of the product line, only screen out the valid exception request of the product line, and facilitate subsequent alarming. The invalid abnormal request is an abnormal request which is within expectation, does not need attention and does not need alarming; the effective abnormal request is an unexpected abnormal request which needs attention and an alarm.
Optionally, the loading process may be periodically loaded, for example, once every one minute, two minutes, or other time length, that is, the private exception alarm policy of each product line is periodically loaded, so that the dynamically configured private exception alarm policy of each product line can be timely loaded to be effective. Of course, optionally, the loading may also be performed in real time after the private exception warning policy configured for each product line is configured.
In addition, the private exception alert policy configured for each product line in this embodiment may be established based on information of at least one dimension of a request mode, a request address, a request parameter, a request identity, a response parameter, and a response state. The specific private exception alarm policy includes information about which dimensions, and needs to be set with reference to specific services of the product line.
The public exception alarm policy and the private exception alarm policy of each product line in this embodiment may be configured based on information of at least one dimension of a request mode, a request address, a request parameter, a request identity, a response parameter, a response state, and the like.
The request mode refers to a standard Hypertext transfer protocol (Http) request mode, and may specifically include GET, POST, PUT, DELETE, and the like. The request address refers to the standard Http request address. The request parameter of the embodiment also refers to a standard Http request parameter, and may include a query parameter, such as param1 value1, a header parameter, such as content-type application/json, a body parameter, such as { "request", "demo", and so on. The request identity refers to a string that uniquely identifies the user identity, e.g., AccountId: e1dd29ib9c8e 6. The response status code is used to identify the exception status of the exception request, such as 200, 400, 500, or 4xx, 5xx, etc. may identify the response status code of the exception request. In practical application, the setting can be carried out according to specific scenes. The response parameter is used for characterizing the response entity, and specifically, similar to a Json format such as { "success": false }, an abnormal reason of the abnormal request can be specifically identified in the response parameter.
It should be noted that the above steps are all accurate work of exception handling, and may be performed offline. Wherein the configured common exception alert policy may be solidified in the code. And the private abnormity alarm strategy configured by each product line can be configured and dynamically recorded in real time so as to meet the service requirements of different product lines, and the use is very flexible.
S205, detecting whether the received abnormal request belongs to an abnormal alarm request of public service logic by adopting a pre-configured public abnormal alarm strategy; if yes, go to step 206; otherwise, go to step S208;
it should be noted that the exception request of this embodiment may include information such as a request mode, a request address, a request parameter, a request identity, a response parameter, and a response status. And the public abnormal alarm strategy is configured based on the information of at least one dimension of the request mode, the request address, the request parameter, the request identity, the response parameter and the response state, so that whether the abnormal request belongs to the abnormal alarm request of the public service logic or not can be detected based on the public abnormal alarm strategy.
S206, acquiring an exception handling group identifier of the public service logic; step S207 is executed;
s207, based on the abnormal processing group mark of the public service logic, an alarm prompt message of the abnormal request is initiated to inform all people in the abnormal processing group of the public service logic that the abnormal alarm request of the public service logic occurs, and the operation is finished.
In this embodiment, an exception handling group of a common service logic may be preconfigured, and the group may include at least one principal of each product line. When the abnormal request is the abnormal alarm request of the public service logic, the abnormal request alarm prompt message can be directly sent to the abnormal processing group of the public service logic to inform all persons in the abnormal processing group of the public service logic that the abnormal alarm request of the public service logic occurs, and the person in charge of each product line is used for respectively checking the abnormal request, so that the abnormal request checking efficiency is improved.
S208, acquiring a product line identifier corresponding to the abnormal request; step S209 is executed;
specifically, the exception request may indicate that there is product line identification information, and a product line identification corresponding to the exception request is obtained according to the product line identification information in the exception request. And further, based on the representation of the product line, obtaining the private abnormity alarm strategy of the product line from the pre-loaded private abnormity alarm strategies of each product line.
S209, detecting whether the abnormal request belongs to the abnormal alarm request or not by adopting a pre-loaded and corresponding private abnormal alarm strategy of the product line based on the product line identifier; if yes, go to step S210; otherwise, determining that the received abnormal request does not need to be subjected to alarm processing, and ending.
S210, acquiring a contact way of a product line principal based on a corresponding relation between a pre-established product line identifier and a corresponding product line principal contact way; step S211 is executed;
and S211, based on the contact way of the product line responsible person, initiating an alarm prompt message of the abnormal request to inform the product line responsible person, and ending.
That is to say, for the determined abnormal alarm request of a certain product line, an alarm prompt message can be directly sent to the responsible person of the product line to prompt the responsible person of the product line that the abnormal alarm occurs on the product line and needs to be checked in time, so that the abnormal request can be accurately positioned by the scheme, and the efficiency of checking the abnormal condition of the product line is improved.
By adopting the technical scheme, the exception handling method of the embodiment can realize two-stage detection on the exception request at the cloud end, refine the screening granularity of the exception alarm request, effectively remove the exception requests which are in expectation of each product line and do not need to be concerned, and only screen out the exception alarm request of the public service logic and the exception alarm request of each product line, namely effectively screen out the exception request needing to be alarmed; and further, alarm processing is carried out based on different abnormal alarm requests, so that invalid alarms can be reduced, accurate positioning of abnormal request troubleshooting can be facilitated, and the efficiency of abnormal troubleshooting of a product line is improved.
FIG. 3 is a schematic illustration according to a third embodiment of the present application; as shown in fig. 3, the present embodiment provides an exception handling apparatus 300, which is disposed in a cloud, and includes:
a request obtaining module 301, configured to obtain an exception request;
a product line obtaining module 302, configured to obtain a product line identifier corresponding to an exception request when a pre-configured public exception alarm policy is used to detect that a received exception request belongs to an exception alarm request of a public service logic;
and the alarm module 303 is configured to alarm based on the exception request when detecting that the exception request belongs to the exception alarm request of the product line by using the preloaded private exception alarm policy of the corresponding product line based on the product line identifier.
The exception handling apparatus 300 of this embodiment, which implements the exception handling principle and technical effect by using the modules, is the same as the implementation of the related method embodiment, and reference may be made to the description of the related method embodiment in detail, which is not repeated herein.
FIG. 4 is a schematic illustration according to a fourth embodiment of the present application; as shown in fig. 4, the exception handling apparatus 300 of the present embodiment further describes the technical solution of the present application in more detail on the basis of the technical solution of the embodiment shown in fig. 3.
In the exception handling apparatus 300 of this embodiment, the alarm module 303 is further configured to alarm based on the exception request when detecting that the received exception request belongs to an exception alarm request of a common service logic by using a pre-configured common exception alarm policy.
Further optionally, the alarm module 303 is specifically configured to:
acquiring an exception handling group identifier of public service logic;
and based on the abnormal processing group identification of the public service logic, initiating an alarm prompt message of the abnormal request to inform all people in the abnormal processing group of the public service logic that the abnormal alarm request of the public service logic occurs.
Further optionally, as shown in fig. 4, the exception handling apparatus 300 of this embodiment further includes:
the acquisition module 304 is used for acquiring the public service logic information on each product line;
and a configuration module 305, configured to configure a common exception alarm policy based on the common service logic information of each product line.
Further optionally, as shown in fig. 4, the exception handling apparatus 300 of this embodiment further includes:
the policy obtaining module 306 is configured to obtain the private anomaly alarm policy of the product line corresponding to the product line identifier according to the preloaded private anomaly alarm policies of each product line and the corresponding relationship between the product line identifier and the private anomaly alarm policy.
Further optionally, as shown in fig. 4, the exception handling apparatus 300 of this embodiment further includes:
a receiving module 307, configured to receive a private exception alarm policy configured for each product line;
and the loading module 308 is used for periodically loading the private exception alarm strategies of each product line.
Further optionally, in the exception handling apparatus 300 of this embodiment, the alarm module 303 is specifically configured to, when the exception request belongs to an exception alarm request of a product line, obtain a contact address of a product line person in charge based on a correspondence between a pre-established identifier of the product line and a corresponding contact address of a product line person in charge; and based on the contact way of the product line responsible person, initiating an alarm prompt message of the abnormal request to inform the product line responsible person.
The exception handling apparatus 300 of this embodiment, which implements the exception handling principle and technical effect by using the modules, is the same as the implementation of the related method embodiment, and reference may be made to the description of the related method embodiment in detail, which is not repeated herein.
According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.
Fig. 5 is a block diagram of an electronic device according to an exception handling method according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.
As shown in fig. 5, the electronic apparatus includes: one or more processors 501, memory 502, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 5, one processor 501 is taken as an example.
The memory 502, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules (e.g., related modules shown in fig. 3 and 4) corresponding to the exception handling method in the embodiments of the present application. The processor 501 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 502, that is, implements the exception handling method in the above-described method embodiment.
The memory 502 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the electronic device of the exception handling method, and the like. Further, the memory 502 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, memory 502 optionally includes memory located remotely from processor 501, which may be connected via a network to an electronic device implementing the exception handling method. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The electronic device implementing the exception handling method may further include: an input device 503 and an output device 504. The processor 501, the memory 502, the input device 503 and the output device 504 may be connected by a bus or other means, and fig. 5 illustrates the connection by a bus as an example.
The input device 503 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the electronic apparatus implementing the exception handling method, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, a pointing stick, one or more mouse buttons, a track ball, a joystick, or other input devices. The output devices 504 may include a display device, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
According to the technical scheme of the embodiment of the application, whether the received abnormal request belongs to the abnormal alarm request of the public service logic is detected by adopting a pre-configured public abnormal alarm strategy; if not, acquiring a product line identifier corresponding to the abnormal request; based on the product line identification, the method detects whether the abnormal request belongs to the abnormal alarm request of the product line by adopting the pre-loaded and corresponding private abnormal alarm strategy of the product line, can realize two-stage detection on the abnormal request at the cloud end, can refine the screening granularity of the abnormal alarm request, effectively removes the abnormal request which is in expectation of each product line and does not need to be concerned, and only screens the abnormal alarm request of the public service logic and the abnormal alarm request of each product line, namely can effectively screen the abnormal request which needs to be alarmed, further can reduce subsequent invalid alarm, is convenient for accurately positioning the abnormal investigation, and improves the efficiency of the abnormal investigation of the product line.
According to the technical scheme of the embodiment of the application, two-stage detection on the abnormal requests can be realized at the cloud end, the screening granularity of the abnormal alarm requests is refined, the abnormal requests which are in expectation of each product line and do not need to be concerned are effectively removed, and only the abnormal alarm requests of the public service logic and the abnormal alarm requests of each product line are screened out, namely the abnormal requests needing to be alarmed can be effectively screened out; and further, alarm processing is carried out based on different abnormal alarm requests, so that invalid alarms can be reduced, accurate positioning of abnormal request troubleshooting can be facilitated, and the efficiency of abnormal troubleshooting of a product line is improved.
It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.
The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (16)
1. An exception handling method, which is applied in a cloud terminal, the method comprising:
acquiring an abnormal request;
when a pre-configured public abnormal alarm strategy is adopted to detect that the abnormal request does not belong to an abnormal alarm request of public service logic, a product line identifier corresponding to the abnormal request is obtained;
and based on the product line identification, when a pre-loaded private abnormity alarm strategy of the corresponding product line is adopted to detect that the abnormity request belongs to the abnormity alarm request of the product line, alarming is carried out based on the abnormity request.
2. The method of claim 1, wherein the method further comprises: and adopting a pre-configured public abnormal alarm strategy to detect that the received abnormal request belongs to the abnormal alarm request of the public service logic, and alarming based on the abnormal request.
3. The method of claim 2, wherein when a pre-configured public abnormal alarm strategy is adopted to detect that a received abnormal request belongs to an abnormal alarm request of public service logic, alarming based on the abnormal request comprises:
acquiring an exception handling group identifier of the public service logic;
and initiating an alarm prompt message of the abnormal request based on the abnormal processing group identifier of the public service logic so as to inform all people in the abnormal processing group of the public service logic that the abnormal alarm request of the public service logic occurs.
4. The method of claim 1, wherein before detecting that the received exception request does not belong to an exception alarm request of a common service logic by using a pre-configured common exception alarm policy, the method further comprises:
collecting the logic information of the public service on each product line;
and configuring the public abnormal alarm strategy based on the public service logic information of each product line.
5. The method of claim 1, wherein, based on the product line identifier, before detecting that the exception request belongs to an exception alert request of the product line using a preloaded private exception alert policy of the corresponding product line, further comprising:
and acquiring the private abnormity alarm strategy of the product line corresponding to the product line identification according to the preloaded private abnormity alarm strategy of each product line and the corresponding relation between the product line identification and the private abnormity alarm strategy.
6. The method according to claim 5, wherein before obtaining the private anomaly alarm policy of the product line corresponding to the product line identifier according to the preloaded private anomaly alarm policy of each product line and the corresponding relationship between the product line identifier and the private anomaly alarm policy, the method further comprises:
receiving a private exception alarm strategy configured for each product line;
and periodically loading the private exception alarm strategies of the product lines.
7. The method of any one of claims 1-6,
based on the product line identification, when a pre-loaded and corresponding private abnormity alarm strategy of the product line is adopted to detect that the abnormity request belongs to the abnormity alarm request of the product line, alarming is carried out based on the abnormity request, and the method comprises the following steps:
acquiring a contact way of a product line person in charge based on a corresponding relation between a pre-established identifier of the product line and a corresponding contact way of the product line person in charge;
and initiating an alarm prompt message of the abnormal request based on the contact way of the product line responsible person so as to inform the product line responsible person.
8. An exception handling apparatus, the apparatus being disposed in a cloud, comprising:
the request acquisition module is used for acquiring an abnormal request;
the system comprises a product line acquisition module, a product line identification acquisition module and a service line identification acquisition module, wherein the product line acquisition module is used for acquiring a product line identification corresponding to an abnormal request when detecting that the received abnormal request does not belong to the abnormal alarm request of the public service logic by adopting a pre-configured public abnormal alarm strategy;
and the alarm module is used for alarming based on the abnormal request when the private abnormal alarm strategy of the corresponding product line loaded in advance is adopted to detect that the abnormal request belongs to the abnormal alarm request of the product line based on the product line identification.
9. The apparatus of claim 8, wherein the alarm module is further configured to alarm based on the exception request when detecting that the received exception request belongs to an exception alarm request of a common service logic by using a pre-configured common exception alarm policy.
10. The apparatus according to claim 9, wherein the alarm module is specifically configured to:
acquiring an exception handling group identifier of the public service logic;
and initiating an alarm prompt message of the abnormal request based on the abnormal processing group identifier of the public service logic so as to inform all people in the abnormal processing group of the public service logic that the abnormal alarm request of the public service logic occurs.
11. The apparatus of claim 8, wherein the apparatus further comprises:
the acquisition module is used for acquiring the public service logic information on each product line;
and the configuration module is used for configuring the public abnormal alarm strategy based on the public service logic information of each product line.
12. The apparatus of claim 8, wherein the apparatus further comprises:
and the strategy acquisition module is used for acquiring the private abnormity alarm strategy of the product line corresponding to the product line identification according to the preloaded private abnormity alarm strategy of each product line and the corresponding relation between the product line identification and the private abnormity alarm strategy.
13. The apparatus of claim 12, wherein the apparatus further comprises:
the receiving module is used for receiving the private abnormity alarm strategies configured for each product line;
and the loading module is used for periodically loading the private exception alarm strategies of the product lines.
14. The apparatus according to any one of claims 8-13, wherein the alarm module is specifically configured to: acquiring a contact way of a product line person in charge based on a corresponding relation between a pre-established identifier of the product line and a corresponding contact way of the product line person in charge;
and initiating an alarm prompt message of the abnormal request based on the contact way of the product line responsible person so as to inform the product line responsible person.
15. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.
16. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010530993.9A CN111901140A (en) | 2020-06-11 | 2020-06-11 | Exception handling method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010530993.9A CN111901140A (en) | 2020-06-11 | 2020-06-11 | Exception handling method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111901140A true CN111901140A (en) | 2020-11-06 |
Family
ID=73206296
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010530993.9A Pending CN111901140A (en) | 2020-06-11 | 2020-06-11 | Exception handling method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111901140A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113204467A (en) * | 2021-05-12 | 2021-08-03 | 北京百度网讯科技有限公司 | Monitoring method, device, equipment and storage medium of online business system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101958803A (en) * | 2010-09-09 | 2011-01-26 | 中兴通讯股份有限公司 | Alarm compression system and method based on communication network |
| US20150304457A1 (en) * | 2012-10-29 | 2015-10-22 | Tencent Technology (Shenzhen) Company Limited | Method, System And Device For Monitoring Data |
| CN108833188A (en) * | 2018-07-17 | 2018-11-16 | 顺丰科技有限公司 | A kind of warning message management method, device, equipment and storage medium |
| CN108989132A (en) * | 2018-08-24 | 2018-12-11 | 深圳前海微众银行股份有限公司 | Fault warning processing method, system and computer readable storage medium |
-
2020
- 2020-06-11 CN CN202010530993.9A patent/CN111901140A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101958803A (en) * | 2010-09-09 | 2011-01-26 | 中兴通讯股份有限公司 | Alarm compression system and method based on communication network |
| US20150304457A1 (en) * | 2012-10-29 | 2015-10-22 | Tencent Technology (Shenzhen) Company Limited | Method, System And Device For Monitoring Data |
| CN108833188A (en) * | 2018-07-17 | 2018-11-16 | 顺丰科技有限公司 | A kind of warning message management method, device, equipment and storage medium |
| CN108989132A (en) * | 2018-08-24 | 2018-12-11 | 深圳前海微众银行股份有限公司 | Fault warning processing method, system and computer readable storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113204467A (en) * | 2021-05-12 | 2021-08-03 | 北京百度网讯科技有限公司 | Monitoring method, device, equipment and storage medium of online business system |
| CN113204467B (en) * | 2021-05-12 | 2024-01-30 | 北京百度网讯科技有限公司 | Method, device, equipment and storage medium for monitoring online service system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8914499B2 (en) | Method and apparatus for event correlation related to service impact analysis in a virtualized environment | |
| CN110705461B (en) | Image processing method and device | |
| US20180359184A1 (en) | Out-of-band telemetry data collection | |
| CN111459770A (en) | Server operation state warning method and device, server and storage medium | |
| CN111367698B (en) | Application program flash back detection and processing method and device and electronic equipment | |
| CN111309574B (en) | Information processing method, device and equipment | |
| JP2024521357A (en) | Detecting large-scale faults in data centers using near real-time/offline data with ML models | |
| CN114095522A (en) | Vehicle monitoring method, service system, management terminal, vehicle and storage medium | |
| CN115001967B (en) | Data acquisition method and device, electronic equipment and storage medium | |
| CN111625195A (en) | Method and device for server capacity expansion | |
| CN112016465A (en) | Scene recognition method, device and system | |
| CN110958250B (en) | Port monitoring method and device and electronic equipment | |
| CN111901140A (en) | Exception handling method and device, electronic equipment and storage medium | |
| CN114356699A (en) | Embedded equipment alarm method, device, equipment and storage medium | |
| CN110995687B (en) | Cat pool equipment identification method, device, equipment and storage medium | |
| CN110659184B (en) | Health state checking method, device and system | |
| CN110477866B (en) | Method and device for detecting sleep quality, electronic equipment and storage medium | |
| CN112817686B (en) | Method, device, equipment and computer storage medium for detecting virtual machine abnormality | |
| CN114679295B (en) | Firewall security configuration method and device | |
| CN115102838B (en) | Emergency processing method and device for server downtime risk and electronic equipment | |
| CN116112342A (en) | Alarm information processing method, device, electronic equipment and storage medium | |
| CN115190000B (en) | Alarm data processing method and device, electronic equipment and storage medium | |
| CN111835857B (en) | Method and apparatus for accessing data | |
| CN112104748B (en) | Block chain data supervision method and device, electronic equipment and storage medium | |
| CN103457771A (en) | Method and device for HA virtual machine cluster management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201106 |