I have a console app that is made using Azure Webjob SDK. The app makes calls to 3rd party website and performs some logic (authentication, posting some data, etc).
The app works on local machine just fine, but when I deploy the exact same app on Azure as a WebJob then it's not working as expected. The 3rd party website logs the client out after some requests being made (randomly without any patterns as I see it). No exceptions detected in the app itself. This is very confusing since the code is the same and I'm wondering what's the difference between running on local machine vs running on Azure.
Usually I would use Fiddler to see what's going on with request/response during those website calls. How to do that on Azure? How can I see all the requests/responses made by that app? Are there any tools for it?
You could go for remote debuging, as suggested in the comments. It will let you step through the execution of your code.
You could also enable Application Insights in Azure, integrate it in your webjob, and start collecting logs and detailed diagnostics. This way you will get detailed information about the execution of your webjob.
Related
My app needs a background service that constantly receives and handles events streamed from an Azure Event Hub.
I see that Azure Functions has built-in triggers for this, but the problem is that my app is written in .NET 5 and Azure Function support for it is fairly immature at this point.
I also see from this documentation that .NET has an readily-made SDK Azure.Messaging.EventHubs. My understanding is that this will run as a console app.
I'm already using the Azure App Service (Linux plan) to host the main web app.
So if I create a console app using Azure.Messaging.EventHubs, I'd want to deploy it as something like a web job, but the Linux app service plan doesn't support it. I guess I can deploy the console app it to a separate Windows App Service plan.
What's the next best option? Are there any practical differences compared to using Azure Functions?
There's also this .NET Core Worker Service that's more optimized for background services. I wonder if there's a place for it in this use case.
These options are confusing me a bit. Your advices would be greatly appreciated.
Azure function should be the best choice. It has the built-in eventhub trigger and process logic, and easy to setup / configure(like logging via Application Insights) / less code to write. And recently(Mar 10 2021), it is supported for running production .NET 5 apps on Azure Functions. I suggest you can give it a try and use it if no issues.
For azure webjobs, in this case, if you're directly using the SDK, you need to write many codes and configure something like logging.
For .NET Core Worker Service, it can also be published as azure webjobs if you want to use it. You can follow this doc on how to publish worker service as azure webjob.
We are migrating to Azure. We have a Web App deployed. However, I have a Windows Service that I need to add in to the mix. The service continuously runs, checking the associated Service Bus Queue for messages every 5 seconds.
I am looking for recommendations on how to do this.
I have looked at Web Jobs. But, I don't understand how it gets kicked off. I know there is a Web Hook involved - but I just want the code to run continuously without having to be constantly kicked.
We are also trying to avoid the cost of having a VM involved.
Thanks in advance.
Since you already have a web app, you could use a Azure App Service to run the Web App. The Azure App Service will allow you to also have a Web Job that you can have run on a schedule.
It does not make sense to break you web app into Azure Functions since it is already built. You can have the service run in an Azure Function, but it will probably add more complexity to interact with the web app (if that is what is happening) and if the service is running every 5 seconds, that could get costly.
I am running my asp.net C# app on azure appservices in a reasonably good plan and I am getting a really slow app initialization. This happens every time I deploy or restart the app.
At first, I thought my global.asax Application_Startup was taking too long to load configs from the database. But then I realized that it is taking over 20 mins before it even hits my Application_Startup.
I'm looking for ideas on where to look for the root cause of the problem.
Many thanks
I would suggest to check for Azure Metrics logs to get more details, also one of the best thing which I love to do is remote debugging on Azure app. You can check below post for more details on remote debugging:
Remote debugging Azure App Service
When the MVC application is deployed to azure environment, there is slowness in page loading and also response time of web site get delayed for few seconds once the deployment is done.
When the application is deployed in production environment, this slowness make the bad user experience.
Automation test scripts fails due to delay in response of site immediate after deployment
Deployment is done from Visual studio 2013 to Azure Web App services using Visual Studio Publish option settings.
What we have tried:
Deployment is scheduled once in 30 days and also in mid night, however the user in other part of world face issues when deployment happens.
Can some one help me to resolve issue and there should not be any difference to user when deployment happens in production.
There is a slight increase in loading time, for the first request, after an application is deployed to an Azure Web App. What happens behind the scenes is that the underlying web application must pre-compile the MSIL into machine code before it can serve the site. See https://msdn.microsoft.com/en-us/library/ms366723.aspx for more details.
The application pool, used by the Web App, is also regularly recycled in case of in-activity. The same pre-compilation happens then as well. This downtime can be minimized by enabling "Always-On" for the Web App. See https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/ for more details on how to enable it. The always-on feature regularly pings the site to keep it from going inactive.
Also, to minimize downtime, when doing a deployment to a Azure Web App. Have a look at using deployment slots, https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/. Idea here is that you first deploy to the deployment slot (an own web app instead, get it warmed up) and swap it to be the production slot. This way achieving minimal downtime for the Web App. To automatize this process there is a feature called Auto Swap https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#configure-auto-swap-for-your-web-app that does this for you.
Deployment slots are available for standard and premium apps while always-on is available for basic, standard and premium apps.
I have several web and worker roles in my solution, but I also have a non-Azure application running on a Azure hosted VM. That application connects to Azure storage for various things like reading and writing blobs and queues, and that works fine.
I'd like to use Azure diagnostics from within that same application (a .NET app running on a VM hosted in Azure). However, if I try to initialize diagnostics I get an exception that:
System.InvalidOperationException: Not running in a hosted service or the Development Fabric.
This makes sense, but I'm wondering if it's possible to use the diagnostics in some way without being a hosted service. In particular, I'm using azure diagnostics to gather logging information, written out by System.Diagnostics.Trace, and that's all hidden away from the application code, so if there were some other APIs I have a place I can probably slot that in.
Any ideas?
Thanks,
JC
Unfortunately, no. At least not today. The agent has some hard-coded checks for the RoleEnvironment stuff and when it is not there, it fails. This is also the reason you cannot use the agent in the IaaS stuff today either.