4 ms·

That in one line: "But I don't like it because it doesn't do things my preferred way!". People use Nagios because it works, and it gets everything right, inclu

That in one line: "But I don't like it because it doesn't do things my preferred way!". People use Nagios because it works, and it gets everything right, including config if you have any clue whatsoever how to set up a good object hierarchy. The only real problem with it is maintenance, an issue which Icinga resolved long ago.

zwily 13y ago
We add/remove about 150 nodes every day to/from our monitoring system automatically via APIs. That use case has always sucked for me with Nagios. How would you do that?
- peterstjohn 13y ago
  I'd be interested to hear about that too - often Nagios can spend much of its time being reconfigured than actually monitoring…
- blueskin_ 13y ago
  In my current job, it's done automatically with Puppet. My previous job was a lot smaller scale and hosts were manually added to a config file of hosts, but I had set up groups properly so they only needed a single hostgroup to inherit all their services, dependencies and contacts from there.
- darkandbrooding 13y ago
  Are you making the Nagios host pull (via NRPE) or are you asking the individual hosts to push (via NSCA)? I am trying to solve a similar problem. Given a dynamic population of hosts, each of which has a variable life span, I think that asking individual hosts to query their own state and then push that to a "monitoring receiver" is the most scalable, sustainable approach. At least, that's the theory I'll be testing this week.
  - zwily 13y ago
    We're not actually using Nagios. We use sensu because it was designed with this sort of dynamic environment in mind. (I'm trying to stay away from the "C" word. :)
seiji 13y ago
In my old job, for nagios they had a custom nagios tempting system built off C pre processor macros. You'd edit their custom config syntax, run a "build config" script, and everything would get converted into nagios-readable formats. The thing is: nagios doesn't actually work for more than monitoring about 100 machines. Everything after that is a hack. It's made where you know your systems by hand, are hand configuring everything, and setting up all alerts with love and care and a kiss as you edit every file manually. [This is your brain.] [This is your brain after losing sleep every night for a week because of nagios spurious alerting.]
vacri 13y ago
I'm only a Nagios newbie, and have inherited an amateur setup, but I can't see how Nagios does everything right. Comment out a host? Better hope there was no test linked to only that host, because Nagios will throw a fit until you hunt down anything orphaned and get rid of it. And it doesn't give you helpful log messages in figuring out what went wrong in these cases. The UI is also horrible, though I see they've remade that in the latest versions. In particular the UI does not update to show changes in state in a timely manner. If you tail the logs, you see that the state has changed as expected when expected, but the UI is still reporting old data for minutes to come. I haven't tried a lot of systems and am really no expert in monitoring, but saying Nagios gets everything right... just makes me feel oily. It can be best-of-class and still be shitty.

zwily 13y ago

We add/remove about 150 nodes every day to/from our monitoring system automatically via APIs. That use case has always sucked for me with Nagios. How would you do that?

peterstjohn 13y ago
I'd be interested to hear about that too - often Nagios can spend much of its time being reconfigured than actually monitoring…
blueskin_ 13y ago
In my current job, it's done automatically with Puppet. My previous job was a lot smaller scale and hosts were manually added to a config file of hosts, but I had set up groups properly so they only needed a single hostgroup to inherit all their services, dependencies and contacts from there.
darkandbrooding 13y ago
Are you making the Nagios host pull (via NRPE) or are you asking the individual hosts to push (via NSCA)? I am trying to solve a similar problem. Given a dynamic population of hosts, each of which has a variable life span, I think that asking individual hosts to query their own state and then push that to a "monitoring receiver" is the most scalable, sustainable approach. At least, that's the theory I'll be testing this week.
- zwily 13y ago
  We're not actually using Nagios. We use sensu because it was designed with this sort of dynamic environment in mind. (I'm trying to stay away from the "C" word. :)

seiji 13y ago

In my old job, for nagios they had a custom nagios tempting system built off C pre processor macros. You'd edit their custom config syntax, run a "build config" script, and everything would get converted into nagios-readable formats. The thing is: nagios doesn't actually work for more than monitoring about 100 machines. Everything after that is a hack. It's made where you know your systems by hand, are hand configuring everything, and setting up all alerts with love and care and a kiss as you edit every file manually. [This is your brain.] [This is your brain after losing sleep every night for a week because of nagios spurious alerting.]

vacri 13y ago

I'm only a Nagios newbie, and have inherited an amateur setup, but I can't see how Nagios does everything right. Comment out a host? Better hope there was no test linked to only that host, because Nagios will throw a fit until you hunt down anything orphaned and get rid of it. And it doesn't give you helpful log messages in figuring out what went wrong in these cases. The UI is also horrible, though I see they've remade that in the latest versions. In particular the UI does not update to show changes in state in a timely manner. If you tail the logs, you see that the state has changed as expected when expected, but the UI is still reporting old data for minutes to come. I haven't tried a lot of systems and am really no expert in monitoring, but saying Nagios gets everything right... just makes me feel oily. It can be best-of-class and still be shitty.