v2.5 adds log clustering anomaly detection, history-based forecast alerts and cross-cluster federated queries, plus improvements to Chinese tokenization and alert notifications, with a batch of fixes.
In a sea of logs, what really deserves attention is often a "new pattern" drowning in the noise. v2.5 clusters error logs in real time, groups highly similar lines together and sorts them by frequency. When one error type jumps from dozens of occurrences an hour to thousands, the cluster surfaces at the top instead of scattering across hundreds of thousands of lines.
cluster:
enabled: true
source: error_logs
similarity: 0.85
window: 5mClustering only surfaces and highlights — it never discards the raw logs. Click any cluster and you can expand to the individual lines. For high-volume teams this is the fastest entry point for "unknown failure" investigations. Start the similarity threshold at 0.85: lower it if clusters are too fragmented, raise it if they are too coarse.
Clustering complements, rather than replaces, keyword search. Use search to find a known failure fast, and clustering to notice a failure you did not know to look for. Teams that start with clustering on error logs typically find one or two recurring errors they had been ignoring for weeks.
Fixed-threshold alerts have a well-known flaw: daytime and nighttime traffic baselines differ, so a single threshold either pages falsely during the day or misses real problems at night. v2.5 adds history-based forecast alerts — the system learns upper and lower bounds from the metric's distribution over the same period in past weeks, and fires when the actual value deviates significantly from the predicted band.
alert:
name: order-qps-anomaly
type: forecast
metric: order_qps
sensitivity: 3
lookback: 4wsensitivity controls how many standard deviations count as anomalous; higher means less sensitive. Forecast alerts suit metrics with a clear daily or weekly cycle. For flat, steady metrics a traditional threshold is still more direct — the two coexist, so you do not have to pick one.
Forecast alerts need history before they are useful: with fewer than two or three weeks of data the learned band is wide and the alert will be noisy in both directions. Leave a new forecast rule in a learning state for a couple of weeks, review what it would have fired on, then enable it. On holiday weeks, where traffic patterns break their normal shape, expect forecast alerts to fire more — that is usually correct, not a false positive.
When separate observability platforms run in multiple data centers or domestic-computing environments, you used to have to switch platforms to see the data. v2.5 lets you register sub-clusters with a central platform and run cross-cluster queries from the center, aggregating by cluster and drilling down into a single cluster's detail. Data stays in its own cluster — nothing is centrally stored — which suits groups and multi-site deployments.
Federated queries keep data in place, but authentication spans clusters. The central platform holds credentials for each registered sub-cluster and re-issues queries under the operator's identity, so the audit trail records who asked and which clusters were touched. Configure per-cluster query timeouts, because a slow cluster should degrade its own queries rather than stall the whole federation.
This release is backward compatible; no configuration changes are required. Log clustering and forecast alerts are optional and off by default after upgrade — enable them in the console as needed. Run a regression pass in a test environment first, then roll the production nodes.
If you are already on v2.4, this upgrade is low risk: the only behavioral changes sit behind the new optional features. Teams using tail sampling should sanity-check a few traces after upgrading, since the clustering pipeline now runs alongside the sampling decision and both read span attributes.
For federated deployments, roll cluster by cluster and upgrade the central platform last, so older sub-clusters keep answering during the transition.