← Back to blog
Changelog 4 min read 炬鲸团队

v1.5.0 Release Notes: OTLP HTTP Ingest, SQL Lab, and Alert Silencing

JUJING OBSERVE v1.5.0 ships OTLP HTTP (JSON) log/trace ingest, a tenant SQL Lab, alert silencing and cooldown, finer quota metering, and export fixes, plus upgrade notes.

v1.5.0 is out. This release rounds out the ingest protocol, query capability, and alerting experience, so it's a meaningful one for anyone who has been waiting on standard OTLP ingest or wants to let their tenants run their own analysis. Changes are grouped below as additions, improvements, and fixes.

The headline for most teams is OTLP: if you're coming from an OpenTelemetry-based stack, this is the release that turns migration into a config change. For SaaS operators, the headline is the SQL Lab and quota metering — tenants can finally slice their own data, and you can finally bound what a noisy tenant costs you. Everything below maps to a live capability you can exercise from the console today.

Additions

OTLP HTTP (JSON) ingest. New endpoints POST /api/otlp/v1/logs and /api/otlp/v1/traces accept common OTLP JSON exports (not protobuf), using the same auth as the ingest token. If you already run an OTLP collector, point it at a new endpoint and both logs and traces flow in — no adapter layer needed. This is the piece that makes migration from another observability stack a config change instead of a rewrite.

Tenant SQL Lab (Pro/Ent). Tenants can now write SELECT against service_log / tracing_log for ad-hoc aggregation. The lab only allows SELECT, forces tenant_id + env_id filtering on the inner query, and applies user conditions on the outer query — there's no way to reach another tenant's tables. It also strips multi-statement and write keywords, so it's safe to hand to a tenant's own analysts.

Alert silencing and cooldown. Alert rules support silencing for N minutes (handy during change windows), and a single rule won't re-fire within 15 minutes, reducing alert storms.

Improvements

Finer quota metering. At 80% of a plan's daily ingest quota the platform alerts; at 100% it rejects writes while queries keep working. Cumulative storage limits behave the same way. Query windows are enforced on both frontend and backend, and expired logs are purged hourly per the plan's retention_days with storage usage recomputed.

One-click default alert rules. New tenants can create two presets in one click: level="ERROR" (20 in 5 minutes) and code>=500 (10 in 5 minutes). It removes the "empty dashboard on day one" problem.

Weekly report. A weekly operating report auto-sends Monday 09:00; enable the "weekly report" channel on the dashboard.

Fixes

  • Fixed a potential panic when parsing an empty traceId ([]);
  • Fixed the missing 16 MB limit message when an ingest request body is too large;
  • Fixed the export button not being correctly disabled on lower plans.

Upgrade notes

The backend auto-migrates new tables (e.g. alert_rule) on startup — no manual SQL required. After upgrading, restart the backend to seed plans and preset rules and to start the alert and weekly-report jobs. Existing ingest clients need no changes; the API is backward compatible. See the docs center for the full changelog and Xinchuang support matrix.

Compatibility and roadmap

This release is backward compatible: existing ingest clients, tokens, and query APIs keep working unchanged. Two things are intentionally out of scope for now. First, OTLP protobuf ingest isn't here yet — only OTLP/HTTP JSON — so collectors that speak protobuf only will need the JSON endpoint or a small shim until v1.6. Second, service topology (span-graph) and SLO error budgets are on the roadmap but not scheduled. If either is blocking for you, note it on your account and it feeds the v1.6 prioritization — release cadence here is driven by the requests that actually come in, not by a feature spreadsheet.