Come funzionano lo scaling predittivo delle risorse e il rilevamento delle anomalie<\/h2>\n
Tra poco vedremo in cosa pu\u00f2 aiutarci l’API di Kinsta<\/a>. Prima, per\u00f2, vediamo come prevedere la scalabilit\u00e0 delle risorse. Successivamente, vedremo anche i vantaggi della capacit\u00e0 di rilevare le anomalie nelle prestazioni di un sito.<\/p>\n In poche parole, la scalabilit\u00e0 predittiva delle risorse \u00e8 un modo per gestire le risorse del sito<\/a> in base alla domanda prevista. Si tratta di un approccio proattivo che prevede l’analisi dei dati, dei modelli di utilizzo e di altri fattori rilevanti.<\/p>\n Prevedere quando il sito potrebbe subire un aumento del traffico o del consumo di risorse permette di scalare per soddisfare la domanda. Il risultato netto \u00e8 una performance ottimizzata e una migliore esperienza utente (UX).<\/p>\n Tuttavia, i vantaggi della scalabilit\u00e0 predittiva delle risorse sono molteplici e costituiscono l’insieme:<\/p>\n Combinare lo scaling predittivo con la capacit\u00e0 di rilevare le anomalie delle prestazioni sul server \u00e8 un’ottima combinazione. A seguire parleremo dei vantaggi del rilevamento di queste incongruenze.<\/p>\n Un aspetto che spesso va di pari passo con una strategia di scaling \u00e8 il rilevamento delle irregolarit\u00e0 nelle metriche delle prestazioni<\/a> del sito. Le statistiche avranno una linea di base e dei valori estremi per quanto riguarda l’utilizzo della CPU, il consumo di memoria<\/a> e i tempi di risposta, che possono essere fonte di problemi e potenziali ottimizzazioni.<\/p>\n Individuare tempestivamente queste anomalie permette di affrontare qualsiasi problema potenziale prima che si ripercuota sulla disponibilit\u00e0 e sull’UX del sito e diventi un problema grave. Inoltre, ci sono molti altri vantaggi:<\/p>\n Sia il rilevamento delle anomalie che il miglioramento delle prestazioni sono due facce della stessa medaglia. Ci\u00f2 significa che \u00e8 necessario usare queste strategie in tandem per creare una solida base di prestazioni per il sito. Nella prossima sezione vedremo come si presenta questo aspetto in alcuni scenari tipici.<\/p>\n La necessit\u00e0 di aumentare le risorse del server a propria disposizione ha molti usi pratici. Si pu\u00f2 dire che quasi tutti i siti avranno bisogno di una qualche forma di questa strategia.<\/p>\n Per capire meglio come utilizzare lo scaling predittivo delle risorse e il rilevamento delle anomalie in un contesto reale, esaminiamone alcuni. Il primo \u00e8 probabilmente uno degli scenari pi\u00f9 comuni.<\/p>\n In un mondo ideale, il nostro sito di e-commerce<\/a> avr\u00e0 un traffico e un coinvolgimento costanti durante tutto l’anno. Tuttavia, nella realt\u00e0, qualsiasi attivit\u00e0 \u00e8 soggetta a fluttuazioni. Ad esempio, consideriamo un sito di e-commerce che ha grandi picchi di traffico durante le festivit\u00e0 o i saldi.<\/p>\n In questo caso, il rilevamento delle anomalie si trasforma in un’immersione analitica pi\u00f9 ampia. Si parte dalle metriche e si esaminano i dati storici relativi ai livelli di traffico. Utilizzando queste metriche per anticipare i picchi di traffico previsti, \u00e8 possibile iniziare a pensare alle risorse.<\/p>\n Il compito \u00e8 quello di essere proattivi nel dimensionamento delle risorse in base ai livelli di traffico previsti in determinati periodi dell’anno. Ad esempio, potremmo aumentare l’allocazione di CPU e memoria per gestire un carico maggiore. Sul fronte degli acquisti, l’esperienza pu\u00f2 essere stabile e fluida per i nostri clienti. A sua volta, questo non solo pu\u00f2 farci risparmiare ma anche guadagnare.<\/p>\n Anche i siti che si occupano di contenuti legati all’attualit\u00e0, come le testate giornalistiche, devono affrontare le stesse sfide dei siti di ecommerce. In questo caso, i picchi di traffico si verificano quando ci sono eventi importanti o notizie dell’ultima ora.<\/p>\n In questo caso, per\u00f2, la differenza \u00e8 pi\u00f9 critica: i picchi si verificano pi\u00f9 frequentemente e sono anche pi\u00f9 irregolari. Anche l’accesso ai contenuti rilevanti<\/a> \u00e8 spesso fondamentale. Pensiamo alle allerte meteo, ad esempio.<\/p>\n \u00c8 qui che la scalabilit\u00e0 predittiva delle risorse pu\u00f2 dare buoni risultati. Come nel caso dell’e-commerce, l’analisi dei modelli di traffico passati durante eventi simili pu\u00f2 aiutare a prendere decisioni informate su quando scalare e di quanto. Anche il monitoraggio delle tendenze attuali pu\u00f2 essere utile. L’obiettivo principale \u00e8 garantire che il sito rimanga accessibile e reattivo. Sebbene una UX fluida sia altrettanto importante, l’accesso senza interruzioni \u00e8 fondamentale.<\/p>\n Le applicazioni SaaS possono essere volatili, con modelli di utilizzo variabili in base al comportamento dei clienti e alla domanda complessiva del servizio. Un buon esempio \u00e8 quello dell’epidemia di Covid-19 del marzo 2020. 16 milioni di professionisti IT<\/a> sono dovuti rimanere a casa e Slack ha registrato un aumento<\/a> del 20% degli utenti nelle prime due settimane.<\/p>\n Il rilevamento delle anomalie pu\u00f2 aiutare a capire cosa potrebbe andare storto quando si scalano le risorse. Questo aspetto \u00e8 stato molto importante per Slack<\/a> perch\u00e9 era importante aiutare le persone a continuare a lavorare durante la pandemia.<\/p>\n Anche lo scaling predittivo delle risorse \u00e8 fondamentale, perch\u00e9 \u00e8 un modo per ottimizzare la propria infrastruttura in base a qualsiasi modello di utilizzo. Anche in questo caso, l’analisi dei dati storici e l’implementazione di una strategia di scaling proattiva possono aiutare l’UX, minimizzare i costi e costruire la fiducia e la reputazione esterna della propria base di utenti.<\/p>\n Avere un modo per implementare il ridimensionamento delle risorse e rilevare gli scostamenti \u00e8 fondamentale quanto conoscere le strategie. Gli utenti di Kinsta hanno a disposizione la dashboard MyKinsta<\/a>, che contiene una grande quantit\u00e0 di metriche:<\/p>\n Tuttavia, questo non aiuta nelle situazioni in cui si ha bisogno di maggiore flessibilit\u00e0. Lo strumento pi\u00f9 adatto \u00e8 l’API di Kinsta. L’API infatti offre una serie di endpoint per collegarsi alle nostre funzionalit\u00e0, alcune delle quali saranno fondamentali per la scalabilit\u00e0 e l’analisi:<\/p>\n Ne analizzeremo altri in dettaglio pi\u00f9 avanti. Tuttavia, \u00e8 importante capire che l’API di Kinsta copre solo la maggior parte delle basi della scalabilit\u00e0 delle risorse e del rilevamento delle anomalie:<\/p>\n In ogni caso, l’API ha molto da offrire e la sua natura programmatica permette di collegarla ad altri sistemi, di implementare le proprie funzioni e classi e di fare quasi tutto ci\u00f2 che si desidera.<\/p>\n Non utilizzerete lo scaling tutti i giorni e potreste decidere di farlo solo poche volte all’anno. Per questo motivo, esaminiamo qualcosa che farete molto pi\u00f9 regolarmente: rilevare eventuali incongruenze nelle metriche del vostro server.<\/p>\n Il vostro sistema di monitoraggio sar\u00e0 la spina dorsale della vostra proattivit\u00e0. Ci sono molte considerazioni da fare, ma il nostro consiglio \u00e8 di mantenere le cose semplici all’inizio:<\/p>\n Una volta acquisite queste conoscenze, potete iniziare a utilizzare l’API di Kinsta per impostare gli endpoint di cui avete bisogno.<\/p>\n Ci sono alcuni endpoint<\/a> che possono essere utili in questo caso. Ne abbiamo menzionati alcuni in precedenza nel post, ma per completezza, ecco un elenco che riteniamo adatto allo scopo:<\/p>\n Ci sono un paio di endpoint che sono utili per l’analisi delle tendenze:<\/p>\n Se avete bisogno di indicazioni sulle opportunit\u00e0 di scaling, ci sono alcuni endpoint che possono aiutarvi:<\/p>\n Facciamo un esempio di utilizzo di un endpoint per il rilevamento delle anomalie. In questo caso, utilizziamo Node.js<\/a> per verificare la larghezza di banda di un sito. \u00c8 necessario implementare la convalida della chiave API – probabilmente utilizzando variabili d’ambiente<\/a> – e un modo per monitorare costantemente la larghezza di banda.<\/p>\n Per quanto riguarda le notifiche, potreste creare un canale Slack<\/a> per avviare una conversazione quando la larghezza di banda raggiunge un certo limite.<\/p>\n Per individuare eventuali anomalie, dovreste esaminare i dati raccolti per individuare eventuali valori anomali, anche se potreste creare un modo programmatico per cercare metriche anomale. Da l\u00ec potrete iniziare a formulare una risposta.<\/p>\n In poche parole, il vostro script rilever\u00e0 un’anomalia, invier\u00e0 un ping a Slack e voi potrete entrare in azione. Il modo in cui lo farete dipender\u00e0 dal vostro piano di risposta. Questo processo stabilir\u00e0 come indagare, diagnosticare e risolvere la causa del problema.<\/p>\n Ad esempio, se si tratta di un sito di un cliente, potreste avere un accordo sul livello di servizio<\/a> che richiede una risposta entro un determinato periodo di tempo. Per quanto riguarda il vostro sito, potreste semplicemente accedere alle vostre statistiche e controllare i log<\/a>.<\/p>\n Le modalit\u00e0 di configurazione dipendono dalle dimensioni del vostro team, dai requisiti e dalle risorse. A prescindere da questo, il passo successivo sar\u00e0 quello di implementare la vostra strategia di scaling delle risorse.<\/p>\n Una volta conosciute le metriche di base, potete decidere se scalare o meno le risorse. Come abbiamo descritto in una sezione precedente, la previsione automatica \u00e8 un’operazione da implementare. L’Hosting di Applicazioni di Kinsta offre questa possibilit\u00e0 per ogni piano. Trovate l’opzione all’interno della dashboard MyKinsta, nella scheda Applicazioni<\/strong>.<\/p>\n Tuttavia, l’API di Kinsta pu\u00f2 fornirvi gli strumenti per effettuare le vostre previsioni con precisione e sicurezza.<\/p>\n Ci sono alcune strategie che si possono adottare:<\/p>\n Se osservate gli endpoint Gli stessi endpoint che utilizzate per analizzare le tendenze sono ottimi anche per prevedere il ridimensionamento delle risorse. Infatti, l’utilizzo della CPU e della memoria sono entrambi segnali rivelatori della necessit\u00e0 di aumentare la potenza del vostro server.<\/p>\n Infine, i colli di bottiglia nei processi di caricamento delle pagine possono divorare le vostre risorse ed essere un obiettivo ideale per il ridimensionamento. L’endpoint Tuttavia, questo potrebbe<\/em> essere un segnale di necessit\u00e0 di scalare il livello e potrebbe anche evidenziare un punto di ottimizzazione. Si tratta di “vittorie rapide” (in teoria) lungo il percorso, perch\u00e9 la risoluzione di questi problemi incapsulati dovrebbe ridurre la quantit\u00e0 di risorse allocate al sito e di conseguenza liberarle.<\/p>\n Prima di concludere, parliamo di alcune tattiche, pratiche tipiche e suggerimenti per integrare il predictive scaling e il rilevamento delle anomalie nel vostro flusso di lavoro. La proattivit\u00e0 \u00e8 un aspetto che abbiamo citato spesso in questo articolo e ci sono alcuni modi per essere un passo avanti in quest’area:<\/p>\nI vantaggi della scalabilit\u00e0 predittiva delle risorse<\/h3>\n
\n
L’importanza del rilevamento delle anomalie<\/h3>\n
\n
Scenari reali per lo scaling predittivo delle risorse e il rilevamento delle anomalie<\/h2>\n
1. Siti di e-commerce durante le stagioni di punta<\/h3>\n
![\"Il](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/ecommerce-holiday.png\")
2. Siti di notizie e media durante i grandi eventi<\/h3>\n
![\"La](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/nbc-news.png\")
3. Applicazioni Software as a Service (SaaS) con modelli di utilizzo variabili<\/h3>\n
![\"Un](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/slack-app.png\")
Le funzionalit\u00e0 dell’API di Kinsta per la gestione delle risorse<\/h2>\n
![\"Un'immagine](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/mykinsta-dashboard-1.png\")
\n
Utilizzo CPU.<\/code> \u00c8 possibile monitorare l’utilizzo della CPU<\/a> del server nel tempo, il che aiuter\u00e0 a identificare le tendenze e i potenziali colli di bottiglia prima che diventino un problema.<\/li>\nUtilizzo Memoria.<\/code> Si pu\u00f2 monitorare il consumo di memoria<\/a> per assicurarsi che il sito abbia risorse sufficienti per gestire il carico di lavoro e aumentarlo quando necessario.<\/li>\nLarghezza di banda.<\/code> L’analisi dei dati totali trasmessi<\/a> pu\u00f2 essere un buon indicatore per implementare la propria strategia di scaling.<\/li>\nRichieste pi\u00f9 lente.<\/code> Questo \u00e8 uno dei tanti endpoint<\/a> che possono mostrare quali sono le richieste e le risposte che hanno un impatto maggiore sulle prestazioni del sito.<\/li>\n<\/ul>\n\n
Rilevare le anomalie con l’API di Kinsta<\/h2>\n
Impostazione del monitoraggio e degli avvisi<\/h3>\n
\n
Endpoint dell’API Kinsta per rilevare le anomalie<\/h3>\n
\n
Larghezza di banda.<\/code> Ne abbiamo gi\u00e0 parlato: \u00e8 il modo in cui misurerete i dati totali che trasmettete.<\/li>\nRichieste HTTP al minuto.<\/code> Questo \u00e8 semplice: misura letteralmente il numero di richieste HTTP che il vostro sito riceve ogni minuto!<\/li>\n<\/ul>\n\n
Utilizzo CPU.<\/code> La nostra metrica mostra l’utilizzo medio totale della CPU per un periodo di tempo selezionato.<\/li>\nUtilizzo memoria.<\/code> Allo stesso modo, questa \u00e8 la media del consumo totale di memoria per un periodo di tempo selezionato.<\/li>\n<\/ul>\n\n
Tempo di build.<\/code> Il monitoraggio di questo dato mostra il tempo necessario per costruire un’applicazione. Insieme alle metriche sull’utilizzo della CPU e della memoria (tra le altre cose), pu\u00f2 aiutare a farsi un’opinione sulla necessit\u00e0 di scalare.<\/li>\nTempo di esecuzione.<\/code> Il tempo totale di esecuzione dell’applicazione pu\u00f2 aiutare a decidere dove dare priorit\u00e0 all’utilizzo, a trovare i colli di bottiglia delle prestazioni e molto altro ancora.<\/li>\n<\/ul>\nimport fetch from 'node-fetch';\n\n\nconst API_TOKEN = <YOUR-API-TOKEN>;\nconst APPLICATION_ID = <YOUR-COMPANY-ID>;\n\nasync function checkBandwidth(token, id, timeframeStart, timeframeEnd, intervalInSeconds) {\n const query = new URLSearchParams({\n interval_in_seconds: intervalInSeconds,\n timeframe_start: timeframeStart,\n timeframe_end: timeframeEnd,\n }).toString();\n\n const resp = await fetch(`https:\/\/api.kinqsta.com\/v2\/applications\/${id}\/metrics\/bandwidth?${query}`, {\n method: 'GET',\n headers: {\n Authorization: 'Bearer <YOUR-API-KEY>',\n },\n\n });\n\n const data = await resp.json();\n\n if (!resp.ok) {\n console.error('Error checking bandwidth:', data);\n return;\n }\n\n console.log('Bandwidth data:', data);\n\n}\n\n\nasync function run() {\n const timeframeStart = '2021-07-22T18:10:45.511Z';\n const timeframeEnd = '2021-07-22T18:10:45.511Z';\n const intervalInSeconds = '3600';\n\n await checkBandwidth(API_TOKEN, APPLICATION_ID, timeframeStart, timeframeEnd, intervalInSeconds);\n}\n\nrun().catch(error => {\n console.error('An error occurred', error);\n process.exit(1);\n});\n<\/code><\/pre>\nRispondere alle anomalie<\/h3>\n
![\"Una](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/kinsta-logs.png\")
Implementare lo scaling predittivo delle risorse con l’API di Kinsta<\/h2>\n
\n
larghezza di banda<\/code>, richieste HTTP al minuto<\/code> e tempo medio di risposta<\/code>, questi sono ottimi modi per individuare gli ambiti di scalabilit\u00e0. Noterete che il controllo della larghezza di banda e delle richieste HTTP<\/a> fa il “doppio lavoro” per lo scaling delle risorse e il rilevamento delle anomalie.<\/p>\nrichieste pi\u00f9 lente<\/code> \u00e8 da tenere sotto controllo. Segnala i peggiori problemi del vostro sito e la dashboard di MyKinsta fornisce<\/a> un grafico:<\/p>\n![\"Una](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2024\/05\/slowest-requests.png\")
Suggerimenti e trucchi per integrare lo scaling predittivo e il rilevamento delle anomalie nel proprio flusso di lavoro<\/h2>\n