v2.3.0 adds log downsampling, alert silence windows, and DM8/openGauss database support, plus stability fixes for queries and ingestion. Includes upgrade steps and compatibility notes.
v2.3.0 is out today. This release focuses on two things: cutting storage cost and alert noise without losing critical information, and rounding out database support for Xinchuang environments. Details below.
Log downsampling (beta): high-frequency logs (health checks, heartbeats, DEBUG level) can now be deduplicated by field and thinned by time. Example: for kind=healthcheck, keep only one line per host + status every 10 seconds and drop the rest. Downsampling happens at the collector, before anything is stored, so it reduces both write volume and query noise. Ratio, retained fields, and scope are configurable per service in the ingest settings.
The motivation is straightforward: in most deployments, a handful of noisy log types account for a large fraction of total volume, and almost all of those lines are duplicates. Turning off health-check logging entirely is a common workaround, but then you lose the signal entirely. Downsampling keeps the signal at a fraction of the cost — a 1-minute retention of status changes instead of 10-per-second chatter.
Alert silence windows: during deploys or load tests, silence alerts by time range or by label (service, environment). Both one-off and recurring silences are supported (e.g. every Thursday 02:00–04:00 for the daily cutover). Alerts that fire during a silence are marked "silenced" in the event log for later review. No more frantically disabling rules before a release — and no more forgetting to re-enable them after.
Domestic database support: external databases now include DM8 and openGauss 3.x/5.x, joining the existing KingbaseES adapter to cover the mainstream Xinchuang databases. DM8 must be initialized with CASE_SENSITIVE=Y; openGauss needs the app subnet allowed and a higher connection limit — see the Xinchuang deployment guide for the full setup.
Other: syntax highlighting and autocomplete in the query editor; Fluent Bit 2.x compatibility in the collector; a WeCom (WeChat Work) robot channel for alert notifications.
GROUP BY aggregations over large datasets — the most-reported issue in v2.2.x, caused by an unbounded per-shard buffer during merges.To go from v2.2.x to v2.3.0, back up first, then upgrade:
jjctl backup /data/backup/$(date +%F)
jjctl upgrade v2.3.0
The upgrade runs metadata migration, index rebuild, and a storage format check in sequence; large environments should expect anywhere from 30 minutes to a few hours. Querying stays read-only throughout; writes pause briefly. Run jjctl health for a full self-check once it completes, and keep the backup until you've run a full day of production traffic on the new version.
One more thing worth flagging: the query editor's legacy "syntax" mode is now deprecated and will be removed in v2.4.0. If you still rely on it, switch to the new editor in this release while both are available — saved searches migrate automatically, but custom dashboards need a one-time re-save to pick up the new renderer.
See the CHANGELOG in the docs for the full list. If you hit issues during upgrade or onboarding, open a ticket and attach the output of jjctl diag — it bundles the compat log, the schema version, and recent ingest errors, which shortens time-to-diagnosis considerably.