November 2026 Summaries

Grafana Cloud positions itself as an open agentic observability platform that lets engineers access telemetry, alerts, dashboards, and other operational context through their preferred AI tools rather than working exclusively inside Grafana. Its built-in Grafana Assistant supports investigations within Grafana Cloud, while the Grafana Cloud MCP server uses the open Model Context Protocol to connect compatible agents such as Claude, ChatGPT, and Codex to observability data and, through MCP Apps, display interactive Grafana visualizations in conversations. The gcx command-line tool extends this access to coding agents such as Cursor and other shell-capable tools, enabling them to query application services, databases, frontend activity, and user sessions while retaining dashboard context such as filters, queries, and time ranges. The post also describes using an open-source agent in Slack with both MCP and gcx to investigate issues, compare historical data, and report findings with supporting links and suggested next steps, emphasizing flexibility in agent, model, provider, and working environment.

Grafana has introduced section-level variables, now generally available, and cross-dashboard variables, in public preview, to reduce dashboard clutter and simplify variable reuse. Section-level variables can be assigned to individual rows or tabs, allowing controls with the same name, such as an instance selector, to apply only to nearby panels; Grafana resolves variable definitions from the nearest section outward to dashboard scope. Cross-dashboard variables can be defined globally for an organization or within a folder and selectively enabled on dashboards, so shared settings such as environment selectors can be updated centrally while users still choose values independently on each dashboard. Local definitions take precedence over broader scopes, and cross-dashboard variables support existing variable types, URL synchronization, queries, titles, and links. They are also available as separate API resources compatible with Grafana’s Kubernetes-style API and Terraform provider, enabling configuration and provisioning as code.

Grafana Alloy v1.21.0 moves its OpenTelemetry (OTel) engine into Public Preview, offering an embedded Grafana distribution of the OpenTelemetry Collector that runs standard upstream YAML configurations, commands, deployment tooling, and service installations without Alloy-specific translation. Alloy’s default engine remains intended for flexible cross-ecosystem pipelines spanning Prometheus, Loki, syslog, and OTLP, while the OTel engine prioritizes native OTLP workflows, portability, and open standards. Recent additions include Fleet Management support through an embedded OpAMP supervisor, while an experimental alloyengine extension allows collector users to run selected default-engine Alloy components in the same process when native OTel equivalents are unavailable. Grafana Labs is testing integrations with Database Observability and Cloud Provider Observability and is collaborating with the Prometheus community to make exporters available as collector receivers. Future OTel-engine work includes support bundles and converting frequently needed Alloy components into native collector components, while default-engine development focuses on more resilient Prometheus remote write capabilities and redesigned Loki log pipelines to improve delivery guarantees, scalability, shutdown behavior, and write-ahead-log reliability.

Grafana Cloud has made trace linkage generally available in its Database Observability app, enabling users to move from OpenTelemetry application trace database spans directly to related query samples, performance history, schemas, and explain plans. The feature connects Grafana Tempo trace data with database telemetry collected by Alloy using database attributes such as query text, database system, and database name, while supporting both the stable `db.query.text` convention and legacy `db.statement` attribute. For more precise correlations, sqlcommenter can inject trace and span IDs into SQL comments, which Alloy can extract from query sample logs to identify specific executions. Because database sampling, polling intervals, unsupported engines, caching effects, and query normalization can prevent exact trace-context matches, trace linkage also uses normalized query-text matching that accounts for differing literals, placeholders, formatting, and comments. Users with existing OpenTelemetry tracing and Database Observability setups can often begin using query-text matching without additional instrumentation, then optionally add sqlcommenter for best-effort execution-level matching.

Grafana Cloud has made Instrumentation Hub generally available, providing a control plane for discovering Kubernetes workloads and selectively applying eBPF and OpenTelemetry-based instrumentation with minimal manual configuration. After installing Grafana Alloy through a single Helm command, teams can view cluster services by namespace and technology, identify instrumentation gaps, and enable or disable telemetry collection through the Grafana Cloud UI, APIs, or LLM agents. The platform supports a staged observability model that begins with infrastructure monitoring and baseline service visibility, including RED metrics and service relationships, before progressing to distributed tracing and technology-specific insights. Its new selective OpenTelemetry SDK injection aims to simplify auto-instrumentation across supported languages without requiring separate operators, custom resource definitions, application annotations, or disruptive pod restarts. Available to Grafana Cloud users with Linux-based Kubernetes clusters, Instrumentation Hub also allows teams to adjust collection levels over time to investigate issues, limit noisy logs, and manage observability costs.