Skip to main content

Observability

The SocketX Server emits structured JSON logs (via zerolog) to stdout/stderr — every metric in this section is derived from those logs; there is no separate metrics endpoint to scrape. Ready-made dashboards are available for three platforms, all implementing the same panels:

Log format by version

v2 log lines carry service: "socketx-server" and socketx_version fields, an event_type on every dashboard-relevant event, and a time field in Unix milliseconds. v1 (the currently released version) has no service field, no event_type on connection open/close events, and emits time in Unix seconds. All dashboards below work with both versions — their queries match on the log message text, which is identical in v1 and v2.

Startup Logs​

Startup logs include a redacted config object with fields such as listen_addr, log_level, socketx_version, mte_version, mte_kyber_strength, buffer sizes, timeout values, and (v2) mte_event_sample_rate. License secrets are omitted.

MTE Operation Events​

For every successful MTE encryption/decryption operation during proxying, the server emits structured fields including:

  • connection_id
  • event_type as encryption or decryption
  • duration_ms
  • payload_size_bytes
  • payload_sha256
  • eeid
  • host
  • origin
  • upstream_server
note

payload_sha256 is a hash of the plaintext payload bytes at the proxy for correlation and audit workflows. It is not a standalone compliance certification or tamper-evidence guarantee.

Sampling (v2)​

MTE operation events are emitted per proxied message, so on log platforms that bill per ingested GB they dominate cost at high traffic. In v2, MTE_EVENT_SAMPLE_RATE (default 1.0) logs only that fraction of MTE operation events. Connection audits and recovery events are never sampled — close-time totals (audit.messages_to_*, audit.bytes_to_*) stay exact even when per-message events are sampled. See Configuration.

Connection Audits​

On connection open the server logs New websocket connection (event_type: connection_open in v2). On close it logs Websocket connection closed (event_type: connection_close in v2) with an audit object containing connection timing, message counts, byte counts, total encode/decode time, and WebSocket close information.

Recovery Events​

Every non-normal recovery decision also emits event_type=socketx_recovery. Stable fields include:

  • connection_id
  • side
  • phase
  • direction
  • trigger
  • failure_kind
  • recovery_action
  • retryable
  • close_code
  • mte_status (when applicable)

The final connection audit repeats the outcome, trigger, action, retryability, and MTE status so operators can correlate the selected action with the session summary.

Recovery logs never contain plaintext payloads, cookies, MTE state, public or private key material, secrets, or personalization values. Cookie forwarding is logged only as a boolean.

Dashboard downloads​

PlatformDownload
Grafana (AWS CloudWatch)socketx-grafana-dashboard.json
Datadogsocketx-datadog-dashboard.json · monitors
New Relicsocketx-newrelic-dashboard.json

All three implement the same panels: total connections, MTE operation counts, bytes processed, encryption/decryption latency (avg/p95/p99), session duration, traffic by direction, and session audit / recovery event streams.