patternMinor
Scaling issues with Nagios as CaSC
Viewed 0 times
cascnagiosissueswithscaling
Problem
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.
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.
Solution
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.
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.
Context
StackExchange DevOps Q#1421, answer score: 2
Revisions (0)
No revisions yet.