Data source integrations that put self-hosted Grafana in front of logs, monitoring, search and SQL systems, using the built-in data sources and Grafana Labs plugins the Grafana docs describe.
Querying and alerting on logs from a self-hosted Loki in Grafana: the built-in Loki data source, LogQL log and metric queries, label design inherited from Prometheus, log-based alert rules and annotations, and multi-tenant setups.
Building Grafana dashboards on an existing Zabbix estate with the Zabbix app plugin: plugin installation and enablement, API user permissions, metrics, problems and triggers, SLA data, annotations from events, alerting and direct database connections.
Visualizing logs and metrics stored in OpenSearch or Elasticsearch in Grafana: the OpenSearch plugin with Lucene and PPL, the built-in Elasticsearch data source with DSL and ES|QL, supported versions, alerting on search queries, and replacing Kibana or OpenSearch Dashboards views.
Charting data that lives in PostgreSQL with Grafana's built-in data source: time series macros, the visual query builder versus raw SQL, read-only database users, alerting from SQL queries, and managed PostgreSQL services.
Using ClickHouse as a fast backend for Grafana dashboards on logs, traces and high-cardinality metrics with the ClickHouse data source plugin: SQL editor and query builder, alerting and recording rules, ad hoc filters and version prerequisites.
Adding Grafana Tempo as a trace data source: TraceQL queries, trace to logs links into Loki, trace to metrics and the service graph that needs a linked Prometheus source, and why trace alerts run on TraceQL metrics instead of the data source.
Running Grafana Pyroscope beside Grafana for continuous profiling: the core Pyroscope data source, flame graphs linked from Tempo spans, profile collection through Alloy, and where profiling helps cut CPU and memory cost.
Querying traces that already live in Jaeger or Zipkin from Grafana: the core data sources, linking traces to logs and metrics, and when teams move trace storage to Tempo instead of keeping existing backends.
Pointing Grafana at Thanos or Grafana Mimir instead of single Prometheus servers: the Prometheus data source against a Prometheus-compatible query API, global views across clusters, retention, and the Grafana 13 change that moved AWS SigV4 auth into a separate plugin.
Connecting Grafana to InfluxDB 1.x, 2.x or 3.x: choosing between SQL, InfluxQL and Flux, visual builder versus code editor, and the plugin version that stopped API tokens appearing in server logs.
Building operational and business dashboards from MySQL or Microsoft SQL Server with Grafana's core SQL data sources: read-only database users, time series macros, query load on production databases, and alerting on SQL results.
Visualizing and alerting on AWS metrics and logs with the core CloudWatch data source from a self-hosted Grafana: IAM roles versus keys, cross-account access, API request cost and combining CloudWatch with Prometheus on one dashboard.
Querying Azure Monitor metrics, Log Analytics and Resource Graph from self-hosted Grafana: app registration or managed identity, least-privilege roles, and keeping Azure and on-premises monitoring in one place.
Bringing Google Cloud Monitoring metrics into self-hosted Grafana with the core data source: service account keys versus workload identity, project scoping, and dashboards that combine GCP and on-premises data.
Running Grafana on an existing Graphite metrics store: the core Graphite data source, which shared dashboard and transformation features Graphite does not support, and when to plan a move to a Prometheus-compatible backend.
Using the Infinity plugin to chart data from REST APIs, JSON, CSV and XML endpoints that have no dedicated data source: authentication, backend parsing for alerting, and when a small custom data source plugin is the better choice.
Deploying Grafana Alloy as the collector for a self-hosted Grafana stack: one OpenTelemetry Collector distribution with Prometheus pipelines for all four signals, component-based configuration, and where it replaces separate agents.
Planning a self-hosted Grafana observability stack with Loki for logs, Tempo for traces and Mimir for metrics: how the pieces connect, which links Grafana builds between signals, licensing, and what each component costs to run.
Sending OpenTelemetry data from instrumented applications into a self-hosted Grafana stack: OTLP into Alloy, routing traces to Tempo, logs to Loki and metrics to a Prometheus-compatible store, and correlating them in Grafana.
Monitoring Kubernetes clusters with self-hosted Grafana: collecting cluster and workload metrics into a Prometheus-compatible store, logs into Loki, the dashboards and alerts operators need first, and multi-cluster views.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.