The NSCA daemon module is used to receive NSCA packets and submit them to the Shinken command pipe. The NSCA module can be loaded by the Receiver (best solution) or Arbiter process. It will listen on port TCP/5667 for NSCA packets.
Tip
Passive checks can be submitted natively to the Shinken command pipe <thebasics/passivechecks> or from remote hosts to modules, such as NSCA, AMQP or collectd, loaded in the Shinken Arbiter or Receiver process. AMQP is implemented for integration with the Canopsis Hypervisor, but could be re-used for generic messaging.
Note
The Shinken NSCA module implementation is currently limited to the "xor" obfuscation/encryption.
To append the NSCA module to the Shinken receiver daemon, simply add (or uncomment) in the receiver configuration:
define receiver {
receiver_name receiver-master
address localhost
port 7773
spare 0
...
## Modules for Receiver
# - named-pipe = Open the named pipe nagios.cmd
# - nsca = NSCA server
# - TSCA = TSCA server
# - ws-arbiter = WebService for pushing results to the arbiter
# - Collectd = Receive collectd perfdata
modules nsca
}This daemon is totally optional. Its main goal is to get all passive "things" (checks but why not other commands) in distant realms. It will act as a "passive receive buffer" and will then dispatch the data or commands directly to the appropriate Scheduler or Arbiter process.
Data can be received from any Realm, thus the Realm option is nonsensical.
It is launched like all other daemons:
/etc/init.d/shinken-receiver startTip
Alternatively, for small installations you can configure an NSCA module inside your Arbiter instead of the Receiver. It will listen the TCP/5667 port for NSCA packets.
To configure the NSCA module in your Arbiter instead of Receiver, add the NSCA module to the arbiter configuration.
define arbiter {
...
modules ..., nsca
}The NSCA module configuration is defined in the module configuration file: nsca.cfg.
Default configuration is convenient for 'recent' NSCA client implementing NSCA version 3.
This configuration has been tested with Linux send_nsca 2.9.1 and Windows NSClient versions 0.4.1 and 0.4.2.
The XOR encryption has been tested with Windows NSCLient.
Note
Received NSCA packets which are not containing version 3 information are dropped by the module!
## Module: nsca
## Loaded by: Arbiter, Receiver
# Receive check results sent with NSCA protocol.
define module {
module_name nsca
module_type nsca_server
# Default is listening on all address, TCP port 5667
host *
port 5667
# Encryption method:
# 0 for no encryption (default)
# 1 for simple Xor
# No other encryption method available!
encryption_method 0
password helloworld
# Maximum packet age defines the maximum delay
# (in seconds) for a packet to be considered as staled
max_packet_age 60
# If check_future_packet attribute is defined, packets
# more recent than current timestamp are dropped
check_future_packet 1
# Payload length is length of effective data sent :
# . -1 to accept any payload length
# . 512 or 4096 depending upon NSCA client configuration
# If packet payload is not the right size, packet is dropped
payload_length -1
# Buffer length is maximum length of received data :
# should be greater than payload length
# Default is 8192
#buffer_length 8192
# backlog is the maximum number of concurrent sockets
# Default is 10
#backlog 10
}