I have hosted a node.js app using an azure VM connected to a cloud service. Now i am trying to figure out how many sessions have hit that endpoint and their usage around it like, server response time, latency, memory usage, disk usage, unique users etc. Is there a way to get it?
If you're using VMs, you need to implement logging mostly by yourself.
Azure, using the Portal, allows you to view metrics for the VM, like CPU and memory usage. However, to get application-level metrics, such as response times, number of requests, etc, you need to design your own solution.
If your Node.js application communicates with the Internet through a reverse proxy (e.g. Nginx, IIS, etc), then you could fetch those metrics from your web server's logs
Otherwise, you'll have to implement logging inside your JS code. The correct way depends on the framework you're using (if any): Express, Koa, Hopi, etc.
On the other hand, were you using PaaS (Azure Web Apps), you'd get most of these metrics automatically.
Related
My Azure setup involves two web apps and a PostgreSQL server. One of the web apps is a Node frontend, which should be available to the public. The other is a Python backend, which receives requests from the Node app and communicates with the Postgres database. The Python app contains HTTP endpoints that should not be available for anyone to access.
What is the recommended approach to protecting this Python app from unwanted traffic? Should I be blocking traffic outright through some sort of Azure configuration, or simply authenticating my HTTP requests?
I've tried only allowing the outbound IPs of the Node app to communicate with the Python app, via the Azure configuration. However, this seems to have left the Python app unable to communicate with the database, and additionally I can't even SSH or view its logs with this configuration.
It really depends on what your requirements are. If cost is no option, one way to protect the python app is to put it on an App Service Environment (ASE). This is an isolated instance of Azure Web Apps that you can protect behind an Internal Load Balancer. This solution will give you more security as you can enable a Network Security Group to block out Internet traffic and you could setup your Node App to communicate with your VNet with a VPN. This approach is also one of the more expensive approaches for a PaaS Web App.
Other options include setting up your "back-end" python as IaaS (but then you have to manage the updates), or you can use an App Gateway or 3rd party WAF device like KEMP (they have a 200 MBps device that is free) to protect you app.
Finally you can look at a scalability design where you put a queue or some other intermediary between your two web apps. This will allow for independent scaling and give you the opportunity to lock-down the Python app to only accept messages from the queue, not your front-end. A sample arch can be seen here (you can sub the function in this arch for your python app)
Can I use one azure mobile app as a backend to support for mobile app and website?
I need it to support push notification and authentication as well as CRUD operation. Should I use API app or Mobile app or something else?
An Azure Mobile App is just a regular ExpressJS app with the Azure Mobile Apps SDK implemented. Here is a good example of a combined web + mobile:
https://github.com/adrianhall/azure-mobile-apps-html-quickstart
The 'public' directory contains the static website, complete with JS and CSS files. The app.js is your app (note the serve-static module usage to serve up the static content).
Now that Mobile App, Web App, and API App are under one roof so to speak you have several options.
They are all part of App Services.
The easiest way to think about App Services is in terms of a VM that hosts multiple web apps in isolation.
You create an App Service that is like a VM and then you create multiple apps that run in that VM.
You could create a Mobile App and a completely separate Web App that share a common database for instance.
You pay for the App Service instance, not each app, so it's really up to you how you want to divide up the functionality.
Now before someone cries foul on my VM analogy, I said it was the easiest way to visualize it, not the most accurate.
What you really get is a "Virtual Virtual-Machine" that could be one or many VMs. You see it as one logical thing in terms of management, deployment, etc. but it could really be multiple VMs. It can scale up or down based on your configured options (eg 1 VM always, scale up to 5 VMs if CPU or Memory exceed thresholds you set, etc.).
I have my website (abc.azurewebsites.net) hosted to Azure Web Apps using Visual Studio.
Now after 1 month I am facing problems with traffic management. My CPU is always 90 - 95% as the number of requests is too high.
Does anyone know how to add Traffic Management in this web app without changing the domain abc.azurewebsites.net? Is it hard coded in my application?
I thought of changing the web app to a Virtual Machine but now as it's already deployed I am scared of domain loss.
When you Scale your Web App you add instances of your current pricing tier and Azure deploys your Web App package to each of them.
There's a Load Balancer over all your instances, so, traffic is automatically load balanced between them. You shouldn't need a Virtual Machine for this and you don't need to configure any extra Traffic Manager.
I can vouch that my company is using Azure Web Apps to manage more than 1000 concurrent users making thousands of requests with just 2-3 instances. It all depends on what your application does and what other resources does it access too, if you implemented or not a caching strategy and what kind of data storage you are using.
High CPU does not always mean high traffic, it's a mix of CPU and Http Queue Length that gives you an idea of how well your instances are handling traffic.
Your solution might implementing a group of things:
Performance tweak your application
Add caching strategies (distributed cache like Azure Redis is a good option)
Increase Web App instances by configuring Auto-Scaling based on HTTP Queue Length / CPU.
You should not have to change your domain to autoscale a Web App, but you may have to change your pricing tier. Scaling to multiple instance is available at Basic pricing tier, and autoscaling starts at Standard tier. Custom domains are allowed at these levels but you don't have to change your domain if you don't want to.
Here is the overview of scaling a web app https://azure.microsoft.com/en-us/documentation/articles/web-sites-scale/
Adding a Virtual Machine (VM) is very costly as compared to adding instance. On top of it, Redundancy (recommended) for the VMs, adding NIC etc will blow up the cost. Maintenance is another challenge. PAAS (webApp etc) is always a better option than IAAS.
Serverless offerings like Azure Functions can also be thought of. They support http trigger and scale up really well.
If Azure App Service plans are virtual machines dedicated to the Web, API, Logic, and Mobile apps defined within them, does that mean that a web app in an app service plan is an instance of a virtual web server in IIS on that virtual machine?
Assuming this is the case and that each virtual web site gets it's own application pool, is there an Azure scaling strategy or scenario where more than one worker process in that app pool will run, creating a web garden? My understanding of web app scale out is that it results in additional VMs being allocated and not additional worker processes.
The scaling strategy will depend upon the pricing tier you have opted for.
Basically each Service Plan will contain a collection of Web, API, Logic, Mobile apps. These will form a web garden within the Service Plan server you choose.
If you initially choose a single B1 Basic Service Plan, you will get a single virtual machine with all of your applications running on that. As the load on that server increases, you can scale it up to larger servers, but it will still be running on a single server.
If you then choose to create a second instance (and a 3rd, 4th, 5th...) that second server will be a replica of the first server, with the load being balanced between the two. (3,4...)
While I've not seen documentation for this, I would imagine that each Web, API, etc app is run under its own application pool / worker process, and scale out is simply duplicated instances.
I'm not sure what a Virtual Server is, but each app runs in its own dedicated application pool and w3wp.exe process. There is only a single w3wp.exe process per application pool, so no web gardens.
Is there a specific reason you think you need these to scale your apps? In most cases, using web gardens is the wrong way to scale, as adding more processes can cause unnecessary overhead (amongst other problems - you can find some useful resources on the web). You almost always want to prefer threads over processes for improving concurrency. If you're running out of physical resources (CPU, memory, etc), then the correct way to scale is to add additional VMs.
I am new to Microsoft windows azure cloud and want to run my game server using node.js in azure cloud. I read the windows azure Node.js Developer Center site and it seems my server can run in azure cloud multiple ways.
Which azure option is good for my TCP game server using node.js?
Three options:
Web Site
Cloud Service
Virtual Machine
Web Sites are essentially shared web hosting, which only supports HTTP, so not an option for you.
Cloud Services are probably what you want. This is the core PaaS offering on Windows Azure. It will let you run pretty much whatever you want, as long as it runs on Windows. It supports TCP endpoints. There's are pretty nice tools for Node.js. There are two flavors of running Node in a Cloud Service: a web role or a worker role. Web roles use IIS and run Node.js behind it. That won't work for your raw TCP connections, so you'll want to use a worker role. A worker role will simply launch your Node app and leave it running forever.
Virtual Machines would work fine too, but they don't provide much value compared to Cloud Services. In a cloud service, you can spin up new VMs on demand, a load balancer sits in front of your app distributing traffic, your app will get restarted if it ever crashes, you can have your VM automatically patched without downtime, etc. Unless you can't run in a cloud service for some reason, you rarely want to use a raw VM.
tl;dr You want a worker role in a cloud service. :-)
Windows Azure does have a toolkit for Social Games on Github, this might help you in you in your endeavours, not sure it supports Node.js mind you, there should be some takeaways to help you.
https://github.com/WindowsAzure-Toolkits/wa-toolkit-games
This blog post gives a good breakdown on where to run what and use cases for each.
http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to-use-which.aspx
It really depends on your application, what backend does it have, number of users, performance, latency etc...
A word of warning though, running Node.js on Windows is mostly fine but there are several libraries that will not work. Don't know if it's a hard requirement that you use Azure but there are other Node hosting solutions out there.
Nodejitsu
Nodester
Those are only two, there are more out there.
Disclaimer: I'm building a Node.js hosting solution, modulus.io.