First off, apologies if this is off topic. I'm hoping that system and
network monitoring tip are enough of a common issue that this falls under
the group's charter.
We've traditionally used mobile phone email addresses for system
notifications, but over the past 6-12 months, it seems to have become
increasingly sketchy.
For instance, if an application fails to contact a certain service on a
certain server, it sends an email (through it's own SMTP service, to avoid
a chicken-and-egg prob if/when our main SMTP service fails) to 1234567890@tmomail.net. (Obviously, that was a fake number.) More and
more, I'm getting less and less of these notifications.
It seems especially prevalent when MANY things are sent at once; if, for
example, a central piece fails, and dependent pieces suddenly fail as
well.
I try to telnet to mailx.tmomail.net port 25 and get sometimes good,
sometimes laggy, and sometimes no response. T-Mobile, support levels all
the way up to 3 tell me that it's not them, and everything should work
wonderfully.
Is SMTP to a mobile phone a fundamentally flawed way to do this?
Anyone else have any issues, past or present, with this kind of thing?
Anyone else have any issues, past or present, with this kind of thing?
It takes ~ 7 minutes from the time Nagios sends an email sms to AT&T to the time it hits my phone. I'm using @mobile.mycingular.com because mmode.com stopped working (which results in at least two txt pages vs. the one I was used to).
> Is SMTP to a mobile phone a fundamentally flawed way to do this?
It takes ~ 7 minutes from the time Nagios sends an email sms to AT&T to
the time it hits my phone. I'm using @mobile.mycingular.com because
mmode.com stopped working (which results in at least two txt pages vs.
the one I was used to).
> Is SMTP to a mobile phone a fundamentally flawed way to do this?
I'm beginning to think it is!
It's more effective to spend the money on SMS messages. Mobile
providers are forced to use very aggressive anti spam measures, which
can add significant delays in message delivery.
It takes ~ 7 minutes from the time Nagios sends an email sms to AT&T to the time it hits my phone. I'm using @mobile.mycingular.com because mmode.com stopped working (which results in at least two txt pages vs. the one I was used to).
Is SMTP to a mobile phone a fundamentally flawed way to do this?
I'm beginning to think it is!
It's more effective to spend the money on SMS messages. Mobile
providers are forced to use very aggressive anti spam measures, which
can add significant delays in message delivery.
We’ve traditionally used mobile phone email addresses for system
notifications, but over the past 6-12 months, it seems to have become
increasingly sketchy.
[snip]
Is SMTP to a mobile phone a fundamentally flawed way to do this?
Anyone else have any issues, past or present, with this kind of thing?
We tend to avoid the whole SMTP mess and deliver messages to mobiles and pagers via a modem and the provider’s TAP gateway. It works quite well with Verizon and AT&T/Cingular, but I’ve no experience with T-Mobile. It also avoids the whole mess of failing to alert when your monitoring box has a bad NIC, cable, switchport, etc - of course considering that you trade those for problems with a serial port, cable, modem, or phone line… But it gives us a big (and perhaps false) warm fuzzy that our alerting is ‘out of band’ relative to our upstream Internet connections.
as much as i hate to say it, verizon has been extremely reliable on
the smtp<->sms gateway. been using them for paging for 3 years or so
now and never had a significant (detected) failure or latency.
if you don't like this way of doing things you could get an gprs modem
and originate sms directly from the computer.
Some mobile phones you can talk to via AT commandset, either
via USB cable or something else. (eg: I have used a Nokia 6230 with usb
cable.. you can also use bluetooth). If you pay $5 or whatnot for unlimited
SMS on a el-cheapo plan, it might work better than using the SMTP gateway
(when tied to Nagios, etc..) as you can send SMS messages with the AT
commandset.
For instance, if an application fails to contact a certain service on a
certain server, it sends an email (through it's own SMTP service, to avoid
a chicken-and-egg prob if/when our main SMTP service fails) to
[...]
Is SMTP to a mobile phone a fundamentally flawed way to do this?
Anyone else have any issues, past or present, with this kind of thing?
Consider what other points of failure there are for your notification
e-mails, other than your main SMTP server. I've got:
* Failure of your Internet link
* DNS failure at your end
* SMTP failure at the other end
* Failure of *their* Internet link
* Some sort of SMTP blacklisting at their end
There's probably some I've missed there, too.
Notification of outages needs to be as robust as possible, and SMTP to an
off-site location is about as fragile as they come these days. The only
thing I spec for SMS notifications is a GSM modem physically connected to
the monitoring box. There's still points of failure, but they're a lot
fewer than SMTP to some third party.
True paranoids (as we all should be) monitor their monitoring box, and it
might be permissible to use an SMTP to SMS gateway for that monitoring, as
long as you're monitoring all the appropriate things so that wide-scale
failures (such as power loss) still get to you via your GSM modem (mmm,
local UPSen).
> Anyone else have any issues, past or present, with this kind of thing?
It takes ~ 7 minutes from the time Nagios sends an email sms to AT&T to the time it hits my phone. I'm using @mobile.mycingular.com because mmode.com stopped working (which results in at least two txt pages vs. the one I was used to).
> Is SMTP to a mobile phone a fundamentally flawed way to do this?
I'm beginning to think it is!
Any place I've worked thats used sms alerting has ended up using either sms-tools (http://smstools.meinemullemaus.de/) or gnokki (www.gnokii.org) with a bit of scripting to send the sms ourselves.
Is it flawed? It depends on your business requirements. If seconds,
milliseconds, or even microseconds matter to your mission critical apps
(think real-time trading networks) then you would want a 24x7 staffed
NOC using an enterpise monitoring system - something like Openview. You
wouldn't want to rely on anything that sends emails.
> Anyone else have any issues, past or present, with this kind of thing?
It takes ~ 7 minutes from the time Nagios sends an email sms to AT&T to the time it hits my phone. I'm using @mobile.mycingular.com because mmode.com stopped working (which results in at least two txt pages vs. the one I was used to).
> Is SMTP to a mobile phone a fundamentally flawed way to do this?
I'm beginning to think it is!
I've never had a problem with Sprint (###@messaging.sprintpcs.com) accepting on their gateway. Although it has always accepted messages, sometimes there was an hour or two delay before the it hit the phone. Also, if you send too many messages too fast it'll stop talking to you for a bit (450 errors) or throttle the SMS delivery. The delay I normally see is under 30 seconds.
If you want to be fancy and take the internet out of the equation, you can use festival with Asterisk to have it call you and speak the messages. (Bonus points for a "press 1 to acknowledge this problem, 2 to escalate, etc." IVR tree.)
I've had good results with vzw.blackberry.net (Verizon Wireless +
Blackberry) in the Washington DC area. A secondary monitoring server
outside the network will send a message if the network problem is
serious enough to break the path from within the network to vzw.blackberry.net.
I also have a network monitoring system that's smart enough to track
dependencies so it doesn't page me about the http service being down
if it has already paged me because it can't ping the router that the
host sits behind. As a result, I very rarely get a notification flood.
It also keeps notifying until I ack it so if the first message doesn't
go through, the second does.
Once upon a time, Duane Waddle <duane.waddle@gmail.com> said:
We tend to avoid the whole SMTP mess and deliver messages to mobiles and
pagers via a modem and the provider's TAP gateway. It works quite well with
Verizon and AT&T/Cingular, but I've no experience with T-Mobile.
T-Mobile dropped their TAP access several years ago. The only way to
send messages to T-Mobile phones is SMTP or SMS.
I miss the old days of hanging a modem off the side of the monitoring
server and having it send a coded numeric page when something died.
Seemed like that was much more reliable. I'd second the recommendation
to go the modem route.
Or, if you want to mess around just trying things without spending any
money, try doing something like sending the alerts to a Gmail account,
on which you have forwarding set up to go to the gateway. Or have a
shell/perl/fetchmail script on another box offside download that Gmail
message and feed it to the SMS mail gateway.
I'd also perhaps set up (light, not excessive) monitoring of the
provider's inbound SMTP gateway for a bit, to see if you can prove if
it's your issue or theirs. If you can't reach their SMTP gateway
consistently, then try it from another connection on another network
(assuming you've got nine shell accounts around the world like most
admins seem to), and if the reliability data is similar, you know the
provider's got the problem, and you really need to either pound on the
provider, switch providers, or go the modem route.
I also have the feeling that unless you get a hold of somebody who
actually works on those servers at T-Mobile, their support people are
going to tell you it's working, no matter what, because it's a complex
thing that they have no visibility into. I ran into similar fun
conversations with Verizon Wireless in the past, before finally
getting to the actual right person to tell me what I needed to know.
BTW, how I handle it nowadays, believe it or not, is that the alerts
go to a Hotmail account that my Windows Mobile phone accesses. (I
know, I know, people complain about being able to mail to Hotmail -- I
must be one of the lucky ones who knows the secret code to figure it
out.) Has worked fine so far, put it in place a number of weeks ago.
Is SMTP to a mobile phone a fundamentally flawed way to do this?
Yes - think of the dependency chain involved. Years ago, hacking
hylafax (or similar DTMF sources) to dial directly to pagers was
a commonplace solution.