Menu
▾
▴
perfparse-devel-int — Developers Internal high traffic discussion PP development. Contributers only.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(19) |
Dec
(72) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(35) |
Feb
(36) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Yves M. <yme...@li...> - 2004-12-29 16:56:46
|
> Please edit libpp_mysql/dbms.c > > Near the top please add: > > #include <locale.h> > > Then after line 227 in function now_connect please add: > > setlocale(LC_NUMERIC, "POSIX"); > > Now please 'make' and let us know. > > To other members: > > Would any of you know which component effects this definition? Only the numeric format on localized builds of perfparse. In reality : nearly nothing. I have another question : cannot you ask mysql to read your queries as PO= SIX instead of localized ? Somebody knows how ? > Is this fix supported by FreeBSD, SUN and others if added to the > standard distribution? It should be. We already use setlocale() in perfparsed. Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Tim W. <tim...@gm...> - 2004-12-10 14:00:53
|
This might help: (from the MySQL documentation) To make it easier to reload dump files for tables that have foreign key relationships, mysqldump automatically includes a statement in the dump output to set FOREIGN_KEY_CHECKS to 0 as of MySQL 4.1.1.This avoids problems with tables having to be reloaded in a particular order when the dump is reloaded. For earlier versions, you can disable the variable manually within mysql when loading the dump file like this: mysql> SET FOREIGN_KEY_CHECKS = 0; mysql> SOURCE dump_file_name mysql> SET FOREIGN_KEY_CHECKS = 1; This allows you to import the tables in any order if the dump file contains tables that are not correctly ordered for foreign keys. It also speeds up the import operation. FOREIGN_KEY_CHECKS is available starting from MySQL 3.23.52 and 4.0.3. So you can easily keep the reference.... Tim On Fri, 10 Dec 2004 13:48:30 +0000, Ben Clewett <bcl...@pe...> wrote: > More Database design decisions. > > This is a problem which may effect many users, so I would really like to > get it right with new schema. > > We currently have a cyclic referential link in our tables. Yves has > reported that this makes PP data in MySQL impossible to dump and reload. > > This reference is as follows on this ERD: > > <- 1. Last value recorded > +------------------------------+ > | | > | | > [Binary Data] [Metrics] > \|/ | > | | > +------------------------------+ > 2. Metric details -> > > The '1. Last Value Recorded' allows the binary report. Showing for each > metric, when and what the last reading was. Useful information to have > for current and future work. > > The '2. Metric Details' link is used for Referential Integrity. > Stopping the metric being deleted if there is data for the metric. > Therefore avoiding hundreds of Mb of unreferenced data. If this is not > used, the user could end up with GB of orphaned data to which they > cannot access or delete. > > I can think of several possible solutions to this: > > (i) Not worry about Referential Integrity, loose link 2. Add the RI in > programaticly and hope that our programs work. > > (ii) Drop the Binary Report, loose link 1. > > (iii) Hope that newer versions of MySQL have a dump / import program > which works with cyclic referenced tables. > > (iv) Program our own dump program which works. > > I am tending towards option (iv)... > > As I know there are people on this list who know many time more about > databases than my self, I would really like to hear from you! > > Regards, > > Ben. > > -- > Ben Clewett bcl...@pe... > PerfParse http://www.perfparse.org > PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > |
|
From: Ben C. <bcl...@pe...> - 2004-12-10 13:48:33
|
More Database design decisions.
This is a problem which may effect many users, so I would really like to
get it right with new schema.
We currently have a cyclic referential link in our tables. Yves has
reported that this makes PP data in MySQL impossible to dump and reload.
This reference is as follows on this ERD:
<- 1. Last value recorded
+------------------------------+
| |
| |
[Binary Data] [Metrics]
\|/ |
| |
+------------------------------+
2. Metric details ->
The '1. Last Value Recorded' allows the binary report. Showing for each
metric, when and what the last reading was. Useful information to have
for current and future work.
The '2. Metric Details' link is used for Referential Integrity.
Stopping the metric being deleted if there is data for the metric.
Therefore avoiding hundreds of Mb of unreferenced data. If this is not
used, the user could end up with GB of orphaned data to which they
cannot access or delete.
I can think of several possible solutions to this:
(i) Not worry about Referential Integrity, loose link 2. Add the RI in
programaticly and hope that our programs work.
(ii) Drop the Binary Report, loose link 1.
(iii) Hope that newer versions of MySQL have a dump / import program
which works with cyclic referenced tables.
(iv) Program our own dump program which works.
I am tending towards option (iv)...
As I know there are people on this list who know many time more about
databases than my self, I would really like to hear from you!
Regards,
Ben.
--
Ben Clewett bcl...@pe...
PerfParse http://www.perfparse.org
PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php
|
|
From: Ben C. <bcl...@pe...> - 2004-12-10 10:53:16
|
Thanks! I noticed the voting tool. I've not thought of a way to use it yet. Something fun, interesting which also tells us something about PP... 'How long do you keep data' 1 day 2 days 4 days 1 week 2 weeks 1 month 3 months 6 months 1 year More... Any other ideas anybody? Flo Gleixner wrote: > > > I vote for Option 2 too. Hey, tiki has has voting tools too :-) But > that's not useful for now :-) > > Flo > > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Ben C. <bcl...@pe...> - 2004-12-10 10:20:47
|
Tim Wuyts wrote: > Ben, > If I understand correctly, every record in the METRIC table has a > unique id, plus a reference to a SERVICE record (using the > service_id). Every record in the SERVICE table has a unique id and a > reference to a HOST record (using the host_id). > > In that case, good _relational_ db design commands that you use option > 2, since the other option is again duplication of information. > > Tim. Tim, These are my feeling as well. However the complex key structure was requested by a member of this group, in order that data for an entire service or host could be selected more easily. Not a use-case which is currently used, but may be needed by some user :) I'll wait a while to see if anybody else has strong feelings on the subject. > PS: Nice ERD ;) Thanks! Ben > > > On Fri, 10 Dec 2004 09:49:16 +0000, Ben Clewett <bcl...@pe...> wrote: > >>Hi Tim, >> >>No problem. >> >>The host, service and metric is a unique ID of a real host, service or >>metric entries. Referenced in host, service and metric tables. >> >>The host table, for example: >> >>CREATE TABLE IF NOT EXISTS perfdata_host ( >> host_name VARCHAR(75) NOT NULL PRIMARY KEY, >> host_id INT NOT NULL, >> UNIQUE(host_id), >> .... >> >>(host_name is PK because it is already in current tables. host_id is a >>new field.) >> >>The full table definition of the new binary tables may be one of these: >> >>Option 1: >> >>CREATE TABLE IF NOT EXISTS perfdata_bin ( >> host_id INT NOT NULL, >> service_id INT NOT NULL, >> metric_id INT NOT NULL, >> ctime DATETIME NOT NULL, >> PRIMARY KEY (host_id, service_id, metric_id, ctime), >> value DOUBLE, >> state TINYINT NOT NULL, >> bin_extra_id INT >> ) TYPE=InnoDB; >> >>Option 2: >> >>CREATE TABLE IF NOT EXISTS perfdata_bin ( >> metric_id INT NOT NULL, >> ctime DATETIME NOT NULL, >> PRIMARY KEY (metric_id, ctime), >> value DOUBLE, >> state TINYINT NOT NULL, >> bin_extra_id INT >> ) TYPE=InnoDB; >> >>The difference is that the second is: >>- Smaller >>- Faster >>- Easier to construct queries. >> >>A simple ERD: >> >>Option 1: >> >>[host] ---< [service] ---< [metric] >> | | | >> | +----------+ | >> | | | >> | | +-----------------------+ >> | | | >> ^ ^ ^ >>[bin data] >> v >> | >>[extra data] >> >>Option 2: >> >>[host] ---< [service] ---< [metric] >> | >> | >> | >> +-----------------------+ >> | >> ^ >>[bin data] >> v >> | >>[extra data] >> >> >>Ben. >> >> >> >> >>Tim Wuyts wrote: >> >> >>>Ben, >>>For the sake of keeping the discussion clear, could you provide us >>>with a complete database schema? For the moment, it is not clear what >>>e.g. metric is (it's declared INT, so I suppose it references some >>>other table, but this is not defined). >>> >>>A graphical representation (ERD) would be nice :) >>> >>>Thx, >>>Tim >>> >>>On Fri, 10 Dec 2004 08:39:43 +0000, Ben Clewett <bcl...@pe...> wrote: >>> >>> >>>>Dear PP development community. >>>> >>>>I am recoding our main database to be smaller and faster. As discussed >>>>in this document: >>>> >>>>http://wiki.perfparse.org/tiki-index.php?page=DatabaseConversionSpecification >>>> >>>>I want to look again at the key structure for the main binary table. >>>> >>>>The two options are: >>>> >>>>1: >>>> host INT, service INT, metric INT, ctime DATETIME, >>>> PRIMARY KEY (host, service, metric, ctime) >>>> >>>>2: >>>> metric INT, ctime DATETIME, >>>> PRIMARY KEY (metric, ctime) >>>> >>>>Originally we were going to use (2). However several of you commented >>>>that (1) would be more useful for extracting all data for, say, a host >>>>or a service. >>>> >>>>I am looking at this again and am moving back towards structure instead >>>>(2). This gives: >>>> >>>>- Smaller table space. >>>>- Faster keyed access. >>>>- Easier to construct queries. >>>> >>>>I am also looking with respect to the only two likely use-cases in the >>>>near future: >>>> >>>>- Extracting data for one metric. Eg, a graph. >>>>- Extracting data for two or more random metrics. A graph of multiple >>>>metrics. >>>> >>>>Neither of these options require the large complex key. >>>> >>>>If it was ever needed to get all data for a host, this can be completed >>>>simply using a JOIN. Slightly slower, but the number of times this may >>>>be used is small enough that the disadvantaged are not significant. >>>>Where as we all want fast graphs. >>>> >>>>Since it was users on this group who suggested using the longer key >>>>structure (1), I would very much like to know how you feel before I decide. >>>> >>>>Regards, >>>> >>>>Ben Clewett. >>>> >>>>-- >>>>Ben Clewett bcl...@pe... >>>>PerfParse http://www.perfparse.org >>>>PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php >>>> >>>>------------------------------------------------------- >>>>SF email is sponsored by - The IT Product Guide >>>>Read honest & candid reviews on hundreds of IT Products from real users. >>>>Discover which products truly live up to the hype. Start reading now. >>>>http://productguide.itmanagersjournal.com/ >>>>_______________________________________________ >>>>Perfparse-devel mailing list >>>>Per...@li... >>>>https://lists.sourceforge.net/lists/listinfo/perfparse-devel >>>> >>> >>> >> >>-- >> >> >>Ben Clewett bcl...@pe... >>PerfParse http://www.perfparse.org >>PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Tim W. <tim...@gm...> - 2004-12-10 09:58:57
|
Ben, If I understand correctly, every record in the METRIC table has a unique id, plus a reference to a SERVICE record (using the service_id). Every record in the SERVICE table has a unique id and a reference to a HOST record (using the host_id). In that case, good _relational_ db design commands that you use option 2, since the other option is again duplication of information. Tim. PS: Nice ERD ;) On Fri, 10 Dec 2004 09:49:16 +0000, Ben Clewett <bcl...@pe...> wrote: > Hi Tim, > > No problem. > > The host, service and metric is a unique ID of a real host, service or > metric entries. Referenced in host, service and metric tables. > > The host table, for example: > > CREATE TABLE IF NOT EXISTS perfdata_host ( > host_name VARCHAR(75) NOT NULL PRIMARY KEY, > host_id INT NOT NULL, > UNIQUE(host_id), > .... > > (host_name is PK because it is already in current tables. host_id is a > new field.) > > The full table definition of the new binary tables may be one of these: > > Option 1: > > CREATE TABLE IF NOT EXISTS perfdata_bin ( > host_id INT NOT NULL, > service_id INT NOT NULL, > metric_id INT NOT NULL, > ctime DATETIME NOT NULL, > PRIMARY KEY (host_id, service_id, metric_id, ctime), > value DOUBLE, > state TINYINT NOT NULL, > bin_extra_id INT > ) TYPE=InnoDB; > > Option 2: > > CREATE TABLE IF NOT EXISTS perfdata_bin ( > metric_id INT NOT NULL, > ctime DATETIME NOT NULL, > PRIMARY KEY (metric_id, ctime), > value DOUBLE, > state TINYINT NOT NULL, > bin_extra_id INT > ) TYPE=InnoDB; > > The difference is that the second is: > - Smaller > - Faster > - Easier to construct queries. > > A simple ERD: > > Option 1: > > [host] ---< [service] ---< [metric] > | | | > | +----------+ | > | | | > | | +-----------------------+ > | | | > ^ ^ ^ > [bin data] > v > | > [extra data] > > Option 2: > > [host] ---< [service] ---< [metric] > | > | > | > +-----------------------+ > | > ^ > [bin data] > v > | > [extra data] > > > Ben. > > > > > Tim Wuyts wrote: > > > Ben, > > For the sake of keeping the discussion clear, could you provide us > > with a complete database schema? For the moment, it is not clear what > > e.g. metric is (it's declared INT, so I suppose it references some > > other table, but this is not defined). > > > > A graphical representation (ERD) would be nice :) > > > > Thx, > > Tim > > > > On Fri, 10 Dec 2004 08:39:43 +0000, Ben Clewett <bcl...@pe...> wrote: > > > >>Dear PP development community. > >> > >>I am recoding our main database to be smaller and faster. As discussed > >>in this document: > >> > >>http://wiki.perfparse.org/tiki-index.php?page=DatabaseConversionSpecification > >> > >>I want to look again at the key structure for the main binary table. > >> > >>The two options are: > >> > >>1: > >> host INT, service INT, metric INT, ctime DATETIME, > >> PRIMARY KEY (host, service, metric, ctime) > >> > >>2: > >> metric INT, ctime DATETIME, > >> PRIMARY KEY (metric, ctime) > >> > >>Originally we were going to use (2). However several of you commented > >>that (1) would be more useful for extracting all data for, say, a host > >>or a service. > >> > >>I am looking at this again and am moving back towards structure instead > >>(2). This gives: > >> > >>- Smaller table space. > >>- Faster keyed access. > >>- Easier to construct queries. > >> > >>I am also looking with respect to the only two likely use-cases in the > >>near future: > >> > >>- Extracting data for one metric. Eg, a graph. > >>- Extracting data for two or more random metrics. A graph of multiple > >>metrics. > >> > >>Neither of these options require the large complex key. > >> > >>If it was ever needed to get all data for a host, this can be completed > >>simply using a JOIN. Slightly slower, but the number of times this may > >>be used is small enough that the disadvantaged are not significant. > >>Where as we all want fast graphs. > >> > >>Since it was users on this group who suggested using the longer key > >>structure (1), I would very much like to know how you feel before I decide. > >> > >>Regards, > >> > >>Ben Clewett. > >> > >>-- > >>Ben Clewett bcl...@pe... > >>PerfParse http://www.perfparse.org > >>PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php > >> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from real users. > >>Discover which products truly live up to the hype. Start reading now. > >>http://productguide.itmanagersjournal.com/ > >>_______________________________________________ > >>Perfparse-devel mailing list > >>Per...@li... > >>https://lists.sourceforge.net/lists/listinfo/perfparse-devel > >> > > > > > > > -- > > > Ben Clewett bcl...@pe... > PerfParse http://www.perfparse.org > PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php > |
|
From: Ben C. <bcl...@pe...> - 2004-12-10 09:49:22
|
Hi Tim,
No problem.
The host, service and metric is a unique ID of a real host, service or
metric entries. Referenced in host, service and metric tables.
The host table, for example:
CREATE TABLE IF NOT EXISTS perfdata_host (
host_name VARCHAR(75) NOT NULL PRIMARY KEY,
host_id INT NOT NULL,
UNIQUE(host_id),
....
(host_name is PK because it is already in current tables. host_id is a
new field.)
The full table definition of the new binary tables may be one of these:
Option 1:
CREATE TABLE IF NOT EXISTS perfdata_bin (
host_id INT NOT NULL,
service_id INT NOT NULL,
metric_id INT NOT NULL,
ctime DATETIME NOT NULL,
PRIMARY KEY (host_id, service_id, metric_id, ctime),
value DOUBLE,
state TINYINT NOT NULL,
bin_extra_id INT
) TYPE=InnoDB;
Option 2:
CREATE TABLE IF NOT EXISTS perfdata_bin (
metric_id INT NOT NULL,
ctime DATETIME NOT NULL,
PRIMARY KEY (metric_id, ctime),
value DOUBLE,
state TINYINT NOT NULL,
bin_extra_id INT
) TYPE=InnoDB;
The difference is that the second is:
- Smaller
- Faster
- Easier to construct queries.
A simple ERD:
Option 1:
[host] ---< [service] ---< [metric]
| | |
| +----------+ |
| | |
| | +-----------------------+
| | |
^ ^ ^
[bin data]
v
|
[extra data]
Option 2:
[host] ---< [service] ---< [metric]
|
|
|
+-----------------------+
|
^
[bin data]
v
|
[extra data]
Ben.
Tim Wuyts wrote:
> Ben,
> For the sake of keeping the discussion clear, could you provide us
> with a complete database schema? For the moment, it is not clear what
> e.g. metric is (it's declared INT, so I suppose it references some
> other table, but this is not defined).
>
> A graphical representation (ERD) would be nice :)
>
> Thx,
> Tim
>
> On Fri, 10 Dec 2004 08:39:43 +0000, Ben Clewett <bcl...@pe...> wrote:
>
>>Dear PP development community.
>>
>>I am recoding our main database to be smaller and faster. As discussed
>>in this document:
>>
>>http://wiki.perfparse.org/tiki-index.php?page=DatabaseConversionSpecification
>>
>>I want to look again at the key structure for the main binary table.
>>
>>The two options are:
>>
>>1:
>> host INT, service INT, metric INT, ctime DATETIME,
>> PRIMARY KEY (host, service, metric, ctime)
>>
>>2:
>> metric INT, ctime DATETIME,
>> PRIMARY KEY (metric, ctime)
>>
>>Originally we were going to use (2). However several of you commented
>>that (1) would be more useful for extracting all data for, say, a host
>>or a service.
>>
>>I am looking at this again and am moving back towards structure instead
>>(2). This gives:
>>
>>- Smaller table space.
>>- Faster keyed access.
>>- Easier to construct queries.
>>
>>I am also looking with respect to the only two likely use-cases in the
>>near future:
>>
>>- Extracting data for one metric. Eg, a graph.
>>- Extracting data for two or more random metrics. A graph of multiple
>>metrics.
>>
>>Neither of these options require the large complex key.
>>
>>If it was ever needed to get all data for a host, this can be completed
>>simply using a JOIN. Slightly slower, but the number of times this may
>>be used is small enough that the disadvantaged are not significant.
>>Where as we all want fast graphs.
>>
>>Since it was users on this group who suggested using the longer key
>>structure (1), I would very much like to know how you feel before I decide.
>>
>>Regards,
>>
>>Ben Clewett.
>>
>>--
>>Ben Clewett bcl...@pe...
>>PerfParse http://www.perfparse.org
>>PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Perfparse-devel mailing list
>>Per...@li...
>>https://lists.sourceforge.net/lists/listinfo/perfparse-devel
>>
>
>
--
Ben Clewett bcl...@pe...
PerfParse http://www.perfparse.org
PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php
|
|
From: Tim W. <tim...@gm...> - 2004-12-10 09:36:27
|
Ben, For the sake of keeping the discussion clear, could you provide us with a complete database schema? For the moment, it is not clear what e.g. metric is (it's declared INT, so I suppose it references some other table, but this is not defined). A graphical representation (ERD) would be nice :) Thx, Tim On Fri, 10 Dec 2004 08:39:43 +0000, Ben Clewett <bcl...@pe...> wrote: > Dear PP development community. > > I am recoding our main database to be smaller and faster. As discussed > in this document: > > http://wiki.perfparse.org/tiki-index.php?page=DatabaseConversionSpecification > > I want to look again at the key structure for the main binary table. > > The two options are: > > 1: > host INT, service INT, metric INT, ctime DATETIME, > PRIMARY KEY (host, service, metric, ctime) > > 2: > metric INT, ctime DATETIME, > PRIMARY KEY (metric, ctime) > > Originally we were going to use (2). However several of you commented > that (1) would be more useful for extracting all data for, say, a host > or a service. > > I am looking at this again and am moving back towards structure instead > (2). This gives: > > - Smaller table space. > - Faster keyed access. > - Easier to construct queries. > > I am also looking with respect to the only two likely use-cases in the > near future: > > - Extracting data for one metric. Eg, a graph. > - Extracting data for two or more random metrics. A graph of multiple > metrics. > > Neither of these options require the large complex key. > > If it was ever needed to get all data for a host, this can be completed > simply using a JOIN. Slightly slower, but the number of times this may > be used is small enough that the disadvantaged are not significant. > Where as we all want fast graphs. > > Since it was users on this group who suggested using the longer key > structure (1), I would very much like to know how you feel before I decide. > > Regards, > > Ben Clewett. > > -- > Ben Clewett bcl...@pe... > PerfParse http://www.perfparse.org > PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Perfparse-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel > |
|
From: Ben C. <bcl...@pe...> - 2004-12-10 08:39:50
|
Dear PP development community. I am recoding our main database to be smaller and faster. As discussed in this document: http://wiki.perfparse.org/tiki-index.php?page=DatabaseConversionSpecification I want to look again at the key structure for the main binary table. The two options are: 1: host INT, service INT, metric INT, ctime DATETIME, PRIMARY KEY (host, service, metric, ctime) 2: metric INT, ctime DATETIME, PRIMARY KEY (metric, ctime) Originally we were going to use (2). However several of you commented that (1) would be more useful for extracting all data for, say, a host or a service. I am looking at this again and am moving back towards structure instead (2). This gives: - Smaller table space. - Faster keyed access. - Easier to construct queries. I am also looking with respect to the only two likely use-cases in the near future: - Extracting data for one metric. Eg, a graph. - Extracting data for two or more random metrics. A graph of multiple metrics. Neither of these options require the large complex key. If it was ever needed to get all data for a host, this can be completed simply using a JOIN. Slightly slower, but the number of times this may be used is small enough that the disadvantaged are not significant. Where as we all want fast graphs. Since it was users on this group who suggested using the longer key structure (1), I would very much like to know how you feel before I decide. Regards, Ben Clewett. -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Ben C. <bcl...@pe...> - 2004-12-09 16:23:08
|
I have edit the front page of the wiki site to try and look more professional. If you object or want to suggest anything, please do. Or better still, edit your self :) Ben -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Yves <yme...@pe...> - 2004-12-09 10:57:28
|
> There are two new forums on wiki. Help and Announce. These are > moderated by my self for anonymous postings, but open to all. Announce is a dangerous forum. Because only you should be able to write o= n it, it's better to have a static page or a wiki page about it. It is dangerous because of the comments that users can do. An example is = a user who has a problem on his machine and think it's perfparse. He will make a comment= "perfparse does not work in version X.Y". Those who read that think that version X.Y= is unstable and won't test it, and new users may even not try ! Other possible comments are questions. That is support. They should appea= r in the help forum, not in the announce support. I'm not against Announce in a forum, but nobody should be allowed to make= comments. The only interesting thing I see is to link Announce forum with perfparse= -announce mailing-list and for you to have one place less to write the announce :) > I noticed whilst setting this us that it's possible for the wiki to sen= d > postings to perfparse-users as well as receive from this mailing list. > Would this be acceptable for those rightly worried about two similar > lists, if the two kept in sync this way? Give a try like this : help forum <-------> perfparse-devel-int We will see if it's OK. And if not, those at perfparse-users will not see= it. If it is OK, (no porn, no terrorism messages), then replace perfparse-dev= el-int with perfparse-users in the forum config. Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Yves <yme...@pe...> - 2004-12-09 10:43:43
|
> Good work on perfparse - if you have any more patches to get perfdata > in, we'll put it in as soon as we can. Thanks :) We have the parser in a library, inside perfparse, and it should be very = easy to extract it and make a library external to the project. We don't see yet any need for such a library in other projects, so it is = not an emergency for us to release it outside of perfparse. But maybe one day, w= e'll do it :) Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ton V. <to...@ma...> - 2004-12-08 21:27:41
|
On 8 Dec 2004, at 09:39, Yves wrote: > > btw, i18n is good because it gives the opportunity to people to audit > the code :) > I agree. Benoit has done a great job in getting the code more consistent. Good work on perfparse - if you have any more patches to get perfdata in, we'll put it in as soon as we can. Ton |
|
From: Ben C. <bcl...@pe...> - 2004-12-08 17:08:37
|
Developers, There are two new forums on wiki. Help and Announce. These are moderated by my self for anonymous postings, but open to all. I noticed whilst setting this us that it's possible for the wiki to send postings to perfparse-users as well as receive from this mailing list. Would this be acceptable for those rightly worried about two similar lists, if the two kept in sync this way? Regards, Ben. -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
|
From: Yves <yme...@pe...> - 2004-12-08 15:58:13
|
> FYI > > I was able to compile version 0.104.2ym3 Good :) > Method 4 is working. Load issues related to perfparsed > Look to be resolved. > I put the /usr/local/nagios/lib in my LD_RUN_PATH > which is the better flag to use for Solaris8 > Setting the LD_RUN_PATH before the compile > embed's the paths to search for the library's in the > binary. Good to know. I will put that on wiki.perfparse.org somewhere :) > I then added "Storage_Modules_Load=3D"mysql,print,stdout" variable > to the perfparse.cfg in nagios/etc dir. I most likely don't > need "print,stdout" modules but I threw them in anyhow. You don't need print. Print and stdout do the same thing, but print is an= example for programmers with things that an admin cannot use. This is why I developpe= d stdout storage module : do the same thing as print, but with a nice output (the = same output as nagios). About stdout, if you run perfparse as a daemon, you don't need it because= stdout is redirected to /dev/null :) With 0.104.3 (Ben will probably release it this evening), give a try on f= ile_output that will write log files. This was broken in previous releases :) > To resolve the perfparse.cgi and perfgraph.cgi (old name) > I had to make a change the share/side.html file. There is no share/side.html file. Is it something to change in the doc so= mewhere ? Yves > > -----Original Message----- > From: Einecker, Stuart M. > Sent: Monday, December 06, 2004 3:14 PM > To: 'yme...@pe...'; Einecker, Stuart M. > Cc: per...@li... > Subject: RE: [Perfparse-users] perfparsed & CPU usage > > libpp_storage_*.so is not in my LD_LIBRARY_PATH > > As for the perfgraph.cgi: > - When perfgraph.cgi is removed then graphing doesn't work. > - When perfparse.cgi is renamed to perfgraph.cgi. Graphs work. > > > -----Original Message----- > From: Yves [mailto:yme...@pe...] > Sent: Monday, December 06, 2004 3:41 AM > To: Stu...@am... > Cc: per...@li... > Subject: RE: [Perfparse-users] perfparsed & CPU usage > > >> FYI >> In version 104.1ym3 I saw 2 problems with the >> Solaris 8 compile. >> - perfparsed no longer parsed data to the mysql database > > Is the directory where libpp_storage_*.so in your LD_LIBRARY_PATH ? > 0.104.2 should change nothing on that, but tell me anyways :) > >> - The application looks for perfgraph.cgi instead >> of perfparse.cgi > > perfgraph.cgi is supposed to be removed. But you have to do it by yours= elf. > We did not > want to remove anything on users' disks and take the responsibility for= it. > > Could you confirm that you don't have perfgraph.cgi any more on your di= sk ? > If the problem still occurs when you run perfparse.cgi, could you tell = us > more ? > > Yves > >> >> I verified both problems. >> 1. by reverting back to the 103.2; and >> made sure the conf files were still in tack. >> 2. by moving the old perfgraph.cgi out of the way and moving >> the the new perfparse.cgi to perfgraph.cgi. >> >> Later today I will try the 104.2 compile >> to see if these 2 problems go away. >> > > -- > - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - > - GPG key - http://ymettier.free.fr/gpg.txt - > - Maitretarot - http://www.nongnu.org/maitretarot/ - > - Perfparse - http://perfparse.sf.net/ - > > --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: <Stu...@am...> - 2004-12-08 15:20:24
|
FYI I was able to compile version 0.104.2ym3 Method 4 is working. Load issues related to perfparsed Look to be resolved. I put the /usr/local/nagios/lib in my LD_RUN_PATH which is the better flag to use for Solaris8 Setting the LD_RUN_PATH before the compile embed's the paths to search for the library's in the binary. I then added "Storage_Modules_Load="mysql,print,stdout" variable to the perfparse.cfg in nagios/etc dir. I most likely don't need "print,stdout" modules but I threw them in anyhow. To resolve the perfparse.cgi and perfgraph.cgi (old name) I had to make a change the share/side.html file. -----Original Message----- From: Einecker, Stuart M. Sent: Monday, December 06, 2004 3:14 PM To: 'yme...@pe...'; Einecker, Stuart M. Cc: per...@li... Subject: RE: [Perfparse-users] perfparsed & CPU usage libpp_storage_*.so is not in my LD_LIBRARY_PATH As for the perfgraph.cgi: - When perfgraph.cgi is removed then graphing doesn't work. - When perfparse.cgi is renamed to perfgraph.cgi. Graphs work. -----Original Message----- From: Yves [mailto:yme...@pe...] Sent: Monday, December 06, 2004 3:41 AM To: Stu...@am... Cc: per...@li... Subject: RE: [Perfparse-users] perfparsed & CPU usage > FYI > In version 104.1ym3 I saw 2 problems with the > Solaris 8 compile. > - perfparsed no longer parsed data to the mysql database Is the directory where libpp_storage_*.so in your LD_LIBRARY_PATH ? 0.104.2 should change nothing on that, but tell me anyways :) > - The application looks for perfgraph.cgi instead > of perfparse.cgi perfgraph.cgi is supposed to be removed. But you have to do it by yourself. We did not want to remove anything on users' disks and take the responsibility for it. Could you confirm that you don't have perfgraph.cgi any more on your disk ? If the problem still occurs when you run perfparse.cgi, could you tell us more ? Yves > > I verified both problems. > 1. by reverting back to the 103.2; and > made sure the conf files were still in tack. > 2. by moving the old perfgraph.cgi out of the way and moving > the the new perfparse.cgi to perfgraph.cgi. > > Later today I will try the 104.2 compile > to see if these 2 problems go away. > -- - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Benoit M. <ben...@op...> - 2004-12-08 11:08:49
|
Le mercredi 8 D=E9cembre 2004 11:45, Ben Clewett a =E9crit=A0: > Yves, Benoit, Ton and others: > > http://wiki.perfparse.org/tiki-view_faq.php?faqId=3D6 > > This answer does not say which version of the plugins these results come > from. If you know can you let me know and I'll edit the posting. Latest head of last night ;-) =2D-=20 Benoit Mortier OpenSides sprl Linux Engineer |
|
From: Flo G. <fl...@bi...> - 2004-12-08 10:56:07
|
> > With the permission of Flo I would like to try the wiki forum as an alternate > mechanism for user support and see how it works, whether users use it, > whether it does look and work better? > You have admin rights. Don't destroy anything :-) Flo |
|
From: Yves <yme...@pe...> - 2004-12-08 10:48:45
|
> It would look so much better if the support forum mechanism was all > contained in the same environment. But with the mailing-list archives on sourceforge, this is impossible. > I note as well your past comments about not wanting to be tied too > closely to Sourceforge. For example, in case their license options > change. This would be a great way of ensuring that all our facilities > are not tied into sourceforge. No. If you agree with me on that risk, don't create a new thing in an ind= ependant place. Just move the existing to somewhere else, where the risk is lower (I know http://savannah.gnu.org, https://gna.org/). Don't make a wrong analysis :) > The system kindly provided by Flo is controllable, fast, looks great an= d > would keep the users in a consistent PerfParse environment. It would > give a more professional look to the support. I don't agree with "more professional". It would be if everything includi= ng the mailing-lists was at the same place and if everything on the mailing-list= and the forum could be searched with the same tool. With too many support sources, it looks like a young hacker's project who= is discovering the wonderful of tikiwiki and wants to try everything of it :) BTW, I notice that there is a bug tracker enabled on sourceforge, with 10= 27861 and 1045561 being support requests rather than bugs. There are definitely too= many support places here. See at the end my comments about the sourceforge tools. > It would work better for users. The mechanism to sign up to the wiki i= s > faster and cleaner and can be run by users who don't want email sent to > them. For instance users who have email at home and their work place, > it would not tie them into one or the other. Some send us private mails. It already happened to me. Last one was from = Benoit Mortier, today :) > The legal aspect of anonymous postings. I agree that moderated > anonymous posting is probably the correct mechanism. Truly anonymous > systems are probably a thing of the past :) > > With the permission of Flo I would like to try the wiki forum as an > alternate mechanism for user support and see how it works, whether user= s > use it, whether it does look and work better? I agree with the idea to try, because it's always good to have an open mi= nd. However, be careful to the following... - I will not have time to go there and help you answer the postings. If y= ou or users need my help, we will have to invent something else. - Control everything that appear on the forum. You should be able to remo= ve inappropriate messages (porn, money, terrorist...) as soon as they may ap= pear. When you are on holidays, find somebody who does it. I can do it in a short term p= eriod, but you know that I won't be able to stay as active as now on perfparse at a date= that I don't know yet, but certainly in 2005. - You will need time before a community starts there. Before, there will = be few messages, because a forum with few messages looks unsupported. > Finally, the html forum on sourceforge. I will delete those now :) Remove other stuff too... Today, we have this : Summary | Admin | Home Page | Forums | Tracker | Bugs | Support | = Patches | RFE | Lists | Tasks | Docs | Screenshots | News | CVS | Files | We should have that : Summary | Admin | Home Page | RFE | Lists | CVS | Files | About RFE, I notice that you used it on 2004-05-18 and only 7 times after= that. And it is not maintained : 955701 has been completed for a while :) About 955678 (postgresql), you should either remove it, or also add Oracl= e, Sybase, ODBC, sqlite and maybe others. About NEWS : we have http://perfparse.sourceforge.net/news.php (not maint= ained but should be !) and perfparse-announce mailing-list. That enough, isn't it ? About Docs : we have http://wiki.perfparse.org and http://perfparse.sourceforge.net/docs.php (this should be reorganized, bu= t no emergency : it's OK for now : users can find their way easily :) About bugs : if we have a way to send a mail to perfparse-devel-int when = a bug is added, this is a good tool, leave it. If there is no way to send a mail, remove = it (not maintained : 1076856 is OK in pp-0.104.2; 1045561 is a support request (t= hat guy does not have libpng-devel installed); 1027861 is a support request and is pro= bably too old. Back to 1076856 : there has been 4 users who told me about that one : 2 o= n the mailing-list, another one with a direct mail to me (see how those who don= 't want to subscribe do) and bug 1076856 :) I will close that bug. And if you find a way to send a mail to perfparse-= devel-int when a bug is submitted there, keep that good tool :) Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr... I need to have a login to be= able to close that bug. Having a login means more implication in the project, and as a = side effect, more time for the project and less time to code. I have other reasons not= to log in sf.net so please, close that bug for me. Sorry to ask you to do my job :) Yves --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ben C. <BCl...@pe...> - 2004-12-08 10:46:02
|
Yves, Benoit, Ton and others: http://wiki.perfparse.org/tiki-view_faq.php?faqId=3D6 This answer does not say which version of the plugins these results come=20 from. If you know can you let me know and I'll edit the posting. Thanks, Ben Benoit Mortier wrote: > Le mercredi 8 D=E9cembre 2004 10:39, Yves a =E9crit : >=20 >>>Excellent idea. >>> >>>I have cc'd this to Ton Voon who is maintaining the plugin development >>>at the moment. >> >>And Benoit Mortier is working with Ton Voon on the plugins, on the fren= ch >>translation as far as I know, maybe more :) >=20 >=20 > Yes ;-) more ;-) >=20 >=20 >>Funny loop :) >=20 >=20 > ;-) >=20 >=20 >>btw, i18n is good because it gives the opportunity to people to audit t= he >>code :) >=20 >=20 > Yes that's what i am doing now ;-) and i started writing a template plu= gin=20 > to facilitate development .. >=20 > For the perfdata, is the doc from nagios doc the only doc ?? >=20 > Have a nice day >=20 |
|
From: Benoit M. <ben...@op...> - 2004-12-08 10:09:10
|
Le mercredi 8 D=E9cembre 2004 10:39, Yves a =E9crit=A0: > > Excellent idea. > > > > I have cc'd this to Ton Voon who is maintaining the plugin development > > at the moment. > > And Benoit Mortier is working with Ton Voon on the plugins, on the french > translation as far as I know, maybe more :) Yes ;-) more ;-) > Funny loop :) ;-) > > btw, i18n is good because it gives the opportunity to people to audit the > code :) Yes that's what i am doing now ;-) and i started writing a template plugin= =20 to facilitate development .. =46or the perfdata, is the doc from nagios doc the only doc ?? Have a nice day =2D-=20 Benoit Mortier OpenSides sprl Linux Engineer |
|
From: Yves <yme...@pe...> - 2004-12-08 09:39:36
|
> Excellent idea. > > I have cc'd this to Ton Voon who is maintaining the plugin development > at the moment. And Benoit Mortier is working with Ton Voon on the plugins, on the french= translation as far as I know, maybe more :) Funny loop :) btw, i18n is good because it gives the opportunity to people to audit the= code :) Yves > > Yves wrote: > >>>Hi, >>> >>>i have seen your list on the website for plugins perdata, here is a li= sting >>>of perdata support in current plugins >> >> >> Thanks Benoit ! >> Ben, I suggest that we put that list on wiki.perfparse.org. What do yo= u think ? >> >> Yves >> >> >>>Support perfdata >>> >>>Main plugins >>> >>>check_dig >>>check_disk >>>check_dns >>>check_fping >>>check_game >>>check_http >>>check_icmp (new in cvs with the patch from perfparse) >>>check_ldap >>>check_load >>>check_mrtg >>>check_mrtgraf >>>check_nt >>>check_pgsql >>>check_smtp >>>check_tcp >>>check_time >>>check_ups >>>check_user >>> >>>don't support perfdata >>> >>>check_by_ssh >>>check_dhcp >>>check_hpjd >>>check_ide_smart >>>check_mysql >>>check_nagios >>>check_nwstat >>>check_overcr >>>check_ping >>>check_procs >>>check_radius >>>check_real >>>check_ssh >>>check_ups >>> >>>Have a nice day >>>-- >>>Benoit Mortier >>>OpenSides sprl >>>Linux Engineer >>> >>> >> >> >> > > --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
|
From: Ben C. <BCl...@pe...> - 2004-12-08 09:10:10
|
Excellent idea. I have cc'd this to Ton Voon who is maintaining the plugin development at the moment. Yves wrote: >>Hi, >> >>i have seen your list on the website for plugins perdata, here is a listing >>of perdata support in current plugins > > > Thanks Benoit ! > Ben, I suggest that we put that list on wiki.perfparse.org. What do you think ? > > Yves > > >>Support perfdata >> >>Main plugins >> >>check_dig >>check_disk >>check_dns >>check_fping >>check_game >>check_http >>check_icmp (new in cvs with the patch from perfparse) >>check_ldap >>check_load >>check_mrtg >>check_mrtgraf >>check_nt >>check_pgsql >>check_smtp >>check_tcp >>check_time >>check_ups >>check_user >> >>don't support perfdata >> >>check_by_ssh >>check_dhcp >>check_hpjd >>check_ide_smart >>check_mysql >>check_nagios >>check_nwstat >>check_overcr >>check_ping >>check_procs >>check_radius >>check_real >>check_ssh >>check_ups >> >>Have a nice day >>-- >>Benoit Mortier >>OpenSides sprl >>Linux Engineer >> >> > > > |
|
From: Ben C. <BCl...@pe...> - 2004-12-08 09:08:06
|
Yves wrote: >>>People usually subscribe or say they did not subscribe and would like to be in CC for >>>the answer. >> >>KISS: Give them a single page with the archives and a posting form :) >> >>This is not possible with our mailing list. > > > Why ? Because the mail archive is hosted on a server to which we have no control. We cannot give the novice or new users a consistent clean method of posting, searching, checking FAQ. These are on different servers which can't be linked together cleanly. We also can't search the Sourceforge mailing list without using their search tool, so we would have to use their page. It would look so much better if the support forum mechanism was all contained in the same environment. I note as well your past comments about not wanting to be tied too closely to Sourceforge. For example, in case their license options change. This would be a great way of ensuring that all our facilities are not tied into sourceforge. The system kindly provided by Flo is controllable, fast, looks great and would keep the users in a consistent PerfParse environment. It would give a more professional look to the support. It would work better for users. The mechanism to sign up to the wiki is faster and cleaner and can be run by users who don't want email sent to them. For instance users who have email at home and their work place, it would not tie them into one or the other. The legal aspect of anonymous postings. I agree that moderated anonymous posting is probably the correct mechanism. Truly anonymous systems are probably a thing of the past :) With the permission of Flo I would like to try the wiki forum as an alternate mechanism for user support and see how it works, whether users use it, whether it does look and work better? Finally, the html forum on sourceforge. I will delete those now :) Ben > > I suggest that users who have not subscribed can post. And wait for moderation. That > way, you can control that no spams (porn, money...) is sent on the list. > And a posting form would just be an interface for the mailing-list if you really want an > html portal to the mailing-list. > > I thought to the law, and Flo to porn and such messages that anonymous can post. If you > allow anonymous posting, wherever it is (mailing-list or forum or mail form), you have > to control ! > > btw, in France, forums that are hosted in France that allow anonymous posters are > illegal :) > This is a recent law. > But it is not an argument because wiki.perfparse.org is not hosted in France :) > > > >>>You can (additionnaly) edit the web page where you explain where to subscribe and add >>>that users should read on wiki.perfparse.org before asking for something. >> >>This would be this page: >> >>http://sourceforge.net/mailarchive/forum.php?forum_id=43072 >> >>Unfortunately I don't have the option to edit this. This is a dead-end >>URL. > > > I was meaning that you can make your own page with a similar content. > Put that page on the wiki and you have all the information about support and the FAQ in > the same place. Isn't that what you want ? :) > > Put "how to get support" in evidence on the wiki, write that you can get support thanks > to the FAQ and then to the mailing-list, and you are a winner :) > > > >>>>3 Email alerts possible for the rest of us. (Check, is this possible?) >>> >>>I prefer a form that send the question directly to the mailing list and returns to the >>>user that some answers may be found on the mail archives. I prefer it this way in >>>order >>>to centralize everything in the mail archives. >> >>Agreed, would be great. My problem with this is only that it takes them >>away from the nice wiki site where there is no link back home. > > > Just make a link :) > > > > >>I want to give the novice user another mechanism which is fast, >>in the PP style, and keeps them close to the FAQ and other documentation. > > > This is what we have to think about :) > > >>I want to turn a disconnected group of servers sites and mailing lists >>into a consistent PP support tool... > > >>I would like to see it as just two: >> >>www.perfparse.org <----> wiki.perfparse.org >> | | >> | | >> v V >>Static front site. Dynamic documents, FAQ and Forum. > > > Yes. But not the forum. > Forums work well when there is a community around the forum. > Same for mailing-lists. > With the mailing-list, we are now a little community, including Tim Wuyts who sometimes > answers before us, and somebody else that I lost the name. With us answering a lot, it > makes support correct on the mailing-list. > On the forum, it would need the same effort of us before you make a community. I can > spend time on perfparse development, answering the mails, but the forum is too much for > me. And I think it's probably also too much for you and others. > The forum would be a good idea if there was too many mails on the mailing-list. But the > traffic is correct there :) > > > > Yves |
|
From: Yves <yme...@pe...> - 2004-12-08 09:01:31
|
> Hi, > > i have seen your list on the website for plugins perdata, here is a lis= ting > of perdata support in current plugins Thanks Benoit ! Ben, I suggest that we put that list on wiki.perfparse.org. What do you t= hink ? Yves > > Support perfdata > > Main plugins > > check_dig > check_disk > check_dns > check_fping > check_game > check_http > check_icmp (new in cvs with the patch from perfparse) > check_ldap > check_load > check_mrtg > check_mrtgraf > check_nt > check_pgsql > check_smtp > check_tcp > check_time > check_ups > check_user > > don't support perfdata > > check_by_ssh > check_dhcp > check_hpjd > check_ide_smart > check_mysql > check_nagios > check_nwstat > check_overcr > check_ping > check_procs > check_radius > check_real > check_ssh > check_ups > > Have a nice day > -- > Benoit Mortier > OpenSides sprl > Linux Engineer > > --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
2 messages has been excluded from this view by a project administrator.
