Jak porównać ruch na żywo Astrina z logami serwera
Porównywanie ruchu na żywo w Astrina z logami serwera brzmi prosto, dopóki nie pojawi się pierwsza rozbieżność. Jeden raport pokazuje 18 wizyt. Log wyświetla 24 żądania. Taka różnica zwykle ma swoje uzasadnienie, a najczęściej jest ono całkiem przyziemne: przekierowanie, bot, proxy albo znacznik czasu przesunięty o 60 sekund.
Nie chodzi o to, by za wszelką cenę doprowadzić oba wyniki do identyczności. Chodzi o to, by porównanie było na tyle rzetelne, żeby można mu ufać. Jeśli chcesz wiedzieć, jak porównać ruch na żywo Astrina z logami serwera, zacznij od zawężenia problemu, zanim zaczniesz spierać się z liczbami; właśnie dlatego porównanie statystyk Astrina z logami serwera powinno zaczynać się od jasnego zakresu i wspólnego punktu odniesienia.
1. Potwierdź zakres logów serwera, zanim zaczniesz porównanie
Najpierw wybierz dokładne pliki logów. Wiele zespołów miesza w jednym arkuszu ruch produkcyjny, testowy i podglądowy, a potem zastanawia się, dlaczego Astrina pokazuje jeden wzorzec, a serwer inny. Trzymaj się jednej witryny, jednego środowiska i jednego wycinka ruchu. Oznacza to zapisanie nazwy hosta, aplikacji i źródła logów prostym językiem, zanim zrobisz cokolwiek innego.
Jeśli Twoja konfiguracja serwera zapisuje kilka plików dziennie, zanotuj regułę rotacji. Jeśli masz osobne logi dla krawędzi CDN i serwera origin, na pierwszy przebieg wybierz jedną ścieżkę i trzymaj się jej konsekwentnie. Czysty zakres zmniejsza skalę reszty pracy. Chaotyczny zakres sprawia, że każda rozbieżność wygląda podejrzanie.
Praktyczny przykład: porównuj tylko www.example.com w produkcji, tylko żądania stron i tylko ostatnie 24 godziny. Nie dodawaj do tego żądań API, checków zdrowia ani adresów URL panelu administracyjnego. To zupełnie inne kategorie ruchu.
2. Wybierz jeden dokładny przedział czasu i ujednolić znaczniki czasu
Ruch na żywo w Astrina działa najlepiej, gdy przedział jest precyzyjny. Logi serwera działają najlepiej, gdy przedział jest precyzyjny. Użyj tej samej minuty rozpoczęcia i tej samej minuty zakończenia po obu stronach, a nie „około południa” czy „gdzieś po obiedzie”. Ucięcie na poziomie minut ma znaczenie, bo jedno żądanie na granicy może zmienić wynik.
Używaj jednej strefy czasowej dla obu źródeł. Jeśli Astrina pokazuje UTC, a logi serwera są w czasie lokalnym, porównanie nie powiedzie się, zanim jeszcze się zacznie. Przelicz znaczniki czasu w logach raz, a potem trzymaj się tego formatu przez całą analizę. Przesunięcie o 15 minut może stworzyć fałszywy pik. Przesunięcie o 1 godzinę może sprawić, że dane będą wyglądać na uszkodzone.
Jest jedna prosta zasada, która oszczędza czas: nigdy nie porównuj przesuwanego 5-minutowego okna Astrina z wyciągiem z logów obejmującym cały dzień kalendarzowy. Brzmi oczywiście. A jednak ludzie nadal to robią. Wybierz jedno okno, zapisz je i stosuj wszędzie.
3. Odfiltruj logi serwera do ludzkich żądań stron
Logi serwera zawierają wszystko i właśnie to jest problemem. Obrazy, arkusze CSS, paczki JavaScript, żądania favicon, prefetch i wejścia crawlerów stoją obok wizyt na stronach. Astrina zwykle liczy wizyty stron, więc log trzeba zawęzić do tego samego rodzaju żądań.
Najpierw odfiltruj zasoby. Potem usuń checki zdrowia, sondy uptime, endpointy administracyjne i narzędzia wewnętrzne. Jeśli load balancer odpytuje /health co minutę, te wpisy mogą szybko zafałszować sumy. Strona taka jak /pricing nie powinna być porównywana z 400 żądaniami zasobów i trzema pingami monitorującymi.
Warto też zwrócić uwagę na filtrowanie botów. Niektóre boty przez kilka sekund wyglądają jak ludzie, a niektóre przeglądarki wyglądają jak automaty przez swój user agent. Nie opieraj się na jednym sygnale. Jeśli możesz, użyj połączenia ścieżki żądania, user agenta i znanych zakresów wewnętrznych adresów IP. Jeśli log zawiera znacznik „bot” z WAF albo reverse proxy, zachowaj tę etykietę. Przyda się później.
4. Dopasuj pola Astrina do pól logów
Przed próbą dopasowania rekordów zrób prostą mapę pól. Astrina może pokazywać znacznik czasu, ścieżkę strony, referrer i identyfikator podobny do sesji. Log może pokazywać surową linię żądania, kod statusu, user agenta i adres IP. To nie są te same rzeczy i nie należy traktować ich tak, jakby były.
Zrób prostą tabelę z dwiema kolumnami, na papierze albo w arkuszu. Po lewej: pole Astrina. Po prawej: pole z logów. Znacznik czasu mapuje się na znacznik czasu, ścieżka na ścieżkę żądania, referrer na nagłówek referer, a user agent na ciąg user agenta. Identyfikatory podobne do sesji są trudniejsze, bo serwerowy log może w ogóle ich nie zawierać. To nie jest porażka. To po prostu ograniczenie.
| Pole Astrina | Najbliższe pole w logach | Uwagi |
|---|---|---|
| Znacznik czasu | Czas żądania | Najpierw przelicz do jednej strefy czasowej |
| Ścieżka strony | Ścieżka URL | Usuń parametry zapytania do grupowania |
| Referrer | Nagłówek referer | Może być brakujący albo skrócony |
| User agent | Ciąg user agenta | Przydatny do sprawdzania botów |
Nie oczekuj, że każde pole Astrina będzie miało równoważne pole w logach. Niektóre wartości są wnioskowane. Niektóre są modelowane. Niektórych po prostu nie ma w logu serwera. Właśnie dlatego mapa ma znaczenie: pokazuje, gdzie możliwe jest bezpośrednie porównanie, a gdzie tylko przybliżone.
5. Porównuj ruch według ścieżki URL, nie według surowej linii żądania
Surowe linie żądań są pełne szumu. Jedna wizyta na /docs może pojawić się jako /docs, /docs/ albo /docs?utm_source=newsletter. Jeśli porównasz te ciągi dosłownie, rozbijesz jedną stronę na trzy. Astrina może już normalizować część z tego. Twój log prawdopodobnie nie.
Używaj kanonicznych ścieżek. Przed porównaniem zliczeń zgrupuj wszystkie warianty pod tą samą ścieżką strony. Usuń parametry zapytania, jeśli nie są częścią tożsamości strony. Zwijaj końcowe ukośniki tam, gdzie witryna traktuje je jako tę samą stronę. Jeśli w grę wchodzą przekierowania, licz ostateczny adres docelowy, a nie pierwszy etap.
Ten krok często ujawnia niespodziankę. Strona z 50 wizytami w Astrina może pokazać 63 wpisy w logach, bo 13 żądań najpierw trafiło w wersję niekanoniczną, a potem zostało przekierowanych. To nie jest błąd w ruchu. To problem ze ścieżką. Popraw regułę grupowania, zanim zmienisz interpretację.
6. Sprawdź rozbieżności spowodowane cache’em, proxy lub CDN
Warstwy pośrednie zmieniają to, co dociera do serwera origin. CDN może odpowiedzieć na żądanie, zanim origin w ogóle je zobaczy. Proxy może przepisać nagłówki. Trafienie do cache’a może dostarczyć stronę użytkownikowi, nie zostawiając po drodze żadnej odpowiadającej linii w logu origin. To oznacza, że Astrina może zobaczyć wizytę, podczas gdy log serwera pozostaje cichy.
Odwrotna sytuacja też jest możliwa. Log origin może zapisać żądanie, którego Astrina nigdy nie policzy, bo przeglądarka nie dokończyła ładowania strony, skrypt został zablokowany albo żądanie wysłano, zanim kod śledzący zdążył się uruchomić. Szybki test na stronie może to dobrze pokazać. Otwórz stronę w przeglądarce, sprawdź zakładkę sieci i zobacz, czy żądanie śledzące wysyła się, zanim strona skończy się ładować.
Jeśli korzystasz z CDN, sprawdź, czy źródłem logów jest edge czy origin. To różne rekordy. Odpowiedź 304, zcache’owana odpowiedź HTML albo przestarzały obiekt na edge’u mogą powodować fałszywe różnice. Właśnie tutaj krótka notatka w arkuszu porównawczym oszczędza godzinę później.
Dla zespołów, które dopiero konfigurują tracker, ważna jest też ścieżka instalacji. Weryfikacja konfiguracji jest prostsza, jeśli zastosujesz ten sam sposób wdrożenia, którego używasz w produkcji, dlatego wiele zespołów trzyma przewodnik konfiguracji w swoim runbooku obok skryptu eksportu logów.
7. Użyj krótkiego dziennika rozbieżności, by sklasyfikować każdą lukę
Nie zostawiaj rozbieżności jako anonimowych czerwonych pól. Prowadź dziennik rozbieżności, z jedną linią na każdą lukę. Nadaj każdej linii kategorię. Na początek zwykle wystarcza pięć kategorii: szum botów, brak pokrycia logów, opóźnione przetwarzanie, duplikaty żądań i problem z normalizacją ścieżki.
Prosty format wygląda tak: ścieżka strony, liczba w Astrina, liczba w logach, wielkość różnicy, kategoria, uwaga. Ta uwaga powinna wskazywać jedną konkretną przyczynę, a nie odczucie. „CDN podał zcache’owany HTML” jest pomocne. „Wygląda dziwnie” już nie. Jeśli luka powtarza się na trzech stronach, to wskazówka. Jeśli pojawia się raz, to też wskazówka, tylko mniejsza.
Jeden zespół może odkryć, że luka 12 żądań wynika z opóźnionego wysyłania logów. Inny może zauważyć, że rozszerzenie przeglądarki blokuje skrypt śledzący na urządzeniach wewnętrznych. Trzeci może stwierdzić, że serwer zapisuje zduplikowane linie przy ponowieniu żądania. Kategorie chronią przed traktowaniem każdej rozbieżności jak tego samego rodzaju błędu.
Jeśli chcesz głębiej spojrzeć na ten proces od strony operacyjnej, astrina dla wewnętrznych zespołów produktowych śledzących może być przydatnym uzupełnieniem, zwłaszcza gdy rozbieżność w ruchu okazuje się powiązana z wdrożeniem.
8. Powtórz porównanie na małej próbce, zanim je rozszerzysz
Zacznij od jednej strony albo jednego dnia. Nie od dziesięciu stron. Nie od całego miesiąca. Jedna próbka zmusza do precyzyjnego opisania reguł, co jest dobre. Jeśli próbka obejmuje tylko /pricing, możesz ręcznie sprawdzić każdą rozbieżność i ocenić, czy metoda działa.
Najpierw szukaj stabilności, dopiero potem szerokości. Jeśli ten sam filtr, reguła ścieżki i przedział czasu dają dwa razy ten sam wynik, rozszerz na drugą stronę. Jeśli liczby skaczą po dodaniu kolejnego dnia, zatrzymaj się i sprawdź, czy w międzyczasie nie było wdrożenia, zmiany cache’a albo rotacji logów. Małą próbkę łatwiej poprawić niż dużą.
Jest tu przydatna dyscyplina: zmieniaj tylko jedną zmienną naraz. Przejdź z jednej strony na trzy strony albo z jednego dnia na dwa dni, ale nie rób obu rzeczy jednocześnie. W przeciwnym razie nie będziesz wiedzieć, która zmiana zepsuła dopasowanie. Brzmi powoli. W praktyce jest szybciej niż cofanie się przez 40 wierszy błędnych założeń.
Zespoły, które migrują z innego narzędzia analitycznego, często widzą ten sam wzorzec podczas przejścia. Jeśli to Twój przypadek, jak przenieść się z Plausible to praktyczne źródło, które warto mieć otwarte podczas weryfikacji pierwszej próbki względem logów.
Co sprawdzić, gdy liczby nadal się nie zgadzają
Jeśli po ośmiu krokach powyżej porównanie nadal wygląda źle, sprawdź po kolei trzy rzeczy: źródło logów, regułę ścieżki i przedział czasu. Nie przeskakuj od razu do skryptu śledzącego. Zaskakująco często „błędy śledzenia” są w rzeczywistości błędami w eksporcie logów. Inną częstą przyczyną jest przeoczony redirect z /page na /page/.
Sprawdź też, czy sesja przeglądarki kończy się, zanim żądanie śledzące zdąży się wykonać. Połączenia mobilne są bardziej niestabilne niż stacjonarne. Strona może załadować się wizualnie, a wywołanie analityczne zostanie anulowane. To daje Astrina mniej wizyt niż log serwera. Odwrotnie też bywa, gdy przeglądarka ponawia żądanie, a serwer liczy oba podejścia.
Jeszcze jedna rzecz: jeśli Twoja strona ma stronę lub tryb konserwacyjny, traktuj taki ruch osobno. Zdarzenie konserwacyjne zmienia zarówno zachowanie użytkowników, jak i kształt logów. Jeśli potrzebujesz pomocnego odniesienia do takiej sytuacji, co zrobić, gdy Astrina uptime może pomóc ułożyć incydent w kontekst, zanim porównasz go z logami.
Najlepsze porównania są małe, udokumentowane i powtarzalne. Czysty zakres, jedno okno czasowe, odfiltrowane żądania stron i kanoniczne ścieżki zwykle wyjaśniają większość różnicy. To, co zostaje, to miejsce na naprawdę użyteczną analizę.
