Datadog observability monitoring migracja

Datadog Agent: brak metryk po migracji z Nagios/Zabbix/CloudWatch

Naprawa braku metryk w Datadog Agent po migracji z Nagios/Zabbix/CloudWatch: diagnoza statusu agenta, klucza API i regionu (site), łączności do intake, włączenia integracji i niespójnych tagów.

Jerzy Kopaczewski · 2026-09-13

Migracja monitoringu do Datadog jest w toku, agent zainstalowany na hostach, ale w Datadog nie widać danych - host się nie pojawia, integracja (np. Postgres, Nginx) nie zbiera metryk, albo dane są, lecz z niespójnymi tagami, przez co dashboardy i alerty są puste. W trakcie równoległej pracy obu systemów (parallel-run) to jeszcze nie awaria, ale bez tego nie możesz wyłączyć starego systemu. Ten runbook pokazuje, jak zdiagnozować i naprawić brak metryk.

Ten runbook opisuje brak metryk w Datadog Agent po migracji z Nagios, Zabbix lub CloudWatch. Jeśli agent raportuje, ale zżera CPU/pamięć, zobacz runbook Datadog Agent: wysokie zużycie CPU i pamięć. Pełny przewodnik po migracji: Migracja do Datadog z Nagios, Zabbix i CloudWatch. W kwestii architektury observability umów konsultację.

Objaw

Agent działa jako usługa, ale w Datadog brakuje hosta, metryk lub integracji. Typowe sygnały:

# Ogolny status agenta - sekcje Forwarder, API Keys, Collector
sudo datadog-agent status | sed -n '1,60p'

# Typowe sygnaly problemu:
#   "API Key is invalid" / "403 Forbidden"        -> zly klucz API lub zly site (region)
#   "Forwarder ... Errors: N" / "Transactions dropped"  -> lacznosc do intake
#   integracja w sekcji "Checks" nieobecna lub "Instances: 0"  -> integracja niewlaczona
#   host widoczny, ale metryki bez oczekiwanych tagow  -> niespojne tagi

# Czy agent w ogole dostarcza dane do intake
sudo datadog-agent status | grep -A5 "Forwarder"

# Test lacznosci do endpointu intake (site zalezny!)
curl -v "https://api.datadoghq.eu/api/v1/validate" \
  -H "DD-API-KEY: ${DD_API_KEY}" 2>&1 | tail -5
# Uwaga: datadoghq.eu (EU) vs datadoghq.com (US) - zly site = 403 mimo poprawnego klucza

Host nie pojawia się w Datadog, integracja nie raportuje (Instances: 0), forwarder zgłasza błędy, albo dane docierają z tagami niezgodnymi z tymi, na których oparto dashboardy migrowane ze starego systemu.

Przyczyna

Brak metryk w Datadog po migracji ma zwykle jedną z czterech przyczyn:

Zły klucz API lub zły site (region): klucz z innej organizacji, literówka, albo agent skonfigurowany na datadoghq.com (US), podczas gdy konto jest w regionie EU (datadoghq.eu). Skutek: 403 Forbidden przy walidacji i zero danych - najczęstszy błąd zaraz po instalacji.
Zablokowana łączność do intake: firewall/proxy on-prem blokuje ruch wychodzący na 443 do endpointów *-app.agent.datadoghq.eu/.com. Agent zbiera metryki lokalnie, ale forwarder ich nie dostarcza (transactions dropped).
Integracja nie włączona lub błędna konfiguracja check: sam agent nie zbiera metryk aplikacyjnych - trzeba włączyć integrację (conf.d/<integracja>.d/conf.yaml). Po migracji z Zabbix/Nagios zespół instaluje agenta, ale zapomina odwzorować checki na integracje Datadog - stąd Instances: 0.
Niespójne tagi (host/env/service): dashboardy i monitory migrowane ze starego systemu filtrują po tagach (env, service, host), a agent wysyła dane bez nich lub z innymi wartościami. Dane są w Datadog, ale widoki i alerty nic nie pokazują - typowe przy równoległej pracy na mieszanej flocie.

Rozwiązanie

A) Zweryfikuj klucz API i site (region) - pierwszy krok zawsze:

# Sprawdz, na jaki site kieruje agent i czy klucz jest wazny
sudo grep -E '^site:|^api_key:' /etc/datadog-agent/datadog.yaml
# Dla konta EU musi byc:  site: datadoghq.eu

# Waliduj klucz przeciwko wlasciwemu site
curl -s "https://api.datadoghq.eu/api/v1/validate" \
  -H "DD-API-KEY: ${DD_API_KEY}" | grep -q '"valid":true' && echo OK || echo FAIL
# FAIL -> zly klucz lub zly site. Popraw datadog.yaml i zrestartuj agenta:
sudo systemctl restart datadog-agent

B) Łączność do intake - odblokuj ruch wychodzący:

# Sekcja Forwarder w statusie: czy sa dropniete transakcje
sudo datadog-agent status | grep -A8 "Forwarder"

# Wymagana lacznosc wychodzaca 443 do (dla EU) m.in.:
#   *-app.agent.datadoghq.eu, api.datadoghq.eu, orch.datadoghq.eu
nc -vz api.datadoghq.eu 443

# Jesli ruch idzie przez proxy - skonfiguruj proxy w datadog.yaml:
# proxy:
#   https: "http://proxy.firma.local:3128"
sudo systemctl restart datadog-agent

C) Włącz integrację i zweryfikuj check:

# Przyklad: integracja PostgreSQL - utworz konfiguracje z szablonu
sudo cp /etc/datadog-agent/conf.d/postgres.d/conf.yaml.example \
        /etc/datadog-agent/conf.d/postgres.d/conf.yaml
# Uzupelnij host/port/uzytkownika monitorujacego, potem zrestartuj agenta
sudo systemctl restart datadog-agent

# Sprawdz, ze check zbiera metryki (Instances > 0, Metrics > 0)
sudo datadog-agent check postgres | grep -E "Instances|Metrics|Errors"
# Oczekiwane: Instances: 1, Metrics: >0, Errors: 0

D) Ujednolić tagi (host/env/service), na których oparto dashboardy:

# Ustaw tagi globalne w datadog.yaml, spojne z migrowanymi dashboardami/monitorami
# tags:
#   - env:prod
#   - team:platform
# Dla metryk aplikacyjnych ustaw service/env w konfiguracji integracji lub przez autodiscovery.

# Zweryfikuj tagi hosta po restarcie
sudo datadog-agent status | grep -A10 "Host Info"
# Upewnij sie, ze klucze tagow (env, service) zgadzaja sie co do nazwy i wartosci
# z filtrami w migrowanych dashboardach - inaczej widoki pozostana puste.

Prewencja: ustal jedną konwencję tagów (env, service, team) przed migracją i wdroż ją przez konfigurację agenta lub autodiscovery, żeby migrowane dashboardy działały od razu. W trakcie równoległej pracy trzymaj stary system jako źródło prawdy do momentu, aż Datadog raportuje komplet hostów i integracji z poprawnymi tagami. Skonfiguruj monitor „brak danych” (no-data) na kluczowych metrykach, żeby wychwycić milczące hosty zanim wyłączysz stary monitoring.

Walidacja

# 1. Status agenta bez bledow klucza i forwardera
sudo datadog-agent status | grep -E "API Keys|Forwarder" -A3
# Oczekiwane: klucz "valid", brak dropnietych transakcji

# 2. Host raportuje i jest widoczny (walidacja klucza przeciwko wlasciwemu site)
curl -s "https://api.datadoghq.eu/api/v1/validate" -H "DD-API-KEY: ${DD_API_KEY}"
# Oczekiwane: {"valid":true}

# 3. Kazda wymagana integracja zbiera metryki
for c in postgres nginx disk; do
  echo "== $c =="; sudo datadog-agent check $c | grep -E "Instances|Metrics|Errors"
done
# Oczekiwane: Instances > 0, Metrics > 0, Errors: 0 dla kazdej integracji

# 4. Tagi zgodne z dashboardami (env/service obecne)
sudo datadog-agent status | grep -A10 "Host Info" | grep -E "env:|service:"
# Oczekiwane: tagi obecne i zgodne z filtrami migrowanych dashboardow

Jeśli agent ma ważny klucz, forwarder nie gubi transakcji, wymagane integracje zbierają metryki, a tagi zgadzają się z dashboardami - migrację monitoringu dla danego hosta można uznać za potwierdzoną. Dopiero po potwierdzeniu kompletu hostów i integracji wyłączaj stary system.

Brak metryk w Datadog podczas migracji nie zwala produkcji od razu - ale usypia czujność. Jeśli wyłączysz Nagios czy Zabbix, zanim Datadog realnie zbiera komplet danych z poprawnymi tagami, tracisz widoczność w momencie, gdy najbardziej jej potrzebujesz: alerty nie odpalają, bo monitor filtruje po tagu, którego agent nie wysyła. Dlatego przełączenie monitoringu robi się dopiero po walidacji kompletu hostów i integracji, utrzymując stary system jako siatkę bezpieczeństwa.

Datadog nie zbiera metryk po migracji?

Umów bezpłatną 30-minutową rozmowę. Przejrzymy konfigurację agentów, integracje i konwencję tagów, i doprowadzimy migrację monitoringu do czystego przełączenia.

Umów rozmowę