This page describes tips that you might find helpful if you run into problems using Compute Engine.
For help troubleshooting specific issues, see one of the following sections:
- For steps to troubleshoot general issues with instances, such as if your instance doesn't start up, see General troubleshooting.
- For steps to troubleshoot issues with Windows instances, see Troubleshooting Windows instances.
Viewing different response formats
The Google Cloud CLI performs most of its actions by making REST
API calls. The pretty-printed results show only the most important information
returned by any specific command. To see the different response formats,
use the --format
flag which displays the response in different output formats,
including json
, yaml
, and text
. For example, to see a list of instances in
JSON, use --format json
:
gcloud compute instances list --format json
Viewing gcloud compute logs
The gcloud CLI creates and stores logs in a log file that you
can query, located at $HOME/.config/gcloud/logs
. To see the latest log file on
a Linux-based operating system, run:
$ less $(find ~/.config/gcloud/logs | sort | tail -n 1)
The log file includes information about all requests and responses made using
the gcloud CLI
tool.
To automatically purge the log files created by the gcloud CLI,
use the max_log_days
property,
which sets the maximum number of days to retain log files before deleting.
The default setting is 30 days. If you set this property value to 0, it turns
off log garbage collection and does not delete log files.
gcloud config set core/max_log_days DAYS_TO_RETAIN_LOGS
Disable gcloud CLI file logging:
The file $HOME/.config/gcloud/logs
consumes space on the local filesystem.
The amount of logs generated might overwhelm the amount of space on the local
filesystem, which can cause issues like:
- Space utilization reaching 100% on the instance.
- Failure to execute gcloud CLI logging commands because there is no space left to create a new file on the local filesystem.
To change the gcloud CLI behavior and disable the file
logging, use the disable_file_logging
property:
gcloud config set core/disable_file_logging True
Selecting resource names
When selecting names for your resources, keep in mind that these friendly-names may be visible on support and operational dashboards within Compute Engine. For this reason, it is recommended that resource names that do not expose any sensitive information.
Communicating to the internet
An instance has direct internet access only if both of the following conditions are true:
- The instance has an external IP address.
- The instance's VPC network uses a default route whose next hop is the default internet gateway.
Instances can also access the internet indirectly, by connecting through Cloud NAT or an instance-based proxy. For additional considerations, including firewall rule configuration, see Internet access requirements.
Idle connections
Google Cloud VPC networks implement 10-minute connection tracking for IP protocols that have a concept of a connection (TCP for example). This means that inbound packets associated with an established connection are permitted as long as at least one packet is sent or received for the connection within the last 10 minutes. If no packets for the connection have been sent or received for 10 minutes or longer, the idle connection's tracking entries are removed. After the connection's tracking entries have been removed, Google Cloud does not permit additional inbound packets until at least one new outbound packet has been sent. This connection tracking applies to all sources and destinations – both internal and external IP addresses .
To prevent idle connections, do the following:
Set operating system TCP keep-alive parameters to a time frame of less than 10 minutes. This ensures that at least one packet is sent within the time frame.
Ensure applications that open TCP connections do so with the
SO_KEEPALIVE
option enabled.
The following examples demonstrate how to set operating system TCP keep-alive
parameters with an interval value of one minute. Consult your application or
software library's documentation to determine how to configure it to use
SO_KEEPALIVE
.
Linux
Run the following command:
$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5
To ensure that the settings survive a reboot, add the settings to your
/etc/sysctl.conf
file.
See Linux TCP Keepalive HOWTO for additional information.
macOS
Run the following command:
$ sudo sysctl -w net.inet.tcp.always_keepalive=1 net.inet.tcp.keepidle=60000 net.inet.tcp.keepinit=60000 net.inet.tcp.keepintvl=60000
Windows
Under the registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
,
add the following settings, using the
DWORD
data type, or edit the values if the settings already exist:
KeepAliveInterval: 1000 KeepAliveTime: 60000 TcpMaxDataRetransmissions: 10
Accessing Compute Engine as a different SSH user
By default, the gcloud compute
command-line tool uses the $USER
variable to
add users to the /etc/passwd
file for connecting to virtual machine instances
using SSH. You can specify a different user using the
--ssh-key-file PRIVATE_KEY_FILE
flag when running the gcloud compute ssh
command. For example:
gcloud compute ssh example-instance --ssh-key-file my-private-key-file
See the
gcloud
reference documentation for
more information.
Interacting with the serial console
You can enable interactive access to an instance's serial console so you can connect and troubleshoot instances through the serial console.
To learn more, read Interacting with the Serial Console.
Avoiding packet fragmentation to instances built from custom images
The VPC network has a default maximum transmission unit (MTU)
of 1460
bytes for Linux images and Windows Server images. However, the
network MTU can be changed. For details, see the
maximum transmission unit overview in the VPC
documentation.
When creating client applications that communicate with Compute Engine instances over UDP sockets, you can avoid fragmentation if you set the maximum size of the UDP datagram's data to 28 bytes less than the network MTU. For example, if the network's MTU is 1460 bytes, you can send up to 1432 bytes of UDP data per packet without fragmentation. If the network's MTU is 1500 bytes, you can send up to 1472 bytes of UDP data without fragmentation. The 28 bytes are used for an IPv4 packet header (20 bytes) and a UDP datagram header (8 bytes). You can set the network's MTU to a maximum of 8896 bytes.