Foglight Experience Monitor 5.8.1 - Installation and Administration Guide

Editing server details

You can change the display name and command processing time.

For every server listed on the Servers page, there exists a server IP address (under the Servers column), and a server name (under the Display Name column). The display name is used anywhere the server is mentioned in the web console.

Figure 47. Server display name

By default, the server IP address is assigned as the server.

To change the display name:

From the settings column, click the server’s corresponding Edit link.

This displays the Servers > Edit page for that server.

In the Display Name box, type the name you want the server to display in the web console.

In the Command Processing Time Service Level Threshold box, type the desired service level for command processing times on this server. For more information, see Changing monitored servers service levels.

You can also have the appliance retrieve the server domain name by clicking Lookup DNS name.

The DNS name is presented in a window, which you can accept by clicking Use DNS name.

A DNS lookup may or may not yield a server name, depending on how the server is configured.

To use the lookup feature, the appliance needs to be aware of the DNS servers on your network. See Network settings for more information.

To accept the name, and return to the Servers page, click OK.

Changing monitored servers service levels

Every server listed on the Servers page has a Command Processing Time metric value associated with it. You can alter the threshold that determines the value of this metric following the steps defined below. For more information about this metric, see “Command Processing Time” in the Foglight Experience Monitor Metric Reference Guide.

To set service level thresholds:

Click the corresponding Edit link in the Settings column for the server for which you want to set the service level threshold.

This displays the Servers > Edit page for that server.

In the Command Processing Time Service Level Threshold box, type the desired service level for command processing times on this server.

For example, if you decide that the time to process commands should not exceed one second, enter 1000 (units are in milliseconds). The Command Processing Time Service Level metric shows you the percentage of commands whose processing time was under one second.

To commit the change for this server and return to the main Servers page, click OK.

Repeat this procedure for every server whose default threshold requires modification.

Configuring server options

The Server Options page provides the ability to configure a server identification tag and also to specify how the appliance filters the traffic that it is receiving.

To configure server options:

On the Servers page, click Server Options.

In the Server IP Identification Tag box, type the name of HTTP header tag that the appliance will use to identify servers.

In the Traffic Filtering list, select a filtering type.

Choose one of following options to control how the appliance filters incoming traffic.

Table 11. Filtering types
Option	Definition
Use PCAP¹ Filter	Recommended. This option uses the PCAP filter for both TCP ports and IP addresses. It causes the system to apply the list of configured server IPs in a PCAP filter that it uses for each monitoring port. This option is the most efficient mode of operation and it ensures that unwanted traffic does not appear in the metrics. This is the recommended setting because it incurs the lowest overhead on the system. If you select this option, a limit of 300 configured server IPs is enforced. NOTE: If this option is not in the list, you have already configured 300 servers to use the PCAP filter. 300 servers is the maximum number supported by PCAP. You need to select one of the other filter options.
Use internal filter	This option does not use a PCAP filter. The agent filters both the TCP ports and the IP addresses internally. It causes the system to apply the list of configured server IPs within the analysis layer of the FxM agent. This option is less efficient than the Use PCAP filter option, but may be needed at sites where more than 300 server IPs need to be monitored.
Use minimal filtering	This option uses the PCAP filter for TCP ports; IP addresses are not filtered. This causes the system to accept any and all server IPs that appear in the monitored traffic. This option is not as efficient as the first two options, but may be needed at sites where the list of servers that need to be monitored is dynamic and, therefore, cannot be configured in advance. NOTE: In Foglight Experience Monitor versions 5.6.2 (or earlier), this option was known as No filtering. When upgrading your system to version 5.6.3 (or later), the old No filtering option automatically becomes Use minimal filtering. The new No filtering option is now defined as specified below.
No filtering	This option dictates that the traffic is not filtered either via PCAP or by the agent internally. Network traffic for any and all TCP ports and IP addresses is captured and analyzed by the system. This option is the least efficient of the four options, but is required at sites where the IEEE 802.1ad specification (also referred to as 802.1QinQ) is employed. The disadvantage to this option is that unwanted traffic may be monitored by the system and can appear in the metrics. This option also causes the greatest amount of overhead on the system.

PCAP (Packet CAPture) consists of an application programming interface (API) for capturing network traffic. UNIX®-like systems implement PCAP in the libpcap library; Windows® uses a port of libpcap known as WinPcap.

In the Maximum Frame Size box type the value for the largest jumbo frame size expected to be present in the monitored traffic. This setting must be at least 9,038 bytes but no more than 64,000 bytes. If the setting is too low, some traffic may be missed. Use caution when increasing the size, as this has an impact on system memory consumption. Generally, Quest Technical Support can advise you when this setting needs to be increased.

To enable the hardware timestamping functionality, select the Hardware Timestamping check box. For details about this feature, see Foglight Experience Monitor and Ixia Net Tool Optimizers.

Configuring a server identification tag

The Server Options page provides the ability to configure a server identification tag and also to specify how the appliance filters the traffic that it is receiving.

If your site uses a load balancer, the server IP addresses may not be available in the network traffic that the appliance is monitoring.

Consider the following conditions:

•

your web servers are situated behind a load balancer

•

the load balancer is configured to mask server IPs

•

you want the appliance to collect data from any or all of the individual servers concealed behind the load balancer

•

the appliance will be deployed anywhere in front of the load balancer

A load balancer that uses a virtual IP is typically configured to strip out server IP information in the IP layer of any communication it receives from its server farm. In this context, the physical server IPs remain hidden, and the appliance is unable to distinguish between unique servers. This means the appliance will not be able to break out metrics for each individual server.

This issue can be resolved by configuring each web server to insert an HTTP header tag that contains the server’s unique IP address (for example, header name: SERVER-ID, header value: “192.168.1.89”).

If you configure the appliance to recognize the tag as the Server IP Identification Tag (in this case, SERVER-ID), it can identify unique servers behind the load balancer. Actual server IP addresses can then be viewed in the web console (in this case, 192.168.1.89) instead of the load balancer’s virtual IP. These real server IPs appear when you auto-discover servers. For more information, see Automatically discovering servers.


	NOTE: See your web server documentation to find out how to have an HTTP header tag, containing the real server IPs, inserted into outgoing traffic.

Configuring a server identification tag in Microsoft

This example shows you how to configure an HTTP header that will contain each server's physical IP address in Microsoft® Internet Information Services (IIS). This header will allow Foglight Experience Monitor to track metrics by server as described above.

To configure a HTTP header in IIS:

On the web server, navigate to Start > Programs > Administrative Tools > Internet Information Server (IIS) Manager.

In the left pane, expand the Web Server node and then expand the Web Sites node.

Select a Web Site from the list.

Right-click the Web Site and from the menu select Properties.

Select the HTTP Headers tab.

Click Add.

The Add/Edit Custom HTTP Header dialog box displays.

Type a unique value for the Custom header name.

For example, SERVER-IP.

Type a unique value for the Custom header value.

For example, 192.168.1.1 (a standard formatted IP address).

Click OK.


	IMPORTANT: Foglight Experience Monitor expects a valid IP address in this field. This IP address may be a fictitious address so as to protect the identity of your physical servers. This is recommended if the application you are monitoring is publicly available on the Internet.

Configure each Web Server using steps 3-9.


	IMPORTANT: The address of the load balancer and the IP address that you configured in the Custom header value must appear in the list of configured servers on the Configure > Monitoring > Servers page in order for the appliance to collect metrics for the server.

By default, when the appliance is set up for the first time using the Setup Wizard, it monitors HTTP traffic for each server listed on the Servers page. If any of your servers utilize secure HTTP (HTTPS), the appliance must be provided with each server’s private keys in order to decrypt the secure network traffic they process.

These keys are typically stored in encrypted format with an associated password. In order for the appliance to decode and analyze your HTTPS traffic, you need to provide both the key file and the associated password.

The key file and password can be uploaded to the appliance and stored locally in files that are hidden and encrypted. The secure key file needs to be in the PEM (Privacy Enhanced Mail), DER (Distinguished Encoding Rules) or PKCS12 format. For more information about SSL certificates and keys, see Exporting a Certificate to the Appliance:.

These files typically resemble the following sample:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,F85757828BFF54C8

QlHfWyCnqpe5ag4LgNiRQaqrcTC5bBV3yT35tRbB0WKB3VsaDcHuhjlyz3ohQmgpHoZtWcCxCRm8DOROlBPEBhmRgUSYxByyt/Y8OvL9Ei2YFdRjBapsJjEjpTEl6AXNGHKjHbmyCHs5O1LvnwEv13b51Q0RHRpRZX1yNVL34cz/efMCfVlhgqlYCHFb0qRzLcNFVW6vRXWfKkM5jbw67WmKjqeDa+VMMXskPRDxFVYud/HoB+gnMP0ecnSX7k4xZrLkIwk4QcVaJST2BPiDq0DhBdUfXRurJd9AQuAECAw6SgumqIRY/CrH31w5dxqXzs2UY0lqODpU3tVqZW8+OxX34ojsBPeH0zmeOxnmQ8IebRyex8MTHhEVnpIU4DDNdKlbE0/seoyNGJRXFh2lDcrXlkTMgrOVg1VL216vGIgbpfyZgOBDiexkEj24tW4dO0iRhyqiOZVZVlR2kcm9L64NruhwgzLAGPDlaGfLkExATQvp1NNETxoR0iMe4vBgA1xLZDZ/atH4U/oE63Hedj4B9C3MG8Wapnx5lJaA7DVKSkPwKZRP5Qxcbun3R084j+Q7KwmkiOk0yT8RlQapLm7SaYahOklJPy0eHpfo4sZPELhkU39V4smBa1LlAKCbxTzFYq22CLCKBtEkCKrc9yfOQ8KpQ9SsD2/VCJRfLGhMRrVzSheOXeGDA/oKq/ZZLO27r68odZaXQw1e9dR7oKStqNOG8M3WAsY3LEH++DAubqXDJ6g00aHC2eiVr9ZFfRUpKWRqybHns+ukAcg436UJoK2RMyhWyBHV8P2cDqF1ow9QQzO8Qg==
-----END RSA PRIVATE KEY-----

Configuring SSL keys

Foglight Experience Monitor supports the following Secure Sockets Layer (SSL) and Transport Layer Security (TLS) cryptographic protocols:

•

•

•

•

•


	NOTE: Due to the fact that TLSv1.3 only supports key exchanges based on ephemeral keys (unique keys generated for each TLS session), external devices (including Foglight Experience Monitor) are unable to decrypt website traffic using this protocol.

When a server and the appliance communicate over SSL/TLS, a session first needs to be established (often referred to as SSL handshake). After a session has been opened, secure data can then be exchanged. This two-step process makes use of two different encryption algorithm types: key exchange algorithms, and bulk encryption algorithms.

There are various implementations of each algorithm type, and the server’s private key you are using must be supported by the appliance.

Table 12. Key exchange algorithms
Key Exchange Algorithms	Support
RSA	yes
Diffie-Hellman (DH)	no
Kerberos5	no
Fortezza	no

The following bulk encryption algorithms are supported:

•

•

•

•

•

•

•

•

To configure SSL Keys:

In the Secure HTTP column, click the Configure link that corresponds with the server whose private keys are to be uploaded to the appliance.

The Servers > Configure Secure HTTP page for that server is displayed, listing any secure ports currently configured for the server.

Click Add SSL Key to display a window in which you can locate the file containing the private key.

Click Browse to open a dialog and locate the key.

Once you have confirmed its location, and the file path is listed in the Secure Key box enter the private key password in the Password box.

Select the port from the list of HTTPS ports in the Port box.

These ports must have been previously configured on the Protocols page.

Click OK to upload the key, thereby enabling HTTPS monitoring for the specified port on this server.

Each time you click OK, the private keys are uploaded to the appliance. Ensure you have provided private keys for all secure ports for each server that uses HTTPS.


	IMPORTANT: The appliance encrypts the private key files and passwords that are uploaded to it and saves them in hidden files. This, along with the extensive hardening and security measures taken on the appliance itself, guarantees that your secure keys and passwords cannot be compromised. When exporting the private key from your web server, make sure to select Yes, Export the private key. Depending on the web server, the private key is not always included in an export by default.When uploading an SSL key for a server, if you encounter the message The key file you supplied is invalid. Possible reasons are: 1) incorrect password, 2) the file does not contain a private key, 3) the file was exported with strong encryption, or 4) the file is in an unrecognized format—it indicates the key is considered invalid.


	IMPORTANT: Due to the nature of SSL, it is impossible to determine precisely why your key may be invalid, but there are two things you can do to diagnose this problem:1. Ensure your key is contained in a file that follows one of the PKCS, PEM, or DER formats.2. When exporting the private key from your web server, make sure to select Include private key. Depending on the web server, the private key is not always included in an export by default. For more information, see Exporting SSL keys from IIS.