Re: RES: [Perfparse-users] Warning/critical values not going into the database... Again

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

Paulo,

I hope the next version will have these bugs sorted, please check when=20
you can.

I want to answer just one comment from this email:

 > I've found performance problems also in 0.101.1, as I feel that it is
 > much slower than 0.100.7 when reading the serviceperf.log file and
 > putting it into the database. In 0.100.7 I've got thousands of lines
 > per second; in 0.101.1 this number never is greater than 70 lines/sec.
 > And I'm running on a machine with 512 MB RAM, 2xIntel Xeon 3.06 GHz!

There was a bug in versions before 0.101.1.  The performance in the=20
status line was being reported in error, far too high.  You may want to=20
calculate your lines/second by hand to get a correct measure of whether=20
the next version is really any faster.  This bug is fixed in new=20
versions, therefore showing a correct but much lower value.

However, your figure of 70 lines/seconds on a duel Xeon 3.06 is terribly=20
low.  I would expect ~1000 lines/second at least.  Version 0.102.1 which=20
will be out very soon.  Thanks from our friend Yves, this had five=20
different methods of getting data from Nagios to PP.  Perhaps one of=20
these will work better.

Regards,

Ben.


Paulo Afonso Graner Fessel wrote:

> Ben,
>=20
> I've found that perfparse has now the infrastructure to use ranges of w=
arning/critical data, and the problem is that the database hasn't changed=
 in order to use these values (as far as I can see, at least).
>=20
> Part of the problem is at save_bin_data at storage_mysql.c:
>=20
>         g_string_append_printf(s_SQL, ", %s",
>                 getSafeD(perf->d[PERF_VALUE_WARN_START]));
>         g_string_append_printf(s_SQL, ", %s",
>                 getSafeD(perf->d[PERF_VALUE_CRIT_START]));
>         g_string_append_printf(s_SQL, ", %s)",
>                 getSafeD(perf->metric_state));
>=20
> I've changed it to
>=20
>         g_string_append_printf(s_SQL, ", %s",
>                 getSafeD(perf->d[PERF_VALUE_WARN_END]));
>         g_string_append_printf(s_SQL, ", %s",
>                 getSafeD(perf->d[PERF_VALUE_CRIT_END]));
>         g_string_append_printf(s_SQL, ", %s)",
>                 getSafeD(perf->metric_state));
>=20
> and the data begun to show up in perfdata_service_bin. However, metric_=
state values were still wrong and inconsistent indeed with perfdata_servi=
ce_raw. In the example I sent you, the metrics were 2 (CRITICAL) in perfd=
ata_service_bin; OTOH they were 0 (NORMAL) in perfdata_service_raw. And t=
he graphs continued not showing the guides for warning/critical threshold=
s. At this point, I rolled back to release 0.100.7.
>=20
> I've found performance problems also in 0.101.1, as I feel that it is m=
uch slower than 0.100.7 when reading the serviceperf.log file and putting=
 it into the database. In 0.100.7 I've got thousands of lines per second;=
 in 0.101.1 this number never is greater than 70 lines/sec. And I'm runni=
ng on a machine with 512 MB RAM, 2xIntel Xeon 3.06 GHz! I've tried to opt=
imize MySQL settings to no avail, and this was other reason that leaded m=
e to roll back to 0.100.7.
>=20
> Also, the documentation is a little confusing in this release. It took =
me some time until I understood that, with --default-perfdata I wouldn't =
have to use crontab entries anymore to update the database. There's no me=
ntion of this in the doocumentation, and if it sounds obvious for the dev=
eloping team, it may be not so clear for the users.
>=20
> Don't get me wrong: I find that perfparse is THE solution for gathering=
 performance data for Nagios. However, I feel that this wasn't the right =
time to release 0.101.1 because it clearly lacks polishing and has rough =
edges on database architecture and plugin parsing output.
>=20
> Why don't you add a compilation switch to disable these burning edge fe=
atures? It would make life easier to people that rely on perfparse for da=
ta gathering on production systems.
>=20
> []'s and keep the great work,
>=20
> Paulo Afonso Graner Fessel
> Administrador de Ambiente e Sistemas UNIX
> pau...@pr...
> OWT
> Fone: +55 (11) 3038-6554
> Fax: +55 (11) 3038-6508
> http://www.primesys.com.br
> =20
> =20
> =20
> =20
>=20
>=20
>>-----Mensagem original-----
>>De: Ben Clewett [mailto:Be...@cl...]=20
>>Enviada em: ter=E7a-feira, 19 de outubro de 2004 04:25
>>Para: Paulo Afonso Graner Fessel
>>Cc: per...@li...
>>Assunto: Re: [Perfparse-users] Warning/critical values not=20
>>going into the database... Again
>>
>>Paulo,
>>
>>Can you please send me a sample of your data, I want to=20
>>replicate and fix this problem.
>>
>>Regards,
>>
>>Ben Clewett.
>>
>>Paulo Afonso Graner Fessel wrote:
>>
>>
>>>Hello, folks.
>>>=20
>>>I've just upgraded to 0.101.1 and I'm noticing that=20
>>
>>warning/critical=20
>>
>>>values from plugins are not getting into the database again. But=20
>>>differently (and worst) than last time, seems that the=20
>>
>>state field of=20
>>
>>>perfdata_service_bin is also incorrect:
>>>=20
>>>
>>
>>+-------------+-----------------------------+-----------------
>>------------+---------------------+----------+--------+-------
>>---+--------+
>>
>>>| host_name   | service_description         |=20
>>>metric                      | ctime               | value  =20
>>
>> | warn   |=20
>>
>>>critical | state  |
>>>
>>
>>+-------------+-----------------------------+-----------------
>>------------+---------------------+----------+--------+-------
>>---+--------+
>>
>>>| D01         | Cache Hits                  |=20
>>>lib                         | 2004-10-18 17:35:58 |   =20
>>
>>99.99 |      0=20
>>
>>>|        0 |      2 |
>>>| D01         | Cache Hits                  |=20
>>>buffer                      | 2004-10-18 17:35:58 |   =20
>>
>>99.95 |      0=20
>>
>>>|        0 |      2 |
>>>
>>
>>+-------------+-----------------------------+-----------------
>>------------+---------------------+----------+--------+-------
>>---+--------+
>>
>>>In my definition of this particular service, I want these=20
>>
>>two metrics=20
>>
>>>to be as high as possible, with a maximum value of 100%.=20
>>
>>However, as=20
>>
>>>you can see, I don't have warning and critical values for=20
>>
>>this metric,=20
>>
>>>and also its state as determined by perfparse is 2 (CRITICAL); it=20
>>>should be 0 actually (NORMAL).
>>>=20
>>>[]'s
>>>=20
>>>*Paulo Afonso Graner Fessel*
>>>/Administrador de Ambiente e Sistemas UNIX/=20
>>>pau...@pr... <mailto:pau...@pr...>
>>>OWT
>>>Fone: +55 (11) 3038-6554
>>>Fax: +55 (11) 3038-6508
>>>http://www.primesys.com.br <http://www.primesys.com.br/>
>>>=20
>>>=20
>>>=20
>>
>>
>=20