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

[Paulo A. G. F. <pau...@pr...>]

Ben,

I've found that perfparse has now the infrastructure to use ranges of =
warning/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).

Part of the problem is at save_bin_data at storage_mysql.c:

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

I've changed it to

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

and the data begun to show up in perfdata_service_bin. However, =
metric_state values were still wrong and inconsistent indeed with =
perfdata_service_raw. In the example I sent you, the metrics were 2 =
(CRITICAL) in perfdata_service_bin; OTOH they were 0 (NORMAL) in =
perfdata_service_raw. And the graphs continued not showing the guides =
for warning/critical thresholds. At this point, I rolled back to release =
0.100.7.

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! I've =
tried to optimize MySQL settings to no avail, and this was other reason =
that leaded me to roll back to 0.100.7.

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 =
mention of this in the documentation, and if it sounds obvious for the =
developing team, it may be not so clear for the users.

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.

Why don't you add a compilation switch to disable these burning edge =
features? It would make life easier to people that rely on perfparse for =
data gathering on production systems.

[]'s and keep the great work,

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

> -----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
>=20
> Paulo,
>=20
> Can you please send me a sample of your data, I want to=20
> replicate and fix this problem.
>=20
> Regards,
>=20
> Ben Clewett.
>=20
> Paulo Afonso Graner Fessel wrote:
>=20
> > 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
> >=20
> +-------------+-----------------------------+-----------------
> ------------+---------------------+----------+--------+-------
> ---+--------+
> > | host_name   | service_description         |=20
> > metric                      | ctime               | value  =20
>  | warn   |=20
> > critical | state  |
> >=20
> +-------------+-----------------------------+-----------------
> ------------+---------------------+----------+--------+-------
> ---+--------+
> > | 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 |
> >=20
> +-------------+-----------------------------+-----------------
> ------------+---------------------+----------+--------+-------
> ---+--------+
> > 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
>=20