thinkWork @ komalk : Agentless Exception Monitoring

AEM: Resource Kit Tools!

Komal — Thu, 27 Sep 2007 20:48:00 GMT

SCOM 2007 resource kit tools has been released and can be found here.

Two of these are of particular interest for AEM:

AEM Validation: This tool can help validate that AEM is working once it has been enabled on a SCOM 2007 installation. This tool can be found here.

AEM Generic Mapping: This tool maps a lot of unknown application errors to more specific information. This tool basically comprises of a new MP that needs to be imported into the SCOM system.

AEM: Changing Threshold Values (via SDK)

Komal — Thu, 28 Jun 2007 00:06:00 GMT

In the last blog post, it was described how overrides for AEM applications/error groups can be changed via submitting discovery data for Microsoft.SystemCenter.CM.AEM.MonitorOverride through a management pack. Same can be achieved via writing code against the SDK service. Below is a snippet of code that can help achieve the same.

namespace AEM_Samples

{

using System;

using ObjectModel = System.Collections.ObjectModel;

using Microsoft.EnterpriseManagement;

using Configuration = Microsoft.EnterpriseManagement.Configuration;

using ConnectorFramework = Microsoft.EnterpriseManagement.ConnectorFramework;

using Monitoring = Microsoft.EnterpriseManagement.Monitoring;

public class AEMDemoClass

{

private void SetOverrides()

{

// Connect to the sdk service on the local machine

ManagementGroup localManagementGroup = new ManagementGroup("komalk-test");

// Retrieving information about ClientMonitoring library MP

Configuration.ManagementPack aemLibraryMp = localManagementGroup.GetManagementPack(

"Microsoft.SystemCenter.ClientMonitoring.Library",

"9396306c2be7fcc4",

new Version("6.0.5000.0"));

// We need to create as many CustomMonitoringObjects as we have overrides

// to be defined

// So, let's figure out how many applications as of now the

// OpsMgr system knows that meet the given requirement (appName = 'sample.exe'

// appVersion like '%'.

// Let's 1st get class type for application

Configuration.ManagementPackClass applicationClass =

aemLibraryMp.GetClass("Microsoft.SystemCenter.CM.AEM.Application");

Configuration.MonitoringClass applicationMonitoringClass =

localManagementGroup.GetMonitoringClass(applicationClass.Id);

ObjectModel.ReadOnlyCollection<Monitoring.MonitoringObject> apps =

localManagementGroup.GetMonitoringObjects(

new Monitoring.MonitoringObjectCriteria(

"ApplicationName = 'sample.exe'",

applicationMonitoringClass));

if (apps.Count == 0)

{

// there are no Apps whose override value can be set;

return;

}

// Let's get class type id for Microsoft.SystemCenter.CM.AEM.MonitorOverride

// defined in MP: Microsoft.SystemCenter.ClientMonitoring.Library

Configuration.ManagementPackClass monitorOverrideClass =

aemLibraryMp.GetClass("Microsoft.SystemCenter.CM.AEM.MonitorOverride");

Configuration.MonitoringClass monitorOverrideMonitoringClass =

localManagementGroup.GetMonitoringClass(monitorOverrideClass.Id);

// Let's get information about various elements on this class

Configuration.MonitoringClassProperty managedEntityIdProperty =

monitorOverrideMonitoringClass.GetMonitoringProperty("ManagedEntityId");

Configuration.MonitoringClassProperty errorCountProperty =

monitorOverrideMonitoringClass.GetMonitoringProperty("HitCountThresholdValue");

Configuration.MonitoringClassProperty userCountProperty =

monitorOverrideMonitoringClass.GetMonitoringProperty("UniqueUserThresholdValue");

Configuration.MonitoringClassProperty computerCountProperty =

monitorOverrideMonitoringClass.GetMonitoringProperty("UniqueComputerThresholdValue");

// For all these applications, lets set new override values for all 3

// basic threshold parameters

// we achieve this by submitting a MonitorOverride information about each

// to submit we need to add each instance of CustomMonitoringObject to

// discovery data below

// Discovery Data would contain class Instance for AEM Crash Listener

ConnectorFramework.IncrementalMonitoringDiscoveryData discoveryData =

new ConnectorFramework.IncrementalMonitoringDiscoveryData();

for (Int32 idx = 0; idx < apps.Count; idx++)

{

Monitoring.CustomMonitoringObject aemMonitorOverride =

new Monitoring.CustomMonitoringObject(monitorOverrideMonitoringClass);

// Key:

aemMonitorOverride.SetMonitoringPropertyValue(

managedEntityIdProperty,

apps[idx].Id);

// Non-Keys:

aemMonitorOverride.SetMonitoringPropertyValue(errorCountProperty, 100);

aemMonitorOverride.SetMonitoringPropertyValue(userCountProperty, 150);

aemMonitorOverride.SetMonitoringPropertyValue(computerCountProperty, 200);

discoveryData.Add(aemMonitorOverride);

}

// Committing makes sure the data is submitted to the system now

discoveryData.CommitForUserDiscoverySource(localManagementGroup);

}

} // end of class

} // end of namespace

More about inserting discovery data can be read here.

It should be noted that this approach only takes care of submitting overrides for applications that are known to OpsMgr and match given criteria. Where as the MP approach takes care of applications new to OpsMgr have overrides defined/submitted periodically.

AEM: Changing Threshold Values (via MP)

Komal — Tue, 26 Jun 2007 20:44:00 GMT

Various error groups and applications that report crashes over period of time can be seen in AEM Views.

The state of each error group is controlled by 3 thresholds: error/crash/hit count, unique users affected, unique computers affected. By default, the threshold value for all these 3 parameters is 50. In other words, if any error group has a error count and/or unique users affected count and/or unique computers affected count exceeding 50 then the health of corresponding error group goes red affecting it's availability aspect.

The state of each application is also controlled by 3 direct thresholds: error/crash/hit count, unique users affected, unique computers affected. But it is also affected by state of any of the error groups it hosts/encompasses. The threshold for the 3 basic thresholds is 50 here too.

These basic threshold values can be changed by submitting an instance of Microsoft.SystemCenter.CM.AEM.MonitorOverride for each error group/application whose threshold values need to be changed. This class type has 4 properties: ManagedEntityId and new value for the 3 thresholds. The ManagedEntityId can correspond to either ID of a watson bucket/application error group or ID of an application.

Attached is a sample/demo MP that shows how to change the threshold values. Let's analyze various parts of the MP.

<Category>Discovery</Category>

</DiscoveryTypes>

</DataSource>

</Discovery>

The above discovery tells us that the new threshold values for all the 3 basic monitors is going to be 100 for all applications whose applicationName is foo.exe irrespective of their applicationVersion.

Let's look at the composition of the module type ApplicationThresholdDefiner used above.

</Node>

</Composition>

There are 4 modules used: Scheduler (System.Scheduler from System.Library MP) followed by OleDbProbe, followed by Filter (System.ExpressionFilter from System.Library MP) and then followed by DiscoveryMapper.

The Scheduler module is configured to 15 minutes in the MP and can be changed. What does this indicate? This indicates that if new applications are discovered by the system which meet the criteria defined by user, then in 15 minutes (worst case), a threshold override would also be submitted to the system.

The OleDbProbe module retrieves the managed entity id for one or more applications meeting given criteria.

The Filter module ensures that there's at least one application known to OpsMgr via AEM that meets given criteria.

The DiscoveryMapper module is responsible for submitting override data to the system in form of instances of the class Microsoft.SystemCenter.CM.AEM.MonitorOverride defined in Microsoft.SystemCenter.ClientMonitoring.Library MP.

Similar composition has been provided in attached MP to change threshold values for 1 or more error groups.

It should be noted that the state change for all error groups and applications is computed every 15 minutes. As a result, with the attached sample MP, it can take upto 30 minutes to reflect the override changes in the OpsMgr console.

This max. value can be reduced to 15 minutes by reducing the configuration of scheduler module from 15 minutes to 30 seconds or something like that. However, reducing the configuration for scheduler module would have an impact on performance as that determines how frequently the OpsMgr DB is hit with queries as defined in the compositions in the sample MP.

However, based on user requirements, the value can even be bumped up or changed to a schedule basis as well.

Agentless Exception Monitoring (AEM)

Komal — Wed, 06 Jun 2007 22:59:00 GMT

The AEM feature in Operations Manager 2007 is next step from CER 2.0. A training video is available here.

As such, AEM falls under the umbrella of Client Monitoring which in its current state also emcompasses other features like Customer Experience Improvement Program (CEIP). A white paper on Client Monitoring can be read here.

Operations Manager SDK contains helper classes for programming with AEM under Microsoft.EnterpriseManagement.Monitoring.ClientMonitoring namespace.

There's a lot available online to read about AEM (one such read is here) and so the next few blogs on AEM would focus on how you can customize AEM as per your needs.