Thread: [Shinken-devel] New feature in devel branch : The "Check ways"
Status: Beta
Brought to you by:
naparuba
From: nap <nap...@gm...> - 2013-02-22 11:54:07
|
Hi all, I just pushed an exciting feature into the git repository : Check ways. The idea is to allow admins to define different thresholds in checks based on the timeperiod. For example you put low thresholds the day, and bigger ones the night. To define one, it's very easy : *define checkway{ checkway_name Huge_load_the_night check_period night check_command check_load!10!20 }* Then in your service you can just call it : *define service{ use generic-service host_name srv-checkways check_command check_load!1!2 checkways Huge_load_the_night } * So? During the day the checkway is not active, and so the default check_command is used. But during the night, the new check_command is called instead. If you got several checkways in your host/service definition, it will use the first available. Want to give a try? Go clone the check_ways branch in the git repo : https://github.com/naparuba/shinken/tree/check_ways An extension for checkways is about filtering about object state too (like only if critical, etc). But let first start with this version, and if need, we can add new options to it. Good test :) Jean |
From: Olivier H. <oli...@gm...> - 2013-02-23 08:42:48
|
Great feature ! I think this is really something usefull that other monitoring box doesn't have. In the same way, the next step could be "macro_ways" : * having macro variables whose values can change over the time : We just need to find a clear syntax for that :) Olivier 2013/2/22 nap <nap...@gm...> > Hi all, > > I just pushed an exciting feature into the git repository : Check ways. > The idea is to allow admins to define different thresholds in checks based > on the timeperiod. For example you put low thresholds the day, and bigger > ones the night. > > To define one, it's very easy : > *define checkway{ > checkway_name Huge_load_the_night > check_period night > check_command check_load!10!20 > }* > > > Then in your service you can just call it : > *define service{ > use generic-service > host_name srv-checkways > > check_command check_load!1!2 > checkways Huge_load_the_night > } > * > > So? During the day the checkway is not active, and so the default > check_command is used. But during the night, the new check_command is > called instead. If you got several checkways in your host/service > definition, it will use the first available. > > Want to give a try? Go clone the check_ways branch in the git repo : > https://github.com/naparuba/shinken/tree/check_ways > > An extension for checkways is about filtering about object state too (like > only if critical, etc). But let first start with this version, and if need, > we can add new options to it. > > Good test :) > > > Jean > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |
From: Hermann L. <Her...@iw...> - 2013-02-25 10:01:30
|
Hello all, On Sat, Feb 23, 2013 at 09:42:36AM +0100, Olivier Hanesse wrote: > * having macro variables whose values can change over the time : > > We just need to find a clear syntax for that :) ... > > To define one, it's very easy : > > *define checkway{ > > checkway_name Huge_load_the_night > > check_period night > > check_command check_load!10!20 > > }* just an idea to put in there: Is it feasible to have different config "languages" like the salt config management tool has ? Those can use at least yaml, direct python code, jinja2 and xml. One is the (settable) default for the config files, but this can be changed with a shebang syntax in every individual file. Of course shinken would have additionally the nagios compatible "language", in the beginning as the default "language". An important point would be that the direct python code would allow to introduce self defined functions, objects and more, so not every new dynamic feature has to be introduced in the nagios "language", as you can use python code. This would also be a path to merge the daemons config into the main config in the long run. Shurely no short time idea... Thanks very much for all the work, greetings Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: Her...@iw... |
From: nap <nap...@gm...> - 2013-02-25 10:21:35
|
On Mon, Feb 25, 2013 at 10:02 AM, Hermann Lauer < Her...@iw...> wrote: > Hello all, > [...] > > just an idea to put in there: Is it feasible to have different config > "languages" like the salt config management tool has ? Those can use at > least yaml, direct python code, jinja2 and xml. > One is the (settable) default for the config files, but this can be changed > with a shebang syntax in every individual file. > > Of course shinken would have additionally the nagios compatible "language", > in the beginning as the default "language". > > An important point would be that the direct python code would allow to > introduce self defined functions, objects and more, so not every new > dynamic feature has to be introduced in the nagios "language", as you > can use python code. > > This would also be a path to merge the daemons config into the main > config in the long run. > > Shurely no short time idea... > Thanks very much for all the work, > > greetings > Hermann > Hi, Sounds possible indeed (in the Shinken internal, the objects are just a key=>value dictionary with strings, so we don't really care about the input format.). But maybe we should try to find some use cases where this can be used, and see if the effort will really solve a real user problem, or if the current configuration features are enough. It's true that the nagios configuration style was a problem, but after some quick features for simplify the configuration, now it's quite good, even for linking lot of objects together (like escalations and hosts for example). So let's find something that will change admin habits with this new capabilities, and then we can look if we should add a configuration overlay (like direct python or jinja, I'm really not a fan of XML and YAML :p ). Jean |
From: Hermann L. <Her...@iw...> - 2013-02-25 11:47:21
|
Hello Jean, On Mon, Feb 25, 2013 at 11:21:22AM +0100, nap wrote: > > just an idea to put in there: Is it feasible to have different config > > "languages" like the salt config management tool has ? Those can use at > > least yaml, direct python code, jinja2 and xml. > > One is the (settable) default for the config files, but this can be changed > > with a shebang syntax in every individual file. > > > > Of course shinken would have additionally the nagios compatible "language", > > in the beginning as the default "language". > > > > An important point would be that the direct python code would allow to > > introduce self defined functions, objects and more, so not every new > > dynamic feature has to be introduced in the nagios "language", as you > > can use python code. > > > > This would also be a path to merge the daemons config into the main > > config in the long run. ... > Sounds possible indeed (in the Shinken internal, the objects are just a > key=>value dictionary with strings, so we don't really care about the input > format.). But maybe we should try to find some use cases where this can be > used, and see if the effort will really solve a real user problem, or if > the current configuration features are enough. One minor issue is the following line in our current udp module (see https://bitbucket.org/hlauer/shinken2rrd for the code): template = template.replace('<','{').replace('>','}').replace(r'\n', '\n') This introduces additional syntax to get template="{$HOSTNAME$}\nssh {time[0]}" through the nagios config. Writing such stuff in python directly would be easy and well documented. > It's true that the nagios configuration style was a problem, but after some > quick features for simplify the configuration, now it's quite good, even > for linking lot of objects together (like escalations and hosts for > example). So let's find something that will change admin habits with this > new capabilities, and then we can look if we should add a configuration > overlay (like direct python or jinja, I'm really not a fan of XML and YAML > :p ). I'm also no fan of XML, but yaml looks pythonic to me ;-) BTW, just upgraded from 1.2.1 to 1.2.4 without any problems so far - many thanks. Greetings Hermann PS: On the bitbucket repo is now also a plugin for cisco threshold monitoring, if anybody needs -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: Her...@iw... |
From: Florent H. <flo...@gm...> - 2013-02-25 11:00:41
|
Hello all, I am following this discussion with lot of interest. I don't really know how the python module that convert the config files in the dictionary internal representation, but I currently have some though about plugin Shinken with other tools. The more obvious use case I see (and I'm interested in) is to be able to plug Shinken with a CMDB like tool to automatically generate probe definition from what is configured in architecture referential. Change the definition in the central database, and monitoring tools (and even other tools) automatically adapt to it. I know such kind of thing is already done with GLPI with the help of a module but there is currently no way to "easily" plug to another tool. I see 3 ways it can be done : 1/ One develop a module that will plug into shinken and will after startup add all necessary host/services extracted from the given external tool. It may be the more robust, but need developing skills and knowing Shinken's internal to add even a simple connexion 2/ Completely externally to shinken (a bit like centreon works), the external tools generate a nagios like config file that is then read by Shinken. More standard format like json or xml may help in this direction 3/ Introducting python code directly into config file may be a mid point between those two ones : in the config file, a small fonction is written that query the external tool and merge the adequate config into the config file My own point is that I don't sufficiently know Shinken's internal (for now) to develop a module even for very simple case and is sticked to solution 2 that I don't really like because of all the hassle with file generation when multiples sources are required. I planned to learn in a few month how Shinken load config files and work an a module for my particular needs, but if it can be used in the standard Shinken release it's even better ! I will be glad to help if there is no hurry to implement this feature. Regards, Florent 2013/2/25 nap <nap...@gm...> > > > On Mon, Feb 25, 2013 at 10:02 AM, Hermann Lauer < > Her...@iw...> wrote: > >> Hello all, >> [...] >> >> just an idea to put in there: Is it feasible to have different config >> "languages" like the salt config management tool has ? Those can use at >> least yaml, direct python code, jinja2 and xml. >> One is the (settable) default for the config files, but this can be >> changed >> with a shebang syntax in every individual file. >> >> Of course shinken would have additionally the nagios compatible >> "language", >> in the beginning as the default "language". >> >> An important point would be that the direct python code would allow to >> introduce self defined functions, objects and more, so not every new >> dynamic feature has to be introduced in the nagios "language", as you >> can use python code. >> >> This would also be a path to merge the daemons config into the main >> config in the long run. >> >> Shurely no short time idea... >> Thanks very much for all the work, >> >> greetings >> Hermann >> > Hi, > > Sounds possible indeed (in the Shinken internal, the objects are just a > key=>value dictionary with strings, so we don't really care about the input > format.). But maybe we should try to find some use cases where this can be > used, and see if the effort will really solve a real user problem, or if > the current configuration features are enough. > > It's true that the nagios configuration style was a problem, but after > some quick features for simplify the configuration, now it's quite good, > even for linking lot of objects together (like escalations and hosts for > example). So let's find something that will change admin habits with this > new capabilities, and then we can look if we should add a configuration > overlay (like direct python or jinja, I'm really not a fan of XML and YAML > :p ). > > > Jean > > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |
From: Olivier H. <oli...@gm...> - 2013-02-25 14:10:42
|
Hello Florent, A mysql module exists, that can query a database :) It is very simple. You just have to forge your sql request to suit your CMDB. Regards Olivier 2013/2/25 Florent Houbart <flo...@gm...> > Hello all, > > I am following this discussion with lot of interest. I don't really know > how the python module that convert the config files in the dictionary > internal representation, but I currently have some though about plugin > Shinken with other tools. The more obvious use case I see (and I'm > interested in) is to be able to plug Shinken with a CMDB like tool to > automatically generate probe definition from what is configured in > architecture referential. Change the definition in the central database, > and monitoring tools (and even other tools) automatically adapt to it. > I know such kind of thing is already done with GLPI with the help of a > module but there is currently no way to "easily" plug to another tool. I > see 3 ways it can be done : > > 1/ One develop a module that will plug into shinken and will after > startup add all necessary host/services extracted from the given external > tool. It may be the more robust, but need developing skills and knowing > Shinken's internal to add even a simple connexion > > 2/ Completely externally to shinken (a bit like centreon works), the > external tools generate a nagios like config file that is then read by > Shinken. More standard format like json or xml may help in this direction > > 3/ Introducting python code directly into config file may be a mid > point between those two ones : in the config file, a small fonction is > written that query the external tool and merge the adequate config into the > config file > > > My own point is that I don't sufficiently know Shinken's internal (for > now) to develop a module even for very simple case and is sticked to > solution 2 that I don't really like because of all the hassle with file > generation when multiples sources are required. > I planned to learn in a few month how Shinken load config files and work > an a module for my particular needs, but if it can be used in the standard > Shinken release it's even better ! I will be glad to help if there is no > hurry to implement this feature. > > Regards, > Florent > > > 2013/2/25 nap <nap...@gm...> > >> >> >> On Mon, Feb 25, 2013 at 10:02 AM, Hermann Lauer < >> Her...@iw...> wrote: >> >>> Hello all, >>> [...] >>> >>> just an idea to put in there: Is it feasible to have different config >>> "languages" like the salt config management tool has ? Those can use at >>> least yaml, direct python code, jinja2 and xml. >>> One is the (settable) default for the config files, but this can be >>> changed >>> with a shebang syntax in every individual file. >>> >>> Of course shinken would have additionally the nagios compatible >>> "language", >>> in the beginning as the default "language". >>> >>> An important point would be that the direct python code would allow to >>> introduce self defined functions, objects and more, so not every new >>> dynamic feature has to be introduced in the nagios "language", as you >>> can use python code. >>> >>> This would also be a path to merge the daemons config into the main >>> config in the long run. >>> >>> Shurely no short time idea... >>> Thanks very much for all the work, >>> >>> greetings >>> Hermann >>> >> Hi, >> >> Sounds possible indeed (in the Shinken internal, the objects are just a >> key=>value dictionary with strings, so we don't really care about the input >> format.). But maybe we should try to find some use cases where this can be >> used, and see if the effort will really solve a real user problem, or if >> the current configuration features are enough. >> >> It's true that the nagios configuration style was a problem, but after >> some quick features for simplify the configuration, now it's quite good, >> even for linking lot of objects together (like escalations and hosts for >> example). So let's find something that will change admin habits with this >> new capabilities, and then we can look if we should add a configuration >> overlay (like direct python or jinja, I'm really not a fan of XML and YAML >> :p ). >> >> >> Jean >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Shinken-devel mailing list >> Shi...@li... >> https://lists.sourceforge.net/lists/listinfo/shinken-devel >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |
From: Florent H. <flo...@gm...> - 2013-02-25 14:38:52
|
Hello Olivier, I did not know that, great info to know :) What is the name of this module ? I cannot find it in the docs... Unfortunately my CMBD is not Mysql but is a home made tool powered by Postgres. Information should not be directly extracted from database but from a REST web interface that add some logic on the raw data. Same situation may occur when interconnecting closed application that rarely expose their database directly. It's very specific, and I think I'm not the only one who think of connecting monitoring with external tools. That's why I was so enthusiast with different coding language and much more by programmatic salt in the config that will allow such interconnection much more easily. Regards Florent 2013/2/25 Olivier Hanesse <oli...@gm...> > Hello Florent, > > A mysql module exists, that can query a database :) It is very simple. > You just have to forge your sql request to suit your CMDB. > > Regards > > Olivier > > |
From: Olivier H. <oli...@gm...> - 2013-02-25 14:55:28
|
Re :) The module name is : Mysqlmport. You can have a look at the file mysql_import_arbiter.py It is very easy to understand, and can be work with psql (or rest interface) too without heavy modification. 2013/2/25 Florent Houbart <flo...@gm...> > Hello Olivier, > > I did not know that, great info to know :) > What is the name of this module ? I cannot find it in the docs... > > Unfortunately my CMBD is not Mysql but is a home made tool powered by > Postgres. Information should not be directly extracted from database but > from a REST web interface that add some logic on the raw data. > Same situation may occur when interconnecting closed application that > rarely expose their database directly. > It's very specific, and I think I'm not the only one who think of > connecting monitoring with external tools. > > That's why I was so enthusiast with different coding language and much > more by programmatic salt in the config that will allow such > interconnection much more easily. > > Regards > Florent > > > 2013/2/25 Olivier Hanesse <oli...@gm...> > >> Hello Florent, >> >> A mysql module exists, that can query a database :) It is very simple. >> You just have to forge your sql request to suit your CMDB. >> >> Regards >> >> Olivier >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |
From: Florent H. <flo...@gm...> - 2013-02-25 17:31:44
|
Thanks for this info ! It's indeed rather simple, a good base to understand how to inject configuration via modules. Florent 2013/2/25 Olivier Hanesse <oli...@gm...> > Re :) > > The module name is : Mysqlmport. > You can have a look at the file mysql_import_arbiter.py > It is very easy to understand, and can be work with psql (or rest > interface) too without heavy modification. > > > > > 2013/2/25 Florent Houbart <flo...@gm...> > >> Hello Olivier, >> >> I did not know that, great info to know :) >> What is the name of this module ? I cannot find it in the docs... >> >> Unfortunately my CMBD is not Mysql but is a home made tool powered by >> Postgres. Information should not be directly extracted from database but >> from a REST web interface that add some logic on the raw data. >> Same situation may occur when interconnecting closed application that >> rarely expose their database directly. >> It's very specific, and I think I'm not the only one who think of >> connecting monitoring with external tools. >> >> That's why I was so enthusiast with different coding language and much >> more by programmatic salt in the config that will allow such >> interconnection much more easily. >> >> Regards >> Florent >> >> >> 2013/2/25 Olivier Hanesse <oli...@gm...> >> >>> Hello Florent, >>> >>> A mysql module exists, that can query a database :) It is very simple. >>> You just have to forge your sql request to suit your CMDB. >>> >>> Regards >>> >>> Olivier >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Shinken-devel mailing list >> Shi...@li... >> https://lists.sourceforge.net/lists/listinfo/shinken-devel >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |
From: nap <nap...@gm...> - 2013-02-26 13:52:56
|
On Mon, Feb 25, 2013 at 6:30 PM, Florent Houbart <flo...@gm...>wrote: > Thanks for this info ! > It's indeed rather simple, a good base to understand how to inject > configuration via modules. > > Florent > > > Hi, modules are a good way for importing moving configuration. I'm thinking about adding a way so the arbiter can easily "merge" data from various sources (from VMWare you got the VM property, from CMDB you got the OS and such things, from Active Directory you can have some tags, etc). Now if we came back to check_ways, François proposed in a github ticket to rename them check_modulation(s). It's maybe more clear about what they are doing, and it sounds like businessimpact_modulations or result_modulations after all. so what do you prefer? check_way(s) or check_modulation(s) ? Jean |
From: Olivier H. <oli...@gm...> - 2013-02-26 14:06:43
|
or maybe "command_modulation" as we are changing the command of a check ? 2013/2/26 nap <nap...@gm...> > > > On Mon, Feb 25, 2013 at 6:30 PM, Florent Houbart < > flo...@gm...> wrote: > >> Thanks for this info ! >> It's indeed rather simple, a good base to understand how to inject >> configuration via modules. >> >> Florent >> >> >> Hi, > > modules are a good way for importing moving configuration. I'm thinking > about adding a way so the arbiter can easily "merge" data from various > sources (from VMWare you got the VM property, from CMDB you got the OS and > such things, from Active Directory you can have some tags, etc). > > Now if we came back to check_ways, François proposed in a github ticket to > rename them check_modulation(s). It's maybe more clear about what they are > doing, and it sounds like businessimpact_modulations or result_modulations > after all. > > so what do you prefer? check_way(s) or check_modulation(s) ? > > > Jean > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Shinken-devel mailing list > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > |