Datadog Agent zużywa za dużo CPU lub pamięci: jak zdiagnozować i naprawić
Diagnoza i naprawa wysokiego zużycia CPU/pamięci przez Datadog Agent: wyłączenie zbędnych integracji, ograniczenie custom metrics, konfiguracja logów i przejście na Cluster Agent.
Jeśli planujesz migrację do Datadog z innej platformy, zobacz nasz przewodnik po migracji do Datadog. Jeśli potrzebujesz pomocy z konfiguracją i optymalizacją Datadog, zobacz naszą usługę Datadog consulting.
Objaw
Agent zużywa znacząco więcej zasobów niż jego zdefinowane parametry:
# Sprawdź zużycie zasobów przez agenta
# Na Linux:
top -p $(pgrep -f "datadog-agent run")
# Na Kubernetes (DaemonSet):
kubectl top pods -n datadog -l app=datadog-agent
# Oczekiwane wartości (typowy host z 10-15 integracji):
# CPU: 0.5-2% (single core)
# RAM: 150-300 MB
# Jeśli widzisz >5% CPU lub >500 MB RAM - masz problem
Sprawdź status agenta, aby zobaczyć co jest uruchomione:
# Status agenta ze szczegółami integracji
sudo datadog-agent status
# Sprawdź ile integracji jest aktywnych
sudo datadog-agent status | grep -c "Instance ID"
# Sprawdź ile custom metrics jest raportowanych
sudo datadog-agent status | grep "Total number of custom metrics"
Przyczyna
Pięć najczęstszych powodów wysokiego zużycia zasobów:
1. Za dużo aktywnych integracji
Każda integracja (check) uruchamia się co 15-30 sekund. Przy 30+ integracji na jednym hoście, Agent spędza znaczną część czasu na odpytywaniu usług.
2. Metryki o wysokiej kardynalności (DogStatsD) (DogStatsD)
Aplikacja wysyła metryki z dynamicznymi tagami (np. user_id, request_id, session_token). Każda unikalna kombinacja metric name + tagi to osobna seria czasowa, którą Agent musi buforować i wysyłać.
3. Śledzenie dużych plików logów
Agent śledzi logi z pliku o wysokim throughput (>1000 linii/s). Parsowanie i wysyłanie każdej linii wymaga CPU.
4. Monitorowanie procesów z pełnymi argumentami
process_config.enabled: true z process_config.scrub_args: false zbiera pełne argumenty każdego procesu. Na hoście z setkami procesów to znaczne obciążenie.
5. APM z dużą liczbą traces (śladów)
Agent zbiera i przetwarza ślady (traces) z wielu usług na jednym hoście. Przy >1000 spans/s agent potrzebuje więcej zasobów na sampling i agregację.
Naprawa
A) Zidentyfikuj co zużywa zasoby
# Profil zużycia per integracja
sudo datadog-agent diagnose show-metadata agent-checks
# Sprawdź czas wykonania każdego check
sudo datadog-agent status | grep -A2 "Last Execution"
# Na Kubernetes - sprawdź logi agenta pod kątem wolnych operacji
kubectl logs -n datadog -l app=datadog-agent --tail=100 | grep -i "slow\|timeout\|warning"
B) Wyłącz zbędne integracje
# /etc/datadog-agent/conf.d/ - usuń lub przenieś pliki .yaml integracji
# których nie potrzebujesz
# Typowe zbędne integracje na serwerach aplikacyjnych:
# - disk (domyślnie włączony, często niepotrzebny na kontenerach)
# - network (domyślnie włączony, rozważ wyłączenie na krótkotrwałych kontenerach)
# - ntp (rzadko potrzebny gdy host ma chronyd)
# Wyłącz integrację bez usuwania pliku:
# Zmień nazwę: mv conf.d/ntp.d/conf.yaml conf.d/ntp.d/conf.yaml.disabled
C) Ogranicz custom metrics (DogStatsD)
# /etc/datadog-agent/datadog.yaml
# Ogranicz liczbę unikalnych tagów per metryka
dogstatsd_mapper_profiles:
- name: reduce_cardinality
prefix: "app."
mappings:
- match: "app.request.*"
name: "app.request"
tags:
endpoint: "$1"
# NIE dodawaj user_id, session_id itp.
# Alternatywnie - ustaw hard limit
dogstatsd_metrics_stats_enable: true
# Monitoruj w Datadog: datadog.dogstatsd.metrics.unique_metrics
W kodzie aplikacji - nigdy nie używaj dynamicznych wartości (user ID, timestamp, UUID) jako tagów:
# ZLE - tworzy miliony unikalnych serii czasowych
statsd.increment('api.request', tags=[f'user:{user_id}'])
# DOBRZE - ograniczona kardynalność
statsd.increment('api.request', tags=[f'endpoint:{endpoint}', f'status:{status_code}'])
D) Zoptymalizuj zbieranie logów
# /etc/datadog-agent/conf.d/app_logs.d/conf.yaml
logs:
- type: file
path: /var/log/app/production.log
service: my-app
source: python
# Ogranicz throughput
# Maksymalna liczba linii na sekundę z tego pliku
# (domyślnie: brak limitu)
# processing_rules:
# - type: throttle
# limit: 500 # max 500 linii/s
# Wyklucz niepotrzebne linie (health checks, debug)
processing_rules:
- type: exclude_at_match
name: exclude_health_checks
pattern: "GET /health"
- type: exclude_at_match
name: exclude_debug
pattern: "DEBUG"
E) Przejdź na Cluster Agent (Kubernetes)
Na Kubernetes z >10 nodów, Cluster Agent centralizuje operacje, które nie muszą być per-node:
# values.yaml (Helm chart datadog/datadog)
clusterAgent:
enabled: true
replicas: 2
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
agents:
# Zmniejsz zasoby per-node agenta po włączeniu Cluster Agent
containers:
agent:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 300m
memory: 512Mi
F) Ustaw limity zasobów (Kubernetes)
# Zapobiegaj sytuacji "agent zjada zasoby aplikacji"
# DaemonSet spec:
containers:
- name: agent
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m # Agent będzie ograniczany powyżej tego
memory: 512Mi # Agent zostanie OOMKilled powyżej tego
Weryfikacja
# Po zmianach - restart agenta
sudo systemctl restart datadog-agent
# Poczekaj 2-3 minuty, sprawdź nowe zużycie
top -p $(pgrep -f "datadog-agent run") -n 3 -b
# Sprawdź czy dane nadal płyną do Datadog
sudo datadog-agent status | grep "Running Checks"
sudo datadog-agent status | grep "Total Metrics"
# Na Kubernetes
kubectl top pods -n datadog -l app=datadog-agent
Jeśli CPU spadło poniżej 5% i RAM poniżej 400 MB, problem rozwiązany. Monitoruj metrykę datadog.agent.running i system.cpu.user z filtrem process:datadog-agent w Datadog, aby wyłapać regresje.
Datadog zużywa za dużo zasobów?
Umów bezpłatną 30-minutową rozmowę. Przejrzymy konfigurację agenta i zoptymalizujemy zużycie zasobów.