Telemetry and OTel: check, self-host or switch off

Seeing a dsh-otel-collector host is not a verdict. First confirm whether data is sent, where it goes and what it contains; until those three are clear, disabling or redirecting is guesswork.

First: is anything being sent

Confirm with evidence in three steps.

1. Config: search for OTel, telemetry or exporter entries.
2. Startup flags: check whether the launch command enables observation or names an endpoint.
3. Network: look for outbound records to that host; only records prove traffic.

Only the three together count as confirmation. Config alone can be overridden by environment variables; network alone can be another component.

A hostname in logs is not data leakage. Establish what is sent: metrics, traces or logs, which differ sharply in sensitivity.

What the host likely is

By name, it looks like an OTel collector endpoint.

1. otel usually means OpenTelemetry.
2. collector means a service that receives and forwards telemetry.
3. The subdomain points at a DeepSeek-related service and may be a default sink.
4. Confirm purpose from docs and the current version rather than guessing from the name.
5. If you never configured it, a version default or a plugin may have introduced it.

The name suggests direction, not a conclusion. Judgment still rests on config, flags and network evidence.

Defaults change between versions. After an upgrade, read release notes and configuration docs before assuming continuity.

Checking config and egress

Two paths: local configuration and live connections.

1. Search config files for telemetry, otel, exporter and endpoint keywords.
2. Inspect launch scripts and environment variables for overrides.
3. Use system network tools to see the process outbound connections and targets.
4. Correlate log lines about reporting and failed retries.
5. Record version and configuration so you can tell defaults from changes.

Configuration beats speculation. When a switch exists, use it; only fall back to network measures when none does.

Do not block with hosts. Blocking causes timeouts and retries that slow startup; prefer a configuration switch when you need to stop reporting.

Running your own collector

To keep observability, point the exporter at your collector.

1. Deploy an OTel collector listening on an internal address.
2. Point the exporter in configuration at that address.
3. Decide signals explicitly: metrics, traces and logs as separate switches.
4. Set sampling and retention to control volume.
5. Verify data arrives before disabling the default endpoint.

Self-hosting buys control. Data stays inside your network, and you decide scope and retention.

Validate small first. Enable metrics only, confirm the pipeline and volume, then add traces and logs; enabling everything at once can overwhelm the backend.

Disabling and degrading

If you do not want telemetry, three options in priority order.

1. Configuration: find the switch and turn off collection or export.
2. Self-host: keep observability while data stays internal.
3. Network limits: when config cannot change, restrict egress and watch for timeouts and retries.

Verify after disabling. Check that the requests disappear and logs stop showing failed reports; editing config without verification can leave another path active.

Degrading is not deleting. Keeping local logs and metrics supports basic diagnosis; turning everything off makes problems harder to locate.

Privacy boundaries

Sensitivity depends on fields, not on whether anything is sent.

1. Metrics: usually counts and durations, low sensitivity.
2. Traces: may carry request paths and error text, which need redaction.
3. Logs: may include input and output fragments, the highest risk.
4. Account data: whether it is reported depends on implementation; confirm in config.
5. Compliance: in enterprise settings follow internal policy, not defaults alone.

Look at fields before the switch. Sending only metrics and sending logs carry completely different risk.

Default to off in sensitive environments. When scope is unclear, disable first and enable the smallest set you need.

Troubleshooting

Four issues cover most telemetry scenarios.

1. Slower startup: an unreachable endpoint causes retries; check timeouts and how you block it.
2. Log noise: the endpoint is down or auth fails; disable or change the address.
3. Duplicate data: several exporters are active; keep one.
4. No switch found: version differences or a plugin brought it in; check release notes and plugin docs.

The entry points are configuration, network and logs. Only the three together tell a default apart from a misconfiguration.

Record what you changed. Which switches, which address, what verification; the next upgrade becomes a quick comparison.

Next steps

Confirm first, then decide to disable or redirect. For outbound and proxy configuration, read How to configure a proxy. For startup errors, read DeepSeek Harness errors at startup. For permission boundaries, read What DSH plugins can and cannot do.

Sources: DeepSeek Harness documentation, dsh CLI README, deepseek-harness repository