Siebel Monitoring Tools

A technical overview of monitoring Siebel with open source software

Project objectives

Monitor Siebel On Premise environments regarding:

Servers status;

Components status per server;

Computer resources consumption by component;

Component tasks issues;

All this also available with SNMP;

Project motivations

Siebel environments are usually ignored by moni-toring systems employed by market (or the plug-ins are just to expensive to justify acquisition).

Those systems are configured to monitor the infrastructure used by a Siebel Enterprise, complete ignoring inner faults of the application.

Port monitoring of a Siebel Enterprise is just not enough.

Project motivations

“Poor's man component monitoring”: schedule an work-flow, which queries Siebel components status and send an e-mail in the case detected issues.

“Poor man's” scheme problems

Several Siebel single points of failure (SPOF):

– Workflow Process Batch Manager.

– The AOM being used.

– Communication Outbound Manager.

– There is no simple way to know if the e-mails are being sent or not.

No way to know if e-mails are not being sent because everything is fine or the environment is down.

Your users will get there first: “The server you are trying to access is either busy or experiencing difficulties”.

Other alternatives considered

Siebel COM: must use an AOM (which probably has customizations), COM is being little by little replaced by .NET, uses more memory then de-sired.

Siebel Java Bean: same problems then Siebel COM except it's Java (and thus will be around for a long, long time).

Siebel Management Framework: same problems of Siebel Java Bean and requires more licenses from Oracle.

Siebel Monitoring Tools' wayGet all environment data from Server Manager component.

The component is simple and does not support any customization, thus is more reliable.

If it's down, you're in big trouble anyway.

The project

The project 100% open source and is based on another open source projects.

Nagios is your front door

Nagios is a mature open source project for system monitoring. Siebel Monitoring Tools is integrated to it, so it's your dashboard for checking for problems.

Nagios also have defaultplug-ins that can provide,while more basic, additional checking on Siebel

What is ready for usage

Two Nagios plug-ins are available:

Siebel Components Monitoring (grouped).

Siebel Component Monitoring (individual).

Siebel Components Monitor

Check all components status as a singleservice.

How does it works?

Nagios will query the plug-in for data as scheduled.

The plug-in must be installed in a Linux or a MS Windows box, and in both cases must have the srvrmgr installed.

Getting the srvrmgr installed in the same box as Nagios is a complex task and not recommended.

Siebel Component Monitor

Therefore they have may have individual status and alerts

Each componentis a separatedservice in Nagios

How does it works?

Nagios will query the Nagios plug in for data as scheduled.

It looks like the Siebel Components Monitor plug-in, but it is different.

It uses XML-RPC for communication and caches results from Server Manager, being faster, allows more flexible configuration and gives more precise results.

Siebel::Srvrmgr

The backbone of the project.

It's a generic API in Perl to access Server Manager data through objects.

It enables interaction with the srvrmgr program, capturing output and generating objects on the fly.

Nice side effects, like the Siebel Srvrmgr Exporter.

Considering development for Siebel native load balancer (lbconfig.txt) automatic optimization based on each Server AOM's available.

Two “flavors” of interaction

There are two different implementations to interact with the srvrmgr program.

A “light” one, which uses srvrmgr in batch mode, and does login/logout for each session. Ideal for longer intervals between each check from Nagios.

A “heavy” one, which uses IPC to communicate with srvrmgr interactively, without login/logout. Ideal for short intervals between checks.

Other features

Built-in logging features (thanks to Log::Log4perl) with different levels of messages (WARN, ERROR, DEBUG, etc).

Automated API testing, allowing regression tests after each modification (1858 tests available right now).

Security: the API does not allow any command except “list *” and “load preferences”.

Extensible: the API can be used for integration with other monitoring systems.

Known problems

IPC under Microsoft Windows is problematic.

Full tasks information is not available due a bug with srvrmgr (workaround under construction).

Roadmap

Implement deeper level of checking for components (tasks, performance), including specific components known issues.

Use embedded perl interpreter of Nagios for speed improvement.

Making all this information available with SNMP, which would enable usage of any monitoring system (Nagios included).