I wrote this because SMS access is more universal than reasonably priced data access when you are travelling, and servers go pop with no consideration as to your location at all.
The app uses MongoDB to store a collection of alerts, and there is some configuration which allows you to specify the max size of the collection and its name.
|MON_ALERTS_DB_URL||Database URL - this needs to be a mongodb schemed URL. If not present, it defaults to a local MongoDB installation, with no authentication, and a database called mon_alerts_db.|
|MON_ALERTS_WINDOW_SIZE||The number of alerts that will be stored before older alerts start being overwritten. The collection will never exceed this size. It uses the capped collection capability of MongoDB. Defaults to 2048.|
|MON_ALERTS_COLLECTION_NAME||The name of the collection to be created for storing the alerts. Set this if the default name clashes with your existing collection naming scheme. The default is mon_alerts.|
SMS messages are delivered by Twilio you will need to set up your account data with environment variables:
|TWILIO_KEY||Your Twilio account SID|
|TWILIO_AUTH||Your Twilio auth token|
|TWILIO_FROM||The Twilio number that your message will come from|
|TWILIO_TO||The phone number (or comma-spearated list of phone numbers) that you wish to send the SMS to|
The app maintains a configurable rolling window of alerts using a capped collection. It uses the SMS status callback that Twilio provides to update the status of each message that got sent.
I'll extend this to differentiate between many source applications, so I have a single place
of failure to mux/demux alert streams from a number of multipart infrastructures, and dynamically match target numbers based on time-related recipients. Or something.
Run the tests with
$ bundle install $ bundle exec rspec specs/*
There's loads of room for improvement, so fork and hack away. Pull requests are welcome.