Skip to main content
This guide explains how to tailor your Datadog Agent configuration before deploying it. It focuses on Agent-level optimizations for collection, shipment, filtering, masking, and cost control. Platform-specific deployment details (Kubernetes, Docker, cloud providers) are out of scope, but these Agent-centric best practices apply across environments. Objectives:
  • Reduce unnecessary ingestion and storage costs.
  • Prevent sensitive data from being sent to Datadog.
  • Keep metric cardinality in check.
  • Make collection rules explicit and auditable.

​
High-level goals

  • Reduce log volume and exclude or mask sensitive data before ingestion.
  • Limit metric collection and manage cardinality to control costs.
  • Configure an appropriate Agent log level so the Agent does not create excess logs.
  • Make collection, filters, and tags explicit so you collect only what you need.
Start with conservative collection rules. Enable additional sources, higher verbosity, or broader scraping only when you need them for troubleshooting. Incrementally expand data collection after validating cost and usefulness.

​
Agent-level settings

Set basic Agent options in datadog.yaml so behavior is explicit and predictable. Example (datadog.yaml): 
# datadog.yaml
logs_enabled: true
log_level: INFO
Key settings:
  • logs_enabled: enable or disable the Agent’s log collection.
  • log_level: recommended INFO for production; use DEBUG only for short-lived troubleshooting.
Tip: Manage Agent config changes via your configuration management (Git, CI/CD) and document why any non-default settings are used.

​
Log collection, filtering, and masking

Collect only the logs you need and apply processing as close to the source as possible. The Agent supports local processing rules, and Datadog provides server-side log pipelines and dedicated masking/redaction processors—prefer server-side when possible. Best practices:
  • Scope file paths and services narrowly (avoid wildcards that capture unrelated logs).
  • Exclude noisy endpoints (health checks, probes) before ingestion.
  • Mask or redact PII and secrets as early as possible, ideally in a controlled pipeline.
  • Test any regex-based exclusions or redactions in staging to avoid losing important data.
Example per-integration Agent log configuration (conf.d/<integration>.d/conf.yaml): 
# conf.d/myapp.d/conf.yaml
logs:
  - type: file
    path: /var/log/myapp/*.log
    service: myapp
    source: myapp
    tags:
      - env:prod
    log_processing_rules:
      - type: exclude_at_match
        name: exclude_healthchecks
        pattern: '^(GET|HEAD) /health'
      - type: multi_line
        name: new_log_start_with_date
        pattern: '^\d{4}-\d{2}-\d{2}'
Notes:
  • exclude_at_match prevents known noisy lines from being forwarded.
  • multi_line preserves stack traces and multiline exceptions.
  • Verify that the Agent version you use supports the processors you plan to run locally. See the Agent logs documentation for supported processors and syntax.
Avoid broad regex-based exclusions or redactions that can remove useful diagnostic data. Always validate processing rules in a staging environment and review their effects on a representative sample of logs.

​
Metrics scraping and cardinality control

Unrestricted metric collection and high-cardinality tags are common drivers of cost. Apply strict controls on which metrics and tags are collected. Recommendations:
  • Enable only the integrations and checks you actively use.
  • Avoid high-cardinality tags (unique IDs, user IDs, request IDs).
  • Normalize tags to coarse-grained values such as region, role, or service.
  • Use allowlists/deny-lists (where supported) to limit scraped metrics.
Example (Prometheus-style integration): 
# conf.d/prometheus.d/conf.yaml (example)
instances:
  - prometheus_url: http://localhost:9100/metrics
    namespace: node
    # If supported by the check, prefer white-listing metrics:
    # metrics: ['node_cpu_seconds_total', 'node_memory_MemAvailable_bytes']
    tags:
      - env:prod
      - role:web
Do / Don’t summary:
ActionRecommended
Add instance-id or request-id as a metric tagDon’t — high cardinality
Use region, service, role tagsDo — low cardinality and useful for aggregation
Collect every Prometheus metric by defaultDon’t — use a whitelist where possible
Aggregate or roll up metrics at source if feasibleDo — reduces downstream cardinality and cost
Periodic housekeeping:
  • Review your metric catalog regularly and delete unused or noisy metrics.
  • Use metric roll-ups or aggregates when raw metrics are not required for troubleshooting.

​
Debugging and troubleshooting

When investigating issues, temporarily increase verbosity and enable additional integrations. Always revert these changes. Temporary debug example: 
# datadog.yaml (temporary change)
log_level: DEBUG
Guidelines:
  • Restrict DEBUG to a short troubleshooting window.
  • For logs, enable only the integration(s) generating the data you need.
  • Revert settings and remove any temporary tag or metrics changes immediately after resolving the incident.

​
Cost optimization checklist

Use this checklist to validate your configuration before wide deployment.
CategoryAction
LogsDisable collection for unused services, scope file paths, and exclude noisy endpoints
PrivacyMask/redact PII and secrets in pipelines or at the Agent if necessary
MetricsRemove high-cardinality tags and whitelist important metrics
RetentionConfigure indexing and retention policies to limit long-term storage
AuditPeriodically review integration configs, dashboards, and alerts for stale data

​
Final notes

Make all filters and rules explicit, incremental, and reversible. Conservative collection combined with deliberate, documented exceptions delivers observability that is more actionable, secure, and cost-effective. That’s a concise overview of Agent-level tuning for efficient Datadog usage. Implement these steps iteratively and validate their effects on both observability and billing before rolling them out broadly.

Watch Video