When a logs pipeline includes an aggregate step (like count() over 5m), the UI used to show only the count chart — to see the actual log lines behind a spike you had to manually strip the aggregate step back out. Now the top 5 contributing log lines appear right below the chart, most recent first, each with its timestamp, severity, and message, plus a “View all matching logs” link that opens the full filter-only query. This is especially handy when you land on the logs screen from an aggregate-based alert.
Improvements
- Traces: Non-timeslice trace aggregations now have a Create Metric button, matching the logs-to-metrics flow
- Alerting: The alert rule timeline supports drag-to-zoom, instead of only selecting a range from the date picker
- Applications (RUM)
- Mobile custom events (
addEvent) now emit OTLP logs in addition to trace events, so mobile funnel markers show up in Logs the same way browser RUM does - Browser RUM can now disable traceparent headers when needed, with documentation
- Mobile custom events (
- Discover Kubernetes: Deployment Events now include ConfigMap and HPA subjects, and detail pages (Deployment, Pod, Node, StatefulSet) show the cluster name in the breadcrumb
Fixes
- Logs: The log chart tooltip overflowed its container
- Alerting
- Scheduled-search alerts saved with a custom aggregate alias (not
result) could silently never fire - The scheduled-search Slack log preview queried a window offset roughly 60 seconds from the evaluation window, so it could miss matching logs from the last minute
- Scheduled-search alerts saved with a custom aggregate alias (not
- Dashboards
- Time series charts didn’t render in bar view on some tenants
- PromQL empty-state operators were incorrect, and a Kubernetes deployment fetch was duplicated
- Discover Services: The Apdex chart showed
0instead of an empty state when there were no requests