fix: Subnet investigation - Récupération des user-agents depuis view_dashboard_entities
- Utilisation de 2 requêtes séparées + fusion en Python - 1ère requête: ml_detected_anomalies pour les détections récentes - 2ème requête: view_dashboard_entities avec IN clause pour les user-agents - La clause IN permet d'utiliser l'index ClickHouse (splitByChar ne l'utilise pas) - PREWHERE optimise les performances de requête Problème résolu: - unique_ua était toujours à 0 car la jointure LEFT JOIN ne fonctionnait pas - La solution avec IN clause fonctionne car elle utilise l'index sur entity_value Testé avec 141.98.11.0/24: - 5 IPs, 8 détections, 65 user-agents uniques - 141.98.11.209: 68 user-agents différents Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
This commit is contained in:
SOC Analyst
243
RETENTION_POLICY.md
Normal file
243
RETENTION_POLICY.md
Normal file
@ -0,0 +1,243 @@
|
||||
# 📅 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
|
||||
Reference in New Issue
Block a user