Automated availability data collection and reporting for system management environments

A system and associated method for automatically monitoring and reporting availability data of at least one system management (SM) environment. A SM environment subject to monitoring is coupled to a SM portal server. The SM portal server has components of a central repository storing monitoring data, a user interface interacting with a user of the SM portal server, and a data collection module remotely controlling operations of availability module running in a monitoring server of the SM environment. The availability module gathers status of terminal systems of the SM environment by use of various SM tools and subsequently reports to the data collection module, which stores gathered data in the central repository and communicates to the user for availability analysis purposes.

BACKGROUND

Conventional system management technologies use a single point of control and system status data collection for multiple computer systems in a system management (SM) environment. Consequently, conventional systems management technologies cannot automatically manage and monitor multiple SM environments.

BRIEF SUMMARY

According to one embodiment of the present invention, a method for automatically monitoring and reporting availability data of at least one system management (SM) environment comprises: identifying a SM environment of said at least one SM environment that is eligible for data collection, wherein the SM environment is coupled to a SM portal server, wherein the SM portal server comprises a central repository, a user interface, and a data collection module, wherein the SM environment comprises a monitoring server and one or more terminal systems coupled to the monitoring server, and wherein the monitoring server runs an availability module that enables collecting of various system level data from said one or more terminal systems; retrieving connection configuration associated with the identified SM environment from the central repository; collecting the availability data from the availability module upon determining that the retrieved connection configuration properly establishes communication between the SM portal server and the identified SM environment, wherein the availability data represents availability of resources of said one or more terminal systems; recording the collected availability data and a transaction log of said collecting in the central repository; and communicating content of the central repository from said recording such that a user of the SM portal server utilizes contents of the central repository in analyzing availability of the resources in the SM environment.

According to one embodiment of the present invention, a computer program product comprises a computer readable memory unit that embodies a computer readable program code. The computer readable program code contains instructions that, when run by a processor of a computer system, implement a method for automatically monitoring and reporting availability data of at least one SM environment.

According to one embodiment of the present invention, a computer system comprises a processor, a memory coupled to the processor, and a computer readable storage device coupled to the processor, said storage device containing program code configured to be executed by the processor via the memory to implement a method for automatically monitoring and reporting availability data of at least one SM environment.

According to one embodiment of the present invention, a process for supporting computer infrastructure, said process comprising providing at least one support service for at least one of creating, integrating, hosting, maintaining, and deploying computer-readable code in a computing system, wherein the code in combination with the computing system is capable of performing a method for automatically monitoring and reporting availability data of at least one SM environment.

DETAILED DESCRIPTION

FIG. 1illustrates a system10for automatically monitoring and reporting availability data of respective system management environments, in accordance with embodiments of the present invention.

The system10comprises a user11, a system management portal server21, and one or more customer systems. In this specification, terms “system management (SM) environment” and “customer system” are used interchangeably to indicate a digital communication network interconnecting two or more computer systems subject to said automatic monitoring and reporting.

A public customer system25of said one or more customer systems is a first customer system wherein components are interconnected via a public network environment. The public customer system25comprises a monitoring/management region server31and at least one endpoint respectively coupled to the monitoring/management region server31. A private customer system26of said one or more customer systems is a second customer system wherein components are interconnected via a private network environment. The private customer system26comprises a monitoring/management enterprise server51and at least one agent respectively coupled to the monitoring/management enterprise server51.

The user11is a human user administering the system management portal server21providing inputs comprising control data and receiving outputs comprising reports to and from the system management portal server21, respectively. In one embodiment of the present invention, the user11interacts with the system management portal server21by use of web-based graphical user interface (GUI). The inputs of the control data dictate automatic monitoring and reporting operations for the system availability data performed by the system management portal server21and respective servers of the customer systems. The inputs of the reports comprise information on current and historical status of the system management portal server21, and information on current and historical status of respective components of all customer systems coupled to the system management portal server21. In this specification, terms “availability data” and “system availability data” are used interchangeably to define a percentile value representing a ratio of available system resources to total system resources.

The system management portal server21automatically collects and subsequently consolidates, analyzes and stores system availability data from respective servers of the customer systems. The system management portal server21interacts with the user11by receiving inputs from the user11and by returning outputs to the user11as being generated by components of the customer systems,25and26. The system management portal server21enables the user11to interact with the customer systems,25and26, in controlling operations of respective servers and in receiving status reports from the respective servers of the customer systems,25and26. See descriptions ofFIG. 2infra for details for components of the system management portal server21.

The monitoring/management region server31of the public customer system25performs automatic monitoring for availability data of said at least one endpoint in the public customer system25. In one embodiment of the present invention, the monitoring/management region server31is implemented by use of IBM® Tivoli® Management Region (TMR) Server, which may run in various operating systems (IBM and Tivoli are registered trademarks of International Business Machines Corporation in the United States and other countries). Examples of the operating systems in which the IBM TMR server runs may be, inter alia, Linux®, AIX®, Solaris®, HP-UX®, Windows™ etc. (Linux is a registered trademark of Linus Torvalds in the United States; AIX is a registered trademark of IBM Corporation, in the United States and other countries; Solaris is a registered trademark of Sun Microsystems, Inc., in the United States and other countries; HP-UX is a registered trademark of Hewlett-Packard Company in the United States and other countries; and Windows is a trademark of Microsoft Corporation, in the United States and other countries.)

In the public customer system25, an endpoint A41A of said at least one endpoint is coupled to the monitoring/management region server31. The endpoint41is a client program deployed on terminal systems of the public customer system25in order to provide availability data to the monitoring/management region server31in performing automatic monitoring and reporting. In one embodiment of the present invention, the endpoint41is implemented by use of IBM Tivoli Endpoint, wherein the monitoring/management region server31is implemented by use of IBM Tivoli Management Region (TMR) Server. The endpoint A41A may run on various operating systems. Examples of the operating systems in which the IBM Tivoli Endpoint runs may be, inter alia, Linux, AIX, Solaris, HP-UX, Windows, etc. See description ofFIG. 3infra for an example of the public customer system25.

The monitoring/management enterprise server51of the private customer system26performs automatic monitoring for availability data of said at least one agent in the private customer system26. In one embodiment of the present invention, the monitoring/management enterprise server51is implemented by use of IBM Tivoli Enterprise Portal Server (TEPS), which may run in AIX operating system.

In the private customer system26, an agent61of said at least one agent is coupled to the monitoring/management enterprise server51. The agent61is another client program deployed on terminal systems of the private customer system26in order to provide availability data to the monitoring/management enterprise server51in performing automatic monitoring and reporting. In one embodiment of the present invention, the agent61is implemented by use of IBM Tivoli Enterprise Monitoring Agent (TEMA), wherein the monitoring/management enterprise server51is implemented by use of IBM Tivoli Enterprise Monitoring Server (TEMS). The agent61may run on an operating system selected from Linux, AIX, Solaris, HP-UX, and Windows. See descriptions ofFIG. 4infra for an example of the private customer system26. In this specification, the term “terminal systems” collectively indicates both endpoints coupled to monitoring/management region servers and agents coupled to monitoring/management enterprise servers.

FIG. 2illustrates the system management portal server21in the system10ofFIG. 1supra, in accordance with the embodiments of the present invention.

The system management portal server (SMPS)21comprises a web-based graphical user interface (GUI)22, a central repository23, and a data collection module24.

The SMPS21interacts with the user11by use of the web-based GUI22, in receiving the control data from the user11and in displaying the reports to the user11resulting from operating the data collection module24. Examples of the reports may be, inter alia, dynamic status reports, web charts, availability data trends, etc. SeeFIG. 8infra for an example of the web-based GUI22.

The central repository23of the SMPS21stores all availability data used by the data collection module24as being gathered from the customer systems and generated before, during, and after performing automatic monitoring and reporting of the availability data. In one embodiment of the present invention, data stored in the central repository23are used for, inter alia, a historical analysis for trends of the availability data, troubleshooting of terminal systems, etc.

The data collection module24connects to and orchestrates operations of availability modules running on respective servers of respective customer systems in collecting latest availability data from all terminal systems coupled to the SMPS21. See description ofFIG. 5infra for operations performed by the data collection module24.

Wherein the SMPS21monitors and manages terminal systems coupled to the monitoring/management region server31, the data collection module24interacts with a regional availability module running in the monitoring/management region server31in the public customer system25. See description ofFIG. 3infra for details of the regional availability module.

Wherein the SMPS21monitors and manages terminal systems coupled to the monitoring/management enterprise server51, the data collection module24interacts with an enterprise availability module running in the monitoring/management enterprise server51in the private customer system26. See description ofFIG. 4infra for details of the enterprise availability module.

FIG. 3illustrates components of the public customer system25in the system10ofFIG. 1supra, wherein the components of the public customer system are coupled via a public network, in accordance with the embodiments of the present invention.

The public customer system25further comprises a public system management environment comprising at least one computer system selected from the group consisting of a Windows endpoint42, an AIX endpoint43, a Solaris endpoint44, a HP-UX endpoint45, and a Linux endpoint46, which are coupled to the monitoring/management region server31via the public network. The Windows endpoint42runs in a Windows server on a first computer system of the public customer system25. The AIX endpoint43runs in an AIX server on a second computer system of the public customer system25. The Solaris endpoint44runs in a Solaris server on a third computer system of the public customer system25. The HP-UX endpoint45runs in a HP-UX server on a fourth computer system of the public customer system25. The Linux endpoint46runs in a Linux server on a fifth computer system of the public customer system25. In one embodiment of the present invention, each endpoint is respectively implemented as a respective Tivoli Endpoint installed in said respective server, and the respective Tivoli Endpoint is coupled to a Tivoli Region environment, which implements the monitoring/management region server31.

The monitoring/management region server31performs system management service tasks for the public customer system25. The monitoring/management region server31comprises a regional availability module32, which collects availability data from above listed endpoints of the public customer system25. See description ofFIG. 6infra for operations performed by the regional availability module32. In one embodiment of the present invention, the regional availability module32runs on a system management environment based on specific client-server architecture, inter alia, Tivoli Framework, Tivoli Monitoring v6, and BMC® Patrol®. (BMC and Patrol are registered trademarks of BMC Software Inc., in the United States and other countries)

The regional availability module32is commonly referred to as “availability agents” that work as a client-side program interacting with a server-side program implemented as the system management portal server21ofFIG. 1supra. Various computer systems of the public system management environment interacts with the system management portal server21ofFIG. 1supra via the regional availability module32running on the monitoring/management region server31such that the monitoring/management region server31integrates said various computer systems into a single environment for system management by collecting data from each computer system of the public system management environment.

In one embodiment of the present invention, the regional availability module32is Tivoli Availability Agent that is installed on each Tivoli Management Region (TMR) Server, which is an example of the monitoring/management region server31. In the same embodiment, the system management portal server21ofFIG. 1supra is implemented by Tivoli Framework Server.

FIG. 4illustrates components of the private customer system26in the system10ofFIG. 1supra, wherein the components of the private customer system are coupled via a private network, in accordance with the embodiments of the present invention.

The private customer system26further comprises a private system management environment comprising at least one computer system selected from the group consisting of a Windows agent62, an AIX agent63, a Solaris agent64, a HP-UX agent65, and a Linux agent66, which are coupled to the monitoring/management enterprise server51via the private network. The Windows agent62runs in a Windows server on a first computer system of the private customer system26. The AIX agent63runs in an AIX server on a second computer system of the private customer system26. The Solaris agent64runs in a Solaris server on a third computer system of the private customer system26. The HP-UX agent65runs in a HP-UX server on a fourth computer system of the private customer system26. The Linux agent66runs in a Linux server on a fifth computer system of the private customer system26. In one embodiment of the present invention, each agent is respectively implemented as a respective Tivoli Enterprise Monitoring Agent (TEMA) installed in said respective server, and the respective TEMA is coupled to a Tivoli Enterprise Monitoring Server (TEMS), which implements the monitoring/management enterprise server51.

The monitoring/management enterprise server51performs system management service tasks for the private customer system26. The monitoring/management enterprise server51comprises an enterprise availability module52, which collects availability data from above listed agents of the private customer system26. See description ofFIG. 7infra for operations performed by the enterprise availability module52. In one embodiment of the present invention, the monitoring/management enterprise server51is a Tivoli Enterprise Portal Server (TEPS) that runs on a AIX Operating System. The enterprise availability module52runs on a system management environment based on specific client-server architecture, inter alia, Tivoli Framework, Tivoli Monitoring v6, and BMC® Patrol®. (BMC and Patrol are registered trademarks of BMC Software Inc., in the United States and other countries)

The enterprise availability module52operates as a client-side program interacting with a server-side program implemented as the system management portal server21ofFIG. 1supra. Various computer systems of the private system management environment interacts with the system management portal server21ofFIG. 1supra via the enterprise availability module52running on the monitoring/management enterprise server51such that the monitoring/management enterprise server51integrates said various computer systems into a single environment for system management by collecting data from each computer system of the private customer system26.

FIG. 5is a flowchart depicting a method for automatically monitoring and reporting availability data of respective system management environments, which is performed by the data collection module in the system management portal server (SMPS) ofFIG. 2supra, in accordance with the embodiments of the present invention.

The data collection module is configured to integrate various system management (SM) environments coupled to the SMPS. The data collection module performs steps110through170respectively for each SM environment.

In step110, the data collection module identifies a current SM environment that is eligible for availability data collection. Then the data collection module proceeds with step120.

In step120, the data collection module retrieves, from the central repository, configuration information of the current SM environment identified in step110supra, for connection between the SMPS and the respective monitoring/management server and subsequent availability data collection. Then the data collection module proceeds with step130.

In step130, the data collection module determines whether the configuration information retrieved in step120supra is proper for further data communication between the SMPS and the respective monitoring/management server of the current SM environment. If the data collection module determines that the configuration information is proper, then the data collection module proceeds with step140. If the data collection module determines that the configuration information is improper, then the data collection module proceeds with step170.

In step140, the data collection module collects availability data from an availability module of the current SM environment. The availability module generates the availability data from terminal systems of the current SM environment by performing steps shown inFIGS. 6 and 7infra. Then the data collection module proceeds with step150.

In step150, the data collection module checks validity of the availability data collected in step140supra. If the data collection module determines that the availability data is valid, then the data collection module proceeds with step160. If the data collection module determines that the availability data is not valid, then the data collection module proceeds with step170.

In step160, the data collection module stores the valid availability data as determined in step150supra, as well as transaction records, in the central repository of the SMPS. Then the data collection module loops back to step110for a next SM environment.

In step170, the data collection module reports a respective error pursuant to a respective preceding step. If the data collection module performs step170subsequent to step130, the data collection module reports a first type of error of improper connection configuration. If the data collection module performs step170subsequent to step150, the data collection module reports a second type of error of invalid availability data collected from availability modules. Then the data collection module loops back to step110for a next SM environment. The data collection module terminates upon collecting data from all SM environments coupled to the SMPS.

FIG. 6is a flowchart depicting a method for automatically generating availability data of respective system management environments, which is performed by the regional availability module in the monitoring/management region server ofFIG. 3supra for a public customer system, in accordance with the embodiments of the present invention.

The regional availability module performs steps210through260for each endpoint eligible for checking of availability data, for all terminal systems coupled to the monitoring/management region server. The public customer system SM environment comprises various types and respective number of endpoints as described inFIG. 3supra.

In step210, the regional availability module verifies availability of a current endpoint. In one embodiment of the present invention, the regional availability module is configured to verify endpoint availability pursuant to a configuration list received from the data collection module during configuration. Then the regional availability module proceeds with step220.

In step215, the regional availability module determines whether the current endpoint is running and available pursuant to a result of step210supra. If the regional availability module determines that the current endpoint is available, then the regional availability module proceeds with step220. If the regional availability module determines that the current endpoint is not available, then the regional availability module proceeds with step260.

In step220, the regional availability module identifies a type of monitoring probe that is configured for deployment on the current endpoint. Then the regional availability module proceeds with step225.

In step225, the regional availability module determines whether a proper monitoring probe is deployed on the current endpoint. If the regional availability module determines that a monitoring probe having a type corresponding to the current endpoint is deployed on the current endpoint, then the regional availability module proceeds with step230. If the regional availability module determines that there is no monitoring probe deployed on the current endpoint or that a monitoring probe deployed on the current endpoint is of a type not corresponding to the current endpoint, then the regional availability module proceeds with step260.

In step230, the regional availability module identifies a respective version of each monitoring probe deployed on the current endpoint. Then the regional availability module proceeds with step235.

In step235, the regional availability module determines a version corresponding to a monitoring probe selected for validation. The version may be selected from a group consisting of DM37, ITM5, and any versions of SM environment probes for Tivoli, Patrol, etc. If the regional availability module determines that the version of the monitoring probe is DM37, then the regional availability module proceeds with step240. If the regional availability module determines that the version of the monitoring probe is ITM5, then the regional availability module proceeds with step250. For each version of the monitoring probe selected for validation, respective steps to check status of the monitoring probe of said each version and to validate the monitoring probe follow. Such respective steps for other versions of monitoring probes are not illustrated inFIG. 6.

In step240, the regional availability module checks state of a DM37 engine. If the regional availability module determines that the state of the DM37 engine is valid, then the regional availability module proceeds with step245. If the regional availability module determines that the state of the DM37 engine is invalid, then the regional availability module proceeds with step260.

In step245, the regional availability module validates each DM37 monitoring probe. Then the regional availability module proceeds with step260.

In steps240and245, the Distributed Monitoring v3.7 (DM37) Engine client software is installed on each endpoint to be monitored directly. The DM37 Engine is responsible to run Distributed Monitoring v3.7 (DM37) monitoring probes, or simply DM37 Probes. The DM37 Engine determines whether or not the DM37 Probes should be triggered, and runs most of the automated responses. The DM37 Probe is responsible to monitor specific types of resources, inter alia, CPU, memory, disk space, communication bandwidth, etc. In one embodiment of the present invention, a respective terminal system runs a Tivoli Endpoint, a DM 37 Engine and one or more DM37 Probes.

In step250, the regional availability module checks state of an ITM5 engine. If the regional availability module determines that the state of the ITM5 engine is valid, then the regional availability module proceeds with step255. If the regional availability module determines that the state of the ITM5 engine is invalid, then the regional availability module proceeds with step260.

In step255, the regional availability module validates each ITM5 resource model. Then the regional availability module proceeds with step260.

In steps250and255, the IBM Tivoli Monitoring v5 (ITM5) Engine client software is installed on each endpoint to be directly monitored. The ITM5 Engine is responsible to run ITM5 Resource Models (RM) monitoring probes, or simply ITM5 resource models. The ITM5 Engine determines whether or not the ITM5 resource models should be triggered, and runs most of the automated responses. The ITM5 resource model is responsible to monitor specific types of resources, inter alia, CPU, memory, disk space, communication bandwidth, etc. In one embodiment of the present invention, a respective terminal system runs a Tivoli Endpoint, an ITM5 Engine and one or more ITM5 Resource Models.

In step260the regional availability module generates a report stating results of validation/verification steps that performed prior to step260for the data collection module. The report comprises one or more results selected from the group consisting of {endpoint available, endpoint unavailable} from step215, {deployed probe exists, no deployed probe} from step225, {DM37 Engine valid, DM37 Engine invalid} from step240, {DM37 Probes validated} from step245, {ITM5 Engine valid, ITM5 Engine invalid} from step250, {ITM5 Resource Models validated} from step255, and combinations thereof. Then the regional availability module loops back to step210to process a next endpoint. The regional availability module terminates upon processing all endpoints eligible for checking in the current SM environment.

FIG. 7is a flowchart depicting a method for automatically generating availability data of respective system management environments, which is performed by the enterprise availability module in the monitoring/management enterprise server ofFIG. 4supra, for a private customer system, in accordance with the embodiments of the present invention.

The enterprise availability module performs steps310and320for each SM agent eligible for checking of availability data, for all terminal systems coupled to the monitoring/management enterprise server. The private customer system SM environment comprises various types and respective number of agents as shown inFIG. 4supra.

In step310, the enterprise availability module verifies availability of a current agent. In one embodiment of the present invention, the enterprise availability module is configured to verify agent availability pursuant to a configuration list received from the data collection module during configuration. Then the enterprise availability module proceeds with step320.

In step320, the enterprise availability module generates a report stating results of validation/verification steps that performed prior to step320for the data collection module. In one embodiment of the present invention, the report generated by step320describes status of ITM6.

FIG. 8is an example of a screen display implementing the web-based graphical user interface (GUI) of the system management portal server (SMPS) ofFIG. 2supra, in accordance with embodiments of the present invention.

The example web GUI shows a General Availability Dashboard (GAD), which consolidates user interfaces for numerous SM tools. The GAD displays key data on the SM environments that are monitored by the SMPS. Examples of key data may be, inter alia, overall Agents & Monitors availability, current baselines, historical trends, etc.

In “CUSTOMER” column, the GAD presents, a respective name of a customer/SM environment in which the SM environment of the present invention is installed.

In “Current Agent Status” column, the GAD shows an overall availability of systems automation agents on the respective environment identified in the CUSTOMER column.

In “Current Monitoring Status” column, the GAD shows an overall availability of monitors and probes running on the respective system automation agent.

In “Number of Agents” column, the GAD shows a respective number of systems automation agents on the respective environment identified in the CUSTOMER column.

In “Reference” column, the GAD shows a time when the SM environment identified in the CUSTOMER column has been most recently synchronized with the SMPS.

In “Historical Evolution” column, the GAD shows a hyperlink to a chart describing historical trends of overall availability of the SM environment identified in the CUSTOMER column.

FIG. 9is an example of a detailed status report generated by the data collection module running in the system management portal server (SMPS) ofFIG. 2supra, in accordance with embodiments of the present invention.

The status report comprises data items collected and stored in steps ofFIG. 5supra, and validation data items reported in step260ofFIG. 6supra, or step320ofFIG. 7supra. The status report ofFIG. 9is hyperlinked to any one customer name ofFIG. 8supra and presented upon clicking a specific customer name.

FIG. 10illustrates a computer system used for automatically monitoring and reporting availability data of respective system management environments, in accordance with the embodiments of the present invention.

The computer system90comprises a processor91, an input device92coupled to the processor91, an output device93coupled to the processor91, and memory devices94and95each coupled to the processor91. In this specification, the computer system90represents any type of programmable data processing apparatus.

The input device92is utilized to receive input data96into the computer system90. The input device92may be, inter alia, a keyboard, a mouse, a keypad, a touch screen, a scanner, a voice recognition device, a sensor, a network interface card (NIC), a Voice/video over Internet Protocol (VOIP) adapter, a wireless adapter, a telephone adapter, a dedicated circuit adapter, etc. The output device93is utilized to communicate results generated by the computer program code97to a user of the computer system90. The output device93may be, inter alia, a printer, a plotter, a computer screen, a magnetic tape, a removable hard disk, a floppy disk, a NIC, a VOIP adapter, a wireless adapter, a telephone adapter, a dedicated circuit adapter, an audio and/or visual signal generator, a light emitting diode (LED), etc.

Any of the components of the present invention can be deployed, managed, serviced, etc. by a service provider that offers to deploy or integrate computing infrastructure with respect to a process for automatically monitoring and reporting availability data of respective system management environments of the present invention. Thus, the present invention discloses a process for supporting computer infrastructure, comprising integrating, hosting, maintaining and deploying computer-readable code into a computing system (e.g., computing system90), wherein the code in combination with the computing system is capable of performing a method for automatically monitoring and reporting availability data of respective system management environments.

Aspects of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. The term “computer program instructions” is interchangeable with the term “computer program code”97in this specification. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.