Did you like the discovery script? Now it's time to look at how it works, and get even more from it.

The discovery is done in two distinct phases:

• the discovery scripts run generates raw data
• the discovery rules use data to generate objects like hosts or services

The discovery scripts can be anything you can launch from a shell, just like plugins. Their main goal is to generate raw data for objects. Yes, it can be open ports of a server, or the number of wheels your car has, as you want :)

The data should be sent to the output.

Here is an example of the output of the nmap script for a standard linux box :

  $ libexec/nmap_discovery_runner.py -t localhost
  
  localhost::isup=1
  localhost::os=linux
  localhost::osversion=2.6.X
  localhost::macvendor=
  localhost::openports=22,80,1521,3306,5432,5666,6502,8080,50000
  localhost::fqdn=localhost
  localhost::ip=127.0.0.1

  objectname::key=value

The discovery scripts definition (like nmap or vmware used by default) are in the file /etc/shinken/discovery_runs.cfg

Without rules, the raw data generated by the discovery scripts is useless. The rules are defined in the /etc/shinken/discovery_rules.cfg file.

Here is an example of how to create a “generic” host for anything that is detected by nmap and answers to a ping request :

  define discoveryrule {
         discoveryrule_name       HostGeneric
         creation_type            host
         
         isup                     1
         
         use                      generic-host
  }

• discoveryrule_name and creation_type parameter. The first one should be unique, and the second can be 'host' or 'service' (default). More types will be added in the future.
• isup : it's the key name that will lookup in the raw data from the discovery scripts. It will use the value (here 1) as a comparison for data value, if all key/values are good, the rule is valid, and will apply.
• use : it's a parameter that the host object that will be generated will inherit. You can add as properties as you want.

Here is an example for a port matching rule service creation :

  define discoveryrule {
       discoveryrule_name       Ftp
       
       openports                ^21$
       
       check_command            check_ftp
       service_description      Ftp
       use                      generic-service
  }

The service generated will be with FTP for the host_name the object_name send by the discovery script, the check_command check_ftp and it will use the generic-service template.

You can ask not to match a rule. It's very easy, just add a ! character before the key name.

For example :

define discoveryrule {
       discoveryrule_name       Ftp
       
       openports                ^21$
       !os                      linux
       
       check_command            check_ftp
       service_description      Ftp
       use                      generic-service
  }

By default, when you put a new host/service property, it will replace all previously detected values. For some properties like templates or groups, this is not a good idea. That's why you can say a property should be “added” by using the character ”+” before it.

For example, we want to add the “ftp” and “http” templates on the host, without removing all previously inserted values.

define discoveryrule {
       discoveryrule_name       Ftp
       creation_type            host
       openports                ^21$
       +use                     ftp
  }
  
define discoveryrule {
       discoveryrule_name       Http
       creation_type            host
       openports                ^21$
       +use                     http
  }

If both ports are open, it will create an host with :

define host {
    host_name   localhost
    use         ftp,http
}