ids.alfacom.it/deployment/TROUBLESHOOTING_SYSLOG_PARSER.md

🔧 TROUBLESHOOTING: Syslog Parser Bloccato

📊 Diagnosi Rapida (Sul Server)

1. Verifica Stato Servizio

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

# 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

# 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

# syslog_parser.py usa connessione persistente
self.conn = psycopg2.connect()  # ← può scadere dopo ore!

Soluzione: Riavvia il servizio

sudo systemctl restart ids-syslog-parser

---

Causa #2: Eccezione Non Gestita

# 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

# /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

# 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)

# 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:

cd /opt/ids
sudo ./update_from_git.sh
sudo systemctl restart ids-syslog-parser

---

📈 Metriche da Monitorare

1. Log/sec processati

   SELECT COUNT(*) / 60.0 AS logs_per_sec 
   FROM network_logs 
   WHERE timestamp > NOW() - INTERVAL '1 minute';
   

2. Ultimo log ricevuto

   SELECT MAX(timestamp) AS last_log FROM network_logs;
   

3. Gap detection (se ultimo log > 5 min fa → problema!)

   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