You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(22) |
Jul
(18) |
Aug
(30) |
Sep
(11) |
Oct
(45) |
Nov
(14) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(10) |
Feb
(12) |
Mar
|
Apr
|
May
(5) |
Jun
(2) |
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(3) |
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(6) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(3) |
2007 |
Jan
(5) |
Feb
(12) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(2) |
2008 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(14) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ben C. <Be...@cl...> - 2004-07-05 08:01:48
|
Garry, A new version is nearly out, 0.0.12. This supports a far better method of defining deletion policies. But is also compatible with earlier versions. The user should see no difference, so I will use your documentation as-is. I will ensure that you are aware of any new visible changes then these become available. Ben |
From: Chris D. <cdo...@cc...> - 2004-06-30 20:05:07
|
Ben, I have done some more research and it looks like your suspicions are correct and the both cursors are not supported by libdbi. It looks like that is going to be out unless we want to get libdbi to change too. It looks like our best bet is probably to do our own abstraction layer. I'll start exploring down that path. Also, in case you are wondering, I am working on Solaris 8. Chris On Jun 30, 2004, at 11:53 AM, Ben Clewett wrote: > Sounds good. > > Although I am not overjoyed at having to suggest to users that they > need to install another program first, it will be a once only, and it > sounds like the benefits are greater than the problems. I would > however like to check that libdbi installs cleanly and does not add > major support problems. > > Another thing I want to look seriously at is the cursors in libdbi. > > PerfParse uses two cursors, both of which need supporting. > > The standard cursor which returns an entire table in memory. This is > fast when the table is small, and allows us to get the row count, > which is used many times in the code. > > The read-forward cursor which replies a row at a time. This is > essential for the graph drawing. Loading a table with 100,000 rows is > slow and consumes way too much memory. > > The respective calls in the MySQL APR are: > > query_result = mysql_store_result(&db_mysql); > query_result = mysql_use_result(&db_mysql); > > I know that PostgreSQL only supports the former, which may be the case > with other DBMS as well. > > In the same way, binary or ASCII cursors will need supporting, where > available from the DBMS. > > If this is not the case, then a simple API for doing this our selves > is not hard to write. A set of .c files for each DB, each of which > have a common .h file, and are linked, or not, depending on what > configure option has been passed. > > I emplisise how simple the API needs to be. > > All our data is text, no attempt at correct local storage is done. We > only use one table at a time. We operate a 'no error' policy. Any > SQL error will cause the program to exit. Error interperation is > therefore not needed. All SQL is simple text without the need for > variables or clever escapement. We use two simple calls only to > execute the SQL. > > I say this only as I have used API's in .NET, Java, ODBC, ADO, and > many UNIX MySQL API's. As well as at least three I have written my > self. > > Most are vastly over complex, hard to use, hard to understand, and > ultimately far more complex than direct calls. I am not saying this > is the case for libdbi, it may be the exception. But lets not jump > into bed with a monster. :) > > For what it's worth, Ben. > > > > > > Yves Mettier wrote: > >>> Ben and Yves, >>> >>> Thanks for your warm responses. >> :) >>> I agree that the lack of users listed on the libdbi website doesn't >>> look particularly promising however, I think it is probably the >>> correct >>> direction to go, assuming that we don't run into performance issues >>> that require customized database code. A company that I work for, >>> uses >>> the perl package DBI for all of our web applications that interface >>> with databases. I don't believe that DBI for perl and libdbi are >>> related except that they serve the same purpose for their respective >>> languages. >> This is the same reason I think we should give a try :) >> But there is one more check that I must do before we give it a try: >> It has to compile on >> Solaris. Otherwise, why try to use it to port on other databases if >> you cannot port it >> to other OSes ? >> For your information, I work on Solaris, and we have already had some >> people testing >> perfparse on FreeBSD (with no success/failure feedback) >>> Based on an initial comparison of the MySQL code in PerfParse 0.10 >>> and >>> the MySQL dbd module for libdbi, It doesn't look particularly >>> difficult >>> to change from the current MySQL specific calls to libdbi calls. Has >>> the database interface code been changed significantly for 0.11? >> New numerotation: now 0.0.11 :) >> The database interface has not changed, but the table definitions >> will change a lot. >> Ben will send us a new mysql_create.sql file, then I work on all the >> tools to make them >> work with it. >> We still have some points to discuss about it, but it's nearly done. >> Will probably be >> ready tomorrow (thursday). >>> I would like to propose the following plan of action: >>> 1. Produce a patch for 0.11 which enables a configuration option to >>> use >>> libdbi in stead of direct MySQL code. (MySQL code is still default) >>> 2. Role the patch into the 0.12 release >>> 3. Down the road (0.13 or later), make libdbi the default and MySQL >>> an >>> option. >>> 4. Much farther down the road, we can remove the MySQL option all >>> together (or not). >> I have some other idea, because we will be 3 (including you) to work >> on the whole code. >> And both Ben and me have no access to CVS (firewall...) >> 1/ >> I suggest that someone work on perfparse-install-db first. I can do >> it fast because I >> won't use libdbi. >> Then you take my patch to perfparse-install-db and move it to libdbi. >> 2/ >> I work on perfparse-purge-db (without libdbi) while you can already >> work on perfgraph >> and perfchart (adaptation to the new table definitions, and use >> libdbi). >> 3/ >> Somebody adapt perfparse (without libdbi) >> Ben releases 0.0.12 (with libdbi working with perfparse-install-db, >> perfgraph and >> perfchart). >> 0.0.13 will use libdbi everywhere except in perfparse. >> After that, depending on how we work, in 0.0.14 or after, we can have >> an optionnal >> support of libdbi in perfparse, in order to see its performances. >> Some functions use mysql API. Please leave them as is. Write some >> other functions that >> do the same so that we can still use mysql API. Some functions are >> shared between all >> the perfparse tools ! >> I think we will not need any #ifdef, and it's better that way. But I >> may be wrong :) >>> All of this is dependent on getting reasonable performance using >>> libdbi. If libdbi is unusable, I will scrap it in favor of writing >>> code >>> for each database. If it is usable but not as good as MySQL directly, >>> we just might not ever make it to steps 3 and 4 above. >>> >>> Let me know how this sounds and I am anxiously awaiting the release >>> of >>> 0.11. >> Released already, at 16h today (well, is it really 16h ? All files >> are released at 16h :) >> Yves >>> Chris >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email sponsored by Black Hat Briefings & Training. >>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >>> digital self defense, top technical experts, no vendor pitches, >>> unmatched networking opportunities. Visit www.blackhat.com >>> _______________________________________________ >>> Perfparse-devel mailing list >>> Per...@li... >>> https://lists.sourceforge.net/lists/listinfo/perfparse-devel >>> >>> > |
From: Ben C. <Be...@cl...> - 2004-06-30 15:51:38
|
Sounds good. Although I am not overjoyed at having to suggest to users that they need to install another program first, it will be a once only, and it sounds like the benefits are greater than the problems. I would however like to check that libdbi installs cleanly and does not add major support problems. Another thing I want to look seriously at is the cursors in libdbi. PerfParse uses two cursors, both of which need supporting. The standard cursor which returns an entire table in memory. This is fast when the table is small, and allows us to get the row count, which is used many times in the code. The read-forward cursor which replies a row at a time. This is essential for the graph drawing. Loading a table with 100,000 rows is slow and consumes way too much memory. The respective calls in the MySQL APR are: query_result = mysql_store_result(&db_mysql); query_result = mysql_use_result(&db_mysql); I know that PostgreSQL only supports the former, which may be the case with other DBMS as well. In the same way, binary or ASCII cursors will need supporting, where available from the DBMS. If this is not the case, then a simple API for doing this our selves is not hard to write. A set of .c files for each DB, each of which have a common .h file, and are linked, or not, depending on what configure option has been passed. I emplisise how simple the API needs to be. All our data is text, no attempt at correct local storage is done. We only use one table at a time. We operate a 'no error' policy. Any SQL error will cause the program to exit. Error interperation is therefore not needed. All SQL is simple text without the need for variables or clever escapement. We use two simple calls only to execute the SQL. I say this only as I have used API's in .NET, Java, ODBC, ADO, and many UNIX MySQL API's. As well as at least three I have written my self. Most are vastly over complex, hard to use, hard to understand, and ultimately far more complex than direct calls. I am not saying this is the case for libdbi, it may be the exception. But lets not jump into bed with a monster. :) For what it's worth, Ben. Yves Mettier wrote: >>Ben and Yves, >> >>Thanks for your warm responses. > > > :) > > >>I agree that the lack of users listed on the libdbi website doesn't >>look particularly promising however, I think it is probably the correct >>direction to go, assuming that we don't run into performance issues >>that require customized database code. A company that I work for, uses >>the perl package DBI for all of our web applications that interface >>with databases. I don't believe that DBI for perl and libdbi are >>related except that they serve the same purpose for their respective >>languages. > > > This is the same reason I think we should give a try :) > > But there is one more check that I must do before we give it a try: It has to compile on > Solaris. Otherwise, why try to use it to port on other databases if you cannot port it > to other OSes ? > For your information, I work on Solaris, and we have already had some people testing > perfparse on FreeBSD (with no success/failure feedback) > > >>Based on an initial comparison of the MySQL code in PerfParse 0.10 and >>the MySQL dbd module for libdbi, It doesn't look particularly difficult >>to change from the current MySQL specific calls to libdbi calls. Has >>the database interface code been changed significantly for 0.11? > > > New numerotation: now 0.0.11 :) > > The database interface has not changed, but the table definitions will change a lot. > Ben will send us a new mysql_create.sql file, then I work on all the tools to make them > work with it. > We still have some points to discuss about it, but it's nearly done. Will probably be > ready tomorrow (thursday). > > >>I would like to propose the following plan of action: >>1. Produce a patch for 0.11 which enables a configuration option to use >>libdbi in stead of direct MySQL code. (MySQL code is still default) >>2. Role the patch into the 0.12 release >>3. Down the road (0.13 or later), make libdbi the default and MySQL an >>option. >>4. Much farther down the road, we can remove the MySQL option all >>together (or not). > > > I have some other idea, because we will be 3 (including you) to work on the whole code. > And both Ben and me have no access to CVS (firewall...) > > 1/ > I suggest that someone work on perfparse-install-db first. I can do it fast because I > won't use libdbi. > Then you take my patch to perfparse-install-db and move it to libdbi. > > 2/ > I work on perfparse-purge-db (without libdbi) while you can already work on perfgraph > and perfchart (adaptation to the new table definitions, and use libdbi). > > 3/ > Somebody adapt perfparse (without libdbi) > > Ben releases 0.0.12 (with libdbi working with perfparse-install-db, perfgraph and > perfchart). > > > 0.0.13 will use libdbi everywhere except in perfparse. > > After that, depending on how we work, in 0.0.14 or after, we can have an optionnal > support of libdbi in perfparse, in order to see its performances. > > > > Some functions use mysql API. Please leave them as is. Write some other functions that > do the same so that we can still use mysql API. Some functions are shared between all > the perfparse tools ! > I think we will not need any #ifdef, and it's better that way. But I may be wrong :) > > >>All of this is dependent on getting reasonable performance using >>libdbi. If libdbi is unusable, I will scrap it in favor of writing code >>for each database. If it is usable but not as good as MySQL directly, >>we just might not ever make it to steps 3 and 4 above. >> >>Let me know how this sounds and I am anxiously awaiting the release of >>0.11. > > > Released already, at 16h today (well, is it really 16h ? All files are released at 16h :) > > Yves > > >>Chris >> >> >> >>------------------------------------------------------- >>This SF.Net email sponsored by Black Hat Briefings & Training. >>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >>digital self defense, top technical experts, no vendor pitches, >>unmatched networking opportunities. Visit www.blackhat.com >>_______________________________________________ >>Perfparse-devel mailing list >>Per...@li... >>https://lists.sourceforge.net/lists/listinfo/perfparse-devel >> >> > > > |
From: Yves M. <yme...@li...> - 2004-06-30 15:07:56
|
> Ben and Yves, > > Thanks for your warm responses. :) > > I agree that the lack of users listed on the libdbi website doesn't > look particularly promising however, I think it is probably the correct > direction to go, assuming that we don't run into performance issues > that require customized database code. A company that I work for, uses > the perl package DBI for all of our web applications that interface > with databases. I don't believe that DBI for perl and libdbi are > related except that they serve the same purpose for their respective > languages. This is the same reason I think we should give a try :) But there is one more check that I must do before we give it a try: It ha= s to compile on Solaris. Otherwise, why try to use it to port on other databases if you c= annot port it to other OSes ? For your information, I work on Solaris, and we have already had some peo= ple testing perfparse on FreeBSD (with no success/failure feedback) > > Based on an initial comparison of the MySQL code in PerfParse 0.10 and > the MySQL dbd module for libdbi, It doesn't look particularly difficult > to change from the current MySQL specific calls to libdbi calls. Has > the database interface code been changed significantly for 0.11? New numerotation: now 0.0.11 :) The database interface has not changed, but the table definitions will ch= ange a lot. Ben will send us a new mysql_create.sql file, then I work on all the tool= s to make them work with it. We still have some points to discuss about it, but it's nearly done. Will= probably be ready tomorrow (thursday). > I would like to propose the following plan of action: > 1. Produce a patch for 0.11 which enables a configuration option to use > libdbi in stead of direct MySQL code. (MySQL code is still default) > 2. Role the patch into the 0.12 release > 3. Down the road (0.13 or later), make libdbi the default and MySQL an > option. > 4. Much farther down the road, we can remove the MySQL option all > together (or not). I have some other idea, because we will be 3 (including you) to work on t= he whole code. And both Ben and me have no access to CVS (firewall...) 1/ I suggest that someone work on perfparse-install-db first. I can do it fa= st because I won't use libdbi. Then you take my patch to perfparse-install-db and move it to libdbi. 2/ I work on perfparse-purge-db (without libdbi) while you can already work = on perfgraph and perfchart (adaptation to the new table definitions, and use libdbi). 3/ Somebody adapt perfparse (without libdbi) Ben releases 0.0.12 (with libdbi working with perfparse-install-db, perfg= raph and perfchart). 0.0.13 will use libdbi everywhere except in perfparse. After that, depending on how we work, in 0.0.14 or after, we can have an = optionnal support of libdbi in perfparse, in order to see its performances. Some functions use mysql API. Please leave them as is. Write some other f= unctions that do the same so that we can still use mysql API. Some functions are shared= between all the perfparse tools ! I think we will not need any #ifdef, and it's better that way. But I may = be wrong :) > All of this is dependent on getting reasonable performance using > libdbi. If libdbi is unusable, I will scrap it in favor of writing code > for each database. If it is usable but not as good as MySQL directly, > we just might not ever make it to steps 3 and 4 above. > > Let me know how this sounds and I am anxiously awaiting the release of > 0.11. Released already, at 16h today (well, is it really 16h ? All files are re= leased at 16h :) Yves > > Chris > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > > --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - GTKtalog - http://www.nongnu.org/gtktalog/ - |
From: Chris D. <cdo...@cc...> - 2004-06-30 14:27:57
|
Ben and Yves, Thanks for your warm responses. I agree that the lack of users listed on the libdbi website doesn't look particularly promising however, I think it is probably the correct direction to go, assuming that we don't run into performance issues that require customized database code. A company that I work for, uses the perl package DBI for all of our web applications that interface with databases. I don't believe that DBI for perl and libdbi are related except that they serve the same purpose for their respective languages. Based on an initial comparison of the MySQL code in PerfParse 0.10 and the MySQL dbd module for libdbi, It doesn't look particularly difficult to change from the current MySQL specific calls to libdbi calls. Has the database interface code been changed significantly for 0.11? I would like to propose the following plan of action: 1. Produce a patch for 0.11 which enables a configuration option to use libdbi in stead of direct MySQL code. (MySQL code is still default) 2. Role the patch into the 0.12 release 3. Down the road (0.13 or later), make libdbi the default and MySQL an option. 4. Much farther down the road, we can remove the MySQL option all together (or not). All of this is dependent on getting reasonable performance using libdbi. If libdbi is unusable, I will scrap it in favor of writing code for each database. If it is usable but not as good as MySQL directly, we just might not ever make it to steps 3 and 4 above. Let me know how this sounds and I am anxiously awaiting the release of 0.11. Chris |
From: Ben C. <Be...@cl...> - 2004-06-30 08:33:46
|
Thanks Yves. Got to argue with you that the CGI speed is not so important. :) I cannot get more than about 20000 data samples out of perfparse because of speed problems :) Which is about a months data. Speed is vitally important here, and anything which limits this will be an unwelcome addition. I want to aim to be able to get 1 year time averages :) I made a comment about 'cursors'. MySQL does not have a binary cursor, which really effects performance. PostgreSQL, Oracle and others do. On the other hand, MySQL has a 'read-forward' cursor which adds great performance, which PostgreSQL does not have. I wonder whether libdbi can return the fastest cursor for the application, or defaults to a ASCII non-read-forward (slow) cursor. I also note that libdbi is not yet version 1.0.0. PerfParse has it's own very limited API, not always used, to abstract away from MySQL. See 'common.h' My own feeling would be that this should be developed to cater for all DBMSs, using the best cursor available, keeping everything in-house :) Ben Yves Mettier wrote: >>I have never heard of libdbi, I'll have to take a look. We do want >>support for PostgreSQL, Fireblade, Interbase and others. If this lib >>offers an easy way to do this, then all the better. But I do echo Yves >>comments that it may be better for the product to use the basic c API >>from Oracle. You will be able to take advantage of the abilities of the >>API's which a generic API might not have. Stability, speed, special >>cursors etc. > > > I'd like to explain some of my comments: > - for perfparse, aka the parser, we need speed, and we need to be sure that our > dependancies will be maintained forever (at least as longer as perfparse :) > If we discover a bug in a dependancy and there is nobody to maintain that dependancy, we > have to drop the dependancy. Here, I wonder if libdbi is a good choice. And perfparse is > a critical tool because if the user does not run it often, he can loose data in a too > big log file. > > - for the database tools and graph tools, we do not need that much speed. And if a bug > appear in a dependancy, the users can stop their tools for a while, before we fix the > bug or drop the dependancy. Those tools are less critical. > > - we need some abstract layer for databases to port perfparse on other databases, > whatever the layer is. It is often better not to reinvent the wheel when it exists. That > is the reason I like the idea to give a try to libdbi. I just regreet there is no > support for sybase. Chris, if you work with libdbi, maybe I'll try to contribute to > libdbi for the sybase port, in order to have the perfparse tools also work on sybase ! > > Well, for now, just wait 0.0.11. I expect that Ben and me manage to release it today :) > > Yves > |
From: Yves M. <yme...@li...> - 2004-06-30 08:16:08
|
> I have never heard of libdbi, I'll have to take a look. We do want > support for PostgreSQL, Fireblade, Interbase and others. If this lib > offers an easy way to do this, then all the better. But I do echo Yves > comments that it may be better for the product to use the basic c API > from Oracle. You will be able to take advantage of the abilities of th= e > API's which a generic API might not have. Stability, speed, special > cursors etc. I'd like to explain some of my comments: - for perfparse, aka the parser, we need speed, and we need to be sure th= at our dependancies will be maintained forever (at least as longer as perfparse = :) If we discover a bug in a dependancy and there is nobody to maintain that= dependancy, we have to drop the dependancy. Here, I wonder if libdbi is a good choice. A= nd perfparse is a critical tool because if the user does not run it often, he can loose d= ata in a too big log file. - for the database tools and graph tools, we do not need that much speed.= And if a bug appear in a dependancy, the users can stop their tools for a while, befor= e we fix the bug or drop the dependancy. Those tools are less critical. - we need some abstract layer for databases to port perfparse on other da= tabases, whatever the layer is. It is often better not to reinvent the wheel when = it exists. That is the reason I like the idea to give a try to libdbi. I just regreet the= re is no support for sybase. Chris, if you work with libdbi, maybe I'll try to con= tribute to libdbi for the sybase port, in order to have the perfparse tools also wor= k on sybase ! Well, for now, just wait 0.0.11. I expect that Ben and me manage to relea= se it today :) 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/ - - GTKtalog - http://www.nongnu.org/gtktalog/ - |
From: Ben C. <Be...@cl...> - 2004-06-30 07:19:42
|
Hi Chris, I am very excited about the possibility of porting to Oracle. It had always been an aim to support many DBMS platforms. Nobody has yet had a go at this, so you are welcome to have a go. I have never heard of libdbi, I'll have to take a look. We do want support for PostgreSQL, Fireblade, Interbase and others. If this lib offers an easy way to do this, then all the better. But I do echo Yves comments that it may be better for the product to use the basic c API from Oracle. You will be able to take advantage of the abilities of the API's which a generic API might not have. Stability, speed, special cursors etc. We are tying to release version 0.0.11 at the moment. I would not advise any work until then. However, you may want to have a look at the current code and judge how much of an effort this will be. If you do choose to work with us, you will of course be credited as an author and developer in all the usual places. Kind regards, Ben You Chris Donovan wrote: > Greetings, > > I am looking at using PerfParse with Nagios but I would rather store the > data in an Oracle database instead of MySQL. Is there anybody that is > already working on this? Also, is there any reason not to use libdbi so > that the PerfParse code is database independent? > > I'm more then willing to write the code for this, I just want to make > sure that I'm not duplicating someone else's efforts or missing a > fundamental problem with using libdbi. Thanks. > > Chris Donovan > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > |
From: Yves M. <yme...@li...> - 2004-06-29 17:28:39
|
> Greetings, > > I am looking at using PerfParse with Nagios but I would rather store > the data in an Oracle database instead of MySQL. Is there anybody that > is already working on this? Also, is there any reason not to use libdbi > so that the PerfParse code is database independent? I've never heard of libdbi. I'll have a look on http://libdbi.sourceforge= .net/. Do you know other projects that use libdbi ? Is it a stable project ? http://libdbi.sourceforge.net/users.php does not make it very relyable :( > I'm more then willing to write the code for this, I just want to make > sure that I'm not duplicating someone else's efforts or missing a > fundamental problem with using libdbi. Thanks. I've not heard anyone working on this. If Ben answers like me, I suggest = that you give a try. Because of speed considerations and network load, maybe it's better to ha= ve perfparse use a native support of databases. But for all the other tools, there are= not such considerations and libdbi should fit. Maybe I'm wrong. That's why I suggest that you try the way you like. Ben should release perfparse-0.0.11 soon with major changes in the code. = Maybe we can talk before 0.0.11 is released, and work on 0.0.11 instead of 0.10 ? Yves > > Chris Donovan > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > > --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - GTKtalog - http://www.nongnu.org/gtktalog/ - |
From: Chris D. <cdo...@cc...> - 2004-06-29 12:14:45
|
Greetings, I am looking at using PerfParse with Nagios but I would rather store the data in an Oracle database instead of MySQL. Is there anybody that is already working on this? Also, is there any reason not to use libdbi so that the PerfParse code is database independent? I'm more then willing to write the code for this, I just want to make sure that I'm not duplicating someone else's efforts or missing a fundamental problem with using libdbi. Thanks. Chris Donovan |
From: Ben C. <Be...@cl...> - 2004-06-21 09:40:43
|
Andreas, I totally agree. A socket feeding PerfParse would be excellent. For all the reasons you list. I believe that this is in the pipe (no pun intended) for Nagios 2.0. At which time my self and the other PerfParse developers will work 24x7 to make this work :) However, the current method, apart for the 10 minute delay (depending on your cron) works without a major load increase. The load on my system by just the 'perfparse' parser component is not massive. Other work in the next few versions will ensure this load is lessened by moving daily administrative functions to a nightly on-shot. I note your comment about the alternate status display. You can see the start of this in the current version. Which I use as it's faster than the Nagios status display. At least in Nagios 1.2. This will be developed further including easy to use filters and alternate displays. (Possible a Java Bean app as well for instant refresh of changing data at lower load the HTML.) However, having two systems, with two databases, two displays, seems pointless. Accept that PerfParse gives access to all plugin output intrinsically, not just the current. PerfParse is *not* being developed as a replacement to Nagios GUI :) Ben. Andreas Ericsson wrote: > Ben Clewett wrote: > >> Nagios only needs to open *one* file for PerfParse to work. This file >> is help open permanently. (serviceperf.log) The 256 limit per >> process is unlikely to be of any relevance. >> > > If it could open a socket instead, wouldn't that increase performance > and usability by about a zillion times? > * Perfparse could have a single persistent connection to mysql. > * Changes would be visible instantly. > * Less filethrashing. > * No need for exotic filetruncing log-rotation with risks of data-loss. > * No need to set up cron-jobs. > * Nagios still wouldn't have to fork. > * In time, perfparse could well act as a statusdb engine for the nagios > GUI, making it always display the results of the last check (this > requires nagios to forward the entire output message along with relevant > host/service info though, but I hardly think that can be a serious > coding problem). > > Just thinking out loud... > > --[ snip ]--- > >> >> Regards, Ben. >> > |
From: Yves M. <yme...@li...> - 2004-06-17 19:00:26
|
> Garry, Yves, > > At the moment, if we submit patches against a common version to my self= , > I'll keep them, add them and forward them on through the perfparse-deve= l > news group. Taking Yves lead on this, making a patch from the > previously released version against your version, rather than against > any increment. And using the same news group to ensure we are not > editing exactly the same code. Lets see if it can work... > > I like RCS, but not Internet friendly. CVS might have to come one day > when we have hundreds of developers, but since 66.6% of the developers > currently have problems accessing CVS, it might have to wait :) When there are 2 developers who can use CVS, CVS is really necessary. Beg= in to learn it and you will understand that CVS is not for 33,4% developers, but just fo= r you :) I don't insist on using CVS because at my work, I cannot use it because o= f the firewall. But if you both can use it, just learn and use it (and forget the 66,6% w= ho should learn too :) > I am planning to install a Linux box on my home DMZ, as soon as I have > built my home DMZ :) Which we could use for direct ftp in combination > with RCS, but that feels like that might be a bit complex.... RCS is old now :) CVS is the new one. And CVS is old too: some use subversion or arch now. At Sourceforge, there is only CVS, that's why you should use CVS :) Arch looks good. Subversion seems to be just a new CVS with less implemen= tation mistakes. > Garry, did you have any luck with the JavaScript version of perfgraph, > and prototyping using other CGI controls? > > Whilst I am talking to you both, > > In the previous version we had a name change of the installed programs. > 'perfgraph.cgi' -> 'perfgraph' and 'perfchart.png' -> 'perfchart'. > Which was probably a mistake on my part for not noticing it, and has > annoyed several users who couldn't find the new files :) Ben, About perfchart.png, I sent you a patch. I consider this as a big bug, be= cause perfgraph cannot be used. About perfgraph.cgi, I told you how to do it. Have you tried yet ? Does i= t work ? If yes, is it possible that I work on Monday on a new version, or do you = prefer to send me the latest patch ? If no, send me the latest patch and I will do the change. > In the next version I think we should go back to the original format, > and I'll put a very clear comment (and apology from me) in the README := ) Same for me :) > Yves, I've not yet had time to put groups in, but have planned the work= . > I should think I'll have time tomorrow. \o/ > Right now there is an England soccer game I just can't miss :) Seems the English won :) 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/ - - GTKtalog - http://www.nongnu.org/gtktalog/ - |
From: Cook, G. <GW...@ma...> - 2004-06-17 15:26:43
|
U291bmRzIGdvb2QgdG8gbWUuIEkgZGlkbid0IGtub3cgdGhhdCBzbyBtYW55IHBlb3BsZSBoYWQg dHJvdWJsZSB1c2luZyBDVlMuDQogDQpJIHdvcmtlZCBvbiB0aGUgamF2YXNjcmlwdC9jZ2kgY29u dHJvbHMgbW9zdCBvZiB0aGUgZGF5IHllc3RlcmRheSwgYW5kIHdpbGwgY29udGludWUgdG8gZG8g c28gdG9kYXkuIFRoZSBtYWluIHBvcnRpb24gZ2l2aW5nIG1lIHRyb3VibGUgaXMgdGhlIGNhbGVu ZGFyIHBvcC11cC4gSXQgd29ya3MgZ3JlYXQgb24gbXkgdGVzdCBwYWdlLCBidXQgdHJ5aW5nIHRv IGdldCBpdCB0byB3b3JrIGZyb20gdGhlIGNnaSBhZnRlciBhZGRpbmcgaXQgdG8gcGVyZmdyYXBo LmMgaXMgZGlmZmljdWx0LiBBcyBJIHNhaWQsIEknbGwga2VlcCB3b3JraW5nIG9uIGl0LCBidXQg SSBuZWVkIHRvIGhhdmUgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvZiBob3cgdGhlIGNnaSBjcmVh dGVkIHdlYiBwYWdlIHJlZmVyZW5jZXMgZGlyZWN0b3JpZXMgaW4gbmFnaW9zL3NoYXJlLiBJZiB5 b3UgY2FuIHByb3ZpZGUgYW55IGluc2lnaHQgaW50byB0aGlzLCBvciBhIHBvaW50ZXIgdG8gZG9j dW1lbnRhdGlvbiwgdGhhdCBtaWdodCBoZWxwIHNwZWVkIHVwIHRoZSBwcm9jZXNzLg0KIA0KSSB3 b3VsZCBkZWZpbml0ZWx5IGdvIGJhY2sgdG8gdGhlIG9yaWdpbmFsIHZlcnNpb25zIHdpdGggLmNn aSBleHRlbnNpb25zLiBZb3UgbWlnaHQgYWxzbyB3YW50IHRvIGFkZCBhIG1lc3NhZ2UgdG8gdGhl IHVzZXIgbGlzdCB3ZWxjb21lIGVtYWlsLCB0byB3YXJuIG5ldyB1c2VycyB1bnRpbCB0aGUgbmV4 dCB2ZXJzaW9uIGlzIHJlbGVhc2VkLiBFaXRoZXIgdGhhdCwgb3IgcmVsZWFzZSB2ZXJzaW9uIDAu MDkgdG8ganVzdCBjb3JyZWN0IHRoaXMgaXNzdWUuDQogDQotZw0KDQoJLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0gDQoJRnJvbTogQmVuIENsZXdldHQgW21haWx0bzpCZW5AY2xld2V0dC5vcmcu dWtdIA0KCVNlbnQ6IFRodSA2LzE3LzIwMDQgOToxOCBBTSANCglUbzogQ29vaywgR2FycnkgDQoJ Q2M6IFl2ZXMgTWV0dGllcjsgcGVyZnBhcnNlLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCAN CglTdWJqZWN0OiBSZTogV29ya2luZyBvbiBQZXJmUGFyc2Ugc3R1ZmYuLi4NCgkNCgkNCg0KCUdh cnJ5LCBZdmVzLA0KCQ0KCUF0IHRoZSBtb21lbnQsIGlmIHdlIHN1Ym1pdCBwYXRjaGVzIGFnYWlu c3QgYSBjb21tb24gdmVyc2lvbiB0byBteSBzZWxmLA0KCUknbGwga2VlcCB0aGVtLCBhZGQgdGhl bSBhbmQgZm9yd2FyZCB0aGVtIG9uIHRocm91Z2ggdGhlIHBlcmZwYXJzZS1kZXZlbA0KCW5ld3Mg Z3JvdXAuICBUYWtpbmcgWXZlcyBsZWFkIG9uIHRoaXMsIG1ha2luZyBhIHBhdGNoIGZyb20gdGhl DQoJcHJldmlvdXNseSByZWxlYXNlZCB2ZXJzaW9uIGFnYWluc3QgeW91ciB2ZXJzaW9uLCByYXRo ZXIgdGhhbiBhZ2FpbnN0DQoJYW55IGluY3JlbWVudC4gIEFuZCB1c2luZyB0aGUgc2FtZSBuZXdz IGdyb3VwIHRvIGVuc3VyZSB3ZSBhcmUgbm90DQoJZWRpdGluZyBleGFjdGx5IHRoZSBzYW1lIGNv ZGUuICBMZXRzIHNlZSBpZiBpdCBjYW4gd29yay4uLg0KCQ0KCUkgbGlrZSBSQ1MsIGJ1dCBub3Qg SW50ZXJuZXQgZnJpZW5kbHkuICBDVlMgbWlnaHQgaGF2ZSB0byBjb21lIG9uZSBkYXkNCgl3aGVu IHdlIGhhdmUgaHVuZHJlZHMgb2YgZGV2ZWxvcGVycywgYnV0IHNpbmNlIDY2LjYlIG9mIHRoZSBk ZXZlbG9wZXJzDQoJY3VycmVudGx5IGhhdmUgcHJvYmxlbXMgYWNjZXNzaW5nIENWUywgaXQgbWln aHQgaGF2ZSB0byB3YWl0IDopDQoJDQoJSSBhbSBwbGFubmluZyB0byBpbnN0YWxsIGEgTGludXgg Ym94IG9uIG15IGhvbWUgRE1aLCBhcyBzb29uIGFzIEkgaGF2ZQ0KCWJ1aWx0IG15IGhvbWUgRE1a IDopICBXaGljaCB3ZSBjb3VsZCB1c2UgZm9yIGRpcmVjdCBmdHAgaW4gY29tYmluYXRpb24NCgl3 aXRoIFJDUywgYnV0IHRoYXQgZmVlbHMgbGlrZSB0aGF0IG1pZ2h0IGJlIGEgYml0IGNvbXBsZXgu Li4uDQoJDQoJR2FycnksIGRpZCB5b3UgaGF2ZSBhbnkgbHVjayB3aXRoIHRoZSBKYXZhU2NyaXB0 IHZlcnNpb24gb2YgcGVyZmdyYXBoLA0KCWFuZCBwcm90b3R5cGluZyB1c2luZyBvdGhlciBDR0kg Y29udHJvbHM/DQoJDQoJV2hpbHN0IEkgYW0gdGFsa2luZyB0byB5b3UgYm90aCwNCgkNCglJbiB0 aGUgcHJldmlvdXMgdmVyc2lvbiB3ZSBoYWQgYSBuYW1lIGNoYW5nZSBvZiB0aGUgaW5zdGFsbGVk IHByb2dyYW1zLg0KCSAgJ3BlcmZncmFwaC5jZ2knIC0+ICdwZXJmZ3JhcGgnIGFuZCAncGVyZmNo YXJ0LnBuZycgLT4gJ3BlcmZjaGFydCcuDQoJV2hpY2ggd2FzIHByb2JhYmx5IGEgbWlzdGFrZSBv biBteSBwYXJ0IGZvciBub3Qgbm90aWNpbmcgaXQsIGFuZCBoYXMNCglhbm5veWVkIHNldmVyYWwg dXNlcnMgd2hvIGNvdWxkbid0IGZpbmQgdGhlIG5ldyBmaWxlcyA6KQ0KCQ0KCUluIHRoZSBuZXh0 IHZlcnNpb24gSSB0aGluayB3ZSBzaG91bGQgZ28gYmFjayB0byB0aGUgb3JpZ2luYWwgZm9ybWF0 LA0KCWFuZCBJJ2xsIHB1dCBhIHZlcnkgY2xlYXIgY29tbWVudCAoYW5kIGFwb2xvZ3kgZnJvbSBt ZSkgaW4gdGhlIFJFQURNRSA6KQ0KCQ0KCVl2ZXMsIEkndmUgbm90IHlldCBoYWQgdGltZSB0byBw dXQgZ3JvdXBzIGluLCBidXQgaGF2ZSBwbGFubmVkIHRoZSB3b3JrLg0KCSAgSSBzaG91bGQgdGhp bmsgSSdsbCBoYXZlIHRpbWUgdG9tb3Jyb3cuDQoJDQoJUmlnaHQgbm93IHRoZXJlIGlzIGFuIEVu Z2xhbmQgc29jY2VyIGdhbWUgSSBqdXN0IGNhbid0IG1pc3MgOikNCgkNCglSZWdhcmRzIHRvIHlv dSBib3RoLCBCZW4NCgkNCgkNCgkNCglDb29rLCBHYXJyeSB3cm90ZToNCgkNCgk+ICA+PiBJIHRo aW5rIHRoYXQgd2Ugc2hvdWxkIGFsbCBqb2luIHRoZSBwcC1kZXYgbWFpbGluZyBsaXN0LCBpZiB3 ZSBoYXZlbid0DQoJPiAgPj4gZG9uZSBzbyBhbHJlYWR5LCBhbmQgc3RhcnQgcG9zdGluZyB0aGVy ZSBpbiBjYXNlIGFueW9uZSBlbHNlIHdvdWxkDQoJPiAgPj4gZGVjaWRlIHRvIGxlbmQgYSBoYW5k LiBJIHRoaW5rIHRoYXQgd2l0aCB0aGUgUFAgcXVlc3Rpb25zIGJlaW5nIHBvc3RlZA0KCT4gID4+ IHRvIHRoZSBOYWdpb3MgbGlzdCwgeW91J2xsIHByb2JhYmx5IHNlZSBpbnRlcmVzdCBpbiB0aGUg cHJvamVjdCBzdGFydCB0bw0KCT4gID4+IHJpc2UgcmVhbGx5IHF1aWNrbHkgaW4gdGhlIG5leHQg ZmV3IGRheXMvd2Vla3MsIHdoaWNoIHNob3VsZCBsZWFkIHRvDQoJPiAgPj4gbW9yZSBvZmZlcnMg Zm9yIGFzc2lzdGFuY2UuIFRoZXJlZm9yZSwgQ1ZTIGltcGxlbnRhdGlvbiBtaWdodCBiZSBhIGdv b2QNCgk+ICA+PiBpZGVhIGFzIHdlbGwuDQoJPiAgPg0KCT4gID5JIGFscmVhZHkgdGFsa2VkIHdp dGggQmVuIGFib3V0IENWUzogaGUgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8gQ1ZTLg0KCT4gTmV0 aGVyIGRvIEkuIEhvdw0KCT4gID5hbmQgd2hvIHdvdWxkIGRvIGl0IGZyZXF1ZW50bHkgPw0KCT4g ID4NCgk+ICA+WXZlcw0KCT4gV2VsbCwgSSBkb24ndCByZWFsbHkga25vdyB0aGF0IG11Y2ggYWJv dXQgQ1ZTLCBJJ3ZlIHVzZWQgYW4gP1JDUz8NCgk+IHJlcG9zaXRvcnkgb24gbXkgYm94LCB3aXRo IGVtYWNzLCB3aGVuIHdvcmtpbmcgb24gc29tZSBwbHVnaW5zLiBJIGRvDQoJPiB0aGlzIGp1c3Qg dG8gbWFrZSBzdXJlIHRoYXQgSSBkb24ndCBoYXZlIDEwIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBh DQoJPiBzaW5nbGUgZmlsZSwgZWFjaCB3aXRoIGEgZGlmZmVyZW50IG5hbWUgdGhhdCB0cmllcyB0 byBiZSBkZXNjcmlwdGl2ZS4gSQ0KCT4gZmlndXJlZCB0aGF0IHlvdSBndXlzIHdvdWxkIGtub3cg bW9yZSBhYm91dCBDVlMgdGhhbiBJLg0KCT4gDQoJPiBUaGVyZSBpcyBDVlMgYWNjZXNzIHNldHVw IG9uIHRoZSBwZXJmcGFyc2UgYXJlYSBvZiBzb3VyY2Vmb3JnZS5uZXQuIElmDQoJPiB3ZSB3ZXJl IHRvIHVzZSB0aGlzLCBpdCB3b3VsZCBhbGxvdyB1cyB0byB3b3JrIG9uIGNvZGUgc2ltdXRhbmVv dXNseSwNCgk+IHdoaWxlIG5vdCBoYXZpbmcgdG8gd29ycnkgYWJvdXQgZGl2ZXJnaW5nIGNvcGll cyBvZiBmaWxlcy4gQWxzbywNCgk+IGl0IHdvdWxkIGFsbG93IHVzZXJzIHRvIHRlc3QgdGhlIGNv ZGUgYmVmb3JlIHRoZSBuZXh0IHJlbGVhc2UsIGFuZA0KCT4gcHJvdmlkZSB1cyBmZWVkYmFjayBi ZWZvcmUgcmVsZWFzaW5nLg0KCT4gDQoJPiBKdXN0IGEgdGhvdWdodC4gSWYgeW91IGd1eXMgZG9u J3Qgd2FudCB0byB1c2UgQ1ZTLCB0aGVuIHdlIGRvbid0IGhhdmUNCgk+IHRvLiBCdXQgaWYgYW55 b25lIGVsc2Ugd2lzaGVzIHRvIGhlbHAgd2l0aCBkZXZlbG9wbWVudCwgaXQgbWF5IGJlY29tZQ0K CT4gbWVzc3kgd2l0aG91dCBpdCwgZXNwZWNpYWxseSBpZiBtb3JlIHRoYW4gMSBvciAyIHBlb3Bs ZSB3ZXJlIHRvIHZvbHVudGVlci4NCgk+IA0KCT4gLWcNCgk+DQoJDQoJDQoNCg== |
From: Ben C. <Be...@cl...> - 2004-06-17 15:17:01
|
Garry, Yves, At the moment, if we submit patches against a common version to my self, I'll keep them, add them and forward them on through the perfparse-devel news group. Taking Yves lead on this, making a patch from the previously released version against your version, rather than against any increment. And using the same news group to ensure we are not editing exactly the same code. Lets see if it can work... I like RCS, but not Internet friendly. CVS might have to come one day when we have hundreds of developers, but since 66.6% of the developers currently have problems accessing CVS, it might have to wait :) I am planning to install a Linux box on my home DMZ, as soon as I have built my home DMZ :) Which we could use for direct ftp in combination with RCS, but that feels like that might be a bit complex.... Garry, did you have any luck with the JavaScript version of perfgraph, and prototyping using other CGI controls? Whilst I am talking to you both, In the previous version we had a name change of the installed programs. 'perfgraph.cgi' -> 'perfgraph' and 'perfchart.png' -> 'perfchart'. Which was probably a mistake on my part for not noticing it, and has annoyed several users who couldn't find the new files :) In the next version I think we should go back to the original format, and I'll put a very clear comment (and apology from me) in the README :) Yves, I've not yet had time to put groups in, but have planned the work. I should think I'll have time tomorrow. Right now there is an England soccer game I just can't miss :) Regards to you both, Ben Cook, Garry wrote: > >> I think that we should all join the pp-dev mailing list, if we haven't > >> done so already, and start posting there in case anyone else would > >> decide to lend a hand. I think that with the PP questions being posted > >> to the Nagios list, you'll probably see interest in the project start to > >> rise really quickly in the next few days/weeks, which should lead to > >> more offers for assistance. Therefore, CVS implentation might be a good > >> idea as well. > > > >I already talked with Ben about CVS: he does not have access to CVS. > Nether do I. How > >and who would do it frequently ? > > > >Yves > Well, I don't really know that much about CVS, I've used an ?RCS? > repository on my box, with emacs, when working on some plugins. I do > this just to make sure that I don't have 10 different versions of a > single file, each with a different name that tries to be descriptive. I > figured that you guys would know more about CVS than I. > > There is CVS access setup on the perfparse area of sourceforge.net. If > we were to use this, it would allow us to work on code simutaneously, > while not having to worry about diverging copies of files. Also, > it would allow users to test the code before the next release, and > provide us feedback before releasing. > > Just a thought. If you guys don't want to use CVS, then we don't have > to. But if anyone else wishes to help with development, it may become > messy without it, especially if more than 1 or 2 people were to volunteer. > > -g > |
From: Ben C. <Be...@cl...> - 2004-06-16 08:33:26
|
Garry, I saw your bug report, can you try the new version enclosed. This does not have your alterations in it, so keep your copy! Please let me know if this works. Cook, Garry wrote: >>I think you mentioned having a calender to select the dates >>for absolute >>time? Which sounds a good idea. I will have to find a open >>source once >>somewhere, less haste than writing one. >> > > Yes, I did indeed mention that. I'll look into it as well, see what I > can dig up. See what you can get... There are lots around, the license is the biggest problem. I am sure somewhere there is a free or GPL version. Would be a great addition. At this time, we can break the date/time for absolute into date and time. > Once you tab to the drop down list, ALT-DOWNARROW will open it up and > allow you to scroll through the options. I also prefer keyboard to > mouse, but hate having to type lots of numbers, especially if they need > a ':' separator. I always fat-finger the numbers. We can see how it works :) Can you do a mock-up of the entire screen with mouse controls? The 'host' and 'service' you can ignore. These can be replaced by <input type=hidden ... > tags, and a description at the top explaining which host/service we are looking at. > I won't pretend to understand that yet. But perhaps if I look at the > code... I'll see what I can do. Just use two where there was one. In the getCGI() you will, after getting the two variables, remake the original: sprintf(sRelativeTime, "%s:%s", sRelativeHours, sRelativeMinutes) You may want to give just a few time options, maybe 00, 15, 30 and 45. Beyond that the graph doesn't display well, and is pretty meaningless. The same for the absolute if you want a challange :) All the best, Ben |
From: Cook, G. <GW...@ma...> - 2004-06-15 19:47:14
|
Ben Clewett wrote: > Garry, >=20 > I have CC'd this to the development list. As you say, we should, and > this is an OSS project, so it's good practice. :) >=20 Hehe, I should practice what I preach. OK, just wasn't sure if anyone was really using the del list yet. Posting to the list from this point forward... > Cook, Garry wrote: >=20 >> Looking at this again, I think that you pretty much covered all of >> the items that I listed in that single feature request. I'll check >> again and submit new single requests if necessary. >=20 > I think you mentioned having a calender to select the dates > for absolute > time? Which sounds a good idea. I will have to find a open > source once > somewhere, less haste than writing one. >=20 Yes, I did indeed mention that. I'll look into it as well, see what I can dig up. >> I changed the code of perfgraph.c somewhat, to make a drop down list >> for the relative period 'Days'. This will allow me to choose from >> one to thirty days. I figure that if I need more than that, I can >> use the absolute period. You may not want to limit your users to >> only 30 days in the relative period, but if so, newfile is attached. >> I called it perfgraph1.c so as not to confuse it with your original. >> I should have just made a diff, next time I will. >=20 > Nice option. I am more of a keyboard person my self, using > TAB to move > from field. Which does make using a large SELECT box > difficult. But I > am open to opinion on this matter, if people want it this way > then this > can very quickly make it into the code. Thanks for the attachment, > looks OK to me :)=20 >=20 Once you tab to the drop down list, ALT-DOWNARROW will open it up and allow you to scroll through the options. I also prefer keyboard to mouse, but hate having to type lots of numbers, especially if they need a ':' separator. I always fat-finger the numbers. >> I wanted to do the same thing with HH:MM as well, but this would >> require two drop down lists to be merged into one value. Don't yet >> know if this is possible... But I was thinking HH 00-23 and MM 00, >> 05, 10... That way the MM list would be only 20 choices. >=20 > If you pass them separately, use two CGI variables. > Recombine them in > the getCGI() and it will work. See what it looks like, but I > would be > worried that it might make the page slower to use, unless all > variables can be made to work with just the pointer... > I won't pretend to understand that yet. But perhaps if I look at the code... I'll see what I can do. Garry W. Cook, CCNA Network Infrastructure Manager MACTEC, Inc. - http://www.mactec.com/ 303.308.6228 (Office) - 720.220.1862 (Mobile) |
From: Jon L. <jly...@ya...> - 2004-06-15 17:24:36
|
Yep, 99% of my checks are with the check_ping plugin, allthough check_ifstatus does reports the performance numbers, but doesn't show up in the graphs... Just spent the entire day trying to fix my MYsql client so I can try this and none of my checks are supported yet....ARGH! --- "Cook, Garry" <GW...@ma...> wrote: > Jon Lyons wrote: > > Ok, I finally got PerfParse installed and running, > but > > only 6 hosts out of 200 are being displayed with __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
From: Cook, G. <GW...@ma...> - 2004-06-15 16:38:53
|
Jon Lyons wrote: > Ok, I finally got PerfParse installed and running, but > only 6 hosts out of 200 are being displayed with > graphs, I've updated to the latest plugings, and I can > see all hosts in the view raw data section(see below), > also perfparse is running very very slow. I've run the > perfpase scripts many times, but only the 6 hosts are > displayed, all my hosts have ping defined as a > service.. >=20 [snip] Perhaps someone else can explain this in greater detail, but from looking at my setup, the raw data seems to show exactly what the plugins would 'normally' show - host, service, status, check time, and output. There does not appear to be any Performance Data listed here. Perhaps if the perfdata was also included in the rawdata table we could easily see which plugins support perfdata and which do not. I think that the 6 hosts that you have graphs for are the only ones being checked by plugins that support perfdata. If in doubt about a plugin, run it from the command line and see if there is a pipe and perfdata returned after the normal output. I'm fairly sure that the check_ping does not yet have support for perfdata enabled, but my plugins are from CVS about two weeks ago, so that could have changed.=20 Garry W. Cook, CCNA Network Infrastructure Manager MACTEC, Inc. - http://www.mactec.com/ 303.308.6228 (Office) - 720.220.1862 (Mobile) |
From: Ben C. <Be...@cl...> - 2004-06-15 16:08:45
|
Jon, Can you manually run one of the plugins which does not produce a graph. This should produce performance data after the '|'. For example: DISK OK - free space: /boot 35 MB (76%);| /boot=34MB;35;40;0;45 If you do not have any data, or a '|', then you may need to try the latest snapshot from http://nagiosplug.sourceforge.net, which at time of writing I see are: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-HEAD-200406150514.tar.gz If this is not the case, please let me know. Regards, Ben. Jon Lyons wrote: > Ok, I finally got PerfParse installed and running, but > only 6 hosts out of 200 are being displayed with > graphs, I've updated to the latest plugings, and I can > see all hosts in the view raw data section(see below), > also perfparse is running very very slow. I've run the > perfpase scripts many times, but only the 6 hosts are > displayed, all my hosts have ping defined as a > service.. > > 190-Waukegan-Rd PING UP 2004-06-15 > 15:48:18 PING OK - Packet loss = 0%, RTA = 9.81 ms > > 400-McHenry-Rd PING UP 2004-06-15 15:48:18 > PING OK - Packet loss = 0%, RTA = 9.95 ms > Nordstrom PING UP 2004-06-15 15:48:18 > PING OK - Packet loss = 0%, RTA = 9.06 ms > Wellness-Park-Center PING UP 2004-06-15 > 15:48:28 PING OK - Packet loss = 0%, RTA = 9.93 ms > > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > |
From: Jon L. <jly...@ya...> - 2004-06-15 16:00:20
|
Ok, I finally got PerfParse installed and running, but only 6 hosts out of 200 are being displayed with graphs, I've updated to the latest plugings, and I can see all hosts in the view raw data section(see below), also perfparse is running very very slow. I've run the perfpase scripts many times, but only the 6 hosts are displayed, all my hosts have ping defined as a service.. 190-Waukegan-Rd PING UP 2004-06-15 15:48:18 PING OK - Packet loss = 0%, RTA = 9.81 ms 400-McHenry-Rd PING UP 2004-06-15 15:48:18 PING OK - Packet loss = 0%, RTA = 9.95 ms Nordstrom PING UP 2004-06-15 15:48:18 PING OK - Packet loss = 0%, RTA = 9.06 ms Wellness-Park-Center PING UP 2004-06-15 15:48:28 PING OK - Packet loss = 0%, RTA = 9.93 ms __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Cook, G. <GW...@ma...> - 2004-06-14 16:38:56
|
nag...@li... wrote: > Is anyone using perfparse? I've compiled the apps and > created the MySQL database but I get this error when I > execute perfparse, not sure where to look.. >=20 > nagios-new# /usr/local/bin/perfparse -n 40 -r > "SELECT file_name, line_in_file, last_line_hash, pid, > file_name FROM perfdata_state WHERE domain =3D > '03B6BA87'" failed: > Lost connection to MySQL server during query >=20 >=20 > nagios-new# /usr/local/bin/perfparse --show_config > sDBUser: 'nagios' > sDBName: 'nagios' > sDBPass: 'nagios' > sDBHost: '10.128.16.17' > sDropFile: '/tmp/perfparse.drop' > sServiceLogFile: '/var/spool/nagios/serviceperf.log' > sHostLogFile: '/var/spool/nagios/hostperf.log' >=20 There are a few people using it so far. It works great on my site. I must admit that I had some trouble setting it up at first, but Ben Clewett was really helpful in troubleshooting. I've been working on a How-To for the project, and Yves Mettier has contributed quite a bit to the latest version (v.0.08), which should be much easier for folks to implement.=20 From the project page at http://sourceforge.net/projects/perfparse you can find a link to the Mailing Lists. You should join perfparse-users and post your questions there. When you do repost your question to the other list, it would be best to include the versions that you are running for Nagios, Nagios Plugins, PerfParse, and MySQL. Garry W. Cook, CCNA Network Infrastructure Manager MACTEC, Inc. - http://www.mactec.com/ 303.308.6228 (Office) - 720.220.1862 (Mobile) |
From: Jon L. <jly...@ya...> - 2004-06-14 14:37:04
|
Is anyone using perfparse? I've compiled the apps and created the MySQL database but I get this error when I execute perfparse, not sure where to look.. nagios-new# /usr/local/bin/perfparse -n 40 -r "SELECT file_name, line_in_file, last_line_hash, pid, file_name FROM perfdata_state WHERE domain = '03B6BA87'" failed: Lost connection to MySQL server during query nagios-new# /usr/local/bin/perfparse --show_config sDBUser: 'nagios' sDBName: 'nagios' sDBPass: 'nagios' sDBHost: '10.128.16.17' sDropFile: '/tmp/perfparse.drop' sServiceLogFile: '/var/spool/nagios/serviceperf.log' sHostLogFile: '/var/spool/nagios/hostperf.log' __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Jon L. <jly...@ya...> - 2004-06-14 14:36:54
|
Is anyone using perfparse? I've compiled the apps and created the MySQL database but I get this error when I execute perfparse, not sure where to look.. nagios-new# /usr/local/bin/perfparse -n 40 -r "SELECT file_name, line_in_file, last_line_hash, pid, file_name FROM perfdata_state WHERE domain = '03B6BA87'" failed: Lost connection to MySQL server during query nagios-new# /usr/local/bin/perfparse --show_config sDBUser: 'nagios' sDBName: 'nagios' sDBPass: 'nagios' sDBHost: '10.128.16.17' sDropFile: '/tmp/perfparse.drop' sServiceLogFile: '/var/spool/nagios/serviceperf.log' sHostLogFile: '/var/spool/nagios/hostperf.log' __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |