I would like to ask why Operation_Id is duplicate in Requests table.
or what is proper configuration of Application Insights so telemetry will be unique based on opeartion_id ?
requests
| where operation_Name contains "GetFuelPriceAsync"
Every request/dependency telemetry item has the following identifiers:
operation_Id is unique per distributed transaction. So it is by design not to be unique per request
id is unique per telemetry item
parent_Id points to a parent's telemetry item id in a distributed transaction identified by operation_Id
This is based on default behavior of applications instrumented with Application Insights SDKs.
If your web app is also instrumented with JavaScript Application Insights SDK then it starts a transaction per web page. If this web page does multiple calls to your app service then requests originated from the same web page will have the same operation_Id. If your web page is SPA then the current default behavior is that whole session will be treated as one transaction.
Related
Is there a way to fetch (via iOS) the current number of Firestore API requests an app has used for the day / week / billing cycle?
I'm trying to see if I can fetch this value to display it to the user. I know some database services offer this as a service in order to determine how many requests are remaining.
There is no such client API available. You are always free to file a feature request.
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.
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.
Does kaa has an api to list all registered end-point/devices for an application by application ID? Or do we have to parse the registration logs to get a unique list of end points? Thanks.
As commented #Pete you can list all registered end-point/devices for an application. Every Kaa application, when created, becomes a member of the default group all. See Using endpoint groups documentation. Also look at corresponding Server REST APIs Grouping and Profiling documentation sections.
Assume that you are developing a web application that shows currency
exchange rates for a bank web site. The rates are stored in an IBM
Mainframe in the bank and rates are available through web services.
Each time a user accesses the rates page, the page makes a request to
the mainframe. This generates too much load on the mainframe.
Especially most of the time the rates delivered is the same. How would
you design a caching architecture that minimises the trip to the web
service. But at the same time rates may fluctuate within the day and
if rates have changed the rates web page should not display the cached
values but make another request to the web service. How would you
design such a caching architecture and make sure it is invalidated on
rate changes? Please explain by drawing a diagram.
Can you tell me in this scenario how ASP.net will know that values are changed? what should I do?
The "Mainframe" must advertise to Web that the value has changed.
So you can, for example, implement another web service called "InvalidateCache()" that would empty the cache when called.
When the rates change, "Mainframe" would call InvalidateCache service which would empty the cache so that subsequent request to the Rate service would call Mainframe for new rates.
Following is the description:
Make a new webservice which stores just a token, that token could be anything like datetime or you can generate the token from any other algo.
When the user comes to that page on which currency rates needs to be shown, browser make a hit to that new service along with token.
If the client token matches with the server then the service returns true response otherwise false and sends the updated token too.
If response is true then the browser gets data from it's cache.
If it's false then the browser stores the updated token and calls the main webservice gets data from there and stores it in it's cache.
Whenever the currency rates changes, token in new webservice needs to be updated.