Azure Monitoring. What to Choose?

You are going live with your Azure system and need to know what is happening there?
Cannot sleep at night as your system crashes from time to time?
Need to know whatever your fast growing system will go out of resources in the near future?
If so, this post is for you!

Decisions
In general you have 3 main options:

1. Open Source Software that is installed by you and managed by you.
2. Azure built in monitoring that may require some extra charging and tailoring to your business case.
3. 3rd Party SaaS offering that provides you an End to End solution.

The Open Source Way

1. Major OSS monitoring tools are available and widely used in the industry. Some of the leading solutions are Zabbix, Nagios and Ganglia.
2. Software is available w/ no additional cost
3. You will need to install the servers by yourself (and of course paying for the instances and manage the data).
4. Implementing an end to end monitoring (inc. user experience) may require extra servers installation on another data center or using a 3rd party service.
5. Other downsides are well described by CopperEgg.

The Azure Monitoring Way

1. If you are already invested in Azure, it's built-in, so why not using it?
2. The service provides nice utilization graphs, and some minimal alerting system (limited to 10 rules). However, there are no pre configured templates, and some metrics are with additional charging.
3. Basic website availability is provided using web site monitoring.
4. Yet, there are several gaps such as VM monitoring, SQL Azure and Azure Storage.
5. The overall impression is that many features are available, but it's far from being a monitoring product, and you will have to do a lot of integration work by yourself..

3rd Party Monitoring as s Service

1. CopperEgg: Nice company, the their website could look better. More important, Their features looks pretty similar to the OSS solutions with an integrated website response time and availability service. Pricing: $7-9/server|service/month.
2. AzureWatch: a very similar product to CopperEgg both in features and pricing (although their landing page looks much better). Pricing: $5-8/server|service/month.
3. New Relic:Probably the most intersting product around, not only it provides an end to end monitoring, but it also analyzes your performance bottlenecks. Their product is being integrated to your code and provides you with production profiling and alerts you regarding any exception. Pricing: standard version that includes the other providers offers is free. Code level diagnostics and inner level profiling will cost you $25-200/server|service/month

Bottom Line

If you are ready to invest time to get your own solution, the OSS products with Azure integration will probably be your preferred solution. Otherwise, I will recommend you to choose New Relic, that seems to provide the best value in the market for your needs.

Keep Performing

Moshe Kaplan

Apache Session Persistancy Using MongoDB

Your app is booming, you need more web servers and you need to serve users and keep their user experience. When you had a single server you just used session for that, but now, How do you keep sessions across multiple web servers? 

Using a session stickiness load balancer is a good solution, but what happens when a web server needs a restart?

Session Off Loading

Many of you are familiar with the concept of session off loading. The common configuration for it is using Memcached to store the session object, so it is accessible from all web servers. However, this solution lacks the features of high availability by replication and persistence.

The Next Step: High Availablability

Offloading web servers sessions to MongoDB looks like a great solution: key-value store, lazy persistency and built in replication and auto master failover.

Step by Step Solution for LAMP Session Off Loading using MongoDB

1. Install MongoDB (preferably in a replica set with at least 3 nodes)
2. Install MongoDB driver for PHP: 
3. Configure the php.ini: extension=mongo.so
4. Download and integrate Apache session handler implementation using MongoDB.
5. Configure your MongoDB setting in the module:
1. Set the list of nodes in the connectionString setting: 'connectionString' => 'mongodb://SERVER1:27017, mongodb://SERVER2:27017',
2. Do the same to the list of servers (see at the bottom of this post)
3. Configure the cookie_domain (or just place a null string there to support all): 'cookie_domain' => ''
4. Don't forget to enable replica set if you are using one: 'replicaSet' => true,
6. Add the MongoSession.php to your server and require it: require_once('MongoSession.php');
7. Replace the session_start() function with $session = new MongoSession();

And that's all. Now you can continue using the session objects as you used to create new great features:

if (!isset($_SESSION['views'])) $_SESSION['views'] = 0;

$_SESSION['views'] = $_SESSION['views'] + 1;

echo $_SESSION['views'];

Bottom Line

Smart work can tackle every scale issue you are facing off...

Keep Performing,

Moshe Kaplan

Appendix: 

'servers' => array(
array(
'host' => 'SERVER1',
'port' => Mongo::DEFAULT_PORT,
'username' => null,
'password' => null,
'persistent' => false
),
array(
'host' => 'SERVER2',
'port' => Mongo::DEFAULT_PORT,
'username' => null,
'password' => null,
'persistent' => false

)