perfparse-devel — Development Issues

[Perfparse-devel] PerfParse

[Ben C. <Be...@cl...>]

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

Re: [Perfparse-devel] libdbi

[Chris D. <cdo...@cc...>]

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
>>>
>>>
>

Re: [Perfparse-devel] libdbi

[Ben C. <Be...@cl...>]

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
>>
>>
> 
> 
> 

Re: [Perfparse-devel] libdbi

[Yves M. <yme...@li...>]

> 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/                    -

Re: [Perfparse-devel] libdbi

[Chris D. <cdo...@cc...>]

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

Re: [Perfparse-devel] libdbi

[Ben C. <Be...@cl...>]

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
> 

Re: [Perfparse-devel] libdbi

[Yves M. <yme...@li...>]

> 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/                    -

Re: [Perfparse-devel] libdbi

[Ben C. <Be...@cl...>]

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
> 

Re: [Perfparse-devel] libdbi

[Yves M. <yme...@li...>]

> 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/                    -

[Perfparse-devel] libdbi

[Chris D. <cdo...@cc...>]

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

[Perfparse-devel] Re: Antwort: Re: [Nagios-users] Perf-Problem - Not more than 255 Childs?

[Ben C. <Be...@cl...>]

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.
>>
> 

[Perfparse-devel] Re: Working on PerfParse stuff...

[Yves M. <yme...@li...>]

> 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/                    -

[Perfparse-devel] RE: Working on PerfParse stuff...

[Cook, G. <GW...@ma...>]

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==

[Perfparse-devel] Re: Working on PerfParse stuff...

[Ben C. <Be...@cl...>]

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 
> 

Re: [Perfparse-devel] RE: Working on PerfParse stuff...

[Ben C. <Be...@cl...>]

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

[Perfparse-devel] RE: Working on PerfParse stuff...

[Cook, G. <GW...@ma...>]

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)

[Perfparse-devel] RE: [Nagios-users] PerfParse Help?

[Jon L. <jly...@ya...>]

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

[Perfparse-devel] RE: [Nagios-users] PerfParse Help?

[Cook, G. <GW...@ma...>]

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)

Re: [Perfparse-devel] RE: [Nagios-users] PerfParse Help?

[Ben C. <Be...@cl...>]

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
> 

[Perfparse-devel] RE: [Nagios-users] PerfParse Help?

[Jon L. <jly...@ya...>]

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 

[Perfparse-devel] RE: [Nagios-users] PerfParse Help?

[Cook, G. <GW...@ma...>]

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)

[Perfparse-devel] PerfParse Help?

[Jon L. <jly...@ya...>]

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/ 

[Perfparse-devel] PerfParse Help?

[Jon L. <jly...@ya...>]

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/