JJWhale OBSERVE v2.8.0 Release Notes

v2.8.0 focuses on log search, alert quality, and xinchuang support. This is a minor release in the sense that it needs no storage migration and introduces no breaking API changes, but the log aggregation and alert improvements change day-to-day workflows enough to deserve a closer look. If you are still on v2.7.x, the upgrade is low-risk, reversible in a single command, and worth doing soon so the new query and alerting behavior is available the next time you need it. Here is the full rundown.

New Features

• Log pipeline aggregation: the search syntax adds pipeline operators such as | stats, | sort, and | limit, enabling server-side grouping and aggregation without exporting logs and writing a script. A typical expression such as service = "order-api" AND level = "ERROR" | stats count() by error_code | sort count desc | limit 10 returns the top ten error codes in a single query.
• Alert aggregation and noise reduction: alerts sharing a root cause are merged automatically, with silence windows and severity tiers to cut down alert storms. Alert rules now accept the same search syntax directly, so the condition is always exactly the query you tested.
• Xinchuang ARM64 support: full support for Phytium and Kunpeng paired with UnionTech UOS and Kylin V10, including domestic SM crypto options.
• Query performance: archived history data now reads through columnar storage, cutting average slow-query latency by roughly 40%.

Using the New Pipeline Aggregation

The pipeline syntax is available in the log search page and anywhere a log query is accepted. To try it, open search, pick a service, and run:

service = "order-api"
| stats count() by status
| sort count desc

This shows the distribution of HTTP status codes for the service, ranked. Chain more stages to refine the result: add | limit 5 for the top five, or | stats p99(latency) by endpoint to find the slowest endpoints. Any pipeline you build can be pinned to a dashboard or converted into an alert rule, exactly like a plain query. For very large result sets, keep your filters before the | so aggregation only sees the rows you care about — that is the main thing that keeps a pipeline query fast.

Improvements

• Metric dashboards support custom time-over-time comparison for easy period-over-period and year-over-year views.
• Tracing supports secondary filtering by service.name and custom labels.
• Log ingestion adds batch import, so historical logs can be loaded offline.
• The collector now parses OTLP resource attributes at finer granularity, aligning traces and metrics per service more accurately.

Bug Fixes

• Fixed occasional data loss in the Collector under high concurrency.
• Fixed an 8-hour offset in time-range queries for certain timezones.
• Fixed a chart layout glitch in some browsers.

Compatibility and Known Issues

This release does not change the storage format, so historical data from v2.7.x requires no migration. One known limitation: a single pipeline aggregation with more than 100,000 grouping keys may be rate-limited, so add filter conditions to narrow the scope first; this limit will be relaxed in v2.9. No public APIs were removed, and all v2.7.x configuration files remain valid.

Upgrade Steps

To upgrade from v2.7.x to v2.8.0:

# 1. Back up config and metadata
jjhctl backup --output /backup/v2.8.0

# 2. Pull the new image and roll
jjhctl upgrade --version 2.8.0

# 3. Verify service health
jjhctl status

Run a regression pass in staging after the upgrade, focusing on log search and alert rules. If you use custom collection plugins, recompile them against the v2.8.0 interface changes. If you need to roll back, jjhctl rollback --version 2.7.x returns to the previous release in one step.

What's Next

Work on v2.9 is already underway. The two items near the top of the roadmap are relaxing the 100,000-key aggregation limit and adding richer multi-condition alert routing, so a single rule can fan out to different channels depending on the affected service. If you hit anything with v2.8.0, reach out through the support channel with your query and a sample of the data — concrete reproduction cases are what let us fix things quickly.