Add documents for timezone and ttl (#2607)
This commit is contained in:
parent
b1b11e7295
commit
12f9991eef
|
|
@ -2,7 +2,7 @@
|
|||
Setup based on which kind of probes are you going to use. If you don't understand, please read [Concepts and Designs](../concepts-and-designs/README.md) first.
|
||||
|
||||
|
||||
**Important: Please comfirm the system time on the monitored servers are same as the time on the OAP servers.**
|
||||
**Important: Please choose the timezone on UI, make it matches the timezone of your OAP backend servers.**
|
||||
|
||||
|
||||
## Download official releases
|
||||
|
|
|
|||
|
|
@ -79,7 +79,22 @@ rules targeting the analysis oal metric objects.
|
|||
scale and support high payload, you may need this.
|
||||
1. [Metric exporter](metric-exporter.md). Use metric data exporter to forward metric data to 3rd party
|
||||
system.
|
||||
1. [Time To Live (TTL)](ttl.md). Metric and trace are time series data, they would be saved forever, you could
|
||||
set the expired time for each dimension.
|
||||
|
||||
## Telemetry for backend
|
||||
OAP backend cluster itself underlying is a distributed streaming process system. For helping the Ops team,
|
||||
we provide the telemetry for OAP backend itself. Follow [document](backend-telemetry.md) to use it.
|
||||
|
||||
|
||||
## FAQs
|
||||
#### When and why do we need to set Timezone?
|
||||
SkyWalking provides downsampling time series metric features.
|
||||
Query and storage at each time dimension(minute, hour, day, month metric indexes)
|
||||
related to timezone when doing time format.
|
||||
|
||||
For example, metric time will be formatted like YYYYMMDDHHmm in minute dimension metric,
|
||||
which format process is timezone related.
|
||||
|
||||
In default, SkyWalking OAP backend choose the OS default timezone.
|
||||
If you want to override it, please follow Java and OS documents to do so.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# TTL
|
||||
In SkyWalking, there are two types of observability data, besides metadata.
|
||||
1. Record, including trace and alarm. Maybe log in the future.
|
||||
1. Metric, including such as p99/p95/p90/p75/p50, heatmap, success rate, cpm(rpm) etc.
|
||||
Metric is separated in minute/hour/day/month dimensions in storage, different indexes or tables.
|
||||
|
||||
You have following settings for different types.
|
||||
```yaml
|
||||
# Set a timeout on metric data. After the timeout has expired, the metric data will automatically be deleted.
|
||||
recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:90} # Unit is minute
|
||||
minuteMetricsDataTTL: ${SW_CORE_MINUTE_METRIC_DATA_TTL:90} # Unit is minute
|
||||
hourMetricsDataTTL: ${SW_CORE_HOUR_METRIC_DATA_TTL:36} # Unit is hour
|
||||
dayMetricsDataTTL: ${SW_CORE_DAY_METRIC_DATA_TTL:45} # Unit is day
|
||||
monthMetricsDataTTL: ${SW_CORE_MONTH_METRIC_DATA_TTL:18} # Unit is month
|
||||
```
|
||||
|
||||
- `recordDataTTL` affects **Record** data.
|
||||
- `minuteMetricsDataTTL`, `hourMetricsDataTTL`, `dayMetricsDataTTL` and `monthMetricsDataTTL` affects
|
||||
metric data in minute/hour/day/month dimensions.
|
||||
Loading…
Reference in New Issue