Migracja z Nagios, Zabbix lub CloudWatch do Datadog - praktyczny przewodnik

Migracja do Datadog z Nagios, Zabbix i CloudWatch

Migracja monitoringu to nie tylko podmiana narzędzia. To zmiana sposobu myślenia o observability - od reagowania na awarie do proaktywnego monitorowania zdrowia całego systemu. Dobrze przeprowadzona daje zespołom jeden punkt prawdy (single pane of glass), niższy MTTR i mniej fałszywych alarmów.

Jeśli szukasz ogólnej analizy kosztów narzędzi monitoringu, zobacz nasz artykuł o rosnących kosztach observability.

Kiedy migracja do Datadog ma sens

Nie każda organizacja potrzebuje Datadog. To premium narzędzie z ceną premium. Migracja jest uzasadniona gdy:

• Masz 3+ narzędzi monitoringu - Nagios do infrastructure, Grafana do metryk, ELK do logów, osobne APM. Konsolidacja eliminuje duplikację i obniża koszt licencji (choć Datadog sam w sobie nie jest tani).
• Alert fatigue zabija reakcję na incydenty - Nagios generuje setki alertów dziennie, z czego 90% to false positive. Zespół ignoruje alerty.
• Brakuje korelacji między warstwami - widzisz że CPU jest na 90%, ale nie wiesz która usługa, który request, który deployment spowodował skok.
• Skalujesz infrastrukturę - Nagios/Zabbix z ręczną konfiguracją hostów nie nadąża za autoscalingiem i kontenerami.
• Potrzebujesz APM - distributed tracing to natywna funkcja Datadog. Dobudowywanie go do Nagios/Zabbix to ogromny wysiłek.

Kiedy NIE migrować

• Masz 5-10 serwerów i prosty stack - Nagios/Zabbix wystarczy
• Budżet na monitoring to <500 EUR/mies - Datadog będzie droższy niż obecne rozwiązanie
• Zespół nie ma czasu na naukę nowej platformy w ciągu najbliższych 2-3 miesięcy
• Compliance wymaga on-premise monitoringu bez SaaS (rzadko, ale się zdarza)

Mapowanie: stare narzędzie na Datadog

Nagios na Datadog

Kluczowa różnica: Nagios operuje na sztywnej hierarchii host > service > check. Datadog operuje na tagach - jeden host może mieć 50 tagów i pojawiać się w dowolnym kontekście. To wymaga zmiany myślenia przy projektowaniu paneli i alertów.

Zabbix na Datadog

Kluczowa różnica: Zabbix to narzędzie do monitoringu infrastruktury. Datadog to platforma observability obejmująca infrastructure, APM, logs, synthetics, security i więcej. Migracja z Zabbix to nie podmiana 1:1 - to skok na wyższy poziom widoczności (i kosztów).

CloudWatch na Datadog

Kluczowa różnica: CloudWatch monitoruje AWS. Datadog monitoruje wszystko - AWS, GCP, Azure, on-prem, Kubernetes, custom apps. Jeśli masz wyłącznie AWS i nie planujesz architektury multi-cloud, CloudWatch + X-Ray może wystarczyć. Migracja ma sens gdy chcesz mieć ”single pane of glass” dla heterogenicznego środowiska lub potrzebujesz lepszego APM niż X-Ray.

Plan migracji - 4 fazy

Faza 1: Inwentaryzacja (2-3 dni)

Co monitorujesz dziś i dlaczego:

# Nagios - eksport aktywnych checks
nagiostats -m -d NUMSVCOK,NUMSVCCRIT,NUMSVCWARN,NUMHSTUP,NUMHSTDOWN
cat /etc/nagios/objects/*.cfg | grep "define service" | wc -l

# Zabbix - eksport aktywnych items i triggers
zabbix_server -R config_cache_reload
mysql -u zabbix -p zabbix -e "SELECT COUNT(*) FROM items WHERE status=0;"
mysql -u zabbix -p zabbix -e "SELECT COUNT(*) FROM triggers WHERE status=0;"

# CloudWatch - lista aktywnych alarmów
aws cloudwatch describe-alarms --state-value OK --query 'MetricAlarms[].AlarmName' | wc -l
aws cloudwatch describe-alarms --state-value ALARM --query 'MetricAlarms[].AlarmName'

Dokumentuj:

• Ile hostów/usług jest monitorowanych
• Ile alertów jest aktywnych (i ile z nich ktokolwiek czyta)
• Jakie panele są używane (nie stworzone - używane)
• Kto otrzymuje alerty i jak reaguje
• Jakie integracje/pluginy są krytyczne

Faza 2: Konfiguracja Datadog w trybie równoległym (1 tydzień)

Cel: Datadog zbiera dane obok starego narzędzia. Nic nie wyłączamy.

1. Zainstaluj Datadog Agent na wszystkich hostach (Ansible playbook lub DaemonSet w K8s)
2. Włącz integracje AWS - Datadog automatycznie pobiera metryki CloudWatch
3. Skonfiguruj podstawowe tagi - env:production, team:platform, service:api
4. Odtwórz krytyczne alerty (nie wszystkie - tylko te, na które reagujecie)
5. Zbuduj 2-3 panele - repliki tych, które zespół faktycznie otwiera

# Przykład: Ansible role do instalacji Datadog Agent
- name: Install Datadog Agent
  hosts: all
  roles:
    - role: datadog.datadog
      vars:
        datadog_api_key: ""
        datadog_agent_major_version: 7
        datadog_config:
          tags:
            - "env:"
            - "team:"
            - "service:"
          logs_enabled: true
          process_config:
            enabled: true
        datadog_checks:
          http_check:
            instances:
              - name: "-health"
                url: "http://localhost:/health"
                timeout: 5

Faza 3: Walidacja i tuning (1 tydzień)

• Porównaj metryki z obu źródeł - czy Datadog widzi to samo co stary system?
• Testuj alerty - wywołaj sztuczny incydent i sprawdź czy Datadog reaguje poprawnie
• Zbierz feedback od zespołu - czy panele odpowiadają na ich pytania?
• Dostosuj thresholdy - Datadog ma anomaly detection, wykorzystaj go zamiast statycznych progów
• Skonfiguruj APM tracing (jeśli potrzebne) - instrumentacja kodu

Faza 4: Przełączenie i decommission (3-5 dni)

1. Ogłoś zespołowi: „Od poniedziałku źródłem prawdy jest Datadog”
2. Przekieruj on-call notifications z Nagios/Zabbix na Datadog monitors
3. Wyłącz alerty w starym systemie (ale zostaw zbieranie metryk jeszcze 2 tygodnie)
4. Po 2 tygodniach bez incydentu - wyłącz stary system całkowicie
5. Usuń agenty Nagios/Zabbix z hostów

Nie wyłączaj starego systemu od razu. Przez 2 tygodnie trzymaj go w trybie read-only jako backup. Jeśli Datadog coś pominie, masz gdzie sprawdzić.

Typowe błędy przy migracji

1. Przenoszenie wszystkich alertów 1:1

Nagios z 500 checks generuje 500 monitorów w Datadog. Efekt: te same false positives co wcześniej, tylko droższa platforma.

Prawidłowe podejście: Przenieś tylko alerty, na które ktokolwiek reagował w ciągu ostatnich 3 miesięcy. Resztę wyrzuć. Migracja to szansa na cleanup.

2. Ignorowanie tag strategy

Tagi to fundament Datadog. Bez spójnej konwencji tagowania tracisz 80% wartości platformy - nie możesz filtrować paneli, budować scope monitorów ani przypisywać kosztów.

Minimum: env, service, team. Opcjonalnie: version, region, tier.

3. Eksplozja custom metrics

Każda unikalna kombinacja metric name + tag values = osobna custom metric = osobna opłata. Zespoły przyzwyczajone do Prometheus (gdzie metryki są darmowe) generują tysiące custom metrics w Datadog i dostają rachunek 3x wyższy niż planowali. To powoduje również problemy wydajnościowe samego agenta. Jeśli Datadog Agent zaczyna zużywać za dużo CPU lub pamięci, zobacz nasz runbook o wysokim zużyciu zasobów przez agenta Datadog.

Prawidłowe podejście: Zdefiniuj budżet custom metrics z góry. Używaj exclusion filters. Monitoruj usage w Datadog → Plan & Usage.

4. Brak cutover date

„Działamy równolegle dopóki nie będziemy gotowi” = nigdy się nie przełączycie. Ustal datę, ogłoś ją, i trzymaj się jej.

5. Migracja bez APM

Jeśli już płacisz za Datadog, nie wykorzystanie APM to jak kupno Tesli i jeżdżenie tylko na parkingu. Distributed tracing zmienia jakość debugowania - od „CPU jest wysoki” do „ten konkretny endpoint w tym serwisie tworzy N+1 query do bazy”.

Porównanie kosztów: Nagios/Zabbix vs Datadog

Uczciwie: Datadog jest droższy na poziomie licencji. Oszczędność pojawia się w: krótszym MTTR (mniej przestojów), mniej czasu inżynierów na utrzymanie monitoringu, konsolidacji narzędzi (koniec z opłatami za ELK + Grafana + PagerDuty osobno), i lepszej widoczności prowadzącej do szybszych decyzji architektonicznych.

Dla firmy z 20 hostami i jednym inżynierem - Nagios wystarczy. Dla firmy ze 100+ hostami, mikrousługami i zespołem 10+ - Datadog się zwraca w ciągu kwartału przez redukcję czasu na debugging i utrzymanie.

Timeline podsumowanie

Dla środowisk Kubernetes czas może być krótszy (DaemonSet = jedna komenda), dla dużych środowisk bare-metal z setkami ręcznych checks Nagios - dłuższy.

Jak możemy pomóc

Realizujemy migracje do Datadog od etapu audytu obecnego monitoringu, przez konfigurację agentów i integracji, po budowę paneli operacyjnych i przekazanie wiedzy zespołowi.

Typowy zakres:

• Audyt obecnego monitoringu (co działa, co jest martwe, co generuje szum)
• Projekt tag strategy i konwencji nazewniczej
• Instalacja i konfiguracja Datadog Agent (Ansible/Terraform/Helm)
• Odtworzenie krytycznych alertów jako Datadog Monitors
• Budowa paneli operacyjnych dla zespołu
• Konfiguracja APM tracing (instrumentacja aplikacji)
• Optymalizacja kosztów Datadog (exclusion filters, budżet custom metrics)
• Szkolenie zespołu i transfer wiedzy

Planujesz migrację monitoringu?

Umów bezpłatną 30-minutową rozmowę. Omówimy Twoje obecne narzędzia i przygotujemy plan przejścia na Datadog.

Umów rozmowę