NagiosXI Licensing vs Monitoring Architecture

[ditt7]

BASICS:
In our network environment we host installations of our software for about 100 customers. The software installation requires a SQL Server back-end and several HTTP/S front end services. SQL Server runs on it’s own hardware and is not an issue w/r/t this problem. The HTTP/S services for a handful of customers are hosted on a single, external-facing server. For example:
https://<Server1 FQDN>/Customer1-Service1
https://<Server1 FQDN>/Customer1-Service2
https://<Server1 FQDN>/Customer1-Service3

https://<Server1 FQDN>/Customer2-Service1
https://<Server1 FQDN>/Customer2-Service2
https://<Server1 FQDN>/Customer2-Service3

MONITORING:
We want to monitor each one of the HTTP/S services for each customer we host to ensure their uptime. We came up with 2 possible solutions:
1. Add the Host Server to Nagios. For each customer, add 3 service-monitors for the specific HTTP/S services to be monitored. When you’re looking at setting this up for 100+ customers, it doesn’t seem optimal and is also error prone since each time a new customer is added, we need to correctly set up 3 Service Monitors. Some of this can be alleviated by setting up appropriate Service Templates and Custom Commands, but it still seems a lot to do and more ways to fail.

2. A much better way, would be to set up a Host Group and assign it to 3 Custom Service Monitors which use parameterized Commands. The Commands reference MACRO variables to monitor an HTTP/S service for a specific customer (i.e. the value of the MACRO ’_CUSTSERVICE1’ gives the unique location of service one for a customer) . For each customer on ’Server1’, we then add a new Host Definition with a unique customer-focused name (e.g. Server1: CUST1) and the same IP address for ‘Server1’. When adding the host for the customer we define the values of the 3 MACROs which identify the 3 HTTP/S services to be monitored and add the host to the Host Group we created that is assigned to the 3 Service Monitors. The great this about this approach is that when a new customer comes on board, we simply add a new host making sure to define the 3 MACROs and assign it to our Host Group and we’re done. One task vs three. The other HUGE benefit is having a single Service Monitor for each of the 3 HTTP/S services which cover ALL customers. This allows us to tweak the monitoring specifics for ALL customers in a single place. Solution (1.) above would require visiting each service for each customer (a LOT of work although I would write and Emacs macro to make fairly short work of it, I cannot expect that from our other employees).

Originally, I implemented (1.) above. I sat with it , and as we tweaked things and ran into the pain it was to tweak so many different services, (2.) became clear. So we moved everything to reflect solution (2.) It works great, except for one problem; we are a fairly small company (about 60 unique hardware/ip’s to monitor with various services. As such, we purchased the “100 Node” license. Apparently, a ‘Node’ is really defined as a ‘Host.’ This means that implementing the more desirable solution to our monitoring problem, (2.), we quickly surpass the number of “Nodes” we are licensed for. This puts us in a difficult situation where the correct solution is being inhibited by the NagiosXI licensing strategy. No judgment on the NagiosXI licensing strategy, but in this case it’s not really working for us.

Has anyone had to solve a similar problem w/r/t the “Node” licenses? If so, how did you work around it while keeping a sane monitoring strategy? Suggestions welcome.

Thanks in advance.

[tmcdonald]

Unfortunately I think the answer is going to depend more on what our Sales team has to say than what the technical capabilities/limitations are. The letter of the law is that the 100-node license can hold 100 hosts, but the spirit of the law would see these 60 or so customers (services) as 60 nodes, and speaking from a licensing standpoint we don't allow MSP/SaaS setups. I would reach out to [email protected] and see what they have to say - If you get the OK for this sort of monitoring, we can tackle it from a technical standpoint.

Please feel free to correct me if I have misunderstood your setup.

[ditt7]

Unfortunately I think the answer is going to depend more on what our Sales team has to say than what the technical capabilities/limitations are. The letter of the law is that the 100-node license can hold 100 hosts, but the spirit of the law would see these 60 or so customers (services) as 60 nodes, and speaking from a licensing standpoint we don't allow MSP/SaaS setups. I would reach out to [email protected] and see what they have to say - If you get the OK for this sort of monitoring, we can tackle it from a technical standpoint.

Please feel free to correct me if I have misunderstood your setup.

Thanks for the reply. I think you're probably correct in that my next move should be to call sales. The basic issue is the question of what constitutes a 'Node'. In my situation, each customer host is actually pointing to the same machine with the same IP, so one could argue that this is really one host with many services. I understand that having a Node defined as a unique IP doesn't necessarily work if there are multiple subnets with the same IP space. However that is not our situation. I'll contact Sales and update this thread when I get a definitive answer.
Thanks.

[lmiltchev]

I'll contact Sales and update this thread when I get a definitive answer.
Thanks.

Sounds good, ditt7. We will keep the thread open.

[ditt7]

I'll contact Sales and update this thread when I get a definitive answer.
Thanks.

Sounds good, ditt7. We will keep the thread open.

Thanks. I reached out to Sales and it looks like there's no relief there. I get it; you have to license somehow. It would be nice if the code that checks for the number of nodes against the license would not count a Host that has a check_dummy service assigned to it as a node. This is what I do to represent the architecture that makes sense for our environment, but all of these 'dummy' hosts are being counted against the license. We ended up purchasing another 100 Nodes (license upgrade) to solve our immediate problem.

[tmcdonald]

I understand the technical reasons behind it, but if our licensing worked that way then everyone would run with a "single" host :)

[ditt7]

I understand the technical reasons behind it, but if our licensing worked that way then everyone would run with a "single" host

Yes, if your entire environment could be addressed with a single IP address that would be true, but that's not what I'm suggesting. I'm saying that if you have an IP as as host with a non-dummy service assigned for the host check, it should be counted. If that same IP is duplicated with a different name and only a dummy assigned as the host check, it shouldn't be counted. Better yet, why not introduce a policy for hosts that are children of other hosts with the same IP as the parent where they do not count. I can think of other ways to solve the problem technically, but if this is where Nagios makes it's money I can understand the lack of motivation to solve such a problem.

[tmcdonald]

You will need to discuss this with Sales.

I will be closing this thread now - If you have any further technical questions, please feel free to open a new thread.