When I deployed my app to Azure App Service I got quite awesome telemetry out of the box.
Some of the telemetry data is generated by the App Service itself, some of it by my ASP.NET Core app that is using Application Insights logging.
As a result I could find out slow http requests, all application and IIS logs related to the request and see a nice chart showing where the time was spent, e.g. waiting for a SQL query or some http call.
I wonder how much of this telemetry can I get if I decide to go with Azure Container Instances.
The telemetry collected from the application itself using Microsoft.ApplicationInsights.AspNetCore SDK- you'd pretty much everything of that irrespective of where app is runnning - vm or container or app service.
from https://learn.microsoft.com/en-us/azure/azure-monitor/app/docker
When you run the Application Insights image on your Docker host, you get these benefits:
Lifecycle telemetry about all the containers running on the host - start, stop, and so on.
Performance counters for all the containers. CPU, memory, network usage, and more.
If you installed Application Insights SDK for Java in the apps running in the containers, all the telemetry of those apps will have additional properties identifying the container and host machine. So for example, if you have instances of an app running in more than one host, you can easily filter your app telemetry by host.
Related
In our scenario, we are trying to Dockerize the Asp.net framework 4.6 based Web API that logs on the server using Nlog.
Currently the application is hosted on IIS web server.
The question is how / where to store the logs when the application is rehosted on Azure kubernetes
should I use something like application insights
You can use the Azure Monitor including Application Insights to have your application logs.
Here is the official documentation on Azure Monitor for containers
Azure Monitor for Containers supports consuming logs from not just
Kubernetes but also from other orchestration engines such as DC/OS,
Docker Swarm, and Red Hat OpenShift.
Azure Monitor for Containers is perfect for Infrastructure monitoring and Application Insights which is now part of Monitor as well would be excellent for APM.
Application Insights for .NET
https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net
We are running our application using Azure App Service. It is based in .NET FW 4.7 with Webforms and API Rest. We are using PC3 App Service Plan (16GB RAM). The application is stateless and it supports the Application Service scale out without a problem.
In a first step to modernize our infrastructure, the application was packaged in a Windows Container and it is executed in an App Service. The image is based on mcr.microsoft.com/dotnet/framework/aspnet:4.8 and uploaded to ACR. The problem occurs when trying to scale out the application. At the time of scale-out, the new container is added to the balancer and some requests are answered with "The Web App's container is starting up!"
Is there a way to add the new container to the balancer only when it is fully functional?
Note: I don't know if this is related to the problem but it appears in the log:
CONTAINER_HEALTH_CHECK_MODE app setting is set to ReportOnly. Container will not be recycled. For container to be recycled when it becomes unhealthy set it to Repair
I was looking to use Azure App Services and noticed Azure now offers Web App for Containers, now I wonder what's the difference between them? And couple more questions come to my mind
Assuming I choose Web App for Containers, who is going to manage the container updates?
Is the deployment differs from App Services to Web App for Containers, from application perspective?
Web App for Containers is one of the offerings in Azure App Service. It allows you to deploy containerized applications on Linux and Windows (the latter is in preview).
The platform automatically takes care of OS patching, capacity provisioning, and load balancing. But, the container updates are up to you.
The deployment differs in that you will be deploying your application inside a Docker container instead of deploying directly like you do in a Web App.
I've been doing some research on how to try to organize an Azure system and would like some feedback on improvements.
I have a web interface that clients will be using. Think of this as a dashboard. This dashboard needs to kick off long running Selenium C# console jobs that run inside a Service Fabric console application.
What is the best way to implement this architecture without having an application constantly run listening for Service Bus message queue messages? I'm thinking during development this could really eat up $.
Initial design thoughts were:
Web app for dashboard - customer facing
The above web application needs to kick off a Service Fabric console application that runs Selenium ChromeDriver.
I was going to achieve this by implementing Service Bus on the web request, and then a listener console application inside Service Fabric that will spin up the Selenium ChromeDriver console application.
Is there a better way to do this aside from having a constant listening polling handler application always running?
I'm not sure how to trigger the Service Bus console application without having the Service Bus listener.
Unless you are talking about Azure Service Fabric Mesh, which is currently in public preview, hosting any process as a Service Fabric application requires a Service Fabric Cluster, meaning you have a Virtual Machine Scale Set running 24x7. Given this fact, I don't understand this part:
What is the best way to implement this architecture without having an application constantly run listening for service bus message queue messages? I'm thinking during development this could really eat up $.
You are already paying for the cluster anyway.
You might be better of skipping Service Fabric and spin up a container doing the work using Azure Container Instances and bring it down once the long running job has completed.
What is happening behind the scenes when an App Service is restarted?
I'm trying to troubleshoot a slow restart for my app (ASP.Net and Sql published from Visual Studio) and I feel like understanding this would help me know what the issue is. My app starts within a few seconds on my dev machine but takes 90 seconds on Azure.
From my research, it sounds like a new service instance is provisioned, application files are copied from the shared storage to the instance and it is started. Is this correct? Is there a way to monitor the startup process to see what is slow?
Edit:
It's a tier S1 service plan. The app isn't slow, just the restart. I was hoping to understand the process so that I could understand whether the slow startup is due to my code or just the nature of the way the restart works. I've noticed that my app runs for about 10 seconds after the restart (refreshing the page), then I get a service unavailable for about 20 seconds, then the page is loading until for about 60 seconds.
It all depends which app service plan you are using, different plans have a different memory, network bandwidth, IO etc, App Service runs customer apps in a multi-tenant hosting environment. Apps deployed in the Free and Shared tiers run in worker processes on shared virtual machines, while apps deployed in the Standard and Premium tiers run on the virtual machine(s) dedicated specifically for the apps associated with a single customer.
Refer to this link for a guide on Troubleshooting slow WebApp in Azure.