Questo documento nel framework dell'architettura Google Cloud si basa sulle precedenti discussioni relative agli obiettivi del livello di servizio (SLO) esplorando cosa e come misurare i carichi di lavoro dei servizi più comuni. Questo documento si basa sui concetti definiti in Componenti degli obiettivi del livello di servizio.
Decidi cosa misurare
Indipendentemente dal dominio, molti servizi condividono funzionalità comuni e possono utilizzare SLO generici. Questa sezione tratta gli SLO generici per tipi di servizi diversi e fornisce spiegazioni dettagliate sugli SLI che si applicano a ogni SLO.
Ognuna delle seguenti sottosezioni identifica un particolare tipo di servizio e fornisce una breve descrizione del servizio. Poi, sotto ogni tipo di servizio sono elencati i possibili SLI, una definizione dell'indicatore e altre informazioni relative allo SLI.
Servizi basati su richiesta
Questo tipo di servizio riceve una richiesta da un client (un utente o un altro servizio), esegue alcuni calcoli, invia potenzialmente richieste di rete a un backend e restituisce una risposta al client.
Disponibilità come SLI
La disponibilità è la proporzione di richieste valide che vengono pubblicate correttamente. Il seguente elenco include le informazioni da considerare quando si utilizza la disponibilità come SLI:
- In qualità di proprietario del servizio, sei tu a decidere qual è una richiesta valida. Le definizioni comuni includono una lunghezza diversa da zero o adotta un protocollo client-server. Un metodo per valutare la validità è esaminare i codici di risposta HTTP (o RPC). Ad esempio, i codici HTTP 5xx sono errori relativi al server che vengono conteggiati a fronte di uno SLO, mentre i codici 4xx sono errori del client che non vengono conteggiati.
- Ogni codice di risposta restituito dal tuo servizio deve essere esaminato per garantire che l'applicazione utilizzi quei codici in modo corretto e coerente. Il codice è un indicatore accurato dell'esperienza d'uso del servizio da parte degli utenti? Ad esempio, come risponde un sito di e-commerce quando un utente tenta di ordinare un articolo non disponibile? La richiesta non riesce e restituisce un messaggio di errore? Il sito suggerisce prodotti simili? I codici di errore devono essere correlati alle aspettative degli utenti.
- Gli sviluppatori possono inavvertitamente usare in modo improprio gli errori. Utilizzando lo scenario non disponibile del punto precedente, uno sviluppatore potrebbe restituire per errore un errore. Tuttavia, il sistema funziona correttamente e non presenta errori. Il codice deve restituire un esito positivo, anche se l'utente non ha potuto acquistare l'articolo. Mentre i proprietari dei servizi dovrebbero essere informati dello scarso inventario, l'impossibilità di effettuare una vendita non è un errore dal punto di vista del cliente e non viene conteggiata ai fini di uno SLO.
- Un esempio di servizio più complesso è il servizio che gestisce le richieste asincrone o fornisce ai clienti un processo a lunga esecuzione. Anche se puoi mostrare la disponibilità in un altro modo, ti consigliamo di rappresentare la disponibilità in proporzione al numero di richieste valide che hanno esito positivo. La disponibilità può essere definita anche come il numero di minuti di esecuzione del carico di lavoro di un cliente (a volte indicato come approccio dei minuti buoni).
- Prendi in considerazione un servizio che offre macchine virtuali (VM). Puoi misurare la disponibilità in termini di numero di minuti dopo una richiesta iniziale in cui la VM è disponibile per l'utente.
Latenza come SLI
La latenza (o velocità) è la proporzione di richieste valide che vengono pubblicate più velocemente di una soglia. Di conseguenza, la latenza indica la velocità del servizio e può essere misurata calcolando la differenza tra l'ora di inizio e l'ora di fine di un determinato tipo di richiesta. Ricorda che questa è la percezione della latenza da parte dell'utente e che i proprietari dei servizi di solito misurano questo valore in modo troppo preciso. In realtà, gli utenti non sono in grado di distinguere tra un aggiornamento di 100 ms e un aggiornamento di 300 ms e potrebbero persino accettare risposte comprese tra 300 ms e 1000 ms normalmente. Per ulteriori informazioni, consulta la sezione Modello ferroviario.
Sviluppa metriche basate sull'attività che si concentrano sull'utente. Di seguito sono riportati alcuni esempi di queste metriche:
- Interattiva: un utente attende 1000 ms per un risultato dopo aver fatto clic su un elemento.
- Scrittura: una modifica a un sistema distribuito sottostante richiede 1500 ms. Sebbene questo periodo di tempo sia considerato lento, gli utenti tendono ad accettarlo. Ti consigliamo di distinguere esplicitamente le scritture e le letture nelle metriche.
- Background: le azioni che non sono visibili all'utente,come un aggiornamento periodico dei dati o altre richieste asincrone, non richiedono più di 5000 ms.
La latenza viene in genere misurata come distribuzione e come indicato nella sezione Scegliere gli SLI. Data una distribuzione, puoi misurare vari percentili. Ad esempio, potresti misurare il numero di richieste più lente rispetto al 99° percentile storico. Gli eventi più veloci di questa soglia sono considerati buoni; le richieste più lente sono considerate meno soddisfacenti. Puoi impostare questa soglia in base ai requisiti del prodotto. Puoi anche impostare più SLO di latenza, ad esempio latenza tipica e latenza di coda.
Non utilizzare solo la latenza media (o mediana) come SLI. Se la latenza mediana è troppo lenta, metà dei tuoi utenti è già insoddisfatta. Inoltre, il tuo servizio può riscontrare una cattiva latenza per giorni prima che tu scopra il problema. Di conseguenza, definisci il tuo SLO per la latenza di coda (95° percentile) e la latenza mediana (50° percentile).
Nell'articolo di ACM Metrics That Matter, Benjamin Treynor Sloss scrive quanto segue:
- "Una buona regola pratica ... è che la latenza del 99° percentile non dovrebbe essere più di 3-5 volte la latenza mediana."
- "Abbiamo notato che le misure di latenza del 50°, 95° e 99° percentile per un servizio sono preziose singolarmente e idealmente imposteremo gli SLO su ciascuno."
Determina le tue soglie di latenza in base ai percentili storici, quindi misura il numero di richieste che rientrano in ciascun bucket. Questo è un buon modello da seguire.
Qualità come SLI
La qualità è la proporzione di richieste valide che vengono gestite senza peggioramento del servizio. Ad esempio, la qualità è uno SLI utile per servizi complessi progettati per funzionare correttamente. Ad esempio, prendiamo in considerazione una pagina web che carica i contenuti principali da un datastore e asset facoltativi da altri 100 servizi e datastore. Se uno degli elementi facoltativi è fuori servizio o troppo lento, la pagina viene comunque visualizzata senza gli elementi facoltativi. In questo caso, puoi utilizzare gli SLI per:
- Se misuri il numero di richieste che ricevono una risposta con prestazioni ridotte (una risposta senza risposta da almeno un servizio di backend), puoi segnalare il rapporto di richieste errate.
- Puoi tenere traccia del numero di risposte per le quali manca una risposta da un singolo backend o da più backend.
Servizi di elaborazione dei dati
Questi servizi utilizzano i dati di un input, li elaborano e generano un output. Le prestazioni dei servizi nei passaggi intermedi non sono importanti quanto il risultato finale. Gli SLI più efficaci sono l'aggiornamento, la copertura, la correttezza e la velocità effettiva. La latenza e la disponibilità sono meno utili.
Aggiornamento come SLI
L'aggiornamento è la proporzione di dati validi aggiornati più di recente rispetto a una soglia. Il seguente elenco fornisce alcuni esempi di utilizzo dell'aggiornamento come SLI:
- In un sistema batch, l'aggiornamento viene misurato come il tempo trascorso durante un'esecuzione di elaborazione completata correttamente per un determinato output.
- Nell'elaborazione in tempo reale o nei sistemi più complessi, l'aggiornamento monitora l'età del record più recente elaborato in una pipeline.
- In un gioco online che genera riquadri di mappa in tempo reale, gli utenti potrebbero non notare la velocità con cui vengono creati riquadri, ma potrebbero notare quando i dati della mappa mancano o non sono aggiornati. In questo caso, l'aggiornamento tiene traccia dei dati mancanti o inattivi.
- In un servizio che legge i record da un sistema di monitoraggio per generare il messaggio "X articoli disponibili" per un sito web di e-commerce, uno SLI di aggiornamento potrebbe essere definito come la percentuale di richieste che utilizzano informazioni sulle scorte aggiornate di recente (entro l'ultimo minuto).
- Puoi anche utilizzare una metrica per fornire dati non aggiornati per aggiornare lo SLI per la qualità.
Copertura come SLI
La copertura è la proporzione di dati validi elaborati correttamente.
Per definire la copertura:
- Determina se accettare un input come valido o se saltarlo. Ad esempio, se un record di input è danneggiato o ha una lunghezza pari a zero e non può essere elaborato, potresti considerare tale record non valido come metrica.
- Conta il numero di record validi. Questo conteggio può essere eseguito con un
metodo
*count()*semplice e rappresenta il conteggio totale dei record. - Infine, conteggia il numero di record elaborati correttamente e confronta questo numero con il numero totale di record validi. Questo valore è il tuo SLI per la copertura.
Correttezza come SLI
La corretta è la proporzione di dati validi che hanno prodotto un output corretto. Quando utilizzi la correttezza come SLI, considera i seguenti punti:
- In alcuni casi, vengono utilizzati i metodi per determinare la correttezza di un output per convalidare l'elaborazione dell'output. Ad esempio, un sistema che ruota o colora un'immagine non dovrebbe mai produrre un'immagine a zero byte o un'immagine con lunghezza o larghezza pari a zero. È importante separare questa logica di convalida dalla logica di elaborazione.
- Un metodo per misurare uno SLI di correttezza è utilizzare i dati di input di test noto. Questo tipo di dati corrisponde a quelli che producono un output corretto noto. Ricorda che i dati di input devono essere rappresentativi dei dati utente.
- In altri casi, è possibile utilizzare un controllo matematico o logico rispetto all'output, come nell'esempio precedente sulla rotazione di un'immagine.
- Infine, prendi in considerazione un sistema di fatturazione che stabilisca la validità delle transazioni controllando la differenza tra il saldo prima e dopo una transazione. Se corrisponde al valore della transazione stessa, si tratta di una transazione valida.
Velocità effettiva come SLI
La velocità effettiva è la proporzione di tempo in cui la frequenza di elaborazione dei dati è stata superiore alla soglia. Ecco alcuni punti da considerare quando si utilizza la velocità effettiva come SLI:
- La velocità effettiva in un sistema di elaborazione dati è spesso più rappresentativa della soddisfazione degli utenti rispetto a una singola misurazione della latenza per una determinata operazione. Se la dimensione di ogni input varia drasticamente, potrebbe non avere senso confrontare il tempo necessario per completare ogni elemento (se tutti i job progrediscono a una velocità accettabile).
- I byte al secondo sono un modo comune per misurare la quantità di lavoro necessaria per elaborare i dati, indipendentemente dalle dimensioni del set di dati. Tuttavia, è valida qualsiasi metrica che scala in modo lineare rispetto al costo dell'elaborazione.
- Potrebbe essere utile partizionare i sistemi di elaborazione dati in base alle velocità di velocità effettiva previste. In alternativa, implementa un sistema di qualità del servizio che garantisca la gestione degli input ad alta priorità e la coda degli input con priorità bassa. In ogni caso, la misurazione della velocità effettiva come definita in questa sezione aiuta a determinare se il tuo sistema funziona come all'interno dello SLO.
Servizi di esecuzione pianificati
Per i servizi che devono eseguire un'azione a intervalli regolari (come i cron job di Kubernetes), misura il disallineamento e la durata dell'esecuzione. Di seguito è riportato un esempio di cron job Kubernetes pianificato:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec:
schedule: "0 * * * *"
Inclina come SLI
Il valore Disallineamento è la proporzione di esecuzioni che iniziano entro un periodo accettabile rispetto all'ora di inizio prevista. Quando utilizzi il disallineamento, considera quanto segue:
- Il disallineamento misura la differenza di tempo tra l'inizio pianificato di un job e l'ora di inizio effettiva. Considera l'esempio di cron job di Kubernetes precedente. Se è impostata per iniziare al minuto zero di ogni ora, ma inizia tre minuti dopo l'ora, il disallineamento è pari a tre minuti. Quando un job viene eseguito in anticipo, si verifica un'inclinazione negativa.
- Puoi misurare il disallineamento come una distribuzione nel tempo, con intervalli accettabili corrispondenti che definiscono il disallineamento. Per determinare lo SLI, confronta il numero di esecuzioni che rientrano in un intervallo accettabile.
Durata di esecuzione come SLI
La durata di esecuzione è la proporzione delle esecuzioni completate entro la finestra di durata accettabile. Di seguito sono riportati alcuni concetti importanti relativi all'utilizzo della durata dell'esecuzione:
- La durata dell'esecuzione è il tempo necessario per completare un job. Per una determinata esecuzione, una modalità di errore comune si verifica quando la durata effettiva supera la durata pianificata.
- Un caso interessante è l'applicazione di questo SLI a un lavoro infinito. Poiché questi job non vengono completati, registra il tempo trascorso su un determinato job anziché attendere il completamento di un job. Questo approccio fornisce una distribuzione accurata del tempo necessario per completare il lavoro, anche negli scenari peggiori.
- Come per il disallineamento, puoi monitorare la durata dell'esecuzione come distribuzione e definire limiti superiori e inferiori accettabili per eventi validi.
Metriche per altri tipi di sistema
Molti altri carichi di lavoro hanno le proprie metriche per generare SLI e SLO. Considera i seguenti esempi:
- Sistemi di archiviazione: durabilità, velocità effettiva, time to first byte, disponibilità dei BLOB.
- Contenuti multimediali/video: continuità della riproduzione del client, tempo di avvio della riproduzione, completezza dell'esecuzione del grafico di transcodifica.
- Giochi: è il momento di abbinare i giocatori attivi, è il momento di generare una mappa.
Decidi come misurare
Nella sezione precedente abbiamo parlato di ciò che stai misurando. Dopo aver deciso cosa misurare, puoi decidere come misurarlo. Puoi raccogliere le metriche SLI in diversi modi. Le seguenti sezioni identificano vari metodi di misurazione, forniscono una breve descrizione del metodo, elencano i vantaggi e gli svantaggi del metodo e identificano gli strumenti di implementazione appropriati per il metodo.
Logging lato server
Il metodo di logging lato server prevede l'elaborazione dei log lato server delle richieste o dei dati elaborati.
| Logging lato server | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
Metriche dell'Application Server
Il metodo delle metriche del server di applicazioni comporta l'esportazione di metriche SLI dal codice che gestisce le richieste degli utenti o elabora i loro dati.
| Metriche dell'Application Server | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
|
Metriche dell'infrastruttura di frontend
Il metodo delle metriche dell'infrastruttura frontale utilizza le metriche dell'infrastruttura di bilanciamento del carico (come un bilanciatore del carico di livello 7 globale in Google Cloud).
| Metriche di infrastruttura frontend | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
|
Client o dati sintetici
Il metodo dati o client sintetici prevede l'utilizzo di client che inviano richieste create a intervalli regolari e convalidano le risposte.
| Client o dati sintetici | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
|
Strumentazione client
Il metodo di strumentazione client comporta l'aggiunta di funzionalità di osservabilità al client con cui l'utente interagisce e il logging degli eventi nell'infrastruttura di gestione che monitora gli SLI.
| Strumentazione client | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
|
Scegli un metodo di misurazione
Dopo aver deciso cosa e come misurare il tuo SLO, il passo successivo è scegliere un metodo di misurazione che sia più in linea con l'esperienza del cliente con il tuo servizio e che richieda il minimo sforzo da parte tua. Per ottenere questo ideale, potresti dover utilizzare una combinazione dei metodi nelle tabelle precedenti. Di seguito sono riportati alcuni approcci consigliati che puoi implementare nel tempo, elencati in ordine crescente:
- Utilizza le esportazioni dei server delle applicazioni e le metriche dell'infrastruttura. In genere, puoi accedere subito a queste metriche, che forniscono rapidamente un valore aggiunto. Alcuni strumenti APM includono strumenti SLO integrati.
- Utilizza la strumentazione del client. Poiché i sistemi legacy in genere non dispongono di una strumentazione incorporata del client per il client, la configurazione della strumentazione potrebbe richiedere un investimento significativo. Tuttavia, se utilizzi una suite APM o un framework di frontend che fornisce la strumentazione del client, puoi ottenere rapidamente informazioni sulla soddisfazione del tuo cliente.
- Utilizza l'elaborazione dei log. Se non riesci a implementare le esportazioni del server o la strumentazione client (elenchi puntati precedenti), ma i log esistono, l'elaborazione dei log potrebbe essere l'approccio migliore. Un altro metodo è combinare le esportazioni e l'elaborazione dei log. Utilizza le esportazioni come fonte immediata per alcuni SLI (come la disponibilità immediata) e l'elaborazione dei log per gli indicatori a lungo termine (come gli avvisi per burnout lento discussi nella guida SLO e avvisi).
- Implementa i test sintetici. Una volta acquisita una conoscenza di base del modo in cui i clienti utilizzano il servizio, puoi testarlo. Ad esempio, puoi creare account di prova con dati noti ed eseguire query su questi dati. Questo approccio può contribuire a evidenziare modalità di errore che non sono immediatamente osservate, ad esempio per i servizi a traffico ridotto.
Che cosa succede dopo?
- Leggi l'articolo su SLO e avvisi.
- Leggi The Art of SLOs, un workshop sviluppato dal team Customer Reliability Engineering di Google.
- Prova Site Reliability Engineering: Measure and Managing Reliability, un corso online sulla creazione di SLO.
- Leggi Site Reliability Engineering: Implementazione degli SLO.
- Leggi Concetti relativi al monitoraggio dei servizi.
- Leggi Implementazione degli obiettivi del livello di servizio di Alex Hidalgo.
- Scopri di più sullo sviluppo di SLO con Cloud Monitoring.
- Prova il generatore SLO flessibile dell'Organizzazione servizi professionali (PSO) di Google.
- Leggi le nostre risorse su DevOps.
Scopri di più sulle funzionalità DevOps relative a questa serie:
Esegui il controllo rapido di DevOps per capire la tua posizione rispetto al resto del settore.
Esplora altre categorie nel framework dell'architettura.
Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.