[jira] [Commented] (FLUME-1715) OpenTSDB Sink

["Jonathan Creasy (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLUME-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14276180#comment-14276180 ] 

Jonathan Creasy commented on FLUME-1715:
----------------------------------------

>From the OpenTSDB Mailing list:

On Thursday, September 25, 2014 9:37:38 AM UTC-7, Jonathan Creasy wrote:
I haven't really gotten too familiar with the code, but could the right classes be extracted from OpenTSDB and included as a jar within a Flume sink to have Flume write to HBase as if it were OpenTSDB 2.0 doing the writing?

On Tue, Oct 14, 2014 at 12:11 AM, ManOLamancha <cl...@gmail.com> wrote:
Super simple to use, just include the tsdb jar file and either overload the Config class or load it from a file, then instantiate a TSDB object and start calling addDatapoint(). Boom! We're looking at doing the same thing with Kafka. 

> 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
>            Assignee: Jayant Shekhar
>
> (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 was sent by Atlassian JIRA
(v6.3.4#6332)