Firma e-commerce, z rozproszonym w 7 narzędziach monitoringiem, nie mogła zdiagnozować uporczywych problemów wydajnościowych. Wdrożyliśmy Datadoga na warstwach infrastruktury, APM i sieci, odkrywając 1-sekundowe opóźnienie sieciowe na każdym zapytaniu.
Branża
E-commerce
Lokalizacja
Europa
Czas
9.2025
Średniej wielkości firma e-commerce działająca na Kubernetesie, on-premise, doświadczała uporczywych problemów wydajnościowych widocznych dla użytkowników końcowych. Czasy odpowiedzi wahały się znacząco, od 200ms do ponad 3000ms dla tych samych transakcji a zespół developerski nie mógł wskazać przyczyny.
Monitoring był rozproszony pomiędzy siedmioma oddzielnymi narzędziami bez korelacji danych:
Jednym z kluczowych problemów tego zestawu był agresywny sampling po stronie APM (kluczowe dane wydajnościowe były odrzucane ze względów finansowych), brak instrumentacji frontendu, brak śledzenia end-to-end transakcji od CloudFlare do backendu, oraz brak widoczności pełnych metryk po stronie dostawcy infrastruktury (mała komercyjna serwerownia), co stwarzało ryzyko utraty reszty danych historycznych w przypadku zakończenia współpracy.
Infrastruktura składała się z klastra Kubernetes na Proxmox na 3 serwerach fizycznych w kolokacji, z CloudFlare jako warstwą CDN z terminacją TLS.
Przeprowadziliśmy audyt infrastruktury obejmujący analizę sieciową, konfigurację Kubernetes, wydajność backendu, storage oraz istniejącą architekturę monitoringu. Na podstawie wyników stworzyliśmy raport. Efektem raportu było wdrożenie platformy Datadog jako zunifikowanej platformy observability zawierającej:
Monitoring infrastruktury: Metryki Kubernetes API, wydajność baz danych (SQL i Redis), metryki na poziomie hostów z hypervisora Proxmox oraz monitoring wydajności storage zarówno blokowego (ZFS na LVM) jak i obiektowego (Minio).
APM (Application Performance Monitoring): Zastąpienie Azure Application Insights przez Datadog APM, zapewniające pełne rozproszenie śledzenia aplikacji backendowej bez agresywnego samplingu, który ukrywał problemy wydajnościowe.
Network Observability: Analiza ruchu end-to-end z klastra Kubernetes (on-premise), przez warstwę sieciową hypervisora, load balancer Nginx, aż do CloudFlare. To był kluczowy brakujący element, ponieważ żadne wcześniejsze narzędzie nie obserwowało pełnej ścieżki sieciowej.
Ten projekt demonstruje nasze usługi wdrożenia observability w chmurze zarówno prywatnej jak i publicznej oraz możliwości konsultingu Datadog zastosowane w złożonym środowisku on-premise.
W ciągu kilku godzin od początkowego wdrożenia Datadog zespół uzyskał widoczność, jakiej nigdy wcześniej nie miał. Pierwsze i najistotniejsze odkrycie: ~1000ms opóźnienia sieciowego na każdym pojedynczym requeście pomiędzy kolokacją a CloudFlare. Pełna sekunda czasu tranzytu sieciowego, która była niewidoczna dla wszystkich poprzednich narzędzi monitoringu, ponieważ żadne z nich nie obserwowało tej konkretnej ścieżki.
To odkrycie przeformułowało całą rozmowę o wydajności. Problem nie leżał w kodzie aplikacji, konfiguracji Kubernetes ani zapytaniach do bazy danych. Był to problem routingu sieciowego pomiędzy dostawcą kolokacji a CloudFlare, który mógł być widoczny tylko przy skorelowanej observability end-to-end.
Dodatkowe ustalenia z audytu obejmowały:
Zaangażowanie otworzyło szerszą rozmowę o fundamentalnych ograniczeniach środowiska on-premise dla biznesu e-commerce, który musi szybko skalować się pod kampanie reklamowe. Klient rozpoczął z nami planowanie migracji do AWS z wykorzystaniem programu AWS Migration Acceleration Program (MAP).
Wdrożenie Datadoga zapewniło widoczność infrastuktury i aplikacji end-to-end w ciągu kilku godzin, natychmiast ujawniając problem opóźnienia sieciowego, o ok. 1000ms, niewidoczny dla poprzedniego rozproszonego zestawu narzędzi monitoringujących. Klient rozpoczął planowanie pełnej migracji do chmury AWS.