GL Trade
Introduction Copied
The Geneos GL Trade plugin monitors the GL system and displays information for each dataview. This document includes the dataviews and plugin configuration for GL Router plugin.
Note
Beginning Geneos 6.0.x, all the GL Trade plugins, except for GL Router, are no longer supported.
GL Router Copied
The GL Router plugin monitors Users and Server connections to the GL P3 router process.
Users View Copied
This view shows a daily history of user connections, Local and Remote, Current and Expired.
Users Headline Legend
Users Table Legend
Name | Description |
---|---|
Total SLE users today |
Cumulative daily total of SLE User
connections.
(Requires entry in names.ini file to
translate server name SLE).
|
maxConcurrentUsers | Maximum number of concurrent users |
Current SLE users |
The number of user currently logged on to
the SLE server.
(Requires entry in names.ini file to
translate server name SLE).
|
Current SLC users |
The number of user currently logged on to
the SLC server.
(Requires entry in names.ini file to
translate server name SLC).
|
Name | Description |
---|---|
Key | Unique User:Node:Subnode identifier. |
userName | |
ipAddress | The user's workstation IP Address. |
logonTime | The time that the user logged on to GL system. |
logoffTime |
The time that the user logged off from GL
system.
(Blank if still logged on).
|
userType | GL API or GL Win. |
localRouter | The router to which the user is directly connected. |
remoteRouter |
The router that connects the user to the
market..
Same as local router if stand alone
configuration (i.e. not across GL Net).
|
serverName | |
RtrStatus | The current status of the router. |
SrvrStatus | The current status of the Server |
userid | Actual GL Trade system IDs. |
localRouterId | Actual GL Trade system IDs. |
remoteRouteID | Actual GL Trade system IDs. |
serverId | Actual GL Trade system IDs. |
Summary View Copied
This view shows the current API and GL Win Users on SLE and SLC.
defined in the names.ini file for a user connection to be counted.Note
The SLE and SLC servers must be
Summary Table Legend
Name | Description |
---|---|
SLE | Number of users/servers on SLE |
SLC | Number of users/servers on SLC |
Servers View Copied
This view shows the Router connections to the SLE and SLC servers, a relay type router (i.e. local P3 connect to broker’s P3) shows the remote server connections
Servers Table Legend
Name | Description |
---|---|
Key | Unique User:Node:Subnode identifier. |
routerName | The name of the Router. (or the GL RouterID if no translation entry is defined in the names section or the file specified by the namesFile section). |
serverName | The name of the Server (SLE or SLC) or the GL ServerID if no translation entry in names.ini file. Entries that show P3 or are blank, refer to the actual P3 status. |
Connection | Indicates either "Direct" or via "GL Net". |
Status | Server/Router status either "Up" or "Down". |
uptime | The time the Server/Router came up. |
downtime | The time the Server/Router went down. |
routerID | Actual GL Trade system IDs. |
serverId | Actual GL Trade system IDs. |
Connections View Copied
This view is only shown if value p3v5IniFilename is defined in the plugin configuration.
command which is part of the net-tools package. The net-tools package is not included in the minimal RHEL7 installation by default. As a result, the net-tools package must be installed separately on a minimal RHEL7 installation in order for the plugin to work.Note
This plugin uses the netstat
Connections Table Legend
Name | Description |
---|---|
Column1 | Description1 |
Column2 | Description2 |
Plugin configuration Copied
The following parameters can be configured for this plugin:
p3LogDir Copied
Specifies the full path to the GL directory for the P3 log files
Mandatory: Yes
names Copied
This section associates textual names with the IDs of the GL routers, GL Server processes (e.g. SLE, SLC, Selector) and GL users. It contains a gl-names > servers section, one or more gl-names > users sections and an optional gl-names > api-names section.
namesFile Copied
This section specifies the path to a file containing the associations between textual names and GL router IDs. The format of this file is described in Names.ini configuration. If the names section has been defined, then the data in the names section will be saved in the file specified in this section in the format described. Mandatory: No Default: “names.ini”
apiNamesUnique Copied
By default, GL API application names are used as the unique session identifier. This means that when an api client loggs on and off and on again it will be shown as a single row, even when its GL user id changes with every new logon.
If the API names are not unique , the above algorithm will cause multiple api clients to be shown as one row. To show each API client on a separate line, set ApiNameUnique to False in the Sampler Descriptor.
time an API client connects and disconnects a new line will be shown. Disconnected users can be set to auto clear after an interval defined by RemoveLoggedoffUsersInterval setting. Mandatory: No Default: TrueNote
The drawback of this is that every
allowDuplicateUsers Copied
[Explanation paragraph 1]
[Explanation paragraph 2…and so on] Mandatory: [Yes/No] Default: [Value]
removeLoggedoffUsersInterval Copied
Disconnected users and API connections can be set to auto clear after the number of seconds defined by RemoveLoggedoffUsersInterval .
When set to -1, the logged off users and API connections are not removed Mandatory: No Default: 43200 (- 12 hours) Units: seconds
previousFiles > fileCount Copied
This is used for exchanges which are up 20 hours and where logins can persist across days. This informs the plugin how far back in time to look to find existing logins. (This would be the period between P3 reconnects). Mandatory: No Default: 0 Units: days
previousFiles > useStagedInitialisation Copied
If set to true then the plugin will read a maximum of one file per sample. This is used when reading multiple p3 files at initialisation and the p3 files are large. Mandatory: No Default: false
p3v5IniFilename Copied
The full path (including filename) of the p3v5.ini file. The “Connections” view is only shown if this setting is configured. Mandatory: No Default: ""
Gl-Names Copied
The GL names section can be shared between different samplers. If it is to be shared, then it is stored in the “Static Vars” section of the setup rather directly in the sampler. Below are the gl-names settings. These can be set in the sampler or in the “Static Vars” section.
gl-names > servers Copied
This section defines a list router/server pairs. Each server entry in the servers section represents a router/server pair.
gl-names > servers > server > id Copied
This is the GL of the server. It is the combination of the router node id and the server subnode separated by a period.
Mandatory: Yes
gl-names > servers > server > type Copied
This is the type of the server. Mandatory: No Default: ""
gl-names > servers > server > name Copied
This is a freeform text description of the router/server pair Mandatory: No Default: ""
gl-names > servers > server > ignore Copied
Set this to true if the specific router/server pair does not need to be monitored Mandatory: No Default: false
gl-names > users Copied
This section defines a user/router community. In most cases there need only be one users section, containing all the users and all the routers. However where there is more than one user with the same ID connecting from different routers (for example on a broker site) they must be separated into different user sections.
gl-names > users > router Copied
This specifies the numeric ID of a router and freeform name to describe the router. There can be more than one user entry per users section. Both the name and ID of the router are mandatory.
Mandatory: No
gl-names > users > user Copied
This specifies the numeric ID of a user and freeform name to describe the user. There can be more than one user entry per users section. Both the name and ID of the user are mandatory.
Mandatory: No
gl-names > api-names Copied
This section is used to describe GL API applications that do not use a fixed name.
For example, where the name is PARSE_345 when the application connects for the first time, and then PARSE_366 the next time they connect and so on. In this case PARSE_ should be defined in this section.
Not using this to section to describe such connections will result in the application being treated as a user, and every time the application connects or disconnects then dummy users will be generated in the GL-ROUTER-USERS window.
This specifies the textual ID of an application and freeform name to describe the application. There can be more than one user entry per users section. Both the name and ID of the application are mandatory.
Mandatory: No
Names.ini configuration Copied
This is an optional reference file that associates textual names with the IDs of the GL routers, GL Server processes (e.g. SLE, SLC, Selector) and GL users. This file can be used instead of defining the data in the names section of the plugin.
The file should always contain one [SERVERS] section and one or more [USERS] section, and optionally an API_NAMES section.
For example:
[SERVERS]
SERVER_ID = 18999.7800, SERVER_NAME = SLC, ROUTER_NAME = Liffe Fut, IGNORE
SERVER_ID = 18999.7801, SERVER_NAME = SLE, ROUTER_NAME = LiffeF
SERVER_ID = 18999.7804, SERVER_NAME = Selector, ROUTER_NAME = LiffeF
[END]
[API_NAMES]
API_ID=RISK_, Risk Management App
API_ID=PARSE_, Parser App
[END]
[USERS]
ROUTER_ID=17000, Internal 1
ROUTER_ID=17003, Internal 2
USER_ID=232, Simone Jones
USER_ID=231, Charles Stout
[END]
[USERS]
ROUTER_ID=13000, Internal 3
USER_ID = 130, Nina Simmons
USER_ID= 140, William Gower
[END]
SERVERS section defines router/server pairs.
If a particular router/server pair does not need to be monitored, then ‘IGNORE’ should be added to the line.
API_NAMES should be used where GL API applications do not use a fixed name.
For example, where the name is PARSE_345 when the application connects for the first time, and then PARSE_366 the next time they connect and so on. In this case PARSE_ should be defined in this section.
Otherwise every time the application connects/disconnects it will be treated as a new user, possibly generating a lot of dummy users in the GL-ROUTER-USERS window.
USERS is a section that defines user / router communities.
from must also be defined in this section in addition to the USER_IDs. More than one router can be defined.Note
The ROUTER_ID that the users connect
In most cases it is only necessary to define one [Names] section with all known routers and users. However where there is more than one user with the same ID connecting from different routers (for example on a broker site) they must be separated into different router communities.