Quindi vuoi fare il monitoraggio?

Non riesco proprio a passare l’opportunità di rubare questa immagine dal blog di Nick Cravers (link in basso)

Il monitoraggio è diventato un argomento di discussione per me durante le ultime settimane e volevo scrivere e riassumere i miei pensieri da qualche parte. Grazie per aver letto e apprezzo i tuoi commenti e feedback

Ok, quindi vuoi fare il monitoraggio.

Da dove inizi?

Scrivi il piano ed elenca tutte le cose che devi monitorare, concentrandoti su queste 3 domande

  • Quali sono tutti i componenti o sistemi che è necessario monitorare?
  • Che cosa significa che il componente / sistema è sano / non sano?
  • Quali metriche indicano la salute?

Per aiutarti con i punti dati, la cartella di lavoro di Google SRE ha un’idea di “Quattro segnali d’oro” (https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals)

  • Latenza
  • Traffico
  • Errori
  • Saturazione

La saturazione richiede alcune spiegazioni: è fondamentalmente quanto sono saturi i tuoi componenti con il carico di lavoro corrente o quanta capacità disponibile hai in questo momento.

Commento a margine: si consiglia di utilizzare il 99 ° percentile mentre si fa il monitoraggio e l’allerta e si lascia fuori l’1% per rumore e anomalie (c’è sempre un po ‘di “rumore” in sistemi complessi e lasciare questo 1% vi farà risparmiare tonnellate di falsi) aspetti positivi e ti permettono di concentrarti su ciò che conta davvero)

Dopo averci pensato un po ‘, questa è la gerarchia che mi è venuta in mente

  • Infrastruttura principale e relative metriche
  • Componenti principali dell’applicazione e loro dipendenze
  • Comportamenti dei sottosistemi core
  • Il core utilizza comportamenti di casi dal punto di vista dell’utente finale

Elenchi dettagliati di cosa monitorare a ciascuno di questi livelli merita un suo post (che potrei scrivere qualche volta in futuro)

Mentre lavoravo su sistemi distribuiti, sono arrivato alla stessa conclusione sul comportamento dei sistemi di monitoraggio delle persone di Amazon e Google: devi eseguire il monitoraggio per eseguire

  • Principali comportamenti dei casi d’uso dal punto di vista dell’utente finale

Dal post del blog “Google Platform Rant” di Steve Yegge:

‘monitoraggio e QA sono la stessa cosa. Non lo penseresti mai fino a quando non provi a fare una grande SOA. Ma quando il tuo servizio dice “oh sì, sto bene”, può darsi che l’unica cosa ancora funzionante nel server sia il piccolo componente che sa come dire “Sto bene, Roger, Roger e fuori “con una voce allegra droide. Per sapere se il servizio sta effettivamente rispondendo, devi effettuare chiamate individuali. Il problema continua in modo ricorsivo fino a quando il monitoraggio non esegue un controllo semantico completo dell’intera gamma di servizi e dati, a quel punto è indistinguibile dal controllo qualità automatizzato. Quindi sono un continuum. ‘

E da Google SRE Workbook: “solo i test di sistema end-to-end possono rilevare che stai offrendo i contenuti sbagliati”.

Un’altra nota sui controlli sanitari: penso che Kubernetes abbia escogitato un approccio intelligente al monitoraggio sanitario. In pratica utilizza 2 tipi di controlli sanitari:

  • Sonde di vitalità. Indica se l’applicazione è viva o morta e, se è morta, deve essere arrestata / riavviata
  • Sonde di prontezza. Indica se l’applicazione è pronta a ricevere traffico. Ci sono casi in cui l’applicazione è attiva, ma non è ancora pronta per servire il traffico, come il caricamento delle dipendenze all’avvio, l’aggiornamento delle configurazioni e così via. Questi sono casi in cui l’app è integra ma non dovrebbe offrire traffico.

Se prendi sul serio la salute del tuo sistema, devi avere test sintetici in tempo reale in esecuzione in produzione che emulino i comportamenti degli utenti e misurino tutto dalla latenza ai tassi di errore e presentino quei dati in tempo reale su un grande schermo di fronte allo sviluppo squadra. (Beh, potrebbe essere con altre metriche aggregate come lo stato e il carico complessivi del sistema, il conteggio degli utenti attivi correnti, le transazioni al secondo e così via, basta scegliere 3-4 4-5 principali e non sovraccaricare le persone con i dati)

E pensieri di coppia sugli utensili

Devi avere:

  • Monitoraggio e dashboard semplici e diretti (in tempo reale)
  • Sistema di avviso e biglietteria
  • Registro approfondito e ampio e monitoraggio della conservazione dei dati per l’analisi post-factum (alcuni ritardi vanno bene se sono in minuti bassi)
  • Sul posto profondo debug e profilazione. A volte sulla macchina dedicata in produzione con carico di produzione e utenti di produzione

Questi strumenti copriranno tutto, dalla visibilità in tempo reale all’analisi approfondita, al triage e al debug sul posto. Ho visto così tanti casi in cui MTTR (tempo medio di recupero) può essere ridotto in modo significativo da alcuni sviluppatori che saltano sulla macchina di produzione e eseguono il debug sul posto. Per alcune ragioni molte organizzazioni non lo supportano e accettano MTTR più lunghi semplicemente perché non forniscono strumenti e accesso agli sviluppatori.

Alla fine di questo post, ecco alcuni link che mi hanno ispirato a riassumere e scrivere questo post:

Cartella di lavoro di Google SRE: https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/

In che modo Stack Overflow esegue il monitoraggio: https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring/

Le piattaforme Google di Stevey sono disponibili: https://gist.github.com/chitchcock/1281611

In bocca al lupo!