Today, many organization’s IT teams are considering the use of “cloud bursting”—the process of scaling production Web applications by leveraging added capacity in the cloud when local resources are maxed. When employing cloud bursting, companies typically use IaaS services from cloud providers like Rackspace, Amazon Web Services, SoftLayer and others. IT teams may also run Web server and application tiers of a production Web application in these cloud environments, and keep database or other backend components in hours.

The question is, how do you make sure that you properly monitor and alert on operations within this new, hybrid environment?

Here are the three key elements that need to be addressed:

1. Monitoring the cloud environment
2. Monitoring the application and OS instances in the cloud, and the performance of the application as a whole
3. Leveraging integrated views of both cloud and internal infrastructures

Following is more information on each of these elements.

1. Monitoring the Cloud Environment

Cloud providers will typically provide a couple of ways to get information about the cloud environment as a whole, and your specific usage. Typically, your administrators can access online dashboards that provide high level information about the health of the cloud and your instances. Through these dashboards, you can view the status of cloud health, whether instances are up or down and more.

However, to ensure optimal service levels, you will need more—and you’ll need an integrated view of disparate systems.

Cloud providers also provide more detailed information on the health and uptime of their environment as a whole, health for specific regions in implementation like Amazon EC2 and S3 and of your specific instances and usage—but this information is only available via Web APIs. You’ll need a monitoring environment that can collect, manage and display the details provided through these interfaces.

With these capabilities, you can get both the high level information about your specific instances, and insights into when a cloud provider, region or location is encountering problems. Armed with this information, you can shift resources to alternate locations when your cloud provider experiences issues.

Nimsoft delivers these capabilities through a set of probes that can collect data from the major IaaS providers. These probes can be located where ever your Nimsoft Monitor instance is located, whether within your local IT environment if you’re running the on-premise version of Nimsoft Monitor, or in the Nimsoft hosted cloud environment if you’re using the SaaS version of the product. From this location, the monitoring probes will work with the IaaS provider’s secure API to collect information.

2. Monitoring Applications and OS Instances in the Cloud

To really understand the performance and health of servers you have in the cloud, you’ll need local collection of information about the operating system and of the applications you are running there. For example, this would mean tracking and consolidating information from all the components; OS’s running components of the multi-tier web application, individual monitors for components – web server software (IIS, Apache, etc.), web application servers (WebLogic or WebSphere servers for instance), underlying database servers (SQL, Oracle, etc.), response time for the overall application and more.

Following are the key requirements for making this happen:

• A monitoring point of presence in the cloud environment. Typically, you’ll need a point of presence (POP) for monitoring in your cloud environment. For Nimsoft customers, this means having a “hub” that resides within the cloud. This POP acts as a data collection and secure transmission point for data gathered from cloud-based instances.
• Monitoring for local OS instances within the cloud. You’ll need local data collection via agents. Cloud based servers aren’t good candidates for access via WMI or other agentless approaches. There can be access problems and if your network connection drops, you’ll get no data. You can get around these limitations by installing a local agent on your cloud server. Using appropriate credentials, you install the agent on the system, and data queues locally if the server is disconnected. Nimsoft Monitor addresses these requirements through a combination of probes that act as data collectors and robots that serve as agents, collecting data and delivering it to a message bus. With these capabilities, you can collect and monitor detailed data, including logs, disk and directory usage, processes and more. By collecting detailed OS and system level specifics, you can get the information you need to support a critical application.
• Monitoring of the application on your cloud-based instance. To understand the performance of applications running in cloud-based instances, you need deep, dedicated monitoring for such applications as WebSphere, WebLogic, Apache, IIS, JBoss and more. Typically this information is gathered by data collectors residing on the cloud-based server. (Nimsoft offers probes for these and many other applications.)
• End user performance monitoring. Monitoring for the overall transaction times and experience both locally and from locations across the world/internet where your users are located
• Automated monitoring deployment. Build the monitoring that you need into your cloud-based system images. When these images are instantiated, monitoring on that image should also be started and automatically register itself and start collecting monitoring data. Your displays should then be able to automatically display this information, classifying it according to the type of server in use.

3. Integrated Views of the Entire Application

Unified, intelligent views that cover all of these components are the last element of the solution.

To do this, your displays and dashboards need to cover not only the local, and remote elements – showing their status and performance – but also be designed to allow for the variable nature of bursting to a cloud environment, or using cloud based Web Server and Application Server tiers. When new servers are added by “bursting” or changes happen with load balancing the monitoring displays need to automatically populate and adjust to the changes.

These intelligent views then allow you keep your SLA commitments even in these highly dispersed “bursting” or “mixed” deployment environment by quickly identifying the reasons for problems when they happen, and proactively responding before problems become outages.

And – by the way – Nimsoft Monitor was built from the ground up to support these types of distributed views, applications and environments, it’s a great match for your needs.