OBSERVE v2.8.0: Continuous Profiling, Alert Root-Cause Analysis, and Domestic Database Slow-SQL Monitoring

New: Continuous Profiling

The headline feature in v2.8.0 is continuous profiling. A low-overhead agent samples stack traces every 60 seconds by default and records each process's CPU, memory allocation, and lock wait as flame graphs. When something breaks you no longer attach pprof after the fact — just rewind through the last 15 minutes of stack snapshots.

JVM, Go, and Node.js runtimes are supported, with CPU sampling overhead under 3%, so you can leave it on in production. Profiling also ties into alerting: when a metric alert fires, OBSERVE automatically captures a 5-minute flame-graph snapshot around the incident. That turns every alert into a replayable piece of evidence instead of a bare number.

Alert Root-Cause Analysis: From Alert to Function

Alerts used to tell you only "CPU is high," leaving you to dig for the cause yourself. Now the alert detail page embeds the relevant flame graph: open an alert and you can see exactly which function is burning CPU or which object is eating memory during the trigger window. Going from "metric anomaly" to "line of code" is now one click.

This is especially useful for on-call engineers: at 3 a.m., instead of logging into a server and running tools, you check the flame graph on the alert page first. Most of the time that narrows it to the suspect function, and the rest goes to the developer for reproduction. It doesn't replace root-cause work — it moves the expensive part (finding where to look) into the alert itself.

Better Slow-SQL Monitoring for Domestic Databases

We added targeted improvements for DM8, KingbaseES, and OceanBase:

• Slow-SQL capture no longer depends on the database's own slow log; it pulls active SQL and execution plans through extension views;
• Two new dashboards — "slow SQL trend" and "top SQL" — sort by duration, execution count, and rows scanned;
• You can link a slow SQL's traceId back to the business trace, so from one slow query you can find which endpoint and which user triggered it.

We've adapted to DM's V$SQL_HISTORY and KingbaseES's pg_stat_statements views, so teams migrating to domestic databases can turn this on right away without building their own collectors.

Upgrade Notes and Compatibility

Three things to check before upgrading:

1. The collection agent must be upgraded to 2.8.0 — older agents produce profiling data in an incompatible format;
2. Continuous profiling is on by default; disable it in config if your hosts are resource-constrained;
3. DM/KingbaseES slow-SQL capture requires a database account with read access to the relevant views — grant it once after upgrading, per the docs.

v2.6 and v2.7 can rolling-upgrade directly; data and alert configs are backward compatible and no migration is needed. See the docs center for the full changelog, including the smaller fixes and behavior changes.

Since profiling is the biggest change, two operational details are worth planning for. First, storage: continuous profiling generates a steady stream of flame-graph data, and while per-sample overhead is low, the aggregate grows quickly. Review the retention (we default to 7 days of hot flame-graph history) and align it with your postmortem window rather than leaving the default. Second, permissions: flame graphs reveal function names, file paths, and occasionally environment variables from a production process — treat them as sensitive data and scope access with the same RBAC you apply to logs.

If you're on v2.6 or v2.7, the rolling upgrade is straightforward, but upgrade the agent first and smoke-test a single host before rolling it out fleet-wide. The full changelog, migration guide, and a ten-minute profiling walkthrough are all in the docs center, and we'll keep shipping profiling improvements in the 2.8.x line based on the feedback from these first production deployments.