Is there anyway to see all requests done via REST API?
I want to be able to monitor REST API calls done by a client ID. I want to look into what specific APIs were called, if possible how the request/response looks like for each call.
Just posting this here to help future question posters.
this is where you need to put some kind of monitoring inside your code. I dont think Azure has built in capabilities for tracking specific REST API calls. Application Insights can be customized to do this, yes, but not out of the box. Or, you could just build your own custom logging which is what I would do, have done
The OP has confirmed that this is indeed the case with Azure, after he spoke with the Azure support folks.
I hope you are talking about a web app or a mobile app calling a backend app which is running on azure or somewhere else. So for this the answer is using Application Insights, it is now part of Monitor but built for apps to monitor APM (Application Perf Monitoring).
Related
I am trying to build Serverless Microservice Architecture
Azure services used by me are:
Azure CDN
Azure Active Directory
Azure Logic Apps
Azure Functions
Azure Event Grid
Azure SignalR Service
Which below tools do I need mange and secure my API in Azure Serverless Microservice Architecture?
Azure Traffic Manager
Azure Application Gateway
Azure API Management
Azure Function Proxy
Links Referred by me are :
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/serverless/web-app
https://learn.microsoft.com/en-us/dotnet/standard/serverless-architecture/serverless-design-examples
Please help
Edit:
I understand above tools and it purpose but what I can't understand is do I require them, if yes in what order, all I am developing is an Angular 2+ app, post a Command Event to Azure Functions/Logic Apps using REST api returning RequestId (and triggering chain of events) and subscribing to that RequestId to listen for Domain Event.
This is very broad Architecture question. All the services you mentioned have specific purpose. You can even secure your functions without using any of them by simply turning on authentication on functions.
I would suggest reading all of them in details can help you identify which service may suit your needs in this case. e.g. Traffic manager is used for cross region traffic distribution and may not be required in your case. Function proxies and Api management overlap in few cases and really depends on what you are trying to achieve. To get better idea you may need to share your architecture diagram.
I was wondering if someone can shed some lights on the application monitoring and alerting solution that's being used to specifically monitor the Azure app service. We have multiple API apps running on App service service and we would like to monitor certain metrics (ex: Availability, response time, number of request received, etc). I enabled the application insight on each of these apps and the result is quite promising, it fulfills all my requirement, but there's one small issue: I need to scroll through each app to see their performance. I can't aggregate them all in one space. I would like to create a centralized dashboard for all aforementioned metrics and have them displayed. I tried using OMS but it seems to be lacking a lot of functionality.
Any pointer would be very appreciated.
I wrote recently about it on our blog: http://predica.pl/blog/azure-monitoring-and-auditing/ - you will find link to MS documentation also there.
If you are using App Insights already you should be able to pick things from App Insights and put it on the Azure portal dashboard. Other than that probably getting data into Power Bi application insight is your best shot - https://powerbi.microsoft.com/en-us/documentation/powerbi-content-pack-application-insights/
I'm currently developing a SOA based architecture in Azure, using disparate Web API services (they'd probably qualify as Microservices, but I'm hesitant to use the term).
I have a service which is triggered by the Azure Scheduler. It does some "stuff" and then needs to call another Web API (via HttpClient) service to trigger something else. To do this, I need to know the URI of the 2nd service. When running locally, this is fine, as it is something like
POST http://localhost:1234/2ndService/api/action
However, when I deploy to Azure (using Internal Only as the access level), it gets an obfuscated URI, such as http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58, which I obviously can't guess at deploy time.
Any ideas on how to solve this problem? Or have I made a fundamental error here?
Instead of relying on public http endpoints, have you considered passing messages via queues in Azure Table Services? It's very simple to do and is going to be more robust since you can take advantage of built-in features like guaranteed message delivery.
The overall idea is that Service A does some "stuff" then puts a message on queue ONE. Service B continuously reads from queue ONE until it picks up a new message from Service A (or any other service for that matter) and then does its "STUFF". You can continue to chain calls like this to other services that need to be notified.
If you want a more elegant solution you can look at using Service Bus Topics but the concept is basically the same.
Also, since you mentioned that your architecture is much like microservices, you can check out the new Service Fabric which is designed for your scenario.
In case of Azure Web Apps, you may always see such properties going to the web app dashboard, then properties. When deploying from the Visual Studio, you can set the URL as you want - just checked it, and it works fine.
Not very clear what technology do you use - is it IaaS VM? Is it Web Apps?
From my standpoint, each service should be deployed as a separate Web App (or API App, if you want). Each Web App has defined its own name as in yourwebapp.azurewebsites.net, so once you have provisioned the Web App no 1 in Azure, you know its address so you will call it from the Web App no 2.
In all the cases, you should have fully qualified domain names, and not local/internal ones.
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
is there any way to publish my API in azure mobile service API instead of using its own. I want just to know it, because assume I have a backup server in amazon and as you know I don't have access to azure sdk in there and it means technically I cant use the API anywhere outside the azure.
Azure mobile services is actually based on the .Net web api in their C# flavor and on node.js on the Javascript side. You could surely write an API using those technology and have the same behavior. You will gain the fact of being more portable, however you will lose some of the preconfigured stuff from Mobile services.
If you are using .NET, please check this to see how to build a Web api! http://www.asp.net/web-api.
If you are using Javascript, here is where you should start : https://nodejs.org/
Both tech are quite easy to learn and super powerfull, have fun! When your API is built, you could just publish them as an azure Web APP (http://azure.microsoft.com/en-us/services/app-service/web/) or an Azure API (https://azure.microsoft.com/en-us/services/app-service/api/) instead of the mobile App
Hope it helps, if you have more questions, please ask!
You can create and publish your own custom APIs in azure mobile service. You could even access in via azure mobile service sdk in client by using "InvokeApiAsync<>()" method.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn614130.aspx
If you want to access the api via fidder/httpclient than AZM SDK, pass the mobile service key in HTTP header as Name:'x-zumo-application' value:'application key from portal'