Performance Monitor Configuration
The Performance Monitor is divided into a server agent, which gathers information about specific requests and determines when it should be logged, and a logger, which collects the information from the agent and structures it so that the log is easily readable.
The properties of these two components are configurable through the Performance Monitor user interface. Access this UI through your browser, using the same URL that you use to log in to your TeamConnect instance, but substituting jmonitor for login. For example:
http://myserver:port/instancename/jmonitor
The resulting page displays several buttons.
- Click Change Password to set a new password.
- Click Update Configuration to view and change the various configurable properties, which are described in the table below.
Configurable Properties for Performance Monitor
|
Property |
Definition |
|---|---|
|
Enabled |
This checkbox determines whether the server agent should collect performance data at all. |
|
Threshold (milliseconds) |
All requests exceeding this threshold are logged (along with all associated data) once they complete. Default=30000. |
|
StuckThreshold (milliseconds) |
As soon as a requests exceeds this threshold, it is logged immediately (along with all associated data gathered to that point). Also, if email is configured (see settings below), a "stuck" alert is emailed to the configured address(es) containing the same data that was written to the log file. If the request later completes, an additional email is sent that the request has completed (become "unstuck"). Default=600000. |
|
Stack Trace Initial Delay(milliseconds) |
Once a request exceeds this initial delay, stack traces for the thread processing the given request are gathered periodically (see stackTracePeriodMillis below). Default=10000. |
|
Stack Trace Period (milliseconds) |
Once a request exceeds an initial delay (see Stack Trace Initial Delay above), this is the interval at which successive stack traces for the thread processing the given request are gathered. Default=1000. |
|
Maximum Trace Events per Request/Operation |
If the number of stack traces for one request reaches this maximum number, no additional trace events are gathered Default=1000. |
|
Log Archive Filename Pattern |
This naming pattern controls how frequently the log file is rolled over. It can also control file compression if you add a standard compressed-file extension such as .gz or .zip to the end of the pattern. The pattern can contain a path specification, which is useful in separating the archive log files from the currently active log file (see next property.) Default="jmonitor%d{yyyy-MM-dd}.log, which specifies daily rollover and no compression. |
|
Log Active Filename |
This naming pattern can contain a path specification, which is useful in separating the archive log files from the currently active log file there is no default value. If you do not supply a value, the "Log Archive Filename Pattern" value will be used. |
|
Log Max History |
If you enter an integer here, then the number of archived log files will not exceed that integer. The oldest archives will be deleted as new ones are created. Default=0 (no limit on number of archived logs). |
|
Email Host |
SMTP host to send email through. |
|
Email Smtp Port |
The port used to communicate with the SMPTP host. Default=25. |
|
Email Username |
Username if SMTP host requires authentication. |
|
Email Password |
Password, if SMTP host requires authentication. |
|
Email SLL |
Set to this box to checked if the SMTP host requires an SSL connection. |
|
Email From Address |
Email address to use as the sender. |
|
Email To Addresses |
Comma-separated list of email addresses to send alerts. |
|
Maximum Trace Elements emailed per Operation |
Controls the size of the email messages by limiting how much trace event information is contained in an email. |
Recovering a Lost Password
The value of the administrator password, used for logging in to Performance Monitor, can also be changed by editing the properties file and updating the password property with the new password in clear text, e.g., adminPassword=mynewpassword. Updating the properties file requires a restart, after which the monitor will encrypt the password and update the jmonitor.properties file with the encrypted value. Using this approach requires that you have access and authority to the jmonitor.properties file.
Important Information About Garbage Collection
Garbage collection is a common cause of performance issues which cannot be detected from the TeamConnect Performance Monitor logs. Garbage collection logging should be on in production environments and these logs should be analyzed in conjunction with the TeamConnect Performance Monitor logs. Mitratech typically recommends these GC logging settings for the Sun JVM:
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:-TraceClassUnloading
Optionally include -Xloggc:<file> if the application server is not capturing stdout to a log file. The only downside to this option is that it overwrites <file> on every restart, which can erase valuable information.
Use this GC logging setting for the IBM JVM:
-verbose:gc
This setting is the same as enabling the Verbose garbage collection checkbox in WebSphere administration console.
Clustering
Support for clustering requires configuring Performance Monitor separately on each node. The monitor web interface is node-specific, so it will work best if you have direct access to address the monitor web interface on each node individually, as opposed to access through a front end load balancer.