Grafana and Graphite integration: what the core data source gives you
If your organization already runs a Graphite metrics store and wants those series in self-hosted Grafana, the core Graphite data source is the place to start. Grafana lists Graphite among its core data sources in the metrics and time series category, so it ships with the product and does not need a separate plugin install. The question this page answers is what that connection gives your teams, what it leaves out, and when a move to a Prometheus-compatible backend deserves a place in the plan.
The core data source lets Grafana panels query Graphite metrics directly, so existing Graphite series can sit next to other data sources on the same dashboard. That is the main value for an estate that is already built around Graphite: teams keep their metric names, retention and collection agents while gaining Grafana's dashboards, panel options and alert rules over the same data. Before you commit, confirm the Graphite version and API access your team will use, and check which functions your existing dashboards depend on, since the query editor and function set are what your engineers will spend most of their time with.
The limits matter as much as the gains. Graphite is listed as unsupported for externally shared dashboards, so any dashboard that must be shown to people outside your identity boundary needs a different data source or an internal sharing model. Filtering data by query refId is not available for Graphite in transformations, which affects dashboards that depend on combining or narrowing several queries inside one panel. Treat these as design constraints when you map dashboards, and ask whether your roadmap includes a Prometheus-compatible store, since that decision changes how much Graphite-specific work you should invest in now.
What you need before connecting Grafana to Graphite
Connecting Grafana to Graphite is a small technical step, but the surrounding decisions take longer: which Grafana release you run, where its configuration lives, how traffic reaches the Graphite endpoint, and who answers for that endpoint. Settle these four items before you add the data source so the integration does not become the thing that changes everything else.
Grafana version and deployment mode
Confirm which Grafana release you run and how it is installed, whether from packages, containers or Helm charts. Grafana publishes a new minor release every other month and patch releases at least monthly, and each minor release is supported for 9 months. Pick a release inside its support window, and record the install method so upgrades and rollbacks follow the same path as the rest of your Grafana estate.
Production-grade configuration database
Grafana stores its configuration in SQLite by default, but the installation docs state SQLite does not scale for production. Plan MySQL 8.0 or later, or PostgreSQL 12 or later, before you rely on dashboards and data source definitions that people depend on. Data source credentials and dashboard definitions live in that database, so its backup and restore process belongs in the plan.
Network path to the Graphite endpoint
Grafana queries Graphite over HTTP, so the Grafana server, or every node in a highly available pair, must reach the Graphite web or render endpoint directly. Check firewall rules, DNS resolution, proxy settings and any TLS certificate chain Grafana must trust. Test from the Grafana host itself, not from your workstation, because the path that matters is the one Grafana uses at runtime.
Ownership of the Graphite query endpoint
Decide who operates the Graphite web or render endpoint Grafana will query, and who approves changes to it. A change to the endpoint, its version or its authentication can break dashboards and alerts that look healthy from the Grafana side. Name an owner, agree on a change process with the team that runs Graphite, and confirm who is on call when a query fails.
Graphite version and API details
Confirm the Graphite version and the API your distribution exposes with its vendor or maintainers, since query syntax, function support and authentication depend on that release. No version details are fixed here, so do not assume a particular API surface. Ask for the exact endpoint URL, the query functions your dashboards use, and whether the endpoint sits behind a reverse proxy that changes its behavior.
Access model for Grafana users
Decide how Grafana users reach the Graphite data source and which accounts Grafana uses to query it. Shared service credentials are simple but give every Grafana user the same reach into Graphite. Confirm which access controls your Graphite endpoint supports, and check which Grafana edition and sign-in method you need for user-level control, since SAML and team sync are Enterprise features.
How to configure the Graphite data source in Grafana
This sequence connects a self-hosted Grafana instance to an existing Graphite metrics store, proves the connection with known series, and confirms that authentication and query results behave as expected before any dashboard is shared.
Confirm network path and Graphite endpoint
The Grafana server, not the browser, opens the connection to Graphite, so the platform or network team confirms that the Grafana host can reach the Graphite web or API endpoint on the agreed port, and that any proxy, firewall rule or DNS entry between them is in place. Ask the Graphite owner for the base URL, whether it is served over HTTPS, and whether it sits behind a reverse proxy that changes paths. Done means a request from the Grafana host itself returns a response from Graphite, and not only from an engineer's workstation.
Add the core Graphite data source
In Grafana, an administrator opens the data source configuration, selects the core Graphite data source from the metrics and time series category, and enters the Graphite URL. Use a name that tells dashboard authors which environment the data belongs to, because data source names appear in every panel and are hard to rename later without touching dashboards. Save the data source only after the URL is reviewed, since saving does not prove the connection yet.
Set authentication and Graphite-specific options
Choose the access method the Graphite owner supports, such as basic authentication or no authentication on an internal-only endpoint, and store any credentials in Grafana's secure fields rather than in the URL. Review the Graphite version and the query and autocomplete options the data source offers, and set them to match the Graphite installation, because mismatched settings produce incomplete function lists or unexpected query results. Confirm the exact fields and their behavior against the current Grafana data source documentation for your version. Done means the settings are saved with credentials held in secure fields.
Run the connection test and a failed-auth check
Use the save and test action on the data source page. A successful result reports that the data source is working. Then, in a non-production copy or with a deliberately wrong password, repeat the test to confirm that Grafana returns a clear authentication or connection error rather than a silent empty result. This negative test shows that the credential is actually being checked and that failures will be visible to the team. Restore the correct credential before continuing.
Build a test query against known series
In Explore, select the new Graphite data source and run a query against a metric the Graphite owner has named and whose value is known, such as a counter that the team can compare with the source system or a series that a test job writes on a fixed schedule. Check that the series returned match the metric path, that the time range is aligned, and that the values are close to what the source reports. Record the query text so it can be reused in a panel and in review. Done means the known series appears with the expected name and approximate values.
Verify panels and time range behavior
Create a dashboard panel with the verified query, then change the dashboard time range and refresh interval to confirm that Graphite returns data points for each window and that gaps are displayed where the source has no data. Compare one panel value with the same value read directly from Graphite for the same interval. Note any functions that Graphite does not return consistently, because differences here are easier to fix now than after dashboards are shared. Done means the panel values match the direct read for at least one interval.
Record the configuration for review
Document the data source name, URL pattern, authentication method, secure field locations, and the known-series test queries in the team's runbook or in the provisioning files used for this Grafana instance. Store the verification queries with the expected results so that a later upgrade or Graphite change can be checked against the same baseline. Done means a second engineer can repeat the connection test and the known-series check from the written record alone.
Which Grafana features Graphite does not support
Externally shared dashboards let Grafana publish a dashboard through a link to people who do not have an account on your instance, such as partners, customers or external auditors. Graphite is listed as unsupported for this feature, so a dashboard whose panels query Graphite cannot be published this way. Treat any Graphite dashboard as internal from the start and confirm the current list in the shared dashboards documentation.
- Affected audience: Anyone outside your sign-in boundary who expects a public link will not receive working Graphite panels.
- Design-time decision: Decide during dashboard design whether an external audience is needed, so you do not build a Graphite dashboard that must be rebuilt later.
- Mixed dashboards: A dashboard that combines Graphite with another source may not be eligible, so test that combination before you promise access.
- Duplicated work: If an external view is required, teams often rebuild panels on a supported source, which means two sets of queries to maintain.
Before you commit to an external audience, check the support list for your Grafana version and test with a non-production dashboard.
Grafana transformations can filter data by query refId, which lets a panel with several queries keep only the results from one chosen query. Filtering by refId is not available for Graphite, so a Graphite query cannot be isolated this way inside a multi-query panel. The effect is on how you structure panels, not on the data itself. The transform data documentation describes the transformations available in each version.
- Combined panels break down: A panel that depends on refId separation cannot be built with Graphite queries in the same panel.
- Panel sprawl: Splitting each query into its own panel multiplies panels, which slows dashboard load and makes review harder.
- Rework on migration: If you later move to a Prometheus-compatible backend, panels built around refId filters will need to be rebuilt or revalidated.
- Other transformations: Confirm which transformations work with Graphite in your version, since the refId limit does not automatically cover every transformation.
Test each transformation chain on a staging copy of the dashboard before you hand it to a team, and document which panels depend on separate queries.
Graphite is a core Grafana data source, so dashboards that query it can be shared with colleagues who sign in to the same instance. Sharing inside the organization is the ordinary model, and the limit described on the other tabs is about reach beyond your sign-in boundary. Who sees a dashboard depends on your folder permissions, team assignments and the access your Graphite service grants to the Grafana service account, which you should confirm with your Graphite administrators.
- Folder-based access: Place Graphite dashboards in folders that match team ownership so visibility follows your access model.
- Team ownership: Assign an owning team to each dashboard so changes and questions have a clear route.
- Service account scope: Check what the Grafana connection can read in Graphite, since it sets the data every viewer sees.
- Shared query load: Many viewers on heavy Graphite queries add load to the metrics store, so review refresh intervals on popular dashboards.
Before you rely on internal sharing, verify folder permissions and the Graphite connection with a user from each team who will use the dashboards.
For most teams, the practical workaround is to keep Graphite dashboards inside your authentication boundary and to publish results to outside audiences through a path you control. Grafana's authentication options let you require sign-in for every viewer, which removes the need for public links. If an external requirement is firm and cannot be met inside your boundary, plan a migration to a Prometheus-compatible backend, where the sharing and transformation options should be checked again before you commit.
- Internal-only access: Require sign-in through your identity provider so every viewer is authenticated, as described in the authentication documentation.
- Controlled exposure: Restrict network access to the instance with your reverse proxy or firewall, and avoid placing dashboards behind unauthenticated routes.
- Owner-issued reports: Let dashboard owners send scheduled exports or screenshots to outside parties, if your policy allows that channel.
- Versioned copies: Keep dashboard definitions in version control so a rebuilt copy on a supported source matches the original.
- Migration trigger: Set a decision point for moving to a Prometheus-compatible backend if external sharing becomes a permanent requirement.
Confirm each workaround with your Grafana version and your security team before you publish any dashboard outside your organization.
How Graphite metric paths map to Grafana queries and dashboards
This table maps Graphite concepts such as metric paths, tags, functions and template variables to the Grafana fields where you use them. Read each row as a checklist of what to confirm against your own Graphite version and naming scheme before you build dashboards. The main takeaway is that the mapping is straightforward for paths and functions, but dashboard sharing and some transformations behave differently for Graphite than for Prometheus-style backends.
| Graphite concept | Where it appears in Grafana | What to verify in your environment |
|---|---|---|
| Metric path (dot-separated name) | Graphite data source query editor, metric path field | Confirm your naming scheme is consistent across hosts and services, since every panel depends on it |
| Wildcards and braces in paths | Metric path field with pattern matching | Test each wildcard against the live metrics tree to confirm it returns the series you expect |
| Graphite functions (for example, sumSeries or averageSeries) | Function editing in the query editor | Check that each function you use exists and behaves the same in your Graphite version |
| Tags (where used) | Tag-based series selection in the query editor, if enabled on your store | Confirm whether tagging is enabled in your Graphite deployment and how tags are applied to existing series |
| Template variables | Dashboard variables that substitute into metric paths and function arguments | Verify that variable values return correct series and that multi-value selections expand as intended |
| Panel time range and intervals | Panel time settings and query interval options | Confirm retention and rollup settings in Graphite so the interval you choose returns data at the resolution you expect |
| Transformations on query results | Transform tab, including filtering by query refId | Filtering by query refId is not available for Graphite, so plan alternative transformations or query structure |
| Shared or public dashboards | Dashboard sharing settings | Graphite is not supported for externally shared dashboards, so plan access through authenticated users instead |
Securing the Graphite connection in self-hosted Grafana
A Graphite data source gives Grafana a standing path into your metrics store, so the connection needs the same care as any other service account. The cards below cover the Graphite side of that connection, how Grafana stores and edits its settings, and the hardening controls that protect a shared instance.
Read-only access to Graphite
Grafana only needs to read series to draw panels and evaluate alert queries, so the account or network path it uses should not be able to write or delete metrics. Ask your Graphite administrators whether access control sits in front of the web or render API, and whether it can be limited to the metric namespaces your dashboards use. Test the restriction by attempting a write from the Grafana host with the same credentials. Confirm the exact access model with your Graphite distribution, because authentication options vary between deployments.
Credential storage and rotation
If your Graphite endpoint requires credentials, store them in the data source configuration as secure fields rather than in dashboards, provisioning files kept in plain text, or shared notes. Provisioning can reference environment variables, which keeps secrets out of the files themselves, but the variables must be protected at the host or orchestrator level. Agree a rotation schedule with the Graphite team and check that rotating a credential does not break alert rules that depend on the same data source.
TLS to the Graphite endpoint
Queries to Graphite can carry metric names, hostnames and business identifiers, so they should travel over TLS when they cross a network boundary. Confirm the certificate chain that Graphite presents and install the internal certificate authority on the Grafana host if needed. Avoid turning off certificate verification to get a connection working, because that removes the protection TLS provides. Verify the connection from the Grafana host itself, since the browser path and the server path can use different trust stores.
Restricting who edits data source settings
Anyone who can change a data source URL or credential can redirect Grafana queries or capture secrets, so editing data sources should be limited to a small administrator group. Use Grafana roles and folder permissions to keep dashboard editors from changing connection settings. Review who holds administrator rights after each team change. Authentication and role mapping depend on your identity provider and edition, so confirm which team sync and provisioning features your edition provides before you design the process.
Secure cookies and SameSite
A shared Grafana instance relies on session cookies, and the hardening guidance recommends secure and SameSite cookie settings so that session tokens are sent only over encrypted connections and are limited in cross-site requests. Set these options in the Grafana configuration and confirm them in the browser developer tools after a login over HTTPS. Test any embedded panels or external links that depend on cross-site cookie behavior, because stricter settings can break them.
Content Security Policy and version exposure
A Content Security Policy limits which scripts and resources the browser will load, which reduces the impact of injected content in a dashboard or plugin. The hardening guidance also recommends Trusted Types and hiding the Grafana version from unauthenticated users. Enable these controls in a test instance first, because custom plugins and panels may need exceptions. Ask your security team to review the policy against the plugins you actually run.
Metrics endpoint and DNS rebinding checks
The Grafana metrics endpoint can expose operational detail, so the hardening guidance recommends requiring authentication for it. Domain verification guards against DNS rebinding, where a hostile page tricks a browser into sending requests to an internal address. Confirm both settings after each upgrade, since defaults and configuration keys can change between releases. Document the expected domain and the scraping account used by your monitoring system.
How to test the Graphite integration before users rely on it
Test the Graphite integration by comparing what Grafana shows with what Graphite returns for the same query and time window. Pick a sample window that includes a recent spike, a quiet period and a gap in the data, then run the same metric paths directly against Graphite's render API and against the Graphite data source panel in Grafana. Check that series names, units, aggregation and the number of points match. Differences usually come from the function chain in the panel, the time range rounding or a metric that was renamed upstream, so record each mismatch and its cause before signing off. Repeat the comparison for at least one panel that uses a transformation, because transformation behavior can differ from the raw query result.
Next, test the queries users will actually write. Wide wildcards such as a top-level glob over every host are the most common source of slow panels and timeouts, so run the heaviest dashboard queries with the time range that people use most and note the response time. Confirm the data source timeout settings in Grafana and the limits on the Graphite side, then agree with the Graphite owners which patterns are allowed on shared dashboards. Also confirm permissions: create a test user in each Grafana role, check that the Graphite data source is visible only where intended, and make sure a user without access cannot edit the data source connection. Because Graphite is not supported for externally shared dashboards, confirm that any sharing workflow you planned is blocked for these panels.
Finally, plan ongoing checks rather than treating the test as a one-time event. Grafana publishes major releases once a year, minor releases every other month and patch releases at least monthly, so a version change can arrive on a regular schedule. After each upgrade, load a fixed set of critical dashboards, compare a few panel values against the baseline you recorded, and check the query timings again. Keep the baseline and the test dashboard list in version control so the next person can repeat the run. Confirm the upgrade cadence and supported version windows in Grafana's upgrade guidance before you set the schedule, since they determine how often this check must run.
Common Graphite and Grafana connection failures and fixes
This table pairs common failures between Grafana and an existing Graphite store with their likely causes and fixes. Use it as a first-pass checklist, then confirm each fix against your Graphite version and the Graphite data source settings in your Grafana build.
| Failure | Likely cause | Fix |
|---|---|---|
| No data for a path that exists | Metric path typed differently from the stored name, or the wrong time range or Graphite time zone | Run the same path in the Graphite render or find API, compare case and dot separators, then align the panel time range with the stored data |
| Wildcard queries are slow or time out | Broad wildcards such as a leading asterisk across many nodes, or large series counts returned to one panel | Narrow the path at each level, use series functions to reduce output, and raise the data source timeout only after reducing query scope |
| Authentication errors on the data source | Missing or expired credentials, basic auth not enabled on the Graphite web app, or a proxy stripping the Authorization header | Verify the basic auth or header settings in the data source, test with curl from the Grafana host, and confirm the proxy forwards credentials |
| TLS trust errors | Graphite served with a certificate issued by an internal CA that the Grafana host does not trust, or a hostname mismatch | Add the internal CA to the Grafana host trust store, correct the URL hostname, and use the TLS client settings the data source exposes in your version |
| Series disappear after a retention change | Carbon retention schemes shortened, so older points were dropped, or a storage aggregation change altered rollups | Check the retention and aggregation rules in the Graphite configuration, restore from backup if needed, and set expectations for dashboard history |
| Graphite panels fail on shared dashboards | Graphite is listed as unsupported for externally shared dashboards, so these panels cannot render for anonymous viewers | Keep Graphite dashboards internal, or move the shared view to a supported data source. Confirm the current list in the Grafana sharing docs |
| Transformations do not filter by query | Filter data by query refId is not available for Graphite queries | Split the panel into separate queries or use transformations that filter on field names, and test the result on your Grafana version |
| Sudden slowdown after adding many panels | Dashboards issue many uncached wildcard queries against Graphite at once | Consolidate panels, use dashboard variables with fixed paths, and review query load on the Graphite web app before adding more dashboards |
When to plan a move to a Prometheus-compatible backend
Plan a move when the Graphite setup can no longer meet one of four requirements: sharing dashboards outside your organization, using transformations that depend on query refId, alerting that needs a different backend, or the skills to run the stack you have. None of these is a failure of Graphite itself. Each one is a point where the Graphite data source stops being the right fit for what your teams need from Grafana. Start by listing which dashboards and alerts fall into each category, because that list sets the scope of any migration. The first two criteria are documented limits. Graphite is listed as unsupported for Grafana externally shared dashboards, so any dashboard that must be viewed by people outside your network through a public share link needs a supported data source before you can offer it. Filtering data by query refId is also not available for Graphite in transformations, so panels that depend on that transformation need to be rebuilt or moved. Check both lists against your current dashboards in your own Grafana version, since support tables change between releases and should be confirmed in the Grafana data sources documentation before you commit to a plan. A move is a parallel project, not a switch. You will run a Prometheus-compatible store next to Graphite, feed it the same metrics, rebuild or re-point dashboards and alert rules, compare results over a period your team agrees on, and then retire the Graphite path. Ask any partner to price this as dual running, dashboard migration, alert validation and decommissioning as separate line items. The design of the target store, including ingestion, retention and high availability, is covered by the sibling Prometheus-compatible topics, so use this section to decide whether and when to start that work.
Questions buyers ask about Grafana and Graphite
How much effort does a Graphite connection take compared with a migration?
A Graphite connection is usually much less work than a migration, because the data stays where it is and Grafana only needs to query it. The connection work covers network reachability from the Grafana servers to the Graphite query endpoint, the data source configuration, and a review of which panels and functions your existing dashboards use. A migration to a Prometheus-compatible backend adds metric renaming, label design, backfill or dual-running decisions, rewritten queries, and a cutover with parallel validation. Ask any partner to separate these two pieces in the written scope so you can decide on them independently.
What drives the cost of a Graphite integration up or down?
The main drivers are the number of dashboards and panels that depend on Graphite functions, the number of teams and data sources involved, how your Graphite endpoints are secured, and how much of your existing alerting you intend to keep. Environments with many custom functions, nested templates or strict network segmentation take longer to validate. Costs are one-time for the build and recurring for upkeep, such as Grafana upgrades and dashboard review. When you request a quote, ask for the work broken into inventory, connection, dashboard review, alerting checks and handover, so you can see which items scale with your estate.
Can our own team set up Graphite in Grafana without a partner?
Often yes, if you have someone comfortable with Grafana administration and with your Graphite deployment. The core Graphite data source is a standard configuration task, and the Grafana data sources documentation covers the steps. The harder parts are usually outside Grafana: confirming which Graphite endpoint is authoritative, agreeing on access accounts with the owners of the metrics store, and checking that existing dashboards still render after the change. A partner is most useful when you have many dashboards to review or when you want the work documented and tested against a written scope. Decide based on your team's capacity and the size of your dashboard estate.
What does the work need from our side?
Plan for four inputs before work starts. First, read access to the Graphite endpoint, with a service account scoped to the metrics that Grafana needs. Second, named owners for Graphite, for Grafana, and for the dashboards and teams that use them, so questions get answers quickly. Third, a list of the networks and firewall rules that separate Grafana from Graphite. Fourth, test windows agreed with the people who run production dashboards and alerts, because changing a data source can affect what operators see during an incident. Ask your partner to confirm each input in writing so no step waits on an unnamed approval.
How long does the connection work typically take?
The duration depends on scope more than on the connection itself. A single Graphite data source with a small set of dashboards is a short piece of work, while a large estate with many custom functions, multiple Graphite clusters and several owning teams takes longer because each dashboard needs review. Access approvals and network changes often set the pace, not the configuration. Ask for a timeline tied to the written scope, with the dependencies listed, and check whether it includes a validation window after the first production dashboards are switched over.
Can shared dashboards be made to work with Graphite?
Not directly. Grafana's externally shared dashboards documentation lists Graphite as unsupported for external sharing, so a dashboard that relies on a Graphite data source cannot be published to an external audience in that form. The usual options are to keep Graphite dashboards internal, to replicate the needed series into a supported data source for the shared view, or to plan a move of those views to a Prometheus-compatible backend. Confirm the current support list in the Grafana docs before you commit to a design, because sharing behavior changes between releases.
Which transformation features are missing when using Graphite?
The Grafana transformations documentation notes that filtering data by query refId is not available for Graphite. This affects dashboards that combine several queries and then select results by their reference identifier. Restructure those panels so each query feeds its own panel, or use transformations that do not depend on refId. Review every panel with multiple queries during the dashboard inventory, because the gap appears only when a transformation is applied and can look like missing data rather than an error.
How DeployOpen scopes and delivers a Graphite integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Grafana. For a Graphite integration, the work starts with a written scope that states which Graphite data sources, dashboards and sharing needs are in and which move to a Prometheus-compatible backend.
How we scope
- Inventory the Graphite endpoints, metric namespaces and retention rules that Grafana must query
- Record which dashboards need external sharing, since Graphite is unsupported for externally shared dashboards
- Confirm which transformations depend on filtering by query refId, which Graphite does not support
How we build
- Install and configure self-hosted Grafana with a production database such as MySQL or PostgreSQL
- Add the core Graphite data source and test queries against representative metric paths
- Document the dashboards that rely on unsupported features and the workarounds agreed in scope
How we hand over
- Provide provisioning files for the Graphite data source and dashboards so configuration is repeatable
- Deliver a written runbook covering access, query verification and known Graphite limitations
- Walk your operations team through the backend migration options and the decision criteria agreed in scope
How we support
- Offer ongoing support, upgrades and testing as a retainer after the fixed-scope delivery ends
- Plan Grafana upgrades against the published release cadence and the support window for each minor release
- Review Graphite-dependent dashboards when a migration to a Prometheus-compatible backend is scheduled
