Segnalazione #297
aperta🔮 [MULTI] Timeout OIDC Keycloak e saturazione CPU/ram
0%
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