OBSERVE v3.3.0 ships high-cardinality metric aggregation and write throttling, deeper DM8 and KingbaseES monitoring with slow-query collection, and label-based alert aggregation with policy-driven on-call escalation. Includes configuration examples and upgrade notes.
OBSERVE v3.3.0 is out. This release focuses on three things: turning high-cardinality metrics from a hidden cost into a controlled resource, deepening domestic database monitoring, and making alert aggregation actually cut on-call noise. Here's the breakdown, plus the upgrade notes you'll want before rolling it out. If you've been waiting for a release that treats metric cardinality as a first-class operational concern rather than an afterthought, this is it.
Previously, a service that stuffed a user ID or order number into metric labels could blow up time-series storage, hurting both the bill and query performance. v3.3.0 enables high-cardinality detection by default: labels whose cardinality exceeds a threshold are automatically reduced to Top-N plus an aggregated "other," and writes over the limit are throttled — writers get an explicit drop counter instead of silent loss. The admin UI adds a "metric cardinality" dashboard ranking label cardinality by service, so you can see at a glance who's abusing labels. Thresholds are configurable per label, and genuinely high-cardinality use cases can be added to an allowlist so the guardrail doesn't get in the way of legitimate needs. Detection runs on a sliding window rather than a one-time scan, so a label that spikes during a promotion is caught and rolled up while the traffic lasts, then returns to normal without anyone reconfiguring anything.
Monitoring for DM8 and KingbaseES is further rounded out: new slow-query collection captures full SQL text and execution plans by execution-time and logical-read thresholds, and new built-in metrics cover lock waits, connection counts, and tablespace usage. The collector connects over standard JDBC with nothing installed inside the database:
database_exporter:
- type: dm8
jdbc: "jdbc:dm://10.0.8.30:5236"
slow_query_threshold_ms: 1000
- type: kingbase
jdbc: "jdbc:kingbase8://10.0.8.31:54321/observe"
slow_query_threshold_ms: 500Captured slow queries are automatically linked to the application traces that called them, so clicking a slow SQL drills down to the corresponding trace and host — moving you straight from "it's slow" to "why it's slow" without opening a second tool. The JDBC collector supports connection pooling and per-instance scrape intervals, and it degrades gracefully: if a database goes down, the exporter keeps the last known metric values for a configurable grace period and emits an up=0 marker rather than a gap that looks like missing data. Both exporters also honor the platform's credentials store, so database passwords don't have to live in plain text in the collector config.
Alerts can now be aggregated by label: alerts from the same host group, warehouse, or business unit collapse into one, with configurable aggregation window and interval. On-call escalation moves from a fixed hierarchy to policy-driven: automatic escalation when unacknowledged within a time window, different on-call groups per alert severity, and different notification channels for holidays and off-hours. Failed escalations fall back to SMS, so a gap in the on-call roster no longer means nobody gets paged. Aggregation also applies to deduplication: an alert that fires, clears, and refires inside the window is collapsed into a single notification with a count, so a flapping service produces one page with "fired 14 times" instead of fourteen separate pages. There's also a weekly digest report for teams that prefer a summary over per-alert notifications.
Upgrading from v3.2.x to v3.3.0 is smooth — the collector and backend protocols are compatible. Upgrade the backend first, then roll the collectors. Two behavior changes to note: high-cardinality throttling is on by default, so services that genuinely need high-cardinality labels must add an explicit allowlist on the collector; and slow-query collection is off by default, to be enabled in the collector config as needed. Also in this release: a batch of fixes for the SQL query engine (several edge cases around nested aggregation), improved OTel semantic-convention support so resource attributes map cleanly onto the new topology view, and a fix for a rare collector restart loop when the disk buffer path sat on a full filesystem. As always, take a config backup before upgrading and watch the collector error counters for the first hour after rollout. See the docs' Release Notes for the full changelog.