Troubleshooting

Short spikes in packet loss that last a few minutes

Certain short spikes lasting for a few minutes are expected or possible. Check for sustained loss that lasts for greater than five minutes. If you see such loss, or if the loss impacts your network or application performance, see Getting support.

Spikes in latency

Latency is measured over Layer 4 traffic and is impacted by the TCP/IP stack running on the remote VM. Some applications with unique TCP/IP stack implementations (such as VPN applications) might artificially increase latency in Performance Dashboard. If latency spikes despite the absence of custom applications that might impact the TCP/IP stack, see Getting support.

No data in Performance Dashboard

If you can't see packet loss information, make sure that you have virtual machine (VM) instances in the Virtual Private Cloud (VPC) or Shared VPC network that you are viewing. Performance Dashboard uses active probes to measure packet loss between zones. The number of active probes is related to the number of VMs in the network. If the network that you are viewing has no VMs, there are no active probes and no packet loss measurement.

If you can't see latency information, make sure that you have VM instances generating enough traffic.

Packet loss by zone heatmap has empty cells (marked as N/A)

This is possible if a project is part of a Shared VPC. In such a case, the matrix might include data for source zones where the project itself doesn't have VMs, but other projects in the same Shared VPC do have VMs. Packet loss between two projects that use Shared VPC is measured toward the destination service project.

Packet loss seen in Performance Dashboard but not in application

Packet loss is based on active probing, which covers the entire mesh of VMs that can communicate with each other. Your traffic pattern might only use a subset of this mesh. It might be that your application is not utilizing the problematic network path.

Another possibility is that we do not have enough measurements to give high confidence results. This might happen if there are very few VMs in a zone, or if the number of VMs is fluctuating.

We also include preemptible VMs in the packet loss calculation, and projects with a high percentage of such VMs might show a higher packet loss rate when VMs are getting preempted. Check if higher packet loss rate corresponds to the time window when preemptible VMs are being shut down.

Constant value seen for latency between two zones

Latency data is stored as a distribution. This means that if all measurements consistently fall in the same bucket in the distribution (which is more likely to happen with higher latency values), the resulting graph displays a constant value that is the mean of the bucket interval.

For example, if there is a bucket for every 10 ms (0 ms-10 ms, 10 ms-20 ms, 20 ms-30 ms, and so on), and there are three different latency measurements of 251 ms, 256 ms, and 253 ms, all of them are in the 250 ms-260 ms bucket. The latency is displayed as 255 ms, which is the mean of the 250 ms-260 ms bucket interval. If a new measurement of 259 ms is recorded, the latency still displays as 255 ms.

Troubleshooting Google Cloud performance metrics

Google Cloud performance appears more stable than project performance

Because the Google Cloud performance metrics are aggregated across all Google Cloud projects, they show fewer variations. This indicates that the typical performance in a zone pair remains stable even though the performance of individual projects might show greater variation due to randomness, natural variation, and measurement noise.

Can choose Google Cloud zones in the Google Cloud performance view but not in project view

For your project-specific view, you can only choose zones where the project is deployed. The Google Cloud performance view enables you to view performance from any Google Cloud zone to any other Google Cloud zone.

No project data in a zone pair but the Google Cloud performance data exists

Google Cloud performance metrics are estimated by aggregating across all Google Cloud projects and are always available.

What's next