Correlated Kubernetes logs and GraphQL errors in RUM

Improvements Fixes

TL;DR

See the logs of a Kubernetes pod, node or workload from its detail page, catch GraphQL calls that fail on HTTP 200, and check DynamoDB capacity per table.

Correlated Kubernetes logs and GraphQL errors in RUM

Improvements

  • Discover
    • Applications (RUM)
      • A GraphQL call that returns HTTP 200 with errors in the body used to count as a success. The Network view now counts it as a failed request, and shows its status as 200 (GraphQL error).
      • GraphQL calls recorded under a different trace were missing from the session. A new Network tab in session details lists requests from every trace in the session.
      • To find views where an API call failed, use the new Has HTTP Errors filter in session details. It keeps views with a 4xx, 5xx, or GraphQL error, and opens the APIs tab with Errors only on.
      • The Has Errors filter is now labeled Has Exceptions, which is what it matches.
      • Sessions with no views are hidden by default. Turn on Show empty sessions to list them.
      • SDK 1.6.9 tracks single-page app route changes inside an iOS WebView as views, as Android already did. See the RUM changelog.
    • Kubernetes: Reading a pod’s logs meant building the filter in Logs Explorer yourself. Node, Deployment, StatefulSet, and Pod details in Discover Kubernetes now have a Logs tab with the logs correlated to that entity, matched on cluster, namespace, and pod UID. View in Logs opens the same query in Logs Explorer.
    • Databases: For DynamoDB capacity planning, set the Database Type filter to DynamoDB in Discover Databases. Each table then shows average and peak read and write capacity, and read and write throttles.
  • Traces: Filter value lists showed only the first 1,000 values, so a value like a specific user ID was often missing. The value list now searches all values as you type, in Traces and in Applications (RUM) Sessions.
  • MCP
    • Auditing alert labels needed every alert group, not only the firing ones. The new get_alert_groups tool lists all alert groups with their labels, team, and tier.
    • The new last9-cloudwatch skill helps coding agents query CloudWatch metrics through the Last9 MCP server without guessing dimensions or statistics.

Fixes

  • AI Assistant: Asking the AI Assistant to change a dashboard it had just created made it create the dashboard again, with a new approval each time.
  • Discover
    • Services and Exceptions
      • Change event markers showed events from every environment, not only the selected one.
      • The change event hover card changed the case of label values, so INC-2291 showed as Inc-2291.
    • Applications (RUM)
      • A Sessions search with two or more filters, such as app version and device ID, could return no sessions even when one matched.
      • A session showed 0 views in the Sessions list while its details listed views.
      • A native screen was marked as a WebView when the session’s first span had a WebView type.
      • Session details left out the user ID when the Session Start span did not have it.
      • Custom events from a WebView page merged into another view did not show under that view.
      • In the Android and iOS SDKs 1.6.9 to 1.6.11 (see the RUM changelog):
        • Calling flush() during login started a new session for the same user.
        • On iOS, a WebView_shown event attached to the previous page, and a second route on the same host was skipped.
        • The page open when the app crashed or was killed was missing from the session.
        • A session could split in two when there was activity just before the inactivity timeout.
        • A native container that holds a WebView, such as a tab bar, was labeled as a WebView view.
    • Databases: Database details failed with a 502 error when a Database Type filter was set.
  • MCP: get_trace_waterfall sent a span ID passed as a trace ID to the server, and returned an unclear error.