2. 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;
3. Project motivations
Siebel environments are usually ignored by monitoring systems employed by market (or the plugins 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.
4. Project motivations
“Poor's man component monitoring”: schedule an workflow, which queries Siebel components status and send an
e-mail in the case detected issues.
5. “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”.
6. 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 desired.
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.
7. Siebel Monitoring Tools' way
Get 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.
9. 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 default
plug-ins that can provide,
while more basic, additional
checking on Siebel
10. What is ready for usage
Two Nagios plug-ins are available:
Siebel Components Monitoring (grouped).
Siebel Component Monitoring (individual).
12. 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.
13. Siebel Component Monitor
Each component
is a separated
service in Nagios
Therefore they have may
have individual status and alerts
14. 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.
15. 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.
16. 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.
17. 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.
18. Known problems
IPC under Microsoft Windows is problematic.
Full tasks information is not available due a bug
with srvrmgr (workaround under construction).
19. 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).