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 caratteristiche 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 sottosezioni seguenti identifica un particolare tipo di servizio e fornisce una breve descrizione del servizio. Poi, elencate sotto ogni servizio sono possibili SLI, una definizione dell'indicatore e altre informazioni correlati 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 quindi restituisce una risposta al client.
Disponibilità come SLI
La disponibilità è la proporzione di richieste valide pubblicate correttamente. Il seguente elenco contiene le informazioni da considerare quando si utilizza la disponibilità come SLI:
- In qualità di proprietario del servizio, puoi decidere tu che cos'è una richiesta valida. Le definizioni comuni includono non di lunghezza pari a zero o è conforme a un protocollo client-server. Uno. per valutare la validità è la revisione dei 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 garantire 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 inavvertitamente fare un uso improprio degli errori. Utilizza il valore out-of-stock del punto precedente, uno sviluppatore potrebbe restituire per 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. Anche se i proprietari dei servizi devono essere informati dello scarso inventario, l'impossibilità di effettuare una vendita non è un errore dal punto di vista del cliente non conta ai fini di uno 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 velocità del servizio e può misurata calcolando la differenza tra i tempi di inizio e di fine di una 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 riesce a distinguere tra un aggiornamento di 100 millisecondi (ms) e un aggiornamento di 300 ms e potrebbe accettare risposte comprese tra 300 ms e 1000 ms come al solito. Per ulteriori informazioni, consulta il modello ferroviario.
Sviluppa metriche basate sull'attività e incentrate 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. Mentre questo periodo 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 percentili. Ad esempio, potresti misurare il numero di richieste più lente rispetto al percentile 99 storico. Gli eventi che superano questa soglia sono considerati buoni; più lento non sono considerate buone. Imposta questa soglia in base al prodotto i tuoi requisiti. Puoi anche impostare più SLO di latenza, ad esempio tipici di latenza e latenza di 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 tuo servizio possono riscontrare una scarsa latenza per alcuni giorni prima che tu rilevi il problema. Pertanto, definisci lo SLO per la latenza finale (95° percentile) e per 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 al 99° percentile non dovrebbe essere più di tre a cinque volte la latenza mediana."
- "Troviamo le misure di latenza del 50°, 95° e 99° percentile per un ogni servizio ha un valore individuale e idealmente imposteremo gli SLO su su ciascuno".
Determina le soglie di latenza in base ai percentili storici, quindi misura e quante richieste rientrano in ogni bucket. Questo approccio è un buon modello per 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 attività complesse e che sono progettati per eseguire gli errori in modo controllato. Per spiegarci meglio, consideriamo un modello pagina che carica il contenuto principale da un datastore e carica asset facoltativi da altri 100 servizi e datastore. 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 ridotta (una risposta senza risposta da almeno un servizio di backend), puoi segnalare il rapporto tra richieste errate.
- 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. Le prestazioni del servizio nei passaggi intermedi non sono importanti quanto come 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 è misurato come il tempo trascorso durante ha completato correttamente l'elaborazione per un determinato output.
- Nell'elaborazione in tempo reale o in sistemi più complessi, l'aggiornamento tiene traccia dell'età dei record più recenti elaborati in una pipeline.
- In un gioco online che genera riquadri di mappe in tempo reale, gli utenti potrebbero non notare la velocità con cui vengono creati i riquadri della mappa, ma potrebbero notare quando i dati mancano o non sono aggiornati. In questo caso, le tracce di aggiornamento mancanti di dati 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, si potrebbe definire uno SLI di aggiornamento come percentuale di richieste che utilizzano le richieste aggiornate di recente (entro il all'ultimo minuto) le informazioni sulle azioni.
- Puoi anche utilizzare una metrica per la pubblicazione di dati non aggiornati per aggiornare 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, conta il numero di record che sono stati elaborati correttamente con il numero totale di record validi. Questo valore è il tuo SLI per la copertura.
Correttezza come SLI
La correttezza è 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 sono utilizzata 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 fase 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. Questo tipo di dati produce 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 l'output, come nell'esempio precedente sulla 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.
Velocità effettiva come SLI
La velocità effettiva è la proporzione di tempo in cui la velocità di elaborazione dei dati è stata più veloce rispetto alla soglia. Ecco alcuni punti da considerare quando si utilizza il throughput come un SLI:
- La velocità effettiva in un sistema di elaborazione dati è spesso più rappresentativo che una singola misurazione della latenza per una determinata operazione. Se le dimensioni di ogni input variano notevolmente, potrebbe non avere senso confrontare Il tempo impiegato da ogni elemento per completare il processo (se tutti i job avanzano a un livello percentuale).
- 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. Ma qualsiasi metrica che scala più o meno in modo lineare rispetto al costo di elaborazione.
- Potrebbe essere utile partizionare i sistemi di elaborazione dei dati in base velocità effettiva previste. 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, misurando la velocità effettiva come definito aiuta a determinare se il sistema funziona all'interno dello 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 pianificato di Kubernetes:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec:
schedule: "0 * * * *"
Skew come SLI
Il disallineamento è la proporzione di esecuzioni che iniziano entro una finestra accettabile di l'ora di inizio prevista. Quando utilizzi il disallineamento, considera quanto segue:
- Il disallineamento misura la differenza di tempo tra il momento in cui è pianificato l'inizio di un job e l'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 lo SLI, confronta di esecuzioni entro un buon intervallo.
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 di esecuzione è il tempo impiegato da un job per essere completato. 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 infinito. 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 il disallineamento, puoi monitorare la durata dell'esecuzione come distribuzione e definire limiti superiori e inferiori accettabili per gli eventi validi.
Metriche per altri tipi di impianto
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 primo byte, blob la disponibilità del servizio.
- Contenuti multimediali/video: continuità della riproduzione del client, tempo per avviare la riproduzione. completezza dell'esecuzione del grafico di transcodifica.
- Giochi: è ora di abbinare i giocatori attivi, è ora di generare una mappa.
Decidere come eseguire la misurazione
La sezione precedente ha trattato gli elementi che stai misurando. Dopo aver determinato cosa misurare, puoi decidere come misurare. Puoi raccogliere le metriche SLI in diversi modi. Le seguenti sezioni illustrano i vari metodi di misurazione, fornire una breve descrizione del metodo, elencare i vantaggi del metodo e svantaggi e identificare gli strumenti di implementazione appropriati per il metodo.
Logging lato server
Il metodo di logging lato server prevede l'elaborazione dei log lato server di richieste o dati elaborati.
| Log lato server | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo di implementazione e strumenti |
Metriche del server delle applicazioni
Il metodo delle metriche del server delle applicazioni prevede l'esportazione delle metriche dello 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 delle metriche dell'infrastruttura frontale utilizza le metriche dell'infrastruttura di bilanciamento del carico (ad esempio, un bilanciatore del carico globale Google Cloud).
| Metriche di infrastruttura frontend | Dettagli |
|---|---|
| Vantaggi |
|
| Svantaggi |
|
| Metodo e strumenti di implementazione |
|
Dati o client sintetici
Il metodo client o dati sintetici prevede l'utilizzo di client che inviano richieste inventate a intervalli regolari e convalida le risposte.
| Dati o client 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 di implementazione e strumenti |
|
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. A per raggiungere questo ideale, potresti dover utilizzare una combinazione dei metodi nella nelle tabelle precedenti. Ecco alcuni approcci suggeriti che puoi implementare nel tempo, elencati in ordine crescente:
- Utilizza le esportazioni del server di applicazioni e le metriche dell'infrastruttura. In genere, puoi accedervi immediatamente e forniscono rapidamente un valore. Alcuni strumenti di APM includono strumenti SLO integrati.
- Utilizza la strumentazione client. Poiché in genere i sistemi legacy mancano la strumentazione client integrata per l'utente finale, la configurazione della strumentazione potrebbe richiedono 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 test sintetici. Dopo aver acquisito una conoscenza di base di come i clienti utilizzano il tuo servizio, testa il servizio. Ad esempio, puoi account di test seed con dati validi noti ed eseguire query su di essi. Questo approccio può evidenziano le modalità di errore non immediatamente osservate, come ad esempio e i servizi a traffico ridotto.
Passaggi successivi
- Leggi la sezione SLO e avvisi.
- Leggi The Art of SLOs, un workshop sviluppato dal team di Customer Reliability Engineering di Google.
- Prova Site Reliability Engineering: misurazione e gestione dell'affidabilità, un corso online sulla creazione degli SLO.
- Leggi Site Reliability Engineering: Implementazione degli SLO.
- Leggi la sezione Concetti relativi al monitoraggio dei servizi.
- Leggi Implementing Service Level Objectives di Alex Hidalgo.
- Scopri di più sullo sviluppo degli 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 correlate a questa serie:
Esegui il controllo rapido DevOps per capire dove rispetto al resto del settore.
Esplora altre categorie nel framework dell'architettura.
Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.