> Configuration management :
> Arbiter restarts is always necessary when managing conf (with puppet,
> chef etc). This leads to a potential issue : there is a period without
> monitoring and where there is no UI feedback (user "It's not
> working").
> We assume 30-40 restart per day (average)
> Possible solutions :
> Make the broker load objects while the arbiter restarts.
> Make the conf more granular so that we can send diff. But diff are
> technically hard to code (hashing issues)
> There are also environments with very small time to live that have to
> be
> considerated (AWS instance, openstack etc). As the time to live is
> short, arbiter has to restart more often. It can be achieved with a 5
> minutes time to restart.
> Possible solution :
> Add a host at runtime through a HTTP API without linking it to other
> host (linking is very cpu/time consuming). This can be done in the
> next
> release.
>
> Restart time is both a technial and "user visibility" issue. Creating
> object, linking and serializing them is loooooooong for huge conf, and
> we also got a huge difference between "monitoring stop" and user
> perception here (UI stop are far longer than real monitoring one).
>
Do you remember my POC with elasticsearch/livestatus ?
At configuration reload, we can do the linking on a new index and when it's
ready swap old and new index. Of course, users will not get update while
configuration reload but at least, they will have answer to their livestatus
queries.
And, as a bonus, it solve livestatus performance issues.
Regards,
Nicolas
--
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite. Tout
message etant susceptible d'alteration, l'emetteur decline toute
responsabilite au titre de ce message s'il a ete altere, deforme ou
falsifie.
-----------------------------------
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. As e-mails are susceptible to alteration,
the issuer shall not be liable for the message if altered, changed
or falsified.
------------------------------------------------------------------------------
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
