Using API for service monitoring

[danhs]

Kudos on the new API. REST API is a fantastic idea that's becoming more and more common in the era of web services. Great choice.

Let me also compliment you on the choices to include JSON, excellent decision. As well as implementing a design which has high-level, powerful methods as found in the web interface as well as low level methods allowing a developer to dig into the nitty-gritty. Very powerful and excellent decisions.

I have a use-case which I don't believe is addressed very naturally by the API.

Recently, I had a service outage from my ISP on a small handful of outbound phone numbers. I'd like to use the API to write a test script to make phone calls so that I know about service outages before they become crises.

But, without being able to detect automated error messages or fast busy signals, etc. it's a bit difficult.

Best workaround I can think up is to have the test script self-call its own IVR which then executes a separate URL which informs a monitoring process that outbound calls/inbound calls are successful.

This seems rather convoluted and complex (not to mention it ties up 2 phone lines). The other alternative of using packet capture logs seems too low level.


In an ideal world, this script would execute every 5 to 30 minutes. When the phone system goes down, I get alerted and can address the problem before it becomes a disaster.

Is there an elegant way to achieve this goal?

Daniel

[ianplain]

Hi you might want to look at Nagios, putting it simply you cant monitor a platform from that platform. What if it goes down you wouldnt know as its down.

We monitor all our customer servers with Nagios checking SIP IAX and Zap channel status as well as disk space etc

Ian

[danhs]

Hi you might want to look at Nagios, putting it simply you cant monitor a platform from that platform. What if it goes down you wouldnt know as its down.

We monitor all our customer servers with Nagios checking SIP IAX and Zap channel status as well as disk space etc

Ian

Absolutely. I was planning on using Zenoss, maybe Pandora FMS...one of them. So far, I have a Zenoss virtual machine up, but I'm not sure if that's the best possible monitoring solution.

I haven't yet settled on a monitoring solution because I'd like to find one that, basically, does *everything*. If you know of an all-in-one that you're happy with, I'd be extraordinarily happy to hear about it.

While Zenoss does a lot (including syslog) I'm really hoping to find a mature monitoring solution that can monitor config files for changes like monit.
========

Ian,
Does switchvox have an API for Zap channel monitoring?

Daniel

[ianplain]

Hi

You wont find a more mature system than nagios. plugins exist to monitor alost every thing .

As to switchvox api not sur eas we user asterisk and have a custom pluging t monitor all channel types .

Ian

[dpodolsky]

Daniel,
Thanks for all the positive remarks about the API, and I have some suggestions on how to use the API to monitor your PBX.

If you want to monitor the status of your voice provider, there a couple of ways depending on if you have an analog, voip, or T1 provider.

For a voip provider us the switchvox.status.voipProviders.getList Extend API method. This method is the same information you see on the system status page and will show you if your provider is Registered or if its down.

If you have a T1 or Analog lines use the switchvox.status.telephonyCards.getList Extend API method. This method is the same information you see on the system status page and will show you if your T1 or analog lines are in Red Alarm.

If you want to be really thorough, you can even monitor the state of all your VoIP Phones using the switchvox.status.phones.getList Extend API method. This will show you the state of every phone connected to your system. Great to monitor the connectivity of external phones.

All of these methods show you the current status of your providers, but I still like your idea of calling to make 100% sure your calls are working. A provider might show a Registered status, but something might be going wrong upstream with your provider and the status won't show anything. That scenario would be rare, but the phone call would be a nice touch. The test would take up two lines, but only for a couple of seconds, once the call connects and hits up the url it could drop immediately.

Hope this information helps, and let us know what you build.

[danhs]

Daniel,
Thanks for all the positive remarks about the API, and I have some suggestions on how to use the API to monitor your PBX.

If you want to monitor the status of your voice provider, there a couple of ways depending on if you have an analog, voip, or T1 provider.

For a voip provider us the switchvox.status.voipProviders.getList Extend API method. This method is the same information you see on the system status page and will show you if your provider is Registered or if its down.

If you have a T1 or Analog lines use the switchvox.status.telephonyCards.getList Extend API method. This method is the same information you see on the system status page and will show you if your T1 or analog lines are in Red Alarm.

If you want to be really thorough, you can even monitor the state of all your VoIP Phones using the switchvox.status.phones.getList Extend API method. This will show you the state of every phone connected to your system. Great to monitor the connectivity of external phones.

All of these methods show you the current status of your providers, but I still like your idea of calling to make 100% sure your calls are working. A provider might show a Registered status, but something might be going wrong upstream with your provider and the status won't show anything. That scenario would be rare, but the phone call would be a nice touch. The test would take up two lines, but only for a couple of seconds, once the call connects and hits up the url it could drop immediately.

Hope this information helps, and let us know what you build.

Thanks very much for the API overview. Much appreciated.

I wrote the basic code necessary to call the server and get a nice response back (the wget example from the blog was helpful).

Writing Nagios plugins should now be pretty easy.

Seems like the prevailing style is 1 plugin/executable per test. Not multiple tests in each executable. Am I mistaken in that understanding? So, each executable corresponds to 1 API method (or test, really....).


Daniel

[danhs]

Daniel,
Thanks for all the positive remarks about the API, and I have some suggestions on how to use the API to monitor your PBX.

If you want to monitor the status of your voice provider, there a couple of ways depending on if you have an analog, voip, or T1 provider.

For a voip provider us the switchvox.status.voipProviders.getList Extend API method. This method is the same information you see on the system status page and will show you if your provider is Registered or if its down.

If you have a T1 or Analog lines use the switchvox.status.telephonyCards.getList Extend API method. This method is the same information you see on the system status page and will show you if your T1 or analog lines are in Red Alarm.

If you want to be really thorough, you can even monitor the state of all your VoIP Phones using the switchvox.status.phones.getList Extend API method. This will show you the state of every phone connected to your system. Great to monitor the connectivity of external phones.

All of these methods show you the current status of your providers, but I still like your idea of calling to make 100% sure your calls are working. A provider might show a Registered status, but something might be going wrong upstream with your provider and the status won't show anything. That scenario would be rare, but the phone call would be a nice touch. The test would take up two lines, but only for a couple of seconds, once the call connects and hits up the url it could drop immediately.

Hope this information helps, and let us know what you build.

Thanks very much for the API overview. Much appreciated.

I wrote the basic code necessary to call the server and get a nice response back (the wget example from the blog was helpful).

Writing Nagios plugins should now be pretty easy.

Seems like the prevailing style is 1 plugin/executable per test. Not multiple tests in each executable. Am I mistaken in that understanding? So, each executable corresponds to 1 API method (or test, really....).


Daniel

I went back to work on this today (couldn't all this week). Nagios output standards (and reconciling that with Zenoss) turned out to be annoying. Anyway, that part is also done now. So I'm not expecting anymore bumps in the road for future stuff.

I finished a Nagios module that monitors telephony card status. I'd like to put it on to some kind of shared/public subversion or mercurial repository. I suppose I could use google code, but is there a repository/project site that's more appropriate for this community?

If there isn't anything already available to this community, Google Code is probably a pretty good choice. Simple and effective. Since this is a developer community, I thought there might be something already considered that would be more convenient.

Daniel

[dpodolsky]

Daniel, that is great that you got your Nagios plugin to monitor Switchvox up and working and even better that you plan on sharing it with the developer community. I think Google Code is a great place to host this project and when you have it hosted please share the link so we can pass it along to other developers.

[danhs]

I put it up on Google Code.

I released it under the GPL in the hopes that other people might find it useful and will be encouraged to get involved: contribute bug fixes, new plug-in modules, enhancements, etc....

So please contribute, and remember: since it's under the GPL no one is going to run away with your contribution and make their own changes, sell them and not contribute back. Any changes made to GPL licensed code must be released if the modifier distributes his/her changes. So you have no reason to not contribute! We'll all get richer, the community will be greatly enhanced!

As far as ease of development is concerned, I think this framework substantially lowers the barrier to doing productive development.

I wrote modules for Nagios and Switchvox then blended the two together. As a result, you can literally write useful Switchvox/Nagios plug-ins in about 15 minutes. I wrote 4 Nagios plugins which you can use as examples (they're basically the 4 plug-ins I need to adequately monitor my office's phone system).

No downloads right now
Sorry, I forgot to upload a tar.gz or a .zip file. So no downloads tonight. If you're a developer (you're in *this* forum, right?) you can do an SVN checkout.

How to run things
It's really pretty simple. Run each of the programs in the bin directory, each one will print out usage directions to the terminal. Pretty simple, eh

Have a good evening. I'll upload a copy of the source in .zip and/or tar.gz tomorrow.


Daniel[/u]