Re: Requests per second/minute monitor?
I haven't looked nor tried your patch (just saw it come into JIRA) yet, but I would welcome having stats in one place and real-time instead of (really: in addition to) analyzing logs. Otis - Original Message From: Will Johnson [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: 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. So far I've added (because I need) avgTimePerRequest avgRequestsPerSecond I agree that you can pull this kind of information from logs but jmx accessibility + the built in stats page make life a good bit simpler especially in distributed environments. Are there any others that people think would be nice to have or should I stop all together? - will -Original Message- 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 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 the logic would be bad .. adding new helper utilities to the RequestHandler Base for handlers that want to do more sounds fine to me. see also http://issues.apache.org/jira/browse/SOLR-176 which already adds a lot of timing info to requests. Yeah, I held off on that as it seemed that timing/statistics might be handleable on a larger scale. OTOH, it does give an easy way to requesthandlers to insert detailed timing data in a logical place in the output. -Mike
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. So far I've added (because I need) avgTimePerRequest avgRequestsPerSecond I agree that you can pull this kind of information from logs but jmx accessibility + the built in stats page make life a good bit simpler especially in distributed environments. Are there any others that people think would be nice to have or should I stop all together? - will -Original Message- 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 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 the logic would be bad .. adding new helper utilities to the RequestHandler Base for handlers that want to do more sounds fine to me. see also http://issues.apache.org/jira/browse/SOLR-176 which already adds a lot of timing info to requests. Yeah, I held off on that as it seemed that timing/statistics might be handleable on a larger scale. OTOH, it does give an easy way to requesthandlers to insert detailed timing data in a logical place in the output. -Mike
RE: Requests per second/minute monitor?
: 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 RequestHandlerBase ... it's a backwards compatibility issue, we want to ensure that data even if you have a custom request handler you've been using since Solr 1.1 (or earlier) : RequestHandlerBase? If things were tracked in the RequestHandlers you : could add timing information there: avg query time, etc. I know some you still can track those things, and return that data or log that data as well ... although if you really wnated to know how long the *whole* request took you would need to do it in teh ResponseWriter (or in the core, after the response has been written) : 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 the logic would be bad .. adding new helper utilities to the RequestHandler Base for handlers that want to do more sounds fine to me. see also http://issues.apache.org/jira/browse/SOLR-176 which already adds a lot of timing info to requests. -Hoss
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 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 the logic would be bad .. adding new helper utilities to the RequestHandler Base for handlers that want to do more sounds fine to me. see also http://issues.apache.org/jira/browse/SOLR-176 which already adds a lot of timing info to requests. Yeah, I held off on that as it seemed that timing/statistics might be handleable on a larger scale. OTOH, it does give an easy way to requesthandlers to insert detailed timing data in a logical place in the output. -Mike
RE: Requests per second/minute monitor?
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 RequestHandlers you could add timing information there: avg query time, etc. I know some people have argued that you can do that with logs but being able to pull that info live via JMX/stats.jsp would make monitoring much cleaner in environments with multiple machines on different networks. If things are tracked in the handlers then people can add more statistics easily to both query response headers and overall via custom handlers. 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. - will
Re: Requests per second/minute monitor?
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 access log? - what the request was (and what handler executed it) currently logged - a status code to signal if the request failed for some reasons currently logged - number of rows fetched The number of documents that matched? That's a higher level concept rather specific to a request handler. That info is returned in most responses though. and - the number of rows actually returned That's also in the response, but would be largely meaningless in general. One could also determine this number from the input parameters and the number of docs that matched. A better number might be size of the response (which is normally in the container access log). fields could be very small, or very large, and faceting, highlighting, or other data could dwarf the size/speed due to the main response documents. -Yonik
Re: Requests per second/minute monitor?
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 you describe is pretty useful. Ultraseek has something similar and that is the log most often used by admins. I'd recommend also logging the start and rows part of the request so you can distinguish between new queries and second page requests. If possible, make the timestamp the same as the HTTP access log so you can correlate the entries. wunder On 5/9/07 9:43 PM, Ian Holsman [EMAIL PROTECTED] wrote: 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 job, or create a separate filter to parse them real time. It would then let you grab more sophisticated stats if you choose to. 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. - IP# of the incoming request - what the request was (and what handler executed it) - a status code to signal if the request failed for some reasons - number of rows fetched and - the number of rows actually returned is this possible? (I'm using tomcat if that changes the answer). regards Ian
Re: Requests per second/minute monitor?
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 job, or create a separate filter to parse them real time. It would then let you grab more sophisticated stats if you choose to. 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. - IP# of the incoming request - what the request was (and what handler executed it) - a status code to signal if the request failed for some reasons - number of rows fetched and - the number of rows actually returned is this possible? (I'm using tomcat if that changes the answer). regards Ian -- View this message in context: http://www.nabble.com/Re%3A-Requests-per-second-minute-monitor--tf3659369.html#a10407072 Sent from the Solr - User mailing list archive at Nabble.com.
Re: Requests per second/minute monitor?
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. Otis - Original Message From: Chris Hostetter [EMAIL PROTECTED] To: solr-user@lucene.apache.org solr-user@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. -Hoss
Re: Requests per second/minute monitor?
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 and produce pretty graphs, no? -Yonik
Re: Requests per second/minute monitor?
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 DisMaxRequestHandler and are available through the MBean interface. If you are running a solr build since yesterday, take a look at the PluginInfoHandler http://localhost:8983/solr/admin/plugins?stats=true This gives you standard response format access to the same info. I'll write up some docs for the wiki shortly Perhaps it should be modified to let you specify a single handler.
Re: Requests per second/minute monitor?
I think the real-time-ness of this is the key. What's the current QPS? How many in-flight queries do we have? What is the average or mean response time? What's the response time for the 90% percentile? etc. Anyhow, not my current itch, just trying to point out what Wunder is after. Otis - 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 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 and produce pretty graphs, no? -Yonik
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. -Hoss
Re: Requests per second/minute monitor?
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
Re: Requests per second/minute monitor?
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 different types of applications. -Yonik
