Problem detection system

Abstract

To provide a problem detection system, a method, and a medium that identifying a problem for interrupting a process and notifying an affected user of it.SOLUTION: A method includes: monitoring of one or multiple software applications for determining a value of a first metric related to an instance of a first process executed by one or multiple software applications; determination of excess of a threshold related to the first process by a value of the first metric in an instance under progress of a first number in the first process; determination regarding whether a first number is larger than a first count limitation related to the first process; and transmission of an error message to a user related to each of instances under progress in the first process in response to determination that the first number is larger than the first count limitation.SELECTED DRAWING: Figure 1

Description

[[TECHNICAL FIELD]]

[0001] The present invention relates to a problem detection system. [[BACKGROUND ART]]

[0002] Enterprise computing systems facilitate the execution of many processes within an enterprise. Despite best efforts, underlying technical problems can delay or prevent the completion of such processes. Technical problems may reside in different computing systems, may be sudden, or otherwise difficult to monitor and / or detect by the responsible technical support team for other reasons.

[0003] When a process is delayed, stopped, or otherwise malfunctions, an affected user (e.g., the user who initiated the process) creates a support ticket and submits it to the technical support team. A second user may later initiate the same process, eventually notice that the process is not executing properly, and create and submit a second separate support ticket. The support tickets are queued by the support team, and users are notified of the progress of their respective tickets.

[0004] When a process problem results from one or more underlying technical problems (e.g., a malfunction in a network connection), many users are affected and create many support tickets. The large number of tickets can overwhelm the technical support team, which continues to receive and queue new tickets while attempting to identify and resolve the problem. Meanwhile, overall user satisfaction decreases.

[0005] In one example, a company allows employees to submit purchase requests for goods and services necessary for their daily operations. Purchases of any item exceeding a certain amount must be approved by the manager of the employee who created the corresponding purchase request. A recent configuration change has caused the rule that determines an employee's manager based on organizational data to malfunction. Instead of determining the manager, the rule returns an empty result set. Consequently, no approval requests are submitted, and all purchase requests remain unapproved.

[0006] The judgment rules continue to return technically valid results, so technical problems go undetected. Process monitoring solutions may detect an increase in average processing time for purchase request approval, but such detections are not particularly helpful in detecting or triggering the resolution of the underlying technical problem. Therefore, the problem is only detected after multiple employees independently notice unusual delays, check with their managers, ask other colleagues if they have the same problem, and finally create a support ticket. [Overview of the project] [Problems that the invention aims to solve]

[0007] The system should efficiently and proactively identify technical problems that interrupt the operating process and notify affected users while limiting false notifications. [Means for solving the problem]

[0008] A method according to a first embodiment includes the steps of monitoring one or more software applications to determine a value of a first metric associated with an instance of a first process, the monitoring step including the step of the first process being executed by the one or more software applications; determining that the value of the first metric exceeds a threshold associated with the first process in a first number of ongoing instances of the first process; determining that the first number is greater than a first count limit associated with the first process; and sending an error message to a user associated with each of the ongoing instances of the first process in response to the determination that the first number is greater than the first count limit. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram of an architecture for detecting and addressing potential problems in the technology layer by monitoring the application layer, according to several embodiments. [Figure 2] This is a flowchart of a process for detecting and addressing potential problems in the technology layer by monitoring the application layer, according to several embodiments. [Figure 3] This diagram illustrates the monitoring of application processes and the issuance of user notifications over time in several embodiments. [Figure 4] This diagram illustrates the monitoring of application processes and the issuance of user notifications over time in several embodiments. [Figure 5] This diagram illustrates the monitoring of application processes and the issuance of user notifications over time in several embodiments. [Figure 6] This diagram illustrates the monitoring of application processes and the issuance of user notifications over time in several embodiments. [Figure 7]This diagram illustrates the monitoring of application processes and the issuance of user notifications over time in several embodiments. [Figure 8] This figure shows the configuration of metric thresholds for application monitoring according to several embodiments. [Figure 9] This is a block diagram of an architecture for detecting and addressing potential problems in the technology layer by monitoring the application layer and based on user working hours, according to several embodiments. [Figure 10] This is a block diagram of a hardware system according to several embodiments. [Modes for carrying out the invention]

[0010] The following description is provided to enable those skilled in the art to manufacture and use the described embodiments and describes the best modes intended for carrying out several embodiments. However, various modifications will be readily apparent to those skilled in the art.

[0011] The embodiment can reduce the time and effort required to detect technical problems that cause delays or failures in the operational process. By accelerating the detection of such technical problems, the associated notification and resolution processes can be triggered faster than in conventional systems.

[0012] The embodiment can detect a problem, initiate a resolution process in response, and proactively notify the user before they manually create a support ticket. Such features not only reduce user overhead involved in problem detection and accelerate problem resolution, but can also provide support personnel with a quick indication that the problem is likely to be more fundamental, affecting multiple users and processes similarly, rather than being related to a single user-specific process.

[0013] Problem detection in some embodiments may include monitoring processes to identify recurring violations of several process-related metrics. When the number of violations reaches a predefined limit, the affected users and support teams are notified. Furthermore, each subsequent violation of a metric results in a notification to the relevant user. These features allow for the rapid clustering of related violations into a single issue to be analyzed, thereby potentially reducing the effort and redundant work required to resolve the problem.

[0014] Figure 1 is a block diagram of the architecture of system 100 according to several embodiments. Each illustrated element of system 100 may be implemented using any suitable combination of known or to be known computing hardware and / or software. Such combinations may include implementations that flexibly allocate computing resources according to demand, needs, price, and / or any other metrics. In some embodiments, two or more elements of system 100 are implemented by a single computing device. Two or more elements of system 100 may be located in the same location. One or more elements of system 100 may be implemented as a cloud service (e.g., software as a service, platform as a service).

[0015] Generally, system 100 operates to provide functionality to users 132, 134, and 136. Users 132, 134, and 136 access the software implementation logic of applications 112, 114, and 116 to receive this functionality. Applications 112, 114, and 116 may include any software applications that are known or will become known.

[0016] In one non-exhaustive example, applications 112, 114, and 116 include a customer relationship management application, a human resource management application, and a supplier relationship management application operated by a single company. Users 132, 134, and 136 may include employees of the company, and each of users 132, 134, and 136 may be permitted to access one or more of applications 112, 114, and 116. Each of users 132, 134, and 136 may have access to different data via applications 112, 114, and 116 depending on the relative permissions granted to each of users 132, 134, and 136.

[0017] Applications 112, 114, and 116 communicate with and utilize an underlying platform and infrastructure (not shown), as known in the art. Such platforms and infrastructure include, but are not limited to, servers (running stand-alone or in a virtual machine), protocols, networks, databases, data centers, and the like.

[0018] Users 132, 134, and 136 interact with applications 112, 114, and 116 via a user interface (UI) layer 120. UI layer 120 may present a user interface operated by users 132, 134, and 136 to access the functions of applications 112, 114, and 116. Alternatively, UI layer 120 may provide entry points to individual UI components (not shown) of applications 112, 114, and 116.

[0019] The application monitoring component 150 may operate to receive data from the applications 112, 114, and 116. Based on the data, as known in the art, the application monitoring component 150 may determine that a desired key performance indicator (KPI) value is not satisfied (for example, the process A has not been completed within 7 days), and transmit a notification to the user that initiated the corresponding process. Such conventional operations are the same as those described in the above background art, requiring a user to diagnose and resolve problems of a specific process (for example, an email has not been read by the intended recipient), or determine that a KPI value is not satisfied due to a technical problem, and generate a corresponding support ticket.

[0020] The issue notification system 160 receives application monitoring data from the application monitoring component 150. Based on this data and the metric definitions 164, the alert engine 162 identifies potential technical problems and transmits corresponding notifications to affected users and the problem tracking system 180, as will be described in detail below. Accordingly, embodiments may operate in parallel with conventional application process monitoring systems.

[0021] The metrics defined by the metric definitions 164 may be time-based (for example, processing time of the process A), occurrence-based (for example, a number of failed software module deployments), or based on other criteria. Each metric is associated with both a threshold value and a count limit, as will be described below. The metrics may include KPIs defined and monitored during normal operation of the system 100, but embodiments are not limited thereto.

[0022] The threshold associated with a metric may, but is not limited to, a threshold specified by an applicable Level of Service Agreement (SLA). For example, metric definition 164 may define a metric associated with the completion of a particular process. An active SLA may require the process to be completed within one day, and other systems may operate to monitor compliance with this requirement, but the threshold associated with the metric in metric definition 164 may be 18 hours.

[0023] The issue tracking system 180 is operated by the technical support team, represented by user 185 in Figure 1. The issue notification system 160 can communicate with the issue tracking system 180 via an interface provided by the issue tracking system 180 to notify the system 180 of potential technical issues, as described below. The issue notification system 160 can also communicate with the messaging component 170 (e.g., an email server) to send notifications to affected users according to the algorithms described herein.

[0024] Figure 2 includes a flowchart of process 200 for efficiently detecting and providing notification of technical problems, according to several embodiments. Process 200 and all other processes referred to herein are embodied in program code executable by one or more processing units (e.g., processors, processor cores, processor threads) and can be read from one or more non-temporary computer-readable media such as hard disk drives, volatile or non-volatile random access memory, DVD-ROMs, flash drives, and magnetic tapes, and then stored in compressed, uncompiled, and / or encrypted forms. In some embodiments, hardwired circuits may be used instead of or in combination with program code for the implementation of the processes according to some embodiments. Thus, embodiments are not limited to any particular combination of hardware and software.

[0025] In S205, one or more metrics are initially determined. Each metric is associated with its own threshold and count limit, the relationships of which are described below. Each determined metric, along with its threshold and count limit, can be stored in the metric definition 164 of the issuance notification system 160.

[0026] The initial set of metrics may be determined by the developers of the issue notification system 160 and / or the developers of applications 112, 114, and 116. These metrics may include KPIs monitored by other application monitoring systems deployed in system 100, and the associated thresholds may be equal to the thresholds required by applicable SLAs. The determined thresholds may be stricter than those required by the SLA based on historical performance data, as described below. According to some embodiments, the metrics, their associated thresholds, or their associated count limits may be modified, added, or removed as needed (e.g., by an administrator or some user).

[0027] Monitoring of one or more applications begins in S210. The applications being monitored are those that require monitoring to determine whether the metrics determined in S205 meet their respective thresholds. For example, if the metric is the time required to complete an approval process, then in S210, the application that manages the approval process will be monitored.

[0028] Next, in S215, it is determined whether the metric has exceeded its associated threshold in the ongoing instance of the process. Note that if not, the flow loops back to S215 until it is determined that the metric has exceeded its associated threshold. The flow then proceeds to S220, where the count associated with the metric is incremented. In S225, it is determined whether the count has exceeded the count limit associated with the metric. If not, the flow returns to S215 and continues as described above.

[0029] Figures 3 to 7 show execution timelines of several ongoing instances of the same process according to several embodiments. The execution timelines are intended to provide examples of process 200 according to several embodiments.

[0030] Figure 3 shows the start of each of processes A1 through A5. The progress of each process is ongoing and is represented by an arrow pointing to its start at t0 in its own timeframe. Therefore, although the relative time differences between t0, t1, t2, and t3 on each timeline are equal, t0 of process A5 occurs after t1 of process A1.

[0031] For the purposes of this explanation, we assume that the threshold time associated with the completion of process A is t2. We also assume that the applicable SLA requires process A to be completed by t3. Therefore, at the time represented by Figure 3, since the instance of process A did not take longer than t2 to complete, in S215, the metric is determined not to have exceeded its threshold.

[0032] Moving to Figure 4, process A1 is not completed by t2, as indicated by "x". Therefore, the counter associated with the completion of process A is incremented to 1 in S220. Assume that the count limit associated with the completion of process A (and determined in S205) is 2. Thus, process A1 and the remaining instances of process A continue to run, and the flow returns from S225 to S215.

[0033] Note that at the time shown in Figure 5, process A2 has not been completed by t2 (as indicated by "x"), while process A3 has been completed by t2 (annotated by "o"). Therefore, the counter associated with the completion of process A is incremented to 2 at S220. The count limit associated with the completion of process A is 2, and since it has not been exceeded, the flow returns to S215 from S225. Time elapses to the time shown in Figure 6, and it is determined that process A4 has not been completed by t2. Therefore, the counter associated with the completion of process A is incremented to 3 at S220. Next, since the count limit associated with the completion of process A has been exceeded, the flow proceeds to S230.

[0034] In S230, communications are sent to each user and technical support personnel associated with the exceeded threshold. In the examples shown in Figures 3-6, communications are sent to the users who initiated processes A1, A2, and A4, and to the technical support personnel. In some embodiments, the alert engine 162 instructs the messaging component 170 to send emails to the appropriate users and communicate with the problem tracking system 180 to open a single corresponding ticket. The emails to users may include error messages indicating, for example, that an underlying technical issue has been identified, that support personnel have been notified, and that the user will be kept informed of the status of the technical issue.

[0035] The above offers several advantages over traditional systems. First, users are notified even before the corresponding SLA is violated (i.e., before completion t2). Second, users are notified before they are likely to generate a support ticket otherwise, thereby saving them effort. Third, the technical support team receives a single support ticket rather than multiple support tickets related to (possibly) the same underlying issue.

[0036] After sending the communication in S230, process 200 continues to monitor in S235 whether the threshold associated with the metric has been exceeded. If not, in S245, it is determined whether the problem has been resolved. The determination in S245 may be based on communication received from the technical support team indicating that the problem has been resolved, a determination that the metric did not exceed its threshold for a given amount of time and / or number of occurrences, and / or any other basis. If the problem has not been resolved, the flow returns to S235.

[0037] If, in S235, the metric is determined to have exceeded its threshold, a communication is sent to the corresponding user in S240. This communication may be similar to the communication sent to the user in S230. In some embodiments, a communication is not sent to the technical support team in S240 because a support ticket has already been opened in S230.

[0038] Figure 7 shows a scenario in which process A5 is determined to have exceeded time t2 in S235. Therefore, in S240, a communication is sent to the corresponding user. The communication is sent regardless of the count limit because it has already been determined that a potential technical problem exists. The flow continues to cycle in this manner between S235, S240, and S245 until it is determined in S245 that the problem has been resolved. Then, in S250, a communication indicating that the problem has been resolved is sent by process 200 to all users who previously received the communication.

[0039] According to some embodiments, S250 includes actions to confirm that the issue has been resolved. For example, upon resolution of the ticket, the issue tracking system 180 notifies system 160 that the support ticket submitter has been identified. System 160 continues to monitor the corresponding metric to determine whether the percentage of the threshold exceeded has decreased (e.g., down to 50% of the prior notification rate). If so, the user is notified as described above. Otherwise, the ticket is reopened and the user is notified that the issue has not been resolved.

[0040] For simplicity, S215-S250 are described above in relation to a single metric. Note that in S215, two or more metrics may be evaluated, and whenever it is determined that a metric exceeds its threshold, the remaining steps of process 200 are performed for that metric, while S215 continues to evaluate the other metrics that have not exceeded their respective thresholds.

[0041] The threshold associated with the metric determines how long a problem is identified. A low threshold ensures that problems do not remain "undetected" for too long. On the other hand, if delays occur regularly, even without any corresponding technical issues, it is desirable to increase the threshold to avoid false positives.

[0042] According to some embodiments, the threshold can be defined in relation to historical performance. This definition may be rule-based, and the threshold may be periodically recalculated based on the definition. In one example, the threshold is defined in relation to historical runtime. For example, the threshold may be defined as the process runtime at which 95% of the process is completed. Such an approach can minimize false positives while still detecting actual problems. This value may be increased (e.g., up to 98%, 99%) if the cost of analysis is more of a concern than timely identification of the problem, or decreased (e.g., up to 65%) if early detection of the problem is more important.

[0043] Figure 8 shows the setting of thresholds associated with a metric in several embodiments. The metric is the completion of a particular process, and Graph 800 shows the percentage of initiated processes completed over time. Graph 800 assumes that 98% of initiated processes are completed by time t2, and the current threshold associated with the metric is time t2. It may be desirable to reduce the completion percentage to 95%. Since this value corresponds to time t2', the threshold associated with the metric is reduced to t2'.

[0044] Similarly, the count limit for a particular metric may be fixed or variable. The setting of the count limit may depend on how often the corresponding process is executed. Specifically, a process that is started very frequently may quickly reach a low count limit and be associated with a higher count limit, while a process that is started rarely may be associated with a lower count limit to reduce the time until the corresponding technical problem is detected.

[0045] Figure 9 shows the architecture 900, where similar components are numbered the same as the corresponding components in Figure 1. The architecture 900 further includes a user time normalizer 166, a workplace personnel system 190, and holiday data 195. The user time normalizer 166 may communicate with the workplace personnel system 190 and holiday data 195 to assist the alert engine 162 in taking “working hours” into account when evaluating metric thresholds. Since embodiments compare overall process time to a threshold to detect technical problems, it may be beneficial to ignore non-working hours in the overall process time (e.g., weekends, holidays, vacation days, sick days, etc.) as those times are typically irrelevant to whether or not a technical problem is present.

[0046] For example, if a message is sent just before the end of business hours and the receiving user responds promptly the following morning, the intervening time shall not be considered part of the overall processing time, especially when compared to the elapsed time from the start of a workday (when no response is received) to the end of the workday. The same applies if a message is sent at the end of Friday and the receiving user responds the following Monday morning.

[0047] In the latter case, working days and holidays depend on the region where the user works. The user's location can be obtained from the workplace HR system 190, and the working days and holidays for that location can be read from the holiday data 195. The location also allows for the establishment of a user time zone and the exclusion of corresponding non-working hours from the total process time. The workplace HR system 190 may also provide user-specific holiday periods for exclusion.

[0048] According to some embodiments, a user's working hours can be derived from the login times of the system in which the user regularly works. Such characteristics can be useful in determining the total process time in the case of part-time users or users working overtime.

[0049] Figure 10 is a block diagram of a computing system according to several embodiments. System 1000 may include a general-purpose computing device and may execute program code to perform any of the functions described herein, including, but not limited to, process 200. System 1000 may be implemented by a standalone computing device, a distributed cloud-based server, or other system and may include other elements not shown according to several embodiments.

[0050] System 1000 includes a processing unit 1010 operably coupled to an I / O device 1020, a data storage device 1030, one or more input devices 1040, one or more output devices 1050, and memory 1060. The I / O device 1020 can facilitate communication with external devices such as an external network, cloud, or data storage device. The input device 1040 may include, for example, a keyboard, keypad, mouse, or other pointing device, microphone, knob or switch, infrared (IR) port, docking station, and / or touchscreen. The input device 1040 may be used, for example, to input information into System 1000. The output device 1050 may include, for example, a display (e.g., a display screen), speaker, and / or printer.

[0051] The data storage device 1030 may comprise any suitable persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives, and flash memory), optical storage devices, read-only memory (ROM) devices, and RAM devices, and the memory 1060 may comprise a RAM device.

[0052] The data storage device 1030 is executed by the processing unit 1010 and stores program code that causes the system 1000 to implement any of its components and execute one or more of the processes described herein. Embodiments are not limited to the execution of these processes by a single computing device. The data storage device 1030 may also store data and other program code necessary for the operation of the system 1000, such as device drivers, operating system files, etc., to provide additional functionality.

[0053] The diagram above represents a logical architecture for illustrating processes according to several embodiments, and actual implementations may include more or different components arranged in other ways. Other topologies may be used in conjunction with other embodiments. Furthermore, each component or device described herein may be implemented by any number of devices communicating over any number of other public and / or private networks. Two or more such computing devices may be located far apart from each other and may communicate over any known method of networking and / or private connections. Each component or device may comprise any number of hardware and / or software elements suitable for providing the functions described herein and any other functions. For example, any computing device used in the implementation of some embodiments may include a processor for executing program code so that the computing device operates as described herein.

[0054] The embodiments described herein are for illustrative purposes only. Those skilled in the art will recognize that other embodiments may be implemented with modifications and changes from those described above. [Explanation of symbols]

[0055] 100 Systems 112 Applications 114 applications 116 Applications 120 User Interface (UI) Layer 132 users 134 users 136 users 150 Application Monitoring Components 160 Issuance Notification System 162 Alert Engine 164 Metric Definitions 166 User Time Normalizer 170 Messaging Components 180 Problem Tracking System 185 users 190 Workplace HR System 195 Public Holiday Data 200 processes 900 Architecture 1000 systems 1010 Processing Unit 1020 I / O devices 1030 Data Storage Devices 1040 Input Devices 1050 Output Device 1060 memory

Claims

1. A monitoring step, comprising the step of monitoring one or more software applications in order to determine the value of a first metric associated with an instance of a first process, wherein the first process is executed by the one or more software applications, A step of determining that the value of the first metric exceeds a threshold associated with the first process in an ongoing instance of the first process, wherein the number of instances that exceed the threshold is a first number. The steps include determining that the first number is greater than a first count limit associated with the first process, In response to determining that the first number is greater than the first count limit, the steps include sending an error message to the user associated with each of the ongoing instances of the first process. A method that includes this.

2. Step 1: In response to determining that the first number is greater than the first count limit, send an error message associated with the first process to the technical support department. The method according to claim 1, further comprising:

3. After sending the error message, the step of determining that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process, The steps include: sending an error message to a user associated with the second ongoing instance of the first process in response to determining that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process; The method according to claim 1, further comprising:

4. The method according to claim 1, wherein the step of determining that the value of the first metric has exceeded a threshold associated with the first process in an ongoing instance of the first process includes the step of determining the working hours of a user associated with the ongoing instance of the first process.

5. A monitoring step to determine the value of a second metric associated with an instance of a second process, the monitoring step includes a step in which the second process is executed by the one or more software applications, A step of determining that the value of the second metric exceeds a second threshold associated with the second process in an ongoing instance of the second process, wherein the number of instances that exceed the second threshold is a second number. The steps include determining that the second number is greater than the second count limit associated with the second process, In response to determining that the second number is greater than the second count limit, the second process sends an error message to the user associated with each of the ongoing instances of the second process. The method according to claim 1, further comprising:

6. The steps include sending the error message to the user associated with each of the ongoing instances of the first process, and then determining that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process, The steps include: sending an error message to a user associated with the second ongoing instance of the first process in response to determining that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process; The steps include sending the error message to the user associated with each of the ongoing instances of the second process, and then determining that the value of the second metric has exceeded the second threshold in the second ongoing instance of the second process, The steps include: sending an error message to a user associated with the second ongoing instance of the second process in response to determining that the value of the second metric has exceeded the second threshold in the second ongoing instance of the second process; The method according to claim 5, further comprising:

7. Monitoring one or more software applications to determine the value of a first metric associated with an instance of a first process, wherein the monitoring includes steps performed by the one or more software applications. Determining that the value of the first metric exceeds a threshold associated with the first process in an ongoing instance of the first process, and that the number of instances exceeding the threshold is a first number, Determining that the first number is greater than the first count limit associated with the first process, In response to the determination that the first number is greater than the first count limit, an error message is sent to the user associated with each of the ongoing instances of the first process. A non-temporary, computer-readable medium that stores program code executable by a processing unit, in order to have a computing system perform a certain task.

8. The aforementioned program code In response to the determination that the first number is greater than the first count limit, send an error message associated with the first process to the technical support department. The medium according to claim 7, further executable by a processing unit to cause a computing system to perform the same action.

9. The aforementioned program code After sending the error message, it is determined that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process. In response to the determination that the value of the first metric exceeds the threshold in the second ongoing instance of the first process, an error message is sent to the user associated with the second ongoing instance of the first process. The medium according to claim 7, further executable by a processing unit to cause a computing system to perform the same action.

10. The medium according to claim 7, wherein determining that the value of the first metric exceeds a threshold associated with the first process in an ongoing instance of the first process includes determining the working hours of a user associated with the ongoing instance of the first process.

11. The aforementioned program code Monitoring one or more software applications to determine the value of a second metric associated with an instance of a second process, wherein the monitoring includes steps performed by the one or more software applications. Determining that the value of the second metric exceeds a second threshold associated with the second process in an ongoing instance of the second process, and that the number of instances exceeding the second threshold is a second number, Determining that the second number is greater than the second count limit associated with the second process, In response to the determination that the second number is greater than the second count limit, an error message is sent to the user associated with each of the ongoing instances of the second process. The medium according to claim 7, further executable by a processing unit to cause a computing system to perform the same action.

12. The aforementioned program code After sending the error message to each of the ongoing instances of the first process, it is determined that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process. In response to the determination that the value of the first metric exceeds the threshold in the second ongoing instance of the first process, an error message is sent to the user associated with the second ongoing instance of the first process. After sending the error message to each of the ongoing instances of the second process, it is determined that the value of the second metric has exceeded the second threshold in the second ongoing instance of the second process. In response to the determination that the value of the second metric exceeds the second threshold in the second ongoing instance of the second process, an error message is sent to the user associated with the second ongoing instance of the second process. The medium according to claim 11, further executable by a processing unit to cause a computing system to perform the same action.

13. It is a system, One or more processing units, Monitoring memory, which includes monitoring one or more software applications to determine the value of a first metric associated with an instance of a first process, wherein the first process includes steps performed by the one or more software applications. Determining that the value of the first metric exceeds a threshold associated with the first process in an ongoing instance of the first process, and that the number of instances exceeding the threshold is a first number, Determining that the first number is greater than the first count limit associated with the first process, In response to the determination that the first number is greater than the first count limit, an error message is sent to the user associated with each of the ongoing instances of the first process. In order to have the computing system perform this, a memory storing program code that can be executed by one or more processing units and A system that includes this.

14. The aforementioned program code In response to the determination that the first number is greater than the first count limit, send an error message associated with the first process to the technical support department. The system according to claim 13, wherein the computing system is capable of performing the above by one or more processing units.

15. The aforementioned program code After sending the error message, it is determined that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process. In response to the determination that the value of the first metric exceeds the threshold in the second ongoing instance of the first process, an error message is sent to the user associated with the second ongoing instance of the first process. The system according to claim 13, wherein the computing system is capable of performing the above by one or more processing units.

16. The system according to claim 13, wherein determining that the value of the first metric exceeds a threshold associated with the first process in an ongoing instance of the first process includes determining the working hours of a user associated with the ongoing instance of the first process.

17. The aforementioned program code Monitoring one or more software applications to determine the value of a second metric associated with an instance of a second process, wherein the monitoring includes steps performed by the one or more software applications. Determining that the value of the second metric exceeds a second threshold associated with the second process in an ongoing instance of the second process, and that the number of instances exceeding the second threshold is a second number, Determining that the second number is greater than the second count limit associated with the second process, In response to the determination that the second number is greater than the second count limit, an error message is sent to the user associated with each of the ongoing instances of the second process. The system according to claim 13, wherein the computing system is capable of performing the above by one or more processing units.

18. The aforementioned program code After sending the error message to each of the ongoing instances of the first process, it is determined that the value of the first metric has exceeded the threshold in the second ongoing instance of the first process. In response to the determination that the value of the first metric exceeds the threshold in the second ongoing instance of the first process, an error message is sent to the user associated with the second ongoing instance of the first process. After sending the error message to each of the ongoing instances of the second process, it is determined that the value of the second metric has exceeded the second threshold in the second ongoing instance of the second process. In response to the determination that the value of the second metric exceeds the second threshold in the second ongoing instance of the second process, an error message is sent to the user associated with the second ongoing instance of the second process. The system according to claim 17, wherein the computing system is capable of performing the above by one or more processing units.

Images