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

OBSERVE v2.7.0: Native OpenTelemetry Logs and eBPF Flame Graphs

v2.7.0 release notes: native OpenTelemetry Logs, eBPF flame graphs, an alert rule test bench, 70% faster concurrent alert evaluation, and Xinchuang compatibility fixes.

Overview

v2.7.0 delivers the two things promised in the last major release: native OpenTelemetry Logs support and eBPF flame graphs. It also includes alert-engine performance work and a batch of Xinchuang compatibility fixes. Read "Upgrade notes" before you upgrade — this release changes how logs can be ingested, so the order in which you upgrade the gateway and the platform matters.

New features

  • Native OpenTelemetry Logs: logs can now be reported directly over OTLP (gRPC or HTTP), with no file-collection Agent required. Java, Go, and Python SDKs send logs straight to the platform, with fields, resource attributes, and trace correlation arriving together — which removes the file-tailing middleman and the parsing drift that comes with it. If you already run the OTel SDK for traces, flipping on the logs exporter is a config change, not a re-architecture;
  • eBPF flame graphs: CPU and memory flame graphs for hosts via eBPF, with no application instrumentation and no restart. You get process-level hotspots — which function is burning CPU, which allocation is growing — without touching a single service;
  • Alert rule test bench: before saving a rule, replay it against historical data to see whether it false-positives or false-negatives. This closes the loop that previously forced teams to ship a rule and wait for the next real incident to find out it was wrong;
  • Log field redaction rules: built-in templates for phone numbers, ID numbers, and bank card numbers mask sensitive data at ingest, so it never reaches storage. This matters for any team under data-protection review, because "we never stored it" is a much simpler answer than "we stored it and rely on access controls."

Performance improvements

  • The alert evaluation engine moved from serial to concurrent evaluation; average evaluation time for 1,000 rules dropped by about 70%. If your rule count has grown past a few hundred, this is the change you'll feel first;
  • The OTLP receiver adds batch-write merging, keeping memory steadier under high-concurrency ingestion — the spikes that used to cause GC pauses on the ingest path should largely disappear;
  • The columnar read path for log search was optimized, cutting large-result-set pagination latency by about 40%. This is most visible on the "export everything from last week" style queries that used to time out.

Bug fixes

  • Fixed eBPF program load failure on Kylin V10, where a kernel symbol difference prevented the BPF program from attaching;
  • Fixed init-script errors for Dameng in case-sensitive mode, so fresh installs on a case-sensitive database no longer fail partway through;
  • Fixed a cross-tenant query authorization bypass under certain boundary conditions — a security fix, and one we recommend upgrading for promptly rather than waiting for the next maintenance window;
  • Fixed silence windows miscalculating across day boundaries, where a silence ending at 01:00 could leak alerts for an extra hour;
  • Fixed occasional loss of trace_id correlation when reporting OTLP logs, which manifested as logs that couldn't be reached from their trace.

Upgrade notes

  1. Back up config and database first. There's no index format change, so no reindex is needed — this is a faster upgrade than v2.6.0;
  2. Before enabling OpenTelemetry Logs, confirm the collection gateway is on the same version, or log protocol parsing will fail at the gateway;
  3. eBPF flame graphs need kernel 4.18+ (Kylin V10 satisfies this by default) and root to load eBPF programs — note the privileged flag for containerized deployments;
  4. A new config item alert.eval_concurrency (default 8) controls evaluation concurrency; raise it for large rule sets, but watch CPU on the alert node;
  5. After upgrading, run a smoke test: send an OTLP log, replay a rule, and view an eBPF flame graph.

Known issues

  • eBPF flame graphs show host processes only in containers for now; container-process mapping lands in the next patch;
  • If an OTLP log's body field is non-string, full-text search isn't available yet — convert it to a string in the SDK before reporting;
  • Rule replay approximates "for duration" semantics, so treat its results as reference, not production behavior. A rule that looks fine in replay can still behave differently against live load.

Roadmap

v2.8.0 planning starts now, with two priorities: alert root-cause analysis (auto-correlating alerts with traces and logs, and ranking likely root causes instead of making the on-call engineer hand-stitch them), and natural-language-to-SQL for log search, so people who don't write SQL can still ask the logs a question. If you have opinions on either, vote on the issue board — it genuinely shapes what we build next.

Try for free Contact