Protocol Metrics Reference

This reference provides descriptions for all metrics that appear on built-in ExtraHop protocol pages. You can access a protocol page in the ExtraHop system by logging into the Web UI, clicking Metrics, and then clicking the name of a source or group; all protocol pages for the source or group are listed in the left column.

AAA

ExtraHop appliances collect metrics about Authentication, Authorization, and Accounting (AAA) activity.

AAA application page

AAA Summary

Transactions
This chart shows you when AAA errors and responses were associated with the application. This information can help you see how active the application was at the time the errors occurred.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of AAA responses.
Errors The number of AAA response errors.
Total Transactions
This chart displays the total number of AAA responses that were associated with the application and how many of those responses contained errors.
Metric Description
Responses The number of AAA responses.
Errors The number of AAA response errors.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long clients took to transmit requests onto the network; the server processing time shows how long the servers took to process requests; and the response transfer time shows how long the servers took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:



It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
Request Transfer Time The time between the ExtraHop system detecting the first packet and last packet of AAA requests. A high value may indicate a large request or network delay.
Server Processing Time The time between the ExtraHop system detecting the last packet of AAA requests and the first packet of their corresponding responses.
Response Transfer Time The time between the ExtraHop system detecting the first packet and last packet of AAA responses. A high value may indicate a large response or network delay.
Round Trip Time The time between when an AAA client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If an application is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. These metrics show the 95th percentile of time that servers took to process requests from clients versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that clients are contacting slow servers. High TCP round trip times indicate that clients are communicating over slow networks.
Metric Description
Server Processing Time The time between the ExtraHop system detecting the last packet of AAA requests and the first packet of their corresponding responses.
Round Trip Time The time between when an AAA client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.

AAA Details

Top Methods
This chart shows which AAA methods were associated with the application by breaking out the total number of AAA requests by method.
Top Error Types
This chart shows which AAA error types were associated with the application the most by breaking out the number of responses by error type.

AAA Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
AAA Server Processing Time The time between the ExtraHop system detecting the last packet of AAA requests and the first packet of their corresponding responses.
Server Processing Time
This chart shows the median processing time for the application.
Metric Description
AAA Server Processing Time The time between the ExtraHop system detecting the last packet of AAA requests and the first packet of their corresponding responses.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when an AAA client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.
Round Trip Time
This chart shows the median round trip time for the application.
Metric Description
Round Trip Time The time between when an AAA client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either a server or a client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were associated with an application. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Request Zero Windows The number of zero window advertisements sent by AAA clients. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of Zero Windows In indicates that a peer device was too slow to process the amount of data received.

Response Zero Windows The number of zero window advertisements sent by servers while receiving AAA requests. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of Zero Windows Out indicates that a client was too slow to process the amount of data received.

Total Host Stalls
This chart shows the median number of zero window advertisements sent by devices.
Network Stalls
This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.
Metric Definition
RTOs In The number of retransmission timeouts caused by congestion when clients were sending AAA requests.An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs In, a device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts caused by congestion when servers were sending AAA responses. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs Out, a device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

Total Network Stalls
This chart shows the median number of retransmission timeouts caused by congestion when clients and servers were sending requests.
Metric Definition
RTOs In The number of retransmission timeouts caused by congestion when clients were sending AAA requests.An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs In, a device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts caused by congestion when servers were sending AAA responses. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs Out, a device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

AAA Metric Totals

Total Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than servers can handle or the network might be too slow. To identify whether the issue is with the network or a server, check RTOs and zero windows in the Network Data section.

Note:It is unlikely that the total number of AAA requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of AAA requests.
Responses The number of AAA responses.
Errors The number of AAA response errors.
Diameter Request The number of Diameter requests.
RADIUS Request The number of RADIUS requests.
Aborts The number of aborted AAA sessions.
AAA Network Metrics
Metric Description
Request Zero Windows The number of zero window advertisements sent by AAA clients. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.
Response Zero Windows The number of zero window advertisements sent by servers while receiving AAA requests. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.
RTOs In The number of retransmission timeouts caused by congestion when clients were sending AAA requests.An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.
RTOs Out The number of retransmission timeouts caused by congestion when servers were sending AAA responses. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.
Request L2 Bytes The number of L2 bytes associated with AAA requests.
Response L2 Bytes The number of L2 bytes associated with AAA responses.
Request Goodput Bytes The number of goodput bytes associated with AAA requests. Goodput refers to the throughput of the original data transferred and excludes other throughput such as protocol headers or retransmitted packets.
Response Goodput Bytes The number of goodput bytes associated with AAA responses. Goodput refers to the throughput of the original data transferred and excludes other throughput such as protocol headers or retransmitted packets.
Request Packets The number of packets associated with AAA requests.
Response Packets The number of packets associated with AAA responses.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AAA client page

AAA Summary

Transactions
This chart shows you when AAA errors occurred and how many responses the AAA client received. This information can help you see how active the client was at the time it received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.
Total Transactions
This chart displays the total number of AAA responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The server processing time shows how long servers took to process requests from clients. Processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at the processing time, because this metric alone provides an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT and processing times are both high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

RTT only measures how long an immediate acknowledgement takes to be sent; it does not wait until all packets are delivered. Therefore, RTT is a good indicator of how your network is performing. If you see high processing times, but the TCP RTT is low, the issue is probably at the device-level. Check the network for latency issues if the TCP RTT and processing times are all both.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.



The processing time might be high because the server took a long time to transmit the response (possibly because the response was very large); however, the processing time could also be high because the response took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
Server Processing Time When the device is acting as an AAA client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Time The time between when an AAA client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance Summary (95th Percentile)
If a client is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. These metrics show the 95th percentile amount of time that servers took to process requests from the client versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the client is contacting slow servers. High TCP round trip times indicate that the client is communicating over slow networks.
Metric Description
Server Processing Time When the device is acting as an AAA client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Time The time between when an AAA client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

AAA Details

Top Methods
This chart shows which AAA methods the client called the most by breaking out the total number of requests the client sent by method.
Top Error Types
This chart shows which AAA error types the client received the most by breaking out the number of responses returned to the client by error type.

AAA Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
AAA Client Server Processing Time When the device is acting as an AAA client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Server Processing Time
This chart shows the median processing time for the client.
Metric Description
AAA Client Server Processing Time When the device is acting as an AAA client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when an AAA client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the client.
Metric Description
Round Trip Time The time between when an AAA client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

AAA Metric Totals

Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the client might be sending more requests than the servers can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.

Note:It is unlikely that the total number of AAA requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of total requests that the device sent when acting as an AAA client.
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.
Diameter Request The number of Diameter requests that the device sent when acting as an AAA client.
RADIUS Request The number of RADIUS requests that the device sent when acting as an AAA client.
Aborts The number of aborted sessions that occurred when the device is acting as an AAA client.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AAA server page

AAA Summary

Transactions
This chart shows you when AAA errors occurred and how many AAA responses the server sent. This information can help you see how active the server was at the time it returned the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.
Total Transactions

This chart displays the total number of AAA responses the server sent and how many of those responses contained errors.

Metric Description
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The server processing time shows how long servers took to process requests from clients. Processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at the processing time, because this metric alone provides an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT and processing times are both high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

RTT only measures how long an immediate acknowledgement takes to be sent; it does not wait until all packets are delivered. Therefore, RTT is a good indicator of how your network is performing. If you see high processing times, but the TCP RTT is low, the issue is probably at the device-level. Check the network for latency issues if the TCP RTT and processing times are all both.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.



The processing time might be high because the server took a long time to transmit the response (possibly because the response was very large); however, the processing time could also be high because the response took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
AAA Server Server Processing Time When the device is acting as an AAA server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance Summary (95th Percentile)
If a server is acting slow, performance summary metrics can help you figure out whether the network or the server is causing the issue. The performance summary metrics show the 95th percentile amount of time the server took to process requests from clients versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the server is slow. High RTTs indicate that the server is communicating over slow networks.
Metric Description
AAA Client Server Processing Time When the device is acting as an AAA server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

AAA Details

Top Methods
This chart shows which AAA methods were called on the server the most by breaking out the total number of requests the server received by method.
Top Error Types
This chart shows which AAA error types the server returned the most by breaking out the total number of responses the server sent by error type.

AAA Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
AAA Server Server Processing Time When the device is acting as an AAA server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Server Processing Time
This chart shows the median processing time for the server.
Metric Description
AAA Server Server Processing Time When the device is acting as an AAA server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the server.
Metric Description
Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

AAA Metric Totals

Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the server can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.

Note:It is unlikely that the total number of AAA requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of total requests that the device received when acting as an AAA server.
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.
Diameter Request The number of Diameter requests that the device received when acting as an AAA server.
RADIUS Request The number of RADIUS requests that the device received when acting as an AAA server.
Aborts The number of aborted sessions that occurred when the device is acting as an AAA server.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AAA client group page

AAA Summary for Group

Transactions
This chart shows you when AAA errors occurred and how many responses the AAA clients received. This information can help you see how active the clients were at the time they received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.
Total Transactions
This chart shows you how many AAA responses the clients received and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.

AAA Details for Group

Top Group Members (AAA Clients)
This chart shows which AAA clients in the group were most active by breaking out the total number of AAA requests the group sent by client.
Top Methods
This chart shows which AAA methods the group called the most by breaking out the total number of requests the group sent by method.
Top Error Types
This chart shows which AAA error types the group received the most by breaking out the number of responses returned to the group by error type.

AAA Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the clients might be sending more requests than servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Requests The number of total requests that the device sent when acting as an AAA client.
Responses The number of responses that the device received when acting as an AAA client.
Errors The number of response errors that the device received when acting as an AAA client.
Diameter Request The number of Diameter requests that the device sent when acting as an AAA client.
RADIUS Request The number of RADIUS requests that the device sent when acting as an AAA client.
Aborts The number of aborted sessions that occurred when the device is acting as an AAA client.
Server Processing Time
If a client group is acting slow, the server processing time can help you figure out whether the issue is with the servers. The Server Processing Time chart shows the median amount of time servers took to process requests from the clients. High server processing times indicate that the clients are contacting slow servers.
Metric Description
Server Processing Time When the device is acting as an AAA client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AAA server group page

AAA Summary for Group

Transactions
This chart shows you when AAA errors occurred and how many AAA responses the servers sent. This information can help you see how active the servers were at the time they returned the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.
Total Transactions
This chart shows you how many AAA responses servers in the group sent and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.

AAA Details for Group

Top Group Members (AAA Servers)
This chart shows which AAA servers in the group were most active by breaking out the total number of AAA responses the group sent by server.
Top Methods
This chart shows which AAA methods were called on servers in the group the most by breaking out the total number of requests the group received by method.
Top Error Types
This chart shows which AAA error types the groups returned the most by breaking out the total number of responses the group sent by error type.

AAA Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of total requests that the device received when acting as an AAA server.
Responses The number of responses that the device sent when acting as an AAA server.
Errors The number of response errors that the device sent when acting as an AAA server.
Diameter Request The number of Diameter requests that the device received when acting as an AAA server.
RADIUS Request The number of RADIUS requests that the device received when acting as an AAA server.
Aborts The number of aborted sessions that occurred when the device is acting as an AAA server.
Server Processing Time
The Server Processing Time chart shows the median amount of time the servers took to process requests from clients. High server processing times indicate that the servers in a group are slow.
Metric Description
AAA Client Server Processing Time When the device is acting as an AAA server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AAA applications page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Application toolbar
The AAA application toolbar includes the following controls:
Errors
The chart displays the number of AAA errors. Mouse over the points to view a summary of a specific time or date. The table lists the AAA error messages and number of occurrences.
Clients
The chart displays the processing time for all clients. Mouse over the points to view a five-number summary of processing time (minimum, lower quartile, median, upper quartile, and maximum values). The orange bars represent a confidence interval around the median value bounded by the 25th and 75th percentile values.

The table lists client IP addresses, the host and device associated with each client as well as total time and processing time for each client. Mouse over the orange bars to view the mean time, standard deviation, and count for each metric.

Servers
The chart displays the processing time for all servers. Mouse over the points to view a five-number summary of processing time (minimum, lower quartile, median, upper quartile, and maximum values). The orange bars represent a confidence interval around the median value bounded by the 25th and 75th percentile values.
Application Details
Specifies the type of additional application information displayed. IP detail views display directly monitored IP addresses and IP addresses that appear through routed traffic. IP addresses that appear through routed traffic are preceded by the word via. Mousing over the counter next to each top-level metric opens a context menu with the following options in the drop-down list:
By Client IP
Displays application metrics by the client IP addresses.
By Server IP
Displays application metrics by the server IP addresses.

For example, Request Bytes is a top-level metric showing how many request bytes were transmitted in and out of the application within the selected time interval. Select By Client IP in the drop-down list while mousing over the Request Bytes counter to view which client IP addresses originated these requests.

L2-L4 Metrics
Contains the following metrics:
Request L2 Bytes
The number of L2 bytes associated with AAA requests.
Response L2 Bytes
The number of L2 bytes associated with AAA responses.
Request Packets
The number of packets associated with AAA requests.
Response Packets
The number of packets associated with AAA responses.
Request RTOs
The number of retransmission timeouts caused by congestion when clients were sending AAA requests. A retransmission timeout is a one-second stall in the TCP connection flow due to excessive retransmissions.
Response RTOs
The number of retransmission timeouts caused by congestion when servers were sending AAA responses. A retransmission timeout is a one-second stall in the TCP connection flow due to excessive retransmissions.
Request Zero Window
The number of zero window advertisements sent by AAA clients. A device advertises a zero window when it cannot process incoming data as quickly as it is arriving.
Response Zero Window
The number of zero window advertisements sent by servers while receiving AAA requests. A device advertises a zero window when it cannot process incoming data as quickly as it is arriving.
AAA Metrics
Contains the following metrics:
Requests
The number of AAA requests.
Responses
The number of AAA responses.
Errors
The number of AAA errors for the selected time interval.
Aborts
The number of aborted AAA sessions.
RADIUS Requests
The number of RADIUS requests.
Diameter Requests
The number of Diameter requests.
Methods
Displays the selected method types for the AAA client or server.
Transactions Per Second
Displays the number of protocol transactions per second as a function of time over the selected time interval. The chart is annotated with red data points to indicate errors. The volume of errors is denoted by the height of red bars under the chart. Click the red dot to see the number of errors that occurred at that time. Click and drag across the chart to select a particular region.
Response Time Breakdown
Displays the area chart containing median round-trip time, request transfer time, server processing time, and response transfer time over time in milliseconds. Click and drag across the chart to select a particular region.
Round-Trip Time (ms)
Displays the median round-trip time (RTT) in milliseconds (ms) from the current objects to clients as a function of time over the selected time interval. Vertical dotted lines indicate the upper and lower quartiles (75th and 25th percentiles) of the round-trip time metrics. Click and drag across the chart to select a particular region.
Congestion Requests: Goodput (bps) and RTOs
Displays goodput and RTOs into the object as a function of time over the selected time interval.
Congestion Responses: Goodput (bps) and RTOs
Displays goodput and RTOs out of the object as a function of time over the selected time interval.

Goodput is application-level throughput (the number of useful information bits) and RTOs are retransmission timeouts. The Congestion In and Out graphs show the relationship over time between the rate of good application throughput and RTOs. An increase in RTOs theoretically leads to a decrease in goodput due to TCP back-off and packet retransmissions. It is best to view these charts in a smaller window of time so the metrics taken over time are not rolled up or smoothed out. In a small timeframe (30 minutes or less), one could see a decrease in goodput associated with a large number of RTOs, assuming that most flows on the server during this time frame experience this behavior. If only one or two flows are affected by RTOs, then the decreased goodput correlation might be masked by superficially healthy flows.

AAA devices page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
AAA Device Toolbar
The AAA device toolbar includes the following controls:
AAA Metric Type
Display metrics for devices acting as an AAA client or AAA server.
Errors
Click the Errors button to display the list of error messages sent to or received by the current device over the time interval. Errors are formatted as follows: Results-Code-Description:Session-Id:Error-Reporting-Host:Subscription-ID-Data.
  • Session-Id frequently contains multiple semicolon-separated records.
  • Error-Reporting-Host is not always present.
Records
Displays results for records that match the selected metric source and protocol.
AAA Client
If you select Client for the AAA Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of total requests that the device sent when acting as an AAA client.
Responses
Number of responses that the device received when acting as an AAA client.
Errors
Number of AAA errors for the selected time interval.
Aborts
Number of aborted sessions that occurred when the device is acting as an AAA client.
AAA Server
If you select Server for the AAA Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of total requests that the device received when acting as an AAA server.
Responses
Number of responses that the device sent when acting as an AAA server.
Errors
Number of AAA errors for the selected time interval.
Aborts
Number of aborted sessions that occurred when the device is acting as an AAA server.
Messages
Selected message types for the AAA server.
Status Codes
The AAA status codes for the selected time interval.
Processing Time Distribution
Displays a boxplot of times it took the server to process requests. Move the mouse pointer over each bar to display the time range it represents and the number of requests in this bin.
Transactions Per Second
Displays the number of protocol transactions per second as a function of time over the selected time interval. The chart is annotated with red data points to indicate errors. The volume of errors is denoted by the height of red bars under the chart. Click the red dot to see the number of errors that occurred at that time. Click and drag across the chart to select a particular region.
Response Time Breakdown
Displays the area chart containing median request transfer time, server processing time, and response transfer time over time in milliseconds. Click and drag across the chart to select a particular region.

AAA groups page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
AAA Groups Toolbar
The AAA groups toolbar includes the following controls:
Metric Type
Click the Metric Type drop-down list and select either Client or Server to display metrics for devices in the current group acting as an AAA client or AAA server, respectively.
Errors
Click the Errors button to display the list of error messages sent to or received by the current member over the time interval. Errors are formatted as follows: Results-Code-Description:Session-Id:Error-Reporting-Host:Subscription-ID-Data.

Session-Id frequently contains multiple semicolon-separated records. Error-Reporting-Host is not always present.

Records
Displays results for records that match the selected metric source and protocol.
AAA Client
If you select Client for the AAA Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of AAA requests for the selected time interval.
Responses
Number of AAA responses for the selected time interval.
Errors
Number of AAA errors for the selected time interval.
Aborts
Number of AAA aborted requests for the selected time interval.
Diameter Requests
Number of Diameter requests for the selected time interval.
Radius Requests
Number of RADIUS requests for the selected time interval.
AAA Server
If you select Server for the AAA Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of AAA requests for the selected time interval.
Responses
Number of AAA responses for the selected time interval.
Errors
Number of AAA errors for the selected time interval.
Aborts
Number of AAA aborted requests for the selected time interval.
Diameter Requests
Number of Diameter requests for the selected time interval.
Radius Requests
Number of RADIUS requests for the selected time interval.
Messages
Selected message types for the AAA server.

AMF

ExtraHop appliances collect metrics about Hypertext Transfer Protocol (HTTP) Action Message Format (AMF) activity.

AMF client page

AMF Summary

Transactions
This chart shows you when AMF errors occurred and how many responses the AMF client received. This information can help you see how active the client was at the time it received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Total Transactions
This chart displays the total number of AMF responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long the client took to transmit requests onto the network; the server processing time shows how long servers took to process the requests; and the response transfer time shows how long servers took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

AMF Client Request Transfer Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the first packet and last packet of sent requests. A high value may indicate a large request or network delay.
AMF Client Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
AMF Client Response Transfer Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the first packet and last packet of received responses. High values may indicate a large response or network delay.
Round Trip Time The time between when a AMF client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If a client is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. These metrics show the 95th percentile amount of time that servers took to process requests from the client versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the client is contacting slow servers. High TCP round trip times indicate that the client is communicating over slow networks.
AMF Client Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Time The time between when a AMF client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

AMF Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
AMF Client Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Server Processing Time
This chart shows the median processing time for the client.
Metric Description
AMF Client Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when a AMF client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the client.
Metric Description
Round Trip Time The time between when a AMF client sent a packet that required an immediate acknowledgment and when the client received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

AMF Metric Totals

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the client might be sending more requests than the servers can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.
Note:It is unlikely that the total number of AMF requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests that the device sent when acting as an HTTP-AMF client.
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Responses Without Length The number of responses that had no length, that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Requests Without Length The number of requests that had no length, that the device sent when acting as an HTTP-AMF client.
Request and Response Size
This chart shows the average size of requests and responses.
Metric Description
Request Size The distribution of sizes (in bytes) of requests that the device sent when acting as an HTTP-AMF client.
Response Size The distribution of sizes (in bytes) of responses that the device received when acting as an HTTP-AMF client.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AMF server page

AMF Summary

Transactions
This chart shows you when AMF errors occurred and how many AMF responses the server sent. This information can help you see how active the server was at the time it returned the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Total Transactions

This chart displays the total number of AMF responses the server sent and how many of those responses contained errors.

Metric Description
Responses The number of responses that the device sent when acting as an HTTP-AMF server.
Errors The number of response errors that the device sent when acting as an HTTP-AMF server.
Performance Summary (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long clients took to transmit requests onto the network; the server processing time shows how long the server took to process requests; and the response transfer time shows how long the server took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

AMF Server Request Transfer Time When the device is acting as an HTTP-AMF server, the time between the ExtraHop system detecting the first packet and last packet of received requests. A high value may indicate a large request or network delay.
AMF Server Server Processing Time When the device is acting as an HTTP-AMF server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
AMF Server Response Transfer Time When the device is acting as an HTTP-AMF server, the time between the ExtraHop system detecting the first packet and last packet of sent responses. High values may indicate a large response or network delay.
Round Trip Time The time between when an AMF server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th Percentile)
If a server is acting slow, performance summary metrics can help you figure out whether the network or the server is causing the issue. The performance summary metrics show the 95th percentile amount of time the server took to process requests from clients versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the server is slow. High RTTs indicate that the server is communicating over slow networks.
Metric Description
AMF Server Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Round Trip Time The time between when an AMF server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

AMF Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
AMF Server Server Processing Time When the device is acting as an HTTP-AMF server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Server Processing Time
This chart shows the median processing time for the server.
Metric Description
Server Processing Time When the device is acting as an HTTP-AMF server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when an AMF server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the server.
Metric Description
Round Trip Time The time between when an AMF server sent a packet that required an immediate acknowledgment and when the server received the acknowledgment. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

AMF Metric Totals

Total Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the server can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.

Note:It is unlikely that the total number of AMF requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests that the device received when acting as an HTTP-AMF server.
Responses The number of responses that the device sent when acting as an HTTP-AMF server.
Responses Without Length The number of responses that had no length, that the device sent when acting as an HTTP-AMF server.
Errors The number of response errors that the device sent when acting as an HTTP-AMF server.
Requests Without Length The number of requests that had no length, that the device received when acting as an HTTP-AMF server.
Request and Response Size
This chart shows the average size of requests and responses.
Metric Description
Request Size The distribution of sizes (in bytes) of requests that the device received when acting as an HTTP-AMF server.
Response Size The distribution of sizes (in bytes) of responses that the device sent when acting as an HTTP-AMF server.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AMF client group page

Learn about charts on this page

AMF Summary for Group

Transactions
This chart shows you when AMF errors occurred and how many responses the AMF clients received. This information can help you see how active the clients were at the time they received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Total Transactions
This chart shows you how many AMF responses the clients received and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.

AMF Details for Group

Top Group Members (AMF Clients)
This chart shows which AMF clients in the group were most active by breaking out the total number of AMF requests the group sent by client.

AMF Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the clients might be sending more requests than servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests that the device sent when acting as an HTTP-AMF client.
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Responses Without Length The number of responses that had no length, that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Requests Without Length The number of requests that had no length, that the device sent when acting as an HTTP-AMF client.
Server Processing Time
If a client group is acting slow, the server processing time can help you figure out whether the issue is with the servers. The Server Processing Time chart shows the median amount of time servers took to process requests from the clients. High server processing times indicate that the clients are contacting slow servers.
AMF Client Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

AMF server group page

Learn about charts on this page

AMF Summary for Group

Transactions
This chart shows you when AMF errors occurred and how many AMF responses the servers sent. This information can help you see how active the servers were at the time they returned the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.
Total Transactions
This chart shows you how many AMF responses servers in the group sent and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as an HTTP-AMF client.
Errors The number of response errors that the device received when acting as an HTTP-AMF client.

AMF Details for Group

Top Group Members (AMF Servers)
This chart shows which AMF servers in the group were most active by breaking out the total number of AMF responses the group sent by server.

AMF Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests that the device received when acting as an HTTP-AMF server.
Responses The number of responses that the device sent when acting as an HTTP-AMF server.
Responses Without Length The number of responses that had no length, that the device sent when acting as an HTTP-AMF server.
Errors The number of response errors that the device sent when acting as an HTTP-AMF server.
Requests Without Length The number of requests that had no length, that the device received when acting as an HTTP-AMF server.
Server Processing Time
The Server Processing Time chart shows the median amount of time the servers took to process requests from clients. High server processing times indicate that the servers in a group are slow.
Metric Description
AMF Server Server Processing Time When the device is acting as an HTTP-AMF client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

HTTP-AMF devices page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
HTTP-AMF Devices Page
The HTTP-AMF device toolbar includes the following controls:
HTTP-AMF Metric Type
Displays metrics for the current device acting as an HTTP-AMF client or HTTP-AMF server.
Clients or Servers
Displays the associated client IP addresses when the device is acting as a server, and the associated server IP addresses when acting as a client.

HTTP-AMF Details specifies the type of additional HTTP-AMF information displayed. Moving the mouse pointer over the counter next to each top-level metric opens a context menu that includes the following options in the drop-down list:

By IP
Displays HTTP-AMF metrics by IP addresses.
By Target URI
Displays HTTP-AMF metrics by Target URI.

For example, HTTP-AMF Requests is a top-level metric showing how many requests were received by the HTTP server during the selected time frame. Selecting By IP in the drop-down list while moving the mouse pointer over the Requests counter displays which IP addresses originated these requests. Selecting By Target URI from the drop-down list while moving the mouse pointer over the HTTP-AMF Requests counter displays which URIs were accessed by the requesters.

IP Address HTTP-AMF Metrics
Click By IP in the drop-down list to display the following information in the details table.
IP Address
Represents the HTTP-AMF server's IP address.
Host
Represents the DNS host name of the HTTP-AMF server determined by passive analysis of the DNS traffic.
Device
Provides a link to the corresponding HTTP-AMF server device. For local HTTP-AMF servers, the link leads to the HTTP server device. For remote HTTP-AMF servers, the link leads to the gateway device through which the requests were routed.
<Metric value>
Displays the value for the selected metric.
Processing Time
Represents the time in milliseconds it took for HTTP servers to process requests for the currently selected HTTP client. Timing information is expressed as a confidence interval around the mean value bounded by one standard deviation. This metric is available for successful HTTP Responses only.
HTTP-AMF Metrics by Target URI
Click By Target URI in the drop-down list to display the following information in the details table.
Target URI
Represents the full HTTP target URI.
<Metric value>
Displays the value for the selected metric.
Processing Time
Represents the time in milliseconds it took to process URIs requested by the currently selected HTTP client. Timing information is expressed as a confidence interval around the mean value bounded by one standard deviation. This metric is available for successful HTTP Responses only.
HTTP-AMF Client
If you select Client for the HTTP-AMF Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of requests that the device sent when acting as an HTTP-AMF client.
Responses
Number of responses that the device received when acting as an HTTP-AMF client.
Errors
Number of HTTP-AMF errors for the selected time interval.
Requests w/o Length
Number of requests that had no length, that the device received when acting as an HTTP-AMF client.
Responses w/o Length
Number of responses that had no length, that the device sent when acting as an HTTP-AMF client.
HTTP-AMF Server
If you select Server for the HTTP-AMF Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of requests that the device received when acting as an HTTP-AMF server.
Responses
Number of responses that the device sent when acting as an HTTP-AMF server.
Errors
Number of HTTP-AMF errors for the selected time interval.
Requests w/o Length
Number of requests that had no length, that the device received when acting as an HTTP-AMFs server.
Responses w/o Length
Number of responses that had no length, that the device sent when acting as an HTTP-AMF server.

HTTP-AMF groups page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
HTTP-AMF Client
If you select Client for the HTTP-AMF Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of HTTP-AMF requests for the selected time interval.
Responses
Number of HTTP-AMF responses for the selected time interval.
Errors
Number of HTTP-AMF errors for the selected time interval.
Requests w/o Length
Number of HTTP-AMF requests without length.
Responses w/o Length
Number of HTTP-AMF responses without length.
HTTP-AMF Server
If you select Server for the HTTP-AMF Metric Type, the Discover appliance displays the following metrics. Click the counter next to each metric to break it down by group members in the table at the bottom of the page.
Requests
Number of HTTP-AMF requests for the selected time interval.
Responses
Number of HTTP-AMF responses for the selected time interval.
Errors
Number of HTTP-AMF errors for the selected time interval.
Requests w/o Length
Number of HTTP-AMF requests without length.
Responses w/o Length
Number of HTTP-AMF responses without length.

CIFS

ExtraHop appliances collect metrics about Common Internet File System (CIFS)/Server Message Block (SMB) activity. ExtraHop appliances support SMB, SMB2 and SMB3.

Important:Access time is the time it takes for a CIFS server to receive a requested block. There is no access time for operations that do not access actual block data within a file. Processing time is the time it takes for a CIFS server to respond to the operation requested by the client, such as a metadata retrieval request.

There are no access times for SMB2_CREATE. SMB2_CREATE creates a file that is referenced in the response by an SMB2_FILEID. The referenced file blocks are then read from or written to the NAS-storage device. These file read and write operations are calculated as access times.

CIFS client page

CIFS Summary

Transactions
This chart shows you when CIFS errors occurred and how many responses the CIFS client received. This information can help you see how active the client was at the time it received the errors.

If you see a large number of errors, you can view details about each error, including the error code. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of requests to responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Tip:To drill down by error code, click Errors and select Error from the menu.
Metric Description
Responses The number of responses received by this CIFS client.
Errors The number of responses received by this CIFS client with an SMB status code other than SUCCESS or a warning. A high number of CIFS errors might indicate corrupt profiles.
Total Transactions
This chart displays the total number of CIFS responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses received by this CIFS client.
Errors The number of responses received by this CIFS client with an SMB status code other than SUCCESS or a warning. A high number of CIFS errors might indicate corrupt profiles.
Operations
This chart shows you when the CIFS client performed read, write, and file system information request operations.
Metric Description
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
File System Information Requests The number of file system metadata queries sent by this CIFS client.
Operation Summary
This chart shows you how many read and write operations the CIFS client performed.
Metric Description
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The access time shows how long servers took to process read or write operations that accessed block data within a file. Access times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at the access time, because this metric alone provides an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high access times, but the RTT is low, the issue is probably at the device-level. However, if the RTT and access times are both high, network latency might be affecting the transfer and access times, and the issue might be with the network.

RTT only measures how long an immediate acknowledgement takes to be sent; it does not wait until all packets are delivered. Therefore, RTT is a good indicator of how your network is performing. If you see high access times, but the TCP RTT is low, the issue is probably at the device-level. Check the network for latency issues if the TCP RTT and access times are all both.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The access time might be high because the server took a long time to transmit the response (possibly because the response was very large); however, the access time could also be high because the response took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
CIFS Client Request Transfer Time When the device is acting as a CIFS client, the time between the ExtraHop system detecting the first packet and last packet of sent requests. High values may indicate a large request or network delay.
CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this CIFS client and first packet of the received response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
CIFS Client Response Transfer Time When the device is acting as a CIFS client, the time between the ExtraHop system detecting the first packet and last packet of received responses. High values may indicate a large response or network delay.
Round Trip Time Round trip time (RTT) is a measurement of total network latency. The ExtraHop system calculates RTT by measuring the time it took between sending a packet and receiving an immediate acknowledgement (ACK).

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th Percentile)
If a client is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. The performance summary metrics show the median amount of time servers took to process requests from the client versus the median time that packets from those requests (and their respective responses) took to be transmitted across the network. High server access times indicate that the client is contacting slow servers. High TCP round trip times indicate that the client is communicating over slow networks.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the request sent by this CIFS client and first packet of the received response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
Round Trip Time Round trip time (RTT) is a measurement of total network latency. The ExtraHop system calculates RTT by measuring the time it took between sending a packet and receiving an immediate acknowledgement (ACK).

CIFS Details

Top Methods
This chart shows which CIFS methods the client called the most by breaking out the total number of requests the client sent by method.
Top Users
This chart shows which users were most active on the client by breaking out the total number of CIFS requests sent by the client by user.
Top Files
This chart shows which files the client accessed the most by breaking out the total number of responses the client received by file path.

CIFS Performance

Access Time Distribution
This chart breaks out access times in a histogram to show the most common access times.
Metric Description
CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this CIFS client and first packet of the received response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
Access Time
This chart shows the median access time for the client.
Metric Description
CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this CIFS client and first packet of the received response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

CIFS Metric Totals

Total Requests and Responses
This chart shows you how many operations the CIFS client performed.
Metric Description
Requests The number of requests sent by this CIFS client.
Responses The number of responses received by this CIFS client.
Errors The number of responses received by this CIFS client with an SMB status code other than SUCCESS or a warning. A high number of CIFS errors might indicate corrupt profiles.
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
File System Info Requests The number of file system metadata queries sent by this CIFS client.
Locks The number of lock operation requests produced by this CIFS client.
Warnings The number of responses received by this CIFS client with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES.
Request and Response Size
This chart shows the average size of requests and responses.
Metric Description
CIFS Server Request Size The distribution of sizes (in bytes) of requests sent by this CIFS client.
CIFS Server Response Size The distribution of sizes (in bytes) of responses received when the device is acting as a CIFS client.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

CIFS server page

CIFS Summary

Transactions
This chart shows you when CIFS errors occurred and how many CIFS responses the server sent. This information can help you see how active the server was at the time it returned the errors.

If you see a large number of errors, you can view details about each error, including the error code. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of requests to responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Tip:To drill down by error code, click Errors and select Error from the menu.
Metric Description
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.
Total Transactions

This chart displays the total number of CIFS responses the server sent and how many of those responses contained errors.

Metric Description
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.
Operations
This chart shows you when the read, write, and file system information request operations were performed on the server.
Metric Description
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
File System Information Requests The number of file system metadata queries sent by this CIFS client.
Operation Summary
This chart shows you how many read and write operations were performed on the server.
Metric Description
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The access time shows how long servers took to process read or write operations that accessed block data within a file. Access times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at the access time, because this metric alone provides an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high access times, but the RTT is low, the issue is probably at the device-level. However, if the RTT and access times are both high, network latency might be affecting the transfer and access times, and the issue might be with the network.

RTT only measures how long an immediate acknowledgement takes to be sent; it does not wait until all packets are delivered. Therefore, RTT is a good indicator of how your network is performing. If you see high access times, but the TCP RTT is low, the issue is probably at the device-level. Check the network for latency issues if the TCP RTT and access times are all both.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The access time might be high because the server took a long time to transmit the response (possibly because the response was very large); however, the access time could also be high because the response took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
CIFS Server Request Transfer Time When the device is acting as a CIFS server, the time between the ExtraHop system detecting the first packet and last packet of received requests. High values may indicate a large request or network delay.
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this CIFS server and first packet of the response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
CIFS Server Response Transfer Time When the device is acting as a CIFS server, the time between the ExtraHop system detecting the first packet and last packet of sent responses. High values may indicate a large response or network delay.
Round Trip Time Round trip time (RTT) is a measurement of total network latency. The ExtraHop system calculates RTT by measuring the time it took between sending a packet and receiving an immediate acknowledgement (ACK).

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If a server is acting slow, performance summary metrics can help you figure out whether the network or the server is causing the issue. The performance summary metrics show the median amount of time the server took to process requests from clients versus the median time that packets from those requests (and their respective responses) took to be transmitted across the network. High server access times indicate that the server is slow. High RTTs indicate that the server is communicating over slow networks.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this CIFS server and first packet of the response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
Round Trip Time Round trip time (RTT) is a measurement of total network latency. The ExtraHop system calculates RTT by measuring the time it took between sending a packet and receiving an immediate acknowledgement (ACK).

CIFS Details

Top Methods
This chart shows which CIFS methods were called on the server the most by breaking out the total number of requests the server received by method.
Top Users
This chart shows which users were most active on the server by breaking out the total number of CIFS requests sent to the server by user.
Top Files
This chart shows which files on the server were accessed the most by breaking out the total number of responses the server sent by file path.

CIFS Performance

Access Time Distribution
This chart breaks out access times in a histogram to show the most common access times.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this CIFS server and first packet of the response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.
Access Time
This chart shows the median access time for the client.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this CIFS server and first packet of the response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

CIFS Metric Totals

Operations
This chart shows you how many operations were performed on the CIFS server.
Metric Description
Requests The number of requests received by this CIFS server.
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.
Reads The number of read operation requests received by this CIFS server.
Writes The number of write operation requests received by this CIFS server.
File System Info Requests The number of file system metadata queries device received by this CIFS server.
Locks The number of lock operation requests received by this CIFS server.
Warnings The number of responses sent by this CIFS server with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES.
Request and Response Size
This chart shows the average size of requests and responses.
Metric Description
CIFS Server Request Size The distribution of sizes (in bytes) of requests received by this CIFS server.
CIFS Server Response Size The distribution of sizes (in bytes) of responses sent by this CIFS server.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

CIFS client group page

CIFS Summary for Group

Transactions
This chart shows you when CIFS errors occurred and how many responses the CIFS clients received. This information can help you see how active the clients were at the time they received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses received by this CIFS client.
Errors The number of responses received by this CIFS client with an SMB status code other than SUCCESS or a warning. A high number of CIFS errors might indicate corrupt profiles.
Total Transactions
This chart shows you how many CIFS responses the clients received and how many of those responses contained errors.
Metric Description
Responses The number of responses received by this CIFS client.
Errors The number of responses received by this CIFS client with an SMB status code other than SUCCESS or a warning. A high number of CIFS errors might indicate corrupt profiles.

CIFS Details for Group

Top Group Members (CIFS Clients)
This chart shows which CIFS clients in the group were most active by breaking out the total number of CIFS requests the group sent by client.
Top Methods
This chart shows which CIFS methods the group called the most by breaking out the total number of requests the group sent by method.
Top Users
This chart shows which CIFS users were most active in the group by breaking out the total number of CIFS responses the group received by user.

CIFS Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the clients might be sending more requests than servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests sent by this CIFS client.
Responses The number of responses received by this CIFS client.
Reads The number of read operation requests sent by this CIFS client.
Writes The number of write operation requests sent by this CIFS client.
File System Info Requests The number of file system metadata queries sent by this CIFS client.
Locks The number of lock operation requests produced by this CIFS client.
Warnings The number of responses received by this CIFS client with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES.
Access Time
If a client group is acting slow, the access time can help you figure out whether the issue is with the servers. The Server Processing Time chart shows the median amount of time servers took to process requests from the clients. High access times indicate that the clients are contacting slow servers.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the request sent by this CIFS client and first packet of the received response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

CIFS server group page

CIFS Summary for Group

Transactions
This chart shows you when CIFS errors occurred and how many CIFS responses the servers sent. This information can help you see how active the servers were at the time they returned the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Metric Description
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.
Total Transactions
This chart shows you how many CIFS responses servers in the group sent and how many of those responses contained errors.
Metric Description
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.

CIFS Details for Group

Top Group Members (CIFS Servers)
This chart shows which CIFS servers in the group were most active by breaking out the total number of CIFS responses the group sent by server.
Top Methods
This chart shows which CIFS methods were called on servers in the group the most by breaking out the total number of requests the group received by method.
Top Users
This chart shows which CIFS users were most active in the group by breaking out the total number of CIFS responses the group sent by user.

CIFS Metrics in Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests received by this CIFS server.
Responses The number of responses sent by this CIFS server.
Errors The number of responses sent by this CIFS server with an SMB status code other than SUCCESS or a warning. A high number of errors should be investigated.
Reads The number of read operation requests received by this CIFS server.
Writes The number of write operation requests received by this CIFS server.
File System Info Requests The number of file system metadata queries device received by this CIFS server.
Locks The number of lock operation requests received by this CIFS server.
Warnings The number of responses sent by this CIFS server with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES.
Access Time
If a server group is acting slow, the Access Time chart can help you figure out whether the issue is with the servers. The Access Time chart shows the median amount of time the servers took to process requests from clients. High server access times indicate that the servers are slow.
Metric Description
CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this CIFS server and first packet of the response. Access time is measured only for the first READ or WRITE operation on every flow in order to minimize the influence of pre-fetching and caching on timing metrics.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

CIFS devices page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
CIFS Devices Toolbar
The CIFS device page toolbar includes the following controls:
CIFS Metric Type
Displays metrics for the current device acting as a CIFS client or CIFS server.
Errors
Displays the list of error messages sent to or received by the current device over the selected time interval.
Warnings
Displays the list of warning messages sent to or received by the current device over the selected time interval.
Methods
Displays the list of methods and associated bytes sent and received by the current device for the selected time interval. Methods are broken out by key parameters, such as the accessed file name and file access time.
Users
Displays the list of users accessing the file server and associated bytes sent and received for the selected time interval.
Files
Displays the list of files accessed and associated bytes sent and received for the selected time interval. The access time indicates the time to access a file on a CIFS partition and is measured by timing the first READ or WRITE on every flow.
Records
Displays results for records that match the selected metric source and protocol.

Where file name detail is presented, the Discover appliance displays both the file path and mount point, if available. The prefix '...' indicates that either the mount point or part of the path is not available. This might occur in instances when the capture process was restarted after the mount or a cd command was issued, or when the commands were lost due to desyncs.

Click the counters next to individual CIFS metrics to show the IP Address CIFS Metrics details for CIFS peer devices. For CIFS servers, the peer devices are CIFS clients. For CIFS clients, the peer devices are CIFS servers.

IP Address
Represents the IP address of the peer device.
Host
Represents the DNS host name of the peer device determined by passive analysis of the DNS traffic.
Device
Provides a link to the corresponding peer device. For local peer devices, the link leads to that device. For remote peer devices, the link leads to the gateway device through which the requests were routed.
CIFS Server
Displays additional IP address details.
Responses
Specifies the number of responses that the device sent when acting as a CIFS server.
Errors
Specifies the number of errors sent by the CIFS server.
Warnings
Displays the list of warning messages sent to or received by the CIFS server over the selected time interval.
Reads
Specifies the number of read operation requests that the device received when acting as a CIFS server.
Writes
Specifies the number of write operation requests that the device received when acting as a CIFS server.
Locks
Specifies the number of lock operation requests that the device received when acting as a CIFS server.
FSInfo
Specifies the number of file system metadata queries that the device received when acting as a CIFS server.
CIFS Client
Displays additional IP address details.
Responses
Specifies the number of responses that the device received when acting as a CIFS client.
Errors
Specifies the number of errors sent by the CIFS client.

CIFS groups page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
CIFS Groups Toolbar
The CIFS groups toolbar includes the following controls:
CIFS Metric Type
Displays metrics for devices in the current group acting as a CIFS client or server, respectively.
Errors
Displays the list of error messages sent to or received by devices in the current group over the selected time interval.
Warnings
Displays the list of warning messages sent to or received by devices in the current group over the selected time interval.
Methods
Displays the list of methods and associated bytes sent and received by devices in the current group during the selected time interval. Methods are broken out by key parameters, such as the accessed file name.
Users
Displays the list of users accessing the file server and associated bytes sent and received for the selected time interval.
Files
Displays the list of files accessed and associated bytes sent and received for the selected time interval. Access Time indicates the time it took for the server to access a file on disk.
Records
Displays results for records that match the selected metric source and protocol.

Where file name detail is presented, the Discover appliance displays both the file path and mount point, if available. The prefix '...' indicates that either the mount point or part of the path is not available. This might occur in instances when the capture process was restarted after the "mount" or a "cd" command was issued, or when the commands were lost due to desyncs.

CIFS Server
Click the counter next to the metric to break it down by group members in the table at the bottom of the page.
Responses
Specifies the number of responses sent by the CIFS server.
Errors
Specifies the number of errors sent by the CIFS server.
Warnings
Displays the list of warning messages sent to or received by devices in the CIFS server over the selected time interval.
Reads
Specifies the number of read operations requested from the CIFS server.
Writes
Specifies the number of write operations requested from the CIFS server.
Locks
Specifies the number of lock operations requested from the CIFS server.
CIFS Client
Click the counter next to the metric to break it down by group members in the table at the bottom of the page.
Responses
Specifies the number of responses received by the CIFS client.
Errors
Specifies the number of errors sent by the CIFS client.
Warnings
Displays the list of warning messages sent to or received by the CIFS client over the selected time interval.
Reads
Specifies the number of read operations requested by the CIFS client.
Writes
Specifies the number of write operations requested by the CIFS client.
Locks
Specifies the number of lock operations requested by the CIFS client.
Methods
Displays the CIFS methods for the selected time interval.

Click the counter next to the method to break it down by group members in the table.

Database

ExtraHop appliances collect metrics about database activity. Activity for the following databases is aggregated and displayed under Database metrics in the ExtraHop Web UI:

  • IBM DB2
  • IBM Informix
  • Microsoft SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
  • Sybase ASE
  • Sybase IQ
Note:ExtraHop Discover appliances also monitor MongoDB database activity, which is displayed through a separate set of metrics specific to MongoDB.

Learn more by taking the Database Quick Peek training.

The following sections describe the top metrics that you should investigate for problems related to databases.

Errors

Database errors occur when a database request cannot be completed by the server. Errors can indicate a minor issue, such as a single log-in failure, or a more severe issue, such as an overloaded database server.

When investigating database errors, you can start by reviewing the total number of errors in your environment on the Metrics > Applications > All Activity > Database page. You can view details about each error, including the raw error message reported by the database, by clicking the Errors icon.

On the Applications > All Activity > Database page, you can break out metrics by database server by hovering over the Response Errors value and clicking By Server IP. You can then sort by the number of errors. If one database server is returning a large number of errors, you can click the server name, and then click the Errors icon to view the total number of errors for that server. However, if no server is contributing a large number of errors, the issue might be more complex, and you should investigate which methods were called on each database.

Methods

You can view which methods were called on databases in your environment. Poorly-formed database calls can cause performance issues, even if no errors exist. To see all methods that were called in your environment over a specified time interval, go to the Metrics > Applications > All Activity > Database page and click Methods.

If a method is called on a table, the table name is displayed after an @ symbol. For example, CREATE @ Configuration displays metrics about how many times the CREATE method was called on a table named Configuration. Methods can be sorted by processing time, which is the amount of time between when a server receives a request and when the server sends a response. Long processing times can indicate that the database is poorly optimized or that statements are poorly formatted.

Custom metrics and records

If the processing time for a database method is continuously long, you might want to investigate further by collecting the raw SQL statements that contain the method. You can record and view raw SQL statements by creating a custom metric or by generating records through a trigger. A custom metric enables you to view a graphical representation of the information; for example, you could create a chart of how many slow database requests occurred over time and break out each response by the SQL statement. Records enable you to view individual records of each event; for example, you could view exactly how much time it took the server to respond to each SQL statement.

The following trigger runs when a database response event occurs. If a database server takes more than 100 milliseconds to respond to a SELECT request on the Configuration table, the trigger records the SQL statement of the request in a custom metric. The trigger also records the total number of database requests that took the server more than 100 milliseconds to respond to.

// Event: DB_RESPONSE
if (DB.processingTime > 100 && DB.method == "SELECT" && DB.table == "Configuration") {

  // Record a custom metric.
  Device.metricAddCount('slow_performers', 1);
  Device.metricAddDetailCount('slow_performers_by_statement', DB.statement, 1);
}

The next trigger generates similar information, but in the form of a record for all database responses. The records contain the processing time, method, table name, and SQL statement for each response. After the records are collected, you can view the SQL statements for all SELECT requests on the Configuration table that took the server more than 100 milliseconds to respond to.

// Event: DB_RESPONSE
DB.commitRecord()
Note:Your Discover appliance must be connected to an Explore appliance to generate records.

After you create a trigger, you must assign the trigger to the devices you want to monitor. If you create a custom metric, you must create a dashboard to view the custom metric.

For more information about triggers, see Triggers concepts.

For more information about dashboards, see Dashboards concepts.

For more information about records, see Records concepts.

Database application page

Database Summary

Transactions
This chart shows you when database errors and responses were associated with the application. This information can help you see how active the application was at the time the errors occurred.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of database responses associated with the application.
Errors The number of database request operations that failed on all database instances. All database errors should be investigated.
Total Transactions
This chart displays the total number of database responses that were associated with the application and how many of those responses contained errors.
Metric Description
Responses The number of database responses associated with the application.
Errors The number of database request operations that failed on all database instances. All database errors should be investigated.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long clients took to transmit requests onto the network; the server processing time shows how long the servers took to process requests; and the response transfer time shows how long the servers took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:



It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
Server Processing Time The time it took for database instance to send the first packet of response after receiving the last packet of a database request operation.
Round Trip Time The time it took for the server or client to send a packet and receive an acknowledgement (ACK). Round trip time might be calculated over the course of a TCP connection. A long round trip time (RTT) indicates network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If an application is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. These metrics show the 95th percentile of time that servers took to process requests from clients versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that clients are contacting slow servers. High TCP round trip times indicate that clients are communicating over slow networks.
Metric Description
Server Processing Time The time it took for database instance to send the first packet of response after receiving the last packet of a database request operation.
Round Trip Time The time it took for the server or client to send a packet and receive an acknowledgement (ACK). Round trip time might be calculated over the course of a TCP connection. A long round trip time (RTT) indicates network latency.

Database Details

Top Methods
This chart shows which database methods were associated with the application by breaking out the total number of database requests by method.
Top Methods (Detailed)
This chart shows which database methods were associated with the application by breaking out the total number of database requests by method.
Top Users
This chart shows which users were most active in the application by breaking out the total number of database requests sent by the application.

Database Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
Database Server Processing Time The time it took for database instance to send the first packet of response after receiving the last packet of a database request operation.
Server Processing Time
This chart shows the median processing time for the application.
Metric Description
Database Server Processing Time The time it took for database instance to send the first packet of response after receiving the last packet of a database request operation.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time it took for the server or client to send a packet and receive an acknowledgement (ACK). Round trip time might be calculated over the course of a TCP connection. A long round trip time (RTT) indicates network latency.
Round Trip Time
This chart shows the median round trip time for the application.
Metric Description
Round Trip Time The time it took for the server or client to send a packet and receive an acknowledgement (ACK). Round trip time might be calculated over the course of a TCP connection. A long round trip time (RTT) indicates network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either a server or a client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were associated with an application. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Request Zero Windows The number of zero window advertisements sent by database clients. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of Zero Windows In indicates that a peer device was too slow to process the amount of data received.

Response Zero Windows The number of zero window advertisements sent by servers while receiving database requests. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of Zero Windows Out indicates that a client was too slow to process the amount of data received.

Total Host Stalls
This chart shows the median number of zero window advertisements sent by devices.
Network Stalls
This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.
Metric Definition
RTOs In The number of retransmission timeouts caused by congestion when clients were sending database requests. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs In, a device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts caused by congestion when servers were sending database responses. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs Out, a device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

Total Network Stalls
This chart shows the median number of retransmission timeouts caused by congestion when clients and servers were sending requests.

Database Metric Totals

Total Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than servers can handle or the network might be too slow. To identify whether the issue is with the network or a server, check RTOs and zero windows in the Network Data section.

Note:It is unlikely that the total number of database requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of database requests associated with this application.
Responses The number of database responses associated with the application.
Errors The number of database request operations that failed on all database instances. All database errors should be investigated.
AAA Network Metrics
Metric Description
Request Zero Windows The number of zero window advertisements sent by database clients. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.
Response Zero Windows The number of zero window advertisements sent by servers while receiving database requests. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.
RTOs In The number of retransmission timeouts caused by congestion when clients were sending database requests. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.
RTOs Out The number of retransmission timeouts caused by congestion when servers were sending database responses. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.
Request L2 Bytes The number of L2 bytes associated with database requests.
Response L2 Bytes The number of L2 bytes associated with database responses.
Request Goodput Bytes The number of goodput bytes associated with database requests. Goodput refers to the throughput of the original data transferred and excludes other throughput such as protocol headers or retransmitted packets.
Response Goodput Bytes The number of goodput bytes associated with database responses. Goodput refers to the throughput of the original data transferred and excludes other throughput such as protocol headers or retransmitted packets.
Request Packets The number of packets associated with database requests.
Response Packets The number of packets associated with database responses.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

Database client page

Database Summary

Transactions
This chart shows you when database errors occurred and how many responses the database client received. This information can help you see how active the client was at the time it received the errors.

If you see a large number of errors, you can view details about each error, including the raw error message reported by the database. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of requests to responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Tip:To see more information about errors, click the Errors link at the top of the page.
Metric Description
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.
Total Transactions
This chart displays the total number of database responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long the client took to transmit requests onto the network; the server processing time shows how long servers took to process the requests; and the response transfer time shows how long servers took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Metric Description
Database Client Request Transfer Time When the device is acting as a database client, the time between the ExtraHop system detecting the first packet and last packet of sent requests. High values may indicate a large request or network delay.
Database Client Server Processing Time The time it took for this database client to receive the first packet of a response after sending the last packet of the query.
Database Client Response Transfer Time When the device is acting as a database client, the time between the ExtraHop system detecting the first packet and last packet of received responses. High values may indicate a large response or network delay.
Round Trip Time The time between when a database client sent a packet that required an immediate acknowledgment and when the client received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If a client is acting slow, performance summary metrics can help you figure out whether the network or servers are causing the issue. These metrics show the 95th percentile amount of time that servers took to process requests from the client versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the client is contacting slow servers. High TCP round trip times indicate that the client is communicating over slow networks.
Metric Description
Database Client Server Processing Time The time it took for this database client to receive the first packet of a response after sending the last packet of the query.
Round Trip Time The time between when a database client sent a packet that required an immediate acknowledgment and when the client received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

Database Details

Top Methods
This chart shows which methods the client called the most by breaking out the total number of database requests the client sent by method.
Top Status Codes
This chart shows which status codes the client received the most by breaking out the number of responses returned to the client by status code.
Top Users
This chart shows which users were most active on the client by breaking out the total number of database requests sent by the client by user.

Database Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
Database Client Server Processing Time The time it took for this database client to receive the first packet of a response after sending the last packet of the query.
Server Processing Time
This chart shows the median processing time for the client.
Metric Description
Database Client Server Processing Time The time it took for this database client to receive the first packet of a response after sending the last packet of the query.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Metric Description
Round Trip Time The time between when a database client sent a packet that required an immediate acknowledgment and when the client received the acknowledgement. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the client.
Metric Description
Round Trip Time The time between when a database client sent a packet that required an immediate acknowledgment and when the client received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

Database Metric Totals

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the client might be sending more requests than the servers can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.
Note:It is unlikely that the total number of database requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests sent by this database client. Requests cover a range of operations: connection negotiations, session configuration, data definition language (DDL), data modification language (DML), or data reads (select).
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.
Aborted Requests The number of requests that this database client began to send, but did not send completely.
Aborted Responses The number of responses that this database client began to receive, but did not receive completely when acting as a database client.
Request and Response Size
This chart shows the average size of requests and responses.
Metric Description
Request Size The distribution of sizes (in bytes) of requests that the device sent when acting as a database client.
Response Size The distribution of sizes (in bytes) of responses that the device received when acting as a database client.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

Database server page

Database Summary

Transactions
This chart shows you when database errors occurred and how many database responses the server sent. This information can help you see how active the server was at the time it returned the errors.

If you see a large number of errors, you can view details about each error, including the raw error message reported by the database. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of requests to responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Tip:To see more information about errors, click the Errors link at the top of the page.
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.
Total Transactions
This chart displays the total number of database responses the server sent and how many of those responses contained errors.
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.
Performance (95th Percentile)
This chart shows the 95th percentile of timing metrics. The transfer and processing time metrics show parts of a complete transaction. The request transfer time shows how long clients took to transmit requests onto the network; the server processing time shows how long the server took to process requests; and the response transfer time shows how long the server took to transmit responses onto the network.

Transfer and processing times are calculated by measuring the time between when the first and last packets of requests and responses are seen by the ExtraHop system, as shown in the following figure:

It can be difficult to tell whether an issue is caused by a network or a device from looking only at transfer and processing times, because these metrics alone provide an incomplete picture. Therefore the round trip time (RTT) metric is also included in this chart. RTT metrics are a good indicator of how your network is performing. If you see high transfer or processing times, but the RTT is low, the issue is probably at the device-level. However, if the RTT, processing, and transfer times are all high, network latency might be affecting the transfer and processing times, and the issue might be with the network.

The RTT metric can help identify the source of the problem because it only measures how long an immediate acknowledgement takes to be sent from the client or server; it does not wait until all packets are delivered.

The ExtraHop system calculates the RTT value by measuring the time between the first packet of a request and the acknowledgement from the server, as shown in the following figure:

The request transfer time might be high because the client took a long time to transmit the request (possibly because the request was very large); however, the transfer time could also be high because the request took a long time to travel on the network (possibly because of network congestion).

Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.

Request Transfer Time When the device is acting as a database server, the time between the ExtraHop system detecting the first packet and last packet of received requests. High values may indicate a large request or network delay.
Server Processing Time The time it took for this database server to send the first packet of a response after receiving the last packet of the query.
Response Transfer Time When the device is acting as a database server, the time between the ExtraHop system detecting the first packet and last packet of sent responses. High values may indicate a large response or network delay.
Round Trip Time The time between when a database server sent a packet that required an immediate acknowledgment and when the server received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

The Performance (95th percentile) chart shows the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. By displaying the 95th value, rather than the true maximum, the chart gives you a more accurate view of the data:

Performance (95th)
If a server is acting slow, performance summary metrics can help you figure out whether the network or the server is causing the issue. The performance summary metrics show the 95th percentile amount of time the server took to process requests from clients versus the 95th percentile time that packets from those requests (and their respective responses) took to be transmitted across the network. High server processing times indicate that the server is slow. High RTTs indicate that the server is communicating over slow networks.
Server Processing Time The time it took for this database server to send the first packet of a response after receiving the last packet of the query.
Round Trip Time The time between when a database server sent a packet that required an immediate acknowledgment and when the server received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

Database Details

Top Methods
This chart shows which database methods were called on the server the most by breaking out the total number of requests the server received by method.
Top Status Codes
This chart shows which database status codes the server returned the most by breaking out the total number of responses the server sent by status code.
Top Users
This chart shows which users were most active on the server by breaking out the total number of database requests sent to the server by user.

Database Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Server Processing Time The time it took for this database server to send the first packet of a response after receiving the last packet of the query.
Server Processing Time
This chart shows the median processing time for the server.
Server Processing Time The time it took for this database server to send the first packet of a response after receiving the last packet of the query.
Round Trip Time Distribution
This chart breaks out round trip times in a histogram to show the most common round trip times.
Round Trip Time The time between when a database server sent a packet that required an immediate acknowledgment and when the server received the acknowledgement. Round trip time (RTT) is a measurement of network latency.
Round Trip Time
This chart shows the median round trip time for the server.
Round Trip Time The time between when a database server sent a packet that required an immediate acknowledgment and when the server received the acknowledgement. Round trip time (RTT) is a measurement of network latency.

Network Data

This section shows you TCP information that is related to the current protocol. In general, host stalls indicate that there is an issue with either the server or the client, and network stalls indicate that there is an issue with the network.

Host Stalls
This chart shows the number of zero windows that were advertised or received by the device. Devices control the amount of data they receive by specifying the number of packets that can be sent to them over a given time period. When a device is sent more data than it can process, the device advertises a zero window to ask its peer device to stop sending packets completely until the device catches up. If you see a large number of zero windows, a server or client might not be not fast enough to support the amount of data being received.
Metric Definition
Zero Windows In The number of zero windows that were sent to the device to stop the flow of data over the connection. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows in indicates that a peer device was too slow to process the amount of data received.

Zero Windows Out The number of zero windows that were sent from the device to stop the flow of data. A device advertises a Zero Window when it cannot process incoming data as quickly as it is arriving.

A large number of zero windows out indicates that the client was too slow to process the amount of data received.

Network Stalls

This chart shows the number of retransmission timeouts that occurred. Retransmission timeouts (RTOs) occur when a network drops too many packets, usually due to packet collisions or buffer exhaustion. If a device sends a request or response and does not receive confirmation within a specified amount of time, the device retransmits the request. If too many retransmissions are unacknowledged, an RTO occurs. If you see a large number of RTOs, the network might be too slow to support the current level of activity.

Metric Definition
RTOs In The number of retransmission timeouts (RTOs) caused by network congestion as peers were sending data to the current device. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs in, the device did not send an acknowledgement to the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

RTOs Out The number of retransmission timeouts (RTOs) caused by network congestion as the device was sending data to its peers. An RTO is a one-second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of RTOs out, the device did not receive an acknowledgement from the server quickly enough, or the network might be too slow to support the current level of activity. Depending on the timeout value configured in the operating system, this delay can be anywhere from 1 to 8 seconds.

Database Metric Totals

Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the server can handle or the network might be too slow. To identify whether the issue is with the network or the server, check RTOs and zero windows in the Network Data section.
Note:It is unlikely that the total number of database requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Requests The number of requests received by all database instances on this server. Requests cover a range of operations: connection negotiations, session configuration, data definition language (DDL), data modification language (DML), or data reads (select).
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.
Aborted Requests The number of requests that this database server began to receive, but did not receive completely.
Aborted Responses The number of responses that this database server began to send, but did not send completely.
Request and Response Size
This chart shows the average size of requests and responses.
Request Size The distribution of sizes (in bytes) of requests that the device received when acting as a database server.
Response Size The distribution of sizes (in bytes) of responses that the device sent when acting as a database server.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

Database client group page

Database Summary for Group

Transactions
This chart shows you when database errors occurred and how many database responses the servers sent. This information can help you see how active the servers were at the time they returned the errors.

If you see a large number of errors, you can drill down to find the specific status codes returned in the requests and learn why servers were unable to fulfill the requests. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of database requests to database responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Tip:To see more information about errors, click the Errors link at the top of the page.
Metric Description
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.
Total Transactions
This chart shows you how many database responses the clients received and how many of those responses contained errors.
Metric Description
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.

Database Details for Group

Top Group Members (Database Clients)
This chart shows which database clients in the group were most active by breaking out the total number of database requests the group sent by client.
Top Methods
This chart shows which database methods the group called the most by breaking out the total number of requests the group sent by method.
Top Status Codes
This chart shows which database status codes the group received the most by breaking out the number of responses returned to the group by status code.

Database Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the clients might be sending more requests than servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests sent by this database client. Requests cover a range of operations: connection negotiations, session configuration, data definition language (DDL), data modification language (DML), or data reads (select).
Responses The number of responses received by this database client. Responses vary by the requested operation.
Errors The number of database request operations sent from this database client that failed. All database errors should be investigated.
Aborted Requests The number of requests that this database client began to send, but did not send completely.
Aborted Responses The number of responses that this database client began to receive, but did not receive completely when acting as a database client.
Server Processing Time
If a client group is acting slow, the server processing time can help you figure out whether the issue is with the servers. The Server Processing Time chart shows the median amount of time servers took to process requests from the clients. High server processing times indicate that the clients are contacting slow servers.
Metric Description
Database Client Server Processing Time The time it took for this database client to receive the first packet of a response after sending the last packet of the query.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

Database server group page

Database Summary for Group

Total Transactions
This chart shows you when database errors occurred and how many database responses the servers sent. This information can help you see how active the servers were at the time they returned the errors.

If you see a large number of errors, you can drill down to find the specific status code returned in the request and learn why the servers were unable to fulfill the requests. However, if the number of errors is low, the issue might be more complex, and you should examine the ratio of database requests to database responses. In a healthy environment, the number of requests and responses should be roughly equal. For more information, see the Metrics for Group section below.

Tip:To see more information about errors, click the Errors link at the top of the page.
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.
Total Transactions
This chart shows you how many database responses servers in the group sent and how many of those responses contained errors.
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.

Database Details for Group

Top Group Members (Database Servers)
This chart shows which database servers in the group were most active by breaking out the total number of database responses the group sent by server.
Top Methods
This chart shows which database methods were called on servers in the group the most by breaking out the total number of requests the group received by method.
Top Status Code
This chart shows which database status codes the groups returned the most by breaking out the total number of responses the group sent by status code.

Database Metrics for Group

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than the servers can handle or the network might be too slow.
Note:It is unlikely that the total number of requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Requests The number of requests received by all database instances on this server. Requests cover a range of operations: connection negotiations, session configuration, data definition language (DDL), data modification language (DML), or data reads (select).
Responses The number of responses by all database instances on this server. Responses vary by the requested operation. For example, a response can include connection and session configurations, success or failure notifications, or a tabular data set.
Errors The number of database request operations that failed on all database instances running on this server. All database errors should be investigated.
Aborted Requests The number of requests that this database server began to receive, but did not receive completely.
Aborted Responses The number of responses that this database server began to send, but did not send completely.
Server Processing Time
The Server Processing Time chart shows the median amount of time the servers took to process requests from clients. High server processing times indicate that the servers in a group are slow.
Server Processing Time The time it took for this database server to send the first packet of a response after receiving the last packet of the query.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

Database applications page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Application Toolbar
The Database application toolbar includes the following controls:
Errors
The chart displays the total count for DB errors. Mouse over the points to view a summary of a specific time or date. The table lists DB error messages and the number of occurrences.
Methods

The chart displays responses compared to processing time. Mouse over the points to view a five-number summary of processing time (minimum, lower quartile, median, upper quartile, and maximum values). The orange bars represent a confidence interval around the median value bounded by the 25th and 75th percentile values.

The table lists methods, number of responses, total time, and processing time (ms) associated with each method. Mouse over the orange bars to view the mean time, standard deviation, and count for each metric.

Users
The chart displays the number of responses and errors for all users. Mouse over the chart to view a summary of a specific time or date. The table displays the list of users, and the number of responses and errors associated with each user.
Clients

The chart displays the total number of responses compared to processing time. Mouse over the points to view a five-number summary of processing time (minimum, lower quartile, median, upper quartile, and maximum values). The orange bars represent a confidence interval around the median value bounded by the 25th and 75th percentile values.

The table lists client IP addresses, the host and device associated with each client, the number of responses from each client, and the total time and processing time for each client. Mouse over the orange bars to view the mean time, standard deviation, and count for each metric.

Servers

The chart displays the total number of responses compared to processing time. Mouse over the points to view a five-number summary of processing time (minimum, lower quartile, median, upper quartile, and maximum values). The orange bars represent a confidence interval around the median value bounded by the 25th and 75th percentile values.

The table lists server IP addresses, the host and device associated with each server, the number of responses from each server, and the total time and processing time for each server. Mouse over the orange bars to view the mean time, standard deviation, and count for each metric.

Application Details
Specifies the type of additional application information displayed. IP detail views display directly monitored IP addresses and IP addresses that appear via routed traffic. IP addresses that appear via routed traffic are preceded by the word via. Mousing over the counter next to each top-level metric opens a context menu that includes the following options in the drop-down list:
By Client IP
Displays application metrics by the client IP addresses.
By Server IP
Displays application metrics by the server IP addresses.

For example, Request Bytes is a top-level metric showing how many request bytes were transmitted in and out of the application within the selected time interval. Select By Client IP in the drop-down list while mousing over the Request Bytes counter to view which client IP addresses originated these requests.

L2-L4 Metrics
Contains the following metrics:
Request L2 Bytes
The number of L2 bytes associated with database requests.
Response L2 Bytes
The number of L2 bytes associated with database responses.
Request Packets
The number of packets associated with database requests.
Response Packets
The number of packets associated with database responses.
Request RTOs
The number of retransmission timeouts caused by congestion when clients were sending database requests. A retransmission timeout is a one-second stall in the TCP connection flow due to excessive retransmissions.
Response RTOs
The number of retransmission timeouts caused by congestion when servers were sending database responses. A retransmission timeout is a one-second stall in the TCP connection flow due to excessive retransmissions.
Request Zero Window
The number of zero window advertisements sent by database clients. A device advertises a zero window when it cannot process incoming data as quickly as it is arriving.
Response Zero Window
The number of zero window advertisements sent by servers while receiving database requests. A device advertises a zero window when it cannot process incoming data as quickly as it is arriving.
DB Metrics
Contains the following metrics:
Requests
The number of database requests.
Responses
The number of database responses.
Response Errors
The number of database response errors.
Transaction Metrics
Transaction metrics display the timing components for all transactions associated with the current device. Timing components are expressed as a confidence interval around the median value bounded by the 25th and 75th percentile values. Mouse over each component to display a five-number statistical summary.
ReqXfer
Request transfer time. The time in milliseconds before the request was received by the server. A large ReqXfer value relative to the total transaction time indicates network delay. If the request size is large, some network delay due to transfer time is expected.
Process
Server processing time. The time in milliseconds between the time the request was received by the server and the time the response was sent. A large server processing time indicates application delay.
RspXfer
Response transfer time. The time in milliseconds before the server finished sending the response. A large RspXfer relative to the total transaction time indicates network delay. If the response size is large, some network delay due to transfer time is expected.
RTT
TCP round-trip time in milliseconds. Large round-trip time indicates that network latency is high.

Click the Transaction Metrics graph to display a chart showing responses compared to mean processing time during the selected time interval. The table below contains the total and mean time for each response.

Transactions Per Second
Displays the number of protocol transactions per second as a function of time over the selected time interval. The chart is annotated with red data points to indicate errors. The volume of errors is denoted by the height of red bars under the chart. Click the red dot to see the number of errors that occurred at that time. Click and drag across the chart to select a particular region.
Response Time Breakdown
Displays the area chart containing median round-trip time, request transfer time, server processing time, and response transfer time over time in milliseconds. Click and drag across the chart to select a particular region.
Round-Trip Time (ms)
Displays the median round-trip time (RTT) in milliseconds (ms) from the current objects to clients as a function of time over the selected time interval. Vertical dotted lines indicate the upper and lower quartiles (75th and 25th percentiles) of the round-trip time metrics. Click and drag across the chart to select a particular region.
Congestion Requests: Goodput (bps) and RTOs
Displays goodput and RTOs into the object as a function of time over the selected time interval.
Congestion Responses: Goodput (bps) and RTOs
Displays goodput and RTOs out of the object as a function of time over the selected time interval.

Goodput is application-level throughput (the number of useful information bits) and RTOs are retransmission timeouts. The Congestion In and Out graphs show the relationship over time between the rate of good application throughput and RTOs. An increase in RTOs theoretically leads to a decrease in goodput due to TCP back-off and packet retransmissions. It is best to view these charts in a smaller window of time so the metrics taken over time are not rolled up or smoothed out. In a small timeframe (30 minutes or less), one could see a decrease in goodput associated with a large number of RTOs, assuming that most flows on the server during this time frame experience this behavior. If only one or two flows are affected by RTOs, then the decreased goodput correlation might be masked by superficially healthy flows.

Database devices page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Devices Toolbar
The Database device toolbar includes the following controls:
Database Metric Type
Displays statistics for the current device acting as a database client or database server.
Errors
Displays the list of error messages sent to or received by the current device over the time interval.
Methods
Displays the list of names and the associated number of responses and errors.
Users
Displays the list of users accessing the database server and associated bytes sent and received for the selected time interval.
Clients or Servers
Displays the associated client IP addresses when the device is acting as a server, and the associated server IP addresses when acting as a client.

Click the counters next to individual database metrics to show the IP Address Database Metrics for database peer devices. For database servers, the peer devices are database clients. For database clients, the peer devices are database servers.

Device Details
Click the counters next to individual database metrics to show the IP Address Database Metrics for database peer devices. For database servers, the peer devices are database clients. For database clients, the peer devices are database servers.
By IP
Displays database metrics by IP address.
By Database
Displays database metrics by database. For local peer devices, the link leads to that device. For remote peer devices, the link leads to the gateway device through which the requests were routed.
Database Client
If you select Client for the Database Metric Type, the Discover appliance displays the following metrics:
Responses
Specifies the number of responses that the device received when acting as a database client. Click to display the list of servers from which responses were sent.
Errors
Specifies the number of database protocol errors for the selected time interval. Click to display the list of servers for which there were errors.
Requests Aborted
Specifies the number of requests that the device began to send but did not send completely when acting as a database client.
Responses Aborted
Specifies the number of responses that the device began to receive but did not receive completely when acting as a database client.
Database Server
If you select Server for the Database Metric Type, the Discover appliance displays the following metrics:
Responses
Specifies the number of responses that the device sent when acting as a database server. Click to display the list of clients to which responses were sent.
Errors
Specifies the number of database protocol errors for the selected time interval. Click to display the list of clients for which there were errors.
Requests Aborted
Specifies the number of requests that the device began to receive but did not receive completely when acting as a database server.
Responses Aborted
Specifies the number of responses that the device began to send but did not send completely when acting as a database server.
Methods
Displays the database methods for the selected time interval. Methods will vary for each specific device.
Transaction Metrics
Displays the timing components for all transactions associated with the current device. Timing components are expressed as a confidence interval around the median value bounded by the 25th and 75th percentile values. Move the mouse pointer over each component to display a five-number statistical summary.
ReqXfer
The request transfer time in milliseconds before the request was received by the server. A large ReqXfer value relative to the total transaction time indicates network delay. If the request size is large, some network delay due to transfer time is expected.
Process
The server processing time in milliseconds between the time the request was received by the server and the time the response was sent. A large server processing time indicates application delay.
RspXfer
The response transfer time in milliseconds before the server finished sending the response. A large RspXfer relative to the total transaction time indicates network delay. If the response size is large, some network delay due to transfer time is expected.
Request Size
Displays the range of request sizes for all transactions associated with the current device. Mouse over the chart to see the five-number summary. The five-number summary includes the minimum, lower quartile, median, upper quartile, and maximum values. Click to display the mean request size for each peer device, database, or IP address.
Response Size
Displays the range of response sizes for all transactions associated with the current device. Mouse over the chart to see the five-number summary. The five-number summary includes the minimum, lower quartile, median, upper quartile, and maximum values. Click to display the mean response size for each peer device, database, or IP address.
Transactions Per Second
Displays the number of database protocol transactions per second as a function of time over the selected time interval. The chart is annotated with red data points to indicate errors. The volume of errors is denoted by the height of red bars under the chart. Click the red data points to list the peer devices associated with the errors at this point in time. Click and drag across the chart to select a particular region. Select a database from the Databases drop-down list and then click the red data points to display results associated with that database only. For detailed error information, click Errors.
Response Time Breakdown
Displays the area chart containing median request transfer time, server processing time, and response transfer time over time in milliseconds. Click and drag across the chart to select a particular region.

Database devices timing page

The timing charts draw data from the Time Selector drop-down list on the navigation toolbar. The events observed during this interval are used to fill the bins of a histogram that displays a distribution of timing data. Timing charts use a logarithmic horizontal axis that simultaneously displays events that took milliseconds and those that took seconds.

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Request Transfer Time
Displays a histogram of times it took to transfer requests from the client to the server. Mouse over each bar to display the time range it represents and the number of requests in this bin.
Processing Time
Displays a histogram of times it took the server to process requests. Mouse over each bar to display the time range it represents and the number of requests in this bin.
Response Transfer Time
Displays a histogram of times it took to transfer the response from the server to the client. Mouse over each bar to display the time range it represents and the number of requests in this bin.

Database devices all methods page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Devices Toolbar
The Database devices toolbar includes the following controls:
Database Metric Type
Displays metrics for the current devices acting as a database client or server, respectively.
Records
Displays results for records that match the selected metric source and protocol.
Methods
This section displays the database methods for the selected time interval. Click to display additional per-client or per-server details.

Database groups page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Groups Toolbar
The Database groups toolbar includes the following controls:
Database Metric Type
Displays metrics for members in the current group acting as a database client or server, respectively.
Errors
Displays the list of error messages sent to or received by members in the current group over the time interval.
Methods
Displays the list of names and the associated processing times for the stored procedures executed within the databases belonging to the current group during the selected time interval.
Users
Displays the list of users accessing the database servers in this group and associated bytes sent and received for the selected time interval.
Database Client
If you select Client for the Database Metric Type, the Discover appliance displays the following metrics. Click the counter to break down the responses by group members in the table at the bottom of the page.
Responses
Specifies the number of database protocol responses received by all members of the current group during the selected time interval.
Errors
Specifies the number of database protocol errors received by all members of the current group during the selected time interval.
Requests Aborted
Specifies the number of requests that members of the group began to send but did not send completely when acting as a database client.
Responses Aborted
Specifies the number of responses that members of the group began to receive but did not receive completely when acting as a database client.
Database Server
If you select Server for the Database Metric Type, the Discover appliance displays the following metrics. Click the counter to break down the responses by group members in the table at the bottom of the page.
Responses
Specifies the number of database protocol responses sent by all members of the current group during the selected time interval.
Errors
Specifies the number of database protocol errors sent by all members of the current group during the selected time interval.
Requests Aborted
Specifies the number of requests that members of the group began to receive but did not receive completely when acting as a database server.
Responses Aborted
Specifies the number of responses that members of the group began to send but did not send completely when acting as a database server.
Methods
Displays the database methods for the selected time interval.

Database groups all methods page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Groups Toolbar
The Database groups toolbar includes the following controls:
Database Metric Type
Displays metrics for members in the current group acting as a database client or server, respectively.
Records
Displays results for records that match the selected metric source and protocol.
Methods
This section displays the database methods for the selected time interval. Click to display additional per-client or per-server details.
Database Client
This table lists the peer members associated with the database client.
Database Server
This table lists the peer members associated with the database server.

Database groups processing time page

Note:This help topic describes a page in the ExtraHop Web UI that is available only when switched to the deprecated page layout.
Database Groups Toolbar
The Database groups toolbar includes the following controls:
Database Metric Type
Displays metrics for members in the current group acting as a database client or server, respectively.
Records
Displays results for records that match the selected metric source and protocol.
Server Processing Time
Shows median server processing time over the selected time interval for each member in the group. The five-number summary, which includes the minimum, lower quartile, median, upper quartile, and maximum values, is displayed by hovering over a bar.

DHCP

ExtraHop appliances collect metrics about Dynamic Host Configuration Protocol (DHCP) activity.

DHCP application page

DHCP Summary

Transactions
This chart shows you when DHCP errors and responses were associated with the application. This information can help you see how active the application was at the time the errors occurred.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of DHCP responses.
Errors The number of DHCP response errors.
Total Transactions
This chart displays the total number of DHCP responses that were associated with the application and how many of those responses contained errors.
Metric Description
Responses The number of DHCP responses.
Errors The number of DHCP response errors.
Server Processing Time
This chart shows DHCP server processing times broken out by percentile. Server processing time shows how long servers took to process requests from clients. Server processing time is calculated by measuring the time between when the last packet of a request and the first packet of a response is seen by the ExtraHop system.
Metric Description
DHCP Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Server Processing Time Summary
Shows the 95th percentile for server processing time.
Metric Description
DHCP Server Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

The Server Processing Time Summary chart focuses on the 95th percentile to show the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. The following chart shows how displaying the 95th value, rather than the true maximum, can give a more accurate view of the data:

DHCP Details

Top Request Message Types
This chart shows which DHCP message types the application sent the most by breaking out the total number of requests the application sent by message type.
Top Response Message Types
This chart shows which DHCP message types the application received the most by breaking out the total number of responses the application received by message type.

DHCP Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
DHCP Server Processing Time The time between the ExtraHop system detecting the last packet of DHCP requests and the first packet of their corresponding responses.
Server Processing Time
This chart shows the median processing time for the application.
Metric Description
DHCP Server Processing Time The time between the ExtraHop system detecting the last packet of DHCP requests and the first packet of their corresponding responses.

DHCP Metric Totals

Total Requests and Responses

Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, clients might be sending more requests than servers can handle or the network might be too slow.

Note:It is unlikely that the total number of database requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of DHCP requests.
Responses The number of DHCP responses.
Errors The number of DHCP response errors.
DHCP Network Metrics
Metric Description
Request L2 Bytes The number of L2 bytes associated with DHCP requests.
Response L2 Bytes The number of L2 bytes associated with DHCP responses.
Request Packets The number of packets associated with DHCP requests.
Response Packets The number of packets associated with DHCP responses.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can create a custom metric through a trigger. For more information, see the following resources:

Check the Solution Bundles Gallery: Many bundles on the Solution Bundles Gallery contain custom metrics. Before you create your own custom metric, check to see if someone has already created a similar metric.

DHCP client page

DHCP Summary

Transactions
This chart shows you when DHCP errors occurred and how many responses the DHCP client received. This information can help you see how active the client was at the time it received the errors.

In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.

Metric Description
Responses The number of responses that the device received when acting as a DHCP client.
Errors When the device is acting as a DHCP client, the number of responses received with an error option.
Total Transactions
This chart displays the total number of DHCP responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses that the device received when acting as a DHCP client.
Errors When the device is acting as a DHCP client, the number of responses received with an error option.
Server Processing Time
This chart shows DHCP server processing times broken out by percentile. Server processing time shows how long servers took to process requests from the client. Server processing time is calculated by measuring the time between when the last packet of a request and the first packet of a response is seen by the ExtraHop system.
Metric Description
DHCP Client Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Server Processing Time
Shows the 95th percentile for server processing time.
Metric Description
DHCP Server Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

The Server Processing Time Summary chart focuses on the 95th percentile to show the highest value for a time period while filtering outliers; the 95th percentile is the highest value that falls below 95% of the values for a sample period. The following chart shows how displaying the 95th value, rather than the true maximum, can give a more accurate view of the data:

DHCP Details

Top Request Message Types
This chart shows which DHCP message types the client sent the most by breaking out the total number of requests the client sent by message type.
Top Response Message Types
This chart shows which DHCP message types the client received the most by breaking out the total number of responses the client received by message type.

DHCP Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
DHCP Client Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
Server Processing Time
This chart shows the median server processing time.
Metric Description
DHCP Client Server Processing Time When the device is acting as a DHCP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.

DHCP Metric Totals

Total Requests and Responses
Requests and responses represent the conversation taking place between clients and servers. If there are more requests than responses, the client might be sending more requests than the servers can handle or the network might be too slow.
Note:It is unlikely that the total number of DHCP requests and responses will be exactly equal, even in a healthy environment. For example, you might be viewing a time period that captures a response to a request that was sent before the start of the time period. In general, the greater the difference between responses and errors, the greater the chance that there is an issue with those transactions.
Metric Description
Requests The number of requests sent by this DHCP client.
Responses The number of responses that the device received when acting as a DHCP client.
Errors When the device is acting as a DHCP client, the number of responses received with an error option.

Where to look next

Drill down on a metric: You can get more information about a metric by clicking the metric value or name and selecting an option from the Drill down by menu. For example, if you are looking at the total number of errors, click the number and select Servers to see which servers returned the errors.

Search the Metric Explorer: Built-in protocol pages include the most commonly referenced metrics for a protocol, but you can see additional metrics in the Metric Explorer. Click any chart title on a protocol page and select Create chart from.... When the Metric Explorer opens, click Add Metric in the left pane to display a drop-down list of comprehensive metrics for the device. If you find an interesting metric, click Add to Dashboard to add the metric to a new or existing dashboard.

Create a custom metric: If you want to view a metric that is not included in the Metric Explorer, you can crea