Grafana Stack i Dynatrace odpowiadają na podobne potrzeby, ale robią to w inny sposób.
Dynatrace jest kompleksową, komercyjną platformą observability, w której monitoring infrastruktury, APM, analiza logów, tracing, wykrywanie zależności czy automatyczna analiza przyczyn problemów są elementami jednego ekosystemu.
Grafana reprezentuje bardziej otwarte i modułowe podejście. Sama Grafana odpowiada przede wszystkim za wizualizację i alerty, natomiast kolejne elementy stacku można dobierać zależnie od potrzeb: Mimir dla metryk, Loki dla logów, Tempo dla traces czy Pyroscope dla continuous profiling. Co istotne, Grafana może również korzystać z danych znajdujących się w innych systemach, bez konieczności przenoszenia ich do jednego backendu.
Modele architektury Grafany i Dynatrace
W środowisku enterprise ważniejsze jest to, jaki model observability chcemy zbudować i ile kontroli nad nim chcemy zachować. Grafana i Dynatrace prezentują dwa różne podejścia do observability.
Najważniejsza różnica pomiędzy rozwiązaniami ujawnia się już na poziomie ich architektury.
Dynatrace jest platformą wewnętrznie zintegrowaną, która w swoim jednym środowisku zapewnia różne funkcje monitoringu. Użytkownik otrzymuje szeroki zestaw funkcjonalności w ramach jednego rozwiązania. Full-stack monitoring obejmuje m.in. APM, monitoring infrastruktury i Kubernetes, profiling oraz automatyczną analizę root cause dla transakcji end-to-end. Platforma obsługuje również dane OpenTelemetry.
Grafana Stack przypomina raczej zestaw współpracujących ze sobą elementów:
- Grafana - wizualizacja, dashboardy, eksploracja danych i alerting,
- Mimir - skalowalne przechowywanie metryk,
- Loki - agregacja i analiza logów,
- Tempo - distributed tracing, czyli śledzenie przepływu pojedynczego żądania przez wiele usług i komponentów systemu
- Pyroscope - continuous profiling, ciągła analiza wykorzystania zasobów przez aplikację na poziomie konkretnych funkcji i fragmentów kodu
- Alloy - kolektor danych telemetrycznych, który zbiera metryki, logi, ślady (traces) i profile z różnych systemów, a następnie przekazuje je do platform observability.
Poszczególne komponenty można wdrażać niezależnie i łączyć również z rozwiązaniami spoza ekosystemu Grafany. W praktyce oznacza to dwie odmienne filozofie. Dynatrace dostarcza znaczną część platformy observability jako gotowy, spójny ekosystem. Grafana pozwala organizacji zbudować architekturę observability z wybranych komponentów.
Integracje i wtyczki - jak Grafana i Dynatrace łączą się z istniejącym środowiskiem?
W dużej organizacji platforma observability nie funkcjonuje w próżni. Musi współpracować z istniejącymi systemami, chmurą, bazami danych, Kubernetes, czy wcześniejszym monitoringiem.
Dlatego liczba i charakter dostępnych integracji są istotnym elementem porównania.
Integracje w Grafanie
Jedną z podstawowych cech Grafany jest architektura oparta na wtyczkach. Pozwalają one podłączać zewnętrzne źródła i wizualizować znajdujące się w nich dane.
Grafana OSS obsługuje źródła takie jak Zabbix, Prometheus, CloudWatch, Loki, Elasticsearch czy PostgreSQL. Ekosystem można rozszerzać kolejnymi pluginami. Grafana może zostać dołożona do istniejącego środowiska zamiast wymuszać jego przebudowę.
Organizacja może przykładowo zachować dotychczasowe źródła metryk czy logów i wykorzystać Grafanę jako wspólną warstwę wizualizacji. Następnie może stopniowo rozszerzać architekturę o Loki, Tempo, Mimir czy Pyroscope.
Integracje w Dynatrace
Dynatrace również posiada ekosystem integracji i rozszerzeń oraz obsługuje otwarte standardy, w tym OpenTelemetry. Dane OTel mogą być zbierane i analizowane przez platformę razem z pozostałymi danymi telemetrycznymi.
Dlatego nie można sprowadzić porównania do stwierdzenia, że Grafana „integruje się ze wszystkim”, a Dynatrace jest systemem zupełnie zamkniętym, różnica leży bardziej w modelu architektonicznym.
Grafana została zaprojektowana jako rozwiązanie kompozycyjne, w którym zewnętrzne źródła danych mogą pozostać niezależnymi elementami architektury. W Dynatrace integracje przede wszystkim rozszerzają możliwości centralnej platformy.
W środowisku enterprise ta różnica może mieć większe znaczenie niż sama liczba dostępnych integracji.
Grafana offers more than 350 plugins
Open source - dlaczego ma znaczenie w enterprise?
Jedną z najważniejszych różnic jest model licencyjny. Grafana, Loki, Tempo, Mimir, Pyroscope czy Alloy są rozwijane jako projekty open source.
Nie chodzi jednak wyłącznie o możliwość korzystania z oprogramowania bez zakupu komercyjnej licencji. Z punktu widzenia architektury enterprise open source oznacza przede wszystkim większą swobodę w budowaniu środowiska. Organizacja może samodzielnie uruchamiać poszczególne komponenty, decydować o miejscu przechowywania danych, łączyć je z rozwiązaniami innych producentów i rozwijać architekturę bez konieczności przenoszenia całego observability do jednego systemu.
Dla organizacji planującej platformę observability na wiele lat oznacza to również mniejsze ryzyko vendor lock-in.
Modularność Grafany - nie trzeba wdrażać wszystkiego naraz
To jedna z największych zalet Grafana Stack w rozbudowanych środowiskach.
Observability nie musi być wdrażane jako jeden wielki projekt. Organizacja może zacząć od Grafany jako warstwy wizualizacji dla danych, które już posiada. Następnie, zależnie od potrzeb, dołączyć kolejne komponenty. Potrzebna jest centralizacja logów? Można wdrożyć Loki. Potrzebny jest distributed tracing? Do architektury można dołączyć Tempo. Potrzebne jest długoterminowe i skalowalne przechowywanie metryk? Mimir.
Zespół chce zejść z analizą wydajności do poziomu funkcji i kodu? Można wykorzystać Pyroscope, który pozwala korelować profiling z metrykami, logami i traces.
Nie oznacza to również, że wdrożenie Grafany wymaga wymiany istniejących technologii. Możliwe jest podejście hybrydowe, w którym część obecnych narzędzi pozostaje źródłem danych, a Grafana staje się wspólną warstwą ich prezentacji i analizy.
To szczególnie istotne w enterprise, gdzie środowisko IT powstawało często przez kilkanaście lat i składa się z technologii pochodzących od wielu producentów.
Modularność pozwala wdrażać podejście observability etapami zamiast przeprowadzać jedną, wielką stuprocentową migrację.
Kolejną, ważną zaletą Grafany, jest to, że Grafana OSS pozwala przetestować architekturę przed wdrożeniem produkcyjnym. W przypadku dużych organizacji ma to znacznie większe znaczenie niż samo hasło „darmowa wersja”.
Można w ten sposób zweryfikować:
- integrację z istniejącymi źródłami danych,
- sposób budowania dashboardów,
- alerting,
- zbieranie i korelację danych,
- wymagania infrastrukturalne,
- skalowanie rozwiązania,
- wymagane kompetencje zespołu,
- potencjalne ograniczenia architektury.
Dzięki temu decyzja o wdrożeniu nie musi być podejmowana wyłącznie na podstawie dokumentacji, prezentacji handlowej czy deklaracji producenta. Najpierw można sprawdzić, czy zaprojektowana architektura rzeczywiście działa w konkretnym środowisku organizacji. Dopiero później można zdecydować, czy rozwiązanie pozostanie oparte na OSS, zostanie rozbudowane o Grafana Enterprise albo czy organizacja wybierze inny model.
Grafana Enterprise jest przy tym komercyjnym rozszerzeniem Grafana OSS, oferującym dodatkowe funkcje i data sources oraz wsparcie producenta 24/7.
Gdzie Dynatrace ma przewagę? Automatyzacja i gotowość platformy
Modularność ma jednak również drugą stronę - ktoś musi tę architekturę zaprojektować.
Grafana Stack wymaga podjęcia decyzji dotyczących m.in. zbierania danych, storage, retencji, high availability, integracji poszczególnych komponentów, alertingu czy skalowania.
W Dynatrace większa część tych możliwości jest elementem jednej platformy. Przykładowo Full-Stack Monitoring obejmuje APM, analizę infrastruktury, profiling, Kubernetes Platform Monitoring oraz automatyczną analizę root cause dla transakcji end-to-end.
Jeżeli więc priorytetem organizacji jest szybkie uzyskanie zaawansowanej obserwowalności przy ograniczeniu liczby elementów, które trzeba samodzielnie zaprojektować i utrzymywać, Dynatrace ma bardzo mocne argumenty.
Total cost of ownership (TCO)
Grafana OSS jest darmowa, ale observability nie jest. Open source może znacząco zmienić strukturę kosztów platformy, ale błędem byłoby przyjęcie prostego założenia, że Grafana jest zupełnie darmowa, a Dynatrace jest płatny. Co prawda Grafana OSS nie wymaga zakupu komercyjnej licencji na samo oprogramowanie, ale nadal potrzebna jest jednak infrastruktura, storage oraz zespół odpowiedzialny za wdrożenie i utrzymanie platformy.
Przy dużej skali trzeba uwzględnić m.in.:
- zasoby obliczeniowe,
- przechowywanie rosnącej ilości danych,
- backup i wysoką dostępność,
- aktualizacje,
- rozwój integracji,
- utrzymanie dashboardów i alertingu,
- kompetencje administratorów i SRE.
Dynatrace stosuje natomiast komercyjny model oparty na rocznym zobowiązaniu i wykorzystaniu poszczególnych możliwości platformy. Publiczny cennik rozdziela m.in. monitoring infrastruktury, Full-Stack Monitoring oraz przetwarzanie i przechowywanie danych telemetrycznych.
Dlatego przy środowisku 500, 2000 czy 10 000 hostów właściwym wskaźnikiem nie jest koszt licencji, ale total cost of ownership.
Porównanie powinno obejmować licencje, infrastrukturę, storage, administrację, kompetencje, wsparcie, rozwój oraz koszt przyszłych migracji. Dopiero wtedy można uczciwie powiedzieć, które rozwiązanie jest tańsze dla konkretnej organizacji.
Vendor lock-in i kontrola nad architekturą
W środowisku działającym 24/7 platforma observability może funkcjonować przez wiele lat. Dlatego warto zastanowić się nie tylko nad wdrożeniem, ale również nad tym, jak trudno będzie kiedyś z niego wyjść.
Modularna architektura Grafana Stack pozwala wymieniać poszczególne komponenty bez konieczności przebudowy całego środowiska. Grafana może przykładowo nadal pełnić rolę warstwy wizualizacji, nawet jeżeli organizacja zmieni backend odpowiedzialny za logi lub metryki. Data source plugins umożliwiają bowiem odpytywanie zewnętrznych systemów bez przenoszenia wszystkich danych do Grafany.
W Dynatrace więcej funkcjonalności znajduje się w obrębie jednego ekosystemu. Daje to korzyść w postaci spójności i automatyzacji, ale jednocześnie zwiększa znaczenie strategicznej relacji z jednym dostawcą. W perspektywie kilku lat organizacja powinna więc uwzględnić nie tylko obecne możliwości platformy, ale także koszt zmiany architektury w przyszłości.
Kiedy warto wybrać Dynatrace?
Dynatrace może być lepszym rozwiązaniem, jeżeli organizacja oczekuje przede wszystkim gotowej, mocno zintegrowanej platformy observability.
Warto go rozważyć szczególnie wtedy, gdy:
- priorytetem jest automatyzacja,
- organizacja potrzebuje zaawansowanego APM,
- automatyczne wykrywanie zależności i root cause analysis mają kluczowe znaczenie,
- zespół nie chce samodzielnie budować i integrować wielu elementów stacku,
- organizacja akceptuje komercyjny model licencjonowania w zamian za ograniczenie części złożoności operacyjnej.
Kiedy warto wybrać Grafana Stack?
Grafana Stack staje się szczególnie interesujący, gdy organizacja chce zachować większą kontrolę nad architekturą observability.
Warto go rozważyć, jeśli:
- istnieje już kilka różnych systemów monitoringu i źródeł danych telemetrycznych,
- organizacja chce wdrażać observability etapami,
- ważne są open source i otwarte standardy,
- istotne jest ograniczenie vendor lock-in,
- dostępne są odpowiednie kompetencje wewnętrzne lub zewnętrzny partner odpowiedzialny za architekturę i utrzymanie.
Grafana Stack czy Dynatrace - co wybrać w enterprise?
Wybór między Grafana Stack a Dynatrace zależy przede wszystkim od architektury środowiska, istniejących technologii i oczekiwanego modelu observability. Dynatrace jest dobrym wyborem tam, gdzie najważniejsze są automatyzacja, szybkie uruchomienie zaawansowanego APM i ograniczenie liczby elementów, które organizacja musi samodzielnie integrować.
W Hawatel w środowiskach produkcyjnych stawiamy jednak na Grafanę. Grafana Stack jest szczególnie atrakcyjny ze względu na modularność, open source, integrację istniejących technologii, kontroli nad architekturą oraz możliwości stopniowego budowania observability. Dzięki temu możemy projektować rozwiązania dopasowane do rzeczywistych potrzeb istniejącej infrastruktury organizacji, zamiast dopasowywać całe środowisko do jednej platformy.
W środowisku enterprise celem nie jest bowiem wdrożenie kolejnego narzędzia do monitoringu. Jest nim stworzenie architektury, która zapewnia widoczność infrastruktury i aplikacji, skraca analizę incydentów i pozostaje możliwa do rozwoju wraz ze zmianami całego środowiska IT.
Narzędzie jest tylko jednym z elementów tej decyzji. Architektura zostaje z organizacją na lata.
