Wśród inżynierów SRE/DevOps nikogo nie zaskoczy, że pewnego dnia pojawia się klient (lub system monitorowania) i informuje, że „wszystko zniknęło”: strona nie działa, płatności nie przechodzą, życie — marność… Choć bardzo chcielibyśmy pomóc w takiej sytuacji, zrobienie tego bez prostego i zrozumiałego narzędzia bywa bardzo trudne. Często problem ukryty jest w kodzie samej aplikacji — wystarczy go zlokalizować.
W smutku i w radości…
Tak się złożyło, że od dłuższego czasu bardzo lubimy New Relic. Był i nadal jest doskonałym narzędziem do monitorowania wydajności aplikacji, a także umożliwia instrumentowanie architektury mikroserwisowej (za pomocą swojego agenta) i wiele, wiele innych rzeczy. I wszystko mogłoby być wspaniałe, gdyby nie zmiany w polityce cenowej usługi: jego koszt wzrosła ponad 3 razy. Dodatkowo, od zeszłego roku do uzyskania konta próbnego konieczna jest rozmowa z menedżerem, co utrudnia prezentację produktu potencjalnemu klientowi.
Typowa sytuacja: New Relic nie jest potrzebny „na stałe”, przypominają o nim tylko w momencie, gdy pojawiają się problemy. Ale płacić trzeba regularnie (140 USD za serwer miesięcznie), a w automatycznie skalującej się chmurze kwoty stają się znaczne. Chociaż istnieje możliwość „Pay-As-You-Go”, do włączenia New Relic wymagany jest restart aplikacji, co może prowadzić do utraty tej problematycznej sytuacji, dla której wszystko się zaczynało. Niedawno New Relic wprowadził nowy plan taryfowy — , który na pierwszy rzut oka wygląda na rozsądna alternatywę dla Professional… ale przy bliższym przyjrzeniu się okazało się, że brakuje w nim części ważnych funkcji (w szczególności brakuje Kluczowe transakcje, Śledzenie aplikacji między sobą, Śledzenie rozproszone).
W wyniku tego zaczęliśmy myśleć o poszukiwaniu tańszej alternatywy, a nasz wybór padł na dwa serwisy: Datadog i Atatus. Dlaczego właśnie na nie?
O konkurentach
Zaraz dodam, że na rynku dostępne są także inne rozwiązania. Rozważaliśmy nawet opcje open source, ale nie wszyscy klienci mają wolne zasoby do umieszczania rozwiązań z kategorii self-hosted… — poza tym wymagają dodatkowej obsługi. Wybrane przez nas parę okazała się najbardziej zbliżona do naszych potrzeb:
- Wbudowane i rozwinięte wsparcie aplikacji PHP (nasze środowisko klienckie jest bardzo różnorodne, ale to jest wyraźny lider w kontekście poszukiwania alternatywy dla New Relic);
- Dostępna cena (poniżej 100 USD miesięcznie za hosting);
- Automatyczna instrumentacja;
- Integracja z Kubernetes;
- Podobieństwo do interfejsu New Relic — wyraźny plus (ponieważ nasi inżynierowie są do niego przyzwyczajeni).
Dlatego na etapie wstępnej selekcji odrzuciliśmy kilka innych popularnych rozwiązań, a w szczególności:
- Tideways, AppDynamics i Dynatrace — ze względu na koszt;
- Stackify — zablokowany w Rosji i pokazuje zbyt mało danych.
Dalszy artykuł jest zbudowany w ten sposób, że najpierw zostaną krótko przedstawione rozważane rozwiązania, a następnie opowiem o naszym typowym interakcjach z New Relic oraz doświadczeniach/wrażeniach z realizacji podobnych operacji w innych serwisach.
Prezentacja wybranych konkurentów
O , pewnie każdy słyszał? Usługa ta rozpoczęła swoją działalność ponad 10 lat temu, w 2008 roku. Aktywnie korzystamy z niej od 2012 roku i nie mieliśmy problemów z integracją naprawdę dużej liczby aplikacji w językach PHP, Ruby i Python, a także mieliśmy doświadczenie w integracji z C# i Go. Twórcy usługi mają rozwiązania do monitorowania aplikacji, infrastruktury, śledzenia mikroserwisowych infrastruktur, stworzyli wygodne aplikacje dla urządzeń użytkowników i wiele więcej.
Jednak agent New Relic działa na własnych protokołach, nie ma wsparcia dla OpenTracing. Aby uzyskać rozszerzoną instrumentację, należy wprowadzać poprawki specjalnie dla New Relic. W końcu wsparcie dla Kubernetes ma obecnie status eksperymentalny.
Rozpoczął swoją działalność w 2010 roku wygląda znacznie ciekawiej niż New Relic, zwłaszcza w kontekście użycia w środowiskach Kubernetes. W szczególności wspiera integrację z NGINX Ingress, zbieranie logów, protokoły statsd i OpenTracing, co pozwala na śledzenie żądań użytkowników od momentu ich połączenia do zakończenia pracy oraz na odnajdywanie logów związanych z tym żądaniem (zarówno po stronie serwera WWW, jak i po stronie konsumentów).
Podczas korzystania z Datadog napotkaliśmy na to, że czasami błędnie budował mapę mikroserwisów oraz miał pewne techniczne niedociągnięcia. Na przykład, błędnie określał typ usługi (przekładał Django na usługę cache'owania) i wywoływał błędy 500 w aplikacji PHP, wykorzystującej popularną bibliotekę Predis.
— najnowsze narzędzie; usługa uruchomiona w 2014 roku. Jego budżet marketingowy wyraźnie ustępuje wymienionym konkurentom, a wzmianki pojawiają się znacznie rzadziej. Niemniej jednak, samo narzędzie jest bardzo podobne do New Relic, nie tylko pod względem funkcji (APM, monitorowanie przeglądarki itp.), ale także w wyglądzie.
Istotną wadą jest wsparcie tylko dla Node.js i PHP. Z drugiej strony, jest ono zrealizowane znacznie lepiej niż w Datadog. W przeciwieństwie do tego, Atatus nie wymaga od aplikacji poprawek i dodawania dodatkowych etykiet w kodzie.
Jak pracujemy z New Relic
Teraz zrozumiemy, jak zazwyczaj korzystamy z New Relic. Załóżmy, że mamy problem do rozwiązania:
Na wykresie łatwo zauważyć skok — przeanalizujemy go. W New Relic dla aplikacji webowej od razu wybrane są transakcje webowe, na wykresie wydajności wskazane są wszystkie komponenty, dostępne są panele error-rate, request-rate… Co najważniejsze — bezpośrednio z tych paneli można przechodzić między różnymi częściami aplikacji (na przykład kliknięcie na MySQL przeniesie nas do sekcji baz danych).
Ponieważ w omawianym przykładzie widzimy skok aktywności PHP, kliknijmy na ten wykres i automatycznie przejdźmy do Transakcje:
Lista transakcji, które w zasadzie są kontrolerami z modelu MVC, już posortowana według Najbardziej czasochłonnych, co jest bardzo wygodne: od razu widzimy, czym zajmuje się aplikacja. Tutaj znajdują się również przykłady długich zapytań, które automatycznie zbiera New Relic. Przełączając sortowanie, w łatwy sposób można znaleźć:
- najbardziej obciążony kontroler aplikacji;
- najczęściej wywoływany kontroler;
- najwolniejszy z kontrolerów.
Dodatkowo, można rozwinąć każdą transakcję i zobaczyć, czym zajmowała się aplikacja w momencie wykonania kodu:
W końcu w aplikacji zapisywane są przykłady tras długich zapytań (które trwają dłużej niż 2 sekundy). Oto panel dla długiej transakcji:
Widać, że dużo czasu zajmują dwie metody, a wraz z tym pokazane jest również czas, kiedy zapytanie zostało wykonane, jego URI i domena. Bardzo często pomaga to znaleźć zapytanie w logach. Przechodząc do Szczegóły tras, można zobaczyć, skąd te metody są wywoływane:
A w Zapytania do bazy danych — ocenić zapytania do baz danych, które były wykonywane w momencie pracy aplikacji:
Uzbrojeni w tę wiedzę, możemy ocenić przyczynę spowolnienia aplikacji i wspólnie z deweloperem wypracować strategię rozwiązania problemu. W rzeczywistości New Relic nie zawsze daje wyraźny obraz, jednak pomaga wybrać kierunek śledztwa:
- długi
PDO::Constructdoprowadził nas do dziwnego działania pgpoll; - niestabilność w czasie
Memcache::Getwskazała na nieprawidłową konfigurację maszyny wirtualnej; - podejrzanie wydłużony czas przetwarzania szablonu doprowadził do zagnieżdżonej pętli sprawdzającej obecność 500 avatarów w magazynie obiektów;
- i tak dalej…
Czasami zdarza się, że zamiast wykonywania kodu na głównym ekranie rośnie coś związanego z zewnętrznym magazynem danych — nieważne, co to będzie: Redis czy PostgreSQL — wszystkie one ukrywają się w zakładce Bazy Danych.
Można wybrać konkretną bazę do analizy i przeprowadzić sortowanie zapytań — podobnie jak robi się to w Transactions. A przechodząc do zakładki zapytania, można zobaczyć, jak często to zapytanie występuje w każdym z kontrolerów aplikacji oraz ocenić, jak często jest wywoływane. To bardzo wygodne:
Podobne dane zawiera zakładka External Services, która ukrywa w sobie zapytania do zewnętrznych usług HTTP, takich jak odwołania do magazynu obiektów, wysyłanie zdarzeń do sentry lub podobne. Pod względem zawartości zakładka jest całkowicie analogiczna do Databases:
Konkurenci: możliwości i wrażenia
Teraz najciekawsze — porównajmy możliwości New Relic z tym, co oferują konkurenci. Niestety, nie udało nam się przetestować wszystkich trzech narzędzi na jednej wersji działającej aplikacji produkcyjnej. Niemniej jednak, staraliśmy się porównać maksymalnie identyczne sytuacje/configuracje.
1. Datadog
Datadog wita nas panelem ze ścianą usług:
Próbuje podzielić aplikacje na komponenty/mikroserwisy, dlatego w przedstawionym przykładzie aplikacji Django zobaczymy 2 połączenia do PostgreSQL (defaultdb i postgres), a także Celery, Redis. Praca z Datadogiem wymaga od Ciebie minimalnej wiedzy na temat zasad MVC: musisz rozumieć, gdzie w ogóle przychodzą zapytania użytkowników. Zwykle w tym pomaga mapa usług:
Swoją drogą, coś podobnego jest też w New Relic:
… a ich mapa, moim zdaniem, jest prostsza i bardziej przejrzysta: pokazuje nie komponenty jednej aplikacji (co uczyniłoby ją zbyt szczegółową, jak w przypadku Datadog), a tylko konkretne usługi lub mikrousługi.
Wracając do Datadog: z mapy usług widać, że zapytania użytkowników docierają do Django. Przejdźmy do usługi Django i w końcu zobaczymy to, czego oczekiwaliśmy:
Niestety, domyślnie brakuje tutaj wykresu Czas transakcji w sieci, podobnego do tego, co widzimy na głównym pulpicie New Relic. Jednak można go skonfigurować w miejscu wykresu % czasu spędzonego. Wystarczy przełączyć go na Średni czas na zapytanie według typu… i oto znany wykres patrzy na nas!
Dlaczego w Datadog wybrano inny wykres — dla nas to zagadka. Rozczarowało też, że system nie zapamiętuje wyboru użytkownika (w przeciwieństwie do obu konkurentów), dlatego jedynym rozwiązaniem jest tworzenie pulpitów użytkowników.
Za to zaskoczyła możliwość w Datadog przejścia z tych wykresów na metryki związanych serwerów, przeczytania logów i ocenienia obciążenia handlerów serwera webowego (Gunicorn). Wszystko prawie jak w New Relic… a nawet trochę więcej (logi)!
Poniżej wykresów znajdują się transakcje, które są całkowicie analogiczne do New Relic:
W Datadog transakcje nazywają się zasobami. Można posortować kontrolery według liczby zapytań, średniego czasu odpowiedzi oraz maksymalnego czasu poświęconego w wybranym okresie.
Zasób można rozwinąć i zobaczyć wszystko, co już obserwowaliśmy w New Relic:
Dostępna jest zarówno statystyka zasobu, jak i zwięzła lista wywołań wewnętrznych oraz przykłady zapytań, które można sortować według kodu odpowiedzi… Nota bene, to sortowanie bardzo spodobało się naszym inżynierom.
Każdy przykład zasobu w Datadog można rozwijać i badać:
Prezentowane są parametry zapytania, diagram podsumowujący czas spędzony na każdym z komponentów oraz wykres wodospadowy, na którym widać sekwencję wywołań. Można również przełączyć na widok drzewa wykresu wodospadowego:
I co najciekawsze — przegląd obciążenia hosta, na którym wykonano zapytanie, oraz przegląd logów zapytania.
Świetna integracja!
Może pojawić się pytanie, gdzie są zakładki Bazy Danych i External Services, jak w New Relic. Tutaj ich nie ma: ponieważ Datadog rozdziela aplikację na składniki, PostgreSQL będzie traktowany jako osobna usługa, a zamiast Usług Zewnętrznych należy szukać aws.storage (analogicznie będzie też w przypadku każdego innego zewnętrznego serwisu, do którego aplikacja może się odnosić).
A oto przykład z postgres:
W zasadzie jest wszystko, co chcieliśmy:
Widać, z jakiego „serwisu” przyszło zapytanie.
Nie będzie zbędne przypomnienie, że Datadog doskonale integruje się z NGINX Ingress i pozwala na przeprowadzanie pełnej śledzenia od momentu przyjęcia zapytania do klastra, a także umożliwia przyjmowanie metryk statsd, zbieranie logów i metryk hostów.
Ogromnym plusem Datadog jest to, że jego cena składa się z monitorowania infrastruktury, APM, zarządzania logami i testów syntetycznych, tzn. można elastycznie dobrać plan.
2. Atatus
Zespół Atatus twierdzi, że ich serwis to „to samo, co New Relic, ale lepsze”. Zobaczmy, czy rzeczywiście tak jest.
Główna tabela wygląda rzeczywiście podobnie, ale nie udało się zidentyfikować używanych w aplikacji Redis i memcached.
APM domyślnie wybiera wszystkie transakcje, chociaż zazwyczaj potrzebne są tylko WEB. Tak jak w Datadog, nie ma możliwości przejścia do potrzebnego serwisu z głównego panelu. Co więcej, transakcje są w liście po błędach, co wygląda dość nielogicznie dla APM.
W transakcjach w Atatus wszystko maksymalnie przypomina New Relic. Minusem jest to, że od razu nie widać dynamiki dla każdego z kontrolerów. Trzeba to szukać w tabeli kontrolerów, sortując według Most Time Consumed:
Znany nam wykaz kontrolerów dostępny jest w zakładce Explore:
W pewnym sensie ta tabela przypomina Datadog i bardziej podoba mi się niż ta podobna w New Relic.
Każdą transakcję można rozwinąć i zobaczyć, czym zajmowała się aplikacja:
Panel również raczej przypomina Datadog: jest liczba zapytań, ogólny obraz wezwań. Górny panel udostępnia zakładkę z błędami HTTP Failures i przykłady wolnych zapytań Session Traces:
Jeśli przejdziesz do transakcji, zobaczysz przykład śledzenia, możesz uzyskać listę zapytań do bazy i sprawdzić nagłówki zapytania. Wszystko podobnie jak w New Relic:
Ogólnie rzecz biorąc, Atatus zadowolił szczegółowymi śledzeniami — bez typowych dla New Relic zlepień wywołań w bloku przypomnienia:
Jednak brakuje tutaj filtra, który (jak w New Relic) odcinałby bardzo szybkie zapytania (<5ms). Z drugiej strony, wyświetlenie końcowej odpowiedzi transakcji (sukces lub błąd) mi się podobało.
Panel Bazy Danych pomoże zbadać zapytania do zewnętrznych baz danych, które wykonuje aplikacja. Przypominam, że Atatus znalazł tylko PostgreSQL i MySQL, chociaż w projekcie zaangażowane są również Redis i memcached.
Zapytania są sortowane według znanych kryteriów: częstość występowania, średni czas odpowiedzi i tak dalej. Warto również zwrócić uwagę na zakładkę z najwolniejszymi zapytaniami — to bardzo wygodne. Co więcej, dane w tej zakładce dla PostgreSQL pokryły się z danymi z rozszerzenia — świetny wynik!
Zakładka Zapytania zewnętrzne jest całkowicie identyczna z Bazami Danymi.
Wnioski
Obydwa przedstawione narzędzia dobrze sprawdzały się w roli APM. Każde z nich może zaoferować niezbędne minimum. Krótko podsumowując nasze wrażenia, można powiedzieć:
Datadog
Zalety:
- wygodna siatka taryfowa (APM kosztuje 31 USD za hosting);
- świetnie sprawdził się z Pythonem;
- możliwość integracji z OpenTracing
- Integracja z Kubernetes;
- integracja z NGINX Ingress.
Wady:
- jedyny APM, który spowodował niedostępność aplikacji z powodu błędu modułu (predis);
- słaba auto-instrumentacja PHP;
- częściowo dziwne określenie usług i ich przeznaczenia.
Atatus
Zalety:
- głęboka instrumentacja PHP;
- interfejs użytkownika podobny do New Relic.
Wady:
- nie działa na starych systemach operacyjnych (Ubuntu 12.05, CentOS 5);
- słaba auto-instrumentacja;
- wsparcie tylko dla dwóch języków programowania (Node.js i PHP);
- wolna praca interfejsu.
Biorąc pod uwagę cenę Atatus wynoszącą 69 USD miesięcznie za serwer, wolelibyśmy używać Datadog, który doskonale integruje się z naszymi potrzebami (aplikacje webowe w K8s) i ma wiele przydatnych funkcji.
P.S.
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «».
Źródło: habr.com
