Iron.io Announces Alerts for IronMQ
 |
| Alerts can now be set on queues to trigger actions. |
Iron.io is pleased to announce the release of alerts for IronMQ. IronMQ is a cloud-based message queuing service that offers high scale and high availability. It provides pull and push queues – meaning processes can get messages (pull) and events or the queue can push messages to processes and other endpoints.
Alerts have now been incorporated into IronMQ. This feature lets developers control actions based on the activity within a queue. With alerts, actions can be triggered when the number of messages in a queue reach a certain threshold. These actions can include things like auto-scaling, failure detection, load-monitoring, and system health.
An Important Feature for Production-Scale Applications
IronMQ has been designed to be the message queue for the cloud. It can serve as a simple buffer between processes but it is also meant for more complex use. It offers push queues, HTTP/REST access, guaranteed one-time delivery, FIFO and now alerts. As a result, it’s even easier to build production-scale applications on cloud infrastructure.
Instead of a monolithic app structure consisting of a bunch of app servers and a database, applications can be built right from the start as distributed systems ready to scale as needed to handle increasing workloads. Processes can be separated and scaled up and down effortlessly. More automated workflows can be created to deal with a varying amount of request/response loops and the resulting workloads that are at the backend of all the inputs.
Flexible Control of Alerts
Because alerts are so important, we put a flexible alert mechanism in place, giving developers fine-grained control over how they want to be alerted and under what circumstances. Users can select the trigger (or size of the message queue) as well as whether it should be a fixed or a progressive alert (one time or on a scaled basis every x messages). In the case of a progressive trigger, users can choose whether it’s ascending or descending. There’s also a snooze parameter that lets users limit the number of alerts within a certain period of time.
Alerts are sent to an endpoint to notify which is an IronMQ queue that you define. This queue can be configured to trigger one or more actions. You can push to a single endpoint or you can fan-out several actions (up to 100 if you want). You can also kick off workers in IronWorker from this alert queue or send messages to other queues.
This flexibility in settings and using a queue to deliver the alerts means that you can send the alert to a variety of processes and services. You can send messages to workers using ascending alerts, for example, to launch more servers to handle increasing workloads. (Alternatively, you can scale your servers down with descending alerts.) You can send notifications via SMS or emails using Twilio or SendGrid for example, or you can hit services like PagerDuty. Because an alert queue can be a push queues, you can communicate with any service that accepts a webhook. And in a world where webhooks are becoming pretty magical, this capability opens up a lot of possibilities that even we can’t predict.
How to Use Alerts in IronMQ
One or more alerts can be set on a pull queue. Within the API alerts can added onto a queue by making a post to the queue receiving the alerts:
POST /projects/{Project ID}/queues/{Queue Name}/alerts/
URL Parameters
- Project ID: The project that the queue belongs to.
- Queue Name: The name of queue to for the alert.
Body Parameters
- Alerts: An array of alerts hashes containing required "type", "direction", "queue", "trigger", and optional "buffer" fields. Maximum number of alerts per queue is 5.
Acceptable fields of an alert hash are:
- type - required - "fixed" or "progressive". In case of alert's type set to "fixed", alert will be triggered when queue size pass value set by trigger parameter. When type is set to "progressive", alerts will be triggered when queue size passes any of the values calculated by trigger * N where N >= 1. (For example, if trigger set to 10, alert will be triggered at queue sizes 10, 20, 30,...)
- trigger - required. It will be used to calculate actual values of queue size when alert must be triggered. See type field description. Trigger must be integer value greater than 0.
- direction - required - "asc" or "desc". Set direction in which queue size must be changed when pass trigger value. If direction set to "asc" queue size must growing to trigger alert. When direction is "desc" queue size must decreasing to trigger alert.
- queue - required. Name of queue which will be used to post alert messages.
- snooze - optional. Number of seconds between alerts. If alert must be triggered but delay is still active, alert will be omitted. Snooze must be integer value greater than or equal to 0.
Note: The IronMQ client libraries will follow a similar approach in terms of the array and hash fields. See the client library for the language of your choice for more specifics.
Sample Settings for Alerts
Setting up Auto-scaling for a Queue
To have a pull queue auto-scale the processing of messages, you can use a progressive alert. For example, set a progressive alert with a trigger of 1000 on a queue in the ascending direction for a queue entitled “worker_push_queue”. This pattern would send an alert to the “worker_push_queue” which can then trigger additional workers and allow for seamless auto-scaling.
{
"type": "progressive",
"trigger": 1000,
"direction": "asc",
"queue": "worker_push_queue"
}`Triggering Workers
To trigger the start of a worker to run whenever there are items within the queue, you might set a fixed alert with a trigger of 1 in an ascending direction. This could hit a queue entitled “worker_polling_queue” which would start a worker process.
{
"type": "fixed",
"trigger": 1,
"direction": "asc",
"queue": "worker_polling_queue"
}`Discontinue Error Processing
To shutdown error processing, you might set a fixed trigger of 0 in a descending direction. When a queue reaches a value of 0, an alert will be posted to the “shutdown_error_processing_queue”. This pattern might fire to a worker that would turn off all polling workers of an error queue.
{
"type": "fixed",
"trigger": 0,
"direction": "desc",
"queue": "shutdown_error_processing_queue"
}`Using the Dashboard to Create and View Alerts
You can create and view the alerts on a queue via the Iron.io dashboard. Just go to the queue and you'll have the ability to see and set alerts.
Check out the Alerts Documentation for more information.
Developing at Cloud Scale
 |
| Alerts can be used for signaling conditions and triggering actions. |
The advantage of cloud-based message queues have been clear for a while – no standing up servers, no maintenance, no need to deal with persistence or redundancy plus they are always on and can handle cloud-scale throughputs. With alerts added to the mix, the comparison between IronMQ and stand-up message queues like RabbitMQ and even something like SQS is even more clear.
There’s an adage that everything breaks at scale. Systems designed to handle even high loads fall over when those limits are reach. Things like API rate limits or database connections can come into play.
And while this may be true – everything may break at scale – IronMQ with alerts makes it less a certainty and, more often than not, just a temporary architectural oversight. Use message queues and increase your pace of development and your ability to scale.
⇒ To learn more about how IronMQ can help you make complex things easy, visit Iron.io and get started today.
⇒ To read more about improving an application's ability to handle unknown or inconsistent load, check out our post here.
← How One User Automated a Research Study with IronWorker and Twilio (a repost from Usability Panda)Iron.io Launches on Pivotal Cloud Foundry Platform →
