naparuba/shinken — comment on commit fca9f2e69c2403039671a8eb4fc405f4e8c5a11e
File:  line 0
By naparuba:

Yes I was thinking about such things, with discovery "layers". One example
if for the Oracle servers.

With the "nmap runner" you see that it's a linux one with an oracle
listener. Great. but the Oracle template need the instance names :(
It can be easy to wrote a tnsping runner that will list (or use the
check_oracle_health plugin) after.

I'm wondering about get a X phases discovery, like a workflow indeed, with
previous results used for new "runners" and entry.

With the duplicate_foreach thing, it can be a killing feature (you use
discovery for filling "properties" that you are using for creating
services, more than just tags).

I'll try to draft something around teh runners and discovery rules, maybe
new parameters for theses last two. It should stay "simple" to wrote of
course. Maybe with some "triggering" entries (like if 'oracle' in use
property -> launch it).

So :

* phase 1 : nmap/other jsut create hosts and add basic data (port, os,
macvendor, etc)
* for each new hosts output by the phase 1 : look for "other runners", and
try to see if one or more match the entry, if so, launch it.
* for each host, loop until we got a loop where no more available runner is
available (only go in one runner for the whole thing).

With it, we can write in the "Oracle pack"
define discoveryrule {
discoveryrule_name Oracle
creation_type host
openports ^1521$
+use oracle
}

define discoveryrun {
discoveryrun_name GetOracleDatabases
discoveryrun_command oracle_discovery

# Now the matching part that must be "match" by the host after the
first pass
use oracle
}

define discoveryrule {
discoveryrule_name OracleDatabases
update_type host
triggered_by GetOracleDatabases
_databases $_HOSTDATABASES$
}

So a multi layer discovery thing. The difficulty is in the OracleDatabases
discovery rule. It should be easy to wrote and we should be sure it will
jsut pop-up after the GetOracleDatabases runner I think (allow ALL
discovery rule can lead to some strange side effects isn't it?) It should
be the most easy to wrote of it won't be used :p

With this, we can have a full "discovery workflow" for each hosts that can
fill property. It's modular in the rules writing and in the data because
i's just scripts that are called by runners.

Sounds very very insteresting for 1.2, maybe to be solved before the
Shin-packs things :p

Jean

On Mon, Jan 30, 2012 at 2:56 PM, xkilian <
reply@reply.github.com
> wrote:

> A global rule discovery module, which calls the various methods and
> applies the "business logic".
>
> Mandatory Tests
> Step 1 - IP -> hostname regex
> Step 2 - nmap generic (ex. common open ports)
> Step 3 - SNMP generic (ex. sysDerc, location, admin, etc.)
>
> Optional Tests based on the previous results or seed files (ex. from GLPI,
> from flat file, from corporate database extraction/query)
> Step 4 - nmap specific (specific tests to figure out what exactly is
> running)
> Step 4 - SNMP specific (run a SNMP custom discovery module)
> Step 5 - WMI queries
>
> Putting it together :
> Business rules to manage the flow through each step for each type of
> template.
>
> Application to the configuration automatically through management rules
> Presentation of the results (what can be supervised) in the skonf UI
> rule based
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/naparuba/shinken/commit/fca9f2e69c2403039671a8eb4fc405f4e8c5a11e#commitcomment-914220
>