Let the Sazabi agent query Grafana Cloud with PromQL and LogQL

Last verified on Nov 8, 2026.

Grafana Cloud usually sits in front of Prometheus metrics, Loki logs and Tempo traces, with dashboards and alert rules on top. The Grafana connector lets the Sazabi agent, part of Sazabi's AI-native observability and security platform, read all of that during an investigation. It does not copy the data into Sazabi. The agent asks Grafana at question time.

What the Sazabi agent can do with Grafana

The connector uses Grafana's hosted Cloud MCP server at mcp.grafana.com/mcp. It authenticates with OAuth 2.1 and dynamic client registration, so you approve access in the browser instead of pasting a token. Once connected, the agent can:

• browse dashboards and panels, and read the queries behind them
• run Prometheus and Loki queries and inspect Tempo traces across connected data sources
• review alert rules, firing alerts and on-call schedules
• pull incident and Sift investigation context into a thread

Grafana's reference names the tools. For metrics there are list_prometheus_metric_names and query_prometheus, which runs PromQL instant or range queries. For logs there are list_loki_label_names and query_loki_logs, which runs LogQL. Tempo tools come from your own Tempo data sources, which the Cloud MCP server proxies.

Access has levels. Read access covers browsing Grafana and querying Prometheus, Loki, Tempo and Pyroscope. Raw SQL-style queries need a separate query grant, and your existing Grafana permissions still apply to every call. The account that authorizes needs a role granting grafana-assistant-app.cloud-mcp:access.

Questions it answers

• Which dashboard panel shows this service's error rate, and what query feeds it?
• What does query_prometheus return for request latency over the last hour?
• Which Loki label values exist for this namespace, and which show errors?
• Which alert rules are firing right now, and who is on call?
• Does a Tempo trace exist for the request ID in this support ticket?

A worked example: turning a firing alert into a query

An alert fires on checkout latency and you open a Sazabi thread. You ask in plain language:

Which Grafana alert rules are firing for the checkout service? For the first one,
show the PromQL behind it, run it for the last 30 minutes, then pull the Loki
error logs for the same namespace.

The agent can read the alert rule, take its query from the rule, and call query_prometheus with it. A query like this would come back:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m])) by (le))

Next it lists label names with list_loki_label_names, picks the namespace label, and runs a LogQL query through query_loki_logs:

{namespace="payments"} |= "timeout"

You read the result as a chain. If the latency curve rose at the same minute the timeouts began, the cause is probably in that namespace, and the next step is to ask about recent deploys. If the curve rose without a log signature, ask for Tempo traces over the same window. If no tools show up at all, check the connector page: the missing piece is usually the grafana-assistant-app.cloud-mcp:access action on your account, and disconnecting and re-authorizing fixes a stale grant.

How it fits with other integrations

If your pipeline runs through Alloy, the Grafana Alloy page covers how to send logs and traces to Sazabi directly, and the Prometheus page covers metrics from a scrape. Sazabi can also query other stacks, such as Datadog or Honeycomb. Browse observability tools for the rest, or see OpenTelemetry for the protocol underneath.