You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2012/11/15 20:59:12 UTC
[jira] [Created] (FLUME-1715) OpenTSDB Sink
Mike Percy created FLUME-1715:
---------------------------------
Summary: OpenTSDB Sink
Key: FLUME-1715
URL: https://issues.apache.org/jira/browse/FLUME-1715
Project: Flume
Issue Type: New Feature
Components: Sinks+Sources
Affects Versions: v0.9.4
Reporter: Dani Abel Rayan
Assignee: Dani Abel Rayan
OpenTSDB is free software and is available under the LGPLv3+ license. It allows you to collect many thousands of metrics from thousands of hosts and applications, at a high rate (every few seconds). and never deletes or downsample data and can easily store billions of data points. Under the hood it uses HBase (Asynchronous client) . Out of box, it gives you awesome graphs and hands-down options to tune your query. http://opentsdb.net/
OpenTSDB was collecting data using python scripts and Open-TSDB Flume plugin looked as natural alternative.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FLUME-1715) OpenTSDB Sink
Posted by "Mike Percy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FLUME-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Percy updated FLUME-1715:
------------------------------
Description:
(Cloned from JIRA issue tracking OpenTSDB sink impl against Flume 0.9)
It would be useful to have an OpenTSDB sink for Flume 1.x. Since the protocol is a text-based TCP protocol, basically a netcat-type protocol, I don't see any concern about licensing issues (OpenTSDB is LGPL licensed).
A couple of ideas on an implementation:
* Have one mode that works "out of the box" where we assume that events sent to this sink are already fully formatted as OpenTSDB "put" queries. Then, this sink only really has to handle error conditions sent back from OpenTSDB, not serialization
* Have another mode where the user can do some serialization of arbitrary events as OpenTSDB queries. The rest of the logic remains the same as above.
More info: http://opentsdb.net/metrics.html
Not sure where the docs are on wire protocol error handling logic. I am pretty sure it uses a "no news is good news" policy, whereby it returns nothing on success, and sends some message back on error.
was:
OpenTSDB is free software and is available under the LGPLv3+ license. It allows you to collect many thousands of metrics from thousands of hosts and applications, at a high rate (every few seconds). and never deletes or downsample data and can easily store billions of data points. Under the hood it uses HBase (Asynchronous client) . Out of box, it gives you awesome graphs and hands-down options to tune your query. http://opentsdb.net/
OpenTSDB was collecting data using python scripts and Open-TSDB Flume plugin looked as natural alternative.
Affects Version/s: (was: v0.9.4)
Reporter: Mike Percy (was: Dani Abel Rayan)
Fix Version/s: v1.4.0
Assignee: (was: Dani Abel Rayan)
> OpenTSDB Sink
> -------------
>
> Key: FLUME-1715
> URL: https://issues.apache.org/jira/browse/FLUME-1715
> Project: Flume
> Issue Type: New Feature
> Components: Sinks+Sources
> Reporter: Mike Percy
> Fix For: v1.4.0
>
>
> (Cloned from JIRA issue tracking OpenTSDB sink impl against Flume 0.9)
> It would be useful to have an OpenTSDB sink for Flume 1.x. Since the protocol is a text-based TCP protocol, basically a netcat-type protocol, I don't see any concern about licensing issues (OpenTSDB is LGPL licensed).
> A couple of ideas on an implementation:
> * Have one mode that works "out of the box" where we assume that events sent to this sink are already fully formatted as OpenTSDB "put" queries. Then, this sink only really has to handle error conditions sent back from OpenTSDB, not serialization
> * Have another mode where the user can do some serialization of arbitrary events as OpenTSDB queries. The rest of the logic remains the same as above.
> More info: http://opentsdb.net/metrics.html
> Not sure where the docs are on wire protocol error handling logic. I am pretty sure it uses a "no news is good news" policy, whereby it returns nothing on success, and sends some message back on error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira