First of all i have to say that i really love livestatus as it is a great tool for interacting with third party addons. The only thing i do not like in current livestatus implementation is just the log part that break the high availibility model. This is just because livestatus use by default sqlite3 databases (IMOO sqlite3 is only for desktop applications or embeded development on phones and tablets). The only way to workaround this is to use mongologs implementation that is still unstable and not ready for production. So i can't recommend livestatus in production environments. 

But i agree that implementing the webui in such a critic place as the broker is not the ideal way but it is the easiest one. 

2013/2/1 Olivier Hanesse <>

2013/2/1 nap <>

On Fri, Feb 1, 2013 at 12:20 PM, Hermann Lauer <> wrote:
Hi :)


The standard way in python in my opinion is "", which translates nowadays
with two simple commands for example in a deb pkg.
Maybe folding (some) functionality of install into with only leaving install
a small driver script is a good way ?
It's true that in python is the king, but because 90% of the python install is about libs :p
For tools with scripts, configuration files and data like us, it's just a nightmare to manage with it, especially now the is quite hard to read (for myself).

I think we should focus on packages for common distributions, make very simple so packagers and other distribs can use it (but with far less features than install script), and the script can just be a wrapper to put good repositories and install/upgrade packages. There are some tools/plugins that we won't be able to package, so the install script can be useful for them (until every thing is package perfectly :) ).

> What about the others? What do you want to remove? :)
> I know it's a difficult task, but will help the project to be more focus on
> what is important.

Probaly not a real kill of a feature, but anyways:
Separating out the web interface from the broker and make it a wsgi script communication
with the broker would be in my opinion a good thingTM:
- broker is a somehow overloaded critical component (I noticed that stopping debug output
  in a screen stops the web ui at the moment)
- wsgi the best way known to me for integration into apache for example
- This would allow to kill all login/ssl security stuff from webui, as you can
  get an authenticated user name via environment (needed for the webui db stuff)
- Also a split in a shinken core and a webui package would be possible, as
  done in carbon-graphite and the graphite-webui package.
It's true, and I though a lot about it when I put webui inside the broker. One problem was about performances, especially for "this" WebUI. If you look at where we got the major performances problems in Shinken (yes there are :) ), it's all about serialization (like all tools, nothing magic here in fact). The goal of being *inside" the broker was to avoid a huge serialization of (huge) objects for each request (direct memory access make 120K object parsing instant :) ).

And why "this" webui is so impacted : we are using it to show lot of dependency trees everywhere, and making use of queries for this will kill performances (or you dump the whole tree, or you make X queries for each nodes, but both is asking for huge serialization phase) :(

One last thing about "why a module" was the windows run. Putting a wsgi env under windows is not trivial (not too hard, but not trivial too). With a broker module, we got a multi-platform with high availability feature by design. Yes I know that lot of you think running under windows is not a priority, but I think lot of windows admins are blocked with bad tools because they got no good alternative and don't have the time to learn Unix.

Of course there are drawback, like the ssl/sso thing (but a reverse proxy can do the trick, there is an option in WebUI for it). One major problem is the lack of scalability for the broker. I think about N broker levels (on in a realm, AND one in the global realm for example, in active/active way), but this won't solve the WebUI scaling problem. I'm still wondering how we can solve this :)

We really need to think about this "N broker"  stuff. 
 - n brokers / realm (so each broker can deal with one module)
 - 1 broker / realm, with potential broker in higher realm 

By the way, I don't know (shame on me) how exactly WebUi is working internally, but why not using Livestatus as a backend for Webui ?
I know having all object in memory is a great thing for speed, but I'm using Livestatus Uis every day, and the speed of the LiveStatus stack isn't an issue at all.
We will lose (maybe) some 'micro-seconds' of reactivity, but scalability will be much easier. And we could have a wsgi env.

Currently, WebUI is strongly linked to the core, and so putting in in another repository is not possible (or we will have lot of problem of "oh why my old webui is not working with y new core" thread on the forums.... :( ), but can be possible if we put an abstraction layer like queries between it and some brokers.

Can you open a new thread and explain your "screen stop" problem? Sounds strange and we should be able to fix it.

This are just my 2 cents.
Thanks for the new release now sitting here and has to wait for installation ;-(
Wait a bit or look at the livestatus patch on the new thread before applying it ;)

Thanks a lot for this output :)




Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Shinken-devel mailing list

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Shinken-devel mailing list

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Shinken-devel mailing list