Frontend Servers

A technical walk-through of how PerformanceGuard frontend servers work. The frontend server runs as the Windows service PerformanceGuard Frontend Server from the collector subfolder of the PerformanceGuard installation folder.

Management

Telnet interface

The frontend server exposes a Telnet interface. By default, the Telnet server runs on port 4002. You can change the port with the admin-port parameter.

To sign in to the frontend server Telnet interface, use the user name and password of a PerformanceGuard user that has the administrator role, for example the built-in admin user.

Caution

Change the password of the built-in admin user after installation.

When you connect to the frontend server via Telnet, type help to view a list of available commands. For example, version shows the server version, status shows the database and time status, conf shows the server configuration, and exit ends the session.

Log files

The frontend server writes its log to pgfrontend.log in the collector\logs subfolder of the PerformanceGuard installation folder. When the file reaches 10 MB, the frontend server starts a new file and keeps up to 10 older files (pgfrontend.1.log to pgfrontend.10.log).

The logging detail level is configured in [PerformanceGuard installation folder]\collector\conf\logback.xml.

The Windows service also writes the standard output and standard error of the frontend server process to separate log files in the same folder.

The log files are text files that you can open in any text editor. PerformanceGuard administrators can also see them on the Log Files tab in the PerformanceGuard web interface. See View Log Files.

Test connectivity

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.

In this example, the IP address of the frontend server is 192.168.101.67 and the port that agents connect to is 4001:

C:\>telnet 192.168.101.67 4001

After Telnet has started, type p. The frontend server replies in clear text, for example:

Performance Guard Frontend Server <version> - Ping reply

If you get this reply, the network path to the frontend server has been successfully set up. The frontend server closes idle sessions after a few seconds. The exact timeout is set by the Socket Timeout parameter.

Database indexes automatically reorganized

The frontend server reorganizes fragmented indexes in the frontend database once a day, between 19:00 (7 PM) and 04:00 (4 AM) local time. Your database administrator doesn’t need to reorganize these indexes manually.

To turn this off, set Rebuild Indexes to 0 on the Frontend tab under ADMINISTRATION → Setup → Parameters. The default is 1 (on).

Parameters

The frontend server gets its settings from three places:

• [PerformanceGuard installation folder]\Settings.ini: the agent port, the backend server host name and port, and the frontend database connection. See Server Settings Ini.
• [PerformanceGuard installation folder]\collector\conf\config.properties: the parameters described in this section.
• The Frontend tab under ADMINISTRATION → Setup → Parameters in the PerformanceGuard web interface, for example Socket Timeout, Responsetime Histogram Intervals, and Rebuild Indexes.

Restart the PerformanceGuard Frontend Server service after you change Settings.ini or config.properties.

Settings in Settings.ini

Setting	Default value	Description
AGENT_PORT	4001	The port where agents connect and deliver reports.
BACKEND_HOSTNAME		The host name of the backend server.
BACKEND_PORT	4008	The port that the frontend server uses to contact the backend server.
FE_DB_USER		The frontend database user name.
FE_JDBC_CONNECTSTRING		The JDBC connection string for the frontend database.

Caution

Make sure that no other application uses the agent port. Before you start the frontend server service, you can check it, for example with netstat. If another application already uses the port, agents may send their data to that application. Because there’s no acknowledgment from the frontend server when data is sent, the agents may then report that they have delivered data to the backend server when they haven’t.

Parameters in config.properties

admin-port
Type	TCP port
Default value	4002
Description	The port of the Telnet interface. The value 0 turns off the Telnet interface.

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

backend.timeout
Type	Integer (milliseconds)
Default value	90000
Description	Socket timeout for the connection to the backend server.

customcounter.fileperiod
Type	Integer (seconds)
Default value	600
Description	Specifies how often a new custom counter spool file is created. If you set the period to less than 300 seconds, 300 seconds is used.

customcounter.filedir
Type	String
Default value	ReportFileStore
Description	Specifies the folder for custom counter spool files. A relative path is relative to the collector folder. To use another folder, specify the full path, for example c:\\Test\\ReportFileStore. Spool files are deleted after five days by default. Sizing example: 1000 agents that measure 10 counters, with a file period of 300 seconds, generate about 1440 files in five days. Each file uses about 45 MB, which is about 65 GB in total.

Parameters in the web interface

Socket Timeout
Set in	Frontend tab under ADMINISTRATION → Setup → Parameters
Type	Integer (milliseconds)
Default value	5000
Description	How long the frontend server waits to receive a complete packet from an agent before it closes the connection.

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 60 seconds, or there is more than about 330 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 about 330 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 speed spoolers, or files that are larger than 5 MB in case of low speed spoolers.

The following spoolers exist:

• 4 default spoolers with spooling speed medium
• 2 aggrip spoolers with spooling speed high
• 2 aggripprocess spoolers with spooling speed high
• 2 aggr spoolers with spooling speed high
• 1 fast spooler with spooling speed high
• 1 fastStatic spooler with spooling speed high
• 1 chunk spooler with spooling speed low
• 2 trace spoolers with spooling speed high
• 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.