The Guru College
Setting Up An Analog Modem For Nagios Alerts, Part 3
Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:
``Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we’re talking from localhost to the modem (so we’re not relying on the network being up to send the pages). Send pages with
qpage -f from_address user_1_pager <em>message</em>
or
qpage -f from_address server_admins_pager <em>message</em>
The first example will hit user_1’s pager, and the second should hit both. Once this is working, create a simple script to queue messages. I’ve written a quick one in perl, but you can use pretty much any language you like. Shove it into your nagios/libexec directory, and make sure it’s owned and executable by the nagios user.
```Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:
``Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we’re talking from localhost to the modem (so we’re not relying on the network being up to send the pages). Send pages with
qpage -f from_address user_1_pager <em>message</em>
or
qpage -f from_address server_admins_pager <em>message</em>
The first example will hit user_1’s pager, and the second should hit both. Once this is working, create a simple script to queue messages. I’ve written a quick one in perl, but you can use pretty much any language you like. Shove it into your nagios/libexec directory, and make sure it’s owned and executable by the nagios user.
Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.
````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
Finally, add create a new user definition in Nagios, which you’ll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren’t going to actually use it, but consistency is king here.
Finally, add the contact handlers in Nagios, copying out the standard email contact and replacing it with something like this:
`````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
```
Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.
````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.
Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:
``
Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
`qpage -f from_address user_1_pager <em>message</em>`
or
`qpage -f from_address server_admins_pager <em>message</em>`
The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.
```
Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.
Finally, add the contact handlers in Nagios, copying out the standard email contact and replacing it with something like this:
`````
Now, when the appropriate service flags itself, qpage will dispatch a message to the listening daemon, and send a page in addition to an email, a jabber message, an SMS, or whatever system you like. If there’s an interest, I’ll also walk through how to setup Google Talk (jabber) notifications and SMS notifications with gnokii-smsd.