Alla ricerca di una raccomandazione sulla misurazione di un'app ad alta disponibilità che utilizza una rete CDN

Lavoro per un'azienda di Fortune 500 che lotta per misurare accuratamente le prestazioni e la disponibilità per applicazioni ad alta disponibilità (ad esempio, app che aumentano del 99,5% con 5 secondi di navigazione da pagina a pagina). Teniamo conto dei tempi di inattività pianificati e non programmati per determinare questo numero di disponibilità. Tuttavia, recentemente abbiamo aggiunto una CDN al mix, il che complica un po 'le nostre metriche. La CDN ora gestisce circa il 75% del nostro traffico, inviando il resto ai nostri server.

Cerchiamo di misurare ciò che chiamiamo "vera esperienza dell'utente" (ovvero, i nostri script di test emulano un tipico utente facendo clic sull'applicazione.) Questi script di monitoraggio si trovano al di fuori della nostra rete, il che significa che stiamo colpendo la CDN di circa il 75% di il tempo.

Il management ha deciso di prendere lo scenario peggiore per misurare la disponibilità. Quindi, se i nostri server di origine stanno riscontrando problemi, ma la CDN sta pubblicando i contenuti correttamente, continuiamo a fare colpo sulla disponibilità. Lo stesso vale il contrario. Il mio pensiero è che fino a quando "l'esperienza dell'utente" avrà successo, non dovremmo punirci inutilmente. Dopotutto, un CDN è lì per migliorare le prestazioni e la disponibilità!

Mi chiedo solo se qualcuno ha qualche conoscenza su come le altre società Fortune 500 calcolano i loro numeri di disponibilità? Guardo apple.com, ad esempio, di una vetrina che utilizza un CDN che non sembra mai essere inattivo (a meno che non ci sia un annuncio di prodotto importante). Sarebbe bello avere alcuni dati concreti e concreti perché non credo che dobbiamo ferirci inutilmente su queste metriche. Noi stiamo facendo le decisioni di business sulla base di questi numeri.

Posso dire, tuttavia, dato che queste metriche sono visibili alla direzione, i problemi vengono risolti e risolti piuttosto rapidamente (leggi: abbiamo tagliato la burocrazia abbastanza rapidamente.) Sfortunatamente, come sviluppatore, non voglio che il management pensi che l'applicazione è attiva o negativa perché alcuni fattori esterni (ad esempio, CDN) stanno influenzando i numeri.

Pensieri?

(Ho erroneamente pubblicato questa domanda su StackOverflow, scusa in anticipo per il cross-post)

In astratto, direi che dovresti definire con precisione ciò che costituisce "disponibile" rispetto a "non disponibile" e misurarti contro di esso. Ad esempio, potresti avere uno SLA delle prestazioni sul lato client per il sito da 1 secondo alla "piega" e 3 secondi per una pagina completamente renderizzata. Quando non si soddisfa lo SLA delle prestazioni, è necessario considerarlo come un errore di disponibilità per quel periodo di tempo. Non dovrebbe importare se stai colpendo la CDN o meno: l'esperienza dell'utente è ciò che conta.

Tuttavia, dal momento che stai solo misurando ogni 5 minuti, sembra ragionevole misurare separatamente i risultati sulla CDN rispetto al sito principale e calcolare che il 75% della disponibilità proviene dalla CDN e il 25% dal master. La difficoltà qui è che il 75% è solo una media. Per attribuire la colpa in modo accurato per un determinato periodo di tempo, è necessario sapere quando l'uno o l'altro sito non è realmente rivolto al cliente, ad esempio durante una modifica pianificata o dopo un'azione manuale quando viene rilevato un problema. È inoltre necessario tenere conto di ciò che accade quando uno del sito principale o il CDN sono inattivi. Il cliente riceve un HTTP 500 o esegue il failover in modo trasparente sul sito di lavoro? Molto dipende dalla soluzione di bilanciamento del carico. La metrica "peggiore" che hai descritto sembra troppo semplicistica. Chiedilo a te stesso, "

Per quanto riguarda se si dovrebbe prendere "la colpa" quando il CDN è inattivo: assolutamente. Se il 75% dei tuoi successi va alla CDN, il 75% della tua esperienza del cliente dipende da loro. Sei responsabile di fornire una buona esperienza ai tuoi clienti, quindi se la CDN sta riscontrando problemi, devi usare le tue risorse di ingegneria per dimostrarlo e fare seguito al fornitore.

Un'altra cosa a cui pensare è cosa succede quando il sito principale non è disponibile per un lungo periodo di tempo. Come l'hai descritto, sembra che la CDN sia una copia statica del contenuto del sito principale. Se il sito principale è inattivo da molto tempo, la rete CDN potrebbe iniziare a diventare obsoleta. Quindi forse parte del tuo SLA dovrebbe essere la freschezza: 1 secondo alla "piega" e 3 secondi per una pagina completamente renderizzata, con contenuto non più vecchio di 15 minuti.

Sono d'accordo con user44700, è meglio separare i test di disponibilità per i tuoi server rispetto alla CDN e tracciare i due in modo indipendente. La tua vera disponibilità sarà Server Avail * CDN Avail, poiché se uno dei due non funziona, stai considerando che la tua pagina / sito è inattiva. Questo ti costerà anche meno con nessuno dei fornitori di monitoraggio.

Non vorrei seguire la strada della creazione di un test del browser e guardare quali elementi non sono riusciti, mentre potrebbe funzionare e alcune aziende come Catchpoint hanno il concetto di "disponibilità dei contenuti" - potrebbe non essere esattamente quello che vuoi in questo caso. Supponiamo ad esempio che la tua pagina web abbia una chiamata al CDN per un file che recapita 404, la maggior parte delle soluzioni di monitoraggio ti dirà che si tratta di un errore, ma è stato davvero il CDN a non riuscire? Quel file era persino importante? forse qualcuno ha appena dimenticato di rimuovere alcuni riferimenti reliquia che nessun utente nota.

Puoi leggere questo post del blog per qualche altra idea: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

La segnalazione SLA dovrebbe riflettere accuratamente la realtà. Se stai misurando la disponibilità dal punto di vista dell'utente e solo il server che esegue la misurazione sta riscontrando problemi, la segnalazione di tale problema all'interno del tuo SLA non rifletterebbe l'esperienza dell'utente.

Riesco a capire il desiderio di mantenere le informazioni di origine su uno standard elevato, magari segnalandole sempre anche se inesatte ma con una nota che identifica il perché.

Se non riesci a trovare un accordo, forse esiste una soluzione tecnica per rendere meno fallibile il server di misurazione.

Se le informazioni sono segnalate come un'interruzione e non lo sono state, quale valore fornisce la segnalazione?

Nel mio ambiente, segnaliamo da più fonti. Una metodologia di monitoraggio esterna per segnalare la disponibilità da una prospettiva esterna, nonché per segnalare il nostro sistema di registrazione delle interruzioni interne, che è inserito dall'uomo e considera molteplici fattori che riflettono più accuratamente la situazione.

Gomez e Keynote sono soluzioni accettate dall'azienda per raccogliere i tipi di metriche citate. Gomez ha anche un servizio che monitora la tua UX dell'utente finale acquistando un file javascript google-analytics-esque.

Pingdom è buono: http://www.pingdom.com/

Siamo un Fortune 500 con un sito abilitato per CDN e usiamo diverse cose. Hai correttamente stabilito che devi misurare cose diverse se vuoi rilevare cose diverse. Non mi è chiaro cosa desideri specificamente: numeri di disponibilità per aiutarti a determinare quando un'app è in realtà inattiva o numeri che ti fanno perdere la gestione. Comunque...

1. Monitoraggio sintetico esterno - Keynote / Gomez / Webmetrics. Usavamo Keynote, ora usiamo Gomez. Ovviamente, come si nota, questo include anche la CDN e qualsiasi altro componente esterno, il che è utile per misurare lo SLA complessivo, ma non è altrettanto utile per determinare gli SLA delle applicazioni.

Per ottenere il "CDN da esso" è possibile prendere un altro monitor Keynote / Gomez e puntarlo verso le tue app non attraverso il CDN utilizzando un nome DNS alternativo o quant'altro. Ma poiché ha ancora risorse statiche, è più utile per le prestazioni che per la disponibilità. E mantiene le interruzioni di Internet, interruzioni degli agenti, ecc. In loop, che è appropriato per alcuni scopi e non altri.

2. Monitoraggio reale dell'utente. C'è basato su rete (Coradiant, Tealeaf) e basato su tag (Jiffy, Gomez). Usiamo Coradiant come sniffer di rete e determina le prestazioni reali degli asset ospitate qui nel nostro data center, in altre parole, le applicazioni effettive e non tutta la spazzatura statica sulla CDN. Abbiamo quindi scritto rapporti per determinare i tassi di errore e le prestazioni dell'app e abbiamo utilizzato Apdex (apdex.org) come metrica derivata. In alcuni casi non è possibile utilizzare la rete (troppo traffico o le risorse non sono ospitate dove è possibile accedere alla rete) e il tag-based non è così affidabile. Ha l'enorme vantaggio di vedere effettivamente i tempi di risposta e gli errori dell'utente finale: è facile impostare un monitor sintetico che non si verifichi in tutti i casi di un utente reale.

3. Monitoraggio sintetico locale. Nagios / zabbix / sitescope / cento altri. Punta un monitor sulla tua app localmente (non passare attraverso la CDN). Per il monitoraggio della disponibilità utilizzabile (come in, inviare una pagina per svegliare qualcuno), questo è il gold standard. Non tiene conto delle cose di rete.

4. Monitoraggio del registro. In un certo senso, questo è ghetto monitoraggio reale dell'utente. Ma se vuoi davvero vedere cosa è successo quando è abbastanza utile. Ha il vantaggio "no davvero quello che è successo" del monitoraggio reale degli utenti. Spesso solo la disponibilità, a meno che tu non stia registrando il tempo impiegato sul livello Web, nel qual caso ti mostra quanto tempo ha impiegato la fine del tuo server - non utile per gli utenti che si trovano ad affrontare SLA, ma molto utile per "su quale codice dobbiamo lavorare ". Usa splunk.

Non è uno dei due o, li usiamo tutti, perché tu vuoi la "storia dell'utente finale" e "su quale programmatore dobbiamo appoggiarci".

BrowserMob è eccezionale