HomeCasa Prompts

Piano di osservabilità: log strutturati, metriche, tracce e alert

Progetta l’osservabilità del tuo backend: SLO per percorso utente, schema dei log strutturati, metriche RED e USE, tracciamento con OpenTelemetry, alert utili e controllo dei costi. Pensato per ChatGPT, Claude, Gemini e Microsoft Copilot. Include 4 variabili personalizzabili e puoi copiarlo gratuitamente con un clic.

Intermedio · Testo · In attesa di revisione editoriale

Pensato per:

Prompt

Agisci come ingegnere SRE che progetta l’osservabilità per team piccoli e medi.

Contesto:
- Sistema e componenti: {{sistema}}
- Stack e linguaggi: {{stack}}
- Strumenti preferiti: {{strumenti}}
- Incidenti o problemi recenti: {{incidenti}}

Consegna:
1. Da tre a cinque percorsi utente critici e, per ognuno, uno SLI misurabile e una proposta di SLO con il relativo error budget. Indica gli obiettivi come proposte da validare con il business.
2. Uno schema di log strutturati in JSON: campi obbligatori (timestamp, livello, servizio, ambiente, id di traccia e di richiesta, utente pseudonimizzato, evento), quando usare ogni livello e cosa non registrare mai (password, token, dati personali completi).
3. Metriche: metodo RED per i servizi (richieste, errori, durata) e USE per le risorse (utilizzo, saturazione, errori), con nomi, label e avvertenze sulle label ad alta cardinalità.
4. Tracciamento distribuito con OpenTelemetry: cosa strumentare in automatico e cosa a mano, propagazione del contesto tra servizi e code, strategia di campionamento.
5. Alert: basati sui sintomi e sulla velocità di consumo dell’error budget, non su ogni causa; per ciascuno, gravità, chi viene avvisato e link al runbook. Elenco degli alert da eliminare o declassare.
6. Dashboard: una panoramica per servizio e una per percorso critico, con i grafici concreti.
7. Conservazione e costi: per quanto tenere ogni segnale, campionamento e come evitare che la bolletta esploda.
8. Codice d’esempio per il mio stack: middleware che aggiunge un id di richiesta, log strutturati e una metrica di latenza.
9. Un piano di adozione a 30, 60 e 90 giorni.

Vincoli:
- Non inventare volumi di traffico né prezzi degli strumenti: usa [DA COMPLETARE] e spiega come stimarli.
- Se mancano informazioni chiave, chiedimele prima di proporre gli SLO.
- Dai priorità a ciò che avrebbe aiutato a rilevare o risolvere prima gli incidenti descritti.

Come usarlo

  1. Descrivi servizi, code e database, e gli ultimi incidenti difficili da individuare.
  2. Indica se preferisci open source in self-hosting, un SaaS o gli strumenti del tuo cloud provider.
  3. Introduci prima log strutturati e id di traccia, poi metriche e alert basati sugli SLO.

Esempio d'uso

Sistema: API Django, worker Celery, PostgreSQL e Redis su Kubernetes · Strumenti: open source in self-hosting · Incidente: la coda si è bloccata per due ore e nessuno se n’è accorto finché non hanno chiamato i clienti.

Esempio di risultato

1. Percorsi critici e SLO (proposte da validare con il business)

PercorsoSLISLO proposto
Login% di richieste 2xx in < 500 ms99,5% su 28 giorni
Creare un ordine% di richieste senza 5xx99,9%
Task in background% di task avviati < 60 s dopo l’accodamento99%

È il terzo che avrebbe intercettato l’incidente: la coda non è «andata in errore», ha semplicemente smesso di avanzare.

5. Alert prioritario: coda Celery ferma

- alert: CeleryQueueStalled
  # Il nome della metrica dipende dall’exporter scelto: [DA COMPLETARE]
  expr: max(celery_queue_oldest_task_age_seconds) > 300
  for: 5m
  labels:
    severity: page
  annotations:
    summary: "Il task più vecchio aspetta da oltre 5 minuti"
    runbook: "https://wiki.interna/runbooks/coda-celery-ferma"

L’alert scatta sul sintomo (età del task più vecchio), non su una causa (CPU del worker, connessioni Redis), così copre qualsiasi motivo per cui la coda si blocchi.

Alert da declassare a ticket

  • CPU del nodo > 80% senza impatto sulla latenza.
  • Riavvii isolati di un pod che si riprende da solo…

Dati chiave

Categoria
Programmazione e sviluppo · DevOps
Tipo di output
Testo
Livello
Intermedio
Pensato per
ChatGPT, Claude, Gemini e Microsoft Copilot
Verificato in
In attesa di verifica editoriale
Variabili
Sistema e componenti, Stack e linguaggi, Strumenti preferiti e Incidenti recenti
Lingua
Italiano
Prezzo
Gratuito, senza registrazione
Aggiornato
07/11/2026

Domande frequenti

Che differenza c’è tra SLI e SLO?

Lo SLI è la misura (per esempio la percentuale di richieste di checkout riuscite in meno di 500 ms). Lo SLO è l’obiettivo per quella misura in un periodo, come il 99,5% in 30 giorni.

Perché fare alert sui sintomi e non sulle cause?

Gli alert sulle cause (CPU alta, pod riavviato) sono rumorosi e spesso non toccano l’utente. Avvisare quando l’utente ha problemi, o quando l’error budget si consuma in fretta, riduce l’affaticamento della reperibilità.

A cosa serve questo prompt?

Progetta l’osservabilità del tuo backend: SLO per percorso utente, schema dei log strutturati, metriche RED e USE, tracciamento con OpenTelemetry, alert utili e controllo dei costi.

Con quali strumenti di IA funziona?

È pensato per ChatGPT, Claude, Gemini e Microsoft Copilot. Non lo abbiamo ancora verificato in questi strumenti, quindi i risultati possono variare da uno all'altro.

Come personalizzo il prompt?

Clicca su «Personalizza» e compila le variabili (Sistema e componenti, Stack e linguaggi, Strumenti preferiti e Incidenti recenti). Il testo si aggiorna all'istante e poi puoi copiarlo con un clic. I valori vengono salvati solo nel tuo browser.

Serve esperienza per usarlo?

È di livello intermedio: conviene conoscere l'argomento per fornire un buon contesto e valutare il risultato con occhio critico.

Questo prompt è gratuito?

Sì. Tutti i prompt di HomeCasa Prompts sono gratuiti, senza registrazione né abbonamento. Puoi usarli anche in progetti professionali.

Posso fidarmi dell'output dell'IA?

Consideralo una bozza di alta qualità: verifica sempre dati, cifre e affermazioni importanti prima di pubblicare o prendere decisioni.

Prompt correlati