Grafana Cloud

Grafana Cloud bundles managed Prometheus (Mimir), Loki (logs), Tempo (traces), and Grafana (dashboards) into a hosted observability platform. For agents, the key advantage is open-standard compatibility: agents already emitting Prometheus metrics, writing logs in Loki format, or generating OpenTelemetry traces can point at Grafana Cloud endpoints without vendor-specific SDKs. The HTTP API supports PromQL queries over metrics, LogQL over logs, and TraceQL over traces. Dashboard management via JSON API enables agents to create and manage dashboards programmatically. The free tier (10K metrics, 50GB logs, 50GB traces) is generous enough for development and small production workloads. Alerting via Grafana Alerting or Mimir rules provides programmatic alert management.

API authentication uses Grafana Cloud API keys or service account tokens with configurable role-based permissions (Viewer, Editor, Admin). Access policies can scope tokens to specific resources (stacks, metrics, logs, traces). For data ingestion, Prometheus remote_write uses a username (instance ID) + API key as Basic Auth. Loki push uses the same pattern. This means agents need different credentials for querying (Grafana API key) versus ingesting (stack-scoped credentials). No OAuth for programmatic access. Grafana Cloud supports SAML/OIDC for console SSO. The access policy model is more granular than many monitoring platforms — agents can be scoped to read-only metrics access without dashboard or admin permissions.

Documentation benefits from the massive open-source Grafana ecosystem — PromQL tutorials, Loki query guides, and dashboard best practices are available from both Grafana Labs and the community. Official docs at grafana.com/docs cover managed and self-hosted configurations, which can be confusing — agents should filter for Cloud-specific content. API reference documentation is comprehensive for the Grafana HTTP API. The Grafana Play demo instance provides a sandbox for experimenting with queries and dashboards. Client libraries for Prometheus metrics (prom-client for Node, prometheus_client for Python) are widely used and well-documented. The ecosystem advantage is real: agents already instrumented with Prometheus or OpenTelemetry can adopt Grafana Cloud with minimal code changes.

Grafana Cloud's API surface follows the open-source tools it hosts. Metrics queries use the Prometheus HTTP API at /api/v1/query and /api/v1/query_range with PromQL — agents familiar with Prometheus query the same way. Log queries use the Loki API with LogQL. Trace queries use the Tempo API with TraceQL or direct trace ID lookup. Dashboard CRUD uses the Grafana HTTP API with JSON dashboard definitions. Alerting rules are managed via the Grafana Alerting API or Mimir Ruler API. Data ingestion uses Prometheus remote_write for metrics, the Loki push API for logs, and OTLP for traces. Each subsystem has its own API conventions, which means agents interacting with multiple data types must handle multiple API patterns.

Prometheus API errors return JSON with status: 'error' and errorType/error fields. PromQL query timeouts return 422 with descriptive messages. Rate limits on data ingestion are per-instance with configurable limits shown in the usage dashboard. Loki push errors include rate-limit-specific status codes (429) with Retry-After headers. The main operational concern for agents is cardinality limits on metrics — high-cardinality label values can cause ingestion rejection. Grafana Cloud publishes usage limits clearly in the pricing documentation. Alert evaluation runs on configurable intervals (default 1 minute). Dashboard save conflicts return version mismatch errors that require fetch-then-update patterns.