I am running WSO2 APIM 2.1.0 , I am setting Tier Availability to Unlimited . Still getting 429 too many request error while doing load testing.
You need to make changes as per given in document.
If you have custom throttling policies, it has some issues with WSO2-2.1.0. Better to get upgraded to wso2-2.6.0.
There are many possible reasons for this kind of issue.
Are you trying throttling scenario on unauthenticated API? When you are going to add a new Subscription level throttling tier in the admin portal, you could see the existing list of subscription tiers in the Subscription Tier List. In this list, you will find a tier named Unauthenticated which has a request quota of 500. This is a subscription tier that automatically applied when the authentication type of your resources is 'None'. That is used when you can invoke APIs without tokens. And this tier is not visible in the Throttling tier list of the application.
Please check the Traffic Manager node connectivity.
Check whether any other throttling tier like application, API, resource level are published with the API.
Check the unit time while you are getting the throttled out response. Invoke the API after unit time getting passed. If the unit time is a larger value, then you should restart the server and try again.
Check the throttling configurations in the gateway, traffic manager, and the publisher.
Related
Is there a way to see the response to a request in the logs generated through appinsights?
I’ve got several apis, and I can see the client making the calls when querying the requests table, I can see the status of the request but I can’t see what was sent back to the client.
Also when I click appinsights in my APIs it says
‘Set up app insights without changing code’
But above it, there’s a green tick saying ‘connected by Instrumentation code’
Does this mean it’s connected and working?
Does this mean it’s connected and working?
Yes, Application Insight connected to API.
Is there a way to see the response to a request in the logs generated through App insights?
If you want to see the response of your request/Custom Events or Custom Metrics, you need to use the Custom Telemetry in your API to get the response in Application insights.
Note: Make sure you can use it for testing purpose. In an application insight who ever have the access of your subscription of the specific resource they can view the telemetry data.
Reference
Custom Metrics in API
We have integrated Azure Application insights with our bot built using Azure bot framework using node.JS and typescript. Everything looks fine and we can see telemetry data flowing in.
In the failures section, we can see Operation name "GET /api/messages" showing repeated times - one failed call (405) and one success call (200).
But we have no GET operation being done on "/api/messages" in our code. We only have "POST" operations.
We are unable to understand why telemetry shows GET operation and one as failed and one as success.
Any help is appreciated.
The operation_SyntheticSource field of request telemetry is often used by microsoft / azure to indicate traffic that is generated by infrastructure or bots. Examples are health requests, keep alive traffic, spider bots.
There are options to filter out telemetry, so it is possible to filter out telemetry cause by synthetic traffic. See the docs.
Telemetry processors can be configured using DI.
I have setup APIM (2.5.0)and Analytics. I have some users and few of the APIs created by the user.
For instance, one of the user onboarded one of the free API which is providing the weather information.
Another user subscribed it from store and started consuming it. At the end of the day, there were around 20 hits from the user to consume weather API.
But, among this 20 hits, 2 hits didnot fetch any result from the weather API URL (URL which we configure in Production and Sandbox URL of the publisher) as the connection was down but the as the APIM was running and allowed the user to consume, the logging continued and produced 20 hits for the user but technically it should be 18 hits only ( as 2 hits were not completed).
How to overcome this case, where the APIs are external and they onboarded in WSO2 APIM (using swagger or manually created) and logging is maintained so that TOTAL_REQUEST_COUNT should come out to be same of the positive hits/response.
Any information on this topic would be helpful.
Thanks
If you are maintaining TOTAL_REQUEST_COUNT it means the request you are getting which is 20 & it's correct. There should be another parameter you should have which will be TOTAL_RESPONSE_COUNT it will maintain the response count. So that you will get to know how many request are coming & how many got responded. Also if you want to see successful response count, have something `TOTAL_SUCCESS_RESPONSE_COUNT.
If you are having backend services in tomcat, then always make sure that thread count in WSO2 should be always greater than thread count of tomcat. WSO2 threads can be configured in <WSO2AM_HOME>/repository/conf/nhttp.properties. Look at last couple of lines in this file.
Also, you can change your retry policy by making changes into API publisher :9443/publisher by editing existing API.
Wanting to validate my ARM template was deployed ok and to get an understanding of the telemetry options...
Under what circumstances do the following get logged to Log Analytics?
DataPlaneRequests
MongoRequests
QueryRuntimeStatistics
Metrics
From what I can tell arduously in the last few days connecting in different ways.
DataPlaneRequests are logged for:
SQL API calls
Table API calls even when the account was setup for SQL API
Graph API calls against an account setup for Graph API
Table API calls against an account setup for Table API
MongoRequests are logged for:
Mongo requests even when the account was setup for SQL API
However I haven't been able to see anything for QueryRuntimeStastics (even when turning on PopulateQueryMetrics) nor have I seen any AzureMetrics appear?
Thanks Alex for spending time and trying out different options of logging for Azure Cosmos DB.
There are primarily two types of monitoring paths for Azure Cosmos DB.
Metrics: These are low latency (<5 min) and aggregated metrics which are exposed on Azure Monitor API for consumption. THese metrics are primarily used for diagnosis of the app for any live site issues.
Logs: These are raw request logs coming at 2hours+ latency and are used for customer for primarily audit scenarios to understand who accessed the data.
Depending on your need you can choose either of the approaches.
DataPlaneRequests by default shows all the requests across all the API's and Mongo Requests only show Mongo specific calls. Please note Mongo requests would also be seen in Data Plane requests.
Metrics would not be see in Log Analytics due to a knowwn which our partner team is fixing.
Let me know if you have any further questions here.
I need to run a report which needs to extract information from a WCF service which is running as an Azure Web App. Unfortunately, there are about 6000 requests I need to run and they MUST be run individually.
When I throw the entire book at the service, I get
ASP.NET rejected this request because the queue limit was exceeded.
I can't find any information which says what the Request Queue Limit is per pricing tier.
Does anyone know what the limits are?
This is not an Azure limit, the queue length is IIS/CPU/Memory bound. See this ServerFault answer for a brief explanation. You should consider having your app queue/throttle the requests with a mechanism like Azure queues.