Docs

Response times in your monitoring (OpenTelemetry)

Set one policy setting and every desktop and the gateway send the response times people see to the monitoring your operations team already uses.

In short

Every minute, WND Terminal sends a response-time histogram and a timeout counter over OTLP/HTTP for each connection, host, label and key. It works with Datadog, Splunk Observability, Grafana, New Relic, Dynatrace, Elastic and any OpenTelemetry collector. Screen contents, field values and typing are never sent.

WND Terminal can send the response times people actually see to the monitoring your operations team already uses: Datadog, Splunk Observability, Grafana (Mimir or Prometheus through a collector), New Relic, Dynatrace, Elastic, or any OpenTelemetry collector. Set one policy setting, TelemetryEndpoint, and every desktop and the gateway start sending.

What is sent

Every minute (TelemetryInterval), for each connection, host, label and key:

On a small screen, swipe the table to read all columns.

Metric Type What it is
wnd.host.response Histogram, milliseconds From a key that sends the screen (Enter, a PF key, Clear, ...) until the keyboard is free again. Buckets at 100, 250, 500 ms, 1, 2, 3, 5, 10 and 30 seconds.
wnd.host.timeouts Counter Keys the host didn’t answer in time.

Attributes on each point: wnd.connection (the connection’s name), server.address (host:port), wnd.host_type (3270, 5250, ...), wnd.label (your ResponseTimeLabels label, or other) and wnd.key.

On the resource: service.name (wnd-terminal or wnd-gateway), service.version, host.name (the computer), os.type, and wnd.department when the policy sets Department. The person’s login (enduser.id) only when TelemetryUser is hashed (a SHA-256 of the login) or plain.

Never screen contents, field values or anything typed. The numbers come from the same measurements as RecordResponseTimes, which keep only timings, and you can use either one without the other.

Settings

On a small screen, swipe the table to read all columns.

Setting What it does
TelemetryEndpoint The collector’s or service’s OTLP/HTTP address, such as https://otel.bank.example:4318. /v1/metrics is added.
TelemetryHeaders Headers it needs, as name=value pairs separated by commas, such as api-key=... or X-Scope-OrgID=mainframe.
TelemetryInterval Seconds between sends: 60 when not set, at least 10.
TelemetryUser none (the default), hashed or plain.

Sending never slows anyone down. It happens on a thread of its own. When the endpoint doesn’t answer, that minute’s numbers are dropped rather than piled up on the disk.

A collector inside your network is the better place for a vendor’s API key than a policy every computer can read. Point TelemetryEndpoint at the collector and let it hold the key.

Examples

With the collector’s Prometheus exporter, the names become wnd_host_response_milliseconds_bucket and wnd_host_timeouts_total.

A minimal collector configuration that receives from WND Terminal and sends to Prometheus:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

Questions

What does WND Terminal send?

Two metrics. wnd.host.response is a histogram of the milliseconds from a key that sends the screen until the keyboard is free again. wnd.host.timeouts counts keys the host didn’t answer in time. Never screen contents, field values or anything typed.

Is the person’s login sent?

Only when TelemetryUser is hashed (a SHA-256 of the login) or plain. The default is none.

What happens when the collector is down?

That minute’s numbers are dropped rather than piled up on the disk. Sending happens on a thread of its own, so it never slows anyone down.

See it on your own mainframe.

Install WND Terminal on a handful of PCs or Macs, import your sessions and keymaps, and let a real team use it next to what you run today. Free, two to four weeks.