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

OBSERVE v2.4: SQL-like Search, Alert Silence Windows, and Kylin Support

v2.4 ships SQL-like log search, alert silence windows, and Kylin/Phytium domestic-stack support, plus fixes. This post lists the changes, how to configure them, and upgrade notes.

New: SQL-like log search

Log search upgrades from keywords plus filters to a full SQL-like engine. You can now write SELECT, WHERE, GROUP BY, HAVING, and subqueries, and treat logs as a table. The old keyword search stays, but complex analysis is better done in SQL — aggregating error rates by service or finding endpoints over a latency threshold is a one-statement job.

SELECT service, count(*) AS cnt
FROM logs
WHERE status >= 500 AND __time__ > now() - interval '1' hour
GROUP BY service
ORDER BY cnt DESC;

Note that SQL depends on structured fields: define field names and types in the Pipeline on the ingestion side, or the columns your query references won't exist.

New: alert silence windows

The most annoying part of on-call is being woken repeatedly by the same alerts. v2.4 lets you set silence windows per rule: pick a time range, pick which alert rules it applies to, and choose one-off or recurring.

silence:
  - rule: node-cpu-high
    window: 23:00-07:00
    recurrence: daily

Set known low-priority maintenance windows (like the nightly backup that spikes disk IO) as recurring silences, but keep P0 alerts un-silenced — don't blanket-mute everything.

Domestic-stack support: Kylin / Phytium

v2.4 officially supports Kylin V10 (arm64) and Phytium processors. Images now ship an arm64 tag, and the metadata database is adapted for Dameng DM8. When deploying in a domestic stack, pull the arm64 image and use the Dameng driver for the database URL — see our earlier field report for details.

Fixes and upgrade notes

This release also fixes three issues: sampling-rate config failing under certain conditions, query results shifting across day boundaries, and trace detail pages stalling on large traces.

Back up the metadata database before upgrading, then run the built-in compatibility self-check afterwards. If you're moving from an x86 install to a domestic stack, migrate logically rather than copying data files directly. The full change list is in the release notes on the documentation site.