RHQ and Cloud-TM project

Paolo Romano romano at inesc-id.pt
Wed May 16 12:24:16 UTC 2012


On 5/16/12 12:32 PM, Heiko W.Rupp wrote:
> Paolo,
>
> Am 16.05.2012 um 00:04 schrieb Paolo Romano:
>
>> What about instead creating an agent plugin that injects future (predicted using external tools) values of metrics?
>>
>> Say that we create a plugin for CPU utilization, which returns to the server, when it is queried at time t, a report containing two metrics:
>> - the current CPU utilization (at time t), called CPU_now
>> - the forecast value of CPU utilization at time (t+k)
>>
>> Do you believe that this will work fine for the server and will be able to plot values/define alerts on this "virtual/forecast" metrics? Or injecting data with future timestamps may lead to unexpected behaviors/failures?
> This is an interesting question.  We do not prevent data to be inserted for the future, but with our rolling table schema (we have 15
> tables to put stuff in - one table per 12h. So there is the current table and 13.x older ones that form the past 7 days. When
> rotating the the current table, we take the next one and truncate it before data is entered. So I think if you write future data that
> will end up in the upcoming table, it will vanish on rotation (I may be off by one here and have never tried it).
>
> As right now we do not support metric comparison like if (value[t-8]...) , but this may/will come in the next generation of alerting.

Thanks for the prompt feedback Heiko!

We will make a brief attempt to check what happens. Actually a very 
preliminary test we have done gives another anomaly: if we provide 
values in the future (at time t+k) for a metric, it appears that this 
metric stops being polled by the server till time t+k has elapsed (the 
future has become past :) ). We'll confirm this with more testing later 
on today.

I was thinking that another, simpler alternative, which would work fine 
for alerting but would be suboptimal in terms of visualization,  would 
be creating new metrics having timestamp in the present, but whose 
values are actually associated with estimates concerning future times.

E.g., say we have a plain metric metric cpu_utilization, our agent would 
provide an additional metric called, say,  cpu_utilization_in_one_hour.

So when at time t, the agent is queried, it returns both cpu_utilization 
and cpu_utilization_in_one_hour, both with timestamp t.

Undertanding the semantics of cpu_utilization_in_one_hour is delegated 
to the user. The visualization of course would not be great, but the 
advantage is that the engine rule will work with no need of modifications.

What do you think?
>
> I think the best bet for you is to use the baselines (base band) that you can also write via rest. You probably compute it less often and
> this gives you then an estimate that you can measure incoming metrics against. It allows to set up an upper and lower bound.

Thanks for the hint, we did not know about this functionality. We'll 
check it out!




More information about the rhq-devel mailing list