dsh-client-ui-elasticsearch

English | 中文

A DeepSeek Harness plugin that adds an Elasticsearch section to Settings and a
host-side es_query_logs model tool.

• Settings → Elasticsearch: configure uris (one per line), username, and
  password. Values are stored in the shared DSH settings document and shared
  across sessions.
• es_query_logs tool: search logs by trace_id (exact match) and/or by
  natural-language search terms via query (matched against message,
  exception, and other log text fields), with optional fields, index, and
  size. It reuses the connection configured above.
• Auto-guidance: a system-prompt section teaches every session to use the
  tool when a trace_id or a log-content question is asked — no dedicated
  agent preset required.

Install

dsh plugin --profile web add @asuka1121/dsh-client-ui-elasticsearch@latest

Then restart the deployment. The package declares dsh.bundle.patch, so
dsh plugin registers it as a profile bundle automatically.

Requires pnpm on PATH. The plugin resolves its @deepseek-ai/* runtime
dependencies as peer dependencies from the DSH installation, so it shares the
installation's single Cordis instance.

Tool

es_query_logs parameters:

* at least one of query or trace_id is required.

• trace_id runs exact term queries on trace_id, trace.id, traceId,
  and traceID.
• query runs a multi_match (best_fields) over the resolved fields, avoiding
  wildcard field expansion that fails on wide indices.
• Both together narrow by trace and content; results are sorted by
  @timestamp desc, trying each configured URI in order.

License

MIT

Development

The compiled lib/ ships with this repo, so consumers can install from the
directory directly. Building from source requires the
deepseek-harness monorepo:
tsdown.config.ts imports the clientBundle preset from
packages/client/tsdown.client.ts. The published npm package
(@asuka1121/dsh-client-ui-elasticsearch) is the canonical build artifact.

Future Plans

Vision. The real payoff of a log-search plugin is correlation: not just
finding log lines, but tracing each one back to the project code that produced
it. The long-term goal is exactly that — log-to-code traceability.

Current boundary. Today the agent correlates logs only against the local
workspace. Code-side integration stays on hold until DSH officially exposes a
remote/network workspace (e.g. binding 0.0.0.0) — correlating logs against a
workspace the agent cannot reach would be meaningless.

Open problem — acquiring the code. The leading idea is to clone the owning
project on the server side, on demand, before each query, keyed by the
app_name found in the logs, so answers stay self-contained and always based
on the latest code. Storing full clones for every app is expensive, so lighter
approaches are under evaluation: shallow/partial clones, lazily fetching only
the files a trace references, and cache/eviction policies.