I am hosting a few WebJobs app services and I like to use the Health check feature included in Apps Services.
My worker job applications do not expose any http endpoints. Therefore exposing the path /api/health explained in this article does not apply to my senario:
https://azure.github.io/AppService/2020/08/24/healthcheck-on-app-service.html
We we have health check options other than exposing a HTTP endpoint?
Is there any way to have App Services does health check by checking a file in file system - like creating/deleting a file to check a file's update date?
There isn't anything out of box so it's something you'll have to implement yourself. Something like the WebJob calling some sort of webhook in your while(true) and if that webhook isn't called after a certain period, fire off an email or something that affect.
Another option is to utilize App Insights. Check the Logging documentation but you could tie into App Insights and feed that into Monitor and configure alerts.
Related
I would like to know how to create health checks for some Azure services? Is this possible? I thought of creating time-triggered Azure functions that would test the end-to-end connectivity of for example my Azure storage, Azure map, and Event Hub but it would fail if suddenly my Azure functions would stop working.
I would like to have some kind of Cachethq, but for all the Azure services that I use for my application.
Is there a best practice for this?
Kind Regards,
Normally you would have an endpoint that checks any relevant subsytem for errors. This could be a public available /health endpoint. Some frameworks like Asp.Net Core has built-in support for health checks.
An http triggered Azure function like you propose could also do the trick.
Then you need something like a watchdog that calls the health endpoint at a given interal. In Azure you can use an availability test. If you want you can create alers based on this availability and create dashboards that show the status over a given period.
If you are hosting your app using Azure Web App you can use the built-in health system as described here
If you have a load balancer or gateway in front of your app you can use the /health endpoint for health probe endpoints of those balancers/gateways.
I have a Node.js functions app running in azure and it is processing thousands of requests every minute, I would like to enable Application Insights using the Azure Portal in order to diagnose an issue but I fear this may interrupt the function while it configures itself.
Is this a valid concern?
All the documentation I have found regarding Application Insights does not mention the impact on any running applications.
Adding AI integration is only a matter of adding a key to app settings, but any edits to app settings require a function app to restart, so yes it will affect your function.
I did some tests, and I made a request to it after enabling Application Insights. It will indeed be affected for a few seconds because it will change the app settings and then restart the Azure function.
As part of our production environment we have several App Services running inside of Azure. I would like to implement notifications to be sent to a specific email address upon file or configuration changes within those App Services. I have tried enabling Application Changes for the service but it does not appear to provide the capability to set up alerts on the changes,
I have also tried enabling App Service alerts but it does not appear that any of the test configuration changes that I have made were captured by the signal "Apply Web App Configuration".
The last thing that I tried was to enable Diagnostic Settings to capture AppServicePlatformLogs and AppServiceFileAuditLogs and stream them to an Event Hub, however, I cannot determine how to set up the email notification from the hub for the events.
I am hoping that there may be an easier way to set this up and was hoping that someone may have some pointers or resources that I can follow.
I was able to accomplish this under "Monitoring" -> "Alerts". A more detailed walkthrough can be found here https://perituza.com/blog/azure-app-service-monitoring-and-alerts/. The key was selecting "Activity Log - Administrative" as the Monitor Service in the Condition.
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).
I have a web api(.netcore) which I have hosted in Azure under an app service.
I have another app related to the above api(in the same resource group) which need to be triggered every few minutes.
My confusion is what is the best practise?
1) Write a webjob app(.net framework) for the second app.
2) Write the second app as an api and write a console app to call the api. Then call the console app from the webjobs in Azure. But that would mean a second app service in the same resource group(for second API).
Is there any pricing difference between the two?
Is there any advantage of one over the other?
Is there any better way?
Update
I have gone with the second option.
Is there any advantage if I go with the below(cost and code vice).So in the same app service there will be a wep app, a webjob to trigger the api and another webjob to read message from queue do the processing.
There are a few options for writing a service that is triggered on a timer:
WebJobs - These are essentially console apps that run behind the scenes to do related jobs that users of your API don't need to wait on (photo processing is a common example) or need to be run on a schedule, like your use case.
Azure Functions - Functions are similar to WebJobs, but make it easier to scale and abstract away the necessity of coding up connections to a lot of other services. They also can have billing advantages if you are creating an App Service just to run them.
Azure Logic Apps - I think you want either WebJobs or Functions, but Logic Apps can also run a job on a schedule. In this case, you are designing your workflow either in JSON file or more likely in a GUI. If your job doesn't require much custom code, using a Logic App means that development time is reduced and you have one less piece of custom code to maintain.
For pricing:
Both Webjobs and Functions can be attached to the same App Service account as your API as long as you have sufficient resources there to handle the additional load. So no additional costs there.
You could pay for a separate App Service account for the Webjob if you want, but usually they are kept on the same App Service account as the API.
Functions apps can run on a special type of App Service account that has a consumption plan. What that means that instead of a monthly fee, you pay for the resources that you actually use.
Logic Apps aren't connected to App Services, and have consumption based billing similar to Functions.