JJHub OBSERVE v2.4.0: SQL-like Log Search, Silence Windows, and Field-level RBAC

v2.4.0 is out. This release advances log search, alert governance, and access control. Full notes below.

The three headline features share a theme: less noise, more signal, and tighter control over who can see what. If you're deciding whether to move from v2.3.x, the short version is that the log-search and alerting changes are backward-compatible, while field-level RBAC is new and opt-in.

New

SQL-like log search

• WHERE conditions plus a | stats aggregation pipeline; fields are parsed at ingestion and indexed at write time.
• Built-in parsing templates for nginx, Java stack traces, and JSON logs, with custom Grok support.
• Indexed queries return in seconds at a hundred-gigabyte daily volume.

A query like level='ERROR' AND service='order-svc' | stats count() by host, error_code now answers "which node and which error code" in one step, where you previously needed a regex plus a manual count in a spreadsheet. If you're on v2.3.x, the old keyword search still works — this is an additive, not a breaking, change to the query language.

Alert silence windows and severity routing

• Alert rules gain a "duration" parameter — N consecutive samples over threshold before firing — to filter transient spikes.
• New silence windows suppress non-critical alerts during fixed periods or for a set duration.
• Alerts route by severity: P0 to phone/SMS, P1 to email, P2 to IM.

The practical effect: a scheduled maintenance window no longer means either muting the whole team or enduring a flood of pages. Set a silence window that matches the maintenance, keep the P0 channel open, and let everything else sleep. Combined with the duration parameter, the two features together eliminate most of the false pages teams told us they'd been ignoring.

Multi-tenant field-level RBAC

• Permissions now go from dashboard-level down to field-level, allowing masking or redaction of specified fields (card numbers, phone numbers).
• New auditor role: read-only by default, with every query action logged.

Field-level redaction is applied at ingestion, so a masked field never reaches any view, export, or dashboard — important if you're in a regulated environment where "who can see what" has to be provable, not just configured.

Improvements

• ARM64 collector and storage images tuned; write throughput on Kunpeng 920 up ~12%.
• DM/KingbaseES dialect support extended for pagination and sequences; metadata failover cut from 45s to 20s.
• Trace detail page supports secondary filtering by service, latency, and status code, loading thousand-span traces faster.

Fixes

• Fixed an occasional duplicate-alert-notification issue under high concurrency.
• Fixed an alignment fault crash in a C extension on Hygon CPUs.
• Fixed an error in log search when stats by aggregated over empty results.

Upgrade notes

• Back up metadata before upgrading; this release touches database dialect code, so rollback requires restoring the metadata snapshot.
• Collectors and storage nodes must upgrade together — running mixed versions produces inconsistent index formats.
• Compatibility: v2.4.0 clients are incompatible with v2.3.x servers; upgrade the whole deployment in one window.
• See the Download Center for the full changelog and binaries.

The recommended sequence for a cluster: stop ingestion at the collectors, snapshot metadata, upgrade storage nodes, upgrade collectors, then re-enable ingestion. This keeps the index format consistent and gives you a clean rollback point if the upgrade goes sideways.

Deprecations

• The legacy regex-only log search remains available but is now labeled legacy in the UI; new work should use the SQL-like syntax, and we plan to remove the old path in v3.0.
• The alert.escalation config field is superseded by severity routing; existing rules migrate automatically on upgrade, and the old field is ignored going forward.

Roadmap

• v2.5 plans tail-sampling visualization — a view of what the tail sampler is keeping and dropping, so you can stop guessing whether errors are actually being retained.
• Automatic span-to-metric correlation: derived RED metrics (rate, errors, duration) generated from spans and queryable like any other metric, without a separate metrics pipeline.
• Planned support for DM 8.2 and KingbaseES V8.