Protocol Metrics Reference
This guide provides definitions for all of the built-in metric charts in the ExtraHop system. Charts are available by protocol, by asset, and in system dashboards.
Metrics are real-time measurements of your network behavior that the ExtraHop system calculates from wire or flow data. The ExtraHop system can analyze and classify over 5,000 metrics from network traffic, and then associate the metrics with a source—the assets on your network, such as applications, devices, activity groups, or networks.
Working with metrics
Here are some ways you can work with metrics:
- Select an asset as a metric source throughout the ExtraHop system when creating dashboard charts, configuring alerts, or building triggers.
- View metrics and access protocol pages from a Device Overview page.
- View metrics in the system Security, Network, and Activity dashboards.
- Drill down from top-level metrics to view detail metrics pages, which provide a list of metric values for a specific key (such as a client or server IP address). 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.
- Add additional sources or metrics to a chart.
- View all built-in and custom metrics available in the Metric Catalog.
- Create a custom metric to collect data that is not included a built-in metric.
- Export chart data to Excel or CSV.
- Create a PDF of a dashboard or chart.
- Create a chart
- Create an activity map.
- Search for devices by protocol activity.
- Find detections.
Types of metrics
Each metric in the ExtraHop system is classified into a metric type. Understanding the distinctions between metric types can help you configure charts or write triggers to capture custom metrics. For example, a heatmap chart can only display dataset metrics.
- Count
- The number of events that occurred over a specific time period. You can view count metrics as a rate or a total count. For example, a byte is recorded as a count, and can either represent a throughput rate (as seen in a time series chart) or total traffic volume (as seen in a table). Rates are helpful for comparing counts over different time periods. A count metric can be calculated as a per-second average over time. When viewing high-precision, or 1-second, bytes and packet metrics, you can also view a maximum rate and minimum rate. Count metrics include errors, packets, and responses.
- Count rate
-
The number of events that occurred over a specific time period. Count rate metrics and count metrics are calculated the same way. However, count rate metrics capture additional details that enable you to view the maximum and minimum rate for an interval. Count rate metrics include bytes and packets.
- Distinct count
-
The number of unique events that occurred during a selected time interval. The distinct count metric provides an estimate of the number of unique items placed into a set during the selected time interval. Estimates are calculated with the HyperLogLog algorithm.
- Dataset
- A distribution of data that can be calculated into percentile values. Dataset metrics include processing time and round trip time.
- Maximum
- A single data point that represents the maximum value from a specified time period.
- Sampleset
- A summary of data about a detail metric. Selecting a sampleset metric in a chart enables you to display a mean (average) and standard deviation over a specified time period.
- Snapshot
- A data point that represents a single point in time.
Metrics by protocol
Each protocol page includes built-in charts with top-level metrics about your assets. These metric charts can be copied to your dashboards.
AAA
The ExtraHop system collects metrics about Authentication, Authorization, and Accounting (AAA) protocol activity. AAA is a security framework that includes application-level network access protocols such as RADIUS, Diameter, TACACS, and TACACS+.
AAA application page
This page displays metric charts of AAA traffic associated with an application container on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AAA Summary
The following charts are available in this region:
- 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 acknowledgment 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 acknowledgment 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 the last packet of an AAA request. A high number might indicate a large request or network delay. Server Processing Time The time between the ExtraHop system detecting the last packet of an AAA request and the first packet of the corresponding response. Response Transfer Time The time between the ExtraHop system detecting the first packet and the last packet of an AAA response. A high value might indicate a large response or network delay. Round Trip Time The time between when an AAA client or server sent a packet that required 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 an AAA request and the first packet of the corresponding response. Round Trip Time The time between when an AAA client or server sent a packet that required immediate acknowledgment and when the acknowledgment was received.
AAA Details
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 an AAA request and the first packet of the corresponding response. - 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 an AAA request and the first packet of the corresponding 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 or server sent a packet that required 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 that required immediate acknowledgment and when the acknowledgment was received.
AAA Network Data
This region 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 that were 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 acknowledgment 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 acknowledgment 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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 that were sent. Responses The number of AAA responses. Errors The number of AAA response errors. Diameter Request The number of Diameter requests that were sent. Diameter is an updated version of the RADIUS AAA protocol. RADIUS Request The number of RADIUS (Remote Authentication Dial-In User Service) requests that were sent. Aborts The number of AAA protocol sessions that were aborted. - AAA Network Metrics
-
Metric Description Request Zero Windows The number of zero window advertisements that were 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 sent that were associated with AAA requests. Response L2 Bytes The number of L2 bytes sent that were 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 sent that were associated with AAA requests. Response Packets The number of packets sent that were associated with AAA responses.
AAA client page
This page displays metric charts of AAA client traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AAA Summary
The following charts are available in this region:
- 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 AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was 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 AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was 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 acknowledgment 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 acknowledgment 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 The time between the ExtraHop system detecting the last packet of a sent AAA request and the first packet of the corresponding response when the device was acting as an AAA client. Round Trip Time The time between when an AAA client sent a packet that required immediate acknowledgment and when the acknowledgment was received. 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 The time between the ExtraHop system detecting the last packet of a sent AAA request and the first packet of the corresponding response when the device was acting as an AAA client. Round Trip Time The time between when an AAA client sent a packet that required immediate acknowledgment and when the acknowledgment was received. Round trip time (RTT) is a measurement of network latency.
AAA Details
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 The time between the ExtraHop system detecting the last packet of a sent AAA request and the first packet of the corresponding response when the device was acting as an AAA client. - Server Processing Time
-
This
chart shows the median processing time for the client.
Metric Description AAA Client Server Processing Time The time between the ExtraHop system detecting the last packet of a sent AAA request and the first packet of the corresponding response when the device was acting as an AAA client. - 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 immediate acknowledgment and when the acknowledgment was received. 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 immediate acknowledgment and when the acknowledgment was received. Round trip time (RTT) is a measurement of network latency.
Network Data
This region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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 AAA requests that were sent when the device was acting as an AAA client. Responses The number of AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was acting as an AAA client. Diameter Request The number of Diameter requests that were sent when the device was acting as an AAA client. Diameter is an updated version of the RADIUS AAA protocol. RADIUS Request The number of RADIUS (Remote Authentication Dial-In User Service) requests that were sent when the device was acting as an AAA client. . Aborts The number of aborted sessions that occurred when the device was acting as an AAA client.
AAA server page
This page displays metric charts of AAA server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AAA Summary
The following charts are available in this region:
- 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 AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was 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 AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was 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 acknowledgment 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 acknowledgment 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 The time between the ExtraHop system detecting the last packet of a received AAA request and the first packet of the corresponding response when the device was acting as an AAA server. Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the acknowledgment was received. 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 The time between the ExtraHop system detecting the last packet of a received AAA request and the first packet of the corresponding response when the device was acting as an AAA server. Round Trip Time The time between when an AAA server sent a packet that required an immediate acknowledgment and when the acknowledgment was received. Round trip time (RTT) is a measurement of network latency.
AAA Details
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 The time between the ExtraHop system detecting the last packet of a received AAA request and the first packet of the corresponding response when the device was acting as an AAA server. - Server Processing Time
-
This
chart shows the median processing time for the server.
Metric Description AAA Server Server Processing Time The time between the ExtraHop system detecting the last packet of a received AAA request and the first packet of the corresponding response when the device was acting as an AAA server. - 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 acknowledgment was received. 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 acknowledgment was received. Round trip time (RTT) is a measurement of network latency.
Network Data
This region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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 AAA requests that were received when the device was acting as an AAA server. Responses The number of AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was acting as an AAA server. Diameter Request The number of Diameter requests that were received when the device was acting as an AAA server. Diameter is an updated version of the RADIUS AAA protocol. 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 was acting as an AAA server.
AAA client group page
This page displays metric charts of AAA client traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AAA Summary for Group
The following charts are available in this region:
- 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 AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was 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 AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was acting as an AAA client.
AAA Details for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 AAA requests that were sent when the device was acting as an AAA client. Responses The number of AAA responses that were received when the device was acting as an AAA client. Errors The number of AAA response errors that were received when the device was acting as an AAA client. Diameter Request The number of Diameter requests that were sent when the device was acting as an AAA client. Diameter is an updated version of the RADIUS AAA protocol. RADIUS Request The number of RADIUS (Remote Authentication Dial-In User Service) requests that were sent when the device was acting as an AAA client. . Aborts The number of aborted sessions that occurred when the device was 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 The time between the ExtraHop system detecting the last packet of a sent AAA request and the first packet of the corresponding response when the device was acting as an AAA client.
AAA server group page
This page displays metric charts of AAA server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AAA Summary for Group
The following charts are available in this region:
- 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 AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was 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 AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was acting as an AAA server.
AAA Details for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 AAA requests that were received when the device was acting as an AAA server. Responses The number of AAA responses that were sent when the device was acting as an AAA server. Errors The number of AAA response errors that were sent when the device was acting as an AAA server. Diameter Request The number of Diameter requests that were received when the device was acting as an AAA server. Diameter is an updated version of the RADIUS AAA protocol. 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 was 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 The time between the ExtraHop system detecting the last packet of a received AAA request and the first packet of the corresponding response when the device was acting as an AAA server.
AJP
The ExtraHop system collects metrics about Apache JServ Protocol (AJP) activity. AJP is a binary format for communication between an Apache web server and an application server.
| Note: | The ExtraHop system does not include any built-in metric pages for AJP. However, you can view AJP metrics by adding them to a custom page or dashboard. |
AMF
The ExtraHop system collects metrics about Action Message Format (AMF) protocol activity. AMF is a format for encoding data transported between Adobe Flash clients and servers over HTTP requests and responses.
AMF client page
This page displays metric charts of AMF traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AMF Summary
The following charts are available in this region:
- 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 acknowledgment 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 acknowledgment 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 number might 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. A high number might 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
The following charts are available in this region:
- 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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.
AMF server page
This page displays metric charts of AMF traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AMF Summary
The following charts are available in this region:
- 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 acknowledgment 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 acknowledgment 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 number might 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. A high number might 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
The following charts are available in this region:
- 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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.
AMF client group page
This page displays metric charts of AMF traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AMF Summary for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
AMF server group page
This page displays metric charts of AMF traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
AMF Summary for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
CIFS
The ExtraHop system collects metrics about Common Internet File System (CIFS)/Server Message Block (SMB) activity. CIFS is an application-level protocol that provides client access to files on a network attached storage (NAS) repository, typically in a Windows environment. The ExtraHop system supports 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. |
Security considerations
- SMB/CIFS authentication can be vulnerable to brute force, which is a method for guessing credentials by submitting numerous authentication requests with different username and password combinations.
- Deprecated SMB dialects, such asSMBv1, have known vulnerabilities. Well-known ransomware malware, such as WannaCry, exploited SMBv1 vulnerabilities.
- SMB/CIFS can be vulnerable to ransomware malware, which performs thousands of reads and writes over SMB/CIFS to encrypt files that are stored on file servers across the network.
- SMB/CIFS is a remote service protocol that an attacker can leverage to interact with remote devices and laterally move across the network.
CIFS client page
This page displays metric charts of CIFS client traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about CIFS security considerations
- Learn about working with metrics.
CIFS Summary
The following charts are available in this region:
- Transactions
- This chart shows you when SMB / CIFS errors occurred and how many responses the SMB /
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 SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - Total Transactions
- This chart displays the total number of SMB / CIFS responses the client received and
how many of those responses contained errors.
Metric Description Responses The number of responses received by this SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - Operations
- This chart shows you when the SMB / CIFS client performed read, write, and file system
information request operations.
Metric Description Reads The number of read operation requests sent by this SMB / CIFS client. Writes The number of write operation requests sent by this SMB / CIFS client. Creates The number of create operation requests sent by this SMB / CIFS client. Deletes The number of delete operation requests sent by this SMB / CIFS client. - Total Operations
- This chart shows you how many read and write operations the SMB / CIFS client
performed.
Metric Description Reads The number of read operation requests sent by this SMB / CIFS client. Writes The number of write operation requests sent by this SMB / CIFS client. Creates The number of create operation requests sent by this SMB / CIFS client. Deletes The number of delete operation requests sent by this SMB / 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 acknowledgment 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 acknowledgment 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 SMB / CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this SMB / 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. SMB / CIFS Client Round Trip Time The time between when an SMB / CIFS 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 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 SMB / CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this SMB / 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. SMB / CIFS Client Round Trip Time The time between when an SMB / CIFS 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.
CIFS Details
The following charts are available in this region:
- Top Methods
- This chart shows which SMB methods the client called the most by breaking out the total number of requests the client sent by method.
- Versions
- This chart shows which SMB / CIFS versions had the most responses received by the client by breaking out the total number of responses the client received, listed by version.
- Top Users
- This chart shows which users were most active on the client by breaking out the total number of SMB / 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
The following charts are available in this region:
- Access Time Distribution
- This chart breaks out access times in a histogram to show the most common access
times.
Metric Description SMB / CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this SMB / 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 SMB / CIFS Client Access Time The time between the ExtraHop system detecting the last packet of the request sent by this SMB / 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- Total Requests and Responses
- This chart shows you how many operations the SMB / CIFS client performed.
Metric Description Requests The number of requests sent by this SMB / CIFS client. Responses The number of responses received by this SMB / CIFS client. File System Info Requests The number of file system metadata queries sent by this SMB / CIFS client. Warnings The number of responses received by this SMB / CIFS client with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES. Creates The number of create operation requests sent by this SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. Reads The number of read operation requests sent by this SMB / CIFS client. Writes The number of write operation requests sent by this SMB / CIFS client. Renames The number of rename operation requests sent by this SMB / CIFS client Deletes The number of delete operation requests sent by this SMB / CIFS client. Locks The number of lock operation requests produced by this SMB / CIFS client. - Request and Response Size
- This chart shows the average size of requests and responses.
Metric Description CIFS Client Request Size The distribution of sizes (in bytes) of requests sent by this SMB / CIFS client. CIFS Client Response Size The distribution of sizes (in bytes) of responses received when the device is acting as an SMB / CIFS client.
CIFS server page
This page displays metric charts of CIFS server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about CIFS security considerations
- Learn about working with metrics.
CIFS Summary
The following charts are available in this region:
- Transactions
- This chart shows you when SMB / CIFS errors occurred and how many SMB / 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 SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - 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 SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - 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 received by this SMB / CIFS server. Writes The number of write operation requests received by this SMB / CIFS server. Creates The number of create operation requests received by this SMB / CIFS server. Deletes The number of delete operation requests sent by this SMB / CIFS server. - Total Operations
- This chart shows you how many read and write operations were performed on the
server.
Metric Description Reads The number of read operation requests received by this SMB / CIFS server. Writes The number of write operation requests received by this SMB / CIFS server. Creates The number of create operation requests received by this SMB / CIFS server. Deletes The number of delete operation requests sent by this SMB / CIFS server. - 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 acknowledgment 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 acknowledgment 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 SMB / CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this SMB / 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. SMB / CIFS Server Round Trip Time The time between when an SMB / CIFS 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)
- 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 SMB / CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this SMB / 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. SMB / CIFS Server Round Trip Time The time between when an SMB / CIFS 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.
CIFS Details
The following charts are available in this region:
- Top Methods
- This chart shows which SMB / CIFS methods were called on the server the most by breaking out the total number of requests the server received by method.
- Versions
- This chart shows which SMB / CIFS versions had the most responses sent by the server by breaking out the total number of responses the server sent, listed by version.
- Top Users
- This chart shows which users were most active on the server by breaking out the total number of SMB / 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
The following charts are available in this region:
- Access Time Distribution
- This chart breaks out access times in a histogram to show the most common access
times.
Metric Description SMB / CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this SMB / 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 SMB / 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- Total Requests and Responses
- This chart shows you how many operations were performed on the SMB / CIFS
server.
Metric Description Requests The number of requests received by this SMB / CIFS server. Responses The number of responses sent by this SMB / CIFS server. File System Info Requests The number of file system metadata queries received by this SMB / CIFS server. Warnings The number of responses sent by this SMB / CIFS server with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES. Creates The number of create operation requests received by this SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. Reads The number of read operation requests received by this SMB / CIFS server. Writes The number of write operation requests received by this SMB / CIFS server. Renames The number of rename operation requests received by this SMB / CIFS server. Deletes The number of delete operation requests sent by this SMB / CIFS server. Locks The number of lock operation requests received by this SMB / CIFS server. - Request and Response Size
- This chart shows the average size of requests and responses.
Metric Description SMB / CIFS Server Request Size The distribution of sizes (in bytes) of requests received by this SMB / CIFS server. SMB / CIFS Server Response Size The distribution of sizes (in bytes) of responses sent by this SMB / CIFS server.
CIFS client group page
This page displays metric charts of CIFS client traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about CIFS security considerations
- Learn about working with metrics.
CIFS Summary for Group
The following charts are available in this region:
- Transactions
- This chart shows you when SMB / CIFS errors occurred and how many responses the SMB /
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 SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - Total Transactions
- This chart shows you how many SMB / CIFS responses the clients received and how many
of those responses contained errors.
Metric Description Responses The number of responses received by this SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile.
CIFS Details for Group
The following charts are available in this region:
- Top Group Members (CIFS Clients)
- This chart shows which SMB / CIFS clients in the group were most active by breaking out the total number of SMB / CIFS requests the group sent by client.
- Top Methods
- This chart shows which SMB / CIFS methods the group called the most by breaking out the total number of requests the group sent by method.
- Versions
- This chart shows which SMB / CIFS versions had the most responses received by clients in the group by breaking out the total number of responses the group received, listed by version.
- Top Users
- This chart shows which SMB / CIFS users were most active in the group by breaking out the total number of SMB / CIFS responses the group received by user.
CIFS Metrics for Group
The following charts are available in this region:
- 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 SMB / CIFS client. Responses The number of responses received by this SMB / CIFS client. File System Info Requests The number of file system metadata queries sent by this SMB / CIFS client. Warnings The number of responses received by this SMB / CIFS client with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES. Creates The number of create operation requests sent by this SMB / CIFS client. Errors The number of responses received by this SMB/CIFS client that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. Reads The number of read operation requests sent by this SMB / CIFS client. Writes The number of write operation requests sent by this SMB / CIFS client. Renames The number of rename operation requests sent by this SMB / CIFS client Deletes The number of delete operation requests sent by this SMB / CIFS client. Locks The number of lock operation requests produced by this SMB / CIFS client. - 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 SMB / CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the request sent by this SMB / 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 server group page
This page displays metric charts of CIFS server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about CIFS security considerations
- Learn about working with metrics.
CIFS Summary for Group
The following charts are available in this region:
- Transactions
- This chart shows you when SMB / CIFS errors occurred and how many SMB / 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 SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. - 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 SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile.
CIFS Details for Group
The following charts are available in this region:
- Top Group Members (CIFS Servers)
- This chart shows which SMB / 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 SMB / CIFS methods were called on servers in the group the most by breaking out the total number of requests the group received by method.
- Versions
- This chart shows which SMB / CIFS versions had the most responses sent by servers in the group by breaking out the total number of responses the group sent, listed by version.
- Top Users
- This chart shows which SMB / CIFS users were most active in the group by breaking out the total number of SMB / CIFS responses the group sent by user.
CIFS Metrics in Group
The following charts are available in this region:
- 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 SMB / CIFS server. Responses The number of responses sent by this SMB / CIFS server. File System Info Requests The number of file system metadata queries received by this SMB / CIFS server. Warnings The number of responses sent by this SMB / CIFS server with an SMB status code that indicates a warning, such as STATUS_BUFFER_TOO_SMALL and STATUS_NO_MORE_FILES. Creates The number of create operation requests received by this SMB / CIFS server. Errors The number of responses sent by this SMB/CIFS server that have an SMB status code other than SUCCESS or that have a warning. A high number of SMB/CIFS errors might indicate a corrupt profile. Reads The number of read operation requests received by this SMB / CIFS server. Writes The number of write operation requests received by this SMB / CIFS server. Renames The number of rename operation requests received by this SMB / CIFS server. Deletes The number of delete operation requests sent by this SMB / CIFS server. Locks The number of lock operation requests received by this SMB / CIFS server. - 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 SMB / CIFS Server Access Time The time between the ExtraHop system detecting the last packet of the received request by this SMB / 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.
Database
The ExtraHop system collects metrics about database activity. Relational databases store, retrieve, and manage structured information through a database management system (DBMS) language. Activity for the following database languages is aggregated and displayed under Database metrics in the ExtraHop system:
- IBM DB2
- IBM Informix
- Microsoft SQL Server
- MySQL
- Oracle
- PostgreSQL
- Sybase ASE
- Sybase IQ
| Note: | The ExtraHop system also monitors 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 page. You can view details about each error, including the raw error message reported by the database, by clicking the Errors icon.
On the 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 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 (requires a recordstore)
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()
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.
Security considerations
- Database authentication can be vulnerable to brute force, which is a method for guessing credentials by submitting numerous authentication requests with different username and password combinations.
- Web applications that are vulnerable to SQL injection (SQLi) can send a database malicious SQL code that is injected into a legitimate data entry field (such as a password field).
- Database queries can enable enumeration, which is a reconnaissance technique that helps an attacker collect information.
- Database takeover attacks target database management systems (DBMS), which interact with file and operating systems on a server. An attacker submits malicious commands (for example, xp_cmdshell queries for Microsoft SQL Servers) in queries to the DBMS.
Database application page
This page displays metric charts of database traffic associated with an application container on your network.
- Learn about charts on this page:
- Learn about database security considerations
- Learn about working with metrics.
Database Summary
The following charts are available in this region:
- 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 acknowledgment 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 acknowledgment 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 acknowledgment (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 acknowledgment (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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 acknowledgment (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 acknowledgment (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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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.
Database client page
This page displays metric charts of database client traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about database security considerations
- Learn about working with metrics.
Database Summary
The following charts are available in this region:
- 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 error messages that were received by database clients. - 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 error messages that were received by database clients. - 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 acknowledgment 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 acknowledgment 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. A high number might 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. A high number might 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 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.
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 acknowledgment. Round trip time (RTT) is a measurement of network latency.
Database Details
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 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 database 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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 error messages that were received by database clients. 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.
Database server page
This page displays metric charts of database server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about database security considerations
- Learn about working with metrics.
Database Summary
The following charts are available in this region:
- 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 error messages that were sent by database servers. - 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 error messages that were sent by database servers. - 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 acknowledgment 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 acknowledgment 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. A high number might 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. A high number might 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 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 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 acknowledgment. Round trip time (RTT) is a measurement of network latency.
Database Details
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 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.
Round Trip Time The time between when a database 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 region 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 acknowledgment 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 acknowledgment 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
The following charts are available in this region:
- 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 error messages that were sent by database servers. 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.
Database client group page
This page displays metric charts of database client traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about database security considerations
- Learn about working with metrics.
Database Summary for Group
The following charts are available in this region:
- 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 error messages that were received by database clients. - 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 error messages that were received by database clients.
Database Details for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 error messages that were received by database clients. 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.
Database server group page
This page displays metric charts of database server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about database security considerations
- Learn about working with metrics.
Database Summary for Group
The following charts are available in this region:
- 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 error messages that were sent by database servers. - 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 error messages that were sent by database servers.
Database Details for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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 error messages that were sent by database servers. 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.
DHCP
The ExtraHop system collects metrics about Dynamic Host Configuration Protocol (DHCP) activity. DHCP is a protocol for dynamically distributing network configuration parameters.
DHCP application page
This page displays metric charts of DHCP traffic associated an application container on your network.
- Learn about charts on this page:
- Learn about working with metrics.
DHCP Summary
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DHCP client page
This page displays metric charts of DHCP client traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
DHCP Summary
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DHCP server page
This page displays metric charts of DHCP server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
DHCP Summary
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DHCP client group page
This page displays metric charts of DHCP client traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
DHCP Summary for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DHCP server group page
This page displays metric charts of DHCP server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
DHCP Summary for Group
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DICOM
The ExtraHop system collects metrics about Digital Imaging and Communications in Medicine (DICOM) activity. DICOM is a standard protocol for storing biomedical images and transmitting those images over a network.
| Note: | The ExtraHop system does 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
The ExtraHop system collects metrics about Domain Name System (DNS) protocol activity. DNS is the naming system for network hosts and resources that are connected to the Internet. DNS servers map IP addresses to hostnames.
Learn more by taking the DNS Quick Peek training.
Security considerations
- DNS is noisy and difficult to monitor with traditional methods.
- DNS transmissions are usually sent over user datagram protocol (UDP), which is easily spoofed and vulnerable to attacks.
- DNS weaknesses can be exploited to help advanced persistent threat (APT) groups evade detection.
- DNS is prone to DNS tunneling, amplification attacks, denial of service (DoS) attacks, hijacking, cache poisoning, redirection attacks, and more.
- DNS reverse lookup requests can enable enumeration, which is a reconnaissance technique that helps an attacker discover internal hostnames.
DNS application page
This page displays metric charts of DNS traffic associated with an application container on your network.
- Learn about charts on this page:
- Learn about DNS security considerations
- Learn about working with metrics.
DNS Summary
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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
The following charts are available in this region:
- 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.
DNS client page
This page displays metric charts of DNS client traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about DNS security considerations
- Learn about working with metrics.
DNS Summary
The following charts are available in this region:
- 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. This chart
does not appear if the device is in Flow Analysis.
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. This chart does not appear if
the device is in Flow Analysis.
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
The following charts are available in this region:
- 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
The following charts are available in this region unless the device is in Flow Analysis:
- 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
The following charts are available in this region:
- 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 The number of requests sent by this DNS client. Errors The number of times this DNS client received error codes in response to a query. 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. Truncated Requests The number of requests that were sent, but were truncated in transit, when the device is acting as a DNS client. 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 When the device is acting as a DNS client, the number of responses that were received but were truncated in transit. A truncated response is indicated by the truncated bit in the message and occurs when the message is larger than the underlying transmission channel allows.
DNS server page
This page displays metric charts of DNS server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about DNS security considerations
- Learn about working with metrics.
DNS Summary
The following charts are available in this region:
- Transactions
- This chart shows you when DNS errors occurred. The chart also shows you how many DNS
responses the server sent so that you can 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 sent by this DNS server. Errors The number of times this DNS server sent error codes in response to a query. - Total Transactions
- This chart displays the total number of DNS responses the server sent and how many of
those responses contained errors.
Metric Description Responses The number of responses sent by this DNS server. Errors The number of times this DNS server sent 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 server sent so that you can see how active the server was at the time
the timeouts occurred.
Requests The number of requests received by this DNS server. Request Timeouts The number of timeouts associated with this DNS server, which occurred after a repeated unanswered DNS query request was sent from clients. 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 received by this DNS server. Request Timeouts The number of timeouts associated with this DNS server, which occurred after a repeated unanswered DNS query request was sent from clients. DNS request timeouts can cause slowdowns and disruptions. - Server Processing Times
- This chart shows DNS 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. This chart
does not appear if the device is in Flow Analysis.
Metric Description DNS Server Server Processing Time The time it took for this DNS server to send the first response packet after receiving a query request. A lengthy processing time can indicate latency. - Server Processing Time Summary
- Shows the 95th percentile for server processing time. This chart does not appear if
the device is in Flow Analysis.
Metric Description DNS Server Server Processing Time The time it took for this DNS server to send the first response packet after receiving a query request. A lengthy processing time can indicate latency.
DNS Details
The following charts are available in this region:
- Top Record Types
- This chart shows which record types were requested on the server the most by breaking out the total number of requests the server received by record type.
- Top Host Queries
- This chart shows which host queries were made on the server the most by breaking out the total number of requests the server received by host query.
- Top Response Codes
- This chart shows which response codes the server sent the most by breaking out the number of responses the server sent by response code.
DNS Performance
The following charts are available in this region unless the device is in Flow Analysis:
- 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 Server Processing Time The time it took for this DNS server to send the first response packet after receiving a query request. A lengthy processing time can indicate latency. - Server Processing Time
- This chart shows the median server processing time.
Metric Description DNS Server Server Processing Time The time it took for this DNS server to send the first response packet after receiving a query request. A lengthy processing time can indicate latency.
Metric Totals
The following charts are available in this region:
- Total Requests and Responses
- Requests and responses represent the conversation taking place between clients and
servers. If there are more requests than responses, the server might be receiving more
requests than the server 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 received by this DNS server. Responses The number of responses sent by this DNS server. Errors The number of times this DNS server sent error codes in response to a query. Request Timeouts The number of timeouts associated with this DNS server, which occurred after a repeated unanswered DNS query request was sent from clients. DNS request timeouts can cause slowdowns and disruptions. Truncated Requests The number of requests that were received, but were truncated in transit, when the device is acting as a DNS server. 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 responses sent, but later truncated, when the device is acting as a DNS server. A truncated response is indicated by the truncated bit in the message and occurs when the message is larger than the underlying transmission channel allows.
DNS client group page
This page displays metric charts of DNS client traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about DNS security considerations
- Learn about working with metrics.
DNS Summary for Group
The following charts are available in this region:
- Transactions
- This chart shows you when DNS errors occurred and how many responses the DNS 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 DNS client. Errors The number of times this DNS client received error codes in response to a query. - Total Transactions
- This chart shows you how many DNS responses the clients 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.
DNS Details for Group
The following charts are available in this region:
- Top Group Members (DNS Clients)
- This chart shows which DNS clients in the group were most active by breaking out the total number of DNS requests the group sent by client.
- Top Record Types
- This chart shows which record types the group requested the most by breaking out the total number of requests the group sent by record type.
- Top Response Codes
- This chart shows which response codes the group received the most by breaking out the number of responses returned to the group by response code.
DNS Metrics for Group
The following charts are available in this region unless all the devices in the group are in Flow Analysis:
- 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 DNS client. 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. - 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 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 server group page
This page displays metric charts of DNS server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about DNS security considerations
- Learn about working with metrics.
DNS Summary for Group
The following charts are available in this region:
- Total Transactions
- This chart shows you when DNS errors occurred and how many DNS 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 DNS server. Errors The number of times this DNS server sent error codes in response to a query. - Total Transactions
- This chart shows you how many DNS responses servers in the group sent and how many of those
responses contained errors.
Metric Description Responses The number of responses sent by this DNS server. Errors The number of times this DNS server sent error codes in response to a query.
DNS Details for Group
The following charts are available in this region:
- Top Group Members (DNS Servers)
- This chart shows which DNS servers in the group were most active by breaking out the total number of DNS responses the group sent by server.
- Top Record Types
- This chart shows which record types were requested on servers in the group the most by breaking out the total number of requests the group received by record type.
- Top Response Codes
- This chart shows which response codes the group sent the most by breaking out the number of responses the group sent by response code.
DNS Metrics for Group
The following charts are available in this region unless all devices in the group are in Flow Analysis:
- 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 DNS server. Responses The number of responses sent by this DNS server. Errors The number of times this DNS server sent error codes in response to a query. Request Timeouts The number of timeouts associated with this DNS server, which occurred after a repeated unanswered DNS query request was sent from clients. DNS request timeouts can cause slowdowns and disruptions. Truncated Requests The number of requests that were received, but were truncated in transit, when the device is acting as a DNS server. 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 responses sent, but later truncated, when the device is acting as a DNS server. A truncated response is indicated by the truncated bit in the message and occurs when the message is larger than the underlying transmission channel allows. - 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 DNS Server Server Processing Time The time it took for this DNS server to send the first response packet after receiving a query request. A lengthy processing time can indicate latency.
FIX
The ExtraHop system collects metrics about Financial Information Exchange (FIX) protocol activity. FIX provides information about the real-time exchange of financial transactions.
FIX application page
This page displays metric charts of FIX traffic associated with application containers on your network.
- Learn about charts on this page:
- Learn about working with metrics.
FIX Summary
The following charts are available in this region:
- Transactions
- This chart shows you when FIX 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 FIX responses. Errors The number of FIX response errors. - Total Transactions
- This chart displays the total number of FIX responses that were associated with the
application and how many of those responses contained errors.
Metric Description Responses The number of FIX responses. Errors The number of FIX 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 acknowledgment 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 acknowledgment 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 FIX requests. A high number might indicate a large request or network delay. Server Processing Time The time between the ExtraHop system detecting the last packet of FIX 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 FIX responses. A high number might indicate a large response or network delay. Round Trip Time The time between when a FIX 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 FIX requests and the first packet of their corresponding responses. Round Trip Time The time between when a FIX client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.
FIX Details
The following charts are available in this region:
- Top Methods
- This chart shows which FIX methods were associated with the application by breaking out the total number of FIX requests by method.
- Top Senders
- This chart shows the top FIX senders for the application by breaking out the total number of FIX requests by sender.
- Top Targets
- This chart shows the top FIX targets for the application by breaking out the total number of FIX requests by target.
FIX Performance
The following charts are available in this region:
- Server Processing Time Distribution
-
This chart breaks out server
processing times in a histogram to show the most common processing times.
Metric Description FIX Server Processing Time The time between the ExtraHop system detecting the last packet of FIX requests and the first packet of their corresponding responses. - Server Processing Time
-
This chart shows the median processing time for the application.
Metric Description FIX Server Processing Time The time between the ExtraHop system detecting the last packet of FIX 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 a FIX 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 a FIX client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.
Network Data
This region 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 FIX 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 FIX 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 FIX 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 acknowledgment 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 FIX 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 acknowledgment 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 FIX 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 acknowledgment 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 FIX 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 acknowledgment 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.
FIX Metric Totals
The following charts are available in this region:
- 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 FIX 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 FIX requests. Responses The number of FIX responses. Errors The number of FIX response errors. - FIX Network Metrics
-
Metric Description Request Zero Windows The number of zero window advertisements sent by FIX 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 FIX requests. A device advertises a Zero Window when incoming data is arriving too quickly to be processed. RTOs In The number of retransmission timeouts caused by congestion when clients were sending FIX requests. An RTO is a 1-5 second stall in the TCP connection flow due to excessive retransmissions. RTOs Out The number of retransmission timeouts caused by congestion when servers were sending FIX 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 FIX requests. Response L2 Bytes The number of L2 bytes associated with FIX responses. Request Goodput Bytes The number of goodput bytes associated with FIX 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 FIX 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 FIX requests. Response Packets The number of packets associated with FIX responses.
FIX client page
This page displays metric charts of FIX server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
FIX Summary
The following charts are available in this region:
- Transactions
- This chart shows you when FIX errors occurred. The chart also shows you how many FIX
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.
Metric Description Responses The number of responses that the device received when acting as a FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade errors. - Total Transactions
-
This chart displays the total number of FIX 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 FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade 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 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 acknowledgment 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 acknowledgment 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 FIX Client Request Transfer Time When the device is acting as a FIX client, the time between the ExtraHop system detecting the first packet and last packet of sent requests. A high number might indicate a large request or network delay. FIX Client Server Processing Time When the device is acting as a FIX client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response. FIX Client Response Transfer Time When the device is acting as a FIX client, the time between the ExtraHop system detecting the first packet and last packet of received responses. A high number might indicate a large response or network delay. Round Trip Time The time between when a FIX 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.
Metric Description FIX Client Server Processing Time When the device is acting as a FIX 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 FIX 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.
FIX Details
The following charts are available in this region:
- Top Methods
- This chart shows which FIX methods the client called the most by breaking out the total number of requests the client sent by method.
- Top Versions
- This chart shows which versions of the FIX protocol the client communicated over the most by breaking out the total number of requests the client sent by FIX version.
- Top Targets
- This chart shows the top FIX targets for the client by breaking out the total number of requests the client sent by target.
FIX Performance
The following charts are available in this region:
- Server Processing Time Distribution
-
This chart breaks out server
processing times in a histogram to show the most common processing times.
Metric Description FIX Client Server Processing Time When the device is acting as a FIX 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 FIX Client Server Processing Time When the device is acting as a FIX 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 a FIX 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 FIX 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 region 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 acknowledgment 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 acknowledgment 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.
FIX Metric Totals
The following charts are available in this region:
- 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 FIX 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 a FIX client. Responses The number of responses that the device received when acting as a FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade errors. Aborted Requests The number of requests that this FIX client began to send but did not send completely. Aborted Responses The number of responses that this FIX client device began to receive but did not receive completely. POS Duplicate The number of possible duplicate messages that the device sent when acting as a FIX client. When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate (PossDup) message is generated. POS Resend The number of possible resend messages that the device sent when acting as a FIX client. Ambiguous application-level messages might be resent when an order remains unacknowledged for an inordinate length of time. - 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 FIX client. Response Size The distribution of sizes (in bytes) of responses received when the device is acting as a FIX client.
FIX server page
This page displays metric charts of FIX server traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about working with metrics.
FIX Summary
The following charts are available in this region:
- Transactions
- This chart shows you when FIX errors occurred. The chart also shows you how many FIX
responses the server sent so that you can see how active the server was at the time it
returned the errors.
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.
Metric Description Responses The number of responses that the device sent when acting as a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade errors. - Total Transactions
-
This chart displays the total number of FIX 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 a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade 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 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 acknowledgment 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 acknowledgment 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 FIX Server Request Transfer Time When the device is acting as a FIX server, the time between the ExtraHop system detecting the first packet and last packet of received requests. A high number might indicate a large request or network delay. FIX Server Server Processing Time When the device is acting as a FIX server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response. FIX Server Response Transfer Time When the device is acting as a FIX server, the time between the ExtraHop system detecting the first packet and last packet of sent responses. A high number might indicate a large response or network delay. Round Trip Time The time between when a FIX 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)
-
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 FIX Server Server Processing Time When the device is acting as a FIX 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 a FIX 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.
FIX Details
The following charts are available in this region:
- Top Methods
- This chart shows which FIX methods were called on the server the most by breaking out the total number of requests the server received by method.
- Top Versions
- This chart shows which versions of the FIX protocol the server communicated over the most by breaking out the total number of requests the server received by FIX version.
- Top Targets
- This chart shows the top FIX targets for the server by breaking out the total number of requests the server received by target.
FIX Performance
The following charts are available in this region:
- Server Processing Time Distribution
-
This chart breaks out server
processing times in a histogram to show the most common processing times.
Metric Description FIX Server Server Processing Time When the device is acting as a FIX 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 FIX Server Server Processing Time When the device is acting as a FIX server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent 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 FIX 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 a FIX 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 region 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 acknowledgment 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 acknowledgment 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.
FIX Metric Totals
The following charts are available in this region:
- 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 FIX 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 FIX server. Responses The number of responses that the device sent when acting as a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade errors. Aborted Requests The number of requests that this FIX server began to receive but did not receive completely. Aborted Responses The number of responses that this FIX server began to send but did not send completely. POS Duplicate The number of possible duplicate messages sent when the device is acting as a FIX server. When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate (PossDup) message is generated. POS Resend The number of possible resend messages sent when the device is acting as a FIX server. Ambiguous application-level messages might be resent when an order remains unacknowledged for an inordinate length of time. - Average 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 a FIX server. Response Size The distribution of sizes (in bytes) of responses received when the device is acting as a FIX server.
FIX client group page
This page displays metric charts of FIX server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
FIX Summary for Group
The following charts are available in this region:
- Transactions
- This chart shows you when FIX errors occurred and how many responses the FIX 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 FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade errors. - Total Transactions
- This chart shows you how many FIX 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 FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade errors.
FIX Details for Group
The following charts are available in this region:
- Top Group Members (FIX Clients)
- This chart shows which FIX clients in the group were most active by breaking out the total number of FIX requests the group sent by client.
- Top Methods
- This chart shows which FIX methods the group called the most by breaking out the total number of requests the group sent by method.
- Top Versions
- This chart shows the top FIX targets for the group by breaking out the total number of requests the group sent by target.
FIX Metrics for Group
The following charts are available in this region:
- 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 a FIX client. Responses The number of responses that the device received when acting as a FIX client. Errors When the device is acting as a FIX client, the number of error responses received. These metrics do not include the processing of order and trade errors. Aborted Requests The number of requests that this FIX client began to send but did not send completely. Aborted Responses The number of responses that this FIX client device began to receive but did not receive completely. POS Duplicate The number of possible duplicate messages that the device sent when acting as a FIX client. When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate (PossDup) message is generated. POS Resend The number of possible resend messages that the device sent when acting as a FIX client. Ambiguous application-level messages might be resent when an order remains unacknowledged for an inordinate length of time. - 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 FIX Client Server Processing Time When the device is acting as a FIX client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response.
FIX server group page
This page displays metric charts of FIX server traffic associated with a device group on your network.
- Learn about charts on this page:
- Learn about working with metrics.
FIX Summary for Group
The following charts are available in this region:
- Transactions
- This chart shows you when FIX errors occurred and how many FIX 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 a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade errors. - Total Transactions
- This chart shows you how many FIX 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 a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade errors.
FIX Details for Group
The following charts are available in this region:
- Top Group Members (FIX Servers)
- This chart shows which FIX servers in the group were most active by breaking out the total number of FIX responses the group sent by server.
- Top Methods
- This chart shows which FIX methods were called on servers in the group the most by breaking out the total number of requests the group received by method.
- Top Versions
- This chart shows the top FIX targets for the group by breaking out the total number of requests the group received by target.
Fix Metrics for Group
The following charts are available in this region:
- 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 FIX server. Responses The number of responses that the device sent when acting as a FIX server. Errors When the device is acting as a FIX server, the number of error responses sent. These metrics do not include the processing of order and trade errors. Aborted Requests The number of requests that this FIX server began to receive but did not receive completely. Aborted Responses The number of responses that this FIX server began to send but did not send completely. POS Duplicate The number of possible duplicate messages sent when the device is acting as a FIX server. When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate (PossDup) message is generated. POS Resend The number of possible resend messages sent when the device is acting as a FIX server. Ambiguous application-level messages might be resent when an order remains unacknowledged for an inordinate length of time. - 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 FIX Server Server Processing Time When the device is acting as a FIX server, the time between the ExtraHop system detecting the last packet of the received request and first packet of the sent response.
FTP
The ExtraHop system collects metrics about File Transfer Protocol (FTP) activity. FTP ) is a standard network protocol for transferring files between a client and a server.
Learn more by taking the FTP Quick Peek training.
Security considerations
- FTP authentication can be vulnerable to brute force, which is a method for guessing credentials by submitting numerous authentication requests with different username and password combinations.
- Anonymous FTP authentication might expose sensitive data to unauthorized users.
FTP application page
This page displays metric charts of FTP traffic associated with an application container on your network.
- Learn about charts on this page:
- Learn about FTP security considerations
- Learn about working with metrics.
FTP Summary
The following charts are available in this region:
- Transactions
- This chart shows you when FTP errors, warnings, and responses were associated with the
application. This information can help you see how active the application was at the
time the errors and warnings occurred.
In a healthy environment, the number of requests and responses should be roughly equal. For more information, see Requests and Responses.
Metric Description Warnings The number of responses with an FTP status code of 4xx. Responses The number of FTP responses. Errors The number of FTP response errors. - Total Transactions
- This chart displays the total number of FTP responses that were associated with the
application and how many of those responses contained warnings and errors.
Metric Description Responses The number of FTP responses. Errors The number of FTP 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 acknowledgment 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 acknowledgment 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 FTP requests. A high number might indicate a large request or network delay. Server Processing Time The time between the ExtraHop system detecting the last packet of FTP 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 FTP responses. A high number might indicate a large response or network delay. Round Trip Time The time between when an FTP 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 FTP requests and the first packet of their corresponding responses. Round Trip Time The time between when an FTP client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.
FTP Details
The following charts are available in this region:
- Top Methods
- This chart shows which FTP methods were associated with the application by breaking out the total number of FTP requests by method.
- Top Status Codes
- This chart shows which FTP status codes the server returned the most by breaking out the total number of responses the application sent by status code.
- Top Users
- This chart shows which users were most active in the application by breaking out the total number of FTP requests sent by the application.
FTP Performance
The following charts are available in this region:
- Server Processing Time Distribution
-
This chart breaks out server
processing times in a histogram to show the most common processing times.
Metric Description FTP Server Processing Time The time between the ExtraHop system detecting the last packet of FTP requests and the first packet of their corresponding responses. - Server Processing Time
-
This chart shows the median processing time for the application.
Metric Description FTP Server Processing Time The time between the ExtraHop system detecting the last packet of FTP 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 FTP 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 FTP client or server sent a packet requiring immediate acknowledgment and when the acknowledgment was received.
Network Data
This region 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 FTP 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 FTP 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 (RTOs) caused by congestion when clients were sending FTP 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 acknowledgment 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 FTP 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 acknowledgment 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 (RTOs) caused by congestion when clients were sending FTP 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 acknowledgment 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 FTP 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 acknowledgment 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.
FTP Metric Totals
The following charts are available in this region:
- 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 FTP 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 FTP requests. Responses The number of FTP responses. Errors The number of FTP response errors. Warnings The number of responses with an FTP status code of 4xx. - FTP Network Metrics
-
Metric Description Request Zero Windows The number of zero window advertisements sent by FTP 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 FTP requests. A device advertises a Zero Window when incoming data is arriving too quickly to be processed. Request RTOs The number of retransmission timeouts (RTOs) caused by congestion when clients were sending FTP 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 FTP 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 FTP requests. Response L2 Bytes The number of L2 bytes associated with FTP responses. Request Goodput Bytes The number of goodput bytes associated with FTP 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 FTP 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 FTP requests. Response Packets The number of packets associated with FTP responses.
FTP client page
This page displays metric charts of FTP traffic associated with a device on your network.
- Learn about charts on this page:
- Learn about FTP security considerations
- Learn about working with metrics.
FTP Summary
The following charts are available in this region:
- Transactions
- This chart shows you when FTP errors occurred and how many responses the FTP 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 Warnings The number of responses with a status code of 4xx, that the device received when acting as an FTP client. Responses The number of responses that the device received when acting as an FTP client. Errors The number of errors that the device received when acting as an FTP client. - Total Transactions
- This chart displays the total number of FTP responses the client received and how many
of those responses contained errors and warnings.
Metric Description Responses The number of responses that the device received when acting as an FTP client. Errors The number of errors that the device received when acting as an FTP client. Warnings The number of responses with a status code of 4xx, that the device received when acting as an FTP 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 the client. The round trip time
(RTT) metric measures how long it took for packets to get an immediate acknowledgment
from the client or server. The ExtraHop system calculates RTT by measuring the time
between the first packet of a request and the acknowledgment from the server, as shown
in the following figure:
RTT only measures how long an immediate acknowledgment 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. However, if the TCP 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.
Learn more about how the ExtraHop system calculates round trip time on the ExtraHop forum.
Metric Description FTP Client Request Transfer Time When the device is acting as an FTP client, the time between the ExtraHop system detecting the first packet and last packet of sent requests. A high number might indicate a large request or network delay. FTP Client Server Processing Time When the device is acting as an FTP client, the time between the ExtraHop system detecting the last packet of the sent request and the first packet of the received response. FTP Client Response Transfer Time When the device is acting as an FTP client, the time between the ExtraHop system detecting the first packet and last packet of received responses. A high number might indicate a large response or network delay. Round Trip Time The time between when a FTP 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.
Metric Description FTP Client Server Processing Time When the device is acting as an FTP 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 FTP 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.
FTP Details
The following charts are available in this region:
- Top Methods
- This chart shows which FTP methods the client called the most by breaking out the total number of requests the client sent by method.
- Top Status Codes
- This chart shows which FTP 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 FTP requests sent by the client by user.
FTP Performance
The following charts are available in this region:
- Server Processing Time Breakdown
-
This chart breaks out server
processing times in a histogram to show the most common processing times.
Metric Description FTP Client Server Processing Time When the device is acting as an FTP 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 FTP Client Server Processing Time When the device is acting as an FTP 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 a FTP 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 FTP 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.
Thank you for your feedback. Can we contact you to ask follow up questions?