Niektóre problemy dają o sobie znać głośno. Inni kryją się w luce między „działa na moim komputerze” a „działa u każdego”. Ten jeden mocno tkwił w tej luce.

Objaw wydawał się prosty: niektórzy użytkownicy nie mogli załadować naszych formularzy obsługiwanych przez HubSpot. Powód był dość uzasadniony: ustawienia prywatności przeglądarki i blokady śledzenia interweniowały, nie pozwalając na przepuszczenie czegokolwiek, co przypominało tracker. Jednak w chwili, gdy próbowaliśmy zmierzyć problem, natrafiliśmy na przeszkodę, która sprawiła, że pozornie szybkie rozwiązanie stało się czymś o wiele ciekawszym.

Narzędzie, po które zazwyczaj sięgamy, aby wykryć takie błędy, czyli monitorowanie rzeczywistych użytkowników, było blokowane przez dokładnie te same zabezpieczenia, które powodowały awarie formularzy. Nasz New Relic RUM wyglądał jak tracker, bo, cóż, nim jest . Próbowaliśmy w zasadzie zainstalować czujnik dymu w pomieszczeniu, w którym dym powodował uruchomienie urządzenia wyłączającego czujniki dymu.

W tym artykule pokażemy, jak obejść ten paradoks: ustawiliśmy serwer proxy New Relic na naszą własną domenę pierwszą, aby nie wyglądało to na śledzenie przez osobę trzecią, poradziliśmy sobie ze komplikacjami związanymi z subdomenami, zadbaliśmy o czystość danych telemetrycznych i na koniec stworzyliśmy niezawodne wykrywanie awarii HubSpot; nawet tych cichych, w których nic się nie ładuje. Po drodze omówimy okablowanie CDN i dyspozytora, testowanie w środowisku szybkiego rozwoju, wdrażanie za pośrednictwem Cloud Manager oraz okres testowania, który zmienia sprytne obejście problemu w wiarygodną metrykę.

Ważna uwaga od New Relic:

Korzystając z metody proxy, należy upewnić się, że masz do tego prawo na mocy zobowiązań umownych, regulacyjnych lub innych zobowiązań prawnych, które możesz mieć wobec użytkowników końcowych i/lub osób odwiedzających witrynę.

Tworzenie New Relic w pierwszej kolejności

Zamiast ładować New Relic bezpośrednio ze standardowych punktów końcowych, rozwiązaniem było przekierowanie wszystkiego przez naszą własną domenę. Powoduje to przeniesienie żądań z podmiotów trzecich do podmiotów pierwszych, co pozwala ominąć większość zabezpieczeń przed śledzeniem.

Wprowadzono dwa punkty końcowe:

• /nr/agent/ → obsługuje agenta przeglądarki New Relic
• /nr/data/ → odbiera żądania dotyczące sygnału radiowego (telemetrii)

Zakodowanie wartości proxy na stałe

Najprostszym sposobem konfiguracji serwera proxy pierwszego typu w New Relic jest ustawienie ścieżek proxy bezpośrednio w NREUM.init jako statycznych ciągów znaków. Wskazujesz assets na adres URL, który obsługuje fragmenty skryptu agenta New Relic, i beacon na adres URL, który odbiera dane telemetryczne; oba są kierowane przez Twoją własną domenę, a nie przez sieć CDN New Relic.

proxy: {
  assets: 'www.arborydigital.com/nr/agent',
  beacon: 'www.arborydigital.com/nr/data'
}

Łatwo o tym pomyśleć. Ścieżki są widoczne na pierwszy rzut oka, nie wymagają żadnej logiki czasu wykonania i są ustalane przed inicjalizacją agenta. Nie ma więc obaw o to, czy konfiguracja zostanie dostarczona na czas. Jeśli na Twoim serwerze te dwie trasy są skonfigurowane i prawidłowo przekierowują do New Relic, wszystko będzie działać. W przypadku witryn działających w pojedynczej domenie bez ruchu w subdomenach, często jest to wszystko, czego potrzebujesz.

Proxy w subdomenach

Jeśli Twoja witryna korzysta z subdomen, takich jak blog.arborydigital.com, pojedyncza, zakodowana na stałe ścieżka proxy nie wystarczy. Każda subdomena działa z własnego źródła, a reguły bezpieczeństwa przeglądarki oznaczają, że żądanie z blog.arborydigital.com do ścieżki proxy hostowanej w www.arborydigital.com jest technicznie żądaniem międzydomenowym. Choć może to działać, to jednak niweczy część idei serwerów proxy pierwszego typu, która polega na wysyłaniu danych telemetrycznych przez to samo źródło, któremu przeglądarka już ufa.

Aby rozwiązać ten problem, konfigurację serwera proxy można ustawić dynamicznie w czasie wykonywania. Zamiast wskazywać na stałą domenę, skrypt sprawdza window.location.hostname , aby ustalić, na którym źródle aktualnie działa strona. Jeśli nazwa hosta odpowiada domenie głównej lub którejkolwiek z jej subdomen, punkty końcowe serwera proxy są tworzone przy użyciu window.location.origin — co oznacza, że blog.arborydigital.com będzie kierować swój ruch New Relic przez blog.arborydigital.com/nr-assets/ i blog.arborydigital.com/nr-beacon, podczas gdy www.arborydigital.com będzie używać własnych równoważnych ścieżek.

Podejście to wymaga, aby każda subdomena miała odpowiednie trasy proxy skonfigurowane na poziomie serwera lub CDN. Konfiguracja agenta New Relic, obejmująca pola beacon i errorBeacon w NREUM.info, musi również zostać zaktualizowana tak, aby odzwierciedlała bieżącą nazwę hosta, dzięki czemu agent będzie wiedział, gdzie raportować dane.

ajax.deny_list

Agent przeglądarki New Relic jest skonfigurowany tak, aby kierować całą telemetrię przez serwer proxy pierwszej strony blog.arborydigital.com/nr/data a nie przez własne serwery New Relic bam.nr-data.net. Pozwala to uniknąć blokad, które celują w znane domeny NR.

Efektem ubocznym tego jest to, że agent NR monitoruje wszystkie wychodzące żądania XHR/fetch na stronie, aby przechwytywać je jako zdarzenia AJAX; dotyczy to także własnych wywołań sygnału nawigacyjnego kierowanych do blog.arborydigital.com/nr/data. Bez listy odrzuconych, NR rejestrowałby własne dane telemetryczne POST jako zdarzenia AJAX, które następnie byłyby wysyłane jako dodatkowe dane telemetryczne, zanieczyszczając dane AJAX wewnętrznym ruchem NR.

Aby naprawić ten błąd i uniknąć sytuacji, w której szybkość transmisji danych będzie przypominać tę z Akiry, możemy zablokować te wywołania beaconów, korzystając z wbudowanego symbolu wieloznacznego. Wyglądałoby to tak: blog.arborydigital.com/nr/data/* . Po zaimplementowaniu tej opcji program New Relic będzie informowany, aby nie tworzył wpisu ajax gdy dane przeglądarki zostaną pomyślnie przechwycone. Wszystkie informacje wewnątrz POST zostają zachowane i nie będzie już zbędnego wpisu ajax.

Używanie parametru zapytania jako flagi funkcji

Ustanowienie bramy dla serwera proxy za ?proxy=yes umożliwia testowanie zachowania w środowisku produkcyjnym bez wpływu na innych użytkowników. Jeśli w adresie URL nie będzie tego parametru, blokada zostanie całkowicie pominięta i w tym przypadku New Relic nie zostanie uruchomiony. Otwierasz kartę z dołączonym parametrem, potwierdzasz w DevTools, że żądania są kierowane przez Twoją własną domenę, a gdy wszystko się sprawdzi, usuwasz warunek ze skryptu. Następnie rozpoczyna się sprawdzanie nazwy hosta i serwer proxy jest automatycznie aktywowany dla całego ruchu.

Wdrażanie nowego agenta reliktów

Fragment kodu JavaScript możesz znaleźć w następujący sposób:

1. Zaloguj się do New Relic One (one.newrelic.com)
2. Przejdź do Przeglądarka → Dodaj dane → Monitorowanie przeglądarki
3. Wybierz aplikację (ID aplikacji) lub utwórz nową
4. Wybierz metodę wdrażania Kopiuj/Wklej za pomocą ładowarki SPA
5. Skopiuj cały wygenerowany fragment kodu <script>

Dodając skrypt RUM do swojego repozytorium, upewnij się, że znajduje się on w osobnym pliku newrelic.js , abyśmy mogli go wywołać w jego obrębie. head.html

• Uwaga: <script src="/scripts/newrelic.js"></script> musi być pierwszym zainicjowanym skryptem, bezpośrednio po znacznikach meta .

Po wykonaniu tej czynności należy dodać do tego ciągu konkretne ustawienia serwera proxy. W bloku NREUM.init wygenerowanego fragmentu kodu dodaj konfigurację serwera proxy:

proxy: {
  assets: 'www.arborydigital.com/nr/agent',
  beacon: 'www.arborydigital.com/nr/data'
}

Podłączanie serwera proxy (warstwa EDS/CDN)

Sam serwer proxy znajduje się na warstwie CDN. Cel jest prosty: przekierowywanie przychodzących żądań /nr/* do prawdziwych punktów końcowych New Relic.

Selektor źródła musi wykluczać /nr/agent/* i /nr/data/* , aby żądania te nie były kierowane do źródła Edge Delivery Services. Zamiast tego trafiają do domyślnego źródła publikacji AEM, w którym wykonywane są reguły Apache ProxyPass. Wewnątrz cdn.yaml wyglądałoby to tak:

originSelectors:
  rules:
    - name: arbory-da
      when:
        allOf:
          - reqProperty: path
            like: /*
          # ...existing exclusions...
          - reqProperty: path
            doesNotMatch: /nr/agent/*
          - reqProperty: path
            doesNotMatch: /nr/data/*
      action:
        type: selectOrigin
        originName: arbory-da

Będziesz musiał również edytować plik VirtualHost (.vhost):

# New Relic Browser Agent Proxy
SSLProxyEngine on

# Proxy New Relic agent JS chunks (lazy-loaded scripts)
<Location "/nr/agent/">
    ProxyPass "https://js-agent.newrelic.com/"
    ProxyPassReverse "https://js-agent.newrelic.com/"
    RewriteEngine Off
</Location>

# Proxy New Relic beacon/telemetry data
<Location "/nr/data/">
    ProxyPass "https://bam.nr-data.net/"
    ProxyPassReverse "https://bam.nr-data.net/"
    RewriteEngine Off
</Location>

Najważniejsze szczegóły:

• SSLProxyEngine on wymagane, ponieważ cele nadrzędne są oparte na protokole HTTPS
• RewriteEngine Off zapobiega zakłócaniu ścieżek proxy przez domyślne reguły przepisywania AEM

Wykrywanie awarii HubSpot (nawet gdy nic się nie ładuje)

Po odblokowaniu New Relic pojawia się kolejny problem: awarie HubSpot nie zawsze powodują oczywiste błędy, zwłaszcza gdy skrypt w ogóle się nie ładuje.

Aby sobie z tym poradzić, dodano dwie ścieżki wykrywania:

1. Błąd ładowania skryptu

Wykryj, kiedy skrypt HubSpot nie ładuje się całkowicie:

script.onerror = () => {
  reportError('HubSpot script failed to load');
};

2. Błąd w czasie wykonywania

Wyłap błędy po załadowaniu skryptu:

window.addEventListener('error', (e) => {
  if (e.filename && e.filename.includes('hsforms')) {
    reportError('HubSpot runtime error');
  }
});

Oba dane trafiają do tej samej funkcji raportowania:

function reportError(errorMsg) {
  console.error(errorMsg);
  if (window.newrelic) {
    window.newrelic.noticeError(new Error(errorMsg));
  }
}

Sprawdzanie, czy to faktycznie działa

Gdy wszystko jest już podłączone, walidacja jest dość prosta, ale nadal istotna. Testowanie powinno się skupić na przeglądarkach z włączoną ścisłą ochroną przed śledzeniem/rozszerzeniami. W takich przeglądarkach formularze HubSpot powinny się nie ładować, w konsoli powinny pojawiać się błędy, a te same błędy powinny pojawiać się w New Relic. W DevTools sprawdź, czy agent jest ładowany z /nr/agent/ i czy sygnały nawigacyjne są wysyłane do /nr/data/, bez żadnych żądań kierowanych do domen zewnętrznych, takich jak bam.nr-data.net. W New Relic sprawdź, czy na pulpicie pojawiają się błędy, zdarzenia odpowiadają wyzwolonym awariom i czy sesje są rejestrowane. Jeśli nadal brakuje sesji, serwer proxy prawdopodobnie nie jest poprawnie skonfigurowany

Testowanie przy użyciu szybkiego środowiska programistycznego (RDE)

Jeśli jesteś jednym z naszych stałych czytelników, pamiętasz zapewne mój artykuł o tym, jak testować zmiany w konfiguracji CDN za pomocą środowiska szybkiego programowania (RDE). Testując ten nowy RUMM użyłem dokładnie tego!

W przypadku stosowania najlepszych praktyk rozwój będzie odbywał się na gałęzi. Aby mieć pewność, że zmiany są wprowadzane w gałęzi, a nie w gałęzi głównej, należy wprowadzić dodatkowe zmiany w cdn.yaml :

    origins:
     # ...existing code...
      - name: arbory-da
        domain: (BRANCH_NAME)--(rest of domain).aem.live
        forwardHost: false

Gdy będziesz gotowy do wdrożenia zmian, będziesz potrzebować dwóch głównych poleceń:

aio aem:rde:install -t env-config ./config :to spowoduje przesłanie zawartości Twojego /config i wykluczeń, które wprowadziliśmy wcześniej.

aio aem:rde:install -t dispatcher-config ./dispatcher/src :to spowoduje przesłanie zawartości Twojego /src—mianowicie zmian w konfiguracji Twojego dyspozytora .vhost .

Ponieważ RDE działa w innej domenie niż pozostałe środowiska, musisz określić nowy adres URL, przez który będzie przekazywany serwer proxy. W przeciwnym wypadku będzie ona postrzegana jako domena osoby trzeciej:

proxy: { 
   assets: 'your-rde-domain.aem.live/nr/agent', 
   beacon: 'your-rde-domain.aem.live/nr/data' 
}

Wdrażanie Cloud Manager Pipeline (rozwój + produkcja)

Wdrożenie tego za pośrednictwem Adobe Cloud Manager wymaga nieco większej koordynacji niż typowa zmiana kodu. Zachowanie serwera proxy zależy od wielu warstw (CDN, dyspozytora i przeglądarki) i wszystkie one muszą być zsynchronizowane w ramach tego samego wdrożenia.

Jak działa wdrożenie

Wykonanie potoku spowoduje:

• Zbuduj i zweryfikuj aplikację
• Wdróż konfigurację dyspozytora (w tym .vhost, filtry i reguły proxy)
• Wdrażanie konfiguracji CDN (cdn.yaml, w tym selektory pochodzenia)
• Unieważnij pamięć podręczną i promuj zmiany w całym środowisku

W przypadku tej implementacji zmiany w dyspozytorze i CDN są ściśle powiązane. Serwer proxy nie będzie działał prawidłowo, jeśli oba elementy nie będą obecne i spójne.

Wymagane zmiany (należy wdrożyć wspólnie)

Następujące aktualizacje muszą zostać uwzględnione w tym samym przebiegu potoku:

• CDN (cdn.yaml)

  • Wyklucz /nr/agent/* i /nr/data/* z routingu dostarczania krawędziowego

• Dyspozytor (.vhost)

  • ProxyPass / ProxyPassReverse reguły dla punktów końcowych New Relic
  • SSLProxyEngine on
  • Wyłącz przepisywanie ścieżek proxy

• Filtry dyspozytorskie

  • Wyraźna reguła zezwalająca na /nr/*

Jeśli którykolwiek z nich zaginie lub nie będzie zsynchronizowany, żądania zostaną przekierowane błędnie, zablokowane lub przekierowane do zewnętrznych punktów końcowych.

Okres wypalania

Teraz, gdy serwer proxy został skonfigurowany i wdrożony, trzeba dać mu czas na wypróbowanie, aby mieć pewność, że wszystko działa zgodnie z oczekiwaniami. Ponieważ awarie zależą od rzeczywistych warunków użytkowania, takich jak ustawienia prywatności, rozszerzenia i zachowanie sieci, uzyskanie pełnego obrazu zajmie trochę czasu.

Gdy poświęcisz trochę czasu i sprawdzisz, czy dane są prawidłowo pobierane, następnym krokiem będzie ich przejrzenie; sprawdzenie wskaźników błędów w odniesieniu do oczekiwanego ruchu, zapewnienie pokrycia w różnych środowiskach i wyeliminowanie wszelkich luk (pominiętych zdarzeń, niespójnych domen lub blokad przypadków skrajnych). Dzięki temu możesz zacząć traktować to jako wiarygodny wskaźnik, trend w czasie i używać go do mierzenia rzeczywistego wpływu użytkowników, a nie tylko anegdotycznych raportów.

Ostatnie myśli

To, co zaczęło się jako „wystarczy dodać trochę monitorowania”, przerodziło się w wycieczkę po modelach prywatności przeglądarek, serwerach proxy pierwszych stron, routingu CDN i subtelnej sztuce mierzenia czegoś, co z założenia opiera się mierzeniu.

Warto zapamiętać tę najważniejszą myśl: jeśli zarówno obiekt, który próbujesz obserwować, jak i obiekt, za pomocą którego go obserwujesz, są traktowane przez przeglądarkę jako niepożądane, nie możesz monitorować sytuacji przy użyciu gotowych narzędzi. Musisz zmienić sposób, w jaki przeglądarka odbiera Twoje dane telemetryczne. Uruchomienie serwera New Relic za pośrednictwem naszej domeny pierwszej strony spowodowało dokładnie to — przekierowało żądania z domeny trzeciej do domeny pierwszej strony, ominęło blokady i dało nam prawdziwy wgląd w awarie, które wcześniej były niewidoczne.

Ale pełnomocnik był tylko połową sukcesu. Wykrywanie awarii HubSpot, zwłaszcza tych cichych, w których skrypt nigdy się nie ładuje, wymagało celowego zarządzania zarówno błędami ładowania, jak i błędami czasu wykonania, które wszystkie były kierowane do jednej ścieżki raportowania. I nic z tego nie ma znaczenia, dopóki dane nie zostaną potwierdzone w okresie testowym, w którym rzeczywiste warunki użytkowania zastąpią założenia dowodami.

Nagrodą jest umiejętność wymieniania anegdot na liczby. Zamiast stwierdzenia „niektórzy użytkownicy twierdzą, że formularz się nie ładuje” mamy teraz mierzalny, trendowy sygnał, który określa rzeczywisty wpływ użytkownika. Czasami najcenniejsze rozwiązanie to nie to, które całkowicie rozwiązuje problem, ale to, które wreszcie pozwala nam dostrzec go wyraźnie. I od tego momentu możesz zacząć go udoskonalać.

Rozwiązywanie problemów

O autorze

Podoba Ci się to co słyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami

Więcej artykułów, które mogą Ci się spodobać