la capacit\u00e0 di monitorare, misurare e comprendere lo stato di un sistema o di un’applicazione esaminandone l’output, i log e le metriche.<\/em><\/p>\n\n\n\n Quando un’organizzazione cresce in dimensioni e complessit\u00e0, la capacit\u00e0 di estrarre informazioni sullo stato di salute dell’infrastruttura diventa fondamentale. In queste situazioni le metriche sono il miglior strumento per determinare lo stato di salute di un’infrastruttura.<\/p>\n\n\n\n Le metriche sono una rappresentazione numerica dei dati misurati nel tempo; sono utili per identificare tendenze, previsioni e anomalie. Affinch\u00e9 portino valore, le metriche devono essere centralizzate, elaborate, aggregate e presentate in modo significativo.<\/p>\n\n\n\n All\u2019interno di AWS, i termini monitoring<\/em> e observability<\/em> dovrebbero immediatamente far pensare ad Amazon CloudWatch. Tutti conoscono Cloudwatch, giusto? I log groups, le metrics e gli events, tutto qui, corretto? <\/p>\n\n\n\n E se vi dicessi che CloudWatch \u00e8 molto di pi\u00f9?<\/p>\n\n\n\n Ecco dunque 3+1 funzionalit\u00e0 di Amazon CloudWatch che non tutti conoscono.<\/p>\n\n\n\n Questa \u00e8 probabilmente la mia feature preferita: con Synthetics \u00e8 possibile creare dei \u201ccanaries<\/em>\u201d, ovvero degli script che vengono eseguiti in modo programmato per monitorare un sito web, un\u2019API o un endpoint in generale. Con un canary \u00e8 possibile simulare le azioni di un utente reale, rendendo davvero semplice scoprire se una pagina web non risponde o se un’API restituisce errori.<\/p>\n\n\n\n Esistono 3 metodi per creare un canary:<\/p>\n\n\n\n L’opzione pi\u00f9 interessante \u00e8 l\u2019utilizzo dei blueprint in quanto mostrano il potenziale di questo strumento. L’interfaccia \u00e8 chiara, i parametri impostabili dall\u2019utente sono ben definiti, facili da compilare e le modifiche aggiornano in tempo reale lo script.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Come mostrato nell’immagine, questi sono i casi d\u2019uso previsti nei blueprint:<\/p>\n\n\n\n Gli script possono essere scritti sia in Node.js utilizzando Puppeteer che in Python con Selenium, anche se alcuni blueprint sono privi dell\u2019implementazione in Python. I runtime supportati consistono quindi in varie combinazioni di questi linguaggi, librerie e versioni di Chromium.<\/p>\n\n\n\n Se vi piace analizzare le metriche, \u00e8 molto probabile che vi piaccia anche la matematica. Se non fosse questo il caso, non preoccupatevi, in questo paragrafo non verr\u00e0 utilizzata alcuna funzione differenziale… forse.<\/p>\n\n\n\n Nelle occasioni in cui vi sia la necessit\u00e0 di una logica pi\u00f9 complessa rispetto al semplice controllo dell\u2019utilizzo della CPU, Cloudwatch viene in aiuto con la possibilit\u00e0 di utilizzare metriche derivate dalla combinazione di altre metriche.<\/p>\n\n\n\n Supponiamo che uno sviluppatore abbia appena corretto un bug che si presenta all\u2019avvio di una funzione Lambda e, dopo la correzione, voglia verificare che la funzione non presenti ancora problemi nei primi millisecondi di esecuzione. Per fare ci\u00f2, il programmatore potrebbe verificare la presenza di errori mentre monitora il tempo di esecuzione medio della funzione. <\/p>\n\n\n\n L’immagine fornita mostra un’implementazione pratica di questo processo.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Naturalmente questo \u00e8 un esempio molto semplice, ma attraverso l’uso di condizioni e delle funzioni presenti nel “math menu” \u00e8 possibile creare espressioni pi\u00f9 complesse. Il men\u00f9 in questione offre moltissime funzioni, a partire dagli operatori matematici pi\u00f9 comuni fino a condizioni, conversioni, ordinamento, filtri e ad altre query pi\u00f9 specifiche.<\/p>\n\n\n\n Le metriche appena create possono poi essere aggiunte ad una dashboard (spoiler) o utilizzate per la creazione di allarmi.<\/p>\n\n\n\n Si pu\u00f2 considerare monitoring se non ci sono delle dashboard? Non credo. Fortunatamente Cloudwatch mette a disposizione un servizio per la loro creazione. Le dashboard di Cloudwatch rendono molto semplice il monitoraggio di un intero workload, anche se composto da servizi diversi in regioni diverse e su account diversi, tutto in un\u2019unica pagina.<\/p>\n\n\n\n Ad esempio, ecco una semplice dashboard che mostra il numero di chiamate a una particolare funzione Lambda e il suo tasso di fallimento.<\/p>\n\n\n\n <\/p>\n\n\n \u201cE se la dashboard dovesse essere vista da persone che non hanno un account AWS?\u201d Nessun problema. \u00c8 possibile condividerla a un elenco di indirizzi e-mail selezionati o specificando un Identity Provider (IdP) di terze parti. Il proprietario di uno degli indirizzi e-mail consentiti dovr\u00e0 creare la propria password che poi potr\u00e0 utilizzare per visualizzare la dashboard.<\/p>\n\n\n\n Inoltre, vale la pena menzionare le “Dashboard automatiche”. Si tratta di dashboard preconfigurate, incentrate su specifici servizi e gi\u00e0 popolate di informazioni. Queste dashboard si rivelano molto utili in quanto consentono un rapido monitoraggio delle risorse senza la necessit\u00e0 di crearne di personalizzate.<\/p>\n\n\n\n Il nome di questa funzione potrebbe ricordare il celebre comando Unix presente nelle GNU coreutils\u2026 ed \u00e8 giusto cos\u00ec! Live Tail replica la funzionalit\u00e0 di \u201ctail -follow\u201d, che legge continuamente le ultime righe di un file, ma su CloudWatch.<\/p>\n\n\n\n Con Live Tail \u00e8 possibile seguire tutti i log di un log group selezionato senza dover continuamente premere il pulsante di aggiornamento nella pagina dei log events. Non \u00e8 tutto, dopo aver selezionato il log group, la selezione del log stream \u00e8 opzionale. Quest’ultima parte potrebbe non sembrare di grande importanza, ma chiunque abbia mai sviluppato un Lambda conosce la fatica di dover cambiare continuamente i log group per visualizzare i log pi\u00f9 recenti. Questa funzionalit\u00e0 permette quindi di eliminare alcuni click ad ogni aggiornamento del codice della funzione, risparmiando molto tempo (ed energia mentale) durante lo sviluppo e, soprattutto, durante il debugging.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Per facilitare l’estrazione delle sole informazioni rilevanti dai logs \u00e8 possibile utilizzare una regex, alcuni esempi:<\/p>\n\n\n\n Per chi non ama le regex (comprensible) esiste anche una sintassi pi\u00f9 semplice:<\/p>\n\n\n\n1. Synthetics<\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/01\/image2-1.png\")
<\/figure><\/div>\n\n\n\n
2. Metriche derivate<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/01\/image4-1.png\")
<\/figure><\/div>\n\n\n3. Dashboards<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/01\/image3-1-1024x340.png\")
<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n4. Bonus: Live Tail<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/01\/image1-1.png\")
<\/figure><\/div>\n\n\n\n