Segnali dorati SRE di AWS Aurora

AWS Aurora è un’opzione di motore di database sempre più popolare, essenzialmente un aggiornamento ad alte prestazioni di AWS RDS. Fortunatamente per noi, include anche metriche di monitoraggio molto utili che facilitano il monitoraggio.

Per riferimento, puoi anche consultare l’articolo SRE Golden Signals di MySQL

Come notato nell’articolo SRE Golden Signals di MySQL, tutti i buoni Golden Signals richiedono di avere una connessione al database, il che è fastidioso, e per RDS richiede un agente o un codice in esecuzione su una VM da qualche parte.

Fortunatamente Aurora fornisce ciò di cui abbiamo bisogno tramite AWS Cloud Watch, quindi una volta che puoi ottenere metriche da ciò, sei pronto per partire.

Una cosa carina, questa Aurora

Mappando i nostri segnali ad Aurora , vediamo:

  • Tasso di richiesta : query al secondo che CloudWatch ha come query. Se è necessario suddividere le query di lettura e scrittura, sono disponibili sia SelectThroughput che DMLThroughput (per inserimenti, aggiornamenti ed eliminazioni).
  • Tasso di errore – Aurora ha alcune metriche utili per alcuni tipi di “errori, anche se gli errori SQL reali richiedono ancora lo schema delle prestazioni, vedere di seguito.

    Per errori di accesso, è possibile ottenere l’elemento LoginFailures, che include gli utenti che non riescono ad accedere a causa del raggiungimento di connessioni massime, oltre a errori di password (che possono segnalare un tentativo di hacking).

    Un’altra metrica utile è BlockedTransactions, che penso significhi bloccato da blocchi, quindi qualsiasi grande aumento in questo significa che hai problemi di blocco.

    Se si attiva lo schema delle prestazioni, è possibile ottenere un tasso di errore globale che include SQL, sintassi e la maggior parte degli altri errori restituiti da MySQL. Questo è un contatore quindi è necessario applicare l’elaborazione delta. La query è:

    SELECT sum (sum_errors) AS query_count
    FROM events_statements_summary_by_user_by_event_name
    WHERE event_name IN (‘statement / sql / select’, ‘statement / sql / insert’, ‘statement / sql / update’, ‘statement / sql / delete’);

  • Latenza : Aurora fornisce questo direttamente in CloudWatch tramite due metriche: SelectLatency e DMLLatency. Il primo è probabilmente il più importante in quanto di solito è dove vedrai prima i problemi di prestazioni delle app, quindi se puoi solo avvisare su uno, usalo.
  • Saturazione : Aurora può fornire la profondità della coda del disco tramite DiskQueueDepth, ma probabilmente non la profondità della coda InnoDB (vedere SRE Golden Signals di MySQL su InnoDB). Aurora fornisce inoltre direttamente una metrica per le query in esecuzione o attive, denominata ActiveTransactions.
  • Utilizzo : ci sono molti modi in cui Aurora può esaurire la capacità, ma è più facile da usare con le percentuali di CPU e I / O sottostanti, misurate da CPUUtilization e ReadIOPS (anche WriteIOPS è disponibile ma di solito meno indicativo di problemi, ma le letture salteranno a causa carichi superiori o SQL peggiore).

Come puoi vedere, Aurora è molto più semplice di MySQL o persino di RDS, in quanto fornisce metriche dirette per la maggior parte delle cose a cui teniamo.

PostgreSQL Aurora

Tutto quanto sopra è incentrato su MySQL, poiché è lì che è la nostra esperienza, anche se guardando le metriche Aurora, la maggior parte o tutte queste si applicano anche a pgsql.