于 2012年10月31日 21:56, Julien Danjou 写道:
On Wed, Oct 31 2012, 吴亚伟 wrote:
1) '12389000' nanoseconds means '123.89' seconds or two minutes,it
seem like to be 1238.9 seconds actually, is there something wrong ?
Why do you think it's 1238.9 seconds?
Well, to be honest, I do really though it's
Hi Eoghan,
Thanks for your reply. As we can see from the document:
-
Three type of meters are defined in ceilometer:
TypeDefinition
Cumulative Increasing over time (instance hours)
Gauge Discrete items (floating
On Wed, Oct 31 2012, Eoghan Glynn wrote:
Yep the sum of local maxima is not lossy as long as the requested
duration completely encapsulates the compute agent outage (and the
instance doesn't restart during the outage).
Actually, if there's one restart, it still _can_ be safe in certain
On Thu, Nov 01 2012, 吴亚伟 wrote:
Is the API capable to deal with that at present? If not, when?
Not yet. When someone will write with the code!
Is the Web API in the document going to be updated recently?
We hope so!
--
Julien Danjou
-- Free Software hacker freelance
--
On Thu, Nov 01 2012, 吴亚伟 wrote:
Cumulative type is apparent, while even with descriptions gauge and delta
type confuse me.
Could you explain them through examples or by sharing an use case?
Gauge is an absolute value, like a temperature or the number of people
in a room.
Delta is a counter
On Wed, Oct 31, 2012 at 1:39 PM, Julien Danjou jul...@danjou.info wrote:
On Wed, Oct 31 2012, Eoghan Glynn wrote:
Would we have also have some 'misses' with the cumulative approach
when the ceilometer agent was down?
No, unless the counter resets several times while your agent is down.
if you have:
Time | Value
0 | 10
1 | 30
2 | 50
3 | 80
4 | 100
If your delta-pollster is down at 1 and 2, you restart at 3,
therefore at 4 you'll send 20 as usage (100 minus 80).
So you miss the delta between 10 (time 0) and 80 (time 3)
(therefore 70 for free!). If
On Thu, Nov 1, 2012 at 1:31 PM, Eoghan Glynn egl...@redhat.com wrote:
if you have:
Time | Value
0 | 10
1 | 30
2 | 50
3 | 80
4 | 100
If your delta-pollster is down at 1 and 2, you restart at 3,
therefore at 4 you'll send 20 as usage (100 minus 80).
So you miss
On Thu, Nov 01 2012, Eoghan Glynn wrote:
What would be the best way to achieve this? A small sqlite DB
per-agent, or even simpler just a pickled dict? The latter would
avoid the complexity of DB versioning and migration.
At the risk of repeating myself, can I stress again how much we don't
On Thu, Nov 01 2012, Eoghan Glynn wrote:
Well local persistence of the prev times would still be of use I think
for the in-pollster CPU util % calculation (as discussed here[1]).
Allright, so that may be needed, but not in the pollster. It'll be
needed in the CW publisher that will compute
On Wed, Oct 31 2012, 吴亚伟 wrote:
1) '12389000' nanoseconds means '123.89' seconds or two minutes,it
seem like to be 1238.9 seconds actually, is there something wrong ?
Why do you think it's 1238.9 seconds?
2) If I never reboot or suspend vm_1, will the 'counter_volume' of cpu
usage
Hi Yawei Wu,
The root of the confusion is the fact the cpu meter is reporting
the cumlative cpu_time stat from libvirt. This libvirt counter is
reset when the associated qemu process is restarted (an artifact
of how cpuacct works).
So when you stop/start or suspend/resume, a fresh qemu process
Not at all. It means the CPU time consumed is reset to 0, but
that's not an issue in itself, the API should be capable to
deal with that if you ask for the total usage.
Would that total usage be much more apparent if we started
metering the delta between CPU times on subsequent polling
On Wed, Oct 31 2012, Eoghan Glynn wrote:
Would that total usage be much more apparent if we started
metering the delta between CPU times on subsequent polling
periods as a gauge measure? (As opposed to treating it as
a cumulative measure)
I'm rather against the idea of transforming all
I don't think (max - min) would suffice to give an accurate
measure of the actual CPU time used, as the counter may have
reset multiple times in the course of the requested duration.
It is, because /max in the API should be aware of the fact a
reset can occur and computes accordingly.
On Wed, Oct 31 2012, Eoghan Glynn wrote:
A-ha, OK, so not so much (max - min) as:
(\Sigma local maxima) - first
Yeah, excuse my math. :)
Sounds computationally expensive to produce on the fly, but maybe
the local maxima can be efficiently recorded as the data is being
ingested.
Yes
On Wed, Oct 31, 2012 at 10:23 AM, Eoghan Glynn egl...@redhat.com wrote:
Hi Yawei Wu,
The root of the confusion is the fact the cpu meter is reporting
the cumlative cpu_time stat from libvirt. This libvirt counter is
reset when the associated qemu process is restarted (an artifact
of how
On Wed, Oct 31, 2012 at 11:25 AM, Eoghan Glynn egl...@redhat.com wrote:
I don't think (max - min) would suffice to give an accurate
measure of the actual CPU time used, as the counter may have
reset multiple times in the course of the requested duration.
It is, because /max in the
On Wed, Oct 31 2012, Doug Hellmann wrote:
Is that better than just reporting the data in a more easily digested
format in the first place?
IMHO yes.
Julien, I don't understand your comment about losing data if your system
is not launched to compute delta. Can you clarify what you mean
If your pollster is not running to compute delta and you have
no state stored, you'll miss a part of what has been used.
Would we have also have some 'misses' with the cumulative approach
when the ceilometer agent was down?
If I understood the (\Sigma local maxima)-first idea correctly,
the
On Wed, Oct 31 2012, Eoghan Glynn wrote:
Would we have also have some 'misses' with the cumulative approach
when the ceilometer agent was down?
No, unless the counter resets several times while your agent is down.
But delta has the same issue.
If I understood the (\Sigma local maxima)-first
Would we have also have some 'misses' with the cumulative approach
when the ceilometer agent was down?
No, unless the counter resets several times while your agent is down.
But delta has the same issue.
If I understood the (\Sigma local maxima)-first idea correctly,
the usage up to
22 matches
Mail list logo
