Ju Jing OBSERVE v2.3: SQL Search, Alert Noise Reduction, and Kylin Support

v2.3 is out today. This release focuses on three things: better search, quieter alerts, and a smoother run on Xinchuang environments. Full notes below.

New: SQL-based log search

Log search upgrades from keyword mode to full SQL, with support for WHERE, GROUP BY, ORDER BY, LIMIT, and aggregate functions including count, avg, and percentile. JSON, key-value pairs, and regex groups are auto-extracted into queryable fields — no schema to define up front.

SELECT upstream, percentile(latency_ms, 99) AS p99
FROM nginx_access
WHERE status = 502 AND time > now() - interval '1 hour'
GROUP BY upstream

The old Lucene syntax still works; the console offers a one-click "SQL / Lucene" toggle, so existing users don't need to migrate. A new "Query Templates" feature lets you save common troubleshooting queries and share them with the team for one-click use on call. On performance, SQL search returns P99 latency around 1.2 seconds across 100 million logs — about 3x faster than Lucene keyword mode on average, and 5x faster on aggregation queries.
SQL search also supports subqueries and HAVING, so a complex investigation can be a single statement instead of repeated console round-trips.

New: alert noise reduction and event aggregation

Three layers of noise reduction target alert storms:

1. Silence windows. Set quiet periods by rule or label (e.g. during a release window); alerts are recorded but not notified.
2. Deduplication. The same alert for the same object notifies at most once per five minutes; repeated triggers merge into one.
3. Event aggregation. Multi-source alerts caused by one fault aggregate into a single event, so on-call handles one event instead of dozens of messages.

A new "Alert Replay" page shows the timeline of an incident from first alert to recovery, for postmortems. Notification channels now include WeCom and DingTalk bots, with outbound phone calls configurable for P0 alerts.

New: full Kylin V10 + Kunpeng 920 support

v2.3 passes full adaptation testing on Kylin V10 SP3 + Kunpeng 920 + Dameng DM8, and official images now include an arm64 tag. The agent, console, and search cluster all run natively on Xinchuang hardware with no x86 translation layer. Dameng table-creation and dialect issues are also fixed; see the fix list below.

Known issues and limitations

• SQL search doesn't yet support multi-table JOIN; for cross-stream correlation, drill down into traces for now. JOIN lands in v2.4.
• Alert silence windows are set at rule granularity; per-object silence isn't available yet.
• On Dameng, older versions (8.1.0 and earlier) still need a client upgrade before table creation works reliably.

Changes and fixes

• Breaking change: the query field on /api/v1/logs/search is renamed to sql; the keyword field is deprecated. Update clients by the end of this month — the compatibility period ends at v2.4.

We ship v2.3 migration packages for each language SDK; for most callers the query → sql rename is a one-field change.

• Performance: inverted-index rebuild is 40% faster, per-shard query memory usage drops about 25%, and ingest memory for large fields (>1MB) drops 30%.
• Fixes: an intermittent agent memory leak when ingesting large fields (>1MB); a bug where the trace sampling-rate config didn't apply after restart; a Dameng issue where some Chinese table names failed to create; a bug where alert silence windows spanning midnight didn't take effect.

Upgrade steps and advice

Upgrade in four steps: back up config → run migrate → swap images → observe a canary.

• Before upgrading from v2.2, back up your config and run migrate. Dameng users should upgrade the DM client to 8.1.3 or later first.
• In production, upgrade a canary environment and watch for 24 hours, focusing on search P99 latency and alert false-positive rate.
• Update clients still calling the old query field in parallel — the old field will stop parsing when the compatibility period ends.
• There is no index-format change, so you can roll back to v2.2 if the upgrade fails. Data stays intact, though newly written field configs won't be backward-compatible.

See the "Downloads" page for the full compatibility matrix and installers. Report issues via tickets or the community.