I was trying to create VM instance on Google Could Platform, but it always gives me an error says Failed to load.
================
Answer
Found the solution by accident, I was browsing in the MarketPlace and trying to launch a Ubuntu 16.04 OS but end with this error
Compute Engine API has not been used in project xxxxxxxxxxx before or
it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/compute.googleapis.com/overview?project=xxxxxxxxxxx
then retry. If you enabled this API recently, wait a few minutes for
the action to propagate to our systems and retry.
So I goto the link mentioned in the above Error message. After I enabled Compute Engine API there I can find the Create Instance button in my VM instances section.
This error message is related to UI issues with cache and cookies. So to fix this you can try any of the following:
1.- Log In to GCP in an Incognito window.
2.- Clear/delete your web browser cache and cookies.
3.- Login to GCP through another web browser.
Please verify Compute Engine API is enabled in your project by following step 3 from this guide.
Additional, there was a known issue yesterday that prevent new projects to enable Compute Engine API and therefore not be able to create VM Instances. This issue has been fixed by now so you shoud be able to create this Instances with no problem.
Related
I created a VM Instance (n1-standard-8) for a project. I was using AI Platform > Workbench (Jupyter Notebook). I was able to read the data from Cloud storage and process it. After 2 months, I tried to start the notebook and clicked on 'OPEN JUPYTERLAB'. It just spins up saying "Setting up proxy to Jupyterlab".
Environment: Kaggle Python
Machine Type: n1-standard-8 (8 vCPUs, 30
GB RAM)
What is the possible issue?
PS: New to Google Cloud
One possible solution is to create a new VPC without adding the DNS rules for the various notebooks endpoints.
Then, use the configured network with a new notebook instance clicking the “OPEN JUPYTERLAB” URL.
You can see more information here.
Another possible thing that could be happening if you check your logs is an error that shows this “ - Required 'compute.instances.get' permission for project'”. This happens because you are using the non-default service account that you specified during the notebook creation. So the solution to this is to use the default service account.
We have setup a fluentd agent on a GCP VM to push logs from syslog server (the VM) to GCP's Google Cloud Logging. The current setup is working fine and is pushing more than 300k log entries to Stackdriver (Google Cloud Logging) per hour.
Due to increased traffic, we are planning to increase the number of VMs employed behind the load balancer. However, the new VM with fluentd agent is not being able to push logs to Stackdriver. After the first time activation of VM, it does send a few entries to Stackdriver and after that, it does not work.
I tried below options to setup the fluentd agent and to resolve the issue:
Create a new VM from scratch and install fluentd logging agent using this Google Cloud documentation.
Duplicate the already working VM (with logging agent) by creating Images
Restart the VM
Reinstall the logging agent
Debugging I did:
All the configurations for google fluentd agent. Everything is correct and is also exactly similar to the currently working VM instance.
I checked the "/var/log/google-fluentd/google-fluentd.log" for any logging errors. But there are none.
Checked if the logging API is enabled. As there are already a few million logs per day, I assume we are fine on that front.
Checked the CPU and memory consumption. It is close to 0.
All the solutions I could find on Google (there are not many)
It would be great if someone can help me identify where exactly I am going wrong. I have checked configurations/setup files multiple times and they look fine.
Troubleshooting steps to resolve the issue:
Check whether you are using the latest version of the fluentd agent or not. If not, try upgrading the fluentd agent. Refer to upgrade the agent for information.
If you are running very old Compute Engine instances or Compute Engine instances created without the default credentials you must complete the Authorizing the agent procedures.
Another point to focus is, how you are Configuring an HTTP Proxy. If you are using an HTTP proxy for proxying requests to the Logging and Monitoring APIs, check whether the metadata server is reachable. The metadata server has to be reachable (and do it directly; no proxy) when Configuring an HTTP Proxy.
Check if you have any log exclusions configured which is preventing the logs from arriving. Refer Exclusion filters for information.
Try uninstalling the Fluentd agent and try to use Ops agent instead (note that syslog logs are collected by it with no setup) and check whether you were able to see the logs. Combining logging and metrics into a single agent, the Ops Agent uses Fluent Bit for logs, which supports high-throughput logging, and the OpenTelemetry Collector for metrics. Refer Ops agent for more information.
Logs from Spring Boot applications deployed to GKE stopped showing up in Stackdriver Logging after February 2nd 2020. What happened around that time is that Stackdriver moved to a new UI, more integrated with the GCP console - could that have anything to do with it?
I do have other projects in GKE, such as a Node.js based backend, where logging to Stackdriver has continued without interruption, but there is just silence from the Spring Boot apps:
If I select "Kubernetes Container" instead of "GKE Container" in the GCP console at "Stackdriver Logging -> Logs Viewer" I do see some log statements, specifically errors like:
WARNING: You do not appear to have access to project [my-project] or it does not exist.
and
Error while fetching metric descriptors for kube-proxy: Get https://monitoring.googleapis.com/v3/projects/my-project/metricDescriptors?...
and
Error while sending request to Stackdriver Post https://monitoring.googleapis.com/v3/projects/my-project/timeSeries?...
OK, so that seems to start explaining the problem but I haven't been changing any IAM permissions, and when comparing those to the ones in the project hosting the Node.js GKE deployments which continue logging fine, they seem to be the same.
Should I be changing some permissions in the project hosting the Spring Boot GKE deployments, to get rid of those Stackdriver errors? What IAM member affects those? What roles would be required?
Turns out that the GKE cluster had Legacy Stackdriver Logging and Legacy Stackdriver Monitoring enabled:
and the problem was solved by setting those attributes to disabled and configuring the Stackdriver Kubernetes Engine Monitoring attribute:
But why the Stackdriver Logging continues uninterrupted for the Node.js applications, with the legacy options enabled, is still a mystery to me.
I'm working on a project where I need to access VM instances from Cloud build to download dependencies.
Cloud build uses worker pool and it will reside outside the VPC so, its not able to go through firewall.
Can anyone suggest me how to resolve this issue or help me with Custom workerpool creating.
From Documentation:
gcloud alpha builds worker-pools create
This command is currently in ALPHA and may change without notice. If this command fails with API permission errors despite specifying the right project, you may be trying to access an API with an invitation-only early access whitelist.
I've just created a VM instance at GCP with os-login feature enabled. I can connect via ssh using web browser console, SDK, but, I can't connect using the android app called Cloud Console.
Is there any extra step while configuring os-login to use the offical google android app?
Thanks.
I believe everything should work out of the box. There certainly isn't mention of any extra documentation on the Cloud Console Mobile App landing page.
I spun up a new instance (europe-west4-b, n1-standard-1, debian-9-stretch-v20190813) and set the metadata to enable-oslogin = TRUE and I managed to connect right away, albeit from an iOS device.
I would suggest trying different networks (WiFi, 3G/4G), double check any suspicious firewall tags on the instance, maybe even try from a different device. If the connection attempt did reach the server, chances are there's at least one log entry mentioning it in /var/log (/var/log/auth.log in Debian is a good place to start).