DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
If Nagios server would use a CasC source of configuration in a larger organization is there a design flaw in this approach which will limit scaling up?
To avoid broken configuration, test instances of Nagios could be validated in a CI environment.
Usage scenario: imagine a central Nagios service with more users than you want to be able to break it, who would like to add their services for monitoring.
Personally I don't think using CasC itself will have any negative scalability impact.
Fundamentally CasC means the actual config files are not hand-maintaned, instead they're auto-generated following version-controlled rules - which can be a lot more reliable.
But once the config files are generated - the service using them functions just as it dit with manually-crafted config files.
If anything - using CasC should make such large nagios system more reliable - if done correctly CasC should reduce/eliminate the risk of human error in modifying the config files.
From my experience in managing a Nagios deployment with version controlled configuration files and CI/CD, it works really well. You can collaborate with other teams more easily since you can grant access to a git repository, and you gain all the benefits of CI/CD e.g. rollback and automatic testing. One thing that may be a bottleneck is how frequently you're reloading Nagios, but this would only be an issue when you have many deployments per hour.
Nagios itself also has a lot of limitations and is missing a few key features for a modern environment (scaling, configuration inheritance, APIs), but strictly speaking this doesn't detract from using CasC with Nagios.
Having a CasC setup means that you are in a better position to deal with any scalability issues that should arise later. It should take you a while to max out a nagios box. As long as you haven't starved it of memory or something you should be able to get thousands of nodes on a single nagios box. How many depends on how many checks you're doing and how expensive those checks are. But if you get to the point that a single nagios box is not enough being in a CasC situation gives you the power to shard things in a convenient way and go on with life. There would be much less manual intervention than if you had to split your configs by hand.
You might not reach the maximum for a single instance, but want the reliability of having local nagios boxes in each data center. Having CasC lets you do this more easily and transparently as well.
