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

v3.5.0 Release: Multi-Tenant RBAC, KingbaseES Storage, and Log-Trace Correlation

v3.5.0 ships a multi-tenant RBAC permission model, KingbaseES storage support, one-click log-trace correlation, on-call rotation, and cross-source dashboard variables — all compatible with existing data and alert rules.

v3.5.0 Release: Multi-Tenant RBAC, KingbaseES Storage, and Log-Trace Correlation

Jujing OBSERVE v3.5.0 is out. This release focuses on three areas: multi-tenant permissions and data security, domestic database support, and connecting logs with traces. Here is the full changelog.

Multi-tenancy and permissions: RBAC goes live

A multi-tenant RBAC permission model is now available, with resource granularity down to "data stream + environment + action" and policies that can apply by tag condition. A permission middleware validates every data endpoint centrally, and new endpoints are deny-by-default — they return 403 unless permissions are explicitly declared. Roles fall into five groups (admin, operator, developer, auditor, visitor) and can be customized per team.

Field-level masking is new too: phone numbers, ID numbers, and tokens are shown as plaintext or masked per role, with masking rules configured in one place. Operation auditing ships alongside it — admin logins, config changes, and data exports are all recorded, the audit log is append-only and cannot be deleted, and the auditor role is read-only.

Xinchuang: KingbaseES storage support

The storage layer now supports KingbaseES (including its MySQL compatibility mode). Metadata, configuration, and alert-history stores can run on KingbaseES. The migration tool exports from MySQL and handles auto-increment-to-sequence conversion plus identifier case and collation differences on import. We also fixed an intermittent file-descriptor leak when running collectors on openEuler 22.03.

Observability: one-click log-trace correlation

The log collection side now supports OpenTelemetry log correlation. After instrumenting the application, the platform attaches logs to the matching span by trace_id automatically. The trace detail page gains a "logs for this request" panel — open a span and its logs expand in place. The search API supports exact filtering by trace_id, with a dedicated index on the otelTraceID field, so one query pulls all logs for a request.

Other changes

  • Alert notifications add an on-call rotation table, with primary and backup on-call staff configurable per week.
  • Dashboards support cross-source variable linking.
  • Collectors gain per-label collection toggles, so you can turn off noisy data sources on demand.
  • Fixed unstable result ordering in some search scenarios and overflow of long labels on wall-screen charts.

How to use the new features

A multi-tenant RBAC config example, with resource granularity at "data stream + environment + action":

role: read-only-ops
permissions:
  - resource: "logs"
    actions: ["read", "search"]
    environments: ["prod", "staging"]

Configure the on-call rotation under Alerting → On-call: fill in primary and backup staff per week, and alerts route automatically to the current week's staff via enterprise WeChat and SMS. Cross-source dashboard variables link by switching the "data source" dropdown while editing a panel.

Performance and stability

  • Batched writes on the time-series path raise single-instance ingest throughput by about 35%.
  • Collectors keep memory stable over long runs; we fixed a slow leak under high load.
  • Search results order more reliably under concurrency; fixed occasional out-of-order results.

Known issues

Dashboards imported from older JSON may need a few custom charts manually re-bound to a data source in v3.5.0; this is scheduled for a fix in v3.5.1. For anything else, report it in the console and we will prioritize by impact.

Suggestions

  • Before going multi-tenant, settle role and tag conventions first instead of adding them on the fly.
  • When moving storage to KingbaseES, run the dual-write comparison and confirm the two sides match before cutting over.
  • For log correlation, pilot it on one core service and confirm logs are searchable by trace_id before enabling it everywhere.
  • Before upgrading, validate in staging first, focusing on on-call rotation and cross-source dashboard variables.

Upgrade notes

Upgrade path: rolling release on the backend; collectors just pull the new image tag and restart. Data and alert rules remain compatible — no migration needed. If you plan to move the storage layer to KingbaseES, complete the dual-run comparison described in the "KingbaseES migration guide" before cutting over traffic. Older clients (v3.3 and below) still work, but log correlation and masking take effect only after upgrading the collector. See the "v3.5.0 upgrade guide" for full steps; file a ticket in the console if you hit issues, and we will triage by impact.