OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest

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

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

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

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

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)

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???

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

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…)

Statistics: ReleasesStatistics: Releases
12
04
05
03
03
02
01
01
03
01
06
07
01
06
02v1.4
v1.4.2
v1.4.4
v1.4.6
v1.4.8
v1.4.10
v1.4.12
v1.4.14
Months

Statistics: DownloadsStatistics: Downloads

Statistics: WebStatistics: Web

Statistics: nagiosplugins.orgStatistics: nagiosplugins.org

Statistics: BugsStatistics: Bugs

Part II – Extra-OptsPart II – Extra-Opts
History
Roadmap
How it works
Examples
History
Roadmap
How it works
Examples

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

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

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

How Extra-Opts Works
(cont.)
(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]

(cont.)
(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

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
}
[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
}

Advanced Examples:
Per-hostsgroup settings
Advanced Examples:
Per-hostsgroup settings
[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
}
[check_stuff_linux-servers]
warning = 50
critical = 100
define command {
command_name check_stuff_hostgroup
command_line $USER1$/check_stuff
--extra-opts=check_stuff_$HOSTGROUPNAME$
}
define service {
use local-service
service_description Hostgroup Stuff
check_command check_stuff_hostgroup
}

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
define command {
command_name check_stuff_config
command_line NAGIOS_CONFIG_PATH="$USER1$/ini/$HOSTGROUPNAME$"
$USER1$/check_stuff --extra-opts --extra-opts=$ARG1$
}
define service {
use local-service
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
define command {
command_name check_stuff_config
command_line NAGIOS_CONFIG_PATH="$USER1$/ini/$HOSTGROUPNAME$"
$USER1$/check_stuff --extra-opts --extra-opts=$ARG1$
}
define service {
use local-service
service_description Hostgroup Config
check_command check_stuff_config!advanced_stuff
}

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
Nagios v3 Output

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

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?

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

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

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)

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

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
• 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

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

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…)

(cont.)
(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

(cont.)
(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:
→ 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

(cont.)
(cont.)
• Plugin-based with unique service ID
• Pros:
→ Simple concept
• 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
• Cons:
→ May requires Nagios modifications to create unique
identifiers
→ May require remote executor to pass arguments
→ Different data storage requires modifications to the
plugin

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!

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

OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest

More Related Content

What's hot (20)

Similar to OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest (20)

Recently uploaded (20)

OSMC 2009 | Nagios Plugins: New features and future projects by Thomas Guyot-Sionnest