A display organized with the various components of a complex process represented by the rows, and selected parameters to be monitored listed in columns. The fields of the display which represent a particular "vital sign" for a particular component present two types of information: (1) alarms which indicate whether the parameter is in or out of limits and how close it is to failure; and (2) trends which indicate changes and types of changes, but do not pose a threat to the system. The alarms, in most part, are represented by solid colors. The trends are shown by the interface line between two contrasting colors or shades of colors defining the trend line and showing the direction of the trend and type of change.
CROSS REFERENCE TO RELATED APPLICATION
This application is a Continuation-In-Part of U.S. application Ser. No. 10/068,969, filed Feb. 7, 2002, now abandoned.
Systems and methods are provided for collecting a set of values from a computing device and associating the collected set of values with a process, such as an business process or industrial process. Process activity is monitored by collecting one or more parameters associated with specific repeatable tasks or activities performed on a computing device. The one or more collected parameters are then aggregated to form a specific process pattern that can be associated with the actual throughput and efficiency of a process.
A method and user interface are provided for independently and conveniently scaling y-values of multiple data sets whereby the data sets may be plotted against a common y-axis and provide satisfactory variability. A multiplier is selected by which data points in a data set are multiplied, allowing plots of multiple data sets to be graphed against a common range of y-axis values. The initial multiplier may be calculated and selected automatically by the computer on which the graphing is performed or may be manually selected by a user. If the results of the graphing are not satisfactory to the user, the user may change the multiplier for any data set. A spin button may be provided to enable the user to easily increment or decrement a multiplier in predefined steps, such as by factors of 10. Additionally, a computer-generated indicator may be displayed to assist the user in selecting a different multiplier.
A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.
A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.
A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.
