Menu
▾
▴
perfparse-devel-int
|
From: Yves <yme...@pe...> - 2005-01-04 10:44:42
|
Hi ! There are 2 scripts perfparse.sh and perfparse_daemon.sh in the perfparse= project. Are they working ? Are they supported ? Are they obsolete ? Should they b= e removed ? perfparse_daemon.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It's in the contrib/ directory. I consider that everything in contrib/ is= unsupported. We can update things in contrib/ ourselves, but it's like a place to put = things that we don't use and cannot support easily. perfparse_daemon.sh was made before perfparsed. Now, we have perfparsed t= hat does better work than perfparse_daemon.sh and perfparse-log2mysql combined. I think that perfparse_daemon.sh should be removed, even if it seems to w= ork and to be up to date :) It's better to force users who are running perfparse_daemon.sh to use per= fparsed. Of course, they can keep their script if they want. perfparse.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This script contains a reference to nagios lock. For that reason, I consi= der it as obsolete. But it is in perfparse/ directory so we have to consider it as = supported. A decision has to be taken here : remove it or update it quick ? :) In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* We now have perfparsed, but perfparsed does not do exactly the same job. Users who are running perfparse.sh with a "* * * * *" scheduling should u= se perfparsed. Users who are running perfparse.sh every 10 minutes or every hour or ever= y day cannot use perfparsed for that. Those users can run perfparse-log2* with the -c = option (configuration file). Should we provide a script that just does it ? Decision to be taken : - do we update perfparse.sh and support it ? - do we remove perfparse.sh from perfparse ? - do we update perfparse.sh and move it to contrib/ (in order to say that= we don't support it) ? Your opinion... ? Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ben C. <bcl...@pe...> - 2005-01-04 12:02:44
|
Yves, I kept the original thread in the 'users' mailing list, my thinking being that they are the ones who uss this, and will therefore know. I hope we get some response from them about who still uses this. I my self use the perfparse.sh script on a live server. I do a clean parse every hour, which is the way I want to run that server. I have not upgraded this one for a while, so was unaware of the nagios.lock being taken out of the config. Do you remember which version this was removed? Therefore I would prefer it is supported as-is. It's a nice ability if people want it, although there may be better methods. I also comment on the 'contrib' directory. This contains the create/drops scripts for the database. Which I chose because that's where Nagios puts them, so users may find them more easily. These are supported. Maybe these need another directory? I agree that the perfparse_deamon.sh should go. Ben Yves wrote: > Hi ! > > There are 2 scripts perfparse.sh and perfparse_daemon.sh in the perfparse project. > Are they working ? Are they supported ? Are they obsolete ? Should they be removed ? > > perfparse_daemon.sh > =================== > It's in the contrib/ directory. I consider that everything in contrib/ is unsupported. > We can update things in contrib/ ourselves, but it's like a place to put things that we > don't use and cannot support easily. > > perfparse_daemon.sh was made before perfparsed. Now, we have perfparsed that does better > work than perfparse_daemon.sh and perfparse-log2mysql combined. > I think that perfparse_daemon.sh should be removed, even if it seems to work and to be > up to date :) > It's better to force users who are running perfparse_daemon.sh to use perfparsed. Of > course, they can keep their script if they want. > > perfparse.sh > ============ > > This script contains a reference to nagios lock. For that reason, I consider it as > obsolete. But it is in perfparse/ directory so we have to consider it as supported. A > decision has to be taken here : remove it or update it quick ? :) > > In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* > We now have perfparsed, but perfparsed does not do exactly the same job. > Users who are running perfparse.sh with a "* * * * *" scheduling should use perfparsed. > Users who are running perfparse.sh every 10 minutes or every hour or every day cannot > use perfparsed for that. Those users can run perfparse-log2* with the -c option > (configuration file). Should we provide a script that just does it ? > Decision to be taken : > - do we update perfparse.sh and support it ? > - do we remove perfparse.sh from perfparse ? > - do we update perfparse.sh and move it to contrib/ (in order to say that we don't > support it) ? > > Your opinion... ? > > Yves -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Ben C. <Ben...@ro...> - 2005-01-04 12:16:23
|
Just another comment: Reinstating the perfparse.sh does not need any c code. This reads the perfparse.cfg file directly. All that is needed is the nagios.lock definition returned to this file :) Ben Ben Clewett wrote: > Yves, > > I kept the original thread in the 'users' mailing list, my thinking > being that they are the ones who uss this, and will therefore know. I > hope we get some response from them about who still uses this. > > I my self use the perfparse.sh script on a live server. I do a clean > parse every hour, which is the way I want to run that server. I have > not upgraded this one for a while, so was unaware of the nagios.lock > being taken out of the config. Do you remember which version this was > removed? > > Therefore I would prefer it is supported as-is. It's a nice ability if > people want it, although there may be better methods. > > I also comment on the 'contrib' directory. This contains the > create/drops scripts for the database. Which I chose because that's > where Nagios puts them, so users may find them more easily. These are > supported. Maybe these need another directory? > > I agree that the perfparse_deamon.sh should go. > > Ben > > > Yves wrote: > >> Hi ! >> >> There are 2 scripts perfparse.sh and perfparse_daemon.sh in the >> perfparse project. >> Are they working ? Are they supported ? Are they obsolete ? Should >> they be removed ? >> >> perfparse_daemon.sh >> =================== >> It's in the contrib/ directory. I consider that everything in contrib/ >> is unsupported. >> We can update things in contrib/ ourselves, but it's like a place to >> put things that we >> don't use and cannot support easily. >> >> perfparse_daemon.sh was made before perfparsed. Now, we have >> perfparsed that does better >> work than perfparse_daemon.sh and perfparse-log2mysql combined. >> I think that perfparse_daemon.sh should be removed, even if it seems >> to work and to be >> up to date :) >> It's better to force users who are running perfparse_daemon.sh to use >> perfparsed. Of >> course, they can keep their script if they want. >> >> perfparse.sh >> ============ >> >> This script contains a reference to nagios lock. For that reason, I >> consider it as >> obsolete. But it is in perfparse/ directory so we have to consider it >> as supported. A >> decision has to be taken here : remove it or update it quick ? :) >> >> In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* >> We now have perfparsed, but perfparsed does not do exactly the same job. >> Users who are running perfparse.sh with a "* * * * *" scheduling >> should use perfparsed. >> Users who are running perfparse.sh every 10 minutes or every hour or >> every day cannot >> use perfparsed for that. Those users can run perfparse-log2* with the >> -c option >> (configuration file). Should we provide a script that just does it ? >> Decision to be taken : >> - do we update perfparse.sh and support it ? >> - do we remove perfparse.sh from perfparse ? >> - do we update perfparse.sh and move it to contrib/ (in order to say >> that we don't >> support it) ? >> >> Your opinion... ? >> >> Yves > > > |
|
From: Yves <yme...@pe...> - 2005-01-04 13:45:59
|
> Just another comment: > > Reinstating the perfparse.sh does not need any c code. This reads the > perfparse.cfg file directly. All that is needed is the nagios.lock > definition returned to this file :) A suggestion : don't mix the config of perfparse and the config of nagios= :) An admin would write a script to find nagios.lock directly in nagios conf= ig files, have a env variable or another mechanism, but not put that in perfparse.cfg. As an admin, I even think that is it not the job of perfparse developers = to provide those scripts, but the job of packagers and companies that sell support. = But well, we have it and users enjoy it, so keep it in perfparse :) Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ben C. <bcl...@pe...> - 2005-01-04 14:13:21
|
Yves, I can read the nagios.cfg file to obtain the location of nagios.pid. I have a problem that none of the config variables tell me where this file is. I cannot assume that PP is installed into the Nagios directory structure. I think this was why this was written into the perfparse.cfg. The reason I didn't notice the demise of this method was that my perfparse.cfg is old, I have not copied over the example for quite some time. I thank the new user for finding this. Personally I would suggest just adding this option into perfparse.cfg and an entry into config_file.c to match this so that every option is accounted for. I will create the new scripts directory with the database creation scripts as well as perfparse.sh. I'll edit the documentation where I can find it. I hope I do not miss any! Ben Yves wrote: >>Just another comment: >> >>Reinstating the perfparse.sh does not need any c code. This reads the >>perfparse.cfg file directly. All that is needed is the nagios.lock >>definition returned to this file :) > > > A suggestion : don't mix the config of perfparse and the config of nagios :) > > An admin would write a script to find nagios.lock directly in nagios config files, have > a env variable or another mechanism, but not put that in perfparse.cfg. > > As an admin, I even think that is it not the job of perfparse developers to provide > those scripts, but the job of packagers and companies that sell support. But well, we > have it and users enjoy it, so keep it in perfparse :) > > Yves > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Yves <yme...@pe...> - 2005-01-04 14:44:26
|
> Mail pour yves > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Yves, > > I can read the nagios.cfg file to obtain the location of nagios.pid. I > have a problem that none of the config variables tell me where this fil= e > is. I cannot assume that PP is installed into the Nagios directory > structure. You have to use a variable to write the file name. Ask yourself what filename is best : nagios config file or nagios pid fil= e ? :) > I think this was why this was written into the perfparse.cfg. No : perfparse used to use the pid of nagios. So it had to be specified i= nto perfparse.cfg. Now, perfparsed and perfparse-log2* don't use it, so it has nothing to do= with perfparse.cfg. > > The reason I didn't notice the demise of this method was that my > perfparse.cfg is old, I have not copied over the example for quite some > time. I thank the new user for finding this. If you want to support that script, I tell you again, update your perfpar= se.cfg and your perfparse.sh script at every new version of perfparse. > > Personally I would suggest just adding this option into perfparse.cfg > and an entry into config_file.c to match this so that every option is > accounted for. I would not do it. If that feature is broken in nagios (it used to be in = nagios-2.0), it would become a bug of perfparse too. If that feature changes or is remove= d, it would become a bug of perfparse. Don't depend on nagios too much : perfparse is= not a nagios extension but a project on its own :) Just put it in the script, and if that feature disappear, changes or is b= roken, users can easily change the script with no impact on perfparse binaries. This is also why I think that perfparse.sh should not be included in perf= parse. It is the role of the admins to provide that script, not the role of the develo= pers. And because it exists and because you want to maintain it, keep it. Some = users probably use it too. > > I will create the new scripts directory with the database creation > scripts as well as perfparse.sh. I'll edit the documentation where I > can find it. I hope I do not miss any! Also check perfparse.cfg.example. I suggest that you remove all options that are OK as default values (chec= k config_file.c) Only keep the options when perfparse cannot work if they are not edited (= like the directory where modules are, like the mysql login parameters...) Remove the others : users can do perfparsed --show_config to have all :) If you remove them, you will have less obsolete entries in the future whe= n you add/remove/change options of the config :) Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ben C. <Ben...@ro...> - 2005-01-04 15:15:11
|
Yves, I want to settle this before the next release. Which is waiting for the 'make distcheck'... We cannot put the nagios lock file into the perfparse.cfg because this ties in the product with a version of Nagios which may change. I can understand this. I do not entirely agree that we are just developers. We are also packagers until somebody offers to build and maintain an RPM (or similar). This script is an essential wrapper if you with to use the 'cron' method. If we use it, we support it. Or I support it :) The script is based on a .in file, therefore a directory with a Makefile. This will be the new 'scripts' directory. The only problem we have is the definition of the nagios.lock. I will set it to the likely default: /usr/local/nagios/var/nagios.lock A sys admin will see this I hope and edit it accordingly. I am worried about removing options from the perfparse.cfg if they are at default. These files often serve as an alternate manual, self explaining what options are available. By removing most options, I don't think we serve the users interests at best. There is the option used by a lot of modern systems where all options are commented out, but shown as default in the comments: (Eg, Samba) # Option for setting foo. Default = "bar" # foo = "bar" The user can see the default, and edit it if they want to change it by uncommenting. Removal of obsolete entries is unfortunate. This does not occur often. After version 1.0.0 I hope not at all if possible. Maybe this is not so important? Ben Yves wrote: >>Mail pour yves >>============== >> >>Yves, >> >>I can read the nagios.cfg file to obtain the location of nagios.pid. I >>have a problem that none of the config variables tell me where this file >>is. I cannot assume that PP is installed into the Nagios directory >>structure. > > > You have to use a variable to write the file name. > Ask yourself what filename is best : nagios config file or nagios pid file ? :) > > >>I think this was why this was written into the perfparse.cfg. > > > No : perfparse used to use the pid of nagios. So it had to be specified into perfparse.cfg. > Now, perfparsed and perfparse-log2* don't use it, so it has nothing to do with > perfparse.cfg. > > >>The reason I didn't notice the demise of this method was that my >>perfparse.cfg is old, I have not copied over the example for quite some >>time. I thank the new user for finding this. > > > If you want to support that script, I tell you again, update your perfparse.cfg and your > perfparse.sh script at every new version of perfparse. > > >>Personally I would suggest just adding this option into perfparse.cfg >>and an entry into config_file.c to match this so that every option is >>accounted for. > > > I would not do it. If that feature is broken in nagios (it used to be in nagios-2.0), it > would become a bug of perfparse too. If that feature changes or is removed, it would > become a bug of perfparse. Don't depend on nagios too much : perfparse is not a nagios > extension but a project on its own :) > Just put it in the script, and if that feature disappear, changes or is broken, users > can easily change the script with no impact on perfparse binaries. > This is also why I think that perfparse.sh should not be included in perfparse. It is > the role of the admins to provide that script, not the role of the developers. > > And because it exists and because you want to maintain it, keep it. Some users probably > use it too. > > > > >>I will create the new scripts directory with the database creation >>scripts as well as perfparse.sh. I'll edit the documentation where I >>can find it. I hope I do not miss any! > > > Also check perfparse.cfg.example. > I suggest that you remove all options that are OK as default values (check config_file.c) > Only keep the options when perfparse cannot work if they are not edited (like the > directory where modules are, like the mysql login parameters...) > Remove the others : users can do perfparsed --show_config to have all :) > If you remove them, you will have less obsolete entries in the future when you > add/remove/change options of the config :) > > Yves > |
|
From: Yves <yme...@pe...> - 2005-01-04 13:41:09
|
> Yves, > > I kept the original thread in the 'users' mailing list, my thinking > being that they are the ones who uss this, and will therefore know. I > hope we get some response from them about who still uses this. We should talk here on perfparse-devel-int and post our conclusion on per= fparse-users and ask for their opinion. If we flood perfparse-users with that thread, = nobody will read our last mail with the conclusion, and nobody will say who still use= s it. This is why I moved to perfparse-devel-int. > I my self use the perfparse.sh script on a live server. I do a clean > parse every hour, which is the way I want to run that server. I have > not upgraded this one for a while, so was unaware of the nagios.lock > being taken out of the config. Do you remember which version this was > removed? I remember now that there are 2 things. - nagios reboot with perfparse : in 0.100.7 and removed in 0.101 ? Check = the ChangeLog :) - nagios reboot thanks to the script : new feature of the script since 0.= 101 ? I forgot that feature of the script. So yes, there is still a nagios lock. But it should be removed of the per= fparse config. This is the nagios config only, and a parameter of perfparse.sh script. > Therefore I would prefer it is supported as-is. It's a nice ability if > people want it, although there may be better methods. I think it's the best method. Provide the tool, and administrators provide script for running the tool = the way they want. And we graciously give such a script :) Do you want to support it ? if yes, I see no problem, but you should upgr= ade that script at every new version. When you install a new perfparse version, you get a perfparse.sh.example = script. So the perfparse.sh script you have is still the old one, that continues to work= for you. Maybe users have a different script. Be sure that you are running the latest on= e :) > I also comment on the 'contrib' directory. This contains the > create/drops scripts for the database. Which I chose because that's > where Nagios puts them, so users may find them more easily. These are > supported. Maybe these need another directory? I agree with you. I suggest a new directory, where you put the db create/drop scripts, *and= perfparse.sh* script. In 0.104.5, "make install" installs perfparse.sh.example". I suggest that= newer versions don't install it (like the db create/drop scripts). Users can find it in the scripts/ directory and install it themselves. Fo= r packaged solutions, this is the job of packagers to do it, not to do it, or to pro= vide their own scripts in their packages. > I agree that the perfparse_deamon.sh should go. I agree with you. Do you want that I do all of that and make a 0.104.5ym1 release or do you= prefer to do it yourself ? Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X