Retention Policies in Routing Director
Use this topic to learn about the different retention policies used in Routing Director.
A retention policy is the period of time for which data is retained in the various databases before being purged. Retention policies in Routing Director vary by use case components and are dependent on the database and services used by the features. The following sections list the retention policies for the different use cases and components in Routing Director.
Observability
|
Feature |
Retention Policy |
|---|---|
|
KPIs and events |
Stored for seven days. You can increase the KPI data retention period beyond the default one-week limit. For information on editing the retention period and deploying the updates, see Update VictoriaMetrics. CAUTION: Increasing the retention period requires additional disk space. The exact storage requirements depend on the configured retention duration and the volume of KPI data collected. For an estimate of the additional disk space needed, contact your Juniper Sales Representative. |
|
Device logs |
Stored for seven days. |
|
Device alerts |
Purged two hours after the alert is closed. |
|
Device alarms |
Stored for 6 months. |
Service Orchestration
Table 2 lists the retention policies used in service orchestration.
| Feature | Retention Policy |
|---|---|
|
Service instance |
Stored until the service is deleted. |
|
Service order history |
Stored until the service is deleted. |
|
Service order modifications |
Stored in the audit log. |
|
Device configuration modifications |
Stored in the audit log |
|
Workflow logs in Airflow |
Stored in the PVC at
/opt/airflow/mount/logs, with a default
storage capacity of 10-GB. A DAG,
To retain logs for a longer period, increase the PVC size to allocate more storage space. |
Active Assurance
Table 3 lists information on the retention policy for metrics related to a stream.
| Metrics for a Stream | Retention Policy |
|---|---|
|
Raw Data |
7 days Note:
Active Assurance does not store the raw data forever. As the data gets older, the data is stored at a lower resolution (concise version of a data). This process is called as data rollup. Data can be rolled up for a period 5 minutes. |
|
5 minutes data rollup |
365 days |
Network Optimization and Planner
Table 4 lists the retention policies used by the Network Optimization and Planner features.|
Data |
Retention Policy |
|---|---|
| Cleanup Frequency |
1 through 10 days |
| Simulation Reports |
1 through 180 days |
| LSP Event History |
1 through 35 days |
Table 5 lists the retention policies for Network Optimization's VictoriaMetrics Database.
| VictoriaMetrics Database | Retention Policy |
|---|---|
| Raw data | 7 days Note:
Network Optimization does not store the raw data forever. As the data gets older, the data is stored at a lower resolution (concise version of a data). This process is called as data rollup. Data can be rolled up daily or hourly. |
| Hourly and daily rollup data | 30 days |
Administration
Table 6 lists the retention policies used by the administration features.|
Data |
Retention Policy |
|---|---|
|
Audit logs |
3 months |
|
System logs |
30 days |
|
Device backups |
2 months |
Infrastructure
Table 7 lists the retention policies used by the Routing Director infrastructure.
|
Data |
Retention Policy |
|---|---|
|
OpenSearch data |
Indices with *-_yyyymm or *__yyyymm or *_yyyymm-xxxxxxx names are stored for the last three months. Indices with *-_yyyymmdd or *__yyyymmdd names are stored for the last 30 days. An automatic cleanup script runs every day at midnight to clean up indices that have exceeded their retention period. However, if the corresponding application cleans up the application data earlier, the application cleanup task will override the OpenSearch retention policy. |
|
Health check reports |
30 days Note: You can configure the retention policy
for health check reports in the Manage Organization Settings
page (Settings Menu > System Settings.
For more information, see Manage Organization Settings.
|