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.

AAA 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 incoming data is arriving too quickly to be processed.

A large number of incoming Zero Windows 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 incoming data is arriving too quickly to be processed.

A large number of outgoing Zero Windows 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of incoming RTOs, 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of outgoing RTOs, 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of incoming RTOs, 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of outgoing RTOs, 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 incoming data is arriving too quickly to be processed.
Response Zero Windows The number of zero window advertisements sent by servers while receiving AAA requests. A device advertises a Zero Window when incoming data is arriving too quickly to be processed.
Request RTOs The number of retransmission timeouts caused by congestion when clients were sending AAA requests. An RTO is a 1-5 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. An RTO is a 1-5 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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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.

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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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.

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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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.

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.

For more information about dashboards, see Dashboards.

For more information about records, see Records.

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 incoming data is arriving too quickly to be processed.

A large number of incoming Zero Windows 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 incoming data is arriving too quickly to be processed.

A large number of outgoing Zero Windows 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of incoming RTOs, 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 1-5 second stall in the TCP connection flow due to excessive retransmissions.

If you see a large number of outgoing RTOs, 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.
Database Network Metrics
Metric Description
Request Zero Windows The number of zero window advertisements sent by database clients. A device advertises a Zero Window when incoming data is arriving too quickly to be processed.
Response Zero Windows The number of zero window advertisements sent by servers while receiving database requests. A device advertises a Zero Window when incoming data is arriving too quickly to be processed.
Request RTOs The number of retransmission timeouts caused by congestion when clients were sending database requests. An RTO is a 1-5 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. An RTO is a 1-5 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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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 before the connection abruptly closed. This client was unable to send the complete request because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
Aborted Responses The number of responses that this database client began to receive before the connection abruptly closed. This client was unable to receive the complete response because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
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 incoming data is arriving too quickly to be processed.

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 incoming data is arriving too quickly to be processed.

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 1-5 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 1-5 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 this database server began to receive before the connection abruptly closed. This server was unable to receive the complete request because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
Aborted Responses The number of responses this database server began to send before the connection abruptly closed. This server was unable to send the complete response because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
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 before the connection abruptly closed. This client was unable to send the complete request because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
Aborted Responses The number of responses that this database client began to receive before the connection abruptly closed. This client was unable to receive the complete response because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
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 this database server began to receive before the connection abruptly closed. This server was unable to receive the complete request because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
Aborted Responses The number of responses this database server began to send before the connection abruptly closed. This server was unable to send the complete response because the connection timed out or the connection was closed with a TCP reset (RST) or FIN.
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.

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 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 server page

DHCP Summary

Transactions
This chart shows you when DHCP errors occurred and how many DHCP 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.

Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent with an error option.
Total Transactions
This chart displays the total number of DHCP responses the server sent and how many of those responses contained errors.
Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent with an error option.
Server Processing Time
This chart shows DHCP server processing times broken out by percentile. Server processing time shows how long the server 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 Server Processing Time When the device is acting as a DHCP 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
Shows the 95th percentile for server processing time.
Metric Description
DHCP Server Server Processing Time When the device is acting as a DHCP server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent 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 server received the most by breaking out the total number of requests the server received by message type.
Top Response Message Types
This chart shows which DHCP message types the server sent the most by breaking out the total number of responses the server sent 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 Server Processing Time When the device is acting as a DHCP 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 server processing time.
Metric Description
DHCP Server Server Processing Time When the device is acting as a DHCP server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent 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, clients might be sending more requests than the server 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 that the device received when acting as a DHCP server.
Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent 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 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 group page

DHCP Summary for Group

Total Transactions
This chart shows you when DHCP errors occurred and how many responses the DHCP 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 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 shows you how many DHCP 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 a DHCP client.
Errors When the device is acting as a DHCP client, the number of responses received with an error option.

DHCP Details for Group

Top Group Members (DHCP Clients)
This chart shows which DHCP clients in the group were most active by breaking out the total number of DHCP requests the group sent by client.
Top Request Message Types
This chart shows which DHCP message types the group sent the most by breaking out the total number of requests the group sent by message type.
Top Response Message Types
This chart shows which DHCP message types the group received the most by breaking out the total number of responses the group received by message type.

DHCP 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 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.
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
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.

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 server group page

DHCP Summary for Group

Transactions
This chart shows you when DHCP errors occurred and how many DHCP 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.

Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent with an error option.
Total Transactions
This chart shows you how many DHCP responses the clients received and how many of those responses contained errors.
Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent with an error option.

DHCP Details for Group

Top Group Members (DHCP Servers)
This chart shows which DHCP servers in the group were most active by breaking out the total number of DHCP responses the group sent by server.
Top Request Message Types
This chart shows which DHCP message types the server received the most by breaking out the total number of requests the server received by message type.
Top Response Message Types
This chart shows which DHCP message types the server sent the most by breaking out the total number of responses servers in the group sent by message type.

DHCP 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 a DHCP server.
Responses The number of responses that the device sent when acting as a DHCP server.
Errors When the device is acting as a DHCP server, the number of responses sent with an error option.
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
DHCP Server Server Processing Time When the device is acting as a DHCP 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.

DICOM

ExtraHop appliances collect metrics about Digital Imaging and Communications in Medicine (DICOM) activity.

Note:ExtraHop appliances do not include any built-in metric pages for DICOM. However, you can view DICOM metrics by adding them to a custom page or dashboard.

DNS

ExtraHop appliances collect metrics about Domain Name System (DNS) activity.

Learn more by taking the DNS Quick Peek training.

DNS application page

Learn about charts on this page

DNS Summary

Transactions
This chart shows you when DNS 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 DNS responses associated with this application.
Errors The number of DNS responses with errors that are associated with this application.
Total Transactions
This chart displays the total number of DNS responses that were associated with the application and how many of those responses contained errors.
Metric Description
Responses The number of DNS responses associated with this application.
Errors The number of DNS responses with errors that are associated with this application.
Requests and Timeouts
This chart shows you when DNS requests and request timeouts occurred.
Metric Description
Requests The number of DNS requests associated with this application.
Request Timeouts The number of timeouts that occurred due to a repeated unanswered DNS query sent by clients to DNS servers. DNS timeouts can cause slowdowns and disruptions.
Total Requests and Timeouts
This chart shows you the total number of DNS requests and request timeouts.
Metric Description
Requests The number of DNS requests associated with this application.
Request Timeouts The number of timeouts that occurred due to a repeated unanswered DNS query sent by clients to DNS servers. DNS timeouts can cause slowdowns and disruptions.
Server Processing Time
This chart shows DNS 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
DNS Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.

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:

Server Processing Time Summary
Shows the 95th percentile for server processing time.
Metric Description
DNS Server Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.

DNS Details

Top Opcodes
This chart shows which DNS opcodes the application received the most by breaking out the number of responses returned to the application by opcode.
Top Host Queries
This chart shows which host queries the application made the most by breaking out the total number of requests the application sent by host query.
Top Response Codes
This chart shows which response codes the application received the most by breaking out the number of responses returned to the application by response code.

DNS Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
DNS Server Processing Time The time it took for DNS servers to send the first packet of a response after receiving the last packet of a request.
Server Processing Time
This chart shows the median processing time for the application.
Metric Description
DNS Server Processing Time The time it took for DNS servers to send the first packet of a response after receiving the last packet of a request.

DNS 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 DNS requests associated with this application.
Responses The number of DNS responses associated with this application.
Errors The number of DNS responses with errors that are associated with this application.
Request Timeouts The number of timeouts that occurred due to a repeated unanswered DNS query sent by clients to DNS servers. DNS timeouts can cause slowdowns and disruptions.
Truncated Requests The number of DNS requests that were sent but were truncated in transit. A truncated request is indicated by the truncated bit in the message and occurs when the message is larger than the underlying transmission channel allows.
Truncated Responses The number of DNS responses that were sent but were truncated in transit. A truncated request is indicated by the truncated bit in the message and occurs when the message is larger than the underlying transmission channel allows.
DNS Network Metrics
Metric Description
Request L2 Bytes The number of L2 bytes associated with DNS requests.
Response L2 Bytes The number of L2 bytes associated with DNS responses.
Request Packets The number of packets associated with DNS requests.
Response Packets The number of packets associated with DNS 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.

DNS client page

Learn about charts on this page

DNS Summary

Transactions
This chart shows you when DNS errors occurred. The chart also shows you how many DNS responses the client received so that you can 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.

Responses The number of responses received by this DNS client.
Errors The number of times this DNS client received error codes in response to a query.
Total Transactions
This chart displays the total number of DNS responses the client received and how many of those responses contained errors.
Metric Description
Responses The number of responses received by this DNS client.
Errors The number of times this DNS client received error codes in response to a query.
Requests and Timeouts
This chart shows you when request timeouts occurred. The chart also shows you how many DNS requests the client sent so that you can see how active the client was at the time the timeouts occurred.
Requests The number of requests sent by this DNS client.
Request Timeouts The number of timeouts that occurred due to a repeated unanswered DNS query request sent from this client to DNS servers. DNS request timeouts can cause slowdowns and disruptions.
Total Requests and Timeouts
This chart shows you the total number of requests and request timeouts.
Requests The number of requests sent by this DNS client.
Request Timeouts The number of timeouts that occurred due to a repeated unanswered DNS query request sent from this client to DNS servers. DNS request timeouts can cause slowdowns and disruptions.
Server Processing Time
This chart shows DNS 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
DNS Client Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.

The Server Processing Time 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:

Server Processing Time Summary
Shows the 95th percentile for server processing time.
Metric Description
DNS Client Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.

DNS Details

Top Record Types
This chart shows which record types the client requested the most by breaking out the total number of requests the client sent by record type.
Top Host Queries
This chart shows which host queries the client made the most by breaking out the total number of requests the client sent by host query.
Top Response Codes
This chart shows which response codes the client received the most by breaking out the number of responses returned to the client by response code.

DNS Performance

Server Processing Time Distribution
This chart breaks out server processing times in a histogram to show the most common processing times.
Metric Description
DNS Client Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.
Server Processing Time
This chart shows the median server processing time.
Metric Description
DNS Client Server Processing Time The time it took for this DNS client to receive the first response packet after sending a query request. A lengthy processing time can indicate latency.

DNS 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 DNS 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 DNS client.
Responses