Questo documento del framework dell'architettura Google Cloud si basa sul discussioni sugli obiettivi del livello di servizio (SLO) esaminando i e come misurare i carichi di lavoro di servizio 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 illustra gli SLO generici per i diversi tipi di servizi e fornisce informazioni dettagliate spiegazioni degli SLI applicabili a ogni 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 sulle richieste
Questo tipo di servizio riceve una richiesta da un client (un utente o un altro servizio), esegue calcoli, invia richieste di rete a un backend e 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. Definizioni comuni Includere non a lunghezza zero o aderire a un protocollo client-server. Uno. per valutare la validità è la revisione dei codici di risposta HTTP (o RPC). Per Ad esempio, i codici HTTP 5xx sono errori relativi al server che incidono sul conteggio di uno 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 l'applicazione li utilizza in modo corretto e coerente. Il codice è indicatore preciso dei requisiti l'esperienza del servizio? Ad esempio: come risponde un sito di e-commerce quando un utente cerca di ordinare un articolo 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 associati all'utente le aspettative.
- 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 esito positivo 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 il servizio o fornisce un processo a lungo termine per i clienti. Sebbene sia possibile esporre la disponibilità in un altro modo, consigliamo di rappresentare la disponibilità come la proporzione di richieste valide andate a buon fine. La disponibilità può ovvero il numero di minuti di esecuzione del carico di lavoro del cliente (l'approccio noto anche come buoni minuti).
- Prendi in considerazione un servizio che offre macchine virtuali (VM). Potresti misurare la disponibilità in termini di numero di minuti successivi a una richiesta iniziale la VM sia a disposizione dell'utente.
Latenza come SLI
La latenza (o velocità) è la proporzione di richieste valide gestite è più veloce di 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 questa è la percezione della latenza dell'utente di solito i proprietari dei servizi misurano questo valore in modo troppo preciso. 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 informazioni, consulta il Modello ferroviario.
Sviluppa metriche basate sull'attività e incentrate sull'utente. Di seguito sono riportate le alcuni esempi di queste metriche:
- Interattiva: un utente attende 1000 ms per ricevere un risultato dopo aver fatto clic su un .
- Scrittura: una modifica a un sistema distribuito sottostante richiede 1500 ms. Mentre questo periodo di tempo è considerato lento, gli utenti tendono ad accettarlo. Me è consigliabile distinguere in modo esplicito le operazioni di scrittura e lettura metriche di valutazione.
- Background: azioni che non sono visibili all'utente,come un aggiornamento periodico di o altre richieste asincrone, il completamento non richiede più di 5000 ms.
In genere, la latenza viene misurata come distribuzione e, come accennato in Scegliere gli SLI. Data una distribuzione, puoi misurare vari percentili. Ad esempio, potrebbe misurare il numero di richieste più lente del 99° posto percentile. 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 valori tipici di latenza e latenza di coda.
Non utilizzare solo la latenza media (o mediana) come SLI. Se la mediana la latenza è troppo lenta, metà dei tuoi utenti è già insoddisfatta. Inoltre, il tuo servizio possono riscontrare una scarsa latenza per alcuni giorni prima che tu rilevi il problema. Pertanto, definisci il tuo SLO per la latenza di coda (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.
La qualità come SLI
La qualità è la proporzione di richieste valide gestite senza la degradazione del servizio. Ad esempio, la qualità è uno SLI utile per attività complesse e che sono progettati per eseguire gli errori in modo controllato. Per essere un esempio, 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 è disattivato di servizio o troppo lenta, la pagina viene comunque visualizzata senza l'opzione elementi. 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 per cui manca una risposta da un da un singolo backend o da più backend.
Servizi di elaborazione dati
Questi servizi consumano dati da un input, li elaborano e generano un come output. Le prestazioni del servizio nei passaggi intermedi non sono importanti quanto come risultato finale. Gli SLI più efficaci sono l'aggiornamento, la copertura, la correttezza e la velocità effettiva 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 è misurato come il tempo trascorso durante un 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:
- Scegli se accettare un input come valido o ignorarlo. Ad esempio, se un record di input è danneggiato o di lunghezza pari a zero e non può essere elaborato, potresti consideri il record non valido come metrica.
- Conta il numero di record validi. Questo conteggio può essere eseguito con una
*
*count()semplice e rappresenta il conteggio totale dei 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. Prendi in considerazione 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 dovrebbe mai produrre un'immagine a zero byte, o un'immagine con lunghezza o larghezza pari a zero. È importante separare questa fase di convalida dalla logica di elaborazione stessa.
- Un metodo per misurare uno SLI di correttezza è utilizzare un input di test valido noto e i dati di Google Cloud. 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 un valore transazione.
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. Di seguito sono riportati alcuni aspetti da considerare quando si utilizza la velocità effettiva uno 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 media).
- I byte al secondo sono un modo comune per misurare la quantità di lavoro necessario di elaborare i dati a prescindere 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. Oppure implementa una qualità del servizio che garantisce la gestione degli input ad alta priorità e a bassa priorità vengono messi in coda. In ogni caso, misurando la velocità effettiva come definito aiuta a determinare se il sistema funziona all'interno dello SLO.
Servizi a esecuzione pianificata
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 pianificato di Kubernetes:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec:
schedule: "0 * * * *"
Disallineamento 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. Considera il cron job Kubernetes precedente esempio. Se è impostato in modo da iniziare al minuto zero di ogni ora, ma inizia tre minuti dopo l'ora, il disallineamento è di tre minuti. Quando viene eseguito un job si ha un disallineamento negativo.
- Puoi misurare il disallineamento come distribuzione nel tempo, con le corrispondenze accettabili che definiscono un buon disallineamento. Per determinare lo SLI, confronta di esecuzioni entro un buon intervallo.
Durata dell'esecuzione come SLI
La durata esecuzione è la proporzione di esecuzioni completate all'interno del accettabile. Di seguito vengono trattati importanti concetti relativi utilizzando la durata di esecuzione:
- La durata di esecuzione è il tempo impiegato da un job per essere completato. Per un dato dell'esecuzione, una modalità di errore comune si verifica quando la durata effettiva supera quella pianificata durata massima.
- Un caso interessante è l'applicazione di questo SLI a un job infinito. Poiché questi job non vengono completati, registra il tempo trascorso su un determinato lavoro anziché in attesa del completamento di un job. Questo approccio fornisce una definizione distribuzione del tempo necessario per completare il lavoro, anche nel peggiore dei casi diversi scenari.
- 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. Prendi in considerazione 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 misurare
La sezione precedente riguardava ciò che stai misurando. Dopo aver determinato cosa misurare, puoi decidere come misurare. Puoi raccogliere le metriche SLI in 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.
| Logging 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 di implementazione e strumenti |
|
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 di implementazione e strumenti |
|
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 di implementazione e strumenti |
|
Strumentazione client
Il metodo di strumentazione client prevede l'aggiunta di funzionalità di osservabilità alle il client con cui interagisce l'utente e il logging degli eventi nella tua pubblicazione che tiene traccia degli 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 passaggio successivo è scegliere il metodo di misurazione più in linea con le preferenze il minimo sforzo 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 delle 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 o un frontend APM che fornisce la strumentazione del client, puoi ottenere rapidamente insight nella felicità del tuo cliente.
- Utilizza l'elaborazione dei log. Se non riesci a implementare le esportazioni del server o del client (punti precedenti), ma esistono log esistenti, l'elaborazione dei log potrebbe 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 disponibilità) ed elaborazione dei log per i segnali a lungo termine (ad esempio, avvisi descritti nella guida SLO e avvisi).
- Implementa test sintetici. Dopo aver compreso come funziona se i clienti utilizzano il tuo servizio, tu lo verifichi. 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
- Per ulteriori informazioni, vedi SLO e avvisi.
- Leggi The Art of SLO per scoprire a un workshop sviluppato dal Customer Reliability Engineering di Google dell'IA.
- Prova Site Reliability Engineering: Misurare e gestire l'affidabilità. un corso online sulla creazione degli SLO.
- Leggi Site Reliability Engineering: Implementazione degli SLO.
- Leggi Concetti sul monitoraggio dei servizi.
- Leggi Implementazione degli obiettivi del livello di servizio 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 relative a 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 nella Framework dell'architettura.
Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.