Answers: <p>Personally I don't think using CasC itself will have any negative scalability impact.</p>
  
  <p>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.</p>
  
  <p>But once the config files are generated - the service using them functions just as it dit with manually-crafted config files.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-26T14:50:40.877Z
Answers: 2017-06-26T14:50:40.877Z
Answers: Dan Cornilescu
Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-04T22:29:00.440Z
Answers: 2017-10-04T22:29:00.440Z
Answers: user2640621
Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-05T00:49:48.613Z
Answers: 2017-10-05T00:49:48.613Z
Answers: chicks
Body: <p>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?</p>
  
  <p>To avoid broken configuration, test instances of Nagios could be validated in a CI environment.</p>
  
  <p>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.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-06-26T14:43:49.153Z
Comments: Maybe explain a bit where/how you think of using CasC in nagios?
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2017-06-26T14:51:57.213Z
Comments: That sounds to me more of a scalability issue of nagios itself, not of using CasC. Unless I'm missing something.
Comments: Dan Cornilescu
Tags: <nagios><scalability><casc>
Title: Scaling issues with Nagios as CaSC
UserDisplayName: Ta Mu
ThreadText: # Scaling issues with Nagios as CaSC
  
  (Asked by: username_0 on 2017-06-25)
  
  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.
  
  **Tags:** nagios, scalability, casc
  
  > **Comments:**
  > **username_1**: Maybe explain a bit where/how you think of using CasC in nagios?  
  > **username_1**: That sounds to me more of a scalability issue of nagios itself, not of using CasC. Unless I'm missing something.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2017-06-26. Score: 2 | Accepted answer
  
  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.
  
  
  ---
  
  ### Answer by username_2 on 2017-10-04. Score: 1
  
  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.
  
  
  ---
  
  ### Answer by username_3 on 2017-10-05. Score: 1
  
  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.
  
  
  ---
  
  