This appendix lists and defines the files and directories available in CAMM. Topics include:
After CAMM is installed all the components of the application package are located in $CAMM_HOME directory.
The following is the $CAMM_HOME directory structure once CAMM is installed:
Table A-1 Directories in $CAMM_HOME Directory
| Directory | Description |
|---|---|
|
apache-tomcat-5.5.20 |
Tomcat server where CAMM Web Application (GUI) is located |
|
bin |
Contains all the executable files to start and stop CAMM, run deployer for Agent and CAMM EJB, run export utility. |
|
config |
Contains all the CAMM runtime configuration parameters that control execution logic, CAMM schemas enablement, CAMM GUI functionality, Service Level Objectives definition, export logic and many more. |
|
darchive |
Stores temporary images for J2EE applications that need to be monitored as well as the results of analysis and modeling of the J2EE application. This directory is created once CAMM is up and running. |
|
deploy |
Contains agent libraries and configuration files, as well as CAMM EJB and CAMM Admin Web Application. These components are deployed on the remote host (Web or Application servers) using deployer utility found in bin directory of CAMM package. |
|
j2sdk |
Contains minimum Java SDK sufficient to run CAMM Server. |
|
lib |
Has all the libraries required for CAMM's proper functionality |
|
log |
Has all the diagnostics records of CAMM performance metrics collection activities. Also logs indicating successful deployment of CAMM Agents can be found here. This directory is created once CAMM is up and running. |
|
mcconfig |
Contains internal base instrumentation configuration. Do not modify these files. |
|
tmp |
Contains all the metadata definitions used for CAMM's needs. |
|
Uninstall CAMM |
Contains utility used to uninstall the CAMM. |
|
userdata |
Contains saved custom views per user. |
Config directory has many files that potentially can be configured and make CAMM to run in a particular way. Any changes applied to files in this directory require restarting CAMM server.
Most of the files never get touched directly by user. The following are the main three files which can be configured manually to achieve desired effect:
| File | Description |
|---|---|
| Acsera.properties | This file is the main CAMM configuration file customization of which helps to tune up CAMM. |
| configuration.xml | In this file you define location of Administration Server and credentials to access it. Usually you do not touch this file. The entire configuration is done through CAMM GUI. |
| dbconfig.xml | This file contains database configuration information for the CAMM metric repository. |
| export.xml | This file contains information that drives proper data export logic. It is used for manual and automatic export of performance metric and events data from the CAMM Data Repository. |
| UrlMap.properties | This file is used to map server addresses to load balancer addresses. |
It is worth mentioning that Service Level Objective definitions and Actions associated with the SLOs are described in slo.xml and event.xml respectively. The content of these files is completely controlled by definitions applied from CAMM GUI (configuration tab).
The /bin directory has all the executable files to start and stop CAMM, run deployer for Agent and CAMM EJB, run export utility.
There are two main reasons why one would need to customize the content of the files in this directory:
To change the pointers to the location of Java Runtime Environment and CAMM installation directory (ACSERA_HOME)
To configure CAMM Server JVM parameters, e.g. memory.
Only the files that are frequently customized will be described in this chapter.
All the files in this directory should have these lines, pointing to the CAMM Installation location:
For UNIX: ACSERA_HOME=/home/CAMM; export ACSERA_HOME
For Windows: set ACSERA_HOME=C:\oracle\em10g\
In addition, acseraenv.sh(.bat) should have a pointer to the JDK used by CAMM:
For UNIX: JAVA_HOME=/home/oracle/em10g/j2sdk;export JAVA_HOME
For Windows: set JAVA_HOME=C:\oracle\em10g\j2sdk
CAMM is a Java application and runs in its own JVM. Default size of JVM memory is 600 MB. Should you want to change this value you can do so by modifying -Xms and -Xmx parameters in acsera.sh (.bat) file.
Bear in mind that if you have installed CAMM as a Windows service and need to change the JVM Memory size, you need to change the size either by updating the Windows Registry or rerunning the createmanagerservice.bat utility with the new JVM parameters.
The /deploy directory contains CAMM Java Agent and OS Metric Agent distributables, including configuration files as well as corresponding libraries. These files are copied to the target systems hosting the Managed Servers when running the deployer utility. Rarely one needs to modify configuration files in this directory. Remember though if you modify the files they will be distributed to ALL targets within single server/cluster.
The acsera.properties file contains global configuration parameters that define the operation of the CAMM Manager.
This section of Acsera.properties file defines log rotation policies. Log.MaxFiles indicates max number of log files available at any given moment, whereas the Log.MaxFileSizeMB indicates maximum size of the log file.
Example A-1 Log Files Management Section
Log.CopyOut = false Log.MaxFiles = 10 Log.MaxFileSizeMB = 30 Log.MergeLogs = true Debug.CopyOut = false Debug.LogLevel = all Debug.MaxFiles = 10 Debug.MaxFileSizeMB = 30
Log files are stored in the log directory.
This section enforces the password policies and the CAMM user session time out.
The following are the parameters to enforce password policies:
length
expiration
complexity
allowed special characters
Example A-2 User Password Management
ConfigurationManager.PasswordMinLength=0 ConfigurationManager.PasswordMaxLength=0 ConfigurationManager.PasswordExpDays= ConfigurationManager.PasswordMinLetters=0 ConfigurationManager.PasswordMinDigits=0 ConfigurationManager.PasswordMinSecialChars=0 ConfigurationManager.PasswordSecialCharSet=!@#$%^&*()_+[]
The default is no length or complexity or expiration day limitation.
Password length control equal to 0 means no restriction. Any other number, we will check for min and/or max length.
Password expiration - if any number set then the password will expire after the specified days.
Password complexity - forces to check letter, digits, and special characters. Default is no complexity check. If you set any number on any of these properties, CAMM checks complexity. For example, PasswordMinLetters=2 means you must have at least 2 letters in your password.
For special characters checking, there is a list of default special characters. This is configurable.
CAMM User Session can be set to time out after a specified time.
Example A-3 CAMM User Session Time Out
# ConfigurationManager.SessionTimeout's unit is minutes. ConfigurationManager.SessionTimeout=10
The default is 10 minutes, which means that after 10 minutes of no activity on the applet the applet will close automatically and redirect the user back to the login screen.
One can limit number of domains to be monitored by setting resource limit parameter: ConfigurationManager.ResourceLimit=2
The default is 2, this means that by default CAMM is set to monitor no more than two Application Server domains.
CAMM uses RMI ports for communication with the agents and collects incoming performance metrics from a particular RMI port. By default, the RMI port is set on the same machine that hosts CAMM. RMI.Registry.Host needs to be un-commented and have a value other than localhost if the host is multi-homed (such as, many network interfaces or has any ipv6 addresses) and you need to make sure that CAMM listens to the incoming traffic on the particular interface.
You may need to change RMI.Registry.Port value in case the default 51099 port number has been allocated to an other application. Also if CAMM is running in multi-instance mode, the port number will be different from instance to instance.
CAMM has sophisticated multi-tiered logic for aggregation (or compression) of performance data. This helps to optimize performance of interaction with the internal data repository both when querying data for presentation or inserting new performance metrics.
Users who want to store longer term data should look for this section in Acsera.properties:
######################### # Production setting # NOTE: use Model.GlobalSamplingRateSecs to configure Metric.Grain.0 ######################### Metric.Grain.0 0s Metric.TableInterval.0 = 4h Metric.DataLife.0 = 8d Metric.Grain.1 = 3m Metric.TableInterval.1 =1d Metric.DataLife.1 = 8d #Metric.Grain.2 = 30m #Metric.TableInterval.2 = 7d #Metric.DataLife.2 = 420d
and uncomment the last 3 lines for the Metric.*.2 properties
CAMM by default aggregates data coming from multiple cluster members by application thus minimizing rate of insertion in to the data repository. This greatly improves performance of CAMM in heavily loaded environment.
As a side effect of this approach though, the user is unable to see metrics from instrumentation (processes and portals) on per server level. If you need to enable this then set the JavaMIP.AggregateInserts to false.
To avoid overhead of unnecessary monitoring of certain applications, you can explicitly state which applications to monitor, or which applications to exclude from monitoring.
Users should append the name of their application to the property ComponentProvider.Application.Exclude.
If there is a firewall between the CAMM Manager and the monitored application servers, ports need to be opened between them. In addition to the application server's JMX access ports, the following two properties in Acsera.properties indicate the ports used specifically by CAMM:
RMI.Registry.Port (51099 by default)
RMI.JavaProvider.ServerPort (55003 by default)
There are times when you deliberately want to cut down on the number of repeated notifications should SLO violation persist for a given period of time. To suppress notifications of the same violation in a short period of time, CAMM provides the SLO Dampening feature. Once enabled, should a SLO violation occur and be repeated several times in a short period, CAMM will not fire the SLO violation notification for the time period defined in SLO.RearmDelay. To disable this feature, set the value of this parameter to 0.
SLO.SuppressDelayedAsserts indicates that if the violation still persists upon time period expiry CAMM, should fire the SLO notification. By default it is false, for example, fire the notification.
The UrlMap.properties file should be created in the CAMM Manager's config directory and used to provide address mappings between load balancers and application servers. The format of this file is:
# Format: # $app_server_ip = $load_balancer_id # E.g: # http\://localhost\:7001 = http\://localhost\:7005 # # Note: ":" character need to be escaped with "\" # http\://192.168.128.53\:7002 = http\://192.168.3.187\:80 http\://192.168.128.53\:7003 = http\://192.168.3.187\:80 http\://192.168.128.54\:7005 = http\://192.168.128.54\:7011 http\://192.168.128.54\:7006 = http\://192.168.128.54\:7011