Datadog Integration

MTE Relay v5 emits structured JSON logs (see the Event Schema Reference). Datadog parses them automatically, with no custom parsing rules. This guide ships logs to Datadog, installs the log pipeline, declares facets and measures, and imports the prebuilt dashboard and monitors.

Artifacts

File	Purpose
mte-relay-v5-dashboard.json	Importable dashboard (traffic, latency, phase breakdown, security, errors)
mte-relay-v5-monitors.json	Five recommended monitors (security, panics, state store, latency, pair loss)
mte-relay-v5-log-pipeline.json	Log pipeline (status/date/service/message remappers)

1. Ship the logs

MTE Relay writes one JSON object per line: operational logs on stderr and structured events on stdout. Collect both streams, which container log collection does by default, and keep USE_CONSOLE_LOGS=false (the default) wherever Datadog ingests logs. The relay does not set a service name itself, so the examples below tag the logs with service: mte-relay, which the pipeline, dashboard, and monitors filter on. Pick the path that matches your deployment:

Docker (Datadog Agent)

Run the Agent with log collection enabled and label the relay container:

# docker-compose excerpt
services:
  mte-relay:
    image: 321186633847.dkr.ecr.us-east-1.amazonaws.com/customer/on-prem/mte-relay-server:5.0.5
    labels:
      com.datadoghq.ad.logs: '[{"source": "mte-relay", "service": "mte-relay"}]'
  datadog-agent:
    image: gcr.io/datadoghq/agent:7
    environment:
      - DD_API_KEY=<YOUR_API_KEY>
      - DD_LOGS_ENABLED=true
      - DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=false
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Kubernetes / AKS (Datadog Agent DaemonSet)

Install the Agent with the Helm chart (datadog.logs.enabled=true) and annotate the relay pods. The annotation key names the container, so use ad.datadoghq.com/<container name>.logs, for example mte-relay-server for the on premise manifest:

metadata:
  annotations:
    ad.datadoghq.com/mte-relay-server.logs: '[{"source": "mte-relay", "service": "mte-relay"}]'

ECS Fargate (FireLens)

Add a FireLens log router to the task definition and point it at Datadog:

"logConfiguration": {
  "logDriver": "awsfirelens",
  "options": {
    "Name": "datadog",
    "apikey": "<YOUR_API_KEY>",
    "dd_service": "mte-relay",
    "dd_source": "mte-relay",
    "provider": "ecs"
  }
}

Logs already in CloudWatch

If the relay already logs to CloudWatch (ECS awslogs driver), deploy the Datadog Forwarder Lambda and subscribe it to the relay log group. No changes to the relay task are needed.

2. Install the log pipeline

The pipeline maps zerolog's fields onto Datadog's reserved attributes: level to status, time to timestamp, and message. Its service and correlation_id remappers look for top level attributes the relay does not emit; the service comes from your agent configuration, and the correlation id sits inside each event object and as correlationId on operational lines.

Via API:

curl -X POST "https://api.datadoghq.com/api/v1/logs/config/pipelines" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \
  -H "Content-Type: application/json" \
  -d @mte-relay-v5-log-pipeline.json

Or recreate it in the UI (Logs → Pipelines → New Pipeline, filter service:mte-relay) with the processors listed in the JSON file.

3. Declare facets and measures

Log-based dashboards aggregate over measures (numeric) and group by facets (string). Create these once in Logs → Explorer (click a value in a matching log → Create facet/measure), or via the facets API:

Path	Type
@correlationId	Facet
@performance_event.event_type	Facet
@performance_event.status_code	Facet
@performance_event.total_time_ms	Measure
@performance_event.decryption_ms	Measure
@performance_event.validation_ms	Measure
@performance_event.proxy_ms	Measure
@performance_event.encryption_ms	Measure
@performance_event.encrypted_data_bytes	Measure
@performance_event.decrypted_data_bytes	Measure
@security_event.event_type	Facet
@security_event.severity	Facet
@security_event.origin	Facet
@encryption_event.event_type	Facet
@encryption_event.mte_type	Facet
@encryption_event.data_size_bytes	Measure
@error_event.event_type	Facet

4. Import the dashboard

In Datadog, create a new dashboard, open its settings, choose Import dashboard JSON, and paste mte-relay-v5-dashboard.json. The dashboard's product and instance template variables filter on @product and @instance, which the relay does not emit. Add those attributes in your log shipper if you want the filters, or leave them at *. The MTE encode/decode time widget charts encryption_event timing fields that the relay does not emit, so it stays empty; the Phase breakdown widget shows the same timings from phase_breakdown events.

5. Create the monitors

Each element of mte-relay-v5-monitors.json is one monitor definition. Create them via API (replace @your-team-handle in the messages first):

jq -c '.[]' mte-relay-v5-monitors.json | while read -r monitor; do
  curl -X POST "https://api.datadoghq.com/api/v1/monitor" \
    -H "DD-API-KEY: ${DD_API_KEY}" \
    -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \
    -H "Content-Type: application/json" \
    -d "$monitor"
done

Included monitors:

Monitor	Fires when
High/critical security event	Any high/critical security_event in 5 min
Handler panic recovered	Any error_event.event_type:panic in 5 min
Pair state missing or not restored	> 5 pair_not_found/state_restore_failed in 10 min
Elevated request latency	Avg total_time_ms > 500 ms over 10 min (tune)
Client pair exhaustion spike	> 50 client_pairs_exhausted in 15 min (tune)

Cost control

Per request performance events dominate volume, and the relay emits them for every request. To reduce cost, add an exclusion filter or sampling for @performance_event.event_type:request_timing in your Datadog log index, and keep security, error, and audit events.