It's a relatively simple chain of events:
- Businesses rely more and more on their information technology infrastructure.
- As they do, managing the technology becomes more complex.
- By increasingly taking over these management tasks, simplifying them or removing them from human interaction, autonomic computing technology reduces the impact of this growing complexity.
The key to completing this series rests in understanding -- the network (or networks), applications, operating systems, any system component -- they all must communicate for the system to act as a whole, whether in the role of automating configuration, optimization, protection, or problem resolution.
One important part of that common language is the Common Base Event. This component is so important to any effort to automate IT management tasks that it is the essential starting point for a partial or fully autonomic computing system. It is the lingua franca that lays a common foundation that makes autonomic computing technology possible, which is why it is critical to get this working correctly first as a basis for enabling all the aspects of autonomic computing.
This is why I'm introducing a very important document in this article -- the recently released guide, "Best Practices for the Common Base Event and Common Event Infrastructure: Guidelines for Using IBM's Initial Implementation of the WSDM Event Format." I'll highlight some of the interesting bits of knowledge in this document, giving you a quick overview of the guide and showing you samples of some of the best practices for capturing and generating Common Base Events, the standard event format that addresses the two issues of notification diversity: formats and the content you use to represent situations.
"Best Practices for the Common Base Event and Common Event Infrastructure" is part of the Common Base Event library and is intended to supplement the Common Base Event specification. It includes the following sections:
- Purpose of Common Base Events
- Scope of the document and who should read it
- Definitions of autonomic computing, Common Base Events, and Common Event Infrastructures (CEI)
- Definition of the Common Base Event structure
- Detailed descriptions of the required elements for Common Base Events
- Detailed descriptions of the optional, but important, elements for Common Base Events
- A comparison of required to optional elements
- Three important scenarios (lifelike examples you're probably going to encounter):
- Considerations for problem determination events
- Considerations for business events
- Bridging the gap between the problem determination and business events
- References and appendices, including related reading and a great sample simple Common Base Event
The guide also provides solid definitions for the following.
Definition: Autonomic computing and Common Base Event
The guide starts by defining what autonomic computing does (shifts the burden of managing IT systems from IT professionals to the systems themselves) and demonstrates the Common Base Event format's place in this definition (it is one fundamental enabler for self-managing autonomic systems that can be used to communicate situations that arise throughout the IT system).
In other words:
- Autonomic computing (the concept) reduces the IT management workload for the IT professional.
- Common Base Event (the common language) enables full-system communication of states.
Now all we need are the tools to do the work! (Don't worry -- they're available!)
The guide also defines an event as an indication of an occurrence, that something of potential interest has happened. According to the Common Base Event specification, "Events are external, visible manifestations of all systems operations -- they represent the onset, evolution, and conclusion of processes both large and small."
Definition: Problem determination
Problem determination is the detection and diagnosis of situations that affect the operational status or availability of business applications. The overarching goal of problem determination is to maximize business and IT system availability by minimizing the time it takes to recover from situations that affect system availability.
What are the different events?
There are various kinds of events in a system that are generally targeted for different purposes. Although these event types are not normatively defined, it is useful to discuss the events that are used for specific purposes. The Best Practices guide discusses two such kinds of events: problem determination events and business events.
Problem determination events support the process of problem determination (naturally) and can incorporate many types of data such as information on operational status, state changes, request processing, performance metrics, and faults. They usually come in two flavors:
- Log events are typically reported by components of a business solution to users and administrators during normal deployment and operations (in production environments).
Now, you say that they are already used as the first indicators of problems occurring in a system. That's true. Humans scan the logs looking for a problem or the system is keyed to warn an admin if a certain event or string of events takes place. So why go to the trouble of converting log files to the Common Base Event format?
With a common format for all log files (and other tools), your system can go quickly from a basic level (like I've just described) to a managed autonomic level (in which logging tools and scripts can automate routine reporting and task management) and probably even further, to a predictive level (in which a knowledge base proposes to the admin what has happened and solutions to the situation).
- The second flavor is diagnostic or trace events, those used by support teams and developers of components to capture internal diagnostic information about a component.
These types of events are not typically reported or available during normal deployment and operations (production environments). Diagnostic events are used mostly to diagnose problems within a component and can help to trace (hence the name) problems if the log events do not contain sufficient data to do so.
Getting it right the first time is the theme of this guide, so the guide will focus mostly on log events; however, the process you learn to use log events applies to diagnostic events too.
When something happens that is of interest to the operation, monitoring, or management of the business, that is a business event. Remember:
- The focus of a problem determination event is an IT resource.
- The focus of a business event is an indication of something that is important to a business process.
Processes like business entities (retail store, transportation path, sales quotas, distribution nodes). The primary person responsible for analyzing these events can vary from company structure to structure; the important thing this guide points out is that you have to distinguish this person's role from those of the IT teams.
There are two flavors of business events too:
- Raw events sometimes do not directly correspond to a recognizable business event.
The word "raw" is the key to understanding here. Raw events could include order submissions, fulfillments, and inquiries. After these are captured, correlated, and compared to an established rule or practice, then they form:
- Derived events. Sort of for communicating potential trend or recognizable business event.
For example, after correlation, a derived event could signal that a possible security violation has been committed (sale of restricted material or technology outside an allowed zone, sale of too much of a controlled material, and so on).
Although business events differ in focus and audience than IT events, the Common Base Event is suitable for communicating both types of events.
Why should I use Common Base Events?
The simple answer is that without the standardization that the Common Base Event format offers, automated situation handling becomes difficult. (To be realistic, for many people the handling becomes impossible.)
OK, that's why you should use Common Base Event. This guide also shows you:
- When to use (any time you need to promptly inform management components, including humans, in the IT infrastructure about occurrences in the environment that are noteworthy and of interest from a management perspective).
- How to choose between using Common Base Events and Application Response Measurements, a popular method for collecting and representing monitoring data related to resources in an IT environment (and that can be encapsulated in a Common Base Event).
- How Common Base Events related to other formats (and more importantly, how they can be converted to Common Base Events without data loss).
What's an event infrastructure?
An event infrastructure, in this case the Common Event Infrastructure (CEI), is an embedded component that supports reporting, persistence, distribution, and interpretation of event data based on the Common Base Event format. Incorporated into several IBM products, the CEI includes these components:
- CEI Server, a Java™ 2 Platform, Enterprise Edition (J2EE) application running in WebSphere® Application Server (Application Server), it is responsible for determining whether and how to distribute and persist events. Requires a local WebSphere Application Server instance.
- CEI Emitter, a library that provides support for applications to report events to the CEI server, can run in a J2EE container or as an Application Server client. Requires the WebSphere J2EE application client library.
- CEI Catalog provides metadata information about events handled by the CEI and is not typically accessed by the other CEI components.
- CEI Access is a client library that provides support for event consumers to perform synchronous event queries, event updates, and purges of the event repository.
- CEI Helper is an optional client helper class that helps event consumers map JMS messages into Common Base Event objects when receiving events from JMS subscriptions.
For generating and using Common Base Events, CEI requires this use of the common programming model that comes with the TPTP Eclipse project. If you want an application to use CEI, you must install the CEI Server components and configure the event repository during installation.
What if I want to do my own Common Base Events?
The guide describes a programming model used to format and capture Common Base Events and provides best practices for these operations even though the facilities used to format and capture events can vary by implementation. It also contrasts the Common Base Event CEI programming model (from the open source TPTP Eclipse Project) with the JSR 47 programming model, the Logging API Specification that defines standard logging APIs for error and trace logging. (Did you know that most basic event capture interfaces are specific to a specialized class of events; for example, JSR 47 is used to capture such problem determination events as log and diagnostic events. This guide is chock full of tidbits of useful information like this!)
The guide also offers CEI run-time characteristics that affect or are related to the Common Base Event and CEI programming models.
In the guide, Section 2.2.1 showcases a table that compares the required and optional elements for problem determination and business events; it also shows you which are recommended, prohibited, and discouraged, giving you a great guide to proper usage with as many options as possible.
In fact, Section 2 on using Common Base Events is extremely detailed, commenting on the structure of Common Base Events and providing granular-level insight into the required and optional elements of Common Base Events.
So, I haven't seen any best practices yet?
OK, here's one. It is a best practice to:
- Generate a Common Base Event any time you need to promptly inform management components, including humans, in the IT infrastructure about occurrences in the environment that are noteworthy and of interest from a management perspective.
To demonstrate the level of detail, here are a few other samples of best practices from the manual:
- As a best practice, event producers should share event metadata by populating the event catalog with event definition records. Event consumers can browse or extract from the catalog to determine the types and content of events available for subscription.
- Event factories are named using the standard Java dot-delimited naming convention. Factory names should resolve to a system, component, package, or class name, depending on the granularity of the configuration template.
- The application can use any
EventFactoryto create a Common Base Event, but it's best to use the sameEventFactoryand template files employed by the underlying event capture run time's basic event capture interface. - Event group qualification is run in the CEI server. Event selector filtering is run in the CEI client. When specifying event groups and event selectors, consider this difference that can affect performance characteristics.
- To achieve adequate performance, event queries should be defined such that the resulting set of events should return a relatively small number of events, and events that are relatively small in size.
The guide not only box-highlights best practices to supplement the regular text, it also includes notes, which consists of instructions on common "gotchas" to watch for and also common setting and implementation parameters that could affect your use of Common Base Events. Some notes for example:
- Event groups that are too broad (selected with coarse granularity) could create unnecessary overlap among events. This can result in duplicate data being published with separate events and can have a negative impact on the overall application performance.
- Overlapping event groups can result in duplicated events being received when subscribing to multiple event groups.
- Event groups that are too narrow (selected with fine granularity) could create event groups that might not be used (that is, might never match the event group selector) and could have a negative impact on the overall application performance.
- This version of the Common Base Event does not provide a specific property to identify installation information. You could use the
ExtendedDataElementproperty to provide information that identifies the installation image of the component reporting the event (perhaps with anextensionNameofInstallIdof type string).
You got 'em. Three of the most probable scenarios are described in detail:
- Using Common Base Events in problem determination applications (an IT event)
- Using Common Base Events in business process applications (a business event)
- An integrated view of using Common Base Events to "bridge" IT (such as problem determination) events and business events
Each of these scenarios is extremely detailed and leaves almost no questions unanswered. At the very least, they should springboard you 90 percent of the way into using Common Base Events to enhance your own systems. (The number, 90 percent, is the author's opinion; IBM is in no way guaranteeing this level.)
And for those of you who want a simpler example, Appendix B provides one. The example describes how to use the required elements of a Common Base Event to generate a correct, complete, minimal Common Base Event. This scenario considers a managed resource that periodically reports a "heartbeat" signal to its autonomic manager to indicate that it is still operational (in this case, an instance of Red Hat Linux®).
This is just a small bite of the Common Base Event Best Practices apple -- the best way to start employing Common Base Events is to refer to the guide and to the specification.
Over the next few months, developerWorks will be detailing various sections of this guide through articles written by the technologists who wrote the guide and who develop and work with autonomic technologies and components.
Learn
-
"Common Base Event Best Practices Guide": Get the entire document at the IBM Autonomic Computing Toolkit Web page.
-
"The Common Event Infrastructure: From technical preview to production" (developerWorks, April 2005): This article provides an overview of the changes and added functions of the Common Event Infrastructure from technical preview to production release.
-
"Create a simple resource model for processing Common Base Events from a file" (developerWorks, June 2004): Learn how to create a simple resource model for processing Common Base Events that are stored in a file.
-
"Standardize messages with the Common Base Event model" (developerWorks, October 2004): This article explains how the model provides a sound base for problem determination.
-
"Meet the experts: Abdi Salahshour" (developerWorks, May 2005): Abdi Salahshour explains how the Common Base Event format lays the groundwork for true autonomic maturity.
-
"Using the Common Event Infrastructure with WebSphere Studio" (developerWorks, December 2004): This article shows how CEI solves the problem of diverse and inconsistent logging formats and infrastructures and can be used to help integrate technology for applications and solutions that need to produce and consume Common Base Events.
-
"Common Base Event logging" (developerWorks, April 2005): Learn how to configure Common Base Event logging in the Java language. This tutorial shows how.
-
"Streamline Common Base Event logging" (developerWorks, January 2006): This tutorial shows you how to streamline Common Base Event logging instrumentation in the Java programming language to reduce complexity and instrumentation code size.
- developerWorks technical events and webcasts: Stay current with the latest technology.
- developerWorks Autonomic computing zone: Expand your knowledge of automating systems.
- developerWorks blogs: Get involved in the developerWorks community.
Get products and technologies
- Autonomic Computing Toolkit: You can start your autonomic computing journey with the IBM Autonomic Computing Toolkit.
- Common Base Event Specification v1.0.1: This specification defines a mechanism for managing events in business enterprise applications and shows how to communicate events in the autonomic computing model.
- IBM trial software: Build your next development project with trial software, available for download directly from developerWorks.
Discuss
- Dave Bartlett's blog: Listen in as Dave talks about integrating autonomic computing standards and capabilities throughout every layer in a system.
Kane Scarlett is the editor of the Autonomic computing technology zone for developerWorks. His past publishing work was with such magazines as Unix Review, Advanced Systems, and the -World publications (Java-, Sun-, NC-, Linux-), as well as some little oddball journals like National Geographic Magazine.
