> [I'm moving this to a wider forum as others may have input or be
> interested in collaboration]
>
> I have no problem with giving Michal the pmderive source under the
> terms you propose, but I would warn:
>
> 1. Data reduction is not the same as trend analysis ... operationally
> and statistically they are quite different, so I'm not sure now
> useful pmderive source will be, and
>
> 2. Ania and I never resolved some of the hard parts of the semantics of
> reduced PCP archive data so I would question how "almost finished"
> it is ... last I recall she had hit the wall on some curly issues
> and did not have a proposal for moving forwards (remember pmderive
> came from a boatload of functionality culled from pmlogextract when I
> was unhappy about the semantic soundness of the output archive).
>
> We need trend analysis tools, and I would encourage collaboration in
> this area. If someone believes pmderive would help, by all means make
> it available.
Okay, I will explain my idea again - this time to a public forum:
Let's start with one of the cases I need to solve. Imagine you got a freemail
web server. One of the issues you face is the disk space. You want to have
it displayed for, say, two months back to be able to estimate when you will need
to extend your disk space, so you can prepare for the operation.
First way is to use pmlogextract, process the values with a script and feed to
gnuplot.
But there's another way: This all _could_ be done with PCPMON with two
drawbacks:
- Archive for one day has about 10MB (for all metrics). PCPMON cannot "skip"
from one PCP archive to another.
- Even if it could, you would have other problems. If you want to show CPU usage
trend, you want to show the HIGHEST load encountered, not some random sample.
So you need to be able to take more samples and apply some grouping function
on them.
I could add those two features to PCPMON. But is seems to me that it is better
to take a more general approach - write tool which would create another PCP
archive. This you can display not only with PCPMON, but you can use other tools
to process it.
I agree that you can "sum apples and pears" with the proposed tool. As you can
do that with PCPMON - the philosophy behind whis approach is that the user must
know what he is doing and what he is seeing. He must know it anyway - consider
aliasing problems.
This is what I need. How do you define "thend analysis tool"? Do you need
other features?
Michal
|