Jump to: navigation, search

debug-level

Section: statserver
Default Value: Init
Valid Values: all, Action, Client, Init, HA, Java, Mngmnt, Reset, Server, SPT, SQL, Status
Changes Take Effect: Immediately upon notification


A comma-separated list of debug categories that are visible in the Stat Server log:

  • all Synonymous with Init,Server,Client,Status,Action,SQL,Mngmnt,Java,Reset. The debug level that you designate for this category supersedes any debug level that you designate for other categories.
  • Action Logs changes to the internal Stat Server object model and provides a significant source of troubleshooting data, which includes entries following every TEvent.
  • Client Logs all Stat Server communication with its clients, such as the opening of statistics and all statistical values sent to the client. This value generates a large amount of data, and should be sparingly used for troubleshooting reproducible problems with statistics.
  • Init Used for capturing data related to Configuration Server that affects Stat Server, including dynamic Configuration Server changes made as Stat Server starts--such as the addition, deletion, and/or change of objects or their properties having an affect on Stat Server. This value is useful for tracking initial configuration and dynamic changes and is much more compact than the information provided in the Configuration Server log. Genesys recommends that you always include this value in this option.
  • HA Logs messages related to HA functionality.
  • Java Displays information related to Java extension functionality. Use this value only for statistics in the Outbound Contact 7.2.0+ or MCR 7.0.1+ (MCR has been renamed to eServices in release 8.0).
  • Mngmnt Displays profiling information, including the number of currently connected clients, statistics being computed at the moment, and statistics to be reported to clients.
  • Reset Enables the log messages Stat Server sends to clients while sending statistics requested with a reset-based notification mode.
  • Server Logs T-Server events pertaining to Stat Server. Genesys recommends that you not include this value if you maintain logs for the related T-Server(s).
  • SPT Logs events related to Stat Server startup. This value is provided to maintain backward compatibility and may be eliminated in future releases.
  • SQL Displays the SQL statements issued if you have configured a database for Stat Server.
  • Status Logs events related to the current state of objects and is useful for troubleshooting Stat Server-Router problems.

This option is enabled only if you have set the verbose common log option to all.

In graphical environments, log output often takes more than half of a server's execution time. To maintain performance, use only the debug levels that you need and run Stat Server in the background. Also, minimize the Stat Server window or redirect log output to a different device, such as a file. Be very careful, however, when directing log output to a file and consider the available free disk space, directory and file permissions, and possible conflicts with different software trying to use the log file at the same time.

For each debug category, you can also set the level of debug logging by specifying a numerical value from [0–9] (with 9 being the most verbose) and appending the number to each category.

For example: Init, Status:6

Debug level 0 is synonymous to no logging at all for the specified debug category.

Debug levels 1–4 provide less logging information than was provided in prior releases but more than debug level 0.

Debug level 5 provides exactly the same logging information that was provided in prior releases. This level is the default level if none is otherwise specified.

Debug levels 6–7 provide more detailed output than level 5.

Debug levels 8–9 provide the most extensive log output requiring further internal processing which, in turn, further degrades Stat Server performance.

The SIP Server 8.1.1 product provides a troubleshooting tool that parses the log output of several Genesys servers including Stat Server. Refer to the SipSpan2 User's Guide, available on the SIP Server CD, for information on how to use this tool.

This option was previously named DebugLevel.

session-expiration-timeout

Section: ha
Default Value: 120
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

Specifies, in seconds, how often the session expiration is checked during the time configured in the session-expiration-period option.

session-expiration-period

Section: ha
Default Value: 1800
Valid Values: 0 - 86400
Changes Take Effect: Immediately
Introduced: 8.5.109

Sets the session expiration period, in seconds. When the primary and backup Stat Servers, operating in high availability (HA) mode, cannot reconnect in time specified by the value of this option, the new session with the full statistics replication is initialized. When this option is set to 0 (zero), the lost session expires immediately.

connect-timeout

Section: ha
Default Value: 2
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

Timeout, in seconds, when the reconnect attempt between Stat Servers, operating in high availability (HA) mode, is made.

chunk-timeout

Section: ha
Default Value: 1
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

Duration, in seconds, between adjacent chunks during replication of statistics between primary and backup Stat Server instances. Term "chunk" means the number of statistics, processed simultaneously.

chunk-size

Section: ha
Default Value: 5000
Valid Values: 1 - 100000
Changes Take Effect: Immediately
Introduced: 8.5.109

Sets the number of statistics, processed simultaneously during replication of statistics between primary and backup Stat Server instances.

addp-trace

Section: ha
Default Value: both
Valid Values: local, remote, both, off
Changes Take Effect: Immediately
Introduced: 8.5.109

If addp is specified for the HA connection, the addp-trace option determines whether ADDP messages are written to the primary and backup Stat Server logs:

  • local ADDP trace occurs on the side of the Stat Server in backup mode.
  • remote ADDP trace occurs on the side of the Stat Server in primary mode.
  • both ADDP trace occurs at both the primary and backup Stat Servers.
  • off Turns ADDP off.

addp-timeout

Section: ha
Default Value: 10
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

If addp is specified for the HA connection, the addp-timeout option specifies the time interval, in seconds, that Stat Server in backup mode waits before polling the other Stat Server in the redundant pair.

addp-remote-timeout

Section: ha
Default Value: 10
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

If addp is specified for the HA connection, the addp-remote-timeout option specifies the time interval, in seconds, that Stat Server in backup mode instructs the other Stat Server in the redundant pair to use when polling to check the connection between the two servers.

connect-timeout

Section: ha
Default Value: 2
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

Timeout, in seconds, when the reconnect attempt between Stat Servers, operating in high availability (HA) mode, is made.

chunk-timeout

Section: ha
Default Value: 1
Valid Values: 1 - 3600
Changes Take Effect: Immediately
Introduced: 8.5.109

Duration, in seconds, between adjacent chunks during replication of statistics between primary and backup Stat Server instances. Term "chunk" means the number of statistics, processed simultaneously.

chunk-size

Section: ha
Default Value: 5000
Valid Values: 1 - 100000
Changes Take Effect: Immediately
Introduced: 8.5.109

Sets the number of statistics, processed simultaneously during replication of statistics between primary and backup Stat Server instances.

Hot Standby (HA)

Genesys uses the term hot standby to describe the redundancy type in which a backup server application remains initialized, clients connect to both the primary and the backup servers at startup, and the backup server data is synchronized with the primary server. Data synchronization and existing client connections to the backup guarantee higher availability of a component.

Starting with release 8.5.109, Stat Server supports Hot Standby redundancy for Stat Servers operating in high availability (HA) mode on Windows and Linux platforms.

Introduction

In HA mode, primary and backup instances of Stat Server replicate historical statistics and their aggregates to each other. Therefore, there is no single point of failure, as if one Stat Server instance fails and is then restarted, it can restore the statistics and their aggregates from another Stat Server instance.

The communication between primary and backup Stat Server instances is performed within a session. In case of a disconnect with the subsequent reconnect, the backup instance tries to restore the previous session. If it succeeds then not the whole population of the statistics but just those that were opened during the disconnect, are replicated. If a session cannot be restored, the whole population of statistics is replicated.

Overview

At startup, both Stat Server instances "read" their configuration and establish connections to each other. When the backup Stat Server instance connects to the primary, both ensure that they are configured as HA pair. Both Stat Server instances run concurrently.

After the successful initialization, two Stat Server instances start synchronization of non-replicated stats. When a new statistic is successfully opened, it is added to a non-replicated collection. Each Stat Server instance pushes statistics to another instance along with their aggregates. This is done in chunks (see the chunk-size option) by the timer (see the chunk-timeout option). If for a receiving Stat Server a statistic is new, this statistic is opened. If a statistic is not new for a receiving Stat Server, then only aggregate synchronization is performed. Aggregates need to be synchronized, except for JavaCategory, where only statistic definitions are synchronized – that requires identically absolute or relative paths to the same extension on two Stat Server instances.

If some mandatory statistical attribute (such as object, filter, time profile, or time range) is deleted in the configuration, the associated Stat Server instance deletes this statistic but still waits for the acknowledgement from another instance.

If a connection between primary and backup Stat Servers is lost, the backup instance tries to reconnect (using frequency, configured as the value of the connect-timeout option) and restore a session. If the session is restored, only new statistics (statistics opened during the disconnect) are replicated. Otherwise, all statistics are replicated.

Configuration

  1. In Genesys Administrator, under Provisioning > Environment > Applications, select your primary Stat Server application.
  2. In the Server Info section, in the Backup Server field, specify the backup Stat Server application.
  3. In the Redundancy Type list, select Hot Standby.
    Configure HA port for Stat Server instances
    (Click thumbnail to enlarge.)
  4. For Listening Ports, click Add. The Port Info dialog appears.
    In the Port Info dialog, configure the port for communication between the Primary and Backup Stat Server instances. The Stat Server instance configured as a backup always tries to connect to the HA Port that is set on the Stat Server instance configured as primary. You must:
    1. In the ID field, enter ha.
    2. Choose what connection protocol the Stat Server HA pair use; the following protocols are supported: default, addp, or tls.
      • For default connection protocol between the Primary and Backup Stat Servers:
        1. In the Listening Mode list, choose Unsecured,
        2. In the Connection Protocol field, enter default.
      • For ADDP connection protocol between the Primary and Backup Stat Servers:
        1. In the Listening Mode list, choose Unsecured,
        2. In the Connection Protocol field, enter addp,
        3. Configure the ADDP-specific options described in step 5.
      • For TLS connection protocol between the Primary and Backup Stat Servers:
        1. Ensure that trusted CA certificates are installed on the hosts where the HA Stat Servers are running. For more information about TLS connections and CA certificate generation, see the Secure Connections (TLS) section of the Genesys Security Deployment Guide.
        2. In the Listening Mode list, choose Secured,
        3. In the Connection Protocol field, enter default.
      • If the Connection Protocol for ha Listening Port is not specified, an ADDP connection protocol is established for HA Stat Servers.
    Changes in ha port configuration take effect after Stat Server restart.
  5. On the Options tab, configure relevant Hot Standby configuration options in the [ha] section, which contains the following options:
Important
New resources, for example: stat types, time profiles, time ranges, filters, can be dynamically added to Stat Server options. However, statistics, using those resources, should only be opened after making identical changes to both Stat Server instances of the HA pair. Otherwise, such statistics may not replicate properly.

Consistency

After all activity in the system is stopped, if both Stat Server instances are configured identically and connected, then they have exactly the same open historical statistics (see exceptions below), and the values for most of those statistics are closed in the HA pair.

Due to the way of how the aggregate synchronization procedure works the double-counting of statistics is possible, but it has a low probability, and even if it happens, its relative contribution is very small.

Special cases of a double-counting are possible during synchronization of GroupBy statistics, such as when one Stat Server instance is started later than the other one, so it did not see the user-data on a call, and created different child for the same call, and after sync, the same call counted twice for different user data keys.

Current statistics are not synchronized and can be different in two instances for the following reasons:

  • One Stat Server instance "saw" a real action start, while another instance did not.
  • One Stat Server instance did not "see" user data for the call, since it is not provided in the EventRegistered, while another instance "saw" it, as it connected to T-Server prior to when the call was started.

Historical custom formulas, having current component (for example: SUM(CallInternal,duration)+@SUM(CallInternal;duration )), can be out-of-sync for the same reasons, as for the current statistics above.

Only the historical component of the aggregate is replicated for the following statistics:
Category=Formula
Subject=<Status>
Expression=<combination of current and historical component>
As a result, such statistics might have different values in different instances of the same HA pair.

The primary and backup Stat Server instances might have an inconsistent statistic with the Subject=DNAction when an Action ends, if prior to that during the synchronization of Stat Server instances (while the Action was incomplete) one of the following conditions occurred:

  • The last reset point of the TimeProfile was different in the primary and backup Stat Server instances.
  • The start of the Filter validation was different in the primary and backup Stat Server instances.

Diagnostic

Starting with release 8.5.109, Stat Server logging is enhanced with the new HA value for the [statserver]/debug-level option. If the HA value is set, Stat Server logs messages related to HA functionality.

This page was last edited on January 21, 2022, at 18:16.
Comments or questions about this documentation? Contact us for support!