v2.6 ships deep alert-to-trace linking, window functions and subqueries in SQL search, a 2x throughput boost for the agent, and a batch of stability fixes. Includes upgrade steps and compatibility notes for a smooth in-place upgrade.
JJHub v2.6 is out. The headline is deeper alert-to-trace integration, but there's plenty for anyone who searches logs or runs the agent at scale. Here's what changed, how to upgrade, and what to watch for.
Alert-to-trace linking: the alert detail page now embeds the trace waterfall at the moment the alert fired and automatically highlights the longest span, so there's no more jumping from the alert to the trace page to correlate by hand. When a latency alert goes off at 3 a.m., the first thing you see is the span that actually caused it, not a list of suspect services.
SQL search gains window functions (ROW_NUMBER, RANK) and subqueries, enabling analysis like "top 3 error counts per service per hour" or "requests whose duration is above the service's own rolling average". Previously these needed multiple queries and some client-side work; now they're a single statement. If you've been exporting logs to a warehouse just to get ROW_NUMBER-style ranking, this release likely deletes that pipeline.
The agent adds automatic reconnect and local disk buffering—when the upstream is briefly unavailable, data lands locally first and backfills after recovery, so no logs are lost during a network blip or a backend restart. The buffer is worth understanding because it changes failure semantics: by default it spools to a local directory with a size cap, and once the cap is reached the oldest data is dropped first (FIFO), so a long outage degrades to "newest data wins" rather than unbounded disk growth. The cap and retention are both configurable.
Agent throughput roughly doubles: after rewriting the batch serialization path, a single instance went from 30k to 60k EPS (measured on 8 cores / 16GB). For most deployments that means either half the agent replicas or headroom for the next traffic spike. The agent memory footprint also dropped by about 30% as a side effect, since fewer temporary objects are allocated per batch.
Query-side time-partition pruning was optimized, cutting the median response time for cross-day queries by about 40%. If you run daily or weekly reports that span partitions, this is the change you'll notice most. Dashboards get a dark theme and centralized alert-threshold configuration across multiple charts—change once, apply to the whole group.
On the fix side, this release closes a race that could drop the first log line after an agent restart, corrects timezone handling on cross-day dashboards, and fixes a memory leak in the alert engine that grew slowly over weeks of uptime.
Back up the metadata database and config directory first. For an in-place upgrade:
yum upgrade jjhub-server -y # Kylin / UOS
# or dpkg -i jjhub-server_2.6.0_amd64.deb (Debian-based)After upgrading the server, upgrade the agent to match—otherwise some new fields (such as the span.duration label the span highlighting depends on) won't be reported. Upgrade the agent first, then the server, to avoid a brief window of missing fields:
systemctl stop jjhub-agent
rpm -Uvh jjhub-agent-2.6.0.x86_64.rpm
systemctl start jjhub-agentRollback is a standard package downgrade: rpm -Uvh --oldpackage or dpkg -i the previous version. Keep the pre-upgrade backup handy until you've verified alerting and search on the new version. Two quick post-upgrade checks: fire a test alert and confirm the trace waterfall renders, then run a window-function query and confirm it returns in the expected time.
This release is backward-compatible with 2.4.x/2.5.x config and data; no index rebuild is required. Two behavior changes to note: SQL search now defaults to strict mode, so field-name typos that were previously tolerated will error out—run EXPLAIN on your statements first; and the alert silence window now keys on "alert rule" rather than "alert instance", so rules that silenced per-instance need re-review. The upgrade causes a single restart with up to a minute of downtime, so schedule it in a low-traffic window. Known issue: window functions occasionally run slow on DM8 over large result sets—a fix is scheduled for 2.6.1; use aggregate functions as a workaround until then. One deprecation to note: the legacy jjhub-agent.conf format is now read-only, and v2.7 will drop support for it—migrate to the new YAML agent config when convenient, and use the new --config-check flag to validate it before restarting.