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.
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.
|
.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. |
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. |
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
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.
Search this documentation
On this page
In this section