Jeden z naszych klientów zażyczył sobie zobaczyć, jak potrafi Dynatrace. Najprostszą odpowiedzią i rozwiązaniem tego (nietrywialnego, jak się później okazało) zagadnienia było:
Proszę zarejestrować się na darmowy 15-dniowy trial pod dynatrace.ai/omnilogy.
Na co klient, nieco kręcąc nosem, odpowiada tak:
Ale nie mam aplikacji testowej, nie wiem, kiedy znajdę czas na ewaluację i pewnie nie uda mi się wygospodarować dwóch tygodni, żeby do tego przysiąść i zrozumieć wartość.

I choć sprawa się nieco komplikuje, bo trudno odmówić logiki takim argumentom, w tym miejscu zaczyna się moja przygoda z Google Cloud Platform.

Co to jest GCP i dlaczego jest fajne?

To nie jest reklama ani kryptoreklama, a ja nie mam z tego żadnych profitów. Google Cloud Platform (GCP) to rozbudowany zestaw usług konkurencyjnych do Amazon AWS i Microsoft Azure. W skład GCP wchodzą różnorodne usługi, począwszy od hostingu maszyn, przez platformy, bazy danych do szerokiego wachlarza wyspecjalizowanych usług. Bardzo skrótowo, z punktu widzenia danych i cyklu ich przetwarzania, oferta GCP wygląda następująco:

Usługi chmurowe GCP

Wybrane usługi w chmurze Google Cloud Platform.

Jest tu wszystko, co niezbędne, żeby zbudować testową wielowarstwową aplikację, dzięki której można zademonstrować potęgę platformy Dynatrace.  Ponieważ nie miałem czasu budować jej od zera, ani też ochoty na wyważanie otwartych drzwi, skorzystałem z gotowej aplikacji przygotowanej przez Dynatrace – easyTravel. Aplikacja easyTravel to wirtualny sklep z wycieczkami, który pozwala na znalezienie oferty spełniającej określone kryteria, a następnie przejście przez proces rezerwacji i sprzedaży wycieczki. Aplikacja ma kilka warstw – webowy front end, Javowy i .NET-owy backend oraz bazę danych. Wystarczający zestaw technologii, kilkanaście wzorców ruchu – od strony technologii jest wszystko, czego potrzebowałem. Problem pojawił się wówczas, gdy się okazało, że nie mogę postawić aplikacji easyTravel na serwerze, którym dysponowałem, bo był zajęty do innych zadań. Zacząłem kombinować, skąd wziąć na cito maszynę z Windows.

I wtedy z pomocą przyszedł kolega (z dobrą radą) i GCP (z zasobami). Postawienie maszyny z jednym z popularnych systemów operacyjnych to bułka z masłem. Ja wybrałem Compute Engine (GCE) i Windows Server, w specyfikacji wymaganej przez easyTravel. Jeśli jednak rozważasz postawienie swojej aplikacji na kontenerach, to możesz to zrobić za pomocą Google App Engine (GAE) i Kubernetesa (GKE). Oczywiście,GCP jest tylko przykładem; w twoim przypadku może szybciej lub łatwiej będzie skorzystać z oferty AWS czy Azure.

Monitoring Dynatrace

Byłem uratowany, bo po kilku minutach miałem hosta z systemem operacyjnymi i aplikacją testową, którą chciałem monitorować za pomocą Dynatrace, a następnie zademonstrować klientowi, co potrafi Dynatrace i jak prosto i szybko można to zrobić.

Dynatrace OneAgent w Google Compute Engine

Instalacja jest prosta, zależnie od systemu uruchamiasz skrypt (Linux) albo plik EXE (Windows). Po instalacji agenta, cały stos technologiczny został automatycznie wykryty – w tym wszystkie procesy, usługi i zależności między nimi.

Automatycznie wykryta topologia aplikacji przedstawiona w modelu Smartscape.

Co ciekawe, Dynatrace sprawnie poradził sobie również z identyfikacją platformy Google. I choć nie ma jeszcze specjalnego widoku dla usług GCP, jak to jest dla Amazon AWS, Dynatrace nie jest „ślepy” na chmurę Google. Metadane dotyczące hosta uruchomionego w chmurze GCP mogą być później użyte np. do automatycznego znakowania (tagowania) komponentów środowiska i filtrowania na dashoardach, np. w celu pokazania tych, które uruchomiono w wybranej strefie (GCE zone) lub należących do wybranego projektu w ramach GCP.

Widok hosta (fragment) na dashboardzie Dynatrace.

Widok procesu.

Metadane o chmurze są dostępne również w przypadku zastosowania Kubernetesa (GKE). Jak widzisz, w przypadku maszyn z GCE jest to bardzo proste i szybkie. Agent startuje, rozpoznaje środowisko i wysyła dane wydajnościowe do serwera automatycznie. Zero konfiguracji, a pełna architektura aplikacji i wszystkie zależności jak na dłoni! (O zależnościach czytaj na naszym blogu w Mapowanie zależności w aplikacji).

Po restarcie procesów, dla których One Agent może prowadzić głęboką analizę, do poziomu kodu, widok dashboardu dla hosta przypomina poniższy:

Dashboard hosta w Dynatrace

OneAgent w Google App Engine

Sprawa trochę inaczej wygląda w przypadku, kiedy nie mamy dostępu do systemu operacyjnego, czyli wówczas, gdy korzystamy z Google App Engine. Wówczas należy wstrzyknąć agenta do obrazu kontenera, a platforma konteneryzacji uruchomi go razem z innymi binariami, znajdującymi się w tym obrazie. Włożenie agenta do obrazu kontenera wymaga wyłącznie przygotowania pliku konfiguracyjnego, który pokaże agentowi, z jakiej ścieżki wystartować kod wykonywalny i do którego środowiska ma się łączyć.

Przykładowy plik konfiguracyjny do wstrzyknięcia agenta do obrazu kontenera.

Konfiguracja wymaga wygenerowania tokena do Dynatrace API, co zrobisz w Settings > Integration > Dynatrace API. Pamiętaj, żeby do każdej integracji używać innego tokena i odpowiednio je nazywać. Pozwala to lepiej kontrolować, gdzie i do czego te tokeny są używane.

Dynatrace wykorzystuje tokeny do integracji z innymi usługami.

Szczegóły dotyczące instalacji agenta w środowisku Google App Engine znajdziesz w https://www.dynatrace.com/support/help/cloud-platforms/google-cloud-platform/google-app-engine/deploy-oneagent-for-google-app-engine-apps/.

OneAgent w Google Kubernetes Engine

W przypadku zastosowania GKE, Dynatrace może monitorować każdy kontener uruchomiony za pomocą K8s. Automatyczna instrumentacja odbywa się za pomocą  Dynatrace OneAgent Operator for Kubernetes and OpenShift, który dba o to, aby OneAgent był ładowany do każdej instancji kontenera, bez konieczności jakiejkolwiek dodatkowej konfiguracji. OneAgent Operator to jakby warstwa pośrednicząca między agentem a platformą K8s i serwerem Dynatrace.

Koncepcja OneAgent Operator

Role OneAgent Operatora w monitoringu skonteneryzowanych aplikacji uruchomionych spod Kubernetesa.

OneAgent Operator i OneAgent muszą być zainstalowane wg dokumentacji https://www.dynatrace.com/support/help/cloud-platforms/google-cloud-platform/google-kubernetes-engine/deploy-oneagent-on-google-kubernetes-engine-clusters/. W tym momencie można rozpocząć deployment kontenerów z komponentami aplikacji. Po wrzuceniu obrazów kontenerów i uruchomieniu ich w klastrze Kubernetesa, aplikacja zaczyna działać i dzięki Operatorowi w każdym kontenerze zagnieżdża się OneAgent, który automatycznie wykrywa, co zostało uruchomione we wszystkich kontenerach.

Mój klaster ma trzy hosty, co widać na poniższym obrazku.

Widok listy hostów w Dynatrace.

Od tego momentu, każdy kontener jest widziany na tym samym poziomie szczegółowości, co host w GCE. Aby przekonać się, jak działa platforma konteneryzacji, warto zacząć od dashboardu dla Dockera (Monitor > Docker).

Dashboard Dockera w Dynatrace

Przekrojowy widok jest przydatny do szybkiego wglądu w dynamikę i obciążenie kontenerów. Stąd można przejść do dashboardu dla konkretnego hosta lub parametrów kontenera.

Dashboard hosta uruchomionego w GKE.

Po co mi to było?

Pewnie zadajesz sobie pytanie, po co było grzebać się w GKE, skoro już miałem maszynę z GCE, na której był OneAgent i wszystko pięknie widać w Dynatrace? Przecież klient chciał zobaczyć, co i jak potrafi monitorować Dynatrace. I tu właśnie jest pies pogrzebany.

Klient chciał zobaczyć, co potrafi Dynatrace. Klienci mają to do siebie, że często nie potrafią precyzyjnie sformułować swoich potrzeb. A przy odrobinie doświadczenia, z góry wiadomo, że coś wyglądającego niewinnie na początku, zwykle zamienia się w jakąś wielowątkową hydrę. Tak też było i w tym przypadku. Z dyskusji o funkcjonalności przeszliśmy szybko do administracji i możliwości automatyzacji. Nic tak dobrze nie przekonuje, jak udane demo na żywym organizmie. W tym przypadku, mogłem to zrobić dzięki GCP i Dynatrace.

Które podejście wybrać?

Ponieważ nie ma na to dobrej odpowiedzi, każdy musi sam sobie odpowiedzieć, czy jest w pełnej gotowości wybrać drogę GCE lub GKE. Bez wątpienia, konteneryzacja przez K8s ma wiele zalet, choćby łatwość automatyzowania deploymentu nowych środowisk czy nowych wersji aplikacji. A co za tym idzie, również automatyzacji monitoringu, bo OneAgent zostanie automatycznie uruchomiony jako kontener i zacznie raportować dane do serwera bez konieczności manualnej konfiguracji. Ale podejście GCE nie jest pozbawione możliwości automatyzacji, choć nie jest to tak wygodne. Z drugiej strony, Kubernetes posiada pewien narzut administracyjny w postaci dekompozycji aplikacji na kontenery (przygotowanie obrazów) oraz procedur automatyzacji deploymentu.

Stos punktowych rozwiązań czy platforma monitoringu?

Ciągle panuje przekonanie, że zestaw różnych specjalistycznych narzędzi jest lepszy niż jedna czy dwie zintegrowane ze sobą platformy. Dzieje się tak dlatego, że metodyka agile i nadmierna fragmentacja zespołów w ramach firmy prowadzą do nieskoordynowanego wyboru narzędzi, w tym narzędzi do monitoringu. Każdy zespół to suma innych doświadczeń i kompetencji, a to prowadzi do innych decyzji. Jakkolwiek punktowe narzędzia, np. do monitoringu infrastruktury, systemów operacyjnych, baz danych, logów i całego mnóstwa innych zagadnień mogą być świetne, nie dają holistycznego obrazu monitorowanego środowiska. Dodatkowo, narzut administracyjny i operacyjny stanowią realny koszt, zbyt często pomijany w szacunkach, obniżając produktywność zespołów.

Wybór platformy monitoringu, jaką jest Dynatrace, z możliwością pełnej automatyzacji, wsparciem dla full stack, od infrastruktury do aktywności użytkownika aplikacji, analityką logów i obsługą danych pochodzących z innych źródeł oraz możliwością integracji z innymi platformami, oznacza znakomite uproszczenie monitoringu i podniesienie jego jakości przy jednoczesnym zachowaniu pełnej widoczności w 100% transakcji. Dynatrace jest wiodącym rozwiązaniem AIOps, od lat lokowanym przez Gartnera w kwadrancie liderów dla APM/DPM.

Jeśli chcesz spróbować, jak Dynatrace działa w twoim środowisku, zarejestruj się na darmowy trial pod dynatrace.ai/omnilogy lub skontaktuj się z nami.

Przydatne pojęcia

Application performance monitoring, monitoring wydajności aplikacji – techniki śledzenia i pomiaru parametrów wydajnościowych transakcji (czasy odpowiedzi, poziom błędów, poziom dostępności i skalowalność) wykonywanych po stronie aplikacji. Monitoringu taki odbywa się głównie po stronie serwera (server-side monitoring), ale takie podejście nie zapewnia całościowego wglądu w wydajność i doznania użytkowników aplikacji.

Full stack monitoring – kompleksowe podejście do monitoringu, które uwzględnia wpływ pełnego stosu aplikacji na jej wydajność i odczucia użytkownika końcowego. Pełen stos technologiczny to infrastruktura (centra danych, serwery i peryferia, systemy operacyjne, procesy, sieć), wszystkie technologie i warstwy aplikacji, włącznie z framework-ami wykorzystanymi do jej zbudowania oraz warstwa kliencka (przeglądarka webowa).

Application performance management, Digital performance management – APM/DPM obejmuje nie tylko full stack server-side monitoring, ale również Real user monitoring (RUM), synthetic monitoring, Customer experience monitoring (CXM), User behavior analytics (UBA) i Business performance reporting. DPM jest podstawą skutecznej cyfrowej transformacji.

Artificial intelligence for IT operations (AIOps) – ogólne pojęcie dotyczące wykorzystania of big data analytics, uczenia maszynowego (machine learning, ML)  i innych technik sztucznej inteligencji (artificial intelligence, AI) w celu zautomatyzowanej identyfikacji i rozwiązywania problemów w środowiskach IT.

Materiały źródłowe: Dynatrace, GoogleOmnilogy