Szukasz zalecenia dotyczącego pomiaru aplikacji o wysokiej dostępności korzystającej z sieci CDN

Pracuję dla firmy z listy Fortune 500, która boryka się z dokładnym pomiarem wydajności i dostępności dla aplikacji wysokiej dostępności (tj. Aplikacji, które zwiększają się o 99,5% z 5-sekundową nawigacją między stronami). Uwzględniamy zarówno zaplanowane, jak i nieplanowane przestoje, aby określić ten numer dostępności. Jednak niedawno dodaliśmy CDN do miksu, co nieco komplikuje nasze wskaźniki. CDN obsługuje teraz około 75% naszego ruchu, a resztę przesyła na nasze własne serwery.

Próbujemy zmierzyć to, co nazywamy „prawdziwym doświadczeniem użytkownika” (tj. Nasze skrypty testowe emulują typowego użytkownika klikającego aplikację). Te skrypty monitorujące znajdują się poza naszą siecią, co oznacza, że ​​docieramy do CDN około 75% czas.

Kierownictwo zdecydowało, że bierzemy najgorszy scenariusz do pomiaru dostępności. Więc jeśli nasze serwery pochodzenia mają problemy, ale CDN dobrze podaje treść, nadal decydujemy się na dostępność. To samo jest prawdą na odwrót. Uważam, że dopóki „wrażenia użytkownika” będą skuteczne, nie powinniśmy niepotrzebnie się karać. W końcu CDN ma na celu poprawę wydajności i dostępności!

Zastanawiam się tylko, czy ktoś ma wiedzę na temat tego, jak inne firmy z listy Fortune 500 obliczają swoje liczby dostępności? Patrzę na przykład na apple.com witryny sklepowej, która korzysta z sieci CDN, która nigdy nie wydaje się nie działać (chyba że pojawi się ważna informacja o produkcie). Byłoby wspaniale mieć twarde, oparte na faktach dane, ponieważ nie sądzę, że musimy niepotrzebnie zranić się tymi wskaźnikami. My są podejmowaniu decyzji biznesowych na podstawie tych liczb.

Mogę jednak powiedzieć, że biorąc pod uwagę, że te wskaźniki są widoczne dla zarządzania, problemy są rozwiązywane i rozwiązywane dość szybko (czytaj: dość szybko przecinamy biurokrację). Niestety, jako programista, nie chcę, aby kierownictwo myślało aplikacja jest w górę lub w dół, ponieważ jakiś czynnik zewnętrzny (np. CDN) wpływa na liczby.

Myśli?

(Błędnie opublikowałem to pytanie na StackOverflow, z góry przepraszam za cross-post)

W streszczeniu powiedziałbym, że powinieneś ostro zdefiniować, co stanowi „dostępny” vs. „niedostępny” i zmierzyć się z tym. Na przykład, możesz mieć SLA wydajności po stronie klienta dla strony od 1 sekundy do „fold” i 3 sekundy dla strony całkowicie renderowanej. Jeśli nie spełniasz warunków umowy SLA, powinieneś liczyć to jako brak dostępności w tym okresie. Nie powinno mieć znaczenia, czy trafisz na CDN, czy nie - liczy się przede wszystkim wygoda użytkownika.

Ponieważ jednak wykonujesz pomiary tylko co 5 minut, rozsądnie wydaje się osobne mierzenie trafień w CDN w porównaniu z witryną główną i obliczenie, że 75% dostępności pochodzi z CDN, a 25% z serwera głównego. Trudność polega na tym, że 75% to tylko średnia. Aby dokładnie przypisać winę za dany okres, musisz wiedzieć, kiedy jedna lub druga strona nie ma kontaktu z klientem, np. Podczas planowanej zmiany lub po ręcznym działaniu w przypadku wykrycia problemu. Musisz także wziąć pod uwagę to, co dzieje się, gdy jedna z witryn głównych lub CDN nie działa. Czy klient otrzymuje HTTP 500, czy po prostu przejrzyście przełącza się na działającą witrynę? Wiele zależy od rozwiązania do równoważenia obciążenia. Opisany przez ciebie „najgorszy przypadek” wydaje się zbyt uproszczony. Zapytaj siebie, "

Jeśli chodzi o to, czy powinieneś wziąć na siebie „winę”, gdy CDN nie działa: absolutnie. Jeśli 75% twoich trafień trafia do CDN, 75% twoich doświadczeń klientów jest od nich zależnych. Jesteś odpowiedzialny za zapewnienie swoim klientom dobrego doświadczenia, więc jeśli CDN ma problemy, musisz użyć zasobów inżynieryjnych, aby to udowodnić i skontaktować się z dostawcą.

Inną rzeczą do przemyślenia jest to, co dzieje się, gdy strona główna jest niedostępna przez dłuższy czas. Jak to opisałeś, wygląda na to, że CDN jest statyczną kopią treści na głównej stronie. Jeśli witryna główna nie działa przez długi czas, CDN może zacząć się zużywać. Może więc częścią umowy SLA powinna być świeżość: 1 sekunda do „zagięcia” i 3 sekundy dla całkowicie zrenderowanej strony, z zawartością nie starszą niż 15 minut.

Zgadzam się z user44700, lepiej jest oddzielić testy dostępności dla twoich serwerów od CDN i śledzić dwa niezależne niezależne. Twoja prawdziwa dostępność będzie Dostępna na serwerze * Dostępna na CDN, ponieważ jeśli jedno z nich ulegnie awarii - rozważasz, że Twoja strona / witryna nie działa. Spowoduje to również niższe koszty u któregokolwiek z dostawców monitoringu.

Nie pójdę drogą tworzenia jednego testu przeglądarki i sprawdzania, które elementy zawiodły, podczas gdy może to działać, a niektóre firmy, takie jak Catchpoint, mają pojęcie „dostępność treści” - może nie być dokładnie tym, czego chcesz w tym przypadku. Powiedzmy na przykład, że twoja strona ma wywołanie do CDN dla pliku, który dostarcza 404, większość rozwiązań monitorujących powie ci, że to jest awaria - ale czy to naprawdę nie była CDN? Czy ten plik był nawet ważny? może ktoś zapomniał usunąć odniesienie do relikwii, którego żaden użytkownik nie zauważa.

Możesz przeczytać ten post na blogu, aby uzyskać więcej pomysłów: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

Raporty SLA powinny dokładnie odzwierciedlać rzeczywistość. Jeśli mierzysz dostępność z perspektywy użytkownika i występują problemy tylko z serwerem dokonującym pomiaru, zgłoszenie tego problemu w umowie SLA nie odzwierciedla wrażenia użytkownika.

Rozumiem, że chcę utrzymać informacje źródłowe na wysokim poziomie, być może zawsze je zgłaszam, nawet jeśli są niedokładne, ale z notatką określającą dlaczego.

Jeśli nie możesz dojść do porozumienia, być może istnieje techniczne rozwiązanie, dzięki któremu serwer pomiarowy będzie mniej zawodny.

Jeśli informacje są zgłaszane jako awarie, a nie były, jaką wartość zapewnia raportowanie?

W moim środowisku raportujemy z wielu źródeł. Metodologia monitorowania zewnętrznego służąca do zgłaszania dostępności z perspektywy zewnętrznej, a także zgłaszania naszego wewnętrznego systemu rejestrowania awarii, który jest wprowadzany przez człowieka i uwzględnia wiele czynników, które najdokładniej odzwierciedlają sytuację.

Gomez i Keynote to zaakceptowane przez przedsiębiorstwo rozwiązania do gromadzenia wspomnianych typów wskaźników. Gomez ma również usługę, która monitoruje Twój użytkownik końcowy, pozyskując plik javascript w języku google-analytics-esque.

Pingdom są dobre: http://www.pingdom.com/

Jesteśmy Fortune 500 z witryną obsługującą CDN i używamy kilku rzeczy. Prawidłowo ustaliłeś, że musisz mierzyć różne rzeczy, jeśli chcesz wykryć różne rzeczy. Nie jest dla mnie jasne, czego konkretnie chcesz - numery dostępności, które pomogą Ci ustalić, kiedy aplikacja jest faktycznie wyłączona, lub liczby, które nie pozwalają na zarządzanie. Tak czy inaczej...

1. Zewnętrzny monitoring syntetyczny - Keynote / Gomez / Webmetrics. Kiedyś używaliśmy Keynote, teraz używamy Gomeza. Oczywiście, jak zauważasz, obejmuje to również CDN i wszelkie inne elementy zewnętrzne - co jest dobre do pomiaru ogólnego SLA, ale nie tak dobre do określenia SLA aplikacji.

Aby uzyskać z niego „CDN”, możesz wziąć inny monitor Keynote / Gomez i skierować go na swoje aplikacje, a nie przez CDN, używając alternatywnej nazwy DNS lub czegoś takiego. Ale ponieważ nadal ma statyczne zasoby, jest bardziej przydatny pod względem wydajności niż dostępności. I utrzymuje w pętli przerwy w dostawie Internetu, awarie agentów itp., Co jest odpowiednie do niektórych celów, a nie innych.

2. Monitorowanie rzeczywistych użytkowników. Jest oparty na sieci (Coradiant, Tealeaf) i oparty na tagach (Jiffy, Gomez). Używamy Coradiant jako sniffera sieciowego, który określa rzeczywistą wydajność zasobów hostowanych tutaj w naszym centrum danych - innymi słowy, rzeczywiste aplikacje, a nie wszystkie śmieci statyczne w sieci CDN. Następnie napisaliśmy raporty w celu ustalenia wskaźników błędów i wydajności aplikacji i wykorzystaliśmy Apdex (apdex.org) jako miarę pochodną. W niektórych przypadkach nie można korzystać z sieci (zbyt duży ruch lub zasoby nie są hostowane tam, gdzie można uzyskać dostęp do sieci), a oparte na tagach nie są tak niezawodne. Ma ogromną korzyść polegającą na tym, że rzeczywiście widzi czas reakcji i błędy użytkownika końcowego - łatwo jest ustawić syntetyczny monitor, który nie będzie zawierał błędów we wszystkich przypadkach, w których robi to prawdziwy użytkownik.

3. Lokalne monitorowanie syntetyczne. Nagios / zabbix / sitescope / setka innych. Skieruj monitor na aplikację lokalnie (nie przechodź przez CDN). W przypadku monitorowania dostępności (jak w przypadku wysyłania strony, aby kogoś obudzić) jest to złoty standard. Nie uwzględnia rzeczy sieciowych.

4. Monitorowanie dziennika. W pewnym sensie jest to monitorowanie rzeczywistego użytkownika w getcie. Ale jeśli naprawdę chcesz zobaczyć, co się popełniło, jest to całkiem przydatne. Ma zaletę „nie, tak się naprawdę stało”, jaką jest monitorowanie użytkowników. Często tylko dostępność, chyba że logujesz się w warstwie internetowej, w którym to przypadku pokazuje, ile czasu zajęło zakończenie twojego serwera - nie jest to pomocne dla SLA skierowanej do użytkownika, ale bardzo pomocne dla "kodu, nad którym musimy pracować . ” Użyj splunk.

Nie jest to albo, albo używamy ich wszystkich, ponieważ chcecie „historii użytkownika końcowego”, a także „jakiego programisty potrzebujemy”.

BrowserMob jest świetny