🥇Nie tylko New Relic: spojrzenie na Datadog i Atatus

W środowisku inżynierów SRE/DevOps nikogo nie zdziwi fakt, że pewnego dnia pojawia się klient (lub system monitorujący) i melduje, że „wszystko stracone”: strona nie działa, płatności nie idą, życie gnije ...Bez względu na to, jak bardzo chciałbyś pomóc w takiej sytuacji, bez prostego i zrozumiałego narzędzia może to być bardzo trudne. Często problem kryje się w samym kodzie aplikacji, wystarczy go zlokalizować.

I w smutku i w radości…

Tak się złożyło, że od dawna i głęboko zakochaliśmy się w New Relic. Było i pozostaje doskonałym narzędziem do monitorowania wydajności aplikacji, a także pozwala na instrumentację architektury mikroserwisów (za pomocą jej agenta) i wiele, wiele więcej. I wszystko mogłoby być świetnie, gdyby nie zmiany w polityce cenowej serwisu: to koszt z 2013 lat urósł ponad 3 razy. Dodatkowo od zeszłego roku uzyskanie konta próbnego wymaga komunikacji z osobistym menadżerem, co utrudnia zaprezentowanie produktu potencjalnemu klientowi.

Typowa sytuacja: Nowa Relikwia nie jest potrzebna „na stałe”, pamiętają o niej dopiero w momencie, gdy zaczynają się problemy. Ale nadal trzeba płacić regularnie (140 USD za serwer miesięcznie), a w przypadku automatycznie skalowanej infrastruktury chmurowej sumy sumują się dość duże. Chociaż istnieje opcja Pay-As-You-Go, włączenie New Relic będzie wymagało ponownego uruchomienia aplikacji, co może doprowadzić do utraty problematycznej sytuacji, od której wszystko zostało uruchomione. Nie tak dawno temu New Relic wprowadził nowy plan taryfowy - Niezbędniki, - który na pierwszy rzut oka wygląda na rozsądną alternatywę dla Professional... jednak po bliższym przyjrzeniu się okazało się, że brakuje w nim kilku ważnych funkcji (w szczególności nie posiada Kluczowe transakcje, Śledzenie między aplikacjami, Śledzenie rozproszone).

W rezultacie zaczęliśmy myśleć o szukaniu tańszej alternatywy i nasz wybór padł na dwie usługi: Datadog i Atatus. Dlaczego na nich?

O konkurentach

Od razu powiem, że na rynku są inne rozwiązania. Rozważaliśmy nawet opcje Open Source, ale nie każdy klient ma wolną przestrzeń do hostowania rozwiązań hostowanych samodzielnie... – ponadto będą one wymagały dodatkowej konserwacji. Wybrana przez nas para okazała się nam najbliższa nasze potrzeby:

wbudowana i rozwinięta obsługa aplikacji PHP (stack naszych klientów jest bardzo zróżnicowany, ale jest to wyraźny lider w kontekście poszukiwania alternatywy dla New Relic);
przystępny koszt (mniej niż 100 USD miesięcznie na hosta);
oprzyrządowanie automatyczne;
integracja z Kubernetesem;
Podobieństwo do interfejsu New Relic jest zauważalnym plusem (ponieważ nasi inżynierowie są do tego przyzwyczajeni).

Dlatego na etapie wstępnej selekcji wyeliminowaliśmy kilka innych popularnych rozwiązań, a w szczególności:

Tideways, AppDynamics i Dynatrace – za cenę;
Stackify jest zablokowany w Federacji Rosyjskiej i pokazuje za mało danych.

Dalsza część artykułu jest tak skonstruowana, że najpierw zostaną pokrótce zaprezentowane omawiane rozwiązania, po czym opowiem o naszej typowej interakcji z New Relic oraz doświadczeniach/wrażeniach z wykonywania podobnych operacji w innych serwisach.

Prezentacja wybranych konkurentów

Про Nowy Relikt, pewnie każdy słyszał? Rozwój tej usługi rozpoczął się ponad 10 lat temu, w 2008 roku. Używamy go aktywnie od 2012 roku i nie mieliśmy żadnych problemów z integracją naprawdę dużej liczby aplikacji w PHP, Ruby i Pythonie, a także mieliśmy doświadczenie w integracji z C# i Go. Autorzy serwisu posiadają rozwiązania do monitorowania aplikacji, infrastruktury, śledzenia infrastruktur mikroserwisowych, stworzyli wygodne aplikacje dla urządzeń użytkowników i wiele więcej.

Jednak agent New Relic działa na zastrzeżonych protokołach i nie obsługuje OpenTracing. Zaawansowane oprzyrządowanie wymaga edycji specjalnie dla New Relic. Wreszcie obsługa Kubernetes jest nadal eksperymentalna.

Rozpoczął swój rozwój w 2010 roku datadog wygląda zauważalnie ciekawiej niż New Relic właśnie pod kątem wykorzystania w środowiskach Kubernetes. W szczególności wspiera integrację z protokołami NGINX Ingress, logcollection, statsd i OpenTracing, co pozwala śledzić żądanie użytkownika od momentu jego połączenia do zakończenia, a także znajdować logi dla tego żądania (zarówno po stronie serwera WWW i konsumenta).

Podczas korzystania z Datadog natknęliśmy się na to, że czasami niepoprawnie budował mapę mikroserwisów i pewne niedociągnięcia techniczne. Na przykład błędnie zidentyfikował typ usługi (myląc Django z usługą buforowania) i spowodował 500 błędów w aplikacji PHP korzystającej z popularnej biblioteki Predis.

Atatus — najmłodszy instrument; usługa została uruchomiona w 2014 roku. Jego budżet marketingowy wyraźnie ustępuje wymienionym konkurentom, wzmianki są znacznie rzadsze. Jednak samo narzędzie jest bardzo podobne do New Relic, nie tylko pod względem możliwości (APM, monitorowanie przeglądarki itp.), ale także wyglądu.

Istotną wadą jest to, że obsługuje tylko Node.js i PHP. Z drugiej strony jest zaimplementowany zauważalnie lepiej niż Datadog. W przeciwieństwie do tego ostatniego, Atatus nie wymaga od aplikacji dokonywania modyfikacji ani dodawania dodatkowych etykiet do kodu.

Jak współpracujemy z New Relic

Teraz zastanówmy się, jak ogólnie używamy New Relic. Załóżmy, że mamy problem wymagający rozwiązania:

Łatwo to zobaczyć na wykresie kolec - Przeanalizujmy to. W New Relic transakcje internetowe są natychmiast wybierane dla aplikacji internetowej, wszystkie komponenty są pokazywane na wykresie wydajności, dostępne są panele błędów, współczynnika żądań... Co najważniejsze, bezpośrednio z tych paneli można poruszać się pomiędzy różnymi części aplikacji (na przykład kliknięcie MySQL spowoduje przejście do sekcji bazy danych).

Ponieważ w rozważanym przykładzie widzimy wzrost aktywności PHP, kliknij ten wykres i automatycznie przejdź do transakcje:

Lista transakcji, które w zasadzie są kontrolerami z modelu MVC, jest już posortowana według Najbardziej czasochłonne, co jest bardzo wygodne: od razu widzimy, co robi aplikacja. Oto przykłady długich zapytań, które są automatycznie zbierane przez New Relic. Przełączając sortowanie, łatwo jest znaleźć:

najbardziej obciążony kontroler aplikacji;
najczęściej żądany kontroler;
najwolniejszy z kontrolerów.

Dodatkowo możesz rozwinąć każdą transakcję i zobaczyć, co robiła aplikacja w momencie wykonania kodu:

Wreszcie aplikacja przechowuje przykłady śladów długich żądań (takich, które trwają dłużej niż 2 sekundy). Oto panel dla długiej transakcji:

Widać, że dwie metody zajmują dużo czasu, a jednocześnie pokazywany jest moment wykonania żądania, jego URI i domena. Bardzo często pomaga to znaleźć żądanie w logach. Zamierzam Szczegóły śledzenia, możesz zobaczyć, skąd są wywoływane te metody:

Oraz w Zapytania do bazy danych — oceniaj zapytania do baz danych, które zostały wykonane podczas działania aplikacji:

Uzbrojeni w tę wiedzę możemy ocenić, dlaczego aplikacja zwalnia i współpracować z programistą w celu opracowania strategii rozwiązania problemu. W rzeczywistości New Relic nie zawsze daje jasny obraz, ale pomaga wybrać wektor śledztwa:

długo PDO::Construct doprowadziło nas do dziwnego funkcjonowania pgpoll;
niestabilność w czasie Memcache::Get zasugerował, że maszyna wirtualna została niepoprawnie skonfigurowana;
podejrzanie wydłużony czas przetwarzania szablonu doprowadził do zagnieżdżonej pętli sprawdzającej obecność 500 awatarów w magazynie obiektów;
i tak dalej…

Zdarza się też, że zamiast wykonać kod, na ekranie głównym wyrasta coś związanego z zewnętrznym przechowywaniem danych - i nie ma znaczenia, co to będzie: Redis czy PostgreSQL - wszystkie są ukryte w zakładce Bazy danych.

Możesz wybrać konkretną bazę do wyszukiwania i sortować zapytania - podobnie jak dzieje się to w Transakcjach. A wchodząc w zakładkę żądania, możesz zobaczyć, ile razy to żądanie pojawia się w każdym z kontrolerów aplikacji, a także oszacować, jak często jest ono wywoływane. To jest bardzo wygodne:

Zakładka zawiera podobne dane Usługi zewnętrzne, który ukrywa żądania do zewnętrznych usług HTTP, takie jak dostęp do pamięci obiektów, wysyłanie zdarzeń do wartownika i tym podobne. Zawartość zakładki jest całkowicie podobna do Bazy Danych:

Konkurenci: możliwości i wrażenia

Teraz najciekawsze jest porównanie możliwości New Relic z tym, co oferuje konkurencja. Niestety nie udało nam się przetestować wszystkich trzech narzędzi na jednej wersji jednej aplikacji działającej w środowisku produkcyjnym. Staraliśmy się jednak porównać sytuacje/konfiguracje, które były jak najbardziej identyczne.

1. Datadog

Datadog wita nas panelem ze ścianą usług:

Próbuje podzielić aplikacje na komponenty/mikrousługi, więc w przykładowej aplikacji Django zobaczymy 2 połączenia z PostgreSQL (defaultdb и postgres), a także Seler, Redis. Praca z Datadog wymaga minimalnej wiedzy na temat zasad MVC: musisz zrozumieć, skąd zazwyczaj pochodzą żądania użytkowników. To zwykle pomaga mapa usług:

Swoją drogą w New Relic jest coś podobnego:

… a ich mapa, moim zdaniem, jest prostsza i bardziej przejrzysta: nie wyświetla elementów jednej aplikacji (co byłoby zbyt szczegółowe, jak w przypadku Datadog), a jedynie konkretne usługi lub mikroserwisy.

Wróćmy do Datadog: z mapy usług widzimy, że żądania użytkowników przychodzą do Django. Przejdźmy do usługi Django i na koniec zobaczmy, czego się spodziewaliśmy:

Niestety domyślnie nie ma tu żadnego wykresu Czas transakcji internetowej, podobnie jak to, co widzimy na głównym panelu New Relic. Można go jednak skonfigurować zamiast harmonogramu % spędzonego czasu. Wystarczy go przełączyć Średni czas na żądanie według typu... i teraz patrzy na nas znajomy wykres!

Dlaczego Datadog wybrał inny wykres, pozostaje dla nas zagadką. Kolejną frustrującą rzeczą jest to, że system nie zapamiętuje wyboru użytkownika (w przeciwieństwie do obu konkurentów), dlatego jedynym rozwiązaniem jest stworzenie paneli na zamówienie.

Byłem jednak zadowolony z możliwości w Datadog przełączenia się z tych wykresów na metryki powiązanych serwerów, odczytania logów i oceny obciążenia procedur obsługi serwerów WWW (Gunicorn). Wszystko jest prawie takie samo jak w New Relic... a nawet trochę więcej (logi)!

Poniżej wykresów znajdują się transakcje całkowicie podobne do New Relic:

W Datadog transakcje są wywoływane Surowce. Możesz sortować kontrolery według liczby żądań, średniego czasu odpowiedzi i maksymalnego czasu spędzonego w wybranym okresie.

Możesz rozwinąć zasób i zobaczyć wszystko, co już zaobserwowaliśmy w New Relic:

Istnieją statystyki dotyczące zasobu, uogólniona lista wywołań wewnętrznych i przykłady żądań, które można sortować według kodu odpowiedzi... Nawiasem mówiąc, naszym inżynierom bardzo podobało się to sortowanie.

Każdy przykładowy zasób w Datadog można otworzyć i przeglądać:

Przedstawione są parametry żądania, wykres podsumowujący czas spędzony nad każdym komponentem oraz wykres kaskadowy przedstawiający sekwencję wywołań. Możesz także przełączyć się na widok drzewa wykresu kaskadowego:

A najciekawsze jest sprawdzenie obciążenia hosta, na którym wykonano żądanie i przeglądanie dzienników żądań.

Świetna integracja!

Możesz się zastanawiać, gdzie są te zakładki Bazy danych и Usługi zewnętrznejak w New Relic. Tutaj ich nie ma: ponieważ Datadog rozkłada aplikację na komponenty, uwzględniony zostanie PostgreSQL osobną usługęi zamiast Usług Zewnętrznych warto ich szukać aws.storage (podobnie będzie dla każdej innej usługi zewnętrznej, do której aplikacja może uzyskać dostęp).

Oto przykład z postgres:

Zasadniczo jest wszystko, czego chcieliśmy:

Możesz zobaczyć, z której „usługi” pochodzi żądanie.

Nie wypada przypomnieć, że Datadog doskonale integruje się z NGINX Ingress i pozwala na śledzenie typu end-to-end od momentu pojawienia się żądania w klastrze, a także umożliwia otrzymywanie metryk statystycznych, zbieranie logów i metryk hostów .

Ogromnym plusem Datadoga jest jego cena rozwija się z monitorowania infrastruktury, APM, Log Management i testów syntetycznych, tj. Możesz wybrać swój plan elastycznie.

2. Stan

Zespół Atatus twierdzi, że ich usługi są „takie same jak New Relic, ale lepsze”. Zobaczmy, czy tak jest naprawdę.

Panel główny wygląda podobnie, jednak nie udało się ustalić, jakie Redis i memcached zostały użyte w aplikacji.

APM domyślnie wybiera wszystkie transakcje, chociaż zazwyczaj potrzebne są tylko transakcje internetowe. Podobnie jak Datadog, nie ma możliwości przejścia do żądanej usługi z panelu głównego. Co więcej, transakcje są wykazywane po błędach, co w przypadku APM nie wydaje się zbyt logiczne.

W transakcjach Atatus wszystko jest jak najbardziej podobne do New Relic. Wadą jest to, że dynamika każdego kontrolera nie jest od razu widoczna. Trzeba go szukać w tabeli kontrolerów, sortując według Najwięcej czasu:

Zwykła lista kontrolerów dostępna jest w zakładce Poznaj:

W pewnym sensie ten stół przypomina Datadoga i podoba mi się bardziej niż podobny w New Relic.

Możesz rozwinąć każdą transakcję i zobaczyć, co robiła aplikacja:

Panel też bardziej przypomina Datadoga: jest szereg żądań, ogólny obraz rozmów. Na górnym panelu znajduje się zakładka błędu Błędy HTTP i przykłady powolnych zapytań Ślady sesji:

Jeśli przejdziesz do transakcji, możesz zobaczyć przykładowy ślad, możesz uzyskać listę żądań do bazy danych i spojrzeć na nagłówki żądań. Wszystko jest podobne do New Relic:

Ogólnie rzecz biorąc, Atatus był zadowolony ze szczegółowych śladów - bez typowego dla New Relic wklejania wezwań w blok przypomnień:

Brakuje jednak filtra, który (jak New Relic) odcinałby ultraszybkie żądania (<5 ms). Z drugiej strony spodobało mi się wyświetlenie ostatecznej odpowiedzi na transakcję (powodzenie lub błąd).

Panel Bazy danych pomoże Ci zbadać żądania do zewnętrznych baz danych wysyłane przez aplikację. Przypomnę, że Atatus znalazł tylko PostgreSQL i MySQL, chociaż w projekt zaangażowane są także Redis i memcached.

Żądania są sortowane według zwykłych kryteriów: częstotliwość odpowiedzi, średni czas odpowiedzi i tak dalej. Wspomnę też o zakładce z najwolniejszymi zapytaniami – jest to bardzo wygodne. Co więcej, dane w tej zakładce dla PostgreSQL pokrywały się z danymi z rozszerzenia pg_stat_statements - doskonały wynik!

Patka Żądania zewnętrzne całkowicie identyczne z bazami danych.

odkrycia

Obydwa zaprezentowane narzędzia sprawdziły się w roli APM. Każdy z nich może zaoferować wymagane minimum. Nasze wrażenia można krótko podsumować następująco:

datadog

Plusy:

wygodny harmonogram taryf (APM kosztuje 31 USD za hosta);
dobrze współpracował z Pythonem;
Możliwość integracji z OpenTracing
integracja z Kubernetesem;
integracja z NGINX Ingress.

Wady:

jedyny APM, który spowodował niedostępność aplikacji z powodu błędu modułu (predis);
słabe automatyczne oprzyrządowanie PHP;
częściowo dziwna definicja usług i ich cel.

Atatus