Mike Jasnowski's Blog

GET INVOLVED

New to Java?
Blogs
CodeShare
Newsgroups
User Groups
Submit Content/Code

PRODUCT CENTERS

BEA AquaLogic
AquaLogic BPM Suite
AquaLogic Service Bus
WebLogic Platform
WebLogic Server
BEA Workshop
WebLogic Portal
WebLogic Integration
BEA JRockit
WebLogic Event Server
BEA WLCP
More Product Centers

TECHNOLOGY CENTERS

Controls
Web Services
Eclipse
XML
EJB
Persistence
JMS
Vertical Markets
Dev Toolbox

BROWSE BY ROLE

Platform Admin

RESOURCES

Dev2Dev Media Center
Article Index
Open Source
Security Advisories
Utilities & Tools
Events Calendar
About Dev2Dev

Dev2Dev Newsletter
RSS/XML Feeds

Dev2Dev > Community > Blogs

Mike Jasnowski's Blog

Michael Jasnowski's Homepage
Mike Jasnowski is a staff engineer at BEA Systems in the OA&M group, leading the WebLogic Server Administration Console team.

Using WLOC in a non-virtualized environment

Posted by masterchief on April 2, 2008 at 8:02 AM | Permalink | Comments (0)

Wow it's been a while since my last entry (, but with GA on the horizon ya gotta focus, you might also have noticed a product name change since then as well LOC > WLOC. Same product, anyways.
With WLOC you can manage both virtualized and non-virtualized endpoints, in the latter this means you can take an existing WLS server based product and use LOC to manage it. Much of my day to day development for WLOC is done in a non-virtualized environment. What this basically means is that I downloaded a BEA Product Kit, installed it on my laptop taking pretty much all defaults, I then run my development environment and configure WLOC to point at that Product Kits BEA_HOME.

I run a WLS 9.2 installation currently from a standard GA kit and then configure a service to point at that installation. In this entry I'll show an example of taking a 9.2 GA kit and setting up a simple service with 2 managed endpoints (1 Admin Server and 1 Managed Server). In my example my installation was installed under the location starting at c:/files For this example I'll use:

Weblogic Operations Control 1.0 (Download Here) - (Documentation)
An installed 9.2 GA Kit, thought 10.x series should work just as well

For WLOC I'll assume the following setup for now (both on same physical machine):

1 Controller on Windows XP/SP2 (Configuring Controller)
1 Plain Agent on Windows XP/SP2 (Configuring Plain Agent) - Do not define any available software for this agent for now

Defining the service metadata

In previous blog posts I wrote about defining service metadata. The service metadata describes the service itself and its requirements in the form of software and computing resources like memory and cpu and processes. For this plain simple case we'll focus on just describing the process requirements and 1 other requirement min-process that will enable WLOC to start our service. The followi.ng image provides a conceptual overview of how service metadata is constructed here.

To define the service metadata I'll first launch the controller and log into the WLOC Administration console. I'm sent to the homepage and from their I'll need to access the Inventory screens either by clicking on the "Inventory" tab at the top or "Services" on the home page. This displays the service table.

From the service table I click on "New" which presents the first screen of the assistant and then click "Next"

I'm presented with the "Process Requirements" table, here is where I will describe the processes needed to run my service. Since the beta there are some new ways to get a head start on describing service metadata which I'll describe briefly. The ones in boldfaced type are the new ones in 1.0.

From Scratch - This is the original method of doing everything by hand from scratch
From another Service - This allows you to import process requirements from another service you already have defined on the same controller
From a WebLogic Domain Configuration - This allows you to specify the path to a config.xml for an installed WLS Domain
From a Running WebLogic Domain - This allows you to connect to a running server (admin or managed, though admin is recommended) and build the metadata from the MBeans registered in the Admin Server

The import methods will attempt to fill out as much of the information as possible though they can't guarantee everything will be filled out. This is primarily due to differences in installations and configurations which may or may not have everything the import expects. This primarly affects import methods of the Configuration or Running variety.User names and Passwords are not imported

During import you can also optionally choose to either select which exact instances get imported as well as generate a summary report of things that could not be imported. For example if you have a 50 node cluster of WLS servers and were only interested in 2 of them you could do either 1) Import everything then delete them from the process requirements table or 2) Import but select "Allow me to choose which instances to import" which would then present you with the list and then you pick the 2 instances to import.

For this example we'll first chose "Add Process Group" and then choose "From Scratch" in the drop-down which presents me with a screen for specifying the name of the process group and the # of instances to use in that process group. When using the "From Scratch" method, the properties on this page will be used to stamp out a set of initial processes using the fields on this page. For this example I'll specify "WLOCAdminGroup" and specify 2 for the # of processes. I'm then returned to the process requirements table. Before finishing I need to ensure that each JVM process has the correct settings if I didn't specify them before during the initial create. Usually this will mean tweaking classpath entries and cmd line switches to ensure that the correct names and ports are passed. Port #'s are automatically incremented when you create the initial set of processes. Some key configurables are:


  Host
  Port
  UserName
  Password
  JVM Arguments - These will most likely be the same arguments you pass in startup scripts and or specify in ServerStartMBean configuration in config.xml. For example here are some the arguments I used in my setup.
    
      -Xmx128m
      -Xms64m
      -cp
      C:/files/bea/weblogic92/samples/server/examples/build/serverclasses; (truncated for brevity)
      -Dweblogic.Name=examplesServer
      -Djava.security.policy=C:/files/bea/weblogic92/server/lib/weblogic.policy   
      -Dwls.home=C:/files/bea/weblogic92/server
      -Dweblogic.RootDirectory=C:/files/bea/weblogic92/samples/domains/wl_server

As with the agent configuration we will not define any software requirements for the service for now, also leave the 'Ready Metric' fields blank.

Service Resource Requirements

Now that I have a set of processes I need to specify 1 more requirement so that WLOC will start the processes for the service. From the process requirements table I click on the process group in the table and then the "Add Resource Requirements" button. On the "Resource Requirements" screen I see the initial # of processes (min-process) is already pre-filled with the # of processes in the process group so I can click "Finish" here and back to the "Process Requirements" table. From here I click "Finish" and my service metadata is persisted and I'm returned to the services table.

Deploy the Service

I choose the service in the table and click "Start" which tells the controller to start moving the service into the deployed state. If you observe the service table Status column you will notice it transition through various states until it reaches the desired state of "deployed". Additionally you will notice that the "Processes" column will increment as processes are started. The event viewer at the bottom of the screen will also list the sequence of actions and steps the controller is taking to bring up the service and the various states the service and its processes transition through.

Deployment Rules

If you visit the "Policies" tab you'll also notice that there are 2 other rules which you did not explicitly create, these are deployment rules that the rules engine in WLOC requires to aid in handling the deployment and undeployment of the service. Along with these you will see the 1 min-process rule that I created in the service assistant.

Summary

And thats it, the most basic example of setting up a WLOC in a non-virtualized environment. You might be wondering now about the comments I made regarding available software. I had previously stated also that when defining service requirements, software requirements were one aspect of that, meaning "What software does my service require to run". Well, in this case I implicitly satisfied that requirement by specifying command line arguments, classpath and main class I specified in the process requirements and JVM/Procecss configuration. Additionally I can specify software requirements during or after service creation, and additionally I can specify available software on the resource pool the agent is managing. This will help WLOC more stricltly control which resource pool the service can make use of.

For example, If I had specified available software on the resource pool portion of the agent configuration required software named WLS92 Andspecified a software requirement on the service process group of software named WLS95 then I would see this message and the service processes would fail to start


Action Failed...StartServerAction Process creation for NewService1Foobar:NewServiceProcessType:AdminServer-AdminServer failed. Error is [ResourceBrokerPool:2012209]Could not find placement possibilities for the requested resources due to some errors. Errors are: [com.bea.adaptive.jvmbroker.JVMCreationException: [ResourceBrokerPool:2012226]Resource pool resource-broker-agent cannot handle jvm since it does not contain the requested software [NfsSoftwareRequirement:WLS95 c:/files/bea/wls10]]

Liquid Operations Control Services,SLA's and Resource Monitoring

Posted by masterchief on December 14, 2007 at 6:59 AM | Permalink | Comments (0)

In my previous post I gave a quick summary of features in the LOC product, as well as their management capabilities from the LOC administration console. In this post I'll begin diving a bit deeper into each section starting with Service Configuration.

LOC Services

The term service is thrown about quite frequently these days, and is of course part of everyones favorite acronym SOA.
A service in LOC at a high-level is a collection of software and processes. Breaking this down further a service can be a single Java application or multiple Java applications running across processes. The processes in this example are instances of WLS, which can be running virtualized or non-virtualized. You can read some about services here LOC Feature Overview

Service MetaData

When a service is defined, you specify metadata about the service in the form of requirements. These requirements indicate things like what software is needed (WLS for example), how much CPU and Memory are expected to be required, as well as some additional metadata that the software may need to start (i.e. point at WLS domain). These requirements are used to then place the service and find a resource pool from which the service can obtain the resources it needs.

A trip through the service assistant follows this general flow:

1) Define general service properties

2) Define service requirements like software

3) Define service requirements like CPU and Memory

Note:Most steps in the assistant can be performed after the fact from other screens. You can also certain aspects of a service for easier management.

For now I'll skip over the resource pool portion for now, but briefly mention that assuming a resource pool exists and is available both physically as well as from a resource availability perspective, the service can be deployed. Depending on the topology of your service this could be analogous to an entire WLS domain starting up Admin Server and all, along with its applications, etc.

SLA's and Resource Monitoring

Now that the service is deployed/running, the next thing to do is to make sure it behaves appropriately. What that behavior is exactly is primarily up to you and your requirements. But typically you may want to ensure that memory and CPU utilization stays within certain boundaries, you may want to ensure that on certain days (Holidays, etc.) more capacity is needed, and possibly ensure that applications that are part of the service are running at expected times. You can of course also remove capacity at specified times as well.

SLA's

Before you define an SLA you must first start with a rule definition. A rule definition indicates some expression which must be true, and as a result of the rule being true, some action or pipeline of actions (more than 1 action) must be run. In addition to a rule definition there must be an action and/or pipeline definition present. It's these two things that are then bound to a service to form the SLA. A rule definition as well as actions and pipeline definitions can be re-used. The rules engine in LOC will then evaluate these rules periodically and other parts of the system will execute the actions and pipelines as necessary.

Probably one of the most common SLA's will be something to monitor the memory usage and send an email to an administrator who can the use the LOC administration console to correct the problem or investigate further. But that's just one example, there could also be further corrective action automatically taken, for example you may indicate that the process should be stopped if memory capacity exceeds a dangerous threshold. In this can you would probably also want to indicate that any action or pipeline that is execute must require explicit approval before executing. An operator or administator can receive requests either by an explicit popup or from a table of pending approval notices.

Resource Monitoring

In the general course of service lifecycle an administrator will need to monitor the resource utilization of a service and the processes used by the service, the LOC UI contains default charts on its detail pages for monitoring high-level attributes like CPU and Memory. You can drill in further to each process and see what each JVM is using in terms of CPU and Memory and you can also view CPU and Memory utilization of Resource Pools. You are not limited to monitoring at a single service level, you can monitoring at an aggregate level, or in WLS domain terms across domains .

In addition to the OOTB charts you can also create your own dashboards of the above resource metrics as well as others of your choosing. For example you may want to have a chart of application throughputs, or execute queue utilizations. The "Monitoring" tab of the LOC administration console contains a resource palette where you can use drag and drop to create charts and organize them into unique dashboards.

Console Notifications

By default the console will automatically update via PUSH, and the event viewer will receive notifications for things like (but not limited to) SLA violations, process starts and stops, etc.. There is a special action that can be run as part of your SLA to alert an administator specifically in the form of highlighting items in the UI, and send specific messages to an administrator or change an icon (not currently in beta kit). For example when the memory utilization reaches a certain point you could define a pipeline to:

1) Send an email
2) Send a message to event viewer
3) Turn the service to a specified color to draw attention to it

A console notification will be PUSHED to the UI without any intervention required or manual page refresh, the changes are of course persistent and will be seen until cleared by another rule and seen by other users who log in later. The nice thing about this is the behaviour is totally configurable and not baked into the product so you can define your own custom rules.

Hopefully this entry has given you a taste of what's possible, I'll add more in future entries.

Thanks, Mike

Liquid Operations Control Public Beta - Take control of IT

Posted by masterchief on December 7, 2007 at 6:32 AM | Permalink | Comments (2)

The recently announced Liquid Operations Control Beta provides a policy driven management framework for enforcing application and service level SLA's. I worked on the UI portion of the product which provides a number of administrative controls for the product. The console utilizes technologies like COMET and AJAX to provide a responsive, push based administrative console (more on this in a subsequent blog).The console provides the following capabilities at a high-level and I'd like to take a moment to briefly summarize:

Service Configuration

Services are the life-blood of any organization, they are the applications which provide the business functions both internally and externally. Services can be configured through the console along with the requirements of the service. The requirements dictate what the expected resource utilization of the service may be in the form of CPU, Memory , Software, etc. and this ultimatley translates into things like processes and other runtime artifacts utilized by the service such as application servers, etc at lower levels. Services can be viewed from the higher-level in the console and allows the requirements and processes to be viewed as well.

Policy Configuration

A policy(or policies) indicate a desired quality of service. For example an administrator may want to receive notifications of memory utilization of a single service or aggregated across the data center. A user can write a variety of policies which control the behavior of processes based on the values of metrics, as well as by date and time. For example during an expected peak load period a policy can trigger the creation of more capacity, which can then be decreased once the load period passes. The console displays all policies from a global level, as well as from a service and process levels. A user can create policy definitions which can be re-used over and over.

High-Level Monitoring

The console allows for varying levels of detail with regards to monitoring. The console allows services to be monitored at different levels, for example you can monitor the CPU utilization of a single service or aggregate of services, you can monitor a service at the process level, a single process or any combination of processes in a single service or across service in effect aggregating results. You can also go more fine-grained and monitor objects exposed via JMX in the processes themselves. The console provides configurable sets of dashboards (a.k.a views) which allow a high-degree of customization for the administrators monitoring needs, these views can be quickly switched between, there is no coding required to create these dashboards. From a technical level the console does not require any plugins to be installed or downloaded to use charting. The console also provides alternative visualizations in the form of tree and treemap views as well as access to logs

Role Based Access

The console was designed from the ground up to provide appropriate access controls from both a basic console function level, as well as a data level. For example a user in the Monitor Role will be able to see anything, create dashboards, etc. but not configure or change any aspect of configuration. Another example is a Service Administrator, the service administrator may be scoped for all services or a single service. In the single service case the user can administer and monitor their service only, which means they can only see their service in tree views, policy views, etc, and can only administer policies which affect their service.

System Configuration

And last but not least, the console provides access to the LOC configuration to allow a user to tune aspects of configuration, change logging, connect and disconnect from agents.

3rdParty

Not to worry, the product exposes alerts and notifications through various methods like SNMP, SMTP, JMS and JMX for integration with 3rdParty/external management products.

You can find out more about the LOC product from the following links. I invite anyone to download and provide feedback. I will also be blogging in the future about the implementation of various aspects of the UI as well as other aspects of the product.

Download

Documentation

Newsgroup

More on the performance applet extension

Posted by masterchief on March 1, 2007 at 7:54 AM | Permalink | Comments (0)

In my last blog post I showed you how to add the performance applet back using a console extension. As shown in the following image.

Performance Applet extension replacing original tab

Great, but the tab also contains alot of other information about JRockit that might be useful and it was just replaced. If you recall in my last post I also mentioned that replace was just one of the actions you could perform. With a analteration to the extension descriptor you can "add" the extension portlet to the original page without replacing the original contents as shown here.

<page-extension>
<page-location>
<parent-label-location label="ServerMonitoringPerformancePage"/>
<page-insertion-point layout-location="0" placeholder-position="0"/>
</page-location>
<portlet-content content-uri="/perf/perf.portlet" orientation="top" default-minimized="false" instance-label="performanceApplet"/>
</page-extension>

This snippet goes into the netuix-extension.xml descriptor, you should comment out the snippet since we don't want to replace the page anymore.
After the descriptor has been updated and extension redeployed the following screen shot shows that the performance applet is now embedded into the original page.

Performance Applet extension inserting into original tab

But what if you don't want to mess with the original page at all? Easy enough, just use this snippet to add the performance applet as a new tab to the Monitoring tabset.

<book-extension>
<book-location>
<parent-label-location label="ServerMonitoringTabmonitoringTabPage"/>
<book-insertion-point page-label="ServerMonitoringPerformancePage"/>
</book-location>
<page-content content-uri="/perf/perf.book" />
</book-extension>

By default when you add a new tab it will get placed at the end of the tabset. Which means depending on the size of the tabset you may have lots of scrolling to do. In the previous example we used the page-label attribute on the book-insertion-pointelement to insert the tab next to the original Performance Tab in the tabset. So as soon as you click on the Monitoring tab you'll see the applet. As shown in this screen shot:

Performance Applet Extension new tab alongside original

Since the examples presented here require some additional knowledge about what labels to use, you'll need to be able to find out the labels of the books and pages we used in the console. One way is to use another console extension found on dev2dev . The developer look and feel console extension. This console extension is a special look and feel extension that prints the labels of books and pages.

These are just some possibilities, you could in theory just replace the entire Monitoring tab, or reconsitute it out of a subset of the original tabsets. I'll show you how in future blogs.

Later,
Mike

Where's the performance applet from 8.1?

Posted by masterchief on February 27, 2007 at 10:12 AM | Permalink | Comments (2)

Many users have questions what happened to the 8.1 performance applet including one quite recently :). Rather than go into the details here, I thought I'd spend this blog post showing you an example of how it can be added back using the console extension feature that has been in place since the Diablo 9.0 release.

If you want to skip to the end you can download the source and binary form of the extension from dev2dev at:

Performance Applet Console Extension

This is a console extension example that effectively replaces the performance tab of the server console with a new portlet that has a performance applet on it.

One of the key pieces of the extension is the descriptor which tells the extension framework how to apply the extension, the following snippet from the descriptor shows that the contents of the perf.book file should be used to replace the page with label ServerMonitoringPerformancePage in the ServerMonitoringTabmonitoringTabPage.

<book-extension>
<book-location>
<parent-label-location label="ServerMonitoringTabmonitoringTabPage"/>
<book-insertion-point page-label="ServerMonitoringPerformancePage" action="replace"/>
</book-location>
<page-content content-uri="/perf/perf.book" />
</book-extension>

And then when you navigate to the Monitoring tab of a server configuration tabset, you should see a tab labeled Performance Applet instead of the former tab. The example I mentioned on dev2dev also includes a sample screen shot. I tested this on 9.2 WLS running JRockit, though it should run on releases 9.0-9.1 as well though I haven't tested those directly. I've included the full source of the extension in the example as well.

It should also be noted that replace is only one of the actions available, you can also effectively append a new tab set, or add the chart to the existing performance page as well. I'll follow up this entry with additional examples of how to apply. So you can replace, or add new functionality in that you like.
Later,
Mike

Developer Look and Feel Console Extension 1.1 Posted

Posted by masterchief on June 30, 2006 at 6:20 AM | Permalink | Comments (1)

The primary change in this release is the update to the URI's for the TLD's we use in the various skeleton files for 3rdParty TLD's only, Beehive, Struts and JSTL. The prior version S118 1.0 Developer LAF Extension is not compatible with versions 9.2+, but both versions are available for download. I'll post more on the TLD change specifically in a future blog.

WebLogic 9.0 Console Extensions (Spring/Tomcat) - Do I need an upgrade?

Posted by masterchief on October 6, 2005 at 11:06 AM | Permalink | Comments (0)

I'd like to further clarify one thing about those two particular extensions. To begin, the Tomcat Management Extension is currently in the realm of a technical preview (not available for download yet). The Spring Extension is currently available as a download on dev2dev as part of the Spring Integration Kit.

Both extensions, in their current form, would not require an upgrade of the existing 9.0 console. This highlights the flexible nature of the extension framework. Think Eclipse for the Web (if you will), basically a web GUI with a myriad of extension points defined by the GUI itself. For example, unless a particular eclipse plugin requires a specific version of Eclipse to operate, you can pretty much install any plugin at any time w/o reshipping eclipse. The same goes for the 9.0 console. So this means you could conceivably further supplement the console w/additional Spring support if you saw fit, or add support for other frameworks that you may be using within WLS.

That said, given the high number of extension points, there will be cases where something just cannot be customized, mainly because it does not have an extension point. In the near future, the devlaf look and feel extension will be posted here on dev2dev to allow you to see those extension points. I'll also be writing blog entries to highlight/discuss extensions in general.

Thanks, Mike