DEV Community

Cover image for DataBuff v0.1.3 Release Notes
AIdevops2088
AIdevops2088

Posted on • Originally published at databuff.ai

DataBuff v0.1.3 Release Notes

DataBuff v0.1.3 focuses on three things: native SkyWalking gRPC ingest (no Agent swap), Ops Expert install recovery and read-only SSH troubleshooting, and verified in-place upgrades — built for teams already on SkyWalking and for installs that exit non-zero while the UI still opens.

Highlights

  • Native SkyWalking ingest: ingest listens on 11800 (OAP default); Java only changes collector.backend_service.
  • Ask why checkout is slow: natural-language questions return traceId and bottleneck spans without browsing the Trace list first.
  • Logs link to traces: one click from a log row to the full call chain.
  • Ops Expert · troubleshooting mode: when install exits non-zero, Web still opens; configure an LLM and let Ops Expert recover Doris over read-only SSH.
  • Ops Expert · on-host checks: align container/host evidence with slow spans — complements telemetry-only AI.
  • In-place upgrade: upgrade scripts keep data/ intact; amd64/arm64 offline packages ship for 0.1.3.

Keep your SkyWalking Agent

Ingest listens on SkyWalking gRPC port 11800. No Agent jar swap — topology, traces, JVM metrics, and log correlation work the same as the OTLP path.

SkyWalking protocol checkout topology

Fig. 1 · SW protocol demo: checkout dependencies in DataBuff topology

ingest ports 4317/4318/11800

Fig. 2 · Ingest exposes OTLP (4317/4318) and SkyWalking (11800)

Checkout latency: ask once, get an answer

Demo scenario: GET /demo/checkout P99 around 240ms. After ingest, troubleshooting shifts from browsing traces to asking AI.

checkout P99 240ms

Fig. 3 · service-a checkout ~240ms avg — triggers AI and Ops Expert

Ask AI why checkout is slow

Fig. 4 · Natural-language question over SkyWalking Agent segments

AI trace breakdown

Fig. 5 · 240ms request split by service/middleware; bottleneck span highlighted

checkout trace flame graph

Fig. 6 · Jump to flame graph by traceId — DB/Cache/MQ/RPC expandable

Logs linked to traces

Fig. 7 · Log analytics: each row links to the call chain

Ops Expert: install failed, UI still opens

When install.sh / start.sh exits non-zero and Doris FE/BE are not ready, Web enters troubleshooting mode: configure an LLM API key, pick the built-in Ops Expert, and recover containers over read-only SSH.

Web troubleshooting mode banner

Fig. 8 · Start failed but troubleshooting guidance prints — configure LLM before Doris is healthy

Ops Expert: no OTel data — conclusion in minutes

For missing OTel data, container restarts, port conflicts, and similar chores, Ops Expert runs read-only Bash + SSH to align host evidence with what APM shows.

Ops Expert prompt

Fig. 9 · Describe missing OTel data to Ops Expert

Ops Expert SSH investigation

Fig. 10 · Read-only Bash checks containers and ports

Ops Expert conclusion

Fig. 11 · Evidence-backed conclusion ready for the incident channel

Full SkyWalking walkthrough: native ingest deep dive. Five Ops Expert scenarios: runtime troubleshooting playbook.

Install & upgrade

New install: Docker installation. Upgrade an existing deployment: Upgrade and uninstall.

Try it

GitHub Release v0.1.3 · Live demo · Star on GitHub

Top comments (0)