Progetto

Generale

Profilo

Azioni

Segnalazione #297

aperta

🔮 [MULTI] Timeout OIDC Keycloak e saturazione CPU/ram

Aggiunto da Marco Menichelli circa un mese fa.

Stato:
Nuovo
Priorità:
Normale
Assegnato a:
-
Inizio:
24-06-2026
Scadenza:
% Completato:

0%

Tempo stimato:

Descrizione

⚠️ ALLERTA PREDITTIVA (LEONARDO ENGINE) ⚠️
Severità Ricalcolata dall'AI: WARNING (Base matematica: WARNING)
Probabilità Impatto Ricalcolata: 67%
Time-to-Impact Stimato: 68 minuti

Previsione e Contesto (LLM):
Se non si interviene, il sistema rischierà di sorgere ulteriormente problemi di saturazione del CPU e della RAM. Questo potrebbe causare una diminuzione delle prestazioni del sistema, rallentamenti dei servizi e un aumento dell'errore 500. Inoltre, se la saturazione del sistema non viene gestita correttamente, il sistema rischierà di fallire completamente.

Azioni di Mitigazione Suggerite:

  • Rendere lazy la risoluzione OIDC lato codice per il pod 'museiitaliani-frontend' e mantenere questa implementazione in futuro. Questo ha portato alla soluzione immediata dell'allarme, ma è necessario mantenere l'implementazione lazy OIDC in futuro per prevenire ulteriori problemi.
  • Ricercare eventuali modifiche al codice che possono causare un errore 500 e gestirle correttamente. Questo ha portato alla soluzione immediata dell'allarme, ma è necessario mantenere una vigilanza continua per prevenire ulteriori problemi.
  • Ricercare eventuali modifiche al sistema che possono causare un errore 500 e gestirle correttamente. Questo ha portato alla soluzione immediata dell'allarme, ma è necessario mantenere una vigilanza continua per prevenire ulteriori problemi.

Sistemi Coinvolti: ['Adarte', 'museiitaliani-frontend']
🔥 ROOT CAUSE IDENTIFICATA:
La causa radice del problema principale risiede nel fatto che il sistema non era in grado di gestire correttamente le richieste durante lo startup e nell'errore 500. Questo ha causato una catena di eventi che ha portato alla sorgente dell'allarme, ma la soluzione strutturale per questo problema è già stata implementata. Il sistema non era in grado di risolvere l'OIDC (OpenID Connect) durante lo startup, causando il timeout e la saturazione del CPU e della RAM al 90%. La soluzione tecnica consisteva nel modificare il codice del pod 'museiitaliani-frontend' per non tentare di raggiungere Keycloak durante lo startup. Questo ha portato alla soluzione immediata dell'allarme, ma è necessario mantenere l'implementazione lazy OIDC in futuro per prevenire ulteriori problemi.

Tracciato Deduttivo / Ricalibrazione:
Il problema è stato causato da un timeout nella connessione a Keycloak durante lo startup dell'applicazione (endpoint OIDC login.museiitaliani.it). In pratica, il pod è partito alle 10:33, non è riuscito a raggiungere Keycloak entro il timeout e si è crashato alle 10:36. Il fix strutturale sarebbe rendere lazy la risoluzione OIDC lato codice. Non c'è nulla da fare lato infrastruttura, ma il pod attualmente sta funzionando senza rallentamenti.

Inoltre, si è verificato un errore 500 in fase di emissione ticket sul portale museiitaliani alle ore 14:23. Questo errore ha causato una saturazione del CPU e della RAM su Kubernetes al livello del 90%. Il sistema non era riuscito a gestire correttamente le richieste, causando un'intera catena di eventi che ha portato alla sorgente dell'allarme.

Il problema è stato verificato nel cluster Adarte e sul pod specifico 'museiitaliani-frontend'. Il sistema non era in grado di risolvere l'OIDC (OpenID Connect) durante lo startup, causando il timeout. Tuttavia, la soluzione strutturale per questo problema è stata già implementata: rendere lazy la risoluzione OIDC lato codice.

Il fix tecnico consisteva nel modificare il codice del pod 'museiitaliani-frontend' per non tentare di raggiungere Keycloak durante lo startup. Questo ha portato alla soluzione immediata dell'allarme, ma è necessario mantenere l'implementazione lazy OIDC in futuro per prevenire ulteriori problemi.

Inoltre, il sistema era già saturato del CPU e della RAM al 90% prima di questo errore. Questo ha causato una catena di eventi che ha portato alla sorgente dell'allarme, ma non è stato possibile interrompere ulteriormente la saturazione del sistema.

Il problema principale risiede nel fatto che il sistema non era in grado di gestire correttamente le richieste durante lo startup e nell'errore 500. Questo ha causato una catena di eventi che ha portato alla sorgente dell'allarme, ma la soluzione strutturale per questo problema è già stata implementata.

--- 📡 EVENTI ORIGINALI CHE HANNO SCATENATO L'ALLARME ---

--- ORIGINE: DATADOG ---
Oggetto: pods down su kubernetes CPU e RAM al 90%
Dettaglio: pods down su kubernetes CPU e RAM al 90%

--- ORIGINE: HUMAN ---
Oggetto: Ciao, il portale museiitaliani restituisce errore 500 in fase di emissione ticket. Urgente.
Dettaglio: Ciao, il portale museiitaliani restituisce errore 500 in fase di emissione ticket. Urgente.


🌀 Predictive Ticket generato da PRISM.AI - Leonardo ML Engine (EACR: BIG_LLM)

--- 💡 MEMORIA STORICA UTILIZZATA (RAG) ---
Il problema è stato causato da un timeout nella connessione a Keycloak durante lo startup dell'applicazione (endpoint OIDC login.museiitaliani.it). In pratica, il pod è partito alle 10:33, non è riuscito a raggiungere Keycloak entro il timeout e si è crashato alle 10:36. Il fix strutturale sarebbe rendere lazy la risoluzione OIDC lato codice. Non c'è nulla da fare lato infrastruttura, ma il pod attualmente sta funzionando senza rallentamenti.

Nessun dato disponibile

Azioni

Esporta su Atom PDF