If you followed the shinken_10min_start tutorial you were able to install and launch shinken. But now you might want to know more.

The default configuration deployed with Shinken sources contains :

• one arbiter
• one scheduler
• one poller
• one reactionner
• one broker

All Theses elements must be configured. In fact, the Arbiter must know about the other daemons and how to communicate with them, just as the others daemons need to know on which TCP port they must to listen to.

The schedulers, pollers, reactionners and brokers daemons need to know in which directory to work on, and on which TCP port to listen. That's all.

Each daemon has one configuration file. The default location is /usr/local/shinken/etc.

Let's see what it looks like :

$cat etc/schedulerd.ini

[daemon]
workdir=/usr/local/shinken/var
pidfile=%(workdir)s/schedulerd.pid
port=7768
host=0.0.0.0
user=shinken
group=shinken
idontcareaboutsecurity=0

• workdir : working directory of the daemon. By default /usr/local/shinken/var
• pidfile : pid file of the daemon (so we can kill it :) ). By default /usr/local/shinken/var/schedulerd.pid for a scheduler.
• port : TCP port to listen to. By default
• - scheduler : 7768
• - poller : 7771
• - reactionner : 7769
• - broker : 7772
• - arbiter : 7770 (the arbiter configuration will be seen later)
• host : IP to listen to. The default 0.0.0.0 means all interfaces
• user : user used by the daemon to run. By default shinken
• group : group of the user. By default shinken.
• idontcareaboutsecurity : if set to 1, you can run it under the root account. But seriously : do not to this. The default is 0 of course.

Now each daemons knows in which directory to run, and on which tcp port to listen. This daemon is a resource in the Shinken architecture. Such resources must be declared in the global configuration (where the Arbiter is) for them to be utilized.

The global configuration file is : /usr/local/shinken/etc/shinken-specific.cfg

Theses declarations are quite easy in fact : each daemon is represented by an object. And the information contained in it are network parameters about how the resources should be treated (is it a spare, …).

Each objects type corresponds to a daemon :

• arbiter
• scheduler
• poller
• reactionner
• broker

The names were chosen to understand their roles more easily :)

They have in common theses parameters :

• *_name : name of the resource
• address : IP or DNS address to connect to the daemon
• port : I think you can find it by your own by now :)
• [spare] : 1 or 0, is a spare or not. See advanced features for this.
• [realm] : realm membership See advanced features for this.
• [manage_sub_realms] : manage or not sub realms. See advanced features for this.
• [modules] : modules used by the daemon. See below.

Some daemons have special parameters :

For the arbiter :

• host_name : hostname of the server where the arbiter is installed. It's mandatory for a high availability environment (2 arbiters or more).

For pollers :

• poller_tags : “tags” that the poller manages. See advanced features for this.

Some daemons like the broker, arbiter, scheduler and receiver can use modules. They are in fact mandatory in the brokers case.

Modules have some common properties :

• module_name : module name called by the resource.
• module_type : module type of the module. It's a fixed value given by the module.
• other options : each modules can have specific parameters. See the module documentation to learn more about this.

Module refernces :

• Arbiter modules
• Scheduler modules
• Broker modules
• Receiver modules

Here is an example of a simple configuration (which you already used without knowing it if you completed the 10min installation tutorial). It has been kept to the strict minimum, with only one daemon for each type. There is no load distribution or high availability, but you'll get the picture more easily.

Here, we have a server named server-1 that has 192.168.0.1 as its IP address :

define arbiter{
       arbiter_name  arbiter-1
       host_name     server-1
       address       192.168.0.1
       port          7770
       spare         0
       }

define scheduler{
       scheduler_name	scheduler-1
       address	        192.168.0.1
       port	        7768
       spare	        0
       }

define reactionner{
       reactionner_name	    reactionner-1
       address	            192.168.0.1
       port	            7769
       spare	            0
       }

define poller{
       poller_name     poller-1
       address         192.168.0.1
       port            7771
       spare           0
}

define broker{
       broker_name	broker-1
       address	        192.168.0.1
       port	        7772
       spare	        0
       modules          Status-Dat,Simple-log
       }

define module{
       module_name      Simple-log
       module_type      simple_log
       path             /usr/local/shinken/var/shinken.log
}

define module{
       module_name              Status-Dat
       module_type              status_dat
       status_file              /usr/local/shinken/var/status.data
       object_cache_file        /usr/local/shinken/var/objects.cache
       status_update_interval   15 ; update status.dat every 15s
}

See? That was easy. And don't worry about forgetting one of them : if there is a missing daemon type, Shinken automatically adds one locally with a default address/port configuration.

To launch daemons, it's still easy (a child's play) :

daemon_path -d -c daemon_configuration.ini 

The command lines arguments are :

• -c, –config : Config file.
• -d, –daemon : Run in daemon mode
• -r, –replace : Replace previous running scheduler
• -h, –help : Print detailed help screen
• –debug : path of the debug file

So a standard launch of the resources look like :

/usr/local/shinken/bin/shinken-scheduler -d -c /usr/local/shinken/etc/schedulerd.ini
/usr/local/shinken/bin/shinken-poller -d -c /usr/local/shinken/etc/pollerd.ini
/usr/local/shinken/bin/shinken-reactionner -d -c /usr/local/shinken/etc/reactionnerd.ini
/usr/local/shinken/bin/shinken-broker -d -c /usr/local/shinken/etc/brokerd.ini

#first we should check the configuration for errors
python bin/shinken-arbiter -v -c etc/nagios.cfg -c etc/shinken-specific.cfg

#then, we can really launch it
python bin/shinken-arbiter -d -c etc/nagios.cfg -c etc/shinken-specific.cfg

Now, you've got the same thing you had when you launched bin/launch_all.sh script (but now you know what you're doing)

If you feel in the mood for testing even more shinken features, now would be the time to look at advanced_features to play with distributed and high availability architectures!