search

shinken-solutions / shinken

Flexible and scalable monitoring framework
http://www.shinken-monitoring.org
GNU Affero General Public License v3.0
1.13k stars 337 forks source link

reload and check logical in arbiter #1545

Open andyxning opened 9 years ago

andyxning commented 9 years ago

i found that no matter what reload(without -v) or check(-v) is specified with shinken-arbiter, we just do the is-correct check, this may be useless and may make the reload take more time.

I think we can add a more option with shinken-arbiter -i, i.e., ignore check. By default we can use the is_correct function to check if the configuration is right. But if we can make sure that the configuration is already checked and everything is fine, we can explicitly add the -i option to bypass the check logic which has already been done with -v options.

naparuba commented 9 years ago

Object check do not take lot of time as far as I remeber. Please give use hints about how much time we can save here by skipping this phase on a normal launch after a manual check.

On Sat, Mar 21, 2015 at 7:05 AM, Ning Xie notifications@github.com wrote:

i found that no matter what reload(without -v) or check(-v) is specified with shinken-arbiter, we just do the is-correct https://github.com/naparuba/shinken/blob/master/shinken/daemons/arbiterdaemon.py#L446 check, this may be useless and may make the reload take more time.

I think we can add a more option with shinken-arbiter -i, i.e., ignore check. By default we can use the is_correct function to check if the configuration is right. But if we can make sure that the configuration is already checked and everything is fine, we can explicitly add the -i option to bypass the check logic which has already been done with -v options.

— Reply to this email directly or view it on GitHub https://github.com/naparuba/shinken/issues/1545.

geektophe commented 9 years ago

I agree with @naparuba, the check phase is negligible in regard to the parse phase, which is anyway mandatory. In addition, even if the I could, personaly I would not take the risk to send a configuration which has not been verified before.

What could be done to optimize restart time could be to reload the configuration from the arbiter process itself on the HUP signal, and if it's correct, replace the existing one. This could avoid having to restart the process, and perform a double check.

andyxning commented 9 years ago

i agree with @Christophe Simon, that we should take consider to make HUP signal handler available on arbiter and in that case without restart the arbiter process we can have arbiter to process external commands with no lose and still do other works.

++++++ Ning Xie

2015-03-27 2:18 GMT+08:00 Christophe Simon notifications@github.com:

I agree with @naparuba https://github.com/naparuba, the check phase is negligible in regard to the parse phase, which is anyway mandatory. In addition, even if the I could, personaly I would not take the risk to send a configuration which has not been verified before.

What could be done to optimize restart time could be to reload the configuration from the arbiter process itself on the HUP signal, and if it's correct, replace the existing one. This could avoid having to restart the process, and perform a double check.

— Reply to this email directly or view it on GitHub https://github.com/naparuba/shinken/issues/1545#issuecomment-86654478.

geektophe commented 9 years ago

I'll have a look at that.

andyxning commented 9 years ago

Can we just make this Reload configuration without stop Arbiter daemon as a main feature in Shinken 2.6. I think it is really useful and essential

naparuba commented 9 years ago

Yes, if the new arbiter is start with the -r parameter, it will kill the old one after loading and parsing all elements, so the huge part. That can make the old arbiter alive for longer period and less "no arbiter" time :)

On Thu, Apr 23, 2015 at 5:58 AM, Ning Xie notifications@github.com wrote:

Can we just make this Reload configuration without stop Arbiter daemon as a main feature in Shinken 2.6. I think it is really useful and essential

— Reply to this email directly or view it on GitHub https://github.com/naparuba/shinken/issues/1545#issuecomment-95420263.

andyxning commented 9 years ago

That's very great and i am looking for that feature.

And do we have beginning to do this in master branch? if we have any code already carrying on, i hope you can give me a place to see it.

++++++ Ning Xie

2015-04-23 14:44 GMT+08:00 Gabès Jean notifications@github.com:

Yes, if the new arbiter is start with the -r parameter, it will kill the old one after loading and parsing all elements, so the huge part. That can make the old arbiter alive for longer period and less "no arbiter" time :)

On Thu, Apr 23, 2015 at 5:58 AM, Ning Xie notifications@github.com wrote:

Can we just make this Reload configuration without stop Arbiter daemon as a main feature in Shinken 2.6. I think it is really useful and essential

— Reply to this email directly or view it on GitHub https://github.com/naparuba/shinken/issues/1545#issuecomment-95420263.

— Reply to this email directly or view it on GitHub https://github.com/naparuba/shinken/issues/1545#issuecomment-95463170.