Query Listener?

Hi All,

Has anyone heard of / or developed a query listener? I'd love to be able to
aggregate/track the queries flowing through the system as they happen. I
don't want to go the route of a log appender, as that would require
monkeying around with slow-query log settings.

Ideally tracking the incoming JSON request would suffice.

Any thoughts?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e7c11e69-1cc2-4f45-bfcb-95aaead7fa38%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Yes, I once started an effort of a pub/sub framework with websockets
between nodes. By doing this, you could also subscribe to nodes and track
queries as they are executed somehwere on the cluster (note that queries
would have to be extended to carry a unique identifier).

There is no current version yet but I plan to jump on the 1.0.0 bandwagon.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFxmAKyFN8OCqPLR25wtn%2BQdowEf9CA5toG9rW0KVpiKw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Makes sense, but not sure I follow... this sort of architecture would lead
to tracking a lot of duplicate calls, as one query can hit X# nodes before
returning for result-aggregation. Is this where the uid comes in - for
de-duplication of calls?

Also, what does 1.0.0 change in this respect?

On Friday, December 6, 2013 1:55:30 PM UTC-5, Jörg Prante wrote:

Yes, I once started an effort of a pub/sub framework with websockets
between nodes. By doing this, you could also subscribe to nodes and track
queries as they are executed somehwere on the cluster (note that queries
would have to be extended to carry a unique identifier).

GitHub - jprante/elasticsearch-transport-websocket: WebSockets for ElasticSearch

There is no current version yet but I plan to jump on the 1.0.0 bandwagon.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/df8a0085-0f9e-405a-a3f8-b7ae829ee7d5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Yes, assigning a uid to a query could assist in collecting all the events
that belong together. Not really deduplication since all the events stand
for themselves and give the big picture.

Tracing query execution comes with a certain overhead impact. I'm quite
sure there will be no such hooks in 1.0.0 to allow this style of a query
listener where clients can "spy" what other clients are doing.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEmqzeqW9yZthnCSK6NoXoxcuLV_tgC-fVRnqsK1u4Uxg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.