Datadog

SocketX ships JSON logs to stdout/stderr, which Datadog parses into attributes automatically. The ready-made dashboard and monitors work with both v1 and v2 servers — every query matches on the stable log message text, not on v2-only fields.

Downloads

• SocketX Datadog Dashboard
• SocketX Datadog Monitors

1. Ship the logs

Keep USE_CONSOLE_LOGS=false (the default) in production — console mode is human-readable but not machine-parseable. Then pick your deployment:

Docker / on-premise

Run the Datadog Agent with log collection enabled (DD_LOGS_ENABLED=true, DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true) and label the SocketX container so logs are tagged correctly:

# docker-compose example
services:
  socketx:
    image: <your-socketx-image>
    labels:
      com.datadoghq.ad.logs: '[{"source": "go", "service": "socketx-server"}]'

AWS (ECS / CloudWatch)

Two options, in order of least infrastructure change:

1. Datadog Forwarder Lambda — keep the awslogs driver from the standard SocketX task definition and subscribe the Datadog Forwarder to the SocketX CloudWatch log group. No change to the task definition.
2. FireLens — replace the log driver with a Fluent Bit sidecar using the Datadog output plugin (lower latency, no CloudWatch storage cost).

Azure AKS / Kubernetes

Install the Datadog Agent Helm chart with log collection:

helm install datadog-agent datadog/datadog \
  --set datadog.apiKey=<DD_API_KEY> \
  --set datadog.logs.enabled=true \
  --set datadog.logs.containerCollectAll=true

Add pod annotations (or rely on containerCollectAll) so the SocketX pods get service: socketx-server.

tip

Always set service: socketx-server at the agent/forwarder level. v2 log lines also carry a service field in the JSON body, but v1 lines do not — agent-level tagging covers both.

2. Pipeline / parsing

JSON logs are parsed into attributes automatically, including the nested audit object. Verify these standard remappers in the pipeline for the socketx-server service (Logs → Pipelines):

Remapper	Attribute	Notes
Date remapper	time	v2 emits Unix milliseconds; v1 emits Unix seconds. Datadog detects the unit by magnitude — just add time to the date remapper.
Status remapper	level	zerolog levels (debug/info/warn/error) map directly.
Message remapper	message	zerolog's message field.

Recommended facets (Logs → Facets): @event_type, @recovery_action, @failure_kind, @host, @upstream_server; measures on @duration_ms, @payload_size_bytes, and @audit.duration_seconds.

3. Import the dashboard

Dashboards → New Dashboard → ⚙ (settings) → Import dashboard JSON, then paste or upload the downloaded JSON. The dashboard mirrors the Grafana dashboard: Global Health stats, Connection Metrics, MTE Performance (avg/p95/p99 latency), Traffic & Throughput, and Session Audit log streams.

4. Import the monitors

The monitors file contains three log monitors — import each via Monitors → New Monitor → Import Monitor from JSON (or the API), and replace @your-notification-channel with your channel:

1. Recovery event rate — event_type:socketx_recovery count over 5 minutes above threshold.
2. Permanent failures — any recovery_action:fail_permanently in 5 minutes.
3. Error-level log spike — error-status logs over 5 minutes above threshold.

Thresholds are starting points; tune them to your traffic.

5. Control ingest cost

MTE operation events are emitted per proxied message and Datadog bills per ingested GB. Recommended, in order:

1. Log-based metrics (Logs → Generate Metrics): create a count metric over MTE events and distribution metrics on @duration_ms / @payload_size_bytes, then add an exclusion filter or short retention for the raw MTE event logs. Dashboards and monitors can be re-pointed at the much cheaper metrics.
2. Server-side sampling (v2): set MTE_EVENT_SAMPLE_RATE (e.g. 0.1). Count/sum panels then show the sampled fraction; the close-time audit totals are never sampled and stay exact. See Configuration.