samitpal / influxdb-router

An InfluxDB proxy for centralized organization level monitoring

Metric flow with influxdb-router (Typical use case)

Installation

To install the binary:

Go to the releases page and select the appropriate binary for your platform.

To build from source follow the steps below:

Install glide from http://glide.sh/.

$ go get github.com/samitpal/influxdb-router/...

$ glide install

Switch to the git tag, e.g if you want to build version 1.0

$ git checkout 1.0

$ make influxdb-router

Sample config.toml

# You can configure multiple customers.
[[customers]]
  # name must be unique across customers
  name = "servicex"
  email = "[email protected]"
  # api key. Should be a long random string. This is the value of the telegraf header (default header name is 'Service-API-Key')
  api_key = "7ba4e75a"
  # Name of the influxdb database where the metrics for this customer should be stored.
  influx_db_name = "telegraf1"
  # Max number of batches that will be kept in-memory for each of the 'influx_hosts'. Beyind that batches with be dropped
  outgoing_queue_cap = 7000
  # Influxdb-routed maintains a retry queue for batches that it fails to send to InfluxDB backends.
  # retry_queue_cap is the max number of batches that can be kept in the retry queue (in-memory).
  retry_queue_cap = 10
  # list of InfluxDB hosts.
  influx_hosts = ["http://127.0.0.1:9086", "http://127.0.0.1:8086"]
  # The auth section needs to come at the end. This should be populated only if you enabled auth in influx-router
  # and set auth-mode to 'from-config'. Additionally you need to enable authentication by setting the 'auth-enabled' option
  # to the in the [http] section of the InfluxDB config. 
  [customers.auth]
      # influxdb user. Yo need to grant privilege to user 'user1' to database 'telegraf1'
      username = "user1"
      # influxdb password for user user1
      password = "password1"

Influxdb-router Usage

1. Without InfluxDB authentication enabled.

$./influxdb-router -config_file config.toml -api-listen-http-port 8080 -listen-http-port 8090

2. With the InfluxDB creds in config.toml and with InfluxDB authentication enabled in the backends.

$./influxdb-router -auth-enabled -auth-mode from-config -config_file config.toml -api-listen-http-port 8080 -listen-http-port 8090

3. config.toml with the InfluxDB creds not in config but in env and with InfluxDB authentication enabled in the backends. You can set the creds in environment in the following format.

$ export username_<name> = "user1"
$ export password_<name> = "password1"
<name> is the 'Name' attribute in the toml.


$ ./influxdb-router -auth-enabled -auth-mode from-env -config_file config.toml -api-listen-http-port 8090 -listen-http-port 8080

4. With SSL

$ ./influxdb-router -secure -config_file config.toml -api-listen-http-port 8080 -listen-https-port 8443 -ssl-server-cert <path to server cert> -ssl-server-key <path to server key>

5. With SSL and with ssl client cert authentication enabled (telegraf needs to be configured with client certs)

$ ./influxdb-router -secure -ssl-client-cert-auth -config_file config.toml -api-listen-http-port 8080 -listen-https-port 8443 -ssl-ca-server-cert <path to CA cert> -ssl-server-cert <path to server cert> -ssl-server-key <path to server key>

Example client side config (telegraf configuration)

influxdb-router's Issues

Don't use the api key to construct internal metrics

Use the service name instead of the api key to construct internal InfluxDB-router metrics.

i.e

influx_router.<api_key>.outgoing_queue...

should be replaced by

influx_router.<service_name>.outgoing_queue...

Limit rps per customer

Some kind of throttling per customer perhaps leveraging the /debug/requests InfluxDB end point

In auth-enabled mode Influxdb-router should test auth creds against every InfluxDB backend during start up and log appropriately.

Influxdb-router can make a call with the configured auth creds to the backends and verify that the creds work as expected. This is primarily for better troubleshooting etc.

Influxdb-router does not log unhealthy backends at start time

During start up influxdb-router does not log anything about unhealthy back ends (InfluxDB hosts). It can lead to confusion.

Goreleaser version, date, commit should be supported

In other words when somebody types
$influxdb-router -version
the version, date, commit should be displayed. Right now the version and buildtime gets displayed but only if some one builds the binary using the make command

Populate the commit id var when some one runs 'make influxdb-router'

Change needs to go to line https://github.com/samitpal/influxdb-router/blob/master/Makefile#L16

verify that encrypted communication between the router and InfluxDB backends works

If the backend InfluxDB is configured for https communication, the influxDB router needs to work as expected. Verify the same

Makefile with old version

Please update Makefile to use the lastest version
INFLUXDB-ROUTER_VERSION := 0.1.2

change to
INFLUXDB-ROUTER_VERSION := 0.1.3

Integrate with travis CI

Integrate with travis CI

The default ports should be above 1024 to let the binary run as non root

• Modify the http proxy port from 80 to 8090
• Modify the https proxy port from 443 to 8443

Build docker image with every release

Perhaps using goreleaser itself
Doc: https://goreleaser.com/docker/

Create version variable and flag

There should be a version flag which outs the version of the binary in use.

Remove the restriction of not allowing !, *, or - character in api key string

Some times a good random string is likely to have the !,- or * characters. Remove the restriction as indicated at https://github.com/samitpal/influxdb-router/blob/master/config.toml#L4

The restriction was purely because of us using the api key as as an env variable when using auth from env. linux does not allow shell variables containing those characters.

Question - Example use-case

Dear Samit,

I have looked at your router and I'm trying to figure out if this would allow us to use it for a specific use-case.

We collect stats for a whole range of customers centrally influx but have the option give customers access to their own data using grafana. We want to segregate data to give customers access to their own data AND still have access to all data from an admin view-point.

I'm correct that your influxdb-router, would allow the option define as a "in-between" gateway/proxy that acts as a "filter" while inserting and/or fetching influx data?

Example:

• "Customer X" has access to influxdata with tags "customer x"?
• "Customer Y" has access to influxdata with tags "customer x" & "customer y"
• "Admin" has access to all influxdata

Mask sensitive info while logging

Mask

• api key, creds during startup.
• api key logged for every request processed successfully.