AzureWatch retirement announcement and transition to CloudMonix
It has been more than 6 years since I originally launched AzureWatch to help companies monitor and auto-scale their Azure Cloud Services. Over the years, as the Azure platform grew and matured, my team and I tried to adapt AzureWatch to help provide more value in the ever-changing Azure space. We implemented monitoring for SQL Azure, WebApps, Virtual Machines, and Service Bus. However, as Azure platform and our customers' needs started to rapidly evolve, it became increasingly obvious that AzureWatch's internal architecture and somewhat dated user interface would simply not be able to keep up.
Having learnt many hard lessons and with deeper understanding of what monitoring/automation needs Azure users have, we started to work on a new product called CloudMonix, to replace AzureWatch. CloudMonix was designed to provide deep insight, /automated issue recovery/ and advanced auto-scaling to Azure (and in the future AWS) platforms. In early 2015, CloudMonix, was launched with great success. Since then, we've experienced a sustained 5-10% month-to-month growth rate.
Today, CloudMonix supports monitoring of over 30 different types of cloud resources, integrates with a dozen of third party products, offers beautiful UI and has tons of bells and whistles that are useful for Service Providers, DevOps teams, and Enterprises. Almost every AzureWatch customer who saw our newsletters and tried CloudMonix, migrated to it and is very happy with the outcome. The product is that good! And what's most important, we update and improve CloudMonix on a weekly basis. Literally.
So, I am both saddened and happy to announce that we intend to retire AzureWatch in April of 2017. We currently have remaining 16 customers that are still using it. Unfortunately, it is becoming less and less profitable for us to maintain the infrastructure and support of AzureWatch as time progresses
I would like to invite every current and previous AzureWatch user to migrate to CloudMonix and my team and I are ready to every assistance and incentive to help migrate your team to the new platform.
To learn more about CloudMonix and to sign up for a free trial, please visit our website at http://cloudmonix.com
To understand the benefits of CloudMonix and see it in action please schedule a time here: https://paraleap.acuityscheduling.com
If I can assist in any other way, just email email@example.com
Q: What are the benefits of CloudMonix vs AzureWatch?
A: CloudMonix far exceeds both AzureWatch and native Azure monitoring in a number of areas:
- Amount and depth of diagnostic data it can capture, visualize and provide ability to alert on.
- Powerful automation capabilities that can automatically recover your resources from outages and issues.
- Sophisticated auto-scaling capabilities not only for Cloud Services, but also for resources such as SQL Azure and Data Warehouses, WebApps and Virtual Machines, etc.
- Native integrations for many 3rd party products like Slack, PageryDuty, Zendesk and Autotask.
- Amazing UI with ability to scroll your dashboards back in time to easily find root cause of previously occurred production issues.
Overall, the full list of benefits is too lengthy to outline in an email. Happy to discuss the benefits via online meeting. Click here to schedule a discussion: https://paraleap.acuityscheduling.com/
Q: How hard is it to onboard with CloudMonix?
A: Onboarding is incredibly simple. Setup Wizard takes 4-5 minutes to complete. CloudMonix comes pre-defined with a number of useful metrics and alerts, so that it brings value right out of the gate. Configuration Templates offer ability to easily propagate similar monitoring setups across many resources in 2 clicks.
Q: Is there an automatic migration from AzureWatch to CloudMonix?
A: Unfortunately there is not. However, default monitoring profiles are pre-packaged with a number of useful metrics and alerts. And everyone who has migrated so far, appreciated the chance to revisit and improve their monitoring setups
Q: What Azure resources can CloudMonix monitor/automate?
A: CloudMonix supports monitoring the following resources (ARM and Classic mode is supported)
- Windows and Linux VMs
- Cloud Services
- Web Apps and Webjobs
- Service Bus Topics and Queues
- SQL Azure and SQL Data Warehouse
- Azure Redis Cache
- DocumentDb Collections
- Azure Storage (Blob, Queue, Table and File storage)
- Stream Analytics and Event Hubs
- Media Services
- Azure Automation Runbooks
- Backup Vaults
- Virtual Networking
- And more coming (Data Factories, Azure Batch, Scale Sets, Azure Search, Service Fabric, etc.)
- CloudMonix can also monitor various non-Azure resources, such as Oracle, MySql, Sql Server (non-Azure), Windows Servers (non-Azure), Sockets, URLs, and JSON/XML API endpoints
AzureWatch is now over four years old and is a little... dated. In order to keep up with our customers' needs and with innovations in Azure, we recently introduced a brand new monitoring product designed to replace AzureWatch. The product is called CloudMonix and it is available at http://cloudmonix.com. CloudMonix enhances Microsoft Azure by providing deep monitoring of most of Azure's infrastructure via live dashboards, ability to self-heal from many different production issues, on-demand historical performance and uptime reports, customizable alerts & notifications, sophisticated auto-scaling engine, integration to third party systems, and a lot more. CloudMonix is not yet available in Azure Marketplace.
Five years ago, I set out on a journey to help Azure developers auto-scale their Azure systems. AzureWatch, a product that I built for that purpose, was originally a Windows desktop application that allowed users to dynamically scale their Web and Worker roles with demand - a feature that Windows Azure lacked back in the day.
Over the years, AzureWatch was continually enhanced to meet ever-growing customer needs. As my team grew with the customer base, so did AzureWatch's feature set. We migrated AzureWatch from a desktop app to a fully hosted cloud solution. We added monitoring capabilities and live dashboards. AzureWatch was enhanced to monitor SQL Azure, Storage, Websites and Virtual Machines. Unfortunately, with each iteration of changes and features, we twisted and adopted AzureWatch to do something it was never meant to. Ongoing maintenance became hard and time to innovate long.
As market conditions changed and need for auto-scaling decreased, due to basic auto-scaling features being introduced in Azure core platform, it was obvious that we needed to offer customers something more substantial and special. After looking thru the backlog of customer requests, a few patterns clearly emerged, where we saw that we could add a ton of value
- Very fast onboarding and intuitive UI. No one has time to learn complex systems that don't work from the get-go
- Deep insight into all levels of technical stack, not just servers. Cloud platforms offer many useful services and they all need to be considered in the overall health of a production system
- Automatic self-healing. While healing procedures are usually simple to script out (reboot server, restart service, clear cache, recycle app pool, truncate table, etc.), knowing WHEN to execute these procedures can be really challenging.
- Ability to compare & contrast performance, uptime, and other metrics over time.
- Provide value not just for Azure but other cloud systems for shops that manage or utilize different cloud platforms
Taking into account that AzureWatch's back-end needed to be re-architected to become much more adaptive at monitoring new and different systems and AzureWatch's front-end UI needed a lot of work to become user-friendly, the decision to re-architect the whole product became a no-brainer. So, in summer of 2014, we set out on a journey to re-invent ourselves and provide a new kind of SaaS service: "Stability-as-a-Service" to cloud production environments with a delightful user experience and backed by our amazing support.
Fast-forward to today. We delivered and in some ways over-delivered on all of our goals with the release of CloudMonix in March of 2015. All lessons learnt in the years of maintaining AzureWatch came in handy. CloudMonix has automatic self-healing and enhanced auto-scaling engines; amazing and responsive UI; ability to integrate with other 3rd party systems; future support for public API, data-region affinity; in-depth monitoring of a number of popular Azure services and ability to develop others very quickly. There is more, much more. With a few known exceptions, CloudMonix far exceeds AzureWatch in features and functionality from the get-go and continues to evolve and expand very quickly.
I invite you experience CloudMonix for yourself at http://cloudmonix.com and tell us what you think.
Microsoft Azure Insider
Major enhancements to AzureWatch Rules engine
A number of important changes are being introduced to AzureWatch this weekend (March 16th):
- Ability to execute rules only after a sustained period of time
- This feature allows for much better control of the scaling process. For example, in certain situations it can be far more effective to scale when sustained load is over a certain threshold rather than try to predict what a moving average looks like. It is important to know that if a rule is configured with a sustained time delay, it will only be executed after continuously being evaluated to TRUE for the specified period of time.
- Ability to send ON and OFF alerts (a single ON email when alert evaluates to TRUE, and a single OFF email when it evaluates to FALSE)
- This feature reduces spam when a certain rule's condition is continuously TRUE. It also simplifies configuration since ON/OFF alerts no longer require throttling. Unless modified, existing Alerts will work as they currently do.
- Separation of Alerts from Management Actions (rules that notify will be separated from rules that execute scale actions, shutdowns, restarts, etc.)
- This feature is relatively important as it may impact existing rule sets. Going forward, rules that are Alerts will be evaluated separately from rules that are Management Actions. When evaluating rules, all Alerts that qualify for execution will be evaluated and acted upon, not just the first one. Management Actions will continue to be evaluated until the first rule that qualifies for execution. Users who currently rely on Alerts to control execution of their Management Actions will want to revisit their scaling configurations. We do expect percentage of such users to be either very small or non-existent.
- After the upgrade, we plan to monitor AzureWatch's email queues and switch highly spamming Alerts to have ON/OFF logic. Impacted customers will be notified.
While we expect minimum impact during or after the upgrade, we want to be transparent with our users: this is probably the most significant change to the Rules engine since the inception of AzureWatch. If you have any concerns, please contact Paraleap support team
Upcoming changes to the way alerts work in AzureWatch
We are currently working on changing the way alerts work in AzureWatch. At this time, Rules for a monitored resource, that trigger either Alerts or Management Actions are ALL evaluated together in a single loop. When a single Rule is evaluated to TRUE, all further evaluation of rules for that resource stops. This will be changing going forward. ALL rules that trigger alerts will be evaluated, regardless of their success or failure. Only rules that contain Management Actions will be evaluated to the first TRUE rule.
Furthermore, we will be adding the following two options to the Rule engine:
1) Ability to send ON/OFF notifications for Alerts. This means that when a condition for a Rule is TRUE, AzureWatch will send out an "Alert ON" alert and subsequently when the condition for a Rule no longer is true, AzureWatch will send out an "Alert OFF" alert.
2) Ability to trigger Rules (Alerts or Management Actions) only after a sustained period of time. This means that when a condition is TRUE, a particular Rule will not be immediately acted upon. Only if Rule's condition has been evaluated as TRUE for the specified period of time, will it trigger it's Alert or Management Action.
Monitor Windows Azure Service Dashboard!
AzureWatch users can now receive notifications when changes are published to the Windows Azure Service Dashboard. Upon logging into AzureWatch portal, users can choose to subscribe to any of the Azure Service Dashboard feeds as shown in the screenshot below. This feature is available free of charge to active AzureWatch users.
New Dashboard is here!
Users logging into AzureWatch Management Portal last week found themselves pleasantly surprised. We've completely overhauled our dashboard. It is now a robust, configurable user experience designed to provide users with an ability to quickly and intuitively see all of the relevant and important monitored data for their Azure applications. Check out a screenshot cutout or simply login with your account to experience the new interface
Introducing preview of auto-scaling, healing, and monitoring of Azure VM's (IaaS)
We are excited to introduce the long-awaited AzureWatch support for monitoring, manage, auto-scaling and healing of Azure Virtual Machines. We are soft launching this functionality in preview mode and are looking for your feedback!
Every minute of every hour, AzureWatch will connect through Powershell Remoting to any Azure VM's that is either stand-alone or a part of an availability set. Once connected, it will capture any number of standard or custom Windows performance counters that have been configured by you and execute its usual suite of monitoring or scaling Rules. After the Rules execute, AzureWatch can execute scaling, re-imaging, stop/start and alerting actions. Please refer to the following table to see what actions are supported under what conditions:
|Performance Counters||Queues & Other Metrics||Auto-Scaling||Auto-Rebooting||Auto-Stop/Start||Alerts|
|Stand-alone Windows VMs|
|Stand-alone Linux VMs|
|Windows-based Availability Sets|
|Linux-based Availability Sets|
It is important to know that stand-alone Virtual Machines cannot be auto-scaled because they are not load-balanced by Windows Azure. However, when a VM is part of an Azure Availability Set, it can be scaled up or down, provided that there are enough shutdown VM's that exist within the Availability Set. During the scale-up event of an availability set, AzureWatch finds the next available VM that has been turned off and simply starts it up. Conversely, when an Availability Set is scaled-down, AzureWatch simply finds the last active VM and shuts it down so that charges are not incurred.
The following must be done in order to have AzureWatch properly monitor Azure VM's:
AzureWatch currently supports capture of performance counters only from Windows-based VMs that have Powershell Remoting enabled. Powershell Remoting port 5986 must be open within the Windows Firewall on the server itself. In addition, a public endpoint mapping to local port 5986 must be defined in the Azure configuration of each monitored Virtual Machine. Azure's public port can be any number.
Users who wish to auto-scale or auto-shutdown/start-up their VM's based on a schedule or queue counts, do not need Powershell Remoting enabled and are not limited to running Windows Server.
AzureWatch brings SaaS/HaaS App Monitoring and Autoscaling Service to the Windows Azure Store
Arlington Heights, IL
As a featured add-on in the Windows Azure Store, AzureWatch provides on-demand elasticity, healing, monitoring and just-in-time provisioning of resources – saving time and money
Paraleap Technologies, a developer of high performance tools and services for cloud computing technology, today announced that their flagship product, AzureWatch, is now offered as an add-on option in the Windows Azure Store, part of the Windows Azure management portal. Developers and IT professionals can now easily implement AzureWatch’s dynamic scalability, healing and monitoring to their applications running on Microsoft’s Windows Azure cloud platform.
As one of the first autoscaling and monitoring services available, AzureWatch has proven itself to be a responsive and affordable service continuously improving and expanding its features. Earlier this year AzureWatch released its newest version which simplified the configuration process and in April expanded services again to offer healing-as-a-service (HaaS) for Windows Azure. HaaS now allows AzureWatch to automatically reboot or re-image servers saving clients time and money on servers that leak memory, disk space or other resources.
As an add-on available through the Windows Azure Store, IT pros can now quickly deploy AzureWatch from inside the Windows Azure management portal. The availability of AzureWatch through the Windows Azure Store helps deliver fast and cost-saving Software-as-a-Service (SaaS) and HaaS-based monitoring and autoscaling of applications running in Windows Azure. Designed with a focus on simplicity and ease of use, AzureWatch can be quickly configured to address each customer’s unique monitoring needs. By automatically scaling Windows Azure services to match real-time demand, AzureWatch saves customers time and money and eliminates the need for manual monitoring of Windows Azure-based resources.
“The Windows Azure Store is an integral part of the developer experience and makes it easy for developers to find and purchase add-ons to help create great applications,” says Scott Guthrie, Corporate Vice President, Windows Azure, Microsoft. “We are pleased to welcome Paraleap to the Windows Azure Store and look forward to giving developers access to Paraleap’s monitoring and autoscaling technologies for their applications.”
“The future of information technology rests in the cloud; Microsoft has long been a global leader in providing a secure open cloud platform. With more and more companies moving services and solutions to the cloud, it is crucial that they have access to the comprehensive monitoring services that AzureWatch provides. Offering AzureWatch through the Windows Azure Store enables us to educate developers and IT pros on the important work we do and extend our services as developers build, deploy and maintain their applications.” says Igor Papirov, founder and CEO of Paraleap Technologies.
“We have been using AzureWatch for close to a year to monitor our Windows Azure app. It is an essential part of our tool belt,” says Hector Obregon, CEO of Formiik.com. “The daily performance reports and metrics history have helped us solve many problems and the e-mail notifications work great, we have those feed directly into our support desk.”
Pricing and Availability
AzureWatch pricing is simple, affordable and based solely upon what is monitored. AzureWatch is offered in five packages to Windows Azure customers:
- Free Package: monitors up to 500 unit-hours per month - free
- Basic Package: monitors up to 5 units per month - $39.90 per month
- Plus Package: monitors up to 10 units per month - $74.90 per month
- Super Package: monitors up to 25 units per month - $159.90 per month
- Ultra Package: monitors up to 100 units per month - $549.90 per month
About Paraleap Technologies
Paraleap Technologies is a Chicago-based software company focused on providing tools and services for cloud computing technologies. As the Paraleap’s flagship product, AzureWatch is designed to add dynamic scalability and monitoring to applications running on Microsoft’s Windows Azure cloud platform.
Healing-as-a-Service for Windows Azure
We are pleased to introduce a number of exciting new features to AzureWatch!
Support for multiple Azure subscriptions
Users can now instrument a single AzureWatch account to monitor and auto-scale any number of Azure Subscriptions (previously the limit was one). Furthermore, users no longer need to transfer all of their diagnostic data into a single storage account. AzureWatch will automatically detect which storage account a particular Role is transferring its diagnostic data to. This should simplify account management, billing and configuration steps for AzureWatch users.
Support for alerts based on conditions of individual servers
In addition to receiving alerts based on metrics aggregated across all servers within a compute Role, AzureWatch users can now receive alerts based on conditions of individual servers. This can help support personnel quickly pin-point problematic servers and take appropriate action.
Support for self-healing!
In addition to generating alerts for individual servers, AzureWatch can now automatically reboot or re-image servers! This is particularly useful for servers that are leaking memory, disk space, or other resources.
Enhanced support for multiple mailboxes
AzureWatch can now send alerts to multiple mailboxes at an account level. Furthermore, each individual alert can be further customized to be sent to more mailboxes if needed. This lets AzureWatch users send alerts of different priority levels or areas of responsibility to different contacts.
Each rule now has a flag (1) that allows it to inspect metric data server-by-server OR aggregated across all servers within a Role. If a Rule is inspecting metric data across all servers within a Role (the default scenario) it can auto-scale servers within that Role and send out alerts based on general conditions of all servers within a Role. However, if users choose to evaluate a particular rule on an individual server basis, it can reboot or re-image servers instead (2). This is obviously very useful for conditions related to memory leaks, fragmented or leaking disk space, accumulating "stuck" IIS requests, etc. While AzureWatch uses Azure Service Management API in order to request rebooting and re-imaging of servers, users should exercise caution and consider putting appropriate thresholds or throttling in place to avoid inappropriate reboots.
When performing any sort of an action based on Rule (scaling, rebooting, or simply alerting), AzureWatch will send notification to every mailbox specified at the account level. However, more mailboxes can be configured at an individual Rule level (3).
When Azure reboots a server (role instance), it will take it offline, restart the underlying operating system for that server, and brings the role instance back online. Any data that is written to the local disk is persisted across reboots. Any data that is in-memory is lost.
When Azure reimages a server (role instance), it will take it offline and write a fresh installation of the Windows Azure guest operating system to the virtual machine. The instance is then brought back online. Windows Azure attempts to maintain data in any local storage resources when the server is reimaged; however, in case of a transient hardware failure, the local storage resource may be lost. Any data that is written to a local directory other than that defined by the local storage resource will be lost when the instance is reimaged.
Support for monitoring and auto-scaling of Azure Websites
Last week was very exciting for us at Paraleap:
- First, we revamped our website with a crisp and modern look. If you have a few minutes, please share with us your thoughts on the new design.
- Second, we soft-launched a major new feature to AzureWatch: support for monitoring and auto-scaling of Azure Websites. Users can now receive alerts or automatically scale the number of instances dedicated to Windows Azure websites. There are no agents to install and no code to redeploy. We simply hook into the Azure Service Management API, grab the running totals for standard metrics, extrapolate their rates of change and take this data through our rule-based monitoring and scaling engines. Users can configure alerts and scale rules using the already familiar interface of AzureWatch Management Portal.