When I have a look at one of my GCP projects under APIs & Services > Dashboard, I can see requests for "Cloud Pub/Sub API" although I do not use this API, all requests are errors, so 100% error rate.
I can see similar situations in other projects with other APIs, the above is only an example.
So far I have tried to find out more within: Logging > Logs Explorer, but it seems that APIs are not included in these logs. In addition I have tried to click on the API within APIs & Services > Dashboard and investigate the menu items "Overview", "Metrics", "Quotas" and "Credentials" but I could not find anything which would describe who/what uses this API.
Any ideas?
EDIT (12. Nov 2020):
I am using the following resources in this project:
App Engine
Compute Engine
Cloud Storage
BigQuery
Cloud SQL
Related
When we migrate from the SafetyNet Api to Google Play Integrity Api we need link a PlayStore application to the Google Cloud Project in the Google Play console.
For existing on production application should it be the same google cloud project in which safetyet's keys were created? Or can it be different/new Google Cloud project and it will not affect the existing clients? Does it matter which account I will link? What should I do if I lost the account which originally was used to created the SafetyNet API keys?
I search through Google's documentation but I have not found any information about this matter. I also have not used increased api usage quota.
Those two API's are not dependent on each other.
I've tried same application with two different Google Cloud projects and got the same token response. So I believe the answer is yes - you can link a new Google Cloud Project to your application.
I'm currently working on a project where I want to have access to log data and other stuff
like graph from GCP on a web application.
For security reasons (I guess), it's not possible to integrate a GCP adress in an tag. Do you know any way to make it work or do you have any idea for something that would make the data accessible ?
You might refer to Cloud Logging for logs, and Cloud Monitoring for metrics and visualization that are the part of Cloud Operation Suite. I believe almost all of the visualizations you see on Google Cloud Console (Web UI) are from Cloud Monitoring. Both of them have API and SDK that can be accessed using popular languages like Python, Java, or JavaScript. Cloud Monitoring itself supports creating visualization in Widgets and combining them all on Dashboards.
For the embedding with IFrame part, I haven't seen a direct way to do that, as it will need to do authentication to view Cloud Monitoring dashboards. According to this answer, you can export the visualization from Grafana instead. But I haven't tried that approach yet.
About the GCP address in a tag. Can you elaborate more about that in the comment below? I can suggest that all the resources in GCP have their own resource name that you can filter from the Metric Explore in Cloud Monitoring. Custom tags are supported, you can put any valid name you like.
When reviewing the documentation here (https://cloud.google.com/monitoring/alerts/incidents-events#incident) and using the general product, it appears that the open incidents and associated details are only displayed via the Google Cloud Console.
The CLI and API appear to only support management of alerting policies, but I cannot find a way to retrieve a list of open incidents. For example, I'd like to send an alert if more than 5 incidents are open for 12 hours on a specific alerting policy. It would seem that the data exists (as provided from the Google Cloud Console), but the API is not public.
I think it is not possible.
Incidents appear to not be part of Google's public API for Cloud Monitoring.
There are a couple of ways to verify this:
APIs Explorer documents Cloud Monitoring API and there are no Incident resource types nor methods.
Using e.g. Chrome Developer Console while browsing Cloud Console: Incidents doesn't (appear to) include any public API endpoints/methods
There's an existing feature request (FR) on Google's public issue tracker for this.
I encourage you to "Star this issue" by clicking the star icon to the left of the issue title Manage Incidents via API to both "+1" the FR and to subscribe to updates on it.
I am developing an application that uses the google api to create projects on the google cloud platform and enable these projects to the Dialogflow api.
For this reason I created a service account with the Cloud Resource Manager API and Service Usage API enabled. In sequence I send two HTTP POST requests to the service account first to the address:
https://cloudresourcemanager.googleapis.com/v3/projects
to create a new project and then to the address
https://serviceusage.googleapis.com/v1/projects/{0}/services/dialogflow.googleapis.com:enable
to enable the Dialogflow api on the new project (clearly in place of {0} I'm going to put the code of the new project returned by the previous API).
Initially and for some time everything worked fine. Projects were created and with the Dialogflow API enabled.
Then all of a sudden the second api to enable dialogflow gives me a resource not found error and it doesn't work anymore.
I understand that the problem is the following:
the API for creating new project, although it does not give me any errors and is done successfully, it does not really create the project in the google cloud platform.
I add that I have a Google Cloud Identity account (required to address a parent folder when a new project is created) and an account with billing details linked to the service account. I also applied to Google to increase the maximum limit of projects allowed on the google cloud platform.
I don't know why suddenly google no longer allows me to create projects via its api.
Problem: Google Cloud Run only provides a subset of documented metadata
I have a simple JVM based application running on Google Cloud Run that queries http://metadata.google.internal for available metadata.
The only metadata available is at the following paths:
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts
http://metadata.google.internal/computeMetadata/v1/instance/zone
http://metadata.google.internal/computeMetadata/v1/project/project-id
http://metadata.google.internal/computeMetadata/v1/project/numeric-project-id
As per the documentation, I was expecting more than this and hoping that I would be able to query the metadata server for the name of the Cloud Run service and the metadata required to configure Stackdriver Monitoring for a generic_node.
One clue that I have found is in the server header in the response from querying the Metadata server gives the value: Metadata Server for Serverless
Theory: Cloud Run is in beta and the Metadata Server for Serverless is separate from the typical metadata server and is a work in progress.
Question(s):
Is this theory valid?
Is this limitation documented somewhere?
Is there a roadmap for adding additional metadata?
Is there an alternative for determining the metadata needed to configure Stackdriver?
Compute Metadata service you linked is only available to Compute Engine products (such as GCE, GKE). Many of the endpoints in there are about VM details, VM metadata/tags, VM startup scripts etc.
These concepts don't apply to serverless compute environments. Therefore I don't think a feature request here will succeed.
Serverless products such as App Engine, Cloud Functions and Cloud Run support a minimal version of the metadata service to provide basic functionality to SDKs (such as Google Cloud client libraries, Stackdriver or OpenTelemetry/OpenCensus clients, or gcloud CLI). Using these endpoints, Google’s own client libraries can automatically get auth tokens, discover project IDs etc.
Also, these serverless products don't run on GCE, and don't have the same concepts. That's why a full metadata service isn't available for these products.
The applicable for serverless environments are the endpoints you listed in your question.
I don't think you will find much information in order to validate your theory as that has to do with the product's architecture and I don't think Google will share it for the moment, however, it does seem to be valid based on the evidence you found.
What can be done is to open a feature request to Google so that they work on adding more information to the metadata so that it cover your needs. As the product is on beta, they should be open to do some changes.
Hope you find this useful.