Skip to content


Repository files navigation

Graphite Remote storage adapter Build Status

This is a read/write adapter that receives samples via Prometheus's remote write protocol and stores them in remote storage like Graphite.

It is based on remote_storage_adapter

Compiling the binary

You can either go get it:

$ go get -d
$ cd $GOPATH/src/
$ make build
$ ./graphite-remote-adapter'http://localhost:8080' --graphite.write.carbon-address=localhost:2003

Or checkout the source code and build manually:

$ mkdir -p $GOPATH/src/
$ cd $GOPATH/src/
$ git clone
$ cd graphite-remote-adapter
$ make build
$ ./graphite-remote-adapter'http://localhost:8080' --graphite.write.carbon-address=localhost:2003


Graphite example:

./graphite-remote-adapter \
  --graphite.write.carbon-address=localhost:2001 \'http://guest:guest@localhost:8080' \
  --read.timeout=10s --write.timeout=5s \
  --read.delay 3600s \
  --graphite.default-prefix prometheus.

To show all flags:

./graphite-remote-adapter -h


You can provide some configuration parameters either as flags or in a configuration file. If defined in both, the flag is used. In addtion, you can fill the configuration file with Graphite specific parameters. You can indeed defined customized paths/behaviors for remote-write into Graphite.

This is an example configuration that should cover most relevant aspects of the YAML configuration format.

  listen_address: ""
  telemetry_path: "/metrics"
  timeout: 5m
  timeout: 5m
  delay: 1h
  ignore_error: true
  default_prefix: test.prefix.
  enable_tags: false
    url: http://localhost:8888
    carbon_address: localhost:2003
    carbon_transport: tcp
    carbon_reconnect_interval: 5m
    enable_paths_cache: true
    paths_cache_ttl: 1h
    paths_cache_purge_interval: 2h
        foo: bar
      var2: foobar

    - match:
        owner: team-X
        service: ^(foo1|foo2|baz)$
      template: '{{}}{{.labels.owner}}.{{.labels.service}}{{if ne .labels.env "prod"}}.{{.labels.env}}{{end}}'
      continue: true
    - match:
        owner: team-X
        env:   prod
      template: 'bla.bla.{{.labels.owner | escape}}.great.{{.var2}}'
      continue: true
    - match:
        owner: team-Z
      continue: false

Support for Tags

Graphite 1.1.0 supports tags:, you can enable support for tags in the remote adapter with --graphite.enable-tags or in the configuration file.

Filtering tags

Using --graphite.filtered-tags (or the filtered_tags yaml field in configuration files), it is possible to exports as tags only a given set of label names. Other labels/values won't be exported as tags, and will still be part of the metric name. This feature is only supported for Graphite Tags (not available when using the OpenMetrics format).

Configuring Prometheus

To configure Prometheus to send samples to this binary, add the following to your prometheus.yml:

# Remote write configuration.
  - url: "http://localhost:9201/write"

# Remote read configuration.
  - url: "http://localhost:9201/read"

Since the 0.0.15, a custom prefix can be set in the query string and this will replace the default one. This could be useful if you are using the graphite remote adapter for multiple Prometheus instances with different prefix.

# Remote write configuration.
  - url: "http://localhost:9201/write?graphite.default-prefix=customprefix."

# Remote read configuration.
  - url: "http://localhost:9201/read?graphite.default-prefix=customprefix."


You can test the graphite-remote-adapter behavior or its configuration using the second binary named ratool for remote-adapter tool. Here are two examples:

Integration test (manual end-to-end)

The remote-adapter tool will read an input file in Prometheus exposition text format; translate it in WriteRequest using compressed protobuf format; and send it to the graphite-remote-adapter url on its /write endpoint. No need to run a Prometheus instance to test it anymore:

file -> ratool -> graphite-remote-adapter -> nc

$ make build
$ cat cmd/ratool/input.metrics.example
  # Use the Prometheus exposition text format
  toto{foo="bar", cluster="test"} 42
  toto{foo="bar", cluster="canary"} 34
  # You can even force a given timestamp
  toto{foo="bazz", cluster="canary"} 18 1528819131000
$ ./graphite-remote-adapter --graphite.write.carbon-address ':8888' --log.level debug &
$ nc -l 8888 -w 1 > out.txt
$ ./ratool mock-write --metrics.file cmd/ratool/input.metrics.example --remote-adapter.url 'http://localhost:9201'
$ cat out.txt 42.000000 1570803131 34.000000 1570803131 18.000000 1528819131

Unittests (automated config unittests)

If you want to unit test your configurations without requiring any network, define a file for each configuration you want to test.


config_file: config.yml
  - name: "Test label"
    input: |
        # Use the Prometheus exposition text format
        toto{foo="bar", cluster="test"} 42 1570802650000
        toto{foo="bar", cluster="canary"} 34 1570802650000
        toto{foo="bazz", cluster="canary"} 18 1528819131000
    output: | 42.000000 1570802650 34.000000 1570802650
        toto.canary.other.template.bazz 18.000000 1528819131

  - name: "Other test"
    input: |
        foo{bar="baz"} 10
    output: | 10 1528819131000

The path to config_file is relative to the test file.

Note: timestamps do not have the same unit for input and output. Input uses a regular unix timestamp in milliseconds, output is in seconds.

To run it:

$ make build
$ ./ratool unittest --test.file test_file.yml

The tool will exit with a non-zero code if the output of the remote adapter for the given configuration and the given input does not match the expected output (order of the lines is not checked).

It also prints the diff on the standard error stream.

Example of output:

./ratool unittest --config.file foo.yml --test.file bar.yml
# Testing foo.yml
## Test label 42.000000 1570802650 34.000000 1570802650
-toto.canary.other.template.bazz 18.000000 1528819131 42.000000 1536658898
+ 34.000000 1536658898
+ 18.000000 1528819131
## Other test 10 1528819131000 10.000000 1536658898