Hi,
I was looking on the monitoring configuration management side lately, and I
think we got lot of enhancement possible there.
We got:
* flat configuration file : purely local, but easy to hack and to know
which modules load
* discovery : great for first discovery, but erase user modifications for
regular scans (like new filesystem or new role)
* arbiter import modules : "load from what you want" is great (we got
mysql, EC2 or things like this). But can be long (think about a VMWare
dump? Or what if the source is down? (server room restart, etc etc). And
one host can be export by one module **ONLY**
* Last but not least: Skonf. Graphical is great, but can't write into
flat files, just read/write one source (mongodb). Also inherit the
discovery problems. This sucks, and that's why I stopped it.
Did you see that none of this allow one thing: distributed generated
configuration. Got one configuration is great, but if you got X datacenters
around the world, you will have X sources of configurations too (maybe one
datacenter is using GLPI, and another is using Itop).
That's why I think we got lot of enhancements there.
I think I found one possible solution, and I want to got your feedback
about it because it can change the 2.4 roadmap a lot.
The key idea is to have an element that will load hosts from X sources. One
host can be filled by X sources (for example your CMDB will say
"use=production,linux" and a vmware scan will say "use=vm,europe-dc". The
element will save each source data, and will export one final version
"use=production,linux,vm,europe-dc" (we can take the source order as
priority).
The arbiter will just have to load this final version as it's configuration
(like with an import module, not on the arbiter core code).
With it:
* cfg and discovery can just be sources, they will be merged with other
ones.
* skonf will also be one source (skonf will read the final version, but
will write as a priority source).
* as skonf always win, you can rescan with discovery without problems, if
the admin overload the value in skonf, it's not a problem.
That can be a simple script, but I think we should add another daemon (yes
I know, we already got plenty...). So it can schedule regular "import", and
you can have a configuration management distribution:
* You got one daemon on Europe, the europe admin are using a local skonf to
write into it, and you scan the europe part only. Europe guys can only see
the europe part.
* You got one daemon on Asia, the asian admin can use skonf to manage asia
hosts, and don't see the other countries.
* You got one daemon in USA... (snip)
* You got one higher level daemon (like on your higher realm) that will
"import" Europe+Asia+USA, and will output one last final version that the
arbiter will load.
With it, you can got the same behavior for distributed monitoring, but for
the configuration management.
I'm thinking about giving the name of "shinken-synchronizer" (or something
like shinken-sync), because it syncronize X sources.
So, what do you think about it? It it clear enough? Did I miss something,
or it it "too much"?
It's your turn now :)
Jean
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
