The Nagios Plugin API has become a well loved standard for providing scripts that act as plugins to monitoring systems, and along with the standard plugins supplied by http://monitoring-plugins.org/ (formerly “Nagios Plugins” prior to legal threats from Nagios Inc) many more are available on various exchanges and on github.
Unfortunately, a noticeable portion of the runtime of some scripts is due to library load overhead because of the single shot runtime model, and many more such scripts eschew library use in favour of copypasta to avoid overhead and dependency management issues.
Both the deployment and scalability issues are solvable, however, at least for perl and CPAN.
Firstly, this talk will cover how to keep deployment simple while still being able to use CPAN modules, including:
* How to track your module use to ensure you always know not only what your dependencies are, but can reproduce the exact versions you’ve developed and tested against
* How to turn a plugin with pure perl dependencies – including the monitoring-plugins.org standard library Monitoring::Plugin – into a single
file that can be deployed without additional installation effort
* How to handle compiled dependencies both via easy in-tree installation to avoid touching system directories and via building system packages for global installation
Secondly, we’ll discuss the limitations of the execution model, and the issues and trade-offs involved in various approaches to a more persistent execution model. Having covered the previous solutions, and why they often don’t end up getting used, we’ll present an alternative that:
* Requires zero changes to plugin code
* Intelligently preloads modules to provide fast warming
* Shares dependency loading to minimise memory usage
* Can detect and work around broken modules automatically
* Is robust to even the most legacy or newbie perl scripting
Come along and find out how to both save yourself time by accelerating your development process, and save your systems’ CPU by accelerating your deployments. Perl experience is not expected, because it *is* expected that these techniques should apply to third party/community sourced code as well.
Session Category : Sessions