Commercial Plan Billing Logic¶
This document presents the conditions for generating each billable item and the logic for price calculation under the pay-as-you-go billing framework of the Commercial Plan TrueWatch product.
Concepts¶
| Term | Description |
|---|---|
| Data Storage | Custom setting of data retention periods for different data types. |
| Basic Billing | The unit price for a billable item is a fixed value. |
| Tiered Billing | The unit price for a billable item is directly linked to your chosen data storage strategy. Different storage duration strategies are bound to different pricing standards. |
Billing Cycle¶
The billing cycle is calculated daily: Workspace usage for each day is settled at 00:00 the following day. The generated daily bill is synchronized to the Billing Center. Ultimately, the system will deduct the corresponding consumption amount from the appropriate account based on your chosen settlement method.
Billable Items¶
Time Series¶
Counts the number of tag combinations corresponding to each metric in the metric data reported via DataKit by the user that day (per thousand series/day).
For more details, refer to Time Series Logic Explained.
Logs¶
Billing is based on actual feature usage and falls into two categories.
Billed by Data Entry Count¶
Data generated by features like Logs, Events, and Synthetic Tests (per million entries/day):
- If the "Custom Multiple Indices" feature is enabled for logs, the daily data increment is counted according to different indices, and the actual cost is calculated based on the unit price corresponding to the data storage strategy.
- Events include those generated by monitoring module configurations (monitors, SLO), events reported by Intelligent Inspection, and custom events reported by users.
- Synthetic data reported by self-built Synthetic Testing nodes.
- The cost for Events and Synthetic Testing data defaults to using the unit price corresponding to the "default" log index's data storage strategy.
Warning
Depending on the chosen storage type, oversized log entries are split into multiple entries for billing:
-
ES Storage: If a log entry exceeds 10 KB, the billed count for that entry = Integer (Log size / 10 KB)
-
SLS Storage: If a log entry exceeds 2 KB, the billed count for that entry = Integer (Log size / 2 KB)
If a single data entry is smaller than the above limits, it is still counted as 1 entry.
Billed by Ingested Traffic¶
The size of the raw log write traffic reported by the user (per GB /day).
Warning
Log data is billed by entry count by default. To switch to billing by ingested traffic, please contact your customer manager.
Data Forwarding¶
Billing is based on the data forwarding archive type and falls into two categories.
External Storage Forwarding Traffic Statistics¶
Aggregates forwarding traffic (after compression) based on external archive types for the current workspace, counts the daily increment, and bills accordingly (per GB /day).
Internal Storage Forwarding Traffic Statistics¶
Aggregates forwarding traffic based on internal storage types for the current workspace, counts the total volume, and bills accordingly (per GB /day).
Sensitive Data Scanning Traffic¶
The size of the original traffic of sensitive data detected based on scanning rules (per GB /day).
For example: If log data A needs to be scanned and three fields within it require desensitization rule processing, billing will apply separately for the desensitization scanning of these three fields.
Security Detection Scanning Traffic¶
The size of data (after compression) actually scanned by security detection rules daily (per GB /day).
Network¶
The number of hosts counted in the network data reported by eBPF within the workspace (per host reporting network data/day).
Trace¶
Generally, if the number of Traces is greater than or equal to 1/10 of the number of Spans, the system uses the Trace count for final billing settlement by default. Otherwise, the Span count is used for billing settlement.
Therefore, based on actual statistics, billing falls into two categories.
By Trace Count¶
Obtains the daily count of newly reported Traces by deduplicating trace_id (per million Traces).
By Span Count¶
Counts the daily number of newly reported Spans (per ten million Span entries).
APM Profile¶
Counts the number of reported APM Profile data entries (per ten thousand Profiles /day).
Billing Note
Profile data mainly consists of two parts: basic attribute data + Profile analysis file.
-
If the Profile analysis file size exceeds 300 KB, the data will be split into multiple entries for billing.
-
Billed entry count formula: Integer (Profile analysis file size / 300 KB)
-
If the analysis file is smaller than 300 KB, it is billed as 1 entry.
RUM PV¶
Counts the number of reported page views from user visits (per ten thousand PVs /day).
Warning
In the latest TrueWatch billing adjustment, the larger value between "count/100" and the actual PV count will be used for daily billing.
Whether it's an SPA (Single Page Application) or MPA (Multi-Page Application), each user visit to a page (including refresh or re-entry) counts as 1 PV.
Session Replay¶
Counts the number of Sessions that actually generated session replay data. Generally obtained by counting the number of session_ids in Session data where has_replay:true exists (per thousand Sessions /day).
Billing Note
-
If there are Sessions with extremely long activity, the Session will be split into multiple entries for billing based on
time_spent. -
If Session
time_spent> 4 hours, billed count = Integer (time_spent/ 4 hours); -
If Session
time_spentis less than the above 4 hours, it is still billed as 1 Session.
Synthetic Tests¶
Initiates Synthetic Testing tasks and retrieves results through the TrueWatch provided testing nodes. Counts the number of new test data entries added within each hourly interval (per ten thousand API tests/day).
Warning
Since Synthetic Testing data is currently stored in the default log index, DQL queries or statistics need to add the following filter conditions to query Synthetic Testing data.
index = ['default'], source = [‘http_dial_testing',‘tcp_dial_testing’,'icmp_dial_testing','websocket_dial_testing']
Triggers¶
Costs generated by using features like anomaly detection, generating metrics, etc. (per ten thousand executions/day).
-
Initiating scheduled detection tasks for monitors, SLOs, etc. Among these, each execution of monitor mutation detection, range detection, outlier detection, and log detection counts as 5 trigger executions; other detection types count as 1 execution. Additionally, if the detection interval exceeds 15 minutes, the excess part adds 1 trigger execution per 15 minutes.
-
Intelligent Monitoring: Each execution of host, log, or application intelligent detection counts as 10 trigger executions; each execution of user access intelligent detection counts as 100 trigger executions.
-
Each DataKit/OpenAPI query counts as 1 trigger execution.
-
Each query for generating metrics counts as 1 trigger execution.
-
Each use of an advanced function provided by DataFlux Func counts as 1 trigger execution.
- Each hit on an escalation policy records 100 trigger executions when sending a notification.
Calculation Example
Monitor trigger count examples:
- Normal case example: Assuming one execution of "Mutation Detection" is calculated as 5 trigger executions.
- Example with exceeded detection interval: If the detection interval is 30 minutes, the excess is calculated by adding 1 per 15 minutes (rounded up). For example, one execution of "Outlier Detection" is calculated as 6 trigger executions.
- Example with multiple detection types and exceeded interval: Executing two "Range Detections" with a combined detection interval of 60 minutes is calculated as 13 trigger executions (2 detections * 5 + 3 excess intervals).
Intelligent Monitoring trigger count example: Assuming one execution of "Host Intelligent Monitoring" is calculated as 10 trigger executions.
Error Issue Records¶
Counts the daily number of new Issue data entries, including Issue data generated by the Error Center (per 1,000 data entries/day).
Scheduled Reports¶
The number of times scheduled reports are sent daily within the workspace (per time/day).
Central Pipeline¶
The size of raw log data processed by the central Pipeline (per GB /day).
SMS¶
The number of SMS messages sent that day (per 10 messages/day).
Phone (IVR)¶
The number of voice notifications sent daily (per time/day).