Time Series Billing Items¶

Update Notes¶

Guance completed the upgrade of GuanceDB's proprietary time series database on April 23, 2023. The new GuanceDB differs from the old time series engine and is a single-metric time series engine. Although it still has the concept of a measurement (Measurement), each metric will have its own independent time series.

As a result, Guance's logic for counting time series has also changed:

Under the new logic:

Bulk statistics have been changed to incremental statistics: That is, instead of counting all historical data stored by users previously, we now count the number of active time series that may occur each day.
Fixed pricing has been changed to tiered pricing: That is, tiered pricing will apply different prices based on the selected data retention policy.
The statistical dimension has been changed from Measurement to Metrics: Previously, the statistical dimension was based on the tag combinations under the Measurement. In the new GuanceDB time series, Guance counts the number of tag combinations generated by all data reported on the day based on the metrics dimension.

It no longer counts the number of time series stored in the time series database as before, with relatively fixed unit prices. It also counted all tag combinations under the Measurement.

What You Need to Know First¶

Two diagrams explain how to understand bulk statistics versus incremental statistics:

Guance's time series database mainly involves the following basic concepts:

Term	Description
Daily Active Time Series	Refers to the number of time series that generate new metric data on a given day. We count the time series that have generated data on the current day. If you stop collecting data, the time series fees will not be charged on the new day, but previously collected metric data can still be queried.
Measurement	Generally refers to a set corresponding to a certain statistical value. Conceptually, it is more like a table in a relational database.
Data Point	In the context of reporting metric data, it refers to a metric data sample, analogous to a row in a relational database.
Timestamp	Represents the time when the data point was generated. This can also be understood as the time when DataKit collects a metric data point and reports it via line protocol.
Metric	Field, usually stores numerical data that changes over time. For example, in a CPU Measurement, common metrics include cpu_total, cpu_use, cpu_use_percent, etc.
Tag	Tags, generally store attribute information that does not change over time. For example, in a CPU Measurement, common fields like host, project are tags used to identify the actual object attributes of the metrics.

Billing Generation¶

DataKit collects metric data and reports it to a workspace. Specifically, this refers to data obtained from querying NameSpace in DQL.

When settling in Renminbi (RMB):

China SiteHong Kong and Overseas Sites

Data Retention Policy	3 Days	7 Days	14 Days	30 Days	180 Days	360 Days
China Site	¥ 0.6	¥ 0.7	¥ 0.8	¥ 1	¥ 4	¥ 7

Data Retention Policy	3 Days	7 Days	14 Days	30 Days	180 Days	360 Days
Hong Kong & Overseas Sites	¥ 1.6	¥ 1.8	¥ 2.2	¥ 2.4	¥ 8	¥ 14

When settling in US Dollars:

China SiteHong Kong and Overseas Sites

Data Retention Policy	3 Days	7 Days	14 Days	30 Days	180 Days	360 Days
China Site	$ 0.09	$ 0.1	$ 0.12	$ 0.14	$ 0.58	$ 1

Data Retention Policy	3 Days	7 Days	14 Days	30 Days	180 Days	360 Days
Hong Kong & Overseas Sites	$ 0.23	$ 0.26	$ 0.32	$ 0.35	$ 1.2	$ 2

Billing Item Statistics¶

Statistics are gathered every hour for the number of new time series within the same day, resulting in 24 data points. The maximum value among these 24 data points is taken as the actual billing quantity.

Example¶

Using the above diagram as an example:

In the old time series counting logic, there were no concepts of metrics or data points; only the number of tag combinations for the current Measurement was counted. Therefore, it was difficult to quantify the exact number of time series for users.

However, after the change, GuanceDB's time series logic counts based on the tag combinations for each metric. According to the latest logic, we can conclude that in the CPU Measurement, there are a total of 6 data points for a single metric. Each data point has a timestamp (time), one metric (cpu_use_pencent), and two tags (host, project). The first and fourth rows represent the CPU usage rate (cpu_use_pencent) of "host" named Hangzhou_test1 belonging to the "project" Guance. Similarly, the second and fifth rows represent the CPU usage rate of "host" Ningxia_test1 belonging to the "project" Guance, and the third and sixth rows represent the CPU usage rate of "host" Singapore_test1 belonging to the "project" Guance_oversea.

Based on the time series data provided, there are 3 unique time series combinations for the metric cpu_use_pencent:

"host":"Hangzhou_test1","project":"Guance"
"host":"Ningxia_test1","project":"Guance"
"host":"Singapore_test1","project":"Guance_oversea"

Similarly, to count all time series for metrics within the current workspace, simply sum up the number of time series for each metric.

Therefore, regarding the number of time series:

After Guance changed the time series logic, the number of daily time series combinations increased, but from an actual data perspective, the number of chargeable time series decreased. This is because, when using bulk statistics, assuming a data retention period of 7 days, the data would stabilize around the seventh, eighth, ninth, and tenth days. Thus, if evaluating the number of time series later, it would always be based on the total number of time series within this interval for billing purposes.

However, with incremental statistics, Guance calculates the number of active time series for the day based on the metric data. So, overall, while the number of time series combinations at the metric level increases, the number of chargeable time series decreases. Considering this increase, GuanceDB's time series pricing has shifted from a flat rate to a tiered pricing model, changing from 3 RMB per thousand to 0.6 RMB per thousand, depending on the user's chosen data retention policy. Therefore, overall, the cost of time series billing has decreased compared to before.

Cost Calculation Formula¶

Daily cost = Actual billing quantity / 1000 * Price (based on the data retention policy)

Assuming a user installs a DataKit on one host and enables default metric data collection. This host generates 600 active time series per day. The calculation steps are as follows:

How many hosts are installing DK?
Number of hosts * 600 = Daily active time series quantity
Unit price for the selected data retention policy * Daily active time series quantity / 1000 = Estimated daily cost