couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: Extending CouchCB
Date Thu, 17 Apr 2014 22:38:29 GMT
On 17. April 2014 at 12:35:57, Diogo Júnior (diogo.junior@fraunhofer.pt) wrote:
> Hi, I want to be able to "log/ signal" when a client request a GET db/_changes request
and  
> when it performs requests on _local /_revs_diff /_bulk_docs etc. I want to simply apply
 
> a specific logic on the requests that clients might be doing and log only the ones that
 
> I want to a specific file. So, I need to analyze the http request content in order to
detect  
> what's the request for and only then decide if I want to log it or not. But I don't want
to  
> replace the normal couchdb behaviour and I don't want my couchdb clients to execute any
 
> other requests to other proxy url, etc
>  
> I've been studying the external process subject but I was not able to understand if this
 
> is the best choice for me.
>  
> How would you implement this kind of stuff?

Hi Diogo,

At this point I would roll up my sleeves and dig into the erlang bits.

There are probably 3 main approaches:

1. avoid erlang completely and do this in apache2/nginx/node/some other proxy that sits in
front and logs stuff. What Mark said, basically.

2. Fiddle with logging the request itself (across all requests) in 

src/couchdb/couch_httpd_db.erl#L249

    ?LOG_DEBUG("~p ~s ~p from ~p~nHeaders: ~p", [

and stash some extra logic in there. Alternatively you *could* put this in the error_log.erl
module but this would likely be a lot more processing overhead.

3. hook into the specific httpd handler for your specific request, and add an additional function
call to do your stuff.

e.g. in src/couchdb/couch_httpd_db.erl you’ll see a whole list of calls that you can hook
into, including the relevant _changes feeds etc. This probably is the most efficient place
to dig into, but also the hairiest. 

BTW this excellent writeup by Jan may be useful to understand the internals https://mail-archives.apache.org/mod_mbox/couchdb-erlang/201211.mbox/%3CE873EE1D-5165-487D-B5D7-0AF9F2F09672@apache.org%3E

4. If this is a one-off sort of thing, consider using redbug[1] or recon[2] to use erlang
tracing to do this digging for you.

[1]: http://code.google.com/p/eper/wiki/redbug
[2]: http://ferd.github.io/recon/

Depending on your preferences, this might be a better discussion on dev@ 

--  
Dave Cottlehuber
Sent from my PDP11




Mime
View raw message