[Released] LoongSuite OpenTelemetry GenAI Observability Plugin for DeepSeek Harness

[fangxiu-wf]

Release status (2026-08-17): Stable version 0.1.1 is available. Install with dsh plugin --profile web add @loongsuite/dsh-plugin. Source and documentation: loongsuite/dsh-plugin.

背景

DeepSeek Harness（DSH）采用“一切皆插件”的架构，并提供完整的 session、turn、step、LLM 和 tool 生命周期数据。仓库目前已经包含 dsh-session-telemetry-otel，可以通过 OTLP 导出结构化日志；但如果想在可观测后端中直接查看一次 Agent 执行里的模型调用、推理步骤、工具调用、Token 和耗时关系，还缺少一棵标准化的 GenAI Trace 树。

我们计划为 DeepSeek Harness 开发一个独立、开源的 LoongSuite 可观测插件，想先向维护者和社区征求对方案及集成方式的意见。

LoongSuite 是什么

LoongSuite 是基于 OpenTelemetry 的开源可观测数据采集体系，并增强了生成式 AI 与 Agent 场景的语义表达。这个项目希望把 LoongSuite 的 OpenTelemetry GenAI 可观测能力带到 DeepSeek Harness，同时保持采集协议、部署方式和后端选择的开放性。

插件代码与文档将托管在独立仓库：loongsuite/dsh-plugin。

方案定位

我们希望提供一个真正的 DSH 原生插件，而不是修改 Harness 核心代码、解析终端输出，或依赖额外的本地采集进程：

• 通过 DSH 原生插件机制、生命周期事件和公开扩展点采集数据；
• 在插件进程内构建 OpenTelemetry GenAI spans 和 metrics；
• 按 OpenTelemetry GenAI Semantic Conventions 组织 ENTRY → AGENT → STEP → LLM / TOOL Trace；
• 采集模型、Token、TTFT、耗时、结束原因、错误和工具调用等指标与属性；
• 插件自身通过标准 OTLP 将数据直接发送到配置的后端；
• 不绑定特定厂商、SaaS 或云服务，也不要求部署额外的本地采集组件；
• 可观测配置、网络或后端故障不会影响 Agent 的正常执行。

目标 Trace 结构示例：

enter_ai_application_system  (ENTRY)
  └── invoke_agent           (AGENT)
       ├── react             (STEP)
       │    ├── chat         (LLM)
       │    └── execute_tool (TOOL)
       └── react             (STEP)
            └── chat         (LLM)

数据通过标准 OTLP 输出，可发送到任何兼容 OTLP 的开源或商业后端，例如 OpenTelemetry Collector、Jaeger、Grafana Tempo、SigNoz 和 Langfuse。不同后端对 GenAI 专用字段和 UI 的展示能力可能不同，但底层数据与传输协议保持开放、标准化。

如何使用（计划接口）

项目目前处于方案与实现准备阶段。首个版本发布后，用户可以从 DSH 插件市场或命令行独立安装：

dsh plugin --profile web add @loongsuite/dsh-plugin

然后在 DSH profile 中配置 OTLP endpoint：

- id: loongsuite-observability
  name: '@loongsuite/dsh-plugin'
  config:
    endpoint: http://localhost:4318/v1/traces
    serviceName: my-dsh-agent
    headers: {}
    captureContent: false

启动或重启 DSH 后，插件会自动采集 Agent 运行数据并上报。用户可以在 Jaeger、Grafana Tempo、SigNoz、Langfuse 等兼容后端中查看会话、模型调用和工具调用链路。OpenTelemetry Collector 可以作为可选的转发与处理层，但不是使用插件的必要条件。

我们也计划支持标准 OpenTelemetry 环境变量，例如 OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_EXPORTER_OTLP_HEADERS 和 OTEL_SERVICE_NAME，便于容器与自动化部署。

与现有能力的关系

这不是对现有 dsh-session-telemetry-otel 的简单重复：

• 现有官方插件主要输出 OTLP Logs，适合保留权威 session 事件和运维记录；
• 本提案重点补齐 Agent / Step / LLM / Tool 的父子 Span、Trace Context 传播和 GenAI Metrics；
• 社区已有的 dsh-plugin-langfuse 证明了从 DSH session 数据构建 Trace 的可行性；LoongSuite 方案的差异是使用标准 OTLP、后端无关，并作为可独立安装的 DSH 插件发布。

实现计划通过 DSH 的公开事件和插件生命周期进行旁观式采集，不占用或替换官方 sessionTelemetry backend，因此目标是能够与现有 OTLP Logs 后端同时运行。

隐私与可靠性原则

• 默认只在 Trace 中采集调用元数据；Prompt、Completion、工具参数和工具结果等内容默认关闭；
• 内容采集必须显式开启，并支持可配置的脱敏与敏感信息过滤；
• OTLP endpoint、鉴权 headers 和资源属性均由用户配置；
• 批处理、队列、刷新和关闭流程遵循 OpenTelemetry SDK 生命周期；
• 采集或导出异常会被隔离，不阻塞或改变 Agent 的正常行为；
• 插件不依赖任何特定云服务、商业产品或私有协议。

如果方向得到认可，我们会在 loongsuite/dsh-plugin 公开设计、实现、测试和使用文档，并首先提供一个能够直接连接本地 OpenTelemetry Collector 或 Jaeger 的最小可运行版本。

---

Background

DeepSeek Harness (DSH) follows an “everything is a plugin” architecture and exposes complete session, turn, step, LLM, and tool lifecycle data. The repository already includes dsh-session-telemetry-otel, which exports structured logs through OTLP. What is still missing is a standardized GenAI trace tree that lets an observability backend directly show the relationships among model calls, reasoning steps, tool executions, token usage, and latency within an agent run.

We propose an independent, open-source LoongSuite observability plugin for DeepSeek Harness and would like feedback from the maintainers and community on the design and integration approach.

What is LoongSuite?

LoongSuite is an open-source observability data collection suite built on OpenTelemetry, with enhanced semantic representation for generative AI and agent workloads. This project aims to bring LoongSuite's OpenTelemetry GenAI observability capabilities to DeepSeek Harness while keeping the collection protocol, deployment model, and backend choice open.

The plugin source code and documentation will live in the standalone repository loongsuite/dsh-plugin.

Proposed scope

The goal is a native DSH plugin, without modifying Harness core, parsing terminal output, or requiring an additional local collection process:

• Collect data through DSH's native plugin mechanism, lifecycle events, and public extension points.
• Build OpenTelemetry GenAI spans and metrics inside the plugin process.
• Represent traces according to the OpenTelemetry GenAI Semantic Conventions as ENTRY → AGENT → STEP → LLM / TOOL.
• Capture model identity, token usage, TTFT, duration, finish reasons, errors, and tool execution attributes.
• Export directly from the plugin to a configured backend through standard OTLP.
• Avoid dependencies on a specific vendor, SaaS product, cloud service, or additional local collection component.
• Ensure that configuration, network, or backend failures in observability never affect normal agent execution.

Target trace structure:

enter_ai_application_system  (ENTRY)
  └── invoke_agent           (AGENT)
       ├── react             (STEP)
       │    ├── chat         (LLM)
       │    └── execute_tool (TOOL)
       └── react             (STEP)
            └── chat         (LLM)

The plugin will emit standard OTLP data to any compatible open-source or commercial backend, including OpenTelemetry Collector, Jaeger, Grafana Tempo, SigNoz, and Langfuse. GenAI-specific visualization capabilities may differ between backends, but the underlying data and transport remain open and standardized.

How to use it (planned interface)

The project is currently in the design and implementation preparation stage. After the first release, users will be able to install it independently from the DSH plugin market or the command line:

dsh plugin --profile web add @loongsuite/dsh-plugin

Users will then configure an OTLP endpoint in their DSH profile:

- id: loongsuite-observability
  name: '@loongsuite/dsh-plugin'
  config:
    endpoint: http://localhost:4318/v1/traces
    serviceName: my-dsh-agent
    headers: {}
    captureContent: false

After DSH starts or restarts, the plugin will automatically collect and export agent telemetry. Sessions, model calls, and tool execution traces can then be inspected in compatible backends such as Jaeger, Grafana Tempo, SigNoz, or Langfuse. An OpenTelemetry Collector may be used as an optional processing and forwarding layer, but it is not required to use the plugin.

We also plan to support standard OpenTelemetry environment variables such as OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, and OTEL_SERVICE_NAME for containerized and automated deployments.

Relationship to existing capabilities

This is not a duplicate of the existing dsh-session-telemetry-otel package:

• The official plugin primarily exports OTLP Logs, which preserve authoritative session events and operational records.
• This proposal focuses on Agent / Step / LLM / Tool parent-child spans, Trace Context propagation, and GenAI metrics.
• The community dsh-plugin-langfuse has demonstrated the feasibility of building traces from DSH session data. The LoongSuite proposal differs by using standard OTLP, remaining backend-neutral, and being distributed as an independently installable DSH plugin.

The implementation is intended to observe DSH public events and plugin lifecycles without claiming or replacing the official sessionTelemetry backend, so it should be able to run alongside the existing OTLP Logs backend.

Privacy and reliability principles

• By default, traces contain invocation metadata only. Prompts, completions, tool arguments, and tool results are disabled by default.
• Content capture must be explicitly enabled and will support configurable redaction and sensitive-data filtering.
• The OTLP endpoint, authentication headers, and resource attributes are controlled by the user.
• Batching, queueing, flushing, and shutdown follow the OpenTelemetry SDK lifecycle.
• Collection and export failures are isolated and never block or alter normal agent behavior.
• The plugin does not depend on any specific cloud service, commercial product, or proprietary protocol.

If the direction is accepted, we will publish the design, implementation, tests, and usage documentation in loongsuite/dsh-plugin, starting with a minimal runnable version that can connect directly to a local OpenTelemetry Collector or Jaeger instance.

[ralf0131]

我维护上游的 alibaba/loongsuite-pilot，和 @fangxiu-wf 是同一个团队——补充下"为什么需要 trace"这件事本身。

先说清楚：dsh-session-telemetry-otel 输出的 OTLP logs 不是要被替代的东西。它保留的是权威的 session
事件账本——发生了什么、按什么顺序、哪一条出错了。审计、复盘、告警、事后追责，都应该以它为准。

但日志回答的是"发生了什么"，回答不了"时间和钱花在哪了"。后者是一棵树的问题，而日志是一串点：

• 这一轮 47 秒，其中多少是模型在想、多少是某个工具在等网络、多少是首 token 之前的排队？
• 这个 subagent 一共烧了多少 token，占整轮成本的几成？
• 同一个任务重试了三次，是每次都卡在同一个工具，还是模型每次换了路线？
• 上下文被压缩之后，后续步骤的耗时和 token 结构变了吗？

这些问题的答案在事件之间的父子关系和时间区间里。事件账本本身是扁平的，谁想回答就得自己重建一次
这棵树——每个后端一套、每个人一套。Trace 的意义就是把这棵树在采集时构建一次，之后所有后端都直接
可用。

第二个意义是复用已有的工具投入。Jaeger、Grafana Tempo、SigNoz、Langfuse 这些后端已经把 trace 的
瀑布图、火焰图、按属性聚合、p95 分析做好了。只要数据是标准 OTLP trace + OpenTelemetry GenAI 语义约定，
"按模型看 p95 延迟""按工具看 token 成本""哪类步骤失败率最高"这类问题不需要任何定制查询就能回答；而
只有日志的话，每个团队都得先自己搭一层管道。

第三个意义是跨系统串联。DSH 只是更大链路里的一跳——CI 任务调起 agent、agent 调 MCP 工具、
工具再打到下游服务。能把这整条请求缝在一起的只有 trace context。日志里可以带 session id，但没有东西
能把它和上游调用方的那次请求关联起来。

所以我们的判断是：logs 和 trace 不是二选一，而是回答不同问题的两种数据，生态里现在只有前者。trace 是
从同一份事件流投影出来的结构化视图——有损、但结构化、可聚合、可跨系统关联。这也是我们选择做成独立
插件、走标准 OTLP、不绑定任何后端的原因：让用户自己决定发到哪里，也让它能和现有的 logs 后端同时运行，
而不是取代它。

I maintain alibaba/loongsuite-pilot and work with @fangxiu-wf. This comment is about one
thing: why traces are worth adding at all.

To be clear first — the OTLP logs from dsh-session-telemetry-otel are not something to replace.
They are the authoritative session ledger: what happened, in what order, which entry failed. For
audit, replay, alerting, and after-the-fact investigation, that ledger should stay the source of
truth.

But logs answer what happened. They do not answer where the time and the money went. That is a
tree-shaped question, and a log is a sequence of points:

• This turn took 47 seconds — how much was the model thinking, how much was one tool waiting on the
  network, how much was queueing before the first token?
• How many tokens did this subagent consume, and what share of the turn's cost was that?
• The task was retried three times: did it stall on the same tool every time, or did the model take a
  different route each time?
• After a context compaction, did the duration and token profile of the following steps change?

The answers live in the parent-child relationships and the intervals between events. An event
ledger is flat, so anyone who wants those answers has to reconstruct that tree themselves — once per
backend, once per team. In our own runs, a single real session produced 8 model steps and 7 tool
executions; rebuilding that structure by hand from flat logs is not realistic. The point of a trace
is to build the tree once, at capture, so every backend gets it for free.

The second reason is reuse of tooling that already exists. Jaeger, Grafana Tempo, SigNoz and Langfuse
have already built the waterfalls, flame graphs, attribute aggregation and percentile analysis. As
long as the data is standard OTLP traces following the OpenTelemetry GenAI semantic conventions,
questions like "p95 latency per model", "token cost per tool", "which kind of step fails most" need
no custom queries at all. With logs only, every team has to build that pipeline first.

The third reason is stitching across systems. A DSH run is increasingly one hop in a longer path — a
CI job invokes an agent, the agent calls an MCP tool, the tool reaches a downstream service. Trace
context is the only thing that sews that whole request together. Logs can carry a session id, but
nothing joins it to the caller's request.

So our view is that logs and traces are not an either/or: they answer different questions, and the
ecosystem currently has only the first. A trace is a projection of the same event stream — lossy, but
structured, aggregatable, and linkable across systems. That is also why we are building it as an
independent plugin over standard OTLP with no backend lock-in: users decide where the data goes, and
it can run alongside the existing logs backend rather than displacing it.

[fangxiu-wf]

Update: stable version 0.1.1 is now available

The standalone plugin discussed here has been implemented and released as a stable package:

• npm: @loongsuite/dsh-plugin
• Source code and documentation: loongsuite/dsh-plugin

Install the current stable release into a DSH profile:

dsh plugin --profile web add @loongsuite/dsh-plugin

The current stable release is 0.1.1. It has been exercised with real DSH Web and headless runs and exports the ENTRY → AGENT → STEP → LLM / TOOL trace hierarchy, GenAI duration and token metrics, and standard OTLP/HTTP protobuf to any compatible backend. Prompt, response, and tool content remain disabled by default and can be enabled explicitly when needed.

Feedback on the DSH lifecycle mapping, GenAI semantics, and backend compatibility is very welcome.

---

进展更新：正式版本 0.1.1 已发布

本讨论中的独立插件已经完成实现并发布稳定版本：

• npm：@loongsuite/dsh-plugin
• 源码与文档：loongsuite/dsh-plugin

安装当前正式版本：

dsh plugin --profile web add @loongsuite/dsh-plugin

当前稳定版本为 0.1.1，已经通过真实 DSH Web 与 headless 场景验证，可通过标准 OTLP/HTTP Protobuf 向任意兼容后端上报 Trace 和 GenAI Metric。正文采集默认关闭，需要时可以显式开启。欢迎试用并反馈生命周期映射、语义兼容性和后端集成方面的建议。

[ralf0131]

Update: To keep up with the npm package name, the latest Github url for loongsuite dsh plugin has been migrated to: https://github.com/loongsuite/dsh-plugin

[Electricitysheep]

OpenTelemetry GenAI 可观测性——session/turn/step/LLM/tool 生命周期数据接 OTel，是生产级观测的正路（比日志强太多）。

已收录进手册生态章节 + 第 6 章（评测/观测可呼应）：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md