In the GCP API Manager I'm seeing multiple requests come in for the Google Compute Engine API. When I try to filter these requests by credential, it seems that the requests aren't tied to any specific one.
I tried disabling the API but all that caused was for the requests to 403 as can be seen in the later API calls. Is there a way to trace the source of these requests?
Are they coming from some integration? From GCP itself?
Here's an expanded view when trying to slice the graph by credential for the same time period:
Related
I've configured a Google API gateway in front of our Cloud Run services with JWT authentication as a custom security definition. It works but I'm seeing a lot of outgoing queries. I can see multiple (2-4) log entries every five minutes for the same endpoint (logname: apigateway.googleapis.com/jwks_queries). Is there a way to further debug this or to allow some caching on this. I'm assuming this is causing some delay on our API requests.
I'm using AWS API Gateway with quota and need increase the number of requests made to api only if my backend return response with status code 200. So, responses with status different of 200 not are accounted for quota usage.
It's possible? If not, how i could make this?
Thanks
Recently i faced the same question, my solution is a little workaround.
You create two apis with aws api gateway and also two usage plans. The first api should be the api used by your customer, the second api exists only to increase the quota usage value for an API Key, so it should be a simple POST Endpoint. Now create one free usage plan (only throttling) and one usage plan with quota limitation enabled. Then connect the free plan to your api which is responsible for processing the data and connect the quota plan to the additional quota api.
Finally create an API Key for your customer, add both usage plans. Now you only need to call your quota api with the API Key provided by your customers, when their requests were successfully.
Hope this will work for you aswell.
I have a custom gRPC backend deployed behind an Endpoints Service Proxy (ESP) connected to Google Cloud Endpoints.
When sending a request with the X-Cloud-Trace-Context header set, I can see the spans recorded by ESP show up in my Stackdriver Trace dashboard.
However, my service is also sending requests to Google Cloud KMS as part of handling that request. I'd like Google Cloud to create trace spans for those sub-requests automatically for me as well; however, attaching the X-Cloud-Trace-Context header that ESP forwarded to me to the sub-requests sent to Cloud KMS does not cause any spans for those sub-requests to show up in Stackdriver Trace. The service account used to connect to Cloud KMS does have the "Stackdriver Trace Agent" role enabled.
Is it possible to tell Google Cloud services (such as Cloud KMS) to automatically generate trace spans for the current request's trace context, or do I need to manually generate traces for these requests in my backend code?
Cloud Trace doesn't currently generate service-side traces for requests to most GCP services, although we're aware of it as a valuable feature. To track how much of your latency is being consumed by KMS (or other services) you can create a client-side trace record using OpenCensus (Github) or similar.
Cloud KMS (as of this writing) doesn't support gRPC, but we are working on it.
I have Requirement of developing a REST API with DB on AWS with Our custom Jar, that will be processing the data coming in the request, once processed we will give a response the result comes from our jar.
We have :
Our Java application that will process the data.
Need to develop Authorisation platform for a various client using REST API.
Need to log all the transaction that is requested and how many are rejected and processed successfully.
We are thinking to deploy the complete application on AWS, so I am looking for best study material on developing and Deployment on AWS that is free (budget issue).
Please suggest where should I start as I am a newbie on the cloud platform.
Thanks in advance for the help.
To save on cost with AWS, try to go serverless architecture.
Use:
S3: to host your front end code by making your bucket a website
Lambda: to host your backend code to insert and retrive from database. You get 1 million requers free per month
Api Gateway: it would provide an interface to access lambda function and detailed logging can be done to cloud watch. It also provides with Authorization with API keys and Cognito user pools.
DynamoDb: it is aws managed database, that give you 15 free read write provisioned throughput
You can start with this
https://medium.com/byteagenten/serverless-architecture-with-aws-adcaa3415acd?source=linkShare-22ecbac0bdc-1526628767
I actually try WSO2 API Manager in our IT and I can't found how to monitor backend WS.
Is there a way to have an alert (trace/mail/...) when :
the time response of a webservice is too high?
the Webservice is unavailable (or http code isn't 200) ?
This tool seems great but I need a monitoring part...
Perhaps I simply miss it...
Any helps ?
If you already use WSO2 APIM in production how do you manage this part?
Regards,
Mike
By Using APIM and CEP integration, you can achieve this requirement. APIM can be configured to publish thrift events into CEP and then CEP can process these events to provide necessary alerts and notifications as required.
Please refer below document for APIM and CEP integration.
WSO2 API Manager has following statistics monitoring
API Subscriptions: Number of subscriptions per API (across all
versions of an API)
API Usage: Number of API calls being made per API
(across all versions of an API)
API Response Times:
API Last Access Times: The subscribers who did the last 10 API invocations and the APIs/versions they invoked
API Usage by Resource Path: Usage of an API and from which resource path (per API version)
API Usage by Destination: To see destination-based usage tracking, you must first enable it. See API Usage by Destination.
API Usage by User: Number of times a user has accessed an API
Faulty Invocations: The number of API invocations that failed to reach the endpoint per API per user In a faulty API invocation, the message is mediated though the fault sequence. By default, the API Manager considers an API invocation to be faulty when the backend service is unavailable.
For more information, please see https://docs.wso2.com/display/AM1100/Viewing+API+Statistics
For our public hosted version of API Manager - WSO2 API Cloud - we simply set up Pingdom for both the gateway and the web UIs and exposed the public dashboard at the SLA & Support page. Pingdom also has email, sms, etc. alerts when response times get over 30 seconds.
Internally we also use various server monitoring tools like icinga.