While waiting for the contributing agreement for my AMQP plugin, my company asked me if it's possible to implement the couchdb protocol for Packetbeat. So I have two questions :
-First, is anybody already working on this protocol implementation ?
-Second, the couchdb protocol goes through the port 5984 and uses the http protocol with a REST api to receive requests. Would it be ok then to use some parts of the http protocol code to parse some parts of the requests (for example, headers), and from there parse what is interesting for the couchdb protocol (ex : database, document version etc.) ?
As far as I know, there is currently no one working on the CouchDB implementation. The best is in case you start to work on a protocol is to add an issue here and mention that you work on it: https://github.com/elastic/packetbeat/labels/new%20protocol
For your second question: Code reuse is always a good thing. So I don't see currently a good reason not to reuse the HTTP code.
Awesome, someone asking about some application "protocol" on top of http.
Haven't had time to start this yet, but the idea was basically to use some criteria like ports and/or http content-type to further analyze the HTTP body. I'm not aware of CouchDB protocols in use, but as I understand it uses a JSON based REST API, right? So if we add a feature to parse(and merge into final event) the JSON body (content-type == application/json), we will be able to support some more services but CouchDB. For example Elasticsearch HTTP API. Think using packetbeat to analyze Logstash/Kibana <-> Elasticsearch . Also monitoring Rich-Client Web applications using REST+JSON will benefit from this enhancement.
For starters I've been thinking about supporting JSON and XML based content-type.
This approach of building on top of HTTP would be useful for the AVRO support I'm working on. One of the options for AVRO communication is to POST the binary over HTTP, the body having content-type = 'binary/avro'.
Obviously that's less generic than JSON and XML, but I think the solution would be similar.
well, the idea is to have it kinda 'pluggable' (think HTTP content extensions), just like the protocol analyzers are already kind of plugins. Sounds like AVRO is another use-case.
You mean a kind of Parse interface for RESTful apis in http ? That would be a good idea. Allowing the user to directly have the url, informations like content-type, and the body would help to parse a lot of protocols like ElasticSearch and CouchDB.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.