BitFolk » Monitoring

Would love to see this implemented. I would have thought the best way would be to buy a block of "SMS credits" to use the service at x pence per credit (I assume usual economics work with this - more you buy cheaper they are per unit).

I might do this for free but limit it to 1 SMS alert per 12 hours per service per customer or something. I'm not too keen to charge people for it because things always get more serious when there's money involved. Plus Bytemark do it for free!

I already have an AQL SMS account where I already have a block of SMS credits for various other notifications I have set up. It'd be cool if I could share that existing pool of SMS credits with the Bitfolk Nagios service, rather than needing to buy a separate SMS bundle with Bitfolk (although Andy's already indicated he'd prefer not to get into doing that).

Rather than building support for AQL specifically, it could be quite a nice idea to just have somewhere I can pass in a URL, the list of necessary HTTP parameter names (and, if necessary for some providers: HTTP auth credentials, though AQL doesn't need that IIRC), that way it'd be provider agnostic and you wouldn't have to worry about managing SMS billing at all, it could just be a bring-your-own-SMS-provider thing, and Nagios could just GET or POST the relevant URL to transmit the SMSes.

If you already have email addresses that gates to SMS or would like BitFolk's Nagios to use curl to poke at something with GET or POST then I am happy to configure this, just send a support ticket.

There is not much prospect of sharing AQL account credit between BiTFolk ad yourself without AQL's agreement, unless you are willing to give us your AQL credentials to send you an SMS.

I currently use AQL to send BitFolk alerts to myself, but I'm thinking of switching to http://www.textmarketer.co.uk/sms-gateway.htm as they are cheaper and a few people have reported they're happy with them.

Most of the major mobile phone providers allow you to send text messages for free by e-mailing a particular address. This could be used initially to provide this functionality for most users with minimal development cost, while an alternative for users of other networks is developed (or maybe just ignored).

http://www.mutube.com/projects/open-email-to-sms/gateway-list/
http://www.livejournal.com/tools/textmessage.bml?mode=details

A more generic/extensible way of doing this would be to implement an alerts infrastructure using XMPP. You could then implement different alert destinations (Email, SMS, Twitter/Identica, etc) by using appropriate XMPP gateway components, and alert sources with simple XMPP component bots. For user generated alerts, users would generate their alerts as XMPP messages originating from their VPS by whatever mechanism they choose (e.g. run an XMPP client, configure their own XMPP server to communicate with the alerts system, use an XMPP plugin for their favoured server software (if available), or simply code up their own component bot - XMPP is fairly simple and there are libraries for most (all?) common languages).