この記事は日本語でもご覧頂けます。 詳細はこちら。

Nagios Alternative – Cost Calculator.

By David Mytton,
CEO & Founder of Server Density.

Published on the 12th November, 2014.

A common misconception in the industry is the notion that open source monitoring software is free. This is true if you’re looking at licensing alone, but there’s infinitely more factors to take into account than that. Being a great Nagios alternative, we decided to work out exactly how expensive Nagios is in comparison to our own server monitoring.

Server Density’s job as a competitor is to highlight some of the problems and difficulties of using Nagios, without damning the open source community and misleading anyone. Anticipating some critique of our calculations we’ve decided to write this article on our ‘workings’. It also gives you the ability to engage with us about the calculations – please comment below if you think we’ve gone wrong. If you can convince us, we’ll happily amend our math. For now though, here’s how we’ve worked it out.

Before you start

You’ll notice a common theme across many of these headings being the time Nagios takes to setup and use. In a world where time and money are completely unrelated, this is how the relationship between Server Density and Nagios looks:

  • Nagios saves you money.
  • Server Density saves you time.

Or

  • Nagios costs you time.
  • Server Density costs you money.

But of course this isn’t true, the age old idiom “time is money” couldn’t be more applicable to the world of fast moving tech startups, so:

  • Nagios costs you money.
  • Server Density costs you money.

Those principles form the basis of our Nagios cost calculator, to which we’ve created a monetary value for Nagios based on the time you’d expect to take setting up and maintaining the open source tool. You can evaluate the cost of a basic monitoring setup if you’d like, but if you need to replicate our monitoring infrastructure it’s best to keep all of the options ticked.

Nagios Cost Calculator

Nagios Hardware Requirements

A Nagios server isn’t cheap to run, they require a large amount of processing power, especially if you have a lot of servers:

Under 50 servers

To monitor anything under 50 servers we suggest something similar to the Amazon m3.medium instance type. At the time of writing (Nov, 2014) that’ll set you back $0.070 an hour, which totals to a yearly cost of $613.

Over 50 servers

Monitoring more than 50 servers will demand more from your Nagios server, so you’ll need to upgrade. For this we’d suggest an m3.xlarge instance. At the time of writing (Nov, 2014) that’ll set you back $0.280 an hour, which totals to a yearly cost of $2452.

We’ve used AWS as the cost benchmark as they’re constantly pushing costs down and are the most popular provider. We didn’t consider reserved instances because they add some complexity to calculating the cost due to the pre-purchase fees, which add to the overall setup cost of Nagios you don’t get with Server Density.

Need redundancy?

If you take monitoring seriously you’ll want to keep redundancy checked. To replicate how Server Density is deployed with full redundancy within our data centers combined with geographic redundancy of deploying into multiple facilities (your monitoring needs to be more reliable than what you’re actually monitoring!) you’ll need to have at least 2 servers each across 2 data centers. In the case that you’re monitoring under 50 servers that’s $613 * 4, if you’re monitoring over 50 it’s $2452 * 4.

This level of redundancy is necessary to ensure you can survive the failure of a node within one facility as well as the failure of the entire data center. Of course, this assumes you know how to set up Nagios in a redundant, load balanced cluster.

Once you get over 50 servers then it’s totally unacceptable to be running just a single Nagios server, so we forced this above 50 servers with our Nagios calculator.

How long does Nagios take to setup?

We’ve calculated the initial monitoring setup to take 2 working days. This can be shorter if you know what you’re doing or longer if you’ve never done it before. This is because it takes time to go through the installation process and in particular, get the initial config right.

How long does Nagios take to deploy across multiple server?

Once you’ve spent the 16 hours setting your Nagios server up, you still need to consider how long it takes to install the monitoring agent(s). There’s no shortage of config files when you’re running Nagios. It’s usually the initial setup that takes the longest, with each additional server only taking a few minutes to get up and running.

Nagios alerts configuration

Monitoring alerts need to be reliable and flexible. By default, Nagios limits alert delivery to email so it takes extra time to set up SMS alerts, or configure push notifications on your phone, plus the services you’ll want to use are often not free. SMS gateway reliability is important and with push notifications you need apps, or some 3rd party that supports generic notifications. Again, reliability has to be monitored. With Server Density, all of this is taken care for you at no extra cost. Even down to free SMS credits.

As part of the Nagios cost calculator, we estimate that setting up an alerting system that compares to the one we offer will take 8 hours of your time and have ignored the cost of using the external service such as for the SMS credits.

Nagios Graphing

It will take you a further 8 hours to install a plugin like nagiosgraph or configure an entirely separate system such as Cacti or Graphite – and even then, here’s the same data presented by Nagios and Server Density:

Nagios Alternative

Nagios Security

Keeping everything nice and secure is essential. It takes time to get some basic hardening on any server and we’ve budgeted a couple of hours for this. What we don’t include is ongoing security assessments and patches that we take care of for you with Server Density. This is particularly important if a piece of software is installed on every single one of your servers or is a key part of your systems…such as monitoring.

Monitoring your monitoring

With no redundancy set up then you’re going to struggle to monitor the performance of your Nagios server without 2 to monitor each other. In the instance of no redundancy, you’ll need to use a service like Server Density on our 1 server plan to make sure everything is okay with your single Nagios server.

Nagios Maintenance

By default our calculator is set to allow for 12 hours of maintenance every year. That’s one hour a month fiddling with preferences, tweaking configs, fixing problems, upgrading or even thinking about improvements to your monitoring setup.

Incident management

We assume you to spend 6 hours every year (30 minutes a month) on incidents relating to your Nagios monitoring servers. This could be a hardware failure, instance retirements, whole region/data center reboots, instance upgrades, dealing with backups or clearing out metrics data from disk space.

Worldwide locations for web checks

If you want availability monitoring, then your best bet is to pay for an external provider like Server Density or Pingdom. On which, a ’50 checks’ account will cost ~ $250/year (as of Nov 2014).

Setting up geographically dispersed monitoring locations and scheduling checks amongst them all is non-trivial, and is something you get as part of the product with Server Density.

Most of the time the calculator settings are defaults and can be changed based on how long you’d consider things to take you. We have tried to be fair to Nagios with our time estimations, because after all cost isn’t the only way we think we have an advantage over the open source competition. There are some cases when Nagios is cheaper (e.g. if you don’t value your time highly or with tiny numbers of servers…but then why are you setting up a complex monitoring tool like Nagios in the first place?!) but with all the functionality Server Density provides, we think we have a pretty good offer!

Thanks for taking the time to read through our justification, if you’d like to join the discussion please leave a comment below, or equally this reddit thread is home to some interesting comments – we love to reading and responding to your thoughts. Oh, and if you’re sick of Nagios, consider us next time you’re looking for a Nagios Alternative.

  • Jeremy Wilson

    This whole post is completely disingenuous and self-serving. Of course a company that makes money from monitoring is going to find that using their services is the best value. It’s like a cigarette company sponsoring a study on the effects of smoking and discovering no link to how it causes cancer.

    I have a Nagios config that I developed years ago that rolls out in minutes and does basic monitoring and graphing with one script, and installing NRPE on the rest of the hosts. I also have scripts to monitor things beyond CPU and memory – mysql, postgres, redis, etc. It also includes SMS notification. Those hours I spent initially have paid off in major dividends since. I don’t have to repeat it for each infrastructure I do after, and most importantly, I don’t need to spend any more money on it. I had monitoring set up on 50 servers in less than 10 minutes last time. Done and done.

    In terms of the type of instance or server you need, I’ve run super-efficient installs on the free-tier micro instances for sub-100 server installs without issue.

    Most importantly, with an in-house Nagios (Icinga in my case) install, I’m not sending off critical internal status info on the public internet, and I’m not relying on a third party to provide a mission-critical service.

    • Thanks for commenting. Always good to have a discussion over the points we’ve raised. We think we make a very good case for why Server Density is better than picking Nagios. There’s a lot of misconceptions about Nagios et al being “free” it’s in our interests to highlight.

      Regarding your specific points,

      > I have a Nagios config that I developed years ago that rolls out in minutes

      This is exactly how we’ve calculated the per server setup costs. There’s an initial cost for the first server as you get configs right, but then it’s just a couple of minutes for each subsequent server. As mentioned, if you’ve done it before then it takes less time but even then you still have to spend time getting things up and running – time I’d argue is better spent elsewhere.

      > I also have scripts to monitor things beyond CPU and memory – mysql, postgres, redis, etc.

      These are all things you had to build yourself where you’re reinventing the wheel unnecessarily. Your time is better spent building features for your customers.

      > It also includes SMS notification

      It’s easy to send SMSs using something like the Twilio API. It’s not so easy to factor in things like delivery status, retries on failure, delivery across many different countries (e.g. if you have people in different geographies, or if you are travelling) and automatic failover to secondary providers.

      > In terms of the type of instance or server you need, I’ve run super-efficient installs on the free-tier micro instances for sub-100 server installs without issue.

      The key here is “sub-100”. Nagios is significantly more difficult to manage after that. It also depends how many checks you want to run. If you’re just doing CPU checks then it can be efficient, but proper monitoring goes much further than that – system metrics are just the base and most of our customers report a huge range of custom metrics across all sorts of systems.

      You’re also not considering the requirement for redundancy across data centers which makes things a lot more complicated.

      > Most importantly, with an in-house Nagios (Icinga in my case) install, I’m not sending off critical internal status info on the public internet, and I’m not relying on a third party to provide a mission-critical service.

      This is pure FUD. If your service is mission critical then you wouldn’t be running your critical monitoring on the free AWS micro instances, which are notorious for poor performance and availability. Sending metrics to Server Density is done over HTTPS and given than monitoring and building our SaaS product is our job, we’ll probably be much better at securing it than you are at securing your Nagios instance.

      We have a whole page on what we do with security at https://www.serverdensity.com/security/

      Further, you are “relying on a third party” for all sorts of other systems such as your SMS gateway that it’s not your full time job to manage, like it is for us. And of course, your hosting provider is a “third party” too.

      • Jeremy Wilson

        The point is, I did it once and haven’t had to do it again in the past decade. As for SMS, I actually prefer to use local telco cellular “keys” but my config handles both local out-of-band and third party.

        If I have to go over 100 servers, yes, I use a bigger instance. And icinga is much better at resource management. Even for my 1000+ service install, a single pizza box handles it all with nearly zero CPU required.

        As for the assertion that an in-house, private IP only monitoring service that never sees the public internet is going to be less secure than sending stuff over the internet, that’s way more FUD than anything I said.

        You make an excellent product that suits a large group of people. Anyone who’d rather pay than think about it is well served. Just like AWS is 3x the price of self-hosted equipment, you’re paying for convenience.

        However, if you’ve got an actual system administrator on staff (as you should if you’re serving production traffic), then just saying “Server Density is better!” is not a black and white statement of fact. And it’s certainly not cheaper!

        • > The point is, I did it once and haven’t had to do it again in the past decade

          This isn’t the full picture – not changing it for 10 years isn’t realistic and misses a lot of things that add to that ongoing cost: security updates, instance lifecycle changes, new monitoring requirements, better ways to visualise or alert. If you have done no extra work for 10 years then I’d hate to think what state the system is in! Compare the state of the art of monitoring in 2004 to 2014 and it’s a massive difference. Amazon Web Services didn’t even exist back then!

          > If I have to go over 100 servers, yes, I use a bigger instance. And icinga is much better at resource management. Even for my 1000+ service install, a single pizza box handles it all with nearly zero CPU required.

          You’re missing one of the biggest things we tried to show in the calculator that adds significantly to the cost – redundancy. When you’re monitoring critical systems you can’t use a single instance, you can’t even use a single data center and you need to be monitoring your monitoring too! It’s not a simple case of using “a single box”.

          > As for the assertion that an in-house, private IP only monitoring service that never sees the public internet is going to be less secure than sending stuff over the internet, that’s way more FUD than anything I said.

          Having private IP only is essentially the same as using HTTPS – the traffic is encrypted. Relying on “private, non-public” is security through obscurity and not real security at all. All sorts of things can go wrong such as software security bugs and information leakage that you have to deal with.

          > Just like AWS is 3x the price of self-hosted equipment, you’re paying for convenience.

          Convenience is a factor but we think we’ve demonstrated where there are a lot of hidden costs for running your own monitoring that most people do not think about, which almost always makes the cost more than it’d be to monitor with us.

          > just saying “Server Density is better!” is not a black and white statement of fact

          Exactly, which is why we’ve gone into the detail in this post and broken it down line by line in the calculator.

          • Jeremy Wilson

            Adding an alert to Nagios is as simple as writing a shell script – adding support for redis took me less than 20 minutes. The hard part is that initial config file setup.

            What about things you don’t have checks for?

            As to redundancy and multi-DC, if you’re only monitoring 50 things that is overkill. And in the larger installs, a backup Nagios install running somewhere else is even easier than the initial setup.

            I really take exception to the insane statement that HTTPS is the same as private IP. *Any* packet sent on a public network is less secure than a packet that is never sent. End of story. That is bordering on dangerous to say.

            The values in your calculator are inflated far beyond what the actual costs are to make your service appear as great a value as possible. Which is fine, it’s your site and your blog and your calculator. I just take exception to the blanket statement that SD is cheaper than self-hosted when in my 20 years of experience, it isn’t.

            Is SD “cheaper” for some? Sure, for a developer with minimal administration skills and starting from absolute zero on monitoring, it’s probably cheaper in the short term to just use SD – it’s convenient and fast to roll out. But in your own words it’s a “Premium Server Monitoring Tool” and it has a premium price.

            But if you have a sysadmin, his salary is the cost of monitoring, and that time spent is spent one time, and he’s then available to do far more useful tasks. So SD doesn’t necessarily make sense then.

            You can’t just make a black and white statement, which is primarily what I’m objecting to.

          • > The hard part is that initial config file setup.

            Exactly, that’s where we estimated most of the time was spent.

            > As to redundancy and multi-DC, if you’re only monitoring 50 things that is overkill.

            That’s not true – many huge businesses run only a small number of servers and they would still consider their setup to be critical. Running a single monitoring server is insufficient – your monitoring system has to be more reliable than the infrastructure it’s actually monitoring!

            > And in the larger installs, a backup Nagios install running somewhere else is even easier than the initial setup.

            That’s not the whole story. Sure, if you want an entirely independent, duplicated setup then just copy the VM or snapshot, but then you don’t get any mirroring of configs or historical data – it has to be duplicated using some other system, or you increase your monitoring traffic by having to mirror it.

            > I really take exception to the insane statement that HTTPS is the same as private IP.

            It the context of your comment that sending data over the “public” internet isn’t secure, it is the same thing. Whether you send traffic over HTTPS or via a “private” network, the attack vectors to be able to intercept that are the same – either compromise the routing infrastructure or attack the end location.

            > The values in your calculator are inflated far beyond what the actual costs are to make your service appear as great a value as possible.

            We’ve taken what we believe are realistic defaults based on average salary and the amount of time it would take an intermediate level user to get things set up to replicate what we offer with Server Density. You can adjust the values in the calculator itself to fit your exact scenario and/or feel free to make suggestions here for changes for the actual values.

            > I just take exception to the blanket statement that SD is cheaper than self-hosted when in my 20 years of experience, it isn’t.

            Nowhere have we made a blanket statement, indeed the whole point of this post is to back up the reasons behind the calculator.

            > But if you have a sysadmin, his salary is the cost of monitoring, and that time spent is spent one time

            It’s not true that the time is spent “one time” unless your business and infrastructure never changes. And indeed we believe we add far more value that means those “more useful tasks” can be done right away and the savings are easy to write down.

            > You can’t just make a black and white statement, which is primarily what I’m objecting to.

            Agreed, that’s why we published this post, provided detailed comments for each aspect of the calculator and explained every line item. If there’s a “black and white statement” anywhere then please do point it out.

  • Infrastructure Architect in FL

    Several months ago I tried to setup Nagios to monitor both our production and infrastructure. I have to agree with the author on almost every point. I did get Nagios working over several days (not two days), but I found the real pain was associated with instrumenting all of my servers. So I did what any sane system administrator would do … put it on the back burner and went back to work.

    Looking for viable monitoring alternatives (and reasonably priced) … I found ServerDensity. An easy to implement cloud based monitoring system which gives me customizable alerts and trending graphs without effort. I am only on day two of my free trial, but I am already convinced this is the way to go.

    In short, I plan on monitoring about 40+ production servers and about 50+ internal development and administration servers.

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time