dashboard/RETENTION_POLICY.md

# 📅 Modification de la Politique de Rétention

## 🎯 Objectif

Augmenter la durée de conservation des données dans ClickHouse pour pouvoir investiguer des incidents plus anciens.

---

## 📊 Durées de rétention actuelles

| Table / Vue | Ancien TTL | Nouveau TTL | Fichier |
|-------------|------------|-------------|---------|
| `view_dashboard_entities` | 30 jours | **90 jours** | `deploy_dashboard_entities_view.sql` |
| `view_dashboard_user_agents` | 7 jours | **90 jours** | `deploy_user_agents_view.sql` |
| `audit_logs` | 90 jours | 90 jours | `deploy_audit_logs_table.sql` |
| `ml_detected_anomalies` | ~1-6h* | **30 jours** (recommandé) | `bot_detector_ai` |

*La table `ml_detected_anomalies` est gérée par le service `bot_detector_ai`

---

## 🔧 Méthode 1: Appliquer sur tables existantes (RECOMMANDÉ)

### Étape 1: Exécuter le script SQL

```bash
clickhouse-client --host test-sdv-anubis.sdv.fr --port 8123 \
  --user admin --password SuperPassword123! \
  < update_retention_policy.sql
```

### Étape 2: Vérifier les modifications

```sql
SELECT 
    name,
    engine,
    create_table_query
FROM system.tables
WHERE database = 'mabase_prod'
  AND name LIKE 'view_dashboard%'
FORMAT Vertical;
```

### Étape 3: (Optionnel) Forcer l'application du TTL

```sql
-- Attention: Peut prendre plusieurs minutes
OPTIMIZE TABLE mabase_prod.view_dashboard_entities FINAL;
OPTIMIZE TABLE mabase_prod.view_dashboard_user_agents FINAL;
```

---

## 🔧 Méthode 2: Recréer les tables avec le nouveau TTL

### Pour `view_dashboard_entities`

```bash
clickhouse-client --host test-sdv-anubis.sdv.fr --port 8123 \
  --user admin --password SuperPassword123! \
  --database mabase_prod \
  < deploy_dashboard_entities_view.sql
```

### Pour `view_dashboard_user_agents`

```bash
clickhouse-client --host test-sdv-anubis.sdv.fr --port 8123 \
  --user admin --password SuperPassword123! \
  --database mabase_prod \
  < deploy_user_agents_view.sql
```

---

## 🔧 Méthode 3: Modifier `ml_detected_anomalies`

Cette table est gérée par le service `bot_detector_ai`. Deux options :

### Option A: Modification directe (si accès)

```sql
-- Vérifier le TTL actuel
SHOW CREATE TABLE mabase_prod.ml_detected_anomalies;

-- Modifier le TTL (exemple: 30 jours)
ALTER TABLE mabase_prod.ml_detected_anomalies 
MODIFY TTL detected_at + INTERVAL 30 DAY;

-- Appliquer immédiatement
OPTIMIZE TABLE mabase_prod.ml_detected_anomalies FINAL;
```

### Option B: Modifier la configuration de bot_detector_ai

Dans le fichier de configuration de `bot_detector_ai` (probablement `config.yaml` ou `settings.py`):

```yaml
# Exemple de configuration
clickhouse:
  retention_days: 30  # Au lieu de 1 ou 7
```

Puis redémarrer le service :

```bash
docker compose restart bot_detector_ai
```

---

## 📈 Impact sur le stockage

### Estimation de l'augmentation

| Table | Données/jour | 30 jours → 90 jours | Impact |
|-------|--------------|---------------------|--------|
| `view_dashboard_entities` | ~100 MB | ×3 | +200 MB |
| `view_dashboard_user_agents` | ~50 MB | ×13 | +600 MB |
| `ml_detected_anomalies` | ~1 GB | ×30 | +29 GB |

**Total estimé:** +30 GB pour 90 jours de rétention

### Vérifier l'espace disque actuel

```sql
SELECT 
    table,
    formatReadableSize(sum(data_compressed_bytes)) AS compressed_size,
    formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed_size,
    count() AS rows
FROM system.parts
WHERE database = 'mabase_prod'
  AND table LIKE 'view_dashboard%'
GROUP BY table
ORDER BY compressed_size DESC;
```

---

## ✅ Vérification après modification

### Test 1: Subnet ancien (ex: 212.30.36.0/24)

```bash
# Via API
curl "http://192.168.1.2:8000/api/entities/subnet/212.30.36.0/24?hours=2160"

# Via ClickHouse
SELECT count() 
FROM mabase_prod.view_dashboard_entities 
WHERE entity_type = 'ip' 
  AND entity_value LIKE '212.30.36.%'
  AND log_date >= now() - INTERVAL 90 DAY;
```

### Test 2: Vérifier les dates minimales

```sql
-- Date la plus ancienne dans view_dashboard_entities
SELECT min(log_date) AS oldest_date
FROM mabase_prod.view_dashboard_entities;

-- Date la plus ancienne dans view_dashboard_user_agents
SELECT min(log_date) AS oldest_date
FROM mabase_prod.view_dashboard_user_agents;

-- Date la plus ancienne dans ml_detected_anomalies
SELECT min(detected_at) AS oldest_date
FROM mabase_prod.ml_detected_anomalies;
```

---

## 🚨 Points d'attention

### 1. Espace disque

Vérifiez l'espace disque disponible avant d'augmenter la rétention :

```bash
df -h /var/lib/clickhouse
```

### 2. Performance des requêtes

Plus de données = requêtes plus lentes. Solutions :
- Ajouter des index
- Utiliser des agrégations pré-calculées
- Partitionner par mois (déjà fait)

### 3. Nettoyage automatique

ClickHouse applique le TTL automatiquement pendant les opérations de merge. Les données ne sont pas supprimées instantanément.

### 4. Backup

Faire un backup avant de modifier les tables :

```bash
clickhouse-backup create mabase_prod_backup_$(date +%Y%m%d)
```

---

## 📚 Références

- [ClickHouse TTL Documentation](https://clickhouse.com/docs/en/sql-reference/statements/alter/ttl)
- [ClickHouse MergeTree TTL](https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/#mergetree-table-ttl)
- [ClickHouse System Tables](https://clickhouse.com/docs/en/operations/system-tables/)

---

## 🆘 Dépannage

### Problème: "TTL expression must return Date or DateTime"

**Solution:** Vérifier que la colonne utilisée dans le TTL est de type Date ou DateTime

```sql
-- Vérifier les types de colonnes
DESCRIBE TABLE mabase_prod.view_dashboard_entities;
```

### Problème: "Table is in readonly mode"

**Solution:** La table est gérée par une vue matérialisée. Modifier la vue, pas la table.

### Problème: OPTIMIZE prend trop de temps

**Solution:** Exécuter en arrière-plan avec un timeout plus long

```sql
-- Exécuter avec timeout de 1 heure
SET max_execution_time = 3600;
OPTIMIZE TABLE mabase_prod.view_dashboard_entities FINAL;
```

---

**Dernière mise à jour:** 2026-03-15  
**Version:** 1.0