Last week our test team finished the battery of tests and validation documentation that comprises Citrix’s interoperability test suite for XenServer and I am happy to report that the Blue Medora ITM Agent for Citrix XenServer has been validated by Citrix to be compatible with Citrix XenServer 5.5 and the newly released XenServer 5.6.  This validations spans all editions of XenServer including Free, Enterprise, and Platinum.

Kudos to our interoperability team as well as the development team that has spent a good bit of the past 12 months developing this new Agent.   We are really looking forward to wrapping up the Beta at the end of July and seeing our customers finally deploy it into their production environments.

It’s here! Today we are announcing the open beta for our newest agent, the Blue Medora ITM Agent for Citrix XenServer.

The Blue Medora ITM Agent for Citrix XenServer provides deep, meaningful data about a customer’s XenServer environment through their existing IBM Tivoli Monitoring infrastructure. That means all of your important data with the convenience of one consolidated monitoring environment. View the utilization of important system resources, be made immediately aware of pool master changes and other important events, and closely monitor patching and XenServer tools information.

The Citrix XenServer Agent is our biggest and most advanced agent to date:

• ITM subnoding gives extensive information on each individual hypervisor in your XenServer environment
• Historical data for monitoring long term performance or problem areas
• Monitor CPU, Memory, Network and Disk Utilization
• Monitor XenServer Tools updates and status
• 12 Pre-made ITM situations to alert you to important events such as license expiration or very high CPU utilization
• Pool Master outages are detected, while monitoring automatically switches to the new Pool Master
• SSL connection is available for secure agent monitoring



If you are interested in joining the Blue Medora Beta program, please visit our Beta Download Center to get started!

For more information about the Blue Medora ITM Agent for Citrix XenServer, please visit the product page.

Create and Configure a KVM Guest

Here at Blue Medora we spend a lot of time working with IBM’s ITCAM for Apps: Siebel CRM Agent. One of the questions that we’ve been seeing a lot lately is whether v6.1 of the Siebel agent is able to run on Windows Server 2008. We did some testing and found that it can – with a few extra steps that aren’t yet documented in the Siebel Agent User Guide. The note below describes the installation process required to install the Siebel v6.1 agent on Windows Server 2008 32-bit.

Question:
Can the ITCAM for Applications: Siebel CRM v6.1 agent be installed on Windows 2008?

Answer:
Yes, however, there are additional steps beyond what is documented in the User Guide. The following steps document the process of installing the ITCAM for Applications: Siebel CRM v6.1 Agent on Windows 2008.

Note: 64-bit versions of Windows 2008 are not supported by the ITCAM for Applications: Siebel CRM v6.1.

The summarized list of steps (that are covered in more detail below) are:

1. Install a supported version of the Universal Agent
• Universal Agent v6.1 FP7+
• Universal Agent v6.2 FP1+
• Universal Agent v6,2.1+
• Universal Agent v6.2.2+
2. Install IBM Java 1.4.x
3. Install Siebel Agent
4. Install Siebel Agent IF3
5. TEMS/TEPS machine that has siebel 6.1 with IF3 Application Support Installed

In the scenario below, we used UA 6.2.2GA, however, as long as you use one of the versions of UA supported (see above), it should work. The output below was taken from a Windows Server 2008 Enterprise 32-bit edition running Siebel 8.0 Application and Gateway Server.

Installing ITM 6.22 Universal Agent:
Check to make sure the Siebel Gateway and Siebel Application Server services are started:

Install ITM 6.2.2 TEMA universal agent. The Agent does not need to be started, this installation is only for installing specific libraries that are needed by the Siebel agent.

When selecting what features to add, make sure to check the universal agent. This selection will also check TEMA Framework if not already checked. Checking these features ensures that the correct libraries are installed.

Once the agent is installed the local TEMS should show the new Universal Agent with the version 06.22.0.00.

Next install ibm-java2-jre-142-SR8 on the agent machine from the Java setup utility that can be found in the ITCAM for Apps Siebel 6.1 agent install media.
[install_dir]\InIBMJRE\ibm-java2-jre-142-SR8

After the Java installation is complete, check that the JAVA_HOME environment variable was set and the %JAVA_HOME%\bin directory was placed in the path:
C:\>java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20070317 (SR8) (JIT enabled: jitc))


Installing the Siebel 6.1 ITM Agent:
When prompted to Upgrade IBM JAVA, the “Current Version:” should be similar to the below picture and not be blank. Make sure to uncheck “Upgrade IBM JAVA” check box and click Next.

When the installation is complete do not configure a new agent yet. Before we do so, you must first upgrade the agent to IF3.

Upgrading The Siebel Agent to IF3:
Open up a command prompt and run the itmpatch utility to patch the agent installed in the previous step.
C:\Users\Administrator>itmpatch -h C:\IBM\ITM\ -i C:\User\Administrator\Desktop\6.1.0-TIV-ITM_SIE-IF0003\

After the agent is patched you can configure the agent from the Siebel template. If you tried configuring the agent before patching it, the configuration would not be able to find the installed version of Siebel.

To check that the installed media is the right version build run in the command prompt:
kincinfo -i

… and you should be able to find the snippet that says:
UB Monitoring Agent for Siebel
WINNT Version: 06.10.00.03 Build:

Next, right click Monitoring agent for Siebel Template and select “Configure Using Defaults” and configure the agent following the instructions in the User Guide.

Finally, after all the configuration is completed, start the new Siebel agent found in the local TEMS. Right click on the monitoring agent for Siebel and select start, to start the agent.

If you have any questions or comments about this post, or anything else related to the Blue Medora ITM Agents, contact me at: matthew.rumph@bluemedora.com
- Matthew Rumph

In today’s post, we will continue looking at the Blue Medora ITM Agent for Amazon EC2 with a walkthrough of the agent in the TEP. In this post, we will consider a number of enterprise scenarios and use the agent to solve them. It is my hope that the information given here will help you to quickly begin taking advantage of the agent’s features in your ITM environment.

– Mike Major

EC2 Service Unavailable

Let’s start with an easy one: Amazon is known for their uncanny ability to maximize the up-time of their services, but even they may experience some downtime or slow time once in awhile. In this scenario, let’s assume that an EC2 instance is not responding and we want to know if we currently have a connection to the service.

This problem is easily solved by clicking the AWS Health node:

Here we can see a quick overview of the status of all Amazon Web Services. Near the bottom, we can also view our current connection with the EC2 and CloudWatch services.

There are also a couple of pre-packaged situations that could help us to become aware of an unreachable service. The situations KB5_EC2_Unreachable and KB5_Cloudwatch_Unreachable fire when there is no response from the EC2 service or CloudWatch service respectively. We will get into the ITM Situations available a little more in the next scenario.

CloudWatch Enabled Instances

Consider this scenario: The system’s administrator for your enterprise needs CloudWatch data to keep a close watch on the performance of your EC2 environment’s instances.

The first thing we will want to do is determine how to view the needed CloudWatch data in the TEP. From the TEP desktop client, we will first view the collected CoudWatch data for all the instances. Click the CloudWatch Summary node:

Here we get a quick overview of the major CloudWatch data such as CPU utilization, network activity and disk operations. For a more detailed look at any of these areas, we can right click the node, click Workspace, and click the workspace view for the data you are interested in:

If we have warehousing enabled, we can view historical CloudWatch data for the last hour, day or week. Let’s take a look at the last day:

Historical views give a quick, graphical indicator of the trends of data in your environment. They can be used to debug problem areas and identify areas that could handle a bigger workload. We can also view the instances that currently have CloudWatch enabled and disabled. Let’s do that now:

Here we can see the instances with CloudWatch enabled or disabled. We can view this table to learn when an instance’s CloudWatch monitoring was disabled, but a better solution would be through an ITM Situation. We will take a look at that later. For now, let’s take a look at the CloudWatch data for a specific instance. Expand the Amazon EC2 Instances node. Then expand the instance you are interested in and click the CloudWatch node:

Here we can see much of the same information as the higher level CloudWatch node, except this information is unique to this specific instance. Like above, we can view historical data with warehousing enabled by right clicking the CloudWatch node and clicking the view we would like to see:

Historical data for a specific instance is very useful for analyzing the performance of an instance. In our scenario, this may be the screen that the administrator is most interested in:

Now, we want to know when one of our instances has CloudWatch disabled, since we are depending on the CloudWatch data for noticing any problem areas. Like I mentioned earlier, we could check this list to see when one of our instances does not have CloudWatch enabled, but that is tedious and takes unnecessary time out of our day. A better solution would be using an ITM Situation. Specifically, the pre-packaged situation named KB5_Instance_CW_Disabled.

To start the situation, right click the instance node and click Manage Situations:

We will now see a list of the available situations for this agent. Click the KB5_Instance_CW_Disabled situation, and Start Situation… near the top (It looks like a ‘play’ button):

Now that we are being notified that our instances have CloudWatch disabled, let’s fix the problem with an ITM Take Action. Right click on the Amazon EC2 node and click Take Action… followed by Select…:

Choose the Start_CloudWatch_All_Instances Take Action and click OK. You could also start CloudWatch for a single instance by right clicking on the Instance node to choose a Take Action:

Congratulations! Your Instance now has CloudWatch enabled!

Critical Servers

Consider this scenario: You have a number of critical servers on your Amazon EC2 environment. These servers need to be running smoothly in order to work effectively.

To solve this problem, we need to first set a situation to warn us when a critical server has a very high CPU utilization. Luckily, the agent comes with a couple pre-packaged situations that do just that.

Navigate to the Manage Situation screen as in the above example. We have two pre-packaged situations to choose from, KB5_Instance_CPU_Warn (which warns us of CPU utilization from 75% – 90%) and KB5_Instance_CPU_Crit (which warns us of a CPU utilization of 90% or higher). Choose the one that feels the most appropriate and click the Start Situation button:

Now that we are aware of any instances behaving badly, let’s fix the situation. Most likely, the instance is being overtaxed. Identifying these instances with the situation warnings will allow you to be aware of whether or not it is time to spawn off another Amazon EC2 Instance and balance the workload.

Let’s assume that, in our example, the problem is a simple runaway process. One way to fix this might be to reboot the instance at the end of the work day. We can do this with a Take Action. Right click the node of the instance in question and navigate to the Take Action window as in the above example. Now choose the Reboot_EC2_Instance take action and click OK:

Notice the list of instances at the bottom of the screen. The instance we are working with is highlighted by default, but you can choose to reboot more instances at the same time by holding the Ctrl key and clicking the instances you would like to reboot. Click OK and the instance will reboot!

Well, that’s it for now. I hope these scenarios have given you a good idea of the power behind the Blue Medora ITM Agent for Amazon EC2. As always, if you have any questions regarding this post, the Amazon EC2 Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

I have been extremely excited about the upcoming release of our newest ITM Agents, the Blue Medora ITM Agent for Amazon EC2 and the Blue Medora ITM Agent for Citrix XenServer. Today I want to take a quick, video walkthrough of the Amazon agent and give you a peek at some of its capabilities and features. I hope you enjoy the video!

If you have any questions regarding the video, the Amazon EC2 Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com