OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest
•
0 likes•30 views
Nagios-Plugins is the official plugin distribution for Nagios. It includes over 50 plugins written in C and Perl for most basic monitoring tasks. It is currently maintained mostly by volunteers; the current active developers are: Ton Voon (project lead), Holger Weiss, Matthias Elbe and Thomas Guyot-Sionnest. In this talk Thomas will look into some noteworthy features added recently in the Nagios-Plugins distribution and show how they can be useful in real-life situations. He will especially emphasize on the extra-opts addition which allows moving plugin parameters to one or more .ini files. In a second part Thomas will introduce the current and upcoming projects for Nagios-Plugins.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest
Similar to OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest (20)
Recently uploaded
Recently uploaded (20)
OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest
- 1. Nagios Plugins: New features and future projects Nagios Plugins: New features and future projects Thomas Guyot-Sionnest October 2009 Thomas Guyot-Sionnest October 2009 Copyright Thomas GuyotCopyright Thomas Guyot--Sionnest. Released under Creative Commons, AttributionSionnest. Released under Creative Commons, Attribution--NoncommercialNoncommercial
- 2. New features and future projects New features and future projects I. State of the Plugins II. Extra-Opts III. Future Projects I. State of the Plugins II. Extra-Opts III. Future Projects
- 3. Part I – State of the PluginsPart I – State of the Plugins The Nagios Plugins Development Team What we have been doing New features Project statistics The Nagios Plugins Development Team What we have been doing New features Project statistics
- 4. The Nagios Plugins TeamThe Nagios Plugins Team • Project Lead: • Ton Voon • Active Developers: • Holger Weiß • Matthias Eble • Thomas Guyot-Sionnest • Project Lead: • Ton Voon • Active Developers: • Holger Weiß • Matthias Eble • Thomas Guyot-Sionnest
- 5. The Nagios Plugins Team (cont.) The Nagios Plugins Team (cont.) • Infrastructure: • SourceForge Tracker, Mailing lists, Web, FRS… • Tinderbox builds on team and community computers • Team server (courtesy of Opsera) • Infrastructure: • SourceForge Tracker, Mailing lists, Web, FRS… • Tinderbox builds on team and community computers • Team server (courtesy of Opsera)
- 6. What Are We Doing?What Are We Doing? • Trying to do much with little resources → We all have real jobs! • Many bugfixes and patches from the trackers and mailing lists → We don’t want to let them accumulate • Coding new features if there’s any time left • Website, tinderboxes, repositories maintenance • Translations… Anyone??? • Trying to do much with little resources → We all have real jobs! • Many bugfixes and patches from the trackers and mailing lists → We don’t want to let them accumulate • Coding new features if there’s any time left • Website, tinderboxes, repositories maintenance • Translations… Anyone???
- 7. New FeaturesNew Features • The big one: • Extra-opts (more on this shortly) • check_http: • SNI support (SSL Server Name Indication) • Sticky redirections • Better support for doing many checks together • check_disk: • Better support for automount environment • Support for +2TB filesystems • The big one: • Extra-opts (more on this shortly) • check_http: • SNI support (SSL Server Name Indication) • Sticky redirections • Better support for doing many checks together • check_disk: • Better support for automount environment • Support for +2TB filesystems
- 8. New Features (cont.)New Features (cont.) • Miscellaneous: • check_icmp returns perfdata • negate can “negate” the status text as well • check_snmp supports standard thresholds, including double values from strings • Some plugins updated to use utils_cmd instead of popen • Developers: • Moved to Git • Self-serve test suites (http, snmp…) • Miscellaneous: • check_icmp returns perfdata • negate can “negate” the status text as well • check_snmp supports standard thresholds, including double values from strings • Some plugins updated to use utils_cmd instead of popen • Developers: • Moved to Git • Self-serve test suites (http, snmp…)
- 16. Part II – Extra-OptsPart II – Extra-Opts History Roadmap How it works Examples History Roadmap How it works Examples
- 17. Extra-Opts HistoryExtra-Opts History • First design as a feature to hide passwords • Initial C ini-parsing routines by Sean Finney → Feb. 2007 • Initial Perl (N::P) implementation by Gavin Carr → March 2007 • Extra-opts implemented for C Plugins by Thomas Guyot-Sionnest → March 2008 • First design as a feature to hide passwords • Initial C ini-parsing routines by Sean Finney → Feb. 2007 • Initial Perl (N::P) implementation by Gavin Carr → March 2007 • Extra-opts implemented for C Plugins by Thomas Guyot-Sionnest → March 2008
- 18. Extra-Opts RoadmapExtra-Opts Roadmap • Implement for Perl plugins → Imply migrating them to Nagios::Plugin • Shell scripts plugin support (maybe) • Building extra-opts by default • Implement for Perl plugins → Imply migrating them to Nagios::Plugin • Shell scripts plugin support (maybe) • Building extra-opts by default
- 19. How Extra-Opts Works?How Extra-Opts Works? • Activated as soon as --extra-opts is present • ini-file syntax: [section] ; This is a comment option = [value] • Options can be repeated (!) • Options are mapped to plugin’s arguments → Both short and long options are supported → Options without argument: bare equal sign • Activated as soon as --extra-opts is present • ini-file syntax: [section] ; This is a comment option = [value] • Options can be repeated (!) • Options are mapped to plugin’s arguments → Both short and long options are supported → Options without argument: bare equal sign
- 20. How Extra-Opts Works (cont.) How Extra-Opts Works (cont.) • Extra-option are always parsed first, in order of appearance • Unless specified otherwise, repeated options override previous options (plugin-specific) • Therefore, extra-opts can be used as default values in many cases, overridden by command-line options • Error triggered on missing file/section • Optional parameter: --extra-opts=[section][@file] • Default section is the plugin’s name → i.e. check_tcp will look for section [check_tcp] • Extra-option are always parsed first, in order of appearance • Unless specified otherwise, repeated options override previous options (plugin-specific) • Therefore, extra-opts can be used as default values in many cases, overridden by command-line options • Error triggered on missing file/section • Optional parameter: --extra-opts=[section][@file] • Default section is the plugin’s name → i.e. check_tcp will look for section [check_tcp]
- 21. How Extra-Opts Works (cont.) How Extra-Opts Works (cont.) • Look for default files in standard locations if no file argument is given (locations are subject to change) 1. plugins.ini a. /etc/nagios b. /usr/local/nagios/etc c. /usr/local/etc/nagios d. /etc/opt/nagios 2. nagios-plugins.ini a. /etc b. /usr/local/etc c. /etc/opt • Location can be overridden with NAGIOS_CONFIG_PATH → Will look for plugin.ini, then nagios-plugin.ini, and finally the default locations above • Look for default files in standard locations if no file argument is given (locations are subject to change) 1. plugins.ini a. /etc/nagios b. /usr/local/nagios/etc c. /usr/local/etc/nagios d. /etc/opt/nagios 2. nagios-plugins.ini a. /etc b. /usr/local/etc c. /etc/opt • Location can be overridden with NAGIOS_CONFIG_PATH → Will look for plugin.ini, then nagios-plugin.ini, and finally the default locations above
- 22. Simple UsageSimple Usage • Default ini file [check_stuff] warning = 10 critical = 20 [some_stuff] warning = 1 critical = 2 • Command Definition define command { command_name check_stuff_extra command_line $USER1$/check_stuff --extra-opts --extra-opts=$ARG1$ } • Service Definition define service { use local-service host_name localhost service_description Some Stuff check_command check_stuff_extra!some_stuff } • Default ini file [check_stuff] warning = 10 critical = 20 [some_stuff] warning = 1 critical = 2 • Command Definition define command { command_name check_stuff_extra command_line $USER1$/check_stuff --extra-opts --extra-opts=$ARG1$ } • Service Definition define service { use local-service host_name localhost service_description Some Stuff check_command check_stuff_extra!some_stuff }
- 23. Advanced Examples: Per-hostsgroup settings Advanced Examples: Per-hostsgroup settings • Default ini file [check_stuff_linux-servers] warning = 50 critical = 100 • Command definition define command { command_name check_stuff_hostgroup command_line $USER1$/check_stuff --extra-opts=check_stuff_$HOSTGROUPNAME$ } • Service definition define service { use local-service hostgroup_name linux-servers service_description Hostgroup Stuff check_command check_stuff_hostgroup } • Default ini file [check_stuff_linux-servers] warning = 50 critical = 100 • Command definition define command { command_name check_stuff_hostgroup command_line $USER1$/check_stuff --extra-opts=check_stuff_$HOSTGROUPNAME$ } • Service definition define service { use local-service hostgroup_name linux-servers service_description Hostgroup Stuff check_command check_stuff_hostgroup }
- 24. Advanced Examples: hostgroup config path Advanced Examples: hostgroup config path • /usr/local/nagios/libexec/ini/linux-servers/plugins.ini [advanced_stuff] warning = 100 critical = 200 • Command definition define command { command_name check_stuff_config command_line NAGIOS_CONFIG_PATH="$USER1$/ini/$HOSTGROUPNAME$" $USER1$/check_stuff --extra-opts --extra-opts=$ARG1$ } • Service definition define service { use local-service hostgroup_name linux-servers service_description Hostgroup Config check_command check_stuff_config!advanced_stuff } • /usr/local/nagios/libexec/ini/linux-servers/plugins.ini [advanced_stuff] warning = 100 critical = 200 • Command definition define command { command_name check_stuff_config command_line NAGIOS_CONFIG_PATH="$USER1$/ini/$HOSTGROUPNAME$" $USER1$/check_stuff --extra-opts --extra-opts=$ARG1$ } • Service definition define service { use local-service hostgroup_name linux-servers service_description Hostgroup Config check_command check_stuff_config!advanced_stuff }
- 25. Part III – Future ProjectsPart III – Future Projects Nagios Plugin Library New Thresholds Format Plugin State Retention Nagios v3 Output Nagios Plugin Library New Thresholds Format Plugin State Retention Nagios v3 Output
- 26. Nagios Plugins LibraryNagios Plugins Library • Why a library? • Make it easy to contribute new and forked C plugins • Standardization of current plugins • Create an official API • Why a library? • Make it easy to contribute new and forked C plugins • Standardization of current plugins • Create an official API
- 27. Plugins Library: DesignPlugins Library: Design • Design goals: • C is not object-oriented, we can’t just do “like” Nagios::Plugins • Will try to stay as close as possible to N::P API (same function names..) • Ease the parsing of arguments, use of thresholds and output of status, i.e. simpler code • Include “cmd” and “tcp” helpers? • Design goals: • C is not object-oriented, we can’t just do “like” Nagios::Plugins • Will try to stay as close as possible to N::P API (same function names..) • Ease the parsing of arguments, use of thresholds and output of status, i.e. simpler code • Include “cmd” and “tcp” helpers?
- 28. Plugins Library: StatusPlugins Library: Status • Mostly sparse attempts at drawing up an API • RFC at: http://nagiosplugins.org/rfc/nagiosplugins-c-library (under construction) • Join the discussion at the team meetings tomorrow, in the #nagios-devel IRC channel or in the mailing list • Mostly sparse attempts at drawing up an API • RFC at: http://nagiosplugins.org/rfc/nagiosplugins-c-library (under construction) • Join the discussion at the team meetings tomorrow, in the #nagios-devel IRC channel or in the mailing list
- 29. New Thresholds FormatNew Thresholds Format • Rationale: • Make thresholds more intuitive → Anyone can explain this: -j @10:100 -k ~:200 • Ease definition of multiple thresholds → No more -w -c -W -C -j -k -x -y -z… • Give more flexibility to plugins → Dynamic metrics, custom options, multiple ranges… • Based on getsubopt() → Like mount options – widespread • Rationale: • Make thresholds more intuitive → Anyone can explain this: -j @10:100 -k ~:200 • Ease definition of multiple thresholds → No more -w -c -W -C -j -k -x -y -z… • Give more flexibility to plugins → Dynamic metrics, custom options, multiple ranges… • Based on getsubopt() → Like mount options – widespread
- 30. New Thresholds: ProposalNew Thresholds: Proposal • Command-line option: --threshold={threshold_definition}, --th={...} • Definition is like a mount option: metric=cpu,warn={range},crit={range} metric=usedspace,ok={range},prefix=Mi • Simple ranges 0..10 15..inf inf..-10 • Complex ranges (10..20) ^0..10 ^(0..10) • Command-line option: --threshold={threshold_definition}, --th={...} • Definition is like a mount option: metric=cpu,warn={range},crit={range} metric=usedspace,ok={range},prefix=Mi • Simple ranges 0..10 15..inf inf..-10 • Complex ranges (10..20) ^0..10 ^(0..10)
- 31. New Thresholds: Advantages New Thresholds: Advantages • Don’t clutter the argument namespace • Explicit range makes them more obvious • Dynamic metrics → metric=sql_{col},... where “col” is a SQL column name in a SQL-based check • Extensible • Support Hysteresis? → warn_upper={range},warn_lower={range} • Add new or custom parameters • Don’t clutter the argument namespace • Explicit range makes them more obvious • Dynamic metrics → metric=sql_{col},... where “col” is a SQL column name in a SQL-based check • Extensible • Support Hysteresis? → warn_upper={range},warn_lower={range} • Add new or custom parameters
- 32. New Thresholds: ExamplesNew Thresholds: Examples • check_http -H $HOSTADDRESS$ --th metric=time,ok=0..5 --th metric=size,ok=10..inf,prefix=Ki • check_procs -C httpd --th metric=vsize,ok=0..8096,warn=8097..16182 • check_procs -C tnslsnr --th metric=count,ok=1..1 • check_load --th metric=1min,ok=0..1.0,warn=1.0..1.5 --th metric=5min,ok=0..0.8,warn=0.8..1.3 --th metric=15min,ok=0..0.7,warn=0.7..1.0 • check_http -H $HOSTADDRESS$ --th metric=time,ok=0..5 --th metric=size,ok=10..inf,prefix=Ki • check_procs -C httpd --th metric=vsize,ok=0..8096,warn=8097..16182 • check_procs -C tnslsnr --th metric=count,ok=1..1 • check_load --th metric=1min,ok=0..1.0,warn=1.0..1.5 --th metric=5min,ok=0..0.8,warn=0.8..1.3 --th metric=15min,ok=0..0.7,warn=0.7..1.0
- 33. New Thresholds: StatusNew Thresholds: Status • RFC stage. See: http://nagiosplugins.org/rfc/new_threshold_syntax • Need to start coding the C and Perl functions. • Probably written as part of the C library • RFC stage. See: http://nagiosplugins.org/rfc/new_threshold_syntax • Need to start coding the C and Perl functions. • Probably written as part of the C library
- 34. Plugin State RetentionPlugin State Retention • Rationale: • Plugins sometimes need to store data between runs • The plugins API could provide a standardized way of storing data • Very early stage of design (we’re still debating on the possible methods…) • Rationale: • Plugins sometimes need to store data between runs • The plugins API could provide a standardized way of storing data • Very early stage of design (we’re still debating on the possible methods…)
- 35. Plugin State Retention (cont.) Plugin State Retention (cont.) • Performance data • Pros: → Bound to service → Simple to implement → No Nagios modifications needed • Cons: → Only small numeric values can be passed → Requires remote executor to pass arguments → May pollute performance data with state retention key/value pairs • Performance data • Pros: → Bound to service → Simple to implement → No Nagios modifications needed • Cons: → Only small numeric values can be passed → Requires remote executor to pass arguments → May pollute performance data with state retention key/value pairs
- 36. Plugin State Retention (cont.) Plugin State Retention (cont.) • File-descriptor passing • Pros: → Bound to service in recommended setup → Large/binary storage possible → Allows flexibility in how data is stored regardless of plugin language • Cons: → Requires wrapper or Nagios/remote-executor modifications → Less intuitive - users are not familiar with this → May require remote executor to pass FD data or implement local storage • File-descriptor passing • Pros: → Bound to service in recommended setup → Large/binary storage possible → Allows flexibility in how data is stored regardless of plugin language • Cons: → Requires wrapper or Nagios/remote-executor modifications → Less intuitive - users are not familiar with this → May require remote executor to pass FD data or implement local storage
- 37. Plugin State Retention (cont.) Plugin State Retention (cont.) • Plugin-based with unique service ID • Pros: → Simple concept → Bound to service in recommended setup → Large/binary storage possible • Cons: → May requires Nagios modifications to create unique identifiers → May require remote executor to pass arguments → Different data storage requires modifications to the plugin • Plugin-based with unique service ID • Pros: → Simple concept → Bound to service in recommended setup → Large/binary storage possible • Cons: → May requires Nagios modifications to create unique identifiers → May require remote executor to pass arguments → Different data storage requires modifications to the plugin
- 38. Nagios v3 OutputNagios v3 Output • Since Nagios v3 it is now possible to send much more detailed data to Nagios • No official plugin use this functionality yet • The C library should include v3 output function that can be used by plugins • Still unclear how it should be enabled (command-line, default) and which plugins should take advantages • Give us your thoughts! • Since Nagios v3 it is now possible to send much more detailed data to Nagios • No official plugin use this functionality yet • The C library should include v3 output function that can be used by plugins • Still unclear how it should be enabled (command-line, default) and which plugins should take advantages • Give us your thoughts!
- 40. ThanksThanks To the team To contributors To users - all feedback is good To Netways To the team To contributors To users - all feedback is good To Netways