Add documents for timezone and ttl (#2607)

This commit is contained in:
吴晟 Wu Sheng 2019-05-07 07:27:41 +08:00 committed by GitHub
parent b1b11e7295
commit 12f9991eef
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 35 additions and 1 deletions

View File

@ -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

View File

@ -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.

View File

@ -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.