Questo documento del framework dell'architettura di Google Cloud si basa sulle discussioni precedenti sugli obiettivi del livello di servizio (SLO) esplorando cosa e come misurare rispetto ai carichi di lavoro dei servizi comuni. Questo documento si basa sui concetti definiti in Componenti degli obiettivi del livello di servizio.
Decidi cosa misurare
Indipendentemente dal tuo dominio, molti servizi condividono funzionalità comuni e possono utilizzare SLO generici. Questa sezione discute gli SLO generici per diversi tipi di servizi e fornisce spiegazioni dettagliate degli SLI applicabili a ciascun SLO.
Ognuna delle seguenti sottosezioni identifica un determinato tipo di servizio e fornisce una breve descrizione del servizio. 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, eventualmente invia richieste di rete a un backend e poi restituisce una risposta al client.
Disponibilità come SLI
La disponibilità è la proporzione di richieste valide che vengono pubblicate correttamente. L'elenco seguente illustra le informazioni da prendere in considerazione quando si utilizza la disponibilità come SLI:
- In qualità di proprietario del servizio, sei tu a decidere cosa costituisce una richiesta valida. Le definizioni comuni includono non di lunghezza pari a zero o rispetta 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 ai fini di un SLO, mentre i codici 4xx sono errori del client che non vengono conteggiati.
- Ogni codice di risposta restituito dal servizio deve essere esaminato per assicurarsi che l'applicazione li utilizzi in modo corretto e coerente. Il codice è un indicatore accurato dell'esperienza degli utenti con il servizio? Ad esempio, come risponde un sito di e-commerce quando un utente tenta di ordinare un articolo che non è disponibile? La richiesta non va a buon fine e restituisce un messaggio di errore? Il sito suggerisce prodotti simili? I codici di errore devono essere legati alle aspettative degli utenti.
- Gli sviluppatori possono fare un uso improprio degli errori inavvertitamente. Utilizzando lo scenario di prodotto non disponibile dell'elenco precedente, uno sviluppatore potrebbe restituire per errore un errore. Tuttavia, il sistema funziona correttamente e non presenta errori. Il codice deve restituire un messaggio di successo, anche se l'utente non è riuscito ad acquistare l'articolo. Sebbene i proprietari di servizi debbano essere avvisati dell'inventario ridotto, l'impossibilità di effettuare una vendita non è un errore dal punto di vista del cliente e non viene considerata ai fini di un SLO.
- Un esempio di servizio più complesso è quello che gestisce richieste asincrone o fornisce ai clienti un processo di lunga durata. Sebbene sia possibile mostrare la disponibilità in un altro modo, ti consigliamo di rappresentarla come la proporzione di richieste valide andate a buon fine. La disponibilità può essere anche definita 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 che la VM è disponibile per l'utente.
Latenza come SLI
La latenza (o velocità) è la proporzione di richieste valide gestite più velocemente rispetto a una soglia. Pertanto, la latenza indica la rapidità del servizio e può essere misurata calcolando la differenza tra l'ora di inizio e quella di fine per un determinato tipo di richiesta. Ricorda che si tratta della percezione della latenza da parte dell'utente e che i proprietari di servizi misurano comunemente questo valore con troppa precisione. In realtà, gli utenti non possono distinguere tra un aggiornamento di 100 millisecondi (ms) e uno di 300 ms e potrebbero persino accettare come normali risposte tra 300 ms e 1000 ms. Per ulteriori informazioni, consulta il modello ferroviario.
Sviluppare metriche incentrate sulle attività che si concentrano sull'utente. Di seguito sono riportati alcuni esempi di queste metriche:
- Interattivo: 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. Anche se questo intervallo di tempo è considerato lento, gli utenti tendono ad accettarlo. Ti consigliamo di distinguere esplicitamente tra scritture e letture nelle tue metriche.
- In background:le azioni non visibili all'utente,come un aggiornamento periodico dei dati o altre richieste asincrone, non richiedono più di 5000 ms per essere completate.
La latenza viene comunemente misurata come distribuzione e come indicato in Scegliere gli SLI. Data una distribuzione, puoi misurare vari percentile. Ad esempio, potresti misurare il numero di richieste più lente rispetto al percentile 99 storico. Gli eventi più rapidi di questa soglia sono considerati buoni; le richieste più lente sono considerate non così buone. Imposti questa soglia in base ai requisiti del prodotto. Puoi anche impostare più SLO di latenza, ad esempio la latenza media rispetto alla latenza coda.
Non utilizzare solo la latenza media (o mediana) come SLI. Se la latenza mediana è troppo lenta, metà dei tuoi utenti non è già soddisfatta. Inoltre, il servizio può presentare una latenza elevata per giorni prima che tu possa rilevare il problema. Pertanto, definisci lo SLO per la latenza finale (95° percentile) e per la latenza mediana (50° percentile).
Nell'articolo dell'ACM Metriche importanti, Benjamin Treynor Sloss scrive quanto segue:
- "Una buona regola pratica è che la latenza al 99° percentile non deve essere superiore a tre-cinque volte la latenza media".
- "Abbiamo riscontrato che le misurazioni della latenza al 50°, 95° e 99° percentile per un servizio sono ciascuna di valore individuale e, idealmente, imposteremo gli SLO in base a ciascuna di esse".
Determina le soglie di latenza in base ai percentile storici, quindi misura il numero di richieste che rientrano in ogni bucket. Questo approccio è un buon modello da seguire.
Qualità come SLI
La qualità è la proporzione di richieste valide che vengono gestite senza un peggioramento del servizio. Ad esempio, la qualità è uno SLI utile per i servizi complessi progettati per arrestarsi in modo corretto in caso di errore. A titolo esemplificativo, prendiamo in considerazione una pagina web che carica i contenuti principali da un data store e gli asset facoltativi da 100 altri servizi e data store. Se uno degli elementi facoltativi non è attivo o è troppo lento, la pagina viene comunque visualizzata senza gli elementi facoltativi. In questo scenario, puoi utilizzare gli SLI per:
- Misurando il numero di richieste che ricevono una risposta con prestazioni ridotte (una risposta a cui manca una risposta da parte di almeno un servizio di backend), puoi segnalare il rapporto tra richieste non valide.
- Puoi monitorare il numero di risposte a cui manca una risposta da un singolo backend o da più backend.
Servizi di elaborazione dati
Questi servizi consumano dati da un input, li elaborano e generano un output. Il rendimento del servizio nelle fasi intermedie non è importante quanto il risultato finale. Gli SLI più importanti sono aggiornamento, copertura, correttezza e throughput. 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. L'elenco seguente 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 in sistemi più complessi, l'aggiornamento monitora l'età del record più recente elaborato in una pipeline.
- In un gioco online che genera riquadri della mappa in tempo reale, gli utenti potrebbero non notare la velocità con cui vengono creati, ma potrebbero notare quando i dati della mappa mancano o non sono aggiornati. In questo caso, l'aggiornamento monitora i dati mancanti o obsoleti.
- In un servizio che legge i record di un sistema di monitoraggio per generare il messaggio "X articoli disponibili" per un sito web di e-commerce, è possibile definire un SLI di aggiornamento come la percentuale di richieste che utilizzano informazioni di inventario aggiornate di recente (nell'ultimo minuto).
- Puoi anche utilizzare una metrica per la pubblicazione di dati non aggiornati per aggiornare l'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 saltarlo. Ad esempio, se un record di input è danneggiato o di lunghezza pari a zero e non può essere elaborato, potresti considerarlo non valido come metrica.
- Conta il numero di record validi. Questo conteggio può essere eseguito con un semplice metodo
*count()*e rappresenta il numero totale di record. - Infine, conteggia il numero di record elaborati correttamente e confrontalo con il numero totale di record validi. Questo valore è il tuo SLI per la copertura.
Correttezza come SLI
Per correttezza si intende la proporzione di dati validi che hanno prodotto un output corretto. Tieni presenti i seguenti punti quando utilizzi la correttezza come SLI:
- In alcuni casi, i metodi per determinare la correttezza di un output vengono utilizzati per convalidare l'elaborazione dell'output. Ad esempio, un sistema che ruota o colora un'immagine non deve mai produrre un'immagine di zero byte o un'immagine con una lunghezza o una larghezza pari a zero. È importante separare questa logica di convalida dalla logica di elaborazione stessa.
- Un metodo per misurare un SLI di correttezza consiste nell'utilizzare i dati di input di test validi noti. Si tratta di dati 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 di rotazione di un'immagine.
- Infine, prendi in considerazione un sistema di fatturazione che determina la validità della transazione controllando la differenza tra il saldo prima e dopo una transazione. Se corrisponde al valore della transazione stessa, si tratta di una transazione valida.
Throughput come SLI
La tasso di throughput è la proporzione di tempo in cui la velocità di elaborazione dei dati è stata superiore alla soglia. Ecco alcuni punti da considerare quando si utilizza il throughput come un SLI:
- La produttività 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 le dimensioni di ogni input variano notevolmente, potrebbe non avere senso confrontare il tempo necessario per completare ogni elemento (se tutti i job procedono 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, qualsiasi metrica che vari in modo approssimativamente lineare rispetto al costo di elaborazione andrà bene.
- Potrebbe essere utile partizionare i sistemi di elaborazione dei dati in base ai tassi di throughput previsti. In alternativa, implementa un sistema di qualità del servizio che garantisca che gli input di alta priorità vengano gestiti e quelli di bassa priorità messi in coda. In ogni caso, la misurazione della produttività come definita in questa sezione consente di determinare se il sistema funziona come previsto dallo SLO.
Servizi di esecuzione pianificata
Per i servizi che devono eseguire un'azione a intervalli regolari (ad esempio i job cron di Kubernetes), misura lo scostamento 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 * * * *"
Skew come SLI
Lo spostamento è la proporzione di esecuzioni che iniziano in un intervallo di tempo accettabile rispetto all'ora di inizio prevista. Quando utilizzi l'obliquità, tieni presente quanto segue:
- Lo skew misura la differenza di tempo tra l'ora pianificata di inizio di un job e la sua ora di inizio effettiva. Prendi in considerazione l'esempio di cron job Kubernetes precedente. Se è impostato per iniziare al minuto zero di ogni ora, ma inizia tre minuti dopo l'ora, lo scostamento è di tre minuti. Quando un job viene eseguito in anticipo, si verifica uno scostamento negativo.
- Puoi misurare la distorsione come distribuzione nel tempo, con intervalli accettabili corrispondenti che definiscono una buona distorsione. Per determinare l'SLI, confronta il numero di esecuzioni che rientravano in un intervallo accettabile.
Durata dell'esecuzione come SLI
La durata dell'esecuzione è la proporzione di esecuzioni completate nell'intervallo di durata accettabile. Di seguito sono riportati 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 quella pianificata.
- Un caso interessante è l'applicazione di questo SLI a un job senza fine. Poiché questi job non terminano, registra il tempo impiegato per un determinato job anziché aspettare il completamento di un job. Questo approccio fornisce una distribuzione accurata del tempo necessario per completare il lavoro, anche negli scenari peggiori.
- Come per l'errore di inclinazione, puoi monitorare la durata dell'esecuzione come distribuzione e definire limiti superiori e inferiori accettabili per gli eventi validi.
Metriche per altri tipi di sistemi
Molti altri carichi di lavoro hanno metriche proprie per generare SLI e SLO. Considera i seguenti esempi:
- Sistemi di archiviazione: durabilità, throughput, tempo di risposta al primo byte, disponibilità dei blob.
- Contenuti multimediali/video: continuità della riproduzione del client, tempo di inizio della riproduzione, completezza dell'esecuzione del grafo di transcodifica.
- Giochi: è ora di abbinare i giocatori attivi, è ora di generare una mappa.
Decidi come eseguire la misurazione
La sezione precedente illustrava cosa misurare. Dopo aver stabilito cosa misurare, puoi decidere come effettuare la misurazione. Puoi raccogliere le metriche SLI in diversi modi. Le sezioni seguenti 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.
Log lato server
Il metodo di logging lato server prevede l'elaborazione dei log lato server delle richieste o dei dati elaborati.
| Log lato server | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
Metriche del server delle applicazioni
Il metodo Metriche del server di applicazioni prevede l'esportazione delle metriche SLI dal codice che gestisce le richieste degli utenti o elabora i loro dati.
| Metriche del server delle applicazioni | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
|
Metriche dell'infrastruttura frontend
Il metodo Metriche dell'infrastruttura di fronteggiamento utilizza le metriche dell'infrastruttura di bilanciamento del carico (ad esempio un bilanciatore del carico di livello 7 globale in Google Cloud).
| Metriche dell'infrastruttura frontend | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
|
Client o dati sintetici
Il metodo client o dati sintetici prevede l'utilizzo di client che inviano richieste simulate a intervalli regolari e convalidano le risposte.
| Client o dati sintetici | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
|
Strumentazione client
Il metodo di strumentazione del client prevede l'aggiunta di funzionalità di osservabilità al client con cui interagisce l'utente e la registrazione degli eventi nella tua infrastruttura di pubblicazione che monitora gli SLI.
| Strumentazione client | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
|
Scegliere un metodo di misurazione
Dopo aver deciso cosa e come misurare lo SLO, il passaggio successivo consiste nel scegliere un metodo di misurazione che sia il più in linea con l'esperienza del cliente con il tuo servizio e che richieda il minor impegno da parte tua. Per ottenere questo risultato ideale, potresti dover utilizzare una combinazione dei metodi nelle tabelle precedenti. Di seguito sono riportati gli approcci suggeriti che puoi implementare nel tempo, elencati in ordine di impegno crescente:
- Utilizza le esportazioni del server di applicazioni e le metriche dell'infrastruttura. In genere, puoi accedere immediatamente a queste metriche, che forniscono rapidamente informazioni utili. Alcuni strumenti APM includono strumenti SLO integrati.
- Utilizza la misurazione del client. Poiché i sistemi legacy in genere non dispongono di instrumentation client per gli utenti finali integrata, la configurazione della instrumentation potrebbe richiedere un investimento significativo. Tuttavia, se utilizzi una suite APM o un framework frontend che fornisce la misurazione del client, puoi ottenere rapidamente informazioni sulla soddisfazione dei clienti.
- Utilizza l'elaborazione dei log. Se non riesci a implementare le esportazioni del server o l'instrumentazione del client (elenchi precedenti), ma esistono i log, l'elaborazione dei log potrebbe essere il tuo approccio migliore. Un altro metodo consiste nel combinare le esportazioni e l'elaborazione dei log. Utilizza le esportazioni come origine immediata per alcuni SLI (ad esempio la disponibilità immediata) e l'elaborazione dei log per gli indicatori a lungo termine (ad esempio gli avvisi a lenta combustione descritti nella guida SLO e avvisi).
- Implementa i test sintetici. Dopo aver acquisito una conoscenza di base di come i clienti utilizzano il tuo servizio, testa il servizio. Ad esempio, puoi iniziare a utilizzare gli account di test con dati validi noti ed eseguire query in merito. Questo approccio può contribuire a evidenziare modalità di errore che non sono facilmente osservabili, ad esempio per i servizi con traffico ridotto.
Passaggi successivi
- Leggi gli SLO e gli avvisi.
- Leggi The Art of SLOs, un workshop sviluppato dal team di Customer Reliability Engineering di Google.
- Prova Site Reliability Engineering: Measuring and Managing Reliability, un corso online sulla creazione di SLO.
- Leggi Site Reliability Engineering: Implementing SLOs.
- Leggi la sezione Concetti relativi al monitoraggio dei servizi.
- Leggi Implementing Service Level Objectives di Alex Hidalgo.
- Scopri di più sullo sviluppo di SLO con Cloud Monitoring.
- Prova il flessibile Generatore SLO dell'Organizzazione servizi professionali (PSO) di Google.
- Leggi le nostre risorse su DevOps.
Scopri di più sulle funzionalità DevOps correlate a questa serie:
Esegui il controllo rapido DevOps per capire dove ti trovi rispetto al resto del settore.
Esplora i consigli negli altri pilastri del Framework dell'architettura.
Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.