: Wednesday, May 16, 2007 2:02:12 PM
Subject: RE: Requests per second/minute monitor?
Adding entries to RequestHandlerBase.getStatistics() sounds like it
might be a reasonable compromise; backwards compatibility is kept in
place but everything from now on gets the added advantages of more
tracking
-
From: Mike Klaas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 15, 2007 5:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Requests per second/minute monitor?
On 15-May-07, at 1:41 PM, Chris Hostetter wrote:
: I'm happy to make the changes and supply a patch to move the
logic as
: well
: Why does SolrCore.setResponseHeaderValues(...) set the QTime (and other
: response header options) instead of having it as a function of
the main reason was to ensure that that data would *always* be there no
matter who wrote a request handler (or wether or not they subclassed the
On 15-May-07, at 1:41 PM, Chris Hostetter wrote:
: I'm happy to make the changes and supply a patch to move the
logic as
: well as adding a few simple metrics unless enough people on this
thread
: really feel that it's always better to do it with log files and
: postmortem math.
moving
I've needed similar logged information recently and I looked at the code
and had a few questions:
Why does SolrCore.setResponseHeaderValues(...) set the QTime (and other
response header options) instead of having it as a function of
RequestHandlerBase? If things were tracked in the
On 5/10/07, Ian Holsman [EMAIL PROTECTED] wrote:
What I would like to know is (and excuse the newbieness of the question) how
to enable solr to log a file with the following data.
- time spent (ms) in the request.
currently logged
- IP# of the incoming request
normally in the container
Yes, that is possible, but we also monitor Apache, Tomcat, the JVM, and
OS through JMX and other live monitoring interfaces. Why invent a real-time
HTTP log analysis system when I can fetch /search/stats.jsp at any time?
By number of rows fetched, do you mean number of documents matched?
The log
Walter Underwood wrote:
This is for monitoring -- what happened in the last 30 seconds.
Log file analysis doesn't really do that.
I would respectfully disagree.
Log file analysis of each request can give you that, and a whole lot more.
you could either grab the stats via a regular cron
@lucene.apache.org
Sent: Thursday, April 19, 2007 5:37:56 PM
Subject: Re: Requests per second/minute monitor?
: Is there a good spot to track request rate in Solr? Has anyone
: built a monitor?
I would think it would make more sense to track this in your application
server then to add it to Solr itself
On 4/27/07, Otis Gospodnetic [EMAIL PROTECTED] wrote:
Would creating a new QueryRateFilter servlet filter be a good place to put
this? This way it could stay out of the Solr core and coult be turned on/off
via web.xml.
There's already gotta be some nice external tools that parse log files
Walter Underwood wrote:
This is for monitoring -- what happened in the last 30 seconds.
Log file analysis doesn't really do that.
I think the XML output in admin/stats.jsp may be enough for us.
That gives the cumulative requests on each handler. Those are
counted in StandardRequestHandler
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-user@lucene.apache.org
Sent: Friday, April 27, 2007 4:15:33 PM
Subject: Re: Requests per second/minute monitor?
On 4/27/07, Otis Gospodnetic [EMAIL PROTECTED] wrote:
Would creating a new QueryRateFilter servlet filter
: Is there a good spot to track request rate in Solr? Has anyone
: built a monitor?
I would think it would make more sense to track this in your application
server then to add it to Solr itself.
-Hoss
Not yet from us, but I'm thinking about a nagios plugin for Solr. It would
be tomcat-based for the http stuff, however.
On 4/18/07, Walter Underwood [EMAIL PROTECTED] wrote:
Is there a good spot to track request rate in Solr? Has anyone
built a monitor?
wunder
--
Search Guru
Netflix
On 4/18/07, Walter Underwood [EMAIL PROTECTED] wrote:
I noticed that admin/stats.jsp gives the total requests since
startup. If the monitor keeps the previous value, it can calculate
the rate at the client.
Something based off of access logs is more universal since it works
across many
15 matches
Mail list logo
