I'm using Google Cloud's StackDriver for tracing requests to my classical AppEngine rest server. Unfortunately, it handles request for URLs like:
/product/{id}
as a separate entry for each id, so I have, for example, statistics about each user separately. My code (REST backend in classical appengine) have about 10 endpoints, but StackDriver thinks I have millions, rendering it's analysis almost useless.
How do I make StackDriver correctly handle all URLs that use a given pattern (wildcards? regex?) as the same thing?
Related
I've been trying to migrate my solution from Google Cloud App Engine to Google Cloud Run and have been struggling a lot.
I have 3 services in app engine for each staging environment, let's call them api, front1, front2. front1 has custom domain name assigned www.example.com, as well as staging subdomain www.dev.example.com. Using dispatch.yaml rules I route requests to appropriate services, for example: requests containing api/* are routed to api service, default path routes to front1, /foo* routes to front2. Everything is working there perfectly well, however, hosting the solution on Cloud Run would decrease the costs a lot.
So at the moment, I am really struggling to understand how could I fully replicate this behavior in Cloud Run. I've tried following firebase routing, but it requires to host an app on Firebase as well and doesn't route all traffic for route /api/** to my api service.
I've tried following this article, but I cannot select my service since I selected Internet Network Ednpoint Group option for backend type, which only can point to a single url. Also, I am not sure if it will support wildcard routing there.
I'd highly appreciate any help here, I am totally out of options at the moment.
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.
We use your service REST api 7.2v, and your Android HERE WeGo (version 2.0.12509) app in offline mode. Our goal is to be able to create a route using the Routing API - route from A to B (fastest;car) and then send the information to the mobile app.
The expected result would be that from the suggested routes on the mobile app, the first one would be the fastest route, and it will correspond with the one that we created using the api.
The problem: fastest route shown on the HERE WeGo app is not corresponding with the one given from the API call. Also, we noticed that the information for duration and distance that we get from the api, are different on the mobile app for the same route.
Questions: Is it even possible to get the same route results? Are we missing a parameter? Can you give us a suggestion.
The offline and online algorithms are different and will continue to be different because of the resources available to compute the routes are different on hi-perf servers vs constrained devices. So it is not possible to get the same route results. Also the Here We go app comes in online mode, so the best approach is to get the route directly instead of using REST API and sending it in mobile app.
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.
Say, I'm developing a Windows (if OS is important) application that will be available to download for free and I would like then to collect some usage statistics. In the easiest case - count of application launches. It looks superfluous to maintain a server (e.g. VDS) just for this.
I've been thinking to use Google Analytics for this (manually send requests to GA server). This will probably work, but it is not GA designed for - the idea looks like a hack.
What are the options here?
I don't think this is a hack. It's all just data about user interaction. There is little logical difference between opening a desktop app and clicking a button vs opening a web page and following a link. Both are measurable user actions you can track, aggregate and put on graphs.
In fact, Google provides a lower level HTTP based "Measurement Protocol" that is intended for exactly that.
https://developers.google.com/analytics/devguides/collection/protocol/v1/
From the overview:
The Google Analytics Measurement Protocol allows developers to make
HTTP requests to send raw user interaction data directly to Google
Analytics servers. This allows developers to measure how users
interact with their business from almost any environment
Just put an HTTP request with the correct parameters in your application launch or button click code and it will collect the data. Any data you want to collect.
In other answers to this question there are suggestions like making web services or storing the data locally but why reinvent the wheel? Google Analytics already provides the collecting and reporting tools and it seems like a good solution.