ids.alfacom.it/deployment/TROUBLESHOOTING_SYSLOG_PARSER.md

# 🔧 TROUBLESHOOTING: Syslog Parser Bloccato

## 📊 Diagnosi Rapida (Sul Server)

### 1. Verifica Stato Servizio
```bash
sudo systemctl status ids-syslog-parser
journalctl -u ids-syslog-parser -n 100 --no-pager
```

**Cosa cercare:**
- ❌ `[ERROR] Errore processamento file:`
- ❌ `OperationalError: database connection`
- ❌ `ProgrammingError:`
- ✅ `[INFO] Processate X righe, salvate Y log` (deve continuare ad aumentare!)

---

### 2. Verifica Database Connection
```bash
# Test connessione DB
psql -h 127.0.0.1 -U $PGUSER -d $PGDATABASE -c "SELECT COUNT(*) FROM network_logs WHERE timestamp > NOW() - INTERVAL '5 minutes';"
```

**Se torna 0** → Parser non sta scrivendo!

---

### 3. Verifica File Log Syslog
```bash
# Log syslog in arrivo?
tail -f /var/log/mikrotik/raw.log | head -20

# Dimensione file
ls -lh /var/log/mikrotik/raw.log

# Ultimi log ricevuti
tail -5 /var/log/mikrotik/raw.log
```

**Se nessun log nuovo** → Problema rsyslog o router!

---

## 🐛 Cause Comuni di Blocco

### **Causa #1: Database Connection Timeout**
```python
# syslog_parser.py usa connessione persistente
self.conn = psycopg2.connect()  # ← può scadere dopo ore!
```

**Soluzione:** Riavvia il servizio
```bash
sudo systemctl restart ids-syslog-parser
```

---

### **Causa #2: Eccezione Non Gestita**
```python
# Loop si ferma se eccezione non gestita
except Exception as e:
    print(f"[ERROR] Errore processamento file: {e}")
    # ← Loop terminato!
```

**Fix:** Il parser ora continua anche dopo errori (v2.0+)

---

### **Causa #3: File Log Ruotato da Rsyslog**
Se rsyslog ruota il file `/var/log/mikrotik/raw.log`, il parser continua a leggere il file vecchio (inode diverso).

**Soluzione:** Usa logrotate + postrotate signal
```bash
# /etc/logrotate.d/mikrotik
/var/log/mikrotik/raw.log {
    daily
    rotate 7
    compress
    postrotate
        systemctl restart ids-syslog-parser
    endscript
}
```

---

### **Causa #4: Cleanup DB Troppo Lento**
```python
# Cleanup ogni ~16 minuti
if cleanup_counter >= 10000:
    self.cleanup_old_logs(days_to_keep=3)  # ← DELETE su milioni di record!
```

Se il cleanup impiega troppo tempo, blocca il loop.

**Fix:** Ora usa batch delete con LIMIT (v2.0+)

---

## 🚑 SOLUZIONE RAPIDA (Ora)

```bash
# 1. Riavvia parser
sudo systemctl restart ids-syslog-parser

# 2. Verifica che riparta
sudo journalctl -u ids-syslog-parser -f

# 3. Dopo 1-2 min, verifica nuovi log nel DB
psql -h 127.0.0.1 -U $PGUSER -d $PGDATABASE -c \
  "SELECT COUNT(*) FROM network_logs WHERE timestamp > NOW() - INTERVAL '2 minutes';"
```

**Output atteso:**
```
 count 
-------
  1234  ← Numero crescente = OK!
```

---

## 🔒 FIX PERMANENTE (v2.0)

### **Migliorie Implementate:**

1. **Auto-Reconnect** su DB timeout
2. **Error Recovery** - continua dopo eccezioni
3. **Batch Cleanup** - non blocca il processing
4. **Health Metrics** - monitoring integrato

### **Deploy Fix:**
```bash
cd /opt/ids
sudo ./update_from_git.sh
sudo systemctl restart ids-syslog-parser
```

---

## 📈 Metriche da Monitorare

1. **Log/sec processati**
   ```sql
   SELECT COUNT(*) / 60.0 AS logs_per_sec 
   FROM network_logs 
   WHERE timestamp > NOW() - INTERVAL '1 minute';
   ```

2. **Ultimo log ricevuto**
   ```sql
   SELECT MAX(timestamp) AS last_log FROM network_logs;
   ```

3. **Gap detection** (se ultimo log > 5 min fa → problema!)
   ```sql
   SELECT NOW() - MAX(timestamp) AS time_since_last_log 
   FROM network_logs;
   ```

---

## ✅ Checklist Post-Fix

- [ ] Servizio running e active
- [ ] Nuovi log in DB (ultimo < 1 min fa)
- [ ] Nessun errore in journalctl
- [ ] ML backend rileva nuove anomalie
- [ ] Dashboard mostra traffico real-time

---

## 📞 Escalation

Se il problema persiste dopo questi fix:
1. Verifica configurazione rsyslog
2. Controlla firewall router (UDP:514)
3. Test manuale: `logger -p local7.info "TEST MESSAGE"`
4. Analizza log completi: `journalctl -u ids-syslog-parser --since "1 hour ago" > parser.log`