DalmatinerDB stores metrics in a periodic fashion, so for every second that passes (assuming your buckets are set up to have a 1s resolution) either a “received” metric’s value or a “non-received” metric is written to the database.
When you miss writing a metric, DalmatinerDB does not write a ‘0’ but it does write an explicit ‘non-value’. This has multiple advantages, not only is it very nice for data compression (ZFS handles zero blocks very well), but it also allows us to differentiate between the two for a specific period.
Version 0.2.0 of DalmatinerDB (the current development branch) will include a confidence function which helps to examine how confident DalmatinerDB can be with a given value or aggregate, let’s look at it using an example below.
When querying a metric, what we usually do, is look at aggregates over time. DalmatinerDB will try to fill up the missing values with the last or next value it can find, so usually you will never notice this. Let’s look at a simple query:
SELECT avg('dalmatinerdb@192.168.1.43'.'mput'.'count' BUCKET 'dalmatinerdb', 1m) AS 'avg' LAST 1h
This query averages the metric count of multi-puts done every minute. That’s exactly what we’d want to see, but (and there is always a but) this does not answer the question concerning how confident we should be about those values? So to address this, let’s add a second measurement into the mix:
SELECT confidence(avg('dalmatinerdb@192.168.1.43'.'mput'.'count' BUCKET 'dalmatinerdb', 1m)) AS 'confidence', avg('dalmatinerdb@192.168.1.43'.'mput'.'count' BUCKET 'dalmatinerdb', 1m) AS 'avg' LAST 1h
With this second measurement, we can now see two graphs displayed, the previous graph (now in purple), and the addition of the blue one, which shows us how confident DalmatinerDB is in the values. This is calculated along with the aggregations, so if 6 values out of a given minute are missing, we get a confidence of value of 90%. As we can see in the above example, DalmatinerDB is very confident in those values with every point being at about 100%.
DalmatinerDB stores metric, why is the uuid less 6 bit than the uuid of vm?
thanks
Hi,
DalmatinerDB stores the metric as it gets it. Kstat is reporting the uuid’s 6 byte short nothing much we can do about that if you don’t like that please take it up with the illumos folks.