I have an existing mvc web app running on azure websites.
I have set application insights running on it whilst it is live.
Is this recommended practise? Will this have any impact on my site whilst it is running? is it okay to leave this running as it provides very useful data...
Many thanks
Absolutely, Application Insights is intended to be able to run in production alongside your applications.
One of its purposes is to help you track the health of your application and assist you when something goes wrong.
While it is optimized to operate as silently as possible, impacting your performance inevitable. Unless you're tracing a lot of custom data or very performance-dependent - you should be fine.
Related
We have an app service that needs to be monitored and notify a set of users when it is down.
Right now, I am just using Activity Log's Service Stopped to check for it.
What more conditions can be added to make it work in many scenarios as possible?
Thank You
Thanks for raising a question and contributing to Stack Overflow.
As Daniel has mentioned you could use Azure Monitor and Application Insights.
Application Insights would also be a better approach, since it helps collect telemetry from your application to analyze its operation and performance.
You can use this information to identify problems that may be occurring or to identify improvements to the application that would most impact users.
Also you can go through the below doc for more reference : App Service Performance
I have an issue where heroku apps goes idle every 2mins, which makes the user wait a few minutes to get a payment request. Is there a way to solve this issue? Also what are some good alternatives to heroku? I'm also seeing low scores on Google Page Insights and I'm guessing that's because heroku is idle most of the time. My app is built in nodejs and react
There are many different deployment solutions available; It really depends what kind of functionality is important to you as a developer. There are other Heroku-esque solutions, such as Netlify who over CD as well as Git integration. Any cloud provider will also be able to do a good job of hosting your application at a low cost. I personally, use Amazon Web Services, but Google Cloud, and Microsoft Azure will do an equally good job.
You can deploy your Node/React app to an AWS EC2 instance, as long as you're reasonably proficient at Linux system configuration, and it will be extremely low cost and very fast.
We have a running site using NLog for logs. We are not only login errors, we use it to measure things relative to business logic.
Now we are moving to Azure and that's why I'm searching for a better way to log this type of info in azure. I'm looking for something like graylog.
Things to have in mind:
What azure provides to log info is easy to read?
Can i make queries to read data?
Is there an API to log?
Check out the following stuff, which is more or less native to Azure. Also you could probably use some of the third parties, like New Relic.
Log Analytics
Application Insights
Operations Management Suite
Application Insights not only has out of the box monitoring but also provides capabilities to create your own queries.
ps. Just my 2 cents, I'd go for OMS, Microsoft is pushing it oh so hard, it is evolving rapidly, even if you are missing some capabilities they are going to be there soon and in the long run, Microsoft is really unlikely to drop OMS anytime soon, since they started forcing it like 1.5 year ago.
I have the following setup
Customer access -> Web application -> Database
A Server application (console based) for each customer running in the Server continuously that downloads data from various locations and update database
So if i am having 100 customers, i will need to run 100 console applications in the server.
If there is any problem/crash with one server application(because of specific kind of data i am downloading), i will be able to fix it by restarting or patching.
I took this approach as i initially thought it is easy to maintain. But feeling not anymore. I am sure there are better tools available outside to manage this kind of scenarios. If you know any please let me know. I should be able start/restart/patch/monitor server usage/check for crash on the server application through some nice GUI.
Or may be there is a way to write one multi-threaded application to serve all customers instead of one for each. And there may be a way to shutdown/restart the any customer's thread.
Thanks
The right way is to use a threaded application that can set your tenant context for the process that needs to be done for that thread.
This way, we have 1 app for all customers and van make use of application events and mailers to notify on case of any error.
An audit table with track of the various data processing status can help in a GUI to be built for tracking the progress on a tenant basis.
HTH
I've been reading about azures storage system, and worker roles and web roles.
Do you HAVE to develop an application specifically for azure with this? It looks like you can remote desktop into azure and setup an application in IIS like you normally can on a windows server, right? I'm a little confused because they read like you need to develop an azure specific application.
Looking to move to the cloud, but I don't want to have to rework my application for it.
Thanks for any clarification.
Changes to the ASP.NET application are minimal (for the most part the web application will just work in Azure)
But you don't remote connect to deploy. You actually build a package (zip) with a manifest (xml) which has information about how to deploy your app, and you give it to Azure. In turn, Azure will take care of allocating servers and deploying your app.
There are several elements to think about here -
Code wise - to a large degree this is 'just' .net running on IIS and Windows, so everything is very familiar and all the past learnings, best-practices, etc. apply.
On top of that you may want to leverage some Azure specific capabilities - for example table storage, or queues, or interacting with your deployment - for which you might need to learn a few more APIs, but these aren't big, and are well thought of and kept quite simple, so there's not a bit learning curve. good architecture, of course, would look to abstract these away to prevent/reduce lock-in, but that's a design choice.
Outside the code, however, there's a bit more to think about -
You'd like to think about your deployment - because RDP-ing into a machine and making changes that way takes away many of the benefits of PaaS - namely the ability of the platform to 'self-heal' by automatically re-deploying your application should a server fail.
You would also like to think about monitoring - which would need to be done slightly differently.
Last - cloud enables different scenarios, and provides a scale-out model rather than a scale-up model, which you might want to take advantage of, but it might require doing things a little bit.
So - bottom line - yes - you could probably get an application in Azure very quickly, without really having learning much or anything, but to do things properly, and to really gain from the platform, you'd like to learn a bit more about it. good thing is - it's not much, and it all feels very familiar, just another 'framework' for .net (and Java, amongst others....)
You can just build a pretty vanilla web application with a SQL backend and get it to work on Azure with minimal Azure dependencies. This application will then be pretty portable to another server or cloud platform.
But like you have seen, there are a number of Azure specific features. But these are generally optional and you can do without them, although in building highly scalable sites they are useful.
Azure is a platform, so under normal circumstances you should not need to remote desktop in fiddle with stuff. RDP is really just for use in desperate debugging situations.