Real User Monitoring at Scale @ Atmosphere Conference 2016
•Download as PPSX, PDF•
0 likes•128 views
This document summarizes a real user monitoring system at scale. The key points are: 1. The system monitors over 20 million real users, 7 million requests per minute, and 150 million daily page views across 3 data centers and 3,000 servers. 2. Data is collected from over 40 teams and 250 daily deployments using script injection and sent to 3 data centers. It is ingested into Kafka and replicated for redundancy. 3. The ingested data is processed by Storm and aggregated metrics are stored in Graphite for presentation and analysis to provide insights for over 300 specialists. Custom alerts are also used.
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Similar to Real User Monitoring at Scale @ Atmosphere Conference 2016
Similar to Real User Monitoring at Scale @ Atmosphere Conference 2016 (20)
More from DreamLab
More from DreamLab (13)
Recently uploaded
Recently uploaded (20)
Real User Monitoring at Scale @ Atmosphere Conference 2016
- 1. Real User Monitoring at scale Jarosław Bloch Albert Łącki
- 4. 20 mln real users 7 mln requests every minute 150 mln PV daily
- 5. 3 data centers 3 000 servers and devices 130 Gbps traffic
- 6. 40 teams > 250 deployments daily 300 specialists
- 8. Speed search +0,4s PV/UU -0,5% load +35% Revenue -5% load +250ms PV/UU -1,8% Revenue/UU -4,3%
- 12. User experience Our responsibility Under our control
- 17. ?
- 18. Real User Monitoring ? ? ? collection ingestion processing presentation
- 19. Data collection
- 20. <script> var data = collect(); data.send(); </script> Data collection
- 21. Navigation Timing API onLoad DOM Processing ResponseRequestTCP, DNSRedirects navigationStart fetchStart requestStart responseStart domLoading responseEnd domInteractive domComplete
- 23. JS Errors try { … } catch (ex) { collect(ex); }
- 27. Script injection
- 30. Data ingestion
- 36. Presentation
- 39. Custom alerts
- 41. Druid
- 43. Deployments
- 44. Instant feedback
- 47. Thank you!
Editor's Notes
- opowiemy o tym jak w DreamLabie robimy Real User Monitoring dla milionów użytkowników. czym się na co dzień zajmujemy i z jakimi wyzwaniami się mierzymy.
- DL - spółka IT - część grupy RAS Spółka medialna obecna w kilku krajach Europy RAS dostarcza treści przez różne kanały - print, internet - Dla nas oczywiście istotne jest to ostatnie
- Tworzymy serwisy, aplikacje mobilne, platformy IT Informacyjne: Onet, Fakt, Newsweek, Ecommerce: Skąpiec, Opineo, Społecznościowe: Nasza-Klasa, Sympatia Oraz wiele innych oraz ich odpowiedników w pozostałych krajach Na co to się przekłada?
- Przede wszystkim na gigantyczną liczbę użytkowników Którzy generują ogromną liczbę zapytań
- To wszystko podawane z 3 serwerowni Ogromny ruch sieciowy Masa sprzętu wykorzystywanego aby sobie z nim poradzić
- Za tym wszystkim stoją ludzie 40 zespołów w 3 biurach – w Krakowie, Wrocławiu i Warszawie Ponad 300 specjalistów Jesteśmy agile, pracujemy w kulturze DevOps, podchodzimy do zmian iteracyjnie Więc mamy ponad 250 wdrożeń dziennie Jak w tak różnorodnym środowisku radzimy sobie z jakością?
- Na jakość składa się wiele czynników – zostańmy przy jednym z nich - szybkości Zastanówmy się czy użytkownicy w ogóle zwracają na takie rzeczy uwagę? Czy jest sens się tym w ogóle zajmować?
- Nie tylko my zadawaliśmy sobie takie pytanie Niewielki wzrost czasu ma realny wpływ na biznes Jeżeli strona ładuje się wolniej to ludzie odejdą do konkurencji Podobnie z innymi usługami – np. wyniki wyszukiwania Nawet niewielka zmiana może powodować duże konsekwencje
- Musimy wiedzieć, czyli mierzyć Potrzebujemy ciągłego monitoringu działania usług No to od czego zacząć?
- Na działanie usługi ma wpływ masa różnych czynników Zaczynając od obciążenia serwerów bazodanowych A kończąc na takich szczegółach jak temperatura pojedynczego dysku w macierzy Każdy z nas to monitoruje Ale czy to wystarczy Źle działająca baza danych może spowodować problemy u użytkownika Suma dobrze działających komponentów nie musi być dobrze działającą usługą Wyjdźmy więc poziom wyżej
- Potraktujmy usługę jako całość Spróbujmy wpiąć się w miejscu w którym łączy się do nas klient moniotrujemy na ostatnim elemencie infrastruktury przed użytkownikiem Wydawałoby się że to wystarczy - przecież wpinamy się w ostatnim punkcie naszej architektury!
- Za co tak naprawdę ocenia nas użytkownik? Typowy Janusz internetu przeglądający profile na sympatii Interesuje go to jak serwis działa w jego przeglądarce Nie jak szybko odpowiada serwer HTTP Zamknięcie się tylko wewnątrz naszej infrastruktury Monitorowanie tego co mamy pod kontrolą to za mało, no to co z tym zrobić?
- Wyjdźmy z monitoringiem poza naszą infrastrukturę Są gotowe usługi które takie podejście realizują również z nich korzystamy zazwyczaj są to automaty udające przeglądarki dostarczają próbniki w wielu lokalizacjach Czy to faktycznie oddaje user experience?
- Patrzcie na to zdjęcie za nami To są nasi użytkownicy Każdy z nich jest inny Jest ich 20 milionów
- Na dodatek korzystają z wielu różnych urządzeń 6 z rzędu rok mobile ;-) Nawet lodówki! Wiele przeglądarek – w różnych wersjach Dochodzi wymiar geograficzny RS - praktycznie tylko mobile, czyli duże opóźnienia HU – bardzo dobra sieć szkieletowa Nie jesteśmy w stanie przewidzieć i sprawdzić wszystkich możliwości Nie damy rady kupić tylu próbników bo będzie to po prostu za drogie A chcemy być pewni że wszyscy użytkownicy otrzymują usługę najwyżej jakości
- Użyjmy naszych użytkowników jako próbnika Niech raportuje sam do nas informacje o tym jak działa u niego usługa I to jest właśnie real user monitoring Co więcej w ten sposób mierzymy user experience a nie jakiś techniczny parametr
- Tylko jak to zrobić w praktyce? Zaczęliśmy szukać gotowych rozwiązań na rynku – są Albo nie wytrzymają ruchu Albo dane które dostarczają są dostępne z pewnym opóźnieniem Co więcej zamykamy się jedynie na metryki które dostarcza usługa Nikt na rynku nie daje możliwości przetwarzania żywych danych wg. własnych potrzeb Czyli musimy zrobić własne rozwiązanie, pytanie tylko od czego zacząć? Jak je zaprojektować?
- Podzieliśmy sobie ten proces na części składowe Potrzebujemy dane zbierać Dostarczyć do naszej infrastruktury Przetworzyć Zaprezentować w celu wyciągnięcia wniosków No to zacznijmy od początku
- Jak zebrać dane od użytkownika? Użytkownicy łączą się do naszych usług za pomocą przeglądarek Spróbujmy wykorzystać przeglądarki użytkowników W jaki sposób?
- na stronach umieszczamy skrypt zbierający dane Pytanie tylko co da się wyciągnąć z przeglądarki?
- Navigation Timing API Cały cykl ładowania strony - wszystkie informacje o połączeniu, DNS, …. Informacje o renderowaniu strony Zdarzenia - domInteractive, domComplete Jak mierzyć RTT za pomocą Navigation Timing API
- Oczywiście na proces ładowania strony mają wpływ też zasoby – css, js, obrazki, reklamy Do tego też jest API Daje identyczne informacje jak Navigation Timing API tyle że dla każdego z zasobów osobno Pamiętajcie tylko o tym, że różnie przeglądarki traktują zasoby ładowane z innych domen Trzeba zapewnić że będą odpowiednie nagłówki My jesteśmy w tej dobrej pozycji że podajemy wszystko z własnej infrastruktury więc możemy to zapewnić
- No ale czasy to nie wszystko Warto zbierać również wszystkie możliwe do przechwycenia wyjątki
- Na tym etapie wyniki są nadal u użytkownika Potrzebujemy je dostarczyć do naszej infrastruktury aby je dalej przetwarzać Nie jest to takie proste, bo tych danych jest bardzo dużo 3 mln zdarzeń na minutę Co przekłada się na wiele GB danych do przesłania Zaczęliśmy szukać usługi która może sobie z tym poradzić
- W naszym przypadku jest to nasz serwer brzegowy – Accelerator Jest to usługa zbudowana w modelu CDN Ulokowana zarówno w naszej infrastrukturze jak i u zewnętrznych operatorów Przystosowana do podawania wszystkich naszych serwisów i streamingu video Więc postanowiliśmy jej użyć również do zbierania danych
- Potrzebna była jedynie niewielka modyfikacja która umożliwiłaby przyjmowanie tych danych w sposób asynchroniczny Chcieliśmy zapewnić że wysyłane dane będą natychmiast obsłużone aby uniknąć wiszących połączeń oczekujących na przetworzenie zdarzenia To nie bank, nie potrzebujemy transakcyjności Natychmiast odpowiadamy OK i buforujemy zdarzenie lokalnie na węźle Na każdym węźle na brzegu bufor RabbitMQ Erlang Bardzo lekki i szybki – 2000 msg / sec / core Dodatkowo zapewnia nam buforowanie zdarzeń w przypadku gdyby nie dało się ich przez moment wysłać dalej
- Przy okazji skorzystaliśmy jeszcze z tego że Accelerator podaje serwisy A więc można go użyć w celu zapewnienia automatycznego umieszczenia skryptu pomiarowego na stronach
- Dzięki temu nasi developerzy nie muszą o tym za każdym razem pamiętać Takie podejście znacznie zmniejsza koszty utrzymania A dodatkowo zyskujemy ogromne możliwości paramteryzując osadzany skrypt np. identyfikatorem DC Jesteśmy w stanie skojarzyć działanie usługi u użytkownika z elementem infrastruktury który go obsługiwał Ale wróćmy do naszych danych
- Na tym etapie scaliliśmy miliony pojedynczych zdarzeń w wiele strumieni dostępnych na serwerach brzegowych aby móc wyciągnąć z tych danych jakieś wnioski potrzebujemy większej mocy obliczeniowej zazwyczaj w takim przypadku zbiera się dane przez jakiś czas a następnie wrzuca do Hadoopa i uruchamia przetwarzanie tyle że my potrzebujemy mieć dane online! bo przecież cały czas – pamiętajcie - mówimy o monitoringu w tym celu możemy wykorzystać naszą chmurę i uruchomić w niej przetwarzanie co da nam skalowalność i elastyczność
- Potrzebujemy usługi która będzie: Dobrze się skalować Nie obsłużymy gigabitów ruchu na jednej maszynie Nawet 10Gbps sieć może nam nie wystarczyć Odporna na awarie bo w tym momencie mamy cały strumień danych w jednym miejscu Nie możemy sobie pozwolić na SPOF Kafka – spełnia te kryteria Plik z logiem - piszemy na końcu, czytamy z początku Z wielu miejsc można równocześnie zapisywać w naszym przypadku źródłem danych są węzły Acceleratora
- Rozproszony plik z logiem - piszemy na końcu, czytamy z początku Z wielu miejsc można równocześnie zapisywać w naszym przypadku źródłem danych są węzły Acceleratora
- zapewnia nam replikację danych pomiędzy serwerowniami Dane bardzo cenne mechanizm mirror maker jesteśmy odporni nie tylko na utratę jednej maszyny ale również całego DC bez utraty danych dostarcza dane do dalszego przetwarzania online dla potrzeb monitoringu na HDFS do późniejszego generowania raportów i batchowego przetwarzania Łączymy dwa światy - online i offline Kafka się do tego bardzo dobrze nadaje, gdyż w odróżnieniu klasycznych message brokerów zgodnych z AMQP pozwala wielu konsumentom niezależnie czytać dane w swoim własnym tempie - w końcu to cały czas po prostu plik z logiem, a konsument to po prostu proces przesuwający się po nim
- to nie sztuka mieć dużo danych, sztuką jest umieć coś z nich policzyć
- a więc potrzebujemy sposobu na przerobienie danych na konkretne metryki Może by zapisać te wszystkie dane do relacyjnej bazy danych? I później ją odpytywać o agregaty. A znacie relacyjną bazę danych która wytrzyma 5 mln zapisów na minutę? I jeszcze szybko będzie odpowiadać na zapytania agregujące A przy okazji nie zajmie nam połowy serwerowni
- Storm - stworzony przez Twittera framework do strumieniowego przetwarzania danych Pozwala developerowi skupić się na stworzeniu logiki przetwarzania zamiast interesować się jak ją uruchomić na wielu maszynach w naszej chmurze Tworzymy topologie czyli graf w którym każdy z węzłów wyliczaja częściowe metryki lub scalających wyniki poprzednich węzłów Każdy wierzchołek w grafie to niezależny komponent, a w praktyce po prostu kawałek kodu implementującego zadaną logikę Na koniec nie mamy już strumienia zdarzeń a zestaw metryk niosących konkretne informacje Przykładowo: mediana czasów renderowania strony liczba błędów javascript w rozbiciu na przeglądarki czas pobierania stron w zależności od operatora telekomunikacyjnego lub kraju i tak moglibyśmy dalej wymieniać... obecnie nasze topologie generują kilkaset tysięcy metryk jednocześnie Co dalej?
- Na koniec potrzebujemy jeszcze narzędzia do wizualizacji
- Wyniki trafiają do graphite Narzędzie pozwalające przechowywać metryki wraz z ich historycznymi wartościami oraz rysować je w postaci wykresów dodatkowo graphite pozwala wykonywać skomplikowane operacje analityczne na metrykach i zestawiać je sobą Skyline (?) co ważne klaster graphite na którym pracujemy służy również do przechowywania metryk pochodzących z innych źródeł niż RUM dzięki temu możemy zestawiać ze sobą pomiary dokonywane u użytkownika z innymi metrykami - np. wspomnianą wcześniej temperaturą dysków w macierzy
- W efekcie z kilkuset tysięcy metryk robi się kilka milionów Z tym już standardowa instalacja graphite nie jest w stanie sobie poradzić jako storage używamy cassandry która zapewnia nam oczekiwaną wydajność oraz replikację pomiędzy DC zamiast frontu używamy Grafany - rysuje o wiele ładniejsze wykresy i daje więcej możliwości wizualizacji
- dodatkowo rozszerzyliśmy możlwiości Grafany o tworzenie alarmów developer ustala własne progi na podstawie metryk po ich przekroczeniu świeci alarm W zasadzie tutaj moglibyśmy już zakończyć gdyż mamy kompleksowe rozwiązanie służące do monitoringu Ale może jesteśmy w stanie z tych danych wyciągnąć coś więcej?
- Nie każdy przekrój jesteśmy w stanie przewidzieć na bieżąco pojawiają się nowe pytania Zmodyfikujmy topologię? Zanim zmodyfikujemy pytanie przestaje już być aktualne Nie możemy z każdym nowym pytaniem wdrażać topologii Możliwości jest zbyt wiele żeby dla każdej rysować metrykę Potrzebujemy usługi która będzie szybko odpowiadać na niestandardowe pytania potrzebujemy OLAP Problem ze standardowym OLAP na relacyjnej bazie danych byłby dokładnie identyczny jak w przypadku metryk
- Druid.io Ostatnio zaczęliśmy eksperymentować z Druidem Przyjmuje stream z Kafki Biężące zdarzenia zapisywane są w tzw. real-time nodeach trzymają dane w RAM odpowiadają bardzo szybko starsze dane przenoszone są na bieżąco do historical node'ów oraz archiwizowane na HDFS w momencie gdy klient zadaje zapytanie druid sprawdza gdzie ma dane w razie potrzeby dociąga je z HDFS Scala i odpowiada Co istotne Druid wystawia łatwe w użyciu API Dzięki czemu możemy tworzyć kolejne usługi i narzędzia sterowane danymi Przykładowo w naszym CDN chcielibyśmy na podstawie danych real user wykrywać serwery które powodują wydłużone czasy i odpowiednio balansować ruch.
- Podsumujmy sobie co zbudowaliśmy Zbieramy dane w przeglądarkach użytkowników Zbieramy je na naszej warstwie brzegowej Za pomocą Kafki dostarczamy i scalamy w naszych DC do przetwarzania Następnie używamy Storma do agregacji i przygotowania metryk Które prezentujemy w Grafanie Oprócz tego używamy Druida do odpowiadania na niestandardowe pytania Na koniec zadajmy sobie jedno pytanie – jak RUM zmienił naszą codzienną pracę?
- Dzisiaj każde wdrożenie zmiany w serwisie odbywa się dla grupy / procenta użytkowników Dzięki temu developer jest w stanie sprawdzić swoją zmianę na stosunkowo małej próbce
- Dzięki osadzeniu skryptów monitorujących na każdej stronie naszych serwisów otrzymuje Natychmiastowy feedback jak jego wdrożenie wpłynęło na działanie u użytkownika Jak zmieniły się czasy Czy pojawiły się jakieś błędy
- Co jeszcze ważniejsze udostępnienie wszystkich tych narzędzi spowodowało zmianę sposobu myślenia w organizacji Nasi developerzy oraz biznes faktycznie zaczęli podejmować decyzje na podstawie danych zbieranych u użytkownika Co daje bardzo wymierne efekty…
- - W efekcie nasz największy portal informacyjny onet.pl po raz kolejny jest najszyciej działającym portalem w polskim internecie - Ten spadek na końcu to naprawdę nie jest przypadek
- Witajcie, nazywam się Jarosław Bloch, nazywam się Albert Łącki, bardzo nam miło że możemy z wami dzisiaj tu być. Podczas tej prezentacji opowiemy o tym jak w DreamLabie robimy Real User Monitoring dla milionów użytkowników [FIXME] Zacznijmy od tego czym się na co dzień zajmujemy i z jakimi wyzwaniami się mierzymy.