Backend plugins

    However, one limitation with these plugins are that they execute on the client-side (in the browser) which makes it hard to support certain use cases/features, e.g. enable Grafana Alerting for data sources. Grafana v7.0 adds official support for backend plugins which removes this limitation. At the same time it gives plugin developers the possibility to extend Grafana in new and interesting ways, with code running in the backend (server side).

    We use the term backend plugin to denote that a plugin has a backend component. Still, normally a backend plugin requires frontend components as well. This is for example true for backend data source plugins which normally need configuration and query editor components implemented for the frontend.

    Data source plugins can be extended with a backend component. In the future we plan to support additional types and possibly new kinds of plugins, such as notifiers for Grafana Alerting and custom authentication to name a few.

    • Enable Grafana Alerting for data sources.
    • Keep state between users, e.g. query caching for data sources.
    • Use custom authentication methods and/or authorization checks that aren’t supported in Grafana.
    • Use a custom data source request proxy, see .

    Grafana’s backend plugin system

    The Grafana backend plugin system is based on the . The Grafana server launches each backend plugin as a subprocess and communicates with it over gRPC. This approach has a number of benefits:

    • Plugins can’t crash your grafana process: a panic in a plugin doesn’t panic the server.
    • Plugins are easy to develop: just write a Go application and run (or use any other language which supports gRPC).
    • Plugins can be relatively secure: The plugin only has access to the interfaces and arguments that are given to it, not to the entire memory space of the process.

    Grafana’s backend plugin system exposes a couple of different capabilities, or building blocks, that a backend plugin can implement:

    • Query data
    • Health checks
    • Collect metrics

    The query data capability allows a backend plugin to handle data source queries that are submitted from a dashboard, or Grafana Alerting. The response contains , which are used to visualize metrics, logs, and traces. The query data capability is required to implement for a backend data source plugin.

    Examples of use cases for implementing resources:

    • Implement a custom data source proxy in case certain authentication/authorization or other requirements are required/needed that are not supported in Grafana’s .
    • Return data or information in a format suitable to use within a data source query editor to provide auto-complete functionality.
    • Return static resources, such as images or files.
    • Send a command to a device, such as a micro controller or IOT device.
    • Request information from a device, such as a micro controller or IOT device.
    • Use chunked transfer encoding to return large data responses in chunks or to enable “basic” streaming capabilities.

    The health checks capability allows a backend plugin to return the status of the plugin. For data source backend plugins the health check will automatically be called when you do Save & Test in the UI when editing a data source. A plugin’s health check endpoint is exposed in the Grafana HTTP API and allows external systems to continuously poll the plugin’s health to make sure it’s running and working as expected.

    A backend plugin can collect and return runtime, process and custom metrics using the text-based Prometheus . If you’re using the Grafana Plugin SDK for Go to implement your backend plugin, then the is built-in, and gives you Go runtime metrics and process metrics out of the box. By using the Prometheus instrumentation library you can add custom metrics to instrument your backend plugin.