Grafana provides several ways to manage the time ranges of the data being visualized, both at the dashboard level and the panel level.
Grafana provides several ways to manage the time ranges of the data being visualized, both at the dashboard level and the panel level.
This page describes supported time units and relative ranges, the common time controls, dashboard-wide time settings, and panel-specific time settings.
## Time units and relative ranges
The following time units are supported: `s (seconds)`, `m (minutes)`, `h (hours)`, `d (days)`, `w (weeks)`, `M (months)`, and `y (years)`.
The following time units are supported: `s (seconds)`, `m (minutes)`, `h (hours)`, `d (days)`, `w (weeks)`, `M (months)`, and `y (years)`.
The minus operator allows you to step back in time, relative to now. If you wish to display the full period of the unit (day, week, month, etc...), append `/<time unit>` to the end.
...
...
@@ -25,13 +25,13 @@ The plus operator allows you to step forward in time relative to now. You might
@@ -98,7 +98,7 @@ Time settings are saved on a per-dashboard basis.
To access the dashboard time settings, click the **Dashboard settings** (gear) icon at the top of the screen. The settings are in the **Time Options** section of the General tab.
-**Timezone -** Specify the local time zone of the service or system that you are monitoring. This can be helpful when monitoring a system or service that operates across several time zones.
-**Default -**The default selected time zone for the user profile, team, or organization is used. If no time zone is specified for the user profile, a team the user is a member of, or the organization, then Grafana uses local browser time.
-**Default -** The default selected time zone for the user profile, team, or organization is used. If no time zone is specified for the user profile, a team the user is a member of, or the organization, then Grafana uses local browser time.
-**Local browser time -** The time zone configured for the viewing user browser is used. This is usually the same time zone as set on the computer.
- Standard [ISO 8601 time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), including UTC.
-**Auto-refresh -** Customize the options displayed for relative time and the auto-refresh options. Entries are comma separated and accept any valid time unit.
...
...
@@ -107,7 +107,7 @@ To access the dashboard time settings, click the **Dashboard settings** (gear) i
## Panel time overrides and timeshift
In [Query options]({{<relref"queries.md#query-options">}}), you can override the relative time range for individual panels, causing them to be different than what is selected in the dashboard time picker in the upper right. This allows you to show metrics from different time periods or days at the same time.
In [Query options]({{<relref"../panels/queries.md#query-options">}}), you can override the relative time range for individual panels, causing them to be different than what is selected in the dashboard time picker in the upper right. This allows you to show metrics from different time periods or days at the same time.
Grafana added support for plugins in version 3.0 and this enabled the Grafana community to create panel plugins and data source plugins. It was wildly successful and has made Grafana much more useful as you can integrate it with anything and do any type of custom visualization that you want.
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).
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.
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]({{<relref"../../../alerting/notifications.md">}}) and custom authentication to name a few.
...
...
@@ -28,11 +28,12 @@ The following examples gives you an idea of why you'd consider implementing a ba
## Grafana’s backend plugin system
The Grafana backend plugin system is based on the [go-plugin library by HashiCorp](https://github.com/hashicorp/go-plugin). The Grafana server launches each backend plugin as a subprocess and communicates with it over [gRPC](https://grpc.io/). 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 `go build` (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:
Grafana's backend plugin system exposes a couple of different capabilities, or building blocks, that a backend plugin can implement:
- Query data
- Resources
...
...
@@ -41,7 +42,7 @@ Grafana's backend plugin system exposes a couple of different capabilities, or b
### Query data
The query data capability allows a backend plugin to handle data source queries that are submitted from a [dashboard]({{<relref"../../../features/dashboard/dashboards.md">}}), [Explore]({{<relref"../../../features/explore/index.md">}}) or [Grafana Alerting]({{<relref"../../../alerting">}}). The response contains [data frames]({{<relref"data-frames.md">}}), which are used to visualize metrics, logs, and traces. The query data capability is required to implement for a backend data source plugin.
The query data capability allows a backend plugin to handle data source queries that are submitted from a [dashboard]({{<relref"../../../features/dashboard/dashboards.md">}}), [Explore]({{<relref"../../../features/explore/index.md">}}) or [Grafana Alerting]({{<relref"../../../alerting">}}). The response contains [data frames]({{<relref"../data-frames.md">}}), which are used to visualize metrics, logs, and traces. The query data capability is required to implement for a backend data source plugin.
### Resources
...
...
@@ -59,7 +60,7 @@ Examples of use cases for implementing resources:
### Health checks
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.
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.
@@ -15,7 +15,7 @@ Grafana already has a strong community of contributors and plugin developers. By
## Short version
1.[Set up Grafana](https://github.com/grafana/grafana/blob/master/contribute/developer-guide.md)
2. Clone an example plugin into ```/var/lib/grafana/plugins``` or `data/plugins` (relative to grafana git repo if you're running development version from source dir)
2. Clone an example plugin into `/var/lib/grafana/plugins` or `data/plugins` (relative to grafana git repo if you're running development version from source dir)
3. Use one of our example plugins as a starting point
Example plugins
...
...
@@ -36,7 +36,7 @@ Since everything turns into JavaScript, it's up to you to choose which language
## Buildscript
You can use any build system that supports systemjs. All the built content should end up in a folder named ```dist``` and be committed to the repository. By committing the dist folder, the person who installs your plugin does not have to run any build script. All of our example plugins have a build script configured.
You can use any build system that supports systemjs. All the built content should end up in a folder named `dist` and be committed to the repository. By committing the dist folder, the person who installs your plugin does not have to run any build script. All of our example plugins have a build script configured.
## Keep your plugin up to date
...
...
@@ -63,34 +63,30 @@ The SDK contains three different plugin classes: PanelCtrl, MetricsPanelCtrl and
Example:
```javascript
import{ClockCtrl}from'./clock_ctrl';
import{ClockCtrl}from'./clock_ctrl';
export{
ClockCtrlasPanelCtrl
};
export{ClockCtrlasPanelCtrl};
```
The module class is also where css for the dark and light themes is imported:
There are three ways that you can start developing a Grafana plugin.
1. Set up a Grafana development environment. [(described here)](https://github.com/grafana/grafana/blob/master/contribute/developer-guide.md) and place your plugin in the ```data/plugins``` folder.
1. Set up a Grafana development environment. [(described here)](https://github.com/grafana/grafana/blob/master/contribute/developer-guide.md) and place your plugin in the `data/plugins` folder.
2. Install Grafana and place your plugin in the plugins directory which is set in your [config file](/installation/configuration). By default this is `/var/lib/grafana/plugins` on Linux systems.
3. Place your plugin directory anywhere you like and specify it grafana.ini.
...
...
@@ -116,11 +112,11 @@ If a panel receives data and hooks into the `data-received` event then it should
We have three different examples that you can fork/download to get started developing your Grafana plugin.
-[simple-json-datasource](https://github.com/grafana/simple-json-datasource)(small data source plugin for querying json data from backends)
<selectclass="input-small gf-form-input"ng-model="ctrl.panel.mySelectProperty"ng-options="t for t in ['option1', 'option2', 'option3']"ng-change="ctrl.onSelectChange()"></select>
<select
class="input-small gf-form-input"
ng-model="ctrl.panel.mySelectProperty"
ng-options="t for t in ['option1', 'option2', 'option3']"
<inputtype="text"class="input-small gf-form-input width-10"ng-model="ctrl.panel.myProperty"ng-change="ctrl.onFieldChange()"placeholder="suggestion for user"ng-model-onblur/>
<input
type="text"
class="input-small gf-form-input width-10"
ng-model="ctrl.panel.myProperty"
ng-change="ctrl.onFieldChange()"
placeholder="suggestion for user"
ng-model-onblur
/>
</div>
</div>
</div>
...
...
@@ -137,43 +149,45 @@ We recommend that you use a linter for your JavaScript. For ES6, the standard li
2. Prefer to use `let` instead `var` ([Exploring ES6](http://exploringjs.com/es6/ch_core-features.html#_from-var-to-letconst))
3. Use arrow functions, which don’t shadow `this` ([Exploring ES6](http://exploringjs.com/es6/ch_core-features.html#_from-function-expressions-to-arrow-functions)):
```js
testDatasource() {
return this.getServerStatus()
.then(status => {
return this.doSomething(status);
})
}
```
better than
```js
testDatasource() {
var self = this;
return this.getServerStatus()
.then(function(status) {
return self.doSomething(status);
})
}
```
```js
testDatasource() {
return this.getServerStatus()
.then(status => {
return this.doSomething(status);
})
}
```
better than
```js
testDatasource() {
var self = this;
return this.getServerStatus()
.then(function(status) {
return self.doSomething(status);
})
}
```
4. Use native _Promise_ object:
```js
metricFindQuery(query) {
if (!query) {
return Promise.resolve([]);
}
}
```
better than
```js
metricFindQuery(query) {
if (!query) {
return this.$q.when([]);
}
}
```
```js
metricFindQuery(query) {
if (!query) {
return Promise.resolve([]);
}
}
```
better than
```js
metricFindQuery(query) {
if (!query) {
return this.$q.when([]);
}
}
```
5. If using Lodash, then be consistent and prefer that to the native ES6 array functions.
