Shinken

$KEY$ with multi-values

It would be great if something like this was possible (in order to have very flexible host-template) : define { name my_wonderful_template register 0 # Default value of the key (but value is a list) _mykey [ "index.php", "http://$HOSTADDRESS$", "REGEX", "2"], } define service { # We can use any item of the key. duplicate_foreach service_description test on $KEY[0]$ register 0 ...more »

Submitted by
2 comments

Voting

1 vote

Shinken

Graphic visualization export of the shiken configuration

i would like to export all shinken's configuration in a big graph where i would see:

- link into all hosts,templates and their services

- all dependancies

- responsibles (contactgroup)

Submitted by
1 comment

Voting

1 vote

Shinken

Shinken Configuration format

Store the Shinken configuration in a more strongly typed, hierarchical and standard format. Ex. JSON, YAML. Continu to provide configuration validity checking and human readability.

This obviously breaks the configuration format. So this should only be done when Shinken reaches critical mass, or when conversion utility is available.

Submitted by
2 comments

Voting

2 votes

Shinken

Storing the configuration in a database

I suggest you store the Shinken configuration in a SQL/noSQL back-end database, instead of current flat-files. Any configuration stored in the database should be exportable/importable to and from a strongly typed format files that are still readable. (JSON, YAML, etc.)

Submitted by
9 comments

Voting

9 votes