Frontend Servers

A technical walk-through of how PerformanceGuard frontend servers work.

Management

Telnet Interface

The frontend server exposes a Telnet interface. By default, the Telnet server runs on port 4002, but the port number may be changed using the admin-port parameter.
In order to log in to the frontend server Telnet interface, you need to supply the name and password of the PerformanceGuard administrator. By default this is

• User name: admin
• Password: admin

When you connect to the frontend server via Telnet, type help to view a list of available commands.

Caution

If you run the stat command to view frontend server statistics in the Telnet interface, for example stat 10 to view statistics for the last 10 seconds, the unique column in the results shows the change in the number of agents that have been added to the frontend server. Thus, if the unique column shows 100, you’ll know that 100 more agents have been added to the frontend server. However, note that the value reflects the change in added agents: So, the value 100 could very well mean that 200 agents have been added while 100 were removed. That’s the reason why you can also experience negative numbers in the unique column, if the number of removed agents is higher than the number of added agents.

Log Files

By default, the frontend server logs important information in its log files located in the /collector/logs subfolder of the PerformanceGuard installation folder.
The frontend logging mechanism is implemented using Java™ Logging. 

The logging detail level, etc. is configured in the file specified in the log-config file parameter; by default this is the file [PerformanceGuard installation folder]\collector\conf\log4j.properties.

Test Connectivity
The logging detail level, etc. is configured in the file specified in the file logback.xml.

The stderr and stdout from the collector process are redirected to two files - stderr.log and stdout.log respectively.

The log files are ASCII text files, and are usually just accessed with an editor or Windows Notepad.

In complex environments it’s sometimes necessary to test if the network path (for example firewalls, proxies and routers) has been successfully set up from a location to the frontend server.
If everything is fine, agents will appear in the list of active agents in the PerformanceGuard web interface.

If an agent doesn’t appear as active in the PerformanceGuard web interface, and you suspect that the network is causing the problem, you can test if a connection can be established using the Windows Telnet command.

The IP address of the frontend in the example is 192.168.101.67 and the port that agents connect to is 4001.
c:>telnet 192.168.101.67 4001ping PremiTech PerformanceGuard Collector - Ping reply Connection to host lost. C:>
After Telnet has started, you need to type p and the frontend will reply to you in clear text. The frontend will terminate idle sessions after a few seconds, the exact timeout is determined by the socket-timeout parameter.
If you get this reply from the frontend server PremiTech PerformanceGuard Collector - Ping reply, the network path to the frontend server has been successfully set up.

Database Indexes Automatically Reorganized

Your database administrator (dba) will appreciate that the frontend server database indexes are automatically reorganized once a day, between 19.00 (7 PM) and 04.00 (4 AM) local time. The dba does thus not need to reorganize indexes himself.

Parameters

The frontend server accepts parameters from a standard Java .properties file located in [PerformanceGuard installation folder]\collector\conf\config.properties.

admin-port
Type	TCP port
Default value	4002
Description	Telnet TCP port. The port used to send administrative commands, like start and stop.

admin-role
Type	String
Default value	E2EAdministrator
Description	The name of the administrator user role.

connection
Type	String
Default value
Description	This is the name of the database connection to use. This name is preceding all the parameters used for the database, that is it’s possible to have multiple database setups, Setting this parameter accordingly will change which one is effective.

.user
Type	String
Default value
Description	The database user name.

.password
Type	String
Default value
Description	Password of the database user.

.url
Type	String
Default value
Description	Defines a JDBC URL used to connect to the database. For ORACLE: 1. jdbc:oracle:thin:@win2000server:1521:win2k For SQL Server: 2. jdbc:jtds:sqlserver:\\win2000server;instance=win2000

.maxcom
Type	Integer
Default value
Description	Defines the maximum number of connection that the collector should make to the backend database.

log-configfile
Type	String
Default value
Description	Specifies where to find the file that defines the logging levels etc for the collector. The config file follows the java.util.logging format as described in: {*}http://java.sun.com/j2se/1.4/docs/api/index.html*

max-threads
Type	Integer
Default value
Description	The maximum number of threads that the collector should create in order to service the agents.

min-threads
Type	Integer
Default value
Description	The maximum number of threads that the collector should create in order to service the agents.

.port
Type	Integer between 1024 and 65535
Default value
Description	The port where agents should connect and deliver reports. Make sure that this port isn’t used by any other application. Prior to starting the collector service you can check e.g. using netstat if the port is in use. Configuring the collector to run on an already used port means that the data from the agents are aimed at the application that first requested to service the port. As there is no acknowledgment from the collector when data is send to the collector, agents may be fooled into thinking that they have actually delivered data to a collector, and indicate that they have successfully delivered data to the backend.

socket-timeout
Type	Integer
Default value
Description	Specifies in milliseconds, how long the collector should wait for receiving a complete packet from the agent before disconnecting.

backend.port
Type	TCP port
Default value
Description	Specifies on which port to contact the backend server.

backend.hostname
Type	String
Default value	localhost
Description	Specifies the hostname of the backend server.

backend.connections
Type	Integer
Default value	10
Description	Specifies the number of socket connection from the frontend server to the backend server.

backend.timeout
Type	String
Default value	9000
Description	Socket-timeout for the connection to the backend server.

customcounter.fileperiod
Type	Integer
Default value	300
Description	Specifies in seconds, how often a new spool file will be created. If the period is set to below 300, then the default will be used.

customcounter.filedir
Type	String
Default value	ReportFileStore
Description	Specifies the default folder that’ll be created for spool files. To change the path, this format should be used - c:\Test ReportFileStore. If the path isn’t set, then the default folder will be created relative to the frontend server. Sizing considerations: 1000 Agents 10 Counters measured using the 300 seconds, that is the default period of each created spool files. Generates: Approx. 1440 files in 5 days (before being removed) Each file uses approx. 45 MB. For a total of approx 65 GB.

Spool Files

The frontend server spool files folder, [PerformanceGuard installation folder]\collector\spooler, contains files consisting of the buffers of data that the frontend server receives from PerformanceGuard agents.

When agents send reports to a frontend server, the frontend server stores them in an internal buffer in memory. Periodically, these buffers get written (or spooled) to the disk, then read from the disk and sent to the backend server. The purpose of this is to avoid data loss in case the frontend server or backend server becomes unavailable.

There are three speeds with which the buffers can get spooled:

• High: Time since the last buffer write to disk is more than 20 seconds, or there is more than 300 KB of data in the buffer
• Medium: Time since the last buffer write to disk is more than 120 seconds, or there is more than 300 KB of data in the buffer
• Low: Time since the last buffer write to disk is more than 180 seconds, or there is more than 3 MB of data in the buffer

Caution

File sizes on the disk can vary beyond the limit that triggers a write because of timing factors in buffer handling. However, you should not see files that are much larger than 1 MB in case of medium and high speeed spoolers or files that are files larger than 5 MB in case of low speed spoolers.

The following spoolers exist:

• 8 default spoolers with spooling speed medium
• 4 aggr_ip spoolers with spooling speed high
• 4 aggr_ip_process spoolers with spooling speed high
• 2 aggr spoolers with spooling speed high
• 4 fast spoolers with spooling speed high
• 1 chunk spooler with spooling speed low
• 1 trace spooler with spooling speed medium
• 1 events spooler with spooling speed high

PerformanceGuard uses parallel spoolers to reduce lock contention and to increase the number of simultaneous file transmissions to the backend server.