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

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

Hi Paulo,

I'm the author of most code of perfparse-log2db so I pay a lot of attenti=
on to your
emails even if Ben answers faster than me.
I will add some things to Ben's answer...

> 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 u=
se 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));
>

This is fixed for the 0.102 branch I'm working on. Ben will decide to rel=
ease 0.101.2
with that or to wait for other fixes.

> 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 e=
xample I sent
> you, the metrics were 2 (CRITICAL) in perfdata_service_bin; OTOH they w=
ere 0 (NORMAL) in
> perfdata_service_raw. And the graphs continued not showing the guides f=
or
> warning/critical thresholds. At this point, I rolled back to release 0.=
100.7.

I have already noticed that with previous versions and I don't remember i=
f the reason
has been found yet.

> 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 d=
atabase. 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, 2xInte=
l Xeon 3.06 GHz!
> I've tried to optimize MySQL settings to no avail, and this was other r=
eason that leaded
> me to roll back to 0.100.7.

Could you send us what this returns ?
perfparse-log2db <your options here> --show_config

I want to make sure that you don't enable something that will slow perfpa=
rse.

> 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 docum=
entation, and if
> it sounds obvious for the developing team, it may be not so clear for t=
he users.

Yes, I'm not good at documentation, and Ben and Garry were too busy to he=
lp me. I should
have asked here on the mailing-list for some help :)

About crontab, perfparse-0.102 will include a daemon and provide more fea=
tures.
If somebody wants to help with beta-testing and documentation, please tel=
l us !

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

0.101.1 was released after 23 devel releases and I needed feedback to kno=
w if I could
continue with my ideas or if I had to listen users.
When you develop on your own, sometimes, you make tools for you and they =
are too far
from users's needs. With 0.101.1, I wanted to be sure that it was OK, and=
 I considered
it as stable enough to make a public and official release.

> 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 data gathering on=
 production
> systems.

What burning edge features ?
Except what I call storage modules (and only the mysql storage module is =
enabled in
perfparse-log2db), I don't understand what you are talking about that cou=
ld be disabled.

> []'s and keep the great work,

Thanks for the feedback. With 0.101.1, this is really necessary !

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