Monitoraggio Uptime con AI: Predire i Downtime Prima che Accadano

Il Monitoraggio Uptime Tradizionale È Reattivo. L’AI Lo Rende Predittivo.

UptimeRobot pinga il tuo sito ogni 5 minuti. Se non risponde, ti manda un alert. Apri l’email alle 3 di notte, il sito è down da 20 minuti, il cliente è già arrabbiato. Troppo tardi.

Il monitoraggio AI funziona diversamente. Analizza i pattern: tempo di risposta che sale gradualmente da 200ms a 800ms nell’arco di 3 giorni, errori 502 sporadici ogni martedì alle 14 (quando parte il backup), picchi di memoria che si avvicinano al limite. Riconosce i segnali di un downtime imminente e ti avvisa prima.

Non è fantascienza. È analisi di serie temporali con LLM. E con i dati che già raccogli, puoi implementarlo oggi.

I Segnali che Precedono un Downtime

In 15 anni di gestione WordPress, abbiamo identificato pattern ricorrenti. Il sito non crolla all’improvviso (tranne in caso di attacco DDoS o failure hardware). Di solito dà segnali per ore o giorni prima:

Un umano può notare questi pattern. Ma non su 30 siti. Non 24/7. L’AI sì.

L’Implementazione: Da Dati a Predizione

Step 1: raccogliere i dati giusti

Serve un sistema che registri queste metriche con granularità al minuto (o almeno ogni 5 minuti):

# Script bash per raccolta metriche (da eseguire via cron ogni 5 min)
#!/bin/bash
SITE_URL="https://tuosito.com"
TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)

# Response time
RESPONSE_TIME=$(curl -o /dev/null -s -w '%{time_total}' "$SITE_URL")
HTTP_CODE=$(curl -o /dev/null -s -w '%{http_code}' "$SITE_URL")

# Risorse server (se hai accesso SSH)
MEMORY_USED=$(free -m | awk 'NR==2{printf "%.1f", $3*100/$2}')
DISK_USED=$(df -h / | awk 'NR==2{print $5}' | tr -d '%')
CPU_LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | tr -d ' ')

# Log in CSV
echo "$TIMESTAMP,$RESPONSE_TIME,$HTTP_CODE,$MEMORY_USED,$DISK_USED,$CPU_LOAD" \
  >> /var/log/site-metrics.csv

Dopo 7 giorni hai circa 2000 data point. Dopo 30 giorni, 8600. Abbastanza per i pattern.

Step 2: analisi AI dei pattern

function analyze_uptime_patterns(string $site_url): array {
    $claude = $GLOBALS['claude'];
    
    // Carica gli ultimi 7 giorni di metriche
    $csv_path = "/var/log/site-metrics-{$site_url}.csv";
    $metrics = file_get_contents($csv_path);
    
    // Prendi solo gli ultimi 2000 data point (7 giorni)
    $lines = explode("\n", trim($metrics));
    $recent = array_slice($lines, -2000);
    $data = implode("\n", $recent);
    
    $prompt = "Analizza queste metriche di monitoraggio WordPress (CSV: timestamp, response_time_sec, http_code, memory_pct, disk_pct, cpu_load).\n\n"
        . "Dati (ultimi 7 giorni, ogni 5 minuti):\n{$data}\n\n"
        . "Fornisci:\n"
        . "1. TREND: il response time sta salendo, scendendo, o è stabile?\n"
        . "2. ANOMALIE: ci sono pattern ricorrenti? (es: spike ogni martedì, rallentamenti notturni)\n"
        . "3. RISCHIO DOWNTIME: stima la probabilità di downtime nelle prossime 48 ore (bassa/media/alta) con motivazione\n"
        . "4. AZIONE: se il rischio è medio o alto, cosa fare ADESSO per prevenire il crash\n"
        . "5. RISORSE: memoria e disco sono in traiettoria critica?\n\n"
        . "Rispondi in JSON strutturato.";
    
    $system = "Sei un sysadmin senior specializzato in WordPress. Analizza i dati con precisione. "
        . "Non inventare problemi se i dati sono normali. Se tutto è ok, dillo.";
    
    $result = $claude->query($prompt, [
        'system' => $system,
        'max_tokens' => 2048,
        'model' => 'claude-sonnet-4-20250514' // Sonnet basta per l'analisi
    ]);
    
    return json_decode($result['content'], true) ?? ['error' => 'Parse fallito'];
}

Step 3: alert intelligenti

// Cron giornaliero
add_action('daily_uptime_analysis', function() {
    $sites = get_managed_sites();
    
    foreach ($sites as $site) {
        $analysis = analyze_uptime_patterns($site->url);
        
        // Alert solo se il rischio è medio o alto
        $risk = $analysis['risk_level'] ?? 'bassa';
        
        if (in_array($risk, ['media', 'alta'])) {
            $message = sprintf(
                "⚠️ %s - Rischio downtime: %s\n\nMotivazione: %s\n\nAzione consigliata: %s",
                $site->url,
                strtoupper($risk),
                $analysis['risk_reason'] ?? 'N/A',
                $analysis['action'] ?? 'N/A'
            );
            
            // Notifica via email
            wp_mail(get_option('admin_email'), "Uptime Alert: {$site->url}", $message);
            
            // Opzionale: notifica Slack/Discord/Telegram
            // send_slack_notification($message);
        }
        
        // Salva l'analisi per lo storico
        update_post_meta($site->ID, '_uptime_analysis_' . date('Y-m-d'), $analysis);
    }
});

Dashboard di Monitoraggio

I dati e le analisi si accumulano. Per visualizzarli, aggiungi un widget nella dashboard WordPress:

add_action('wp_dashboard_setup', function() {
    wp_add_dashboard_widget(
        'ai_uptime_widget',
        '🤖 AI Uptime Monitor',
        function() {
            $sites = get_managed_sites();
            echo '<table style="width:100%">';
            echo '<tr><th>Sito</th><th>Rischio</th><th>Trend</th></tr>';
            
            foreach ($sites as $site) {
                $analysis = get_post_meta($site->ID, '_uptime_analysis_' . date('Y-m-d'), true);
                $risk = $analysis['risk_level'] ?? 'n/a';
                $trend = $analysis['response_time_trend'] ?? 'stabile';
                $color = $risk === 'alta' ? 'red' : ($risk === 'media' ? 'orange' : 'green');
                
                echo "<tr><td>{$site->url}</td>"
                    . "<td style='color:{$color}'>{$risk}</td>"
                    . "<td>{$trend}</td></tr>";
            }
            echo '</table>';
        }
    );
});

Limiti dell’Approccio AI

Onestà. L’AI non è una sfera di cristallo:

• Failure hardware improvvisi: un disco che muore senza warning non è predittibile. L’AI può solo analizzare i dati che ha
• Attacchi DDoS: arrivano senza preavviso nei dati normali. Serve un WAF (Cloudflare, etc.) non l’AI
• Servono dati: senza almeno 7 giorni di metriche, l’AI non ha pattern da analizzare. I primi giorni sono “ciechi”
• False positive: l’AI potrebbe segnalare un rischio alto per un picco di traffico legittimo (lancio prodotto, viral). Il contesto umano resta necessario

Detto questo, per i failure graduali (il 70-80% dei downtime WordPress), l’analisi AI dei pattern funziona. E costa meno di 5 minuti di setup giornaliero.

Confronto con Soluzioni Esistenti

La soluzione custom con Claude API non sostituisce un APM enterprise come Datadog. Ma per agenzie WordPress con 10-50 siti, è il punto ottimale: predittivo, economico, personalizzabile.

FAQ

Funziona su hosting condiviso?

La raccolta metriche server (RAM, CPU, disco) richiede accesso SSH. Su hosting condiviso puoi raccogliere solo response time e HTTP code (via curl esterno). Meno dati = predizioni meno accurate, ma funziona comunque per i pattern di response time.

Quanti dati servono per predizioni affidabili?

Minimo 7 giorni di dati (per catturare i pattern settimanali). Ideale: 30+ giorni. Con meno di 7 giorni, l’AI può solo segnalare anomalie spot, non trend.

Claude API è l’unica opzione per l’analisi?

No. Puoi usare GPT-4, Gemini, o anche modelli open-source locali (Llama, Mistral) se hai un server con GPU. Il vantaggio di Claude è la finestra di contesto da 200K token: puoi passargli 30 giorni di metriche in una singola chiamata.