Manual Monitoring Siebel Enterprise

User Manual: Monitoring Siebel Enterprise

Open the PDF directly: View PDF .
Page Count: 46

Download
Open PDF In Browser	View PDF

Monitoring Siebel Enterprise
eG Enterprise v6

Restricted Rights Legend
The information contained in this document is confidential and subject to change without notice. No
part of this document may be reproduced or disclosed to others without the prior permission of eG
Innovations Inc. eG Innovations Inc. makes no warranty of any kind with regard to the software and
documentation, including, but not limited to, the implied warranties of merchantability and fitness for
a particular purpose.
Trademarks
Microsoft Windows, Windows NT, Windows 2000, Windows 2003 and Windows 2008 are either
registered trademarks or trademarks of Microsoft Corporation in United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Copyright
©2014 eG Innovations Inc. All rights reserved.

Table of Contents
INTRODUCTION ................................................................................................................................................................................................... 1
MONITORING THE SIEBEL WEB SERVER .................................................................................................................................................... 5
2.1

THE SIEBEL WEB LAYER .............................................................................................................................................................................. 6
2.1.1 Siebel Accesses Test ........................................................................................................................................................................ 7
2.1.2 Siebel Error Log Test...................................................................................................................................................................... 7
2.1.3 Siebel Sessions Test ...................................................................................................................................................................... 11
2.1.4 Siebel Events Test ......................................................................................................................................................................... 12
2.1.5 Siebel Locks Test........................................................................................................................................................................... 14

MONITORING SIEBEL GATEWAY SERVER................................................................................................................................................ 16
3.1
3.2

THE SIEBEL GATEWAY LAYER ................................................................................................................................................................... 17
3.1.1 Siebel Gateway Errors Test .......................................................................................................................................................... 17
THE WINDOWS SERVICE LAYER ................................................................................................................................................................. 21

MONITORING THE SIEBEL APPLICATION SERVER ............................................................................................................................... 22
4.1

4.2

THE SIEBEL DATABASE LAYER .................................................................................................................................................................. 23
4.1.1 Siebel SQLs Test ........................................................................................................................................................................... 23
4.1.2 Siebel Network Test ...................................................................................................................................................................... 26
THE SIEBEL APPLICATION LAYER .............................................................................................................................................................. 29
4.2.1 Siebel Object Managers Test ........................................................................................................................................................ 29
4.2.2 Siebel Stats Test ............................................................................................................................................................................ 31
4.2.3 Siebel Server Log Test .................................................................................................................................................................. 33
4.2.4 Siebel Tasks Test ........................................................................................................................................................................... 36
4.2.5 Siebel Traffic Test ......................................................................................................................................................................... 38

TROUBLESHOOTING ........................................................................................................................................................................................ 40
CONCLUSION...................................................................................................................................................................................................... 42

Table of Figures
Figure 1.1: A high-level view of the Siebel application suite architecture................................................................................................................. 2
Figure 1.2: The topology model of the monitored Siebel environment...................................................................................................................... 4
Figure 2.1: Layer model for a Siebel Web Server ..................................................................................................................................................... 6
Figure 2.2: Tests associated with the Siebel Web layer ............................................................................................................................................. 6
Figure 3.1: Layer model of the Siebel Gateway Server ........................................................................................................................................... 16
Figure 3.2: The tests associated with the Siebel Gateway layer ............................................................................................................................... 17
Figure 3.3: shows the tests associated with the Win_Service Layer ....................................................................................................................... 21
Figure 4.1: The layer model for the Siebel Application server. ............................................................................................................................... 22
Figure 4.2: The tests associated with Siebel Database layer .................................................................................................................................... 23
Figure 4.3: The Data source name ........................................................................................................................................................................... 27
Figure 4.4: Selecting the Siebel database Properties................................................................................................................................................ 28
Figure 4.5: The General tab displaying the database Owner.................................................................................................................................... 28
Figure 4.6: The tests associated with the Siebel Application Layer ......................................................................................................................... 29

I n t r o d u c t i o n

Chapter

Introduction
Ever since business entities decided to go online with their service offerings, they have been having
trouble dealing with a fast-expanding customer base and ever-mounting customer concerns. The lack
of any efficient mechanism to manage the growing list of permanent/probable users to the service,
caused the enterprise to lose millions; delays in follow-up calls lead to slow or no conversions, and
poor customer support resulted in a loss of goodwill. That should explain why the service sector
organizations providing business-critical services to end-users, have been turning to Customer
Relationship Management (CRM) solutions like Siebel for help.
Siebel CRM-packaged business applications have become key enablers of an enterprise’s customerfacing business processes. From tracking enquiries received from prospects to providing timely
support to customers, the Seibel CRM modules automate the complete spectrum of activities that form
part of an enterprise's marketing, sales, and support cycles. The wide capabilities of the Siebel
solution demand a complex architecture; accordingly, you have a Siebel web client that front-ends
requests to a Siebel web server, a Siebel gateway that grants the web requests access to the Siebel
application servers, the Siebel application servers that process the requests by applying the business
logic, and finally, the database server which stores and maintains the resultant data.

I n t r o d u c t i o n

Figure 1.1: A high-level view of the Siebel application suite architecture
As multiple tiers of components are at work here, a problem with one tier/component can ripple and
affect the performance of the dependent tiers. Siebel administrators therefore, often find it very
difficult to determine where the real problem lies - is it with the Siebel web server? the Siebel
gateway? the Siebel application server? or the database? The source of the problem has to be
identified and necessary correction/optimization steps need to be taken to improve service
performance and avoid service outages. What Siebel administrators need therefore, is an integrated
solution that can monitor the entire chain of Siebel enterprise servers, taking into consideration the
inter-dependencies that exist between them.
The eG Enterprise Suite, with its 100% web-based architecture and patented correlation and rootcause diagnosis capability, is ideal for monitoring Siebel environments. This solution offers exclusive
monitoring models for analysing the availability and overall health of every Siebel component. The
data collectors employed by the suite extract a wide variety of performance statistics pertaining to the
availability, responsiveness, session information, error logs and key tasks executing on these
components. Besides measuring the health of the critical ingredients of a typical Siebel infrastructure,
eG Enterprise also focuses on the performance of the operating systems that host the Siebel
Enterprise components. Accordingly, a wealth of host-level performance information, which includes
metrics on resource (CPU/memory/disk) usage by the host, key processes executing on the host,
network availability and traffic to and from the host, etc., are collected. Using such extensive
performance data, administrators can easily find answers to common Siebel Enterprise related queries
like:
Siebel
Web
Monitoring

Server



Is the web server available?



Is it responding quickly to client requests?



Are any Siebel modules accessed very often? If so, which ones are
they?



How many sessions are currently active on the web server?



Did the sessions open too slowly? What about session closure? Did
it also take too long?



Were the sessions open for too long?

I n t r o d u c t i o n

Siebel
Monitoring

Gateway

Siebel
Application
Server Monitoring

Database
monitoring

server



Are there any anonymous sessions?



Are too many errors logged in the error log?



Are too many errors logged in the error log? If so, what are they?



Is the Siebel Gateway server up and running currently?



Is the Siebel Gateway Name Server service available? If so, is it
consuming too much CPU?



Is the application server available?



What is the current state of the component object managers? Have
adequate object managers been spawned for the business process
currently in use?



Has the object manager reached the maximum tasks limit?



How quickly does it respond to requests?



Are too many anonymous locks currently held? If so, how long were
they held?



Is the server overloaded with tasks or are only a few currently
running?



Is the server able to easily connect to the database or are
connection retries necessary?



How quickly is the server able to execute/fetch/parse SQL queries
on the database?



Is the database server available?



Does it respond to requests quickly? If not, which are the queries
that are taking too much time?



How are the SQL fetches, parses and execution happening in the
database?



What is the typical workload on the database server?



What is the typical locking activity on the database?



Which processes are being blocked and by whom?



How many processes are running, and what queries are they
executing? Which user(s) are executing these queries?



Which of the databases is seeing more transaction activity?

Moreover, the suite's end-to-end service monitoring capability and its patented root-cause diagnosis
algorithm enable automatic correlation of the performance of the various Siebel components and quick
and accurate problem isolation. By graphically representing a Siebel environment (see Figure 1.2), eG
Enterprise enables administrators to quickly understand the interdependencies among Siebel
components and their cause-effect relationships, and accurately judge root-cause of issues.

I n t r o d u c t i o n

Figure 1.2: The topology model of the monitored Siebel environment
This document will engage you in an in-depth discussion of the monitoring models that eG Enterprise
provides for every Siebel Enterprise component, and the performance metrics that each of these
models help collect.

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

Chapter

Monitoring the Siebel Web Server
Using the Siebel web server extension running within, the Siebel Web Server maintains user sessions
and manages the communication to Siebel Enterprise. The Siebel Web monitoring model (see Figure
2.1) that eG Enterprise prescribes for the Siebel Web server therefore, focuses on session behavior
and related abnormalities.
To enable the eG agent to collect the session-specific and other statistics from the web server, you
need to configure the web server in the following manner:



Edit the \sea\SWEApp\BIN\eapps.cfg file on the Siebel web
server host. For example, if Siebel 7.0.3 is installed in the C directory of a host, then the path
to the configuration file will be as follows: C:\sea703\SWEApp\BIN\eapps.cfg.



To enable the eG agent to extract session statistics from the web server, ensure that the
SessionMonitor flag in the eapps.cfg file is set to TRUE.



Similarly, by setting the AllowStats flag in the eapps.cfg file to TRUE, you can make sure that
metric-collection is enabled on the Siebel web server to be monitored.



Then, save the file.



Finally, restart the web server (in case of a Unix environment) or restart services such as such
as WWW after the eapps.cfg file is changed.

Once monitoring is enabled on the web server, the eG agent can proceed to execute tests on the web
server to determine the following:



Is the web server available?



Is it responding quickly to client requests?



Which are the most popular Siebel modules in terms of the number and duration of accesses?



How many sessions are currently active on the web server?



Did the sessions open too slowly? What about session closure? Did it also take too long?



Were the sessions open for too long?



Are there any anonymous sessions?



Are too many errors logged in the error log?

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

Figure 2.1: Layer model for a Siebel Web Server
Each of the layers depicted by Figure 2.1 above is mapped to one/more tests that an eG agent
executes on the web server. The following sections deal with the Siebel Web layer only. For details on
the Web Server layer, refer to the Monitoring Web Servers document, and for details on the other
layers, refer to the Monitoring Unix and Windows Servers document.

2.1 The Siebel Web Layer
Using the tests associated with it, the Siebel Web layer (see Figure 2.2) keeps a close watch on the
accesses to the web server and the authenticated and anonymous sessions initiated on it, to reveal
the following:



The most popular application on the web server



Errors (if any) that were recently encountered by the web server



The session load on the web server



The events triggered by session open/closure requests



The number and duration of locks held by every monitored application on the web server

Figure 2.2: Tests associated with the Siebel Web layer

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

This test reports how often and for how long the configured application modules on the Siebel web
server were accessed.

Purpose

Reports how often and for how long were configured application modules on the
Siebel web server used

Target of the
test

A Siebel web server

Agent
deploying the
test

An internal or remote agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel web server
3. PORT – The port number on which the Siebel web server is listening
4. URL - Specify the URL of the Siebel web server being monitored.
5. APPLICATIONNAME – Provide a comma-separated list of Siebel modules that
need to be monitored. For example, callcenter,eai,ecustomer.

Outputs of the
test
Measurements
made by the
test

One set of results for each Siebel module monitored.

Measurement
Application hits:

Measurement
Unit
Number

Indicates the number of
current
hits
to
this
application.
Session life span:

Interpretation
The value reported by this measure
signifies the load to the specific Siebel
application; it could also indicate how
popular the application is.

Secs

Indicates the duration of
sessions to this
application.

All the events and errors that relate to the web server are tracked by the log file, along with the date,
time and event for each log entry. Periodic monitoring of these log files can provide administrators
with useful pointers to critical errors that might have affected the web server performance in recent
times. The SiebelErrorLog test reports the errors that were newly added to the web server log since
the last measurement period.

Purpose

Reports the number of newly added errors to the log file

Target of the
test

A Siebel web server

Agent
deploying the

An internal agent

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

test
Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel web server
3. PORT – The port number on which the Siebel web server is listening
4. ALERTFILE - Specify the path to the log file to be monitored. For eg.,
C:/sea703/SWEBApp/LOG/Siebel_Web_log.txt. Multiple log file paths can be
provided as a comma-separated list.
Also, instead of a specific log file path, the path to the directory containing log
files can be provided - eg., C:/sea703/SWEBApp/LOG. This ensures that eG
Enterprise monitors the most recent log files in the specified directory. Specific
log file name patterns can also be specified. For example, to monitor the latest
log files with names containing the strings 'siebel' and 'log', the parameter
specification
can
be,
C:/sea703/SWEBApp/LOG/*siebel*,C:/sea703/SWEBApp/LOG/*log*. Here, '*'
indicates leading/trailing characters (as the case may be). In this case, the eG
agent first enumerates all the log files in the specified path that match the given
pattern, and then picks only the latest log file from the result set for monitoring.
You can also configure the path in the following format:Name@logfilepath. Here,
Name represents the display name of the path being configured. Accordingly,
the parameter specification for the 'siebel' and 'log' example discussed above
can
be:
siebel@C:/sea703/SWEBApp/LOG/*siebel*,log@C:/sea703/SWEBApp/LOG/*log
*. In this case, the display names 'siebel' and 'log' will alone be displayed as
descriptors of this test.
Every time this test is executed, the eG agent verifies the following:



Whether any changes have occurred in the size and/or timestamp of the log
files that were monitoring during the last measurement period;



Whether any new log files (that match the ALERTFILE specification) have
been newly added since the last measurement period;

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

Multiple search patterns can be specified as a comma-separated list. For
example: Gen_errors:Generic*,Critical_errors:*Error*.
If the ALERTFILE specification is of the format Name@logfilepath, then the
descriptor for this test in the eG monitor interface will be of the format:
Name:PatternName. On the other hand, if the ALERTFILE specification consists
only of a comma-separated list of log file paths, then the descriptors will be of
the format: LogFilePath:PatternName.

6. LINES - Specify two numbers in the format x:y. This means that when a line in
the log file matches a particular pattern, then x lines before the matched line
and y lines after the matched line will be reported in the detail diagnosis output
(in addition to the matched line). The default value here is 0:0. Multiple entries
can be provided as a comma-separated list.
If you give 1:1 as the value for LINES, then this value will be applied to all the
patterns specified in the SEARCHPATTERN field. If you give 0:0,1:1 as the value
for LINES and if the corresponding value in the SEARCHPATTERN filed is like
Gen_errors:Generic*,Critical_errors:*Error*, then:
0:0 will be applied to the Gen_errors:Generic* pattern
1:1 will be applied to the Critical_errors:*Error* pattern

7. EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded
from monitoring in the EXCLUDEPATTERN text box. For
*critical*,*exception*. By default, this parameter is set to 'none'.

example

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

9. ROTATINGFILE - This flag governs the display of descriptors for this test in the
eG monitoring console.
If this flag is set to true and the ALERTFILE text box contains the full path to a
specific (log/text) file, then, the descriptors of this test will be displayed in the
following format: Directory_containing_monitored_file:. For
instance, if the ALERTFILE parameter is set to c:\eGurkha\logs\syslog.txt, and
ROTATINGFILE is set to true, then, your descriptor will be of the following
format: c:\eGurkha\logs:. On the other hand, if the
ROTATINGFILE flag had been set to false, then the descriptors will be of the
following
format:
:
i.e.,
syslog.txt: in the case of the example above.
If this flag is set to true and the ALERTFILE parameter is set to the directory
containing log files, then, the descriptors of this test will be displayed in the
format: Configured_directory_path:. For instance, if the
ALERTFILE parameter is set to c:\eGurkha\logs, and ROTATINGFILE is set to
true, then, your descriptor will be: c:\eGurkha\logs:. On the
other hand, if the ROTATINGFILE parameter had been set to false, then the
descriptors
will
be
of
the
following
format:
Configured_directory: - i.e., logs: in the case
of the example above.
If this flag is set to true and the ALERTFILE parameter is set to a specific file
pattern, then, the descriptors of this test will be of the following format:
:. For instance, if the ALERTFILE parameter is set
to c:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor
will be: *sys*:. In this case, the descriptor format will not
change even if the ROTATINGFILE flag status is changed.

10. DETAILED DIAGNOSIS: To make diagnosis more efficient and accurate, the eG
suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when
specific problems are detected. To enable the detailed diagnosis capability of
this test for a particular server, choose On option. To disable the capability, click
on Off option. The option to selectively enabled/disable the detailed diagnosis
capability will be available only if the following conditions are fulfilled:

 The eG manager license should allow the detailed diagnosis capability.
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every log file, log file directory, or LogFilePath:PatternName
monitored on the Siebel web server

Measurement
Recent errors:

Measurement
Unit
Number

Indicates the number of
errors that were newly
added to the log file when
the
test
was
last
executed.

Interpretation
The value of this measure is a clear
indicator of the number of “new” errors
that have occurred on the monitored
Siebel
web
server.
The
detailed
diagnosis of this measure provides the
details of these new errors.

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

This test reports key statistics pertaining to the sessions on the Siebel web server.

Purpose

Reports key statistics pertaining to the sessions on the Siebel web server

Target of the
test

A Siebel web server

Agent
deploying the
test

An internal or remote agent

Configurable
parameters for
the test

4. APPLICATIONNAME – Specifies a comma-separated list of Siebel modules that
need to be monitored.

5. DETAILED DIAGNOSIS: To make diagnosis more efficient and accurate, the eG
suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when
specific problems are detected. To enable the detailed diagnosis capability of
this test for a particular server, choose On option. To disable the capability, click
on Off option. The option to selectively enabled/disable the detailed diagnosis
capability will be available only if the following conditions are fulfilled:

 The eG manager license should allow the detailed diagnosis capability
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for each Siebel web server monitored

Measurement
Current sessions:

Measurement
Unit
Number

Indicates the number of
sessions currently active
on the Siebel web server.

Interpretation
Since the user sessions include data on
any user logged into the Siebel web
server as well as the sessions created by
the Siebel application, this measure is an
accurate indicator of the direct loading
on the web server from clients. As these
user sessions run based on the Siebel
server component task, the information
on the user sessions can be viewed as
either a user session or a task currently
handled by the web server.
The detailed diagnosis of this measure, if
enabled, lists all the current sessions to
the Siebel web server.

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

New sessions:

Number

Tracking the new sessions added over
the
monitoring
interval
enables
administrators to be proactively alerted
of any sudden, unusual increase in the
load on the web server. By observing
session load over a period of time, you
can easily detect load trends, which in
turn, will enable you to plan the capacity
of the web server.

Secs

An abnormal increase in the value of this
measure could indicate that sessions are
not getting closed properly. This hence
necessitates further investigation.

Indicates the number of
sessions that newly
opened on the Siebel Web
server, the last time this
test executed.

Avg session duration:
Indicates the average
duration of sessions.

This test monitors the session related events handled by the Siebel web server. The events are user
specific actions, which help Siebel applications to respond in real time to user requests.

Purpose

Monitors the session related events handled by the Siebel Web server.

Target of the
test

A Siebel web server

Agent
deploying the
test

An internal or remote agent

Configurable
parameters for
the test

4. APPLICATIONNAME – Specifies a comma-separated list of Siebel modules that
need to be monitored.

Outputs of the
test
Measurements
made by the

One set of results for every configured module on the web server monitored

Measurement

Measurement
Unit

Interpretation

M o n i t o r i n g

test

t h e

S i e b e l

W e b

S e r v e r

Anonymous sessions
requested:

Sessions

Ideally, the value reported for this
measure should be low. A high value for
this measure indicates that the number
of anonymous users accessing the web
server has increased. The benchmark
set
for
optimizing
the
Siebel
performance depends upon defining
MaxTasks, MTServers and Anonuserpool
values against the target no of users.
Suppose if your target no of users is
4000
and
you
have
defined
MaxMTServer=MinMTServer to 58, the
MaxTasks defined for this scenario could
be 4600, taking into account the
Anonymous user pool at any point in
time to be 10% (400) of the Target
users. An increase in the number of
anonymous users could affect the ratio
of
threads
per
users,
causing
performance degradation in terms of
longer response times.

Sessions

A high value for this indicates that either
sessions are being timed out or
connectivity is not stable enough.

Sessions

Anonymous sessions returned should be
close to anonymous sessions requested.

Secs

A steady/significant increase in the time
taken to open sessions can point to
probable
issues,
which,
if
left
unresolved, can impair the end user
experience.

Indicates the number of
anonymous
session
requests handled by the
Siebel web Server.

Anonymous sessions
removed:
Indicates the number of
anonymous sessions
removed/terminated by
the Siebel web server.

Anonymous sessions
returned:
Indicates the number of
anonymous sessions
returned to the web
server.

Avg time for opening a
session:
This specifies the average
amount of time spent by
the server to open a
session.

M o n i t o r i n g

t h e

S i e b e l

W e b

S e r v e r

Avg response time:

Secs

Ideally the value for this measure should
be low.

Secs

This event reflects the amount of time it
takes to close a session. Closing the
session might involve signaling to the
session manager to close the session.
The session manager might or might not
close the TCP/IP connection.

Indicates the average
amount of time spent by
the server to respond to
the request.

Avg time for closing a
session:
Indicates the average
amount of time taken by
the sessions to close.

If the value of this measure is very high,
it indicates a bottleneck in session
closure. The reasons for the same should
hence be ascertained.
Avg request time:

Secs

Indicates the average
amount of taken to
submit a request to the
Siebel Server and to get a
response back.

Ideally the value for this measure should
be low. For example, if the user (on the
browser) clicked on a button then the
plug-in receives the request and invokes
a service on the Siebel Server. The value
for Request Time is the average amount
of time for invoking that service.

This test indicates the number and duration of locks on configured modules on the Siebel web server.

Purpose

Indicates the number and duration of locks on configured modules on the web
server

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel server
3. PORT – The port number on which the Siebel server is listening
4. URL - Specify the URL of the Siebel web server being monitored.
5. APPLICATIONNAME – Specifies a comma-separated list of Siebel modules that
need to be monitored.

Outputs of the
test
Measurements
made by the

One set of results for each module configured for monitoring on the Siebel web
server

Measurement

Measurement
Unit

Interpretation

M o n i t o r i n g

test

t h e

S i e b e l

W e b

S e r v e r

Time taken to initialize
locks:

Secs

Represents the time that
an
identified
user
currently took to initialize
locks on this module.
Time taken to acquire
anonymous locks:

Secs

Represents the time that
an
anonymous
user
currently took to acquire
locks on this module.
Initialized locks:

Number

Indicates the number of
locks that are currently
initialized by identified
users to this module.
Anonymous locks:

Number

Indicates the number of
locks on this module that
are currently held by
anonymous users.
Avg time to initialize
locks:

Secs

Indicates
the
average
time taken by identified
users to initialize locks on
this module.
Avg time to acquire
anonymous locks:

Secs

Indicates
the
average
time taken by anonymous
users to acquire locks on
this module.

M o n i t o r i n g

t h e

S i e b e l

G a t e w a y

S e r v e r

Chapter

Monitoring Siebel Gateway Server
The Gateway Server is a logical server that consists of the Siebel Name Server and optionally
Resonate Central Dispatch. These two components can reside on separate physical servers. The
Gateway Name Server is a repository for configuration information about each Siebel Server. When
Siebel Servers or components come online or go offline the Name Server data is refreshed with the
connect strings. Clients will also use the Gateway Name server to connect to the Siebel Servers if
Resonate Central Dispatch (which is used to load balance and manage client connections to Siebel
Enterprise) is not implemented.
Since the Name server component of the Gateway server maintains the connectivity information
pertaining to every component in Siebel Enterprise, the 24 x 7 availability of the Name server is
crucial to the functioning of the Gateway server, and also for ensuring that client connections to Siebel
servers are not disrupted.
eG Enterprise offers a specialized Siebel Gateway monitoring model (see Figure 3.1), which runs
periodic availability checks on the Gateway server to determine the availability of its Name server
component and related services. This way, availability issues can be proactively detected and resolved
before they affect the end-user experience.
Besides, additions to the Siebel Gateway server's log files are also closely monitored, so that potential
threats to the health of the Gateway server can be promptly detected, and administrators immediately
alerted.

Figure 3.1: Layer model of the Siebel Gateway Server
The sections to come will discuss the first 2 layers of Figure 3.1 alone, as the remaining layers have
been elaborately discussed in the Monitoring Unix and Windows Servers document.

M o n i t o r i n g

t h e

S i e b e l

G a t e w a y

S e r v e r

3.1 The Siebel Gateway Layer
Using the Siebel Gateway Errors test, this layer monitors the error logs and indicates whether any new
errors occurred on the Gateway server (see Figure 3.2).

Figure 3.2: The tests associated with the Siebel Gateway layer

This test provides the status of errors logged in the Siebel gateway server log files.

Purpose

Provides the status of errors logged in the Siebel gateway server log files

Target of the
test

A Siebel gateway server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

t h e

S i e b e l

G a t e w a y

S e r v e r

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel web server
3. PORT – The port number on which the Siebel web server is listening
4. ALERTFILE - Specify the path to the log file to be monitored. For eg.,
C:/sea703/SWEBApp/LOG/Siebel_Web_log.txt. Multiple log file paths can be
provided as a comma-separated list.
Also, instead of a specific log file path, the path to the directory containing log
files can be provided - eg., C:/sea703/SWEBApp/LOG. This ensures that eG
Enterprise monitors the most recent log files in the specified directory. Specific
log file name patterns can also be specified. For example, to monitor the latest
log files with names containing the strings 'siebel' and 'log', the parameter
specification
can
be,
C:/sea703/SWEBApp/LOG/*siebel*,C:/sea703/SWEBApp/LOG/*log*. Here, '*'
indicates leading/trailing characters (as the case may be). In this case, the eG
agent first enumerates all the log files in the specified path that match the given
pattern, and then picks only the latest log file from the result set for monitoring.
You can also configure the path in the following format:Name@logfilepath. Here,
Name represents the display name of the path being configured. Accordingly,
the parameter specification for the 'siebel' and 'log' example discussed above
can
be:
siebel@C:/sea703/SWEBApp/LOG/*siebel*,log@C:/sea703/SWEBApp/LOG/*log
*. In this case, the display names 'siebel' and 'log' will alone be displayed as
descriptors of this test.
Every time this test is executed, the eG agent verifies the following:



Whether any changes have occurred in the size and/or timestamp of the log
files that were monitoring during the last measurement period;



Whether any new log files (that match the ALERTFILE specification) have
been newly added since the last measurement period;

M o n i t o r i n g

t h e

S i e b e l

G a t e w a y

S e r v e r

5. SEARCHPATTERN - Enter the specific patterns of alerts to be monitored. The
pattern should be in the following format: :, where
is the pattern name that will be displayed in the monitor
interface and is an expression of the form - *expr* or expr or *expr
or expr*, etc. A leading '*' signifies any number of leading characters, while a
trailing '*' signifies any number of trailing characters.
For example, say you specify Gen_errors:Generic* in the SEARCHPATTERN text
box. This indicates that "Gen_errors" is the pattern name to be displayed in the
monitor interface. "Generic*" indicates that the test will monitor only those lines
in the log which start with the term "Generic".
A single pattern MAY also be of the form e1+e2, where + signifies an OR
condition. That is, the is matched if either e1 is true or e2 is
true.
Multiple search patterns can be specified as a comma-separated list. For
example: Gen_errors:Generic*,Critical_errors:*Error*.
If the ALERTFILE specification is of the format Name@logfilepath, then the
descriptor for this test in the eG monitor interface will be of the format:
Name:PatternName. On the other hand, if the ALERTFILE specification consists
only of a comma-separated list of log file paths, then the descriptors will be of
the format: LogFilePath:PatternName.
6. LINES - Specify two numbers in the format x:y. This means that when a line in
the log file matches a particular pattern, then x lines before the matched line
and y lines after the matched line will be reported in the detail diagnosis output
(in addition to the matched line). The default value here is 0:0. Multiple entries
can be provided as a comma-separated list.
If you give 1:1 as the value for LINES, then this value will be applied to all the
patterns specified in the SEARCHPATTERN field. If you give 0:0,1:1 as the value
for LINES and if the corresponding value in the SEARCHPATTERN filed is like
Gen_errors:Generic*,Critical_errors:*Error*, then:
0:0 will be applied to the Gen_errors:Generic* pattern
1:1 will be applied to the Critical_errors:*Error* pattern

7. EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded
from monitoring in the EXCLUDEPATTERN text box. For example *critical*,
*generic*. By default, this parameter is set to 'none'.

M o n i t o r i n g

t h e

S i e b e l

G a t e w a y

S e r v e r

8. UNIQUEMATCH - By default, the UNIQUEMATCH parameter is set to FALSE,
indicating that, by default, the test checks every line in the log file for the
existence of each of the configured SEARCHPATTERNS. By setting this
parameter to TRUE, you can instruct the test to ignore a line and move to the
next as soon as a match for one of the configured patterns is found in that line.
For example, assume that Pattern1:*Generic*,Pattern2:*Error* is the
SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE,
then the test will read every line in the log file completely to check for the
existence of messages embedding the strings 'Generic' and 'Error'. If both the
patterns are detected in the same line, then the number of matches will be
incremented by 2. On the other hand, if UNIQUEMATCH is set to TRUE, then the
test will read a line only until a match for one of the configured patterns is found
and not both. This means that even if the strings 'Generic' and 'Error' follow one
another in the same line, the test will consider only the first match and not the
next. The match count in this case will therefore be incremented by only 1.
9. ROTATINGFILE - This flag governs the display of descriptors for this test in the
eG monitoring console.
If this flag is set to true and the ALERTFILE text box contains the full path to a
specific (log/text) file, then, the descriptors of this test will be displayed in the
following format: Directory_containing_monitored_file:. For
instance, if the ALERTFILE parameter is set to c:\eGurkha\logs\syslog.txt, and
ROTATINGFILE is set to true, then, your descriptor will be of the following
format: c:\eGurkha\logs:. On the other hand, if the
ROTATINGFILE flag had been set to false, then the descriptors will be of the
following
format:
:
i.e.,
syslog.txt: in the case of the example above.
If this flag is set to true and the ALERTFILE parameter is set to the directory
containing log files, then, the descriptors of this test will be displayed in the
format: Configured_directory_path:. For instance, if the
ALERTFILE parameter is set to c:\eGurkha\logs, and ROTATINGFILE is set to
true, then, your descriptor will be: c:\eGurkha\logs:. On the
other hand, if the ROTATINGFILE parameter had been set to false, then the
descriptors
will
be
of
the
following
format:
Configured_directory: - i.e., logs: in the case
of the example above.
If this flag is set to true and the ALERTFILE parameter is set to a specific file
pattern, then, the descriptors of this test will be of the following format:
:. For instance, if the ALERTFILE parameter is set
to c:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor
will be: *sys*:. In this case, the descriptor format will not
change even if the ROTATINGFILE flag status is changed.

M o n i t o r i n g

t h e

S i e b e l

G a t e w a y

S e r v e r

11. DETAILED DIAGNOSIS: To make diagnosis more efficient and accurate, the eG
suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when
specific problems are detected. To enable the detailed diagnosis capability of
this test for a particular server, choose On option. To disable the capability, click
on Off option. The option to selectively enabled/disable the detailed diagnosis
capability will be available only if the following conditions are fulfilled:

 The eG manager license should allow the detailed diagnosis capability.
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every log file, log file directory, or LogFilePath:PatternName
monitored on the Siebel Gateway server

Measurement

Recent errors:

Measurement
Unit
Number

Indicates
the
total
number of recent errors
logged in the log file.

Interpretation

The value of this measure is a clear
indicator of the number of “new” alerts
that have come into the log file of the
monitored server.

3.2 The Windows Service Layer
The WindowsServices Test mapped to this layer determines the availability of the Name server service
executing on the Gateway server.

Figure 3.3: shows the tests associated with the Win_Service Layer
The WindowsServices test, its parameters, and the measures it reports have been dealt with
extensively in the Monitoring Unix and Windows Servers document.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

Chapter

Monitoring the Siebel Application
Server
The Siebel Application Server has one or more physical servers and is the middle tier of the enterprise
architecture. These servers run the components (i.e., programs/tasks that run on the Siebel server to
service user requests) that provide all business logic to the clients.
Performance degradations experienced by the Siebel Application server can therefore cause fatal
errors in business logic execution, and can even bring the entire Siebel environment to a stand-still,
thereby causing customer dissatisfaction and related revenue losses.
It is hence imperative to constantly 'watch over' the functioning of the Siebel server, so that probable
anomalies are promptly isolated and addressed before they can adversely impact the customer
experience.
The Siebel Application monitoring model (see Figure 4.1) that eG Enterprise offers exclusively for the
Siebel application server, runs a wide variety of tests that execute commands on the application
server to determine the overall health of the Siebel server, and its availability to service client
requests.

Figure 4.1: The layer model for the Siebel Application server.
The sections to come will shed light on the Siebel Application and Siebel Database layers of Figure 4.1. For
information on the other layers, refer to the Monitoring Unix and Windows Servers document.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

4.1 The Siebel Database Layer
The tests associated with this layer monitor the availability of the Siebel database and the efficiency
with which the database server handles queries executed by the Siebel server.

Figure 4.2: The tests associated with Siebel Database layer

This test, executed by an internal agent, monitors the overall health of interactions between the Siebel
server and its backend database.

Purpose

Monitors the overall health of interactions between the Siebel server and its backend
database

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

One set of results for the monitored Siebel server

Measurement
Unit

Measurement
SQL
operations:

execute

Interpretation

Number

Indicates
the
total
number of SQL execute
operations.
SQL fetch operations:
Indicates
the
number of SQL
operations.

A low value is indicative of low fetchintensive Siebel queries on the Siebel
database.

Number

A low value is an indicative of low parseintensive queries on the Siebel database.

Secs

Ideally, the value of this measure should
be low. However, if you find that
execution times are unreasonably long,
look at the execution plan to determine
how the data was accessed. The
following can also be attributed to delays
in SQL execution:

total
fetch

SQL parses:
Indicates
the
number of SQL
operations.

Number

total
parse

Total time taken
SQL executes:

Indicates the total time
taken by SQL execute
operations.

Total time taken
SQL fetches:

Secs

Indicates the total time
taken
for
SQL
fetch
operations.



I/O constraint on the disk where
the table or index resides



Logical
row
lock
contention
(because of INSERT, DELETE,
UPDATE and so on)



DB2 connection on page latches



CPU constrained or
constrained machine

storage

A query is request for data. Sometimes,
various queries from the application do
not fetch the entire result requested
which forces the SQL server to hold
shared key or page locks until the entire
result set is fetched, or canceled
(closed).
Tracking this value helps you to
determine the time taken for SQL fetch
operations. If the time taken to fetch all
result rows is high, then it will lock the
tables, thereby blocking other users.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

Total time taken
SQL parses:

S e r v e r

Secs

Indicates the total time
elapsed for SQL parse
operations.

The parse call – hard or soft – has
overhead
due
to
processing
requirements i.e. actual CPU work
needed by the database engine. During
the hard parse, database engine has to
lock several internal sources to make
sure the structure of the tables involved
does not change. Operations on the
library cache also require locking of
internal sources. These locks are taken
for very short duration of time and have
little
effect
on
the
applications
supporting few users. However for
applications that need to scale many
concurrent users, any such lock will
prevent scalability.
A sudden increase in the value for this
measure can affect other operations and
increase the transaction response time.

Avg
time
executes:

for

SQL

Secs

Indicates
the
average
time
taken
by
SQL
execute operations.

Avg
time
executes:

for

SQL

If the average elapsed time for SQL
execution is high, it could be due to the
following reasons:


I/O constraint on the disk where
the table or index resides



Logical
row
lock
contention
(because of INSERT, DELETE,
UPDATE and so on)



DB2 connection on page latches



CPU constrained or
constrained machine

Secs

Indicates
the
average
time
for
SQL
fetch
operations.
Avg
time
parses:

for

SQL

Secs

Indicates
the
average
time
for
SQL
parse
operations.
Database
retries:

connection

Number

Indicates the number of
retries due to database
connection loss.

Ideally, this value should be 0.

storage

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

This test checks whether the database server is accessible from the Siebel server, and if so, indicates
how quickly the database responds to Siebel requests.

Purpose

Checks whether the database server is accessible from the Siebel server, and if so,
indicates how quickly the database responds to Siebel requests

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel server
3. PORT – The port number on which the Siebel server is listening
4. INSTALLDIRECTORY – Provide the full path to the install directory of the Siebel
server
5. SIEBELDATASOURCE – One of the key pre-requisites for a Siebel installation is
to create an ODBC Data source exclusively for Siebel Enterprise. The name of
this data source needs to be provided here. To know how to locate the data
source name, refer to Page 27.
6. TABLEOWNERNAME – Specify the name of the owner of any valid table on the
Siebel repository. To know how to find the name of a table owner, follow the
procedure detailed in Page 27.
7. USERNAME – This test executes a command on the Siebel server to extract the
statistics of interest; this command requires administrator privileges to execute.
Therefore, enter the name of the Siebel administrator.
8. PASSWORD – Specify the administrator password
9. CONFIRM PASSWORD – Confirm the password by retyping it.
10. NODE – Specify the host name of the system on which the data source has been
installed; typically, this will be the Siebel server's hostname.

Outputs of the
test
Measurements
made by the
test

One set of results for each Siebel server monitored

Measurement
Availability:

Measurement
Unit
Percent

Indicates whether/not a
healthy
network
connection is available
between the Siebel server
and its database server.

Interpretation
Ideally, this value should be 100%. A
zero value reported for this measure
indicates that the database server is not
accessible from the Siebel server. This
could be owing to a faulty network
connection, or a non-availability of the
database server itself.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

Response time:

S e r v e r

Secs

Indicates the time taken
by the database server to
respond to the Siebel
requests.

An increase in response time can be due
to many reasons such as sudden
increase in the number of tasks waiting
to be processed, lack of memory, high
CPU utilization, buffer pools not properly
sized etc.

To view a list of data sources to choose from, do the following:
1. On the ODBC host, follow the menu sequence Start -> Programs -> Administrative Tools -> Data
Sources (ODBC).
2. In the ODBC Data Source Administrator dialog box that appears, click on the System DSN tab.
3. Figure 4.3 then appears listing the ODBC data sources currently configured. Find the Siebel data
source in the list, and provide its name against the DATASOURCENAME parameter. In the example
illustrated by Figure 4.3 below, SiebSrvr_siebel is the name of the Siebel data source.

Figure 4.3: The Data source name
Siebel Enterprise can use an MS SQL server/ Oracle/ DB2 UDB server as its backend. If Siebel
Enterprise uses an MS SQL server backend, then follow the steps given below to determine the owner
of the Siebel database; the table owner is the same as the database owner:
1. Open the SQL Enterprise Manager of the MS SQL server installation using the menu sequence,
Programs -> Microsoft SQL Server -> Enterprise Manager.
2. Expand the Databases node in the tree-structure in the left pane of the SQL Enterprise Manager, and
select the Siebel database from within; right-click on the database, and select the Properties option
(see Figure 4.4).

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

Figure 4.4: Selecting the Siebel database Properties
3. In the Properties dialog box that appears, you will find a name against the Owner field. This name
should be specified as the TABLEOWNERNAME (see Figure 4.5).

Figure 4.5: The General tab displaying the database Owner

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

4.2 The Siebel Application Layer
Using the tests associated with this layer, you can determine the following:



The availability, responsiveness, and resource usage of the object managers on the Siebel
server



Whether the object managers are overloaded with tasks



Recent errors encountered by the Siebel server



Level of data traffic to and from the Siebel server

Figure 4.6: The tests associated with the Siebel Application Layer

The requests to every application executing on a Siebel server are typically handled by one/more
object managers. If the object manager required by an application is not running, then the Siebel
server will be forced to reject all requests for that application, causing the end-user to suffer. The
SiebelObjectManagers test monitors each of the object managers to ascertain their current state and
load.

Purpose

Monitors each of the object managers to ascertain their current state and load.

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

5. GATEWAYSERVER – Provide the IP address/host name of the Gateway server
6. ENTERPRISESERVER - This refers to the name that was specified for the
Enterprise server during a Siebel installation. An Enterprise server is a logical
entity. It collectively represents the Siebel application servers and gateway
server.

7. USERNAME – This test executes a command on the Siebel server to extract the
statistics of interest; this command requires administrator privileges to execute.
Therefore, enter the name of the Siebel administrator.

8. PASSWORD – Specify the administrator password
9. CONFIRM PASSWORD – Confirm the password by retyping it.
Outputs of the
test
Measurements
made by the
test

One set of results for every object manager monitored.

Measurement
Run state :

Measurement
Unit
Boolean

The value 0 for this measure indicates
that the object manager is unavailable.
While 1 indicates that the object
manager is online (i.e., it is available,
but not currently running any tasks), 2
indicates that the object manager is
running (i.e., it is available and is
currently running one/more tasks).

Boolean

This measure is a true indicator of load
on the object manager. As long as the
value of this measure is 0, it is an
indication of an optimal number of tasks
currently executing on the object
manager. If the value becomes 1, it
implies that the 'maximum tasks' limit
has been reached. When this happens,
eG
Enterprise
triggers
an
alarm
indicating an overload on the object
manager. During such circumstances,
the object manager will run out of
threads to execute any more tasks, and
will therefore be unable to handle
subsequent requests.

Indicates
the
current
state of this Siebel Object
Manager.

Max tasks reached :

Interpretation

Indicates whether this
object
manager
has
reached its 'maximum
tasks' limit or not.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

Maximum MTServers:

S e r v e r

Number

An MTServer is a multithreaded
component
process; this measure
indicates the maximum
number of MTServers per
component per server.
Active MTServers:

Number

The value of this should be close to the
value
of
the
Num_max_mts_svr
measure.

Percent

Ideally, the value of this measure should
be between 90-100%. A far less value
indicates that the object manager is
grossly under-utilizing the MTServers.
This happens when the object manager
does not have enough tasks to run, and
is more or less idle.

Indicates the currently
active MTServers on this
object manager.
Percent
usage
MTServers:

Indicates the percentage
of maximum MTServers
that are being actively
used
by
this
object
manager.

Components refer to the various tasks or programs that run on the Siebel server and perform the
work requested by the user. For example, the object manager is one of the key components on a
Siebel server. In order to effectively measure the end-user experience with a Siebel server, it is
essential to keenly observe and analyze the fluctuations in resource usage, responsiveness, and errors
encountered by these components. The Siebel Stats test, executed by an internal agent, enables such
an analysis. In the event of any deterioration in the performance of a Siebel server, the metrics
reported by this test will enable administrators to figure out whether there are any resourceintensive/error-prone components on the Siebel server, which are impacting its performance.

Purpose

Monitors the fluctuations in resource usage, responsiveness, and errors encountered
by the components on the Siebel server

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

Outputs of the
test
Measurements
made by the
test

One set of results for each Siebel server monitored.

Measurement
CPU time:

Measurement
Unit
Secs

Ideally, the value of this measure should
be low. A very high value could indicate
that users are executing one/more CPUintensive tasks on the Siebel server.
Further investigation is hence required
to zero-in on the resource-hungry
components.

Secs

This measure is indicative of time taken
by the task to complete its operation.

Indicates the total CPU
time for component tasks

Elapsed_time:
Indicates
the
total
elapsed (running) time for
component tasks.
Think time:

Interpretation

Secs

Indicates
the
average
end-user
think
time
between requests.
Total response time:

Secs

Indicates
the
total
amount of time taken by
the
components
to
respond to requests.
Total tasks:

Number

Indicates
the
total
number
of
tasks
completed for the server
components.
32

A very high value indicates slow
component responsiveness. Response
time issues can be caused by high
resource utilization or heavy load on the
components.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

Avg response time:

S e r v e r

Secs

A very high value indicates that the
component responds slowly to requests.
Response time issues can be caused by
high CPU utilization or heavy load on the
components.

Secs

Ideally, a low value is desired. A high
value indicates connection bottlenecks.

Number

Ideally, this value should be 0.

Indicates
the
average
time
taken
by
the
components to respond to
requests.
Avg connection time:
Indicates
the
average
connect
time
for
component sessions.
Errors:
Indicates
that
the
component job ran but
encountered
an
error
during operation.
Tests attempted:

Number

This indicates the number
of test attempted.
Tests failed:

Number

This metric represents the
number of tests failed.
Tests successful:

Number

This metric represents the
number of test successful.

This test provides the status of errors logged in the Siebel log files.

Purpose

Provides the status of errors logged in the Siebel log files

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel web server
3. PORT – The port number on which the Siebel web server is listening
4. ALERTFILE - specify the path to the log file to be monitored. For eg.,
C:/sea703/SWEBApp/LOG/Siebel_Web_log.txt. Multiple log file paths can be
provided as a comma-separated list.
Also, instead of a specific log file path, the path to the directory containing log
files can be provided - eg., C:/sea703/SWEBApp/LOG. This ensures that eG
Enterprise monitors the most recent log files in the specified directory. Specific
log file name patterns can also be specified. For example, to monitor the latest
log files with names containing the strings 'siebel' and 'log', the parameter
specification
can
be,
C:/sea703/SWEBApp/LOG/*siebel*,C:/sea703/SWEBApp/LOG/*log*. Here, '*'
indicates leading/trailing characters (as the case may be). In this case, the eG
agent first enumerates all the log files in the specified path that match the given
pattern, and then picks only the latest log file from the result set for monitoring.
You can also configure the path in the following format:Name@logfilepath. Here,
Name represents the display name of the path being configured. Accordingly,
the parameter specification for the 'siebel' and 'log' example discussed above
can
be:
siebel@C:/sea703/SWEBApp/LOG/*siebel*,log@C:/sea703/SWEBApp/LOG/*log
*. In this case, the display names 'siebel' and 'log' will alone be displayed as
descriptors of this test.
Every time this test is executed, the eG agent verifies the following:



Whether any changes have occurred in the size and/or timestamp of the log
files that were monitoring during the last measurement period;



Whether any new log files (that match the ALERTFILE specification) have
been newly added since the last measurement period;

If a few lines have been added to a log file that was monitored previously, then
the eG agent monitors the additions to that log file, and then proceeds to
monitor newer log files (if any). If an older log file has been overwritten, then,
the eG agent monitors this log file completely, and then proceeds to monitor the
newer log files (if any).
5. SEARCHPATTERN - Enter the specific patterns of alerts to be monitored. The
pattern should be in the following format: :, where
is the pattern name that will be displayed in the monitor
interface and is an expression of the form - *expr* or expr or *expr
or expr*, etc. A leading '*' signifies any number of leading characters, while a
trailing '*' signifies any number of trailing characters.
For example, say you specify Gen_errors:Generic* in the SEARCHPATTERN text
box. This indicates that "Gen_errors" is the pattern name to be displayed in the
monitor interface. "Generic*" indicates that the test will monitor only those lines
in the log which start with the term "Generic".

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

A single pattern may also be of the form e1+e2, where + signifies an OR
condition. That is, the is matched if either e1 is true or e2 is
true.
Multiple search patterns can be specified as a comma-separated list. For
example: Gen_errors:Generic*,Critical_errors:*Error*.
If the ALERTFILE specification is of the format Name@logfilepath, then the
descriptor for this test in the eG monitor interface will be of the format:
Name:PatternName. On the other hand, if the ALERTFILE specification consists
only of a comma-separated list of log file paths, then the descriptors will be of
the format: LogFilePath:PatternName.
6. LINES - Specify two numbers in the format x:y. This means that when a line in
the log file matches a particular pattern, then x lines before the matched line
and y lines after the matched line will be reported in the detail diagnosis output
(in addition to the matched line). The default value here is 0:0. Multiple entries
can be provided as a comma-separated list.
If you give 1:1 as the value for LINES, then this value will be applied to all the
patterns specified in the SEARCHPATTERN field. If you give 0:0,1:1 as the value
for LINES and if the corresponding value in the SEARCHPATTERN filed is like
Gen_errors:Generic*,Critical_errors:*Error*, then:
0:0 will be applied to the Gen_errors:Generic* pattern
1:1 will be applied to the Critical_errors:*Error* pattern
7. EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded
from monitoring in the EXCLUDEPATTERN text box. For example *critical*,
*generic*. By default, this parameter is set to 'none'.
8. UNIQUEMATCH - By default, the UNIQUEMATCH parameter is set to FALSE,
indicating that, by default, the test checks every line in the log file for the
existence of each of the configured SEARCHPATTERNS. By setting this
parameter to TRUE, you can instruct the test to ignore a line and move to the
next as soon as a match for one of the configured patterns is found in that line.
For example, assume that Pattern1:*Generic*,Pattern2:*Error* is the
SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE,
then the test will read every line in the log file completely to check for the
existence of messages embedding the strings 'Generic' and 'Error'. If both the
patterns are detected in the same line, then the number of matches will be
incremented by 2. On the other hand, if UNIQUEMATCH is set to TRUE, then the
test will read a line only until a match for one of the configured patterns is found
and not both. This means that even if the strings 'Generic' and 'Error' follow one
another in the same line, the test will consider only the first match and not the
next. The match count in this case will therefore be incremented by only 1.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

 The eG manager license should allow the detailed diagnosis capability.
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Measurements
made by the
test

Measurement
Recent errors:

Measurement
Unit
Number

Shows the number of
errors recently logged in
the Siebel log files.

Interpretation
The value of this measure is a clear
indicator of the number of “new” alerts
that have come into the log file of the
monitored server.

This test reports the current and completed tasks on every object manager on a Siebel server.

M o n i t o r i n g

t h e

S i e b e l

A p p l i c a t i o n

S e r v e r

Purpose

Reports the current and completed tasks on every object manager on a Siebel
server

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The hostname (or IP address) of the Siebel server
3. PORT – The port number on which the Siebel server is listening
4. INSTALLDIRECTORY – Provide the full path to the install directory of the Siebel
server
5. GATEWAYSERVER – Provide the IP address/host name of the Gateway server
6. ENTERPRISESERVER - This refers to the name that was specified for the
Enterprise server during a Siebel installation. An Enterprise server is a logical
entity. It collectively represents the Siebel application servers and gateway
server.
7. USERNAME – This test executes a command on the Siebel server to extract the
statistics of interest; this command requires administrator privileges to execute.
Therefore, enter the name of the Siebel administrator.
8. PASSWORD – Specify the administrator password
9. CONFIRM PASSWORD – Confirm the password by retyping it.
10. DETAILED DIAGNOSIS: To make diagnosis more efficient and accurate, the eG
suite embeds an optional detailed diagnostic capability. With this capability, the
eG agents can be configured to run detailed, more elaborate tests as and when
specific problems are detected. To enable the detailed diagnosis capability of
this test for a particular server, choose On option. To disable the capability, click
on Off option. The option to selectively enabled/disable the detailed diagnosis
capability will be available only if the following conditions are fulfilled:

 The eG manager license should allow the detailed diagnosis capability
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the

One set of results for each object manager on the Siebel server monitored

Measurement

Measurement
Unit

Interpretation

M o n i t o r i n g

test

t h e

S i e b e l

A p p l i c a t i o n

Running tasks:

S e r v e r

Number

Indicates the number of
tasks currently running on
this Object Manager.

Completed tasks:

The detailed diagnosis of this measure, if
enabled, provides the details of tasks
current running. Such details include the
task ID, the object manager that is
running the task, the mode in which the
task is running, and the data\time at
which the task began running. Using this
information, you can quickly identify
long-running tasks, and investigate the
reason behind the same.

Number

Indicates the number of
tasks
that
ran
to
completion and exited
normally on this Object
Manager.

This test monitors the status of incoming and outgoing traffic to the Siebel application server.

Purpose

Monitors the status of incoming and outgoing traffic to the Siebel application server

Target of the
test

A Siebel server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

Outputs of the
test

One set of results for each Siebel server monitored.

M o n i t o r i n g

Measurements
made by the
test

t h e

S i e b e l

A p p l i c a t i o n

Measurement
Request size:

S e r v e r

Measurement
Unit
Bytes

Indicates the size of
incoming requests to the
Siebel server.
Reply size:

Bytes

Indicates the size of
responses sent by the
Siebel server.

Interpretation
This measures helps you to quantify the
load on the Siebel server.

T r o u b l e s h o o t i n g

Chapter

Troubleshooting
If the tests related to the Siebel web server are not running, then first, try connecting to the following
URL, and check whether it takes you to a page that lists the session-related and other web serverspecific
metrics
for
a
configured
APPLICATIONNAME:
http:////_stats.swe?verbode=high. For instance, if
the IP address of the Siebel web server is, 192.168.10.12, and the APPLICATIONNAME configured for
a
Siebel
web
server-related
test
is
callcenter,
the
URL
will
be:
http://192.168.10.12/callcenter/_stats.swe?verbose=high.
If the URL does not result in the display of the desired web page, then proceed to check whether the
AllowStats
and
SessionMonitor
flags
in
the
eapps.cfg
file
(in
the
\sea\SWEApp\BIN directory) are set to TRUE. To know how, refer to
Page 5 of this document.
Also, you can verify the values reported by the tests associated with the Siebel application server
component, using the srvrmgr.exe in the \sea\BIN directory. The syntax
for the command is:

srvrmgr.exe /g /e /u
/p /c ""
For instance, to check whether the statistics reported by the SiebelTasks test are accurate or not, do
the following:
1. Go to the command prompt of the Siebel application server.
2. Switch to the \sea\BIN directory.
3. Assume that the SiebelTasks test takes the following parameters:
GATEWAYSERVER - 192.168.10.58
ENTERPRISESERVER - siebel
USERNAME - sadmin
PASSWORD - sadmin
4. Then, execute the following command on it:

srvrmgr.exe /g 192.168.10.58 /e siebel /u sadmin /p sadmin /c "list tasks", where "list tasks" is the subcommand that is executed for viewing task-related metrics.

Similarly, the command for the SiebelStats test, will be:
40

T r o u b l e s h o o t i n g

srvrmgr.exe /g 192.168.10.56 /e siebel /u sadmin /p sadmin /c "list stats"
The following command will have to be executed for viewing the list of object managers configured on
the Siebel server:

srvrmgr.exe /g 192.168.10.56 /e siebel /u sadmin /p sadmin /c "list comps"
For the SiebelNet test, on the other hand, a utility named visutl.exe will have to be run from the
\sea\SWEApp\BIN directory. The syntax of this command is:

visutl.exe /u /p /c
/d /n

For instance, assume that you want to verify the accuracy of the measures reported by the SiebelNet
test, which takes the following parameters:
USERNAME - sadmin
PASSWORD - sadmin
SIEBELDATASOURCENAME - SiebSrvr_siebel
TABLEOWNERNAME - siebel
NODENAME - siebel
To
achieve
this,
execute
the
following
\sea\SWEApp\BIN directory:

visutl.exe /u sadmin /p sadmin /c SiebSrvr_siebel /d siebel /n siebel

command

from

the

C o n c l u s i o n

Chapter

Conclusion
This document has described in detail the monitoring paradigm used and the measurement
capabilities of the eG Enterprise suite of products with respect to Siebel Enterprise. For details of how to
administer and use the eG Enterprise suite of products, refer to the user manuals.
We will be adding new measurement capabilities into the future versions of the eG Enterprise suite. If
you can identify new capabilities that you would like us to incorporate in the eG Enterprise suite of
products, please contact support@eginnovations.com. We look forward to your support and
cooperation. Any feedback regarding this manual or any other aspects of the eG Enterprise suite can
be forwarded to feedback@eginnovations.com.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Create Date                     : 2013:12:06 15:24:12+05:30
Modify Date                     : 2014:10:16 11:12:45+05:30
Page Count                      : 46
Language                        : en-IN
Tagged PDF                      : Yes
Author                          : Geetha
Creation Date                   : 2013:12:06 15:24:12+05:30
Mod Date                        : 2014:10:16 11:12:45+05:30
Producer                        : Microsoft® Word 2013
Metadata Date                   : 2014:10:16 11:12:45+05:30
Title                           : Manual
Creator                         : Geetha

EXIF Metadata provided by EXIF.tools

Manual Monitoring Siebel Enterprise

Navigation menu

Versions of this User Manual:

Views

Navigation