Our publisher really dropped the ball on this and all the authors involved with the book (including me) are very sorry about the problems purchasers of the book have been having getting access to the code etc in the book.
because we saw early on the problems Syngress was having getting it's act together; on the site you will also find the names and email addresses of the book's management team, they have all promised to do their best to help anyone out who has purchased the book and has complaints about the electronic content that was supposed to accompany the book.
Very nice approach, sounds like a well thought out system. I am doing the same thing with regards to Wiki jump-off.. using the service and host 'notes url' links to provide jump off points to our Wiki so that anyone using Nagios can add SOPs, notes, etc, whatever fits the group using Nagios best.
I might borrow your idea:) and do something similar using the JSON output from Nagios, that sounds very efficient.
I am sorry you haven't heard back from them. You can write either of these two people for help:
Cater, Matthew - M.Cater@elsevier.com
Colantoni, Laura - L.Colantoni@elsevier.com
Laura is a managing editor on the book and Matt worked extensively on it as well. They are both nice people and both have indicated that they wish to straighten out the problems we have had post publication, which includes your complaint and a number of others.. some of which they have resolved, and some which they still haven't 4 months after the book came out. Grrr.
Things have been a mess since they reorganized. If you bought the book, please write either of these two people to get your situation straightened out (they are both on the management team for the book):
Colantoni, Laura (ELS-BUR) - L.Colantoni@elsevier.com
Cater, Matthew (ELS-BUR) - M.Cater@elsevier.com
They are responsive and will do their best to work this out for you.. respond to this thread if you don't hear from them in the next few days.
I am one of the authors of the book (Max Schubert), and I have been very disappointed myself with how poorly this transition has happened, frustrating because nothing authors can do to help and you are not the first customer to complain.. they have also misplaced the VMWare image promised with the book and have yet to get that online. Grr.
And puppet makes a great companion to Nagios or any other NNM for this.. why might this be better than having the NNM scan everything on your networks looking for new devices? * Puppet knows your host, so it can deterministically place the host in the right groups using the rules you define for determining where the host belongs.. much less fuzzy than finding a host and then figuring out from the outside what kind of host the host is * Puppet can send data off to your CMDB at the same time * Puppet can check a template into SVN (or whatever SCM system is in use) and trigger a reload of Nagios or other NNMs without user intervention.
Just using Puppet for this example because it, like Nagios, is so flexible and so easy to integrate with any other systems in use at an organization.
Ok, here is one way to handle this, not perfect, but better than having to redefine every service just to get a new contact group.
Say we have a net-snmp hostgroup that acts as a container for all of our nifty Net-SNMP based services (service to hostgroup relationship).
Now group west-coast wants to have all of those checks but they want to be notified via their contacts not the default service contacts.
You can: * Turn off notification for all services that are associated with host groups in global mappings.. so notification is off by default. * Turn on regexp matching in the Nagios config * define a new serviceescalation object that catches all the hosts in your west coast group * Define contacts in the escalation object
Example: * West coast hosts have the string 'west-' in the name (if they don't just create a new host group that lists them all * Contact group for service checks on the host is west-coast-contacts
; West coast hosts custom notification rules define serviceescalation{
host_name.*-west-.*
service_description West coast notification
contact_groups west-coast-contacts
first_notification 1 ; Notify immediately
last_notification 0 ; Notify as long as this is an issue
notification_interval 60 ; or whatever makes sense
escalation_period 24x7
escalation_options c ; Only notify on critical problems }
Now you don't have to change your global service to host group mappings, you can just add group-specific hosts to your global groups and then control the service notifications through serviceescalation objects.
Do you mean the contact group? Yes, I haven't found a terrific way around that either. I will define a base service template for each specific customer / group that inherits from my global template.. it has the contact group(s) that make sense for that customer in them and just inherit from that template for each service I define for the new customer or group, but that still involves a one to two line template per service for each service the customer wants.
Hmm.. that is a really good point and breaks having services all mapped to host groups globally if different groups want only want someone in their group to be notified for that set of services (instead of a global group), doesn't it?
Nice points about set up; this is a major miss in a lot of NNM setups, irregardless of choice. Somehow companies do not get or forget that an NNM really is a communication proxy and filter: * Communicate events to people *who can do something about the issue* without having to have a person perform a mindless, repetitive check over and over. * Make it easier to store and view historical performance data and alert data for the purposes of knowing when to scale up or replace hardware or focus on software that is causing problems. * Help close the communication gap between those who manage hardware, those who create software, operations and maintenance staff, and management. * Make it easier to communicate system, application and network performance and availability to managers, non-technical people in an organization, and customers.
Some companies also seem to forget that before NNMs people had to do manual checks, and when that was the case, because that was an expensive operation, you would only have people checking the most important indicators of health for the system, application, or device or you would be wasting precious paid people time:P.
So many companies mistakenly think that doing what you describe is enough to make for a meaningful system: * Monitor everything that can be monitored * Throw up alerts on a big screen * Send emails
You hit the nail on the head about methodology.
Most software packages can be configured to do the right thing for an organization, but the organization has to invest time in people still to get that done:p. Having 3 junior people doing 'eyes on glass' as thousands of events occur for systems or domains of expertise they have not been trained in is a waste of money and only creates frustration and a negative attitude about the value of automated / semi-automated monitoring.
Like you, too often I have seen a company think that network management software is the solution rather than it being treated as the glue that helps the people in a company communicate effectively about applications, systems, and networks.
Another big help that also is a source of the 'too complex' complaint is using the object-oriented features of the Nagios configuration language to define base node object definitions that define the host type (base definitions also include host group associations for the service-hostgroup-host relationships you mention).. I use SNMP a lot with Nagios as well, and especially with Nagios 3 I use this feature.
To continue your example:), I might have a host template for a web server that puts it in the right host groups for agent-less checks, but then I also create host templates that define the custom attributes needed for each type of host-based SNMP agent we have.
So, for example, for Sysedge this would include hard-coding SNMP version 1, port 1691, etc.. and that agent template can have a Sysedge hostgroup associated with it to give the client whatever Sysedge-specific SNMP tests and generic we have in place as well through hostgroup associations.
Then the check commands just look for the custom variables I use throughout my config to define snmp port, version, community, etc.. so adding a new web host is then reduced to just 5 attribute lines:p
Having been in Openview shops exclusively, I can see how powerful, and yet frickin' misguided it is. Openview is used, not because of how powerful or elegant it is (it is one, but not the other) but because "HP makes it, and everybody uses it, so we are taking less risk."
Great point, there is a very interesting anti-pattern that i have seen happen in several larger organizations with commercial products like HPOV or Tivoli: * Someone goes for the self-healing, auto-discovers everything hype that commercial monster product marketing types throw at potential customers * Company buys software * Company pays consultants to help install and configure it * COmpany pays big bucks for a support contract * Company pays for a handful of employees to get training at some level
So already our company has a big investment in the software and they haven't even done anything real with it yet.
* Company gets to be very comfortable with the software and used to it's quirks * Company discovers "Ah, it does X and Y, but we realllly need Z to be covered" * COmpany shells out more and more $$$ to learn to customize OR starts paying in-house developers to work around the limitations
So now a rational and reasonable manager or employee says "Hey, isn't this costing us waaay more money than P or Q or R or even S, or even OSS T if we did it ourselves?"
By this time the company is so deep financially into the product that they are afraid to tell higher ups they need to change for fear of looking like they just wasted a ton of money on something that really doesn't meet their needs.
Laziness kicks in as well as does a strong desire not to have to go through that same integration process with another large product and another large company.. so the cycle continues:).
This doesn't happen all the time, but is something I have seen a number of times.
So, back to Openview NNM for a second:
I was impressed that with Openview NNM 8 they moved to using PostgreSQL and JBoss, but then lost that 'warm glow' when I found out that the basic NNM still just does basic SNMP tests for nodes and no performance tests.. and then got a cold feeling when we found out that the performance add on (SPi) for it that lets it do basic network metrics (in/out bits, errors, collisions) has to run on a Windows host! Doh! And then the reporting uses Crystal / Business Object bloatware.. gross!
Yes, there are the ugly monsters. Examples: * Tivoli, Openview, BMC anything
Then there are the less expensive monsters that came out to beat the ugly monsters by being relatively cheaper and slightly more open and useful. Examples: * Spectrum, eHealth * SevOne
Then there are the 'cheap but not so NOC friendly' products that came out to make basic monitoring easy. Examples: * What's Up Gold * Server's Alive
Then there are the OSS projects that came out in reaction to the expensive less than open commercial projects. Examples: * Nagios * Pandora * Cacti * Big Brother * MonIT
Then there are the products that try to hit the middle ground between free/OSS and commercial but more reasonable than the monsters. Examples: * Zabbix * Hobbit * ZenOss
and more expensive but less than the monsters... example: * Hyperic
My list is not comprehensive by any means.. so companies and consultants have a lot of different migration paths they can use to get away from the very expensive, very stovepipe NMSs that used to rule the field of monitoring to less expensive ones with some custom work allowed to free ones that require a fair amount of custom work with the tradeoff of no licensing or overpriced support options (obviously once you go down doing in-house work you incur the cost of having in-house developers maintain the work unless your organization is willing to let you contribute back to the OSS community.. and even then you will still have in house support needed).
Set up dependencies is a must, use notification_delay wisely, and only send out emails or other 'push' notifications for problems that have to have immediate attention. I like to take the approach of monitoring everything that is important but only send emails out for problems that really truly require immediate attention from on-call staff.
Agreed, time and money spent on integrating Nagios into an organization (or any other free OSS product) to me is much better time and money spent than spending money on licenses and paying support people for a commercial product who then not only get your money but also get the benefits of the knowledge learned from the experience instead of your company or group getting that information.
Even that wouldn't be sooo bad except that many commercial companies don't even share that knowledge in a way that other customers can benefit from unless they pay for consulting time... most commercial NNM producers have horrid public forums and KBs that really only cover issues related to upgrades and licensing as opposed to lessons learned by other customers.
This of course only applies to organizations that have development/IT groups that are large enough to support custom integration efforts, I understand that there are many places who can't afford to invest in in-house development or who really do not want to learn how to do systems/application/network monitoring themselves.
If you're polling the devices anyway, why can't you feed the data into a database and draw charts? Why do you need two systems? It all comes from the same source.
You don't need two tools, the PNP Plugin does RRD graphing from performance data returned from Nagios (there are other add-ons for Nagios that do this as well), PNP is just the most flexible in my opinion.
Slashdot Mirror
Hi,
Our publisher really dropped the ball on this and all the authors involved with the book (including me) are very sorry about the problems purchasers of the book have been having getting access to the code etc in the book.
The author team created this site
http://www.nagios3book.com/
because we saw early on the problems Syngress was having getting it's act together; on the site you will also find the names and email addresses of the book's management team, they have all promised to do their best to help anyone out who has purchased the book and has complaints about the electronic content that was supposed to accompany the book.
Very nice approach, sounds like a well thought out system. I am doing the same thing with regards to Wiki jump-off .. using the service and host 'notes url' links to provide jump off points to our Wiki so that anyone using Nagios can add SOPs, notes, etc, whatever fits the group using Nagios best.
I might borrow your idea :) and do something similar using the JSON output from Nagios, that sounds very efficient.
I am sorry you haven't heard back from them. You can write either of these two people for help:
Cater, Matthew - M.Cater@elsevier.com
Colantoni, Laura - L.Colantoni@elsevier.com
Laura is a managing editor on the book and Matt worked extensively on it as well. They are both nice people and both have indicated that they wish to straighten out the problems we have had post publication, which includes your complaint and a number of others .. some of which they have resolved, and some which they still haven't 4 months after the book came out. Grrr.
Things have been a mess since they reorganized. If you bought the book, please write either of these two people to get your situation straightened out (they are both on the management team for the book):
Colantoni, Laura (ELS-BUR) - L.Colantoni@elsevier.com
Cater, Matthew (ELS-BUR) - M.Cater@elsevier.com
They are responsive and will do their best to work this out for you .. respond to this thread if you don't hear from them in the next few days.
I am one of the authors of the book (Max Schubert), and I have been very disappointed myself with how poorly this transition has happened, frustrating because nothing authors can do to help and you are not the first customer to complain .. they have also misplaced the VMWare image promised with the book and have yet to get that online. Grr.
I hope they respond quickly to you.
Did you enable regular expression matching in nagios.cfg? Have to set
use_regexp_matching=1
in nagios.cfg ...
I will try this tonight myself to see what results I get.
And puppet makes a great companion to Nagios or any other NNM for this .. why might this be better than having the NNM scan everything on your networks looking for new devices? .. much less fuzzy than finding a host and then figuring out from the outside what kind of host the host is
* Puppet knows your host, so it can deterministically place the host in the right groups using the rules you define for determining where the host belongs
* Puppet can send data off to your CMDB at the same time
* Puppet can check a template into SVN (or whatever SCM system is in use) and trigger a reload of Nagios or other NNMs without user intervention.
Just using Puppet for this example because it, like Nagios, is so flexible and so easy to integrate with any other systems in use at an organization.
Ok, here is one way to handle this, not perfect, but better than having to redefine every service just to get a new contact group.
Say we have a net-snmp hostgroup that acts as a container for all of our nifty Net-SNMP based services (service to hostgroup relationship).
Now group west-coast wants to have all of those checks but they want to be notified via their contacts not the default service contacts.
You can: .. so notification is off by default.
* Turn off notification for all services that are associated with host groups in global mappings
* Turn on regexp matching in the Nagios config
* define a new serviceescalation object that catches all the hosts in your west coast group
* Define contacts in the escalation object
Example:
* West coast hosts have the string 'west-' in the
name (if they don't just create a new host group that lists them all
* Contact group for service checks on the host is west-coast-contacts
; West coast hosts custom notification rules .*-west-.*
define serviceescalation{
host_name
service_description West coast notification
contact_groups west-coast-contacts
first_notification 1 ; Notify immediately
last_notification 0 ; Notify as long as this is an issue
notification_interval 60 ; or whatever makes sense
escalation_period 24x7
escalation_options c ; Only notify on critical problems
}
Now you don't have to change your global service to host group mappings, you can just add group-specific hosts to your global groups and then control the service notifications through serviceescalation objects.
Make sense?
Do you mean the contact group? Yes, I haven't found a terrific way around that either. I will define a base service template for each specific customer / group that inherits from my global template .. it has the contact group(s) that make sense for that customer in them and just inherit from that template for each service I define for the new customer or group, but that still involves a one to two line template per service for each service the customer wants.
Hmm .. that is a really good point and breaks having services all mapped to host groups globally if different groups want only want someone in their group to be notified for that set of services (instead of a global group), doesn't it?
Have to think about how to resolve that one :).
Nice points about set up; this is a major miss in a lot of NNM setups, irregardless of choice. Somehow companies do not get or forget that an NNM really is a communication proxy and filter:
* Communicate events to people *who can do something about the issue* without having to have a person perform a mindless, repetitive check over and over.
* Make it easier to store and view historical performance data and alert data for the purposes of knowing when to scale up or replace hardware or focus on software that is causing problems.
* Help close the communication gap between those who manage hardware, those who create software, operations and maintenance staff, and management.
* Make it easier to communicate system, application and network performance and availability to managers, non-technical people in an organization, and customers.
Some companies also seem to forget that before NNMs people had to do manual checks, and when that was the case, because that was an expensive operation, you would only have people checking the most important indicators of health for the system, application, or device or you would be wasting precious paid people time :P.
So many companies mistakenly think that doing what you describe is enough to make for a meaningful system:
* Monitor everything that can be monitored
* Throw up alerts on a big screen
* Send emails
You hit the nail on the head about methodology.
Most software packages can be configured to do the right thing for an organization, but the organization has to invest time in people still to get that done :p. Having 3 junior people doing 'eyes on glass' as thousands of events occur for systems or domains of expertise they have not been trained in is a waste of money and only creates frustration and a negative attitude about the value of automated / semi-automated monitoring.
Like you, too often I have seen a company think that network management software is the solution rather than it being treated as the glue that helps the people in a company communicate effectively about applications, systems, and networks.
Another big help that also is a source of the 'too complex' complaint is using the object-oriented features of the Nagios configuration language to define base node object definitions that define the host type (base definitions also include host group associations for the service-hostgroup-host relationships you mention) .. I use SNMP a lot with Nagios as well, and especially with Nagios 3 I use this feature.
To continue your example :), I might have a host template for a web server that puts it in the right host groups for agent-less checks, but then I also create host templates that define the custom attributes needed for each type of host-based SNMP agent we have.
So, for example, for Sysedge this would include hard-coding SNMP version 1, port 1691, etc .. and that agent template can have a Sysedge hostgroup associated with it to give the client whatever Sysedge-specific SNMP tests and generic we have in place as well through hostgroup associations.
Then the check commands just look for the custom variables I use throughout my config to define snmp port, version, community, etc .. so adding a new web host is then reduced to just 5 attribute lines :p
define host {
use my-webhost-template
hostgroups +sysedge-agent
host_name myhost.example.com
address 192.168.1.1
parents my-host-parent
}
Yes, this requires thought and planning ahead of time but the payoffs in mid-long term maintenance and scaling of a configuration are huge.
Having been in Openview shops exclusively, I can see how powerful, and yet frickin' misguided it is. Openview is used, not because of how powerful or elegant it is (it is one, but not the other) but because "HP makes it, and everybody uses it, so we are taking less risk."
Great point, there is a very interesting anti-pattern that i have seen happen in several larger organizations with commercial products like HPOV or Tivoli:
* Someone goes for the self-healing, auto-discovers everything hype that commercial monster product marketing types throw at potential customers
* Company buys software
* Company pays consultants to help install and configure it
* COmpany pays big bucks for a support contract
* Company pays for a handful of employees to get training at some level
So already our company has a big investment in the software and they haven't even done anything real with it yet.
* Company gets to be very comfortable with the software and used to it's quirks
* Company discovers "Ah, it does X and Y, but we realllly need Z to be covered"
* COmpany shells out more and more $$$ to learn to customize OR starts paying in-house developers to work around the limitations
So now a rational and reasonable manager or employee says "Hey, isn't this costing us waaay more money than P or Q or R or even S, or even OSS T if we did it ourselves?"
By this time the company is so deep financially into the product that they are afraid to tell higher ups they need to change for fear of looking like they just wasted a ton of money on something that really doesn't meet their needs.
Laziness kicks in as well as does a strong desire not to have to go through that same integration process with another large product and another large company .. so the cycle continues :).
This doesn't happen all the time, but is something I have seen a number of times.
So, back to Openview NNM for a second:
I was impressed that with Openview NNM 8 they moved to using PostgreSQL and JBoss, but then lost that 'warm glow' when I found out that the basic NNM still just does basic SNMP tests for nodes and no performance tests .. and then got a cold feeling when we found out that the performance add on (SPi) for it that lets it do basic network metrics (in/out bits, errors, collisions) has to run on a Windows host! Doh! And then the reporting uses Crystal / Business Object bloatware .. gross!
Yes, there are the ugly monsters. Examples:
* Tivoli, Openview, BMC anything
Then there are the less expensive monsters that came out to beat the ugly monsters by being relatively cheaper and slightly more open and useful. Examples:
* Spectrum, eHealth
* SevOne
Then there are the 'cheap but not so NOC friendly' products that came out to make basic monitoring easy. Examples:
* What's Up Gold
* Server's Alive
Then there are the OSS projects that came out in reaction to the expensive less than open commercial projects. Examples:
* Nagios
* Pandora
* Cacti
* Big Brother
* MonIT
Then there are the products that try to hit the middle ground between free/OSS and commercial but more reasonable than the monsters. Examples:
* Zabbix
* Hobbit
* ZenOss
and more expensive but less than the monsters ... example:
* Hyperic
My list is not comprehensive by any means .. so companies and consultants have a lot of different migration paths they can use to get away from the very expensive, very stovepipe NMSs that used to rule the field of monitoring to less expensive ones with some custom work allowed to free ones that require a fair amount of custom work with the tradeoff of no licensing or overpriced support options (obviously once you go down doing in-house work you incur the cost of having in-house developers maintain the work unless your organization is willing to let you contribute back to the OSS community .. and even then you will still have in house support needed).
Set up dependencies is a must, use notification_delay wisely, and only send out emails or other 'push' notifications for problems that have to have immediate attention. I like to take the approach of monitoring everything that is important but only send emails out for problems that really truly require immediate attention from on-call staff.
Agreed, time and money spent on integrating Nagios into an organization (or any other free OSS product) to me is much better time and money spent than spending money on licenses and paying support people for a commercial product who then not only get your money but also get the benefits of the knowledge learned from the experience instead of your company or group getting that information.
Even that wouldn't be sooo bad except that many commercial companies don't even share that knowledge in a way that other customers can benefit from unless they pay for consulting time ... most commercial NNM producers have horrid public forums and KBs that really only cover issues related to upgrades and licensing as opposed to lessons learned by other customers.
This of course only applies to organizations that have development/IT groups that are large enough to support custom integration efforts, I understand that there are many places who can't afford to invest in in-house development or who really do not want to learn how to do systems/application/network monitoring themselves.
Agreed that the review does seem less than impartial but I can assure you that Syngress doesn't pay anyone enough to have money to 'pay people off.' :p
If you're polling the devices anyway, why can't you feed the data into a database and draw charts? Why do you need two systems? It all comes from the same source.
You don't need two tools, the PNP Plugin does RRD graphing from performance data returned from Nagios (there are other add-ons for Nagios that do this as well), PNP is just the most flexible in my opinion.