influxdb/services/opentsdb
Jonathan A. Sternberg 83ecab6299 Prevent deadlock during collectd, graphite, opentsdb, and udp shutdown
All of these services start up goroutines and then wait for the
goroutines to finish. Each of them has a `tsdb.PointBatcher` that may
return a point during the shutdown sequence. During the shutdown
sequence, a lock was held. This lock may get accessed when attempting to
write the point that came back from the `tsdb.PointBatcher`. This caused
the read lock attempt to wait forever for the write lock to be unlocked
during `Close()`.

This modifies these methods so that the write lock is released while
waiting for goroutines to finish in these three services.
2017-10-19 15:57:05 -05:00
..
README.md Support multiple OpenTSDB inputs 2016-04-11 08:47:38 -07:00
config.go Report subset of config values in SHOW DIAGNOSTICS 2017-03-14 11:34:19 -07:00
config_test.go rename influxdb/influxdb to influxdata/influxdb 2016-02-10 10:26:18 -07:00
handler.go initial fga work 2017-05-26 13:16:27 -07:00
service.go Prevent deadlock during collectd, graphite, opentsdb, and udp shutdown 2017-10-19 15:57:05 -05:00
service_test.go initial fga work 2017-05-26 13:16:27 -07:00

README.md

OpenTSDB Input

InfluxDB supports both the telnet and HTTP OpenTSDB protocol. This means that InfluxDB can act as a drop-in replacement for your OpenTSDB system.

Configuration

The OpenTSDB inputs allow the binding address, target database, and target retention policy within that database, to be set. If the database does not exist, it will be created automatically when the input is initialized. If you also decide to configure retention policy (without configuration the input will use the auto-created default retention policy), both the database and retention policy must already exist.

The write-consistency-level can also be set. If any write operations do not meet the configured consistency guarantees, an error will occur and the data will not be indexed. The default consistency-level is ONE.

The OpenTSDB input also performs internal batching of the points it receives, as batched writes to the database are more efficient. The default batch size is 1000, pending batch factor is 5, with a batch timeout of 1 second. This means the input will write batches of maximum size 1000, but if a batch has not reached 1000 points within 1 second of the first point being added to a batch, it will emit that batch regardless of size. The pending batch factor controls how many batches can be in memory at once, allowing the input to transmit a batch, while still building other batches.