This article first appeared in the March 2013 issue of GroovyMag. Since the script was originally written Google deprecated the Issue Tracker API and scheduled it for closure on the 14th June 2013. So whilst the script is now for interest only, the principles are still valid for other purposes.

A short while back I had a requirement to rename a Google Code project – it was due to a typo in the project name rather than a ‘cease & desist’ notice. Once my colleague had assigned me owner-level permissions I discovered that even the advanced administration options don’t permit you to change the project name. However, being Google, the issues have an API and being a dab hand with Groovy it was short work to migrate the issues to a new project (sans-typo).

This was early on in the project lifecycle, so the main challenge wasn’t migrating the code (there are several blog posts with instructions on that depending on your flavour of source code control) – rather it was the multitude of issues and comments from a requirements gathering workshop.

The final script is available from GitHub as a gist: https://gist.github.com/rbramley/5073413

API & toolset

The Issue Tracker API is documented at http://code.google.com/p/support/wiki/IssueTrackerAPI

It is a RESTful API using Atom feeds/entries – therefore the tools we’ll use are:

• Apache HttpComponents HttpClient 4.x (replaced commons-httpclient 3.x)
• XmlSlurper – for parsing Atom Feeds that we GET
• MarkupBuilder – for creating Atom entries to POST

Dependencies

HttpClient and its dependencies can be obtained using the Groovy GRAPE @Grab annotations shown in Listing 1. GRAPE (GRoovy Advanced Packaging Engine – http://groovy.codehaus.org/Grape) uses Apache Ivy for dependency resolution and was introduced in Groovy 1.6.

@Grab(group='commons-logging', module='commons-logging', version='1.1.1')
@Grab(group='commons-codec', module='commons-codec', version='1.4')
@Grab(group='org.apache.httpcomponents', module='httpclient', version='4.1.2')
Listing 1: Grab annotations

How does the script work?

To better understand the context of the examples it is useful to quickly recap what the script does – the process is as follows:

1. Form POST credentials
2. If not 403 forbidden, extract auth token (for use in Authorization header on all subsequent requests)
3. GET the issues list from the source project
4. Parse the response body Atom XML (declaring the issues namespace of http://schemas.google.com/projecthosting/issues/2009)
5. For each entry in the feed:
   1. Extract the issue ID
   2. Convert the entry to the required form
   3. POST the Atom entry to the target project issue creation URL
   4. If not 400 bad request, GET the list of comments by issue ID from the source project
   5. Parse the response body Atom XML (declaring the issues namespace as before)
   6. For each entry in the feed:
      1. Convert the entry to the required form
      2. POST the Atom entry to the target project comment creation URL for the current issue

HTTP interaction basics

To work with the API requires the use of two verbs, GET and POST. The examples rely on the definition of HttpClient httpclient = new DefaultHttpClient()

GET

get = new HttpGet(issuesCommentsListUrl)
get.setHeader('Authorization', "GoogleLogin auth=${authToken}")
response = httpclient.execute(get)

println "${response.getStatusLine().getStatusCode()} - ${response.getStatusLine().getReasonPhrase()}"
commentsAtom = EntityUtils.toString(response.entity)
Listing 2: HttpClient GET method

The commentary for Listing 2 falls into two parts: making the request and handling the response.
For the request we have to construct an HttpGet object with the target URL, add the authorization token to the header and then instruct the HttpClient to execute our request.
In terms of handling the response, we require it as a String for XML parsing, so the entity has to be obtained and converted to a String.

Whilst this is fairly straightforward, it doesn’t beat the simplicity of the Groovy augmented getText method on the java.net.URL class (e.g. def response = new URL(url).getText()) – in this case HttpClient is used for consistency and for the ability to set headers.

Login form POST

The first POST operation requires a form post to login, and as shown in Listing 3 the form parameters are constructed using NameValuePair and added to a list. This list is used to construct the URL encoded form entity set on the HttpPost object.

// set up login parameters
NameValuePair accountType = new BasicNameValuePair('accountType', 'GOOGLE')
NameValuePair email = new BasicNameValuePair('Email', emailAddress)
NameValuePair passwd = new BasicNameValuePair('Passwd', password)
NameValuePair service = new BasicNameValuePair('service', 'code')
NameValuePair source = new BasicNameValuePair('source', sourceScript)

HttpResponse response = httpclient.execute(post)
Listing 3: Form POST

If the response status code isn’t a 403 Forbidden, the resulting authorization token is extracted from the body of the response.

POSTing XML

As can be seen in Listing 4, XML payload POST operations are simpler as we are sending the XML using a StringEntity. In this case we also have to set the Content-type header to application/atom+xml.

// post the issue
post = new HttpPost(issuePostUrl)
post.setHeader('Content-type', 'application/atom+xml')
post.setHeader('Authorization', "GoogleLogin auth=${authToken}")
post.setEntity(new StringEntity(issueCreationXml))
response = httpclient.execute(post)
Listing 4: String body POST

Groovy XML processing

Groovy has some very useful helper classes for working with XML – the following sections will cover XmlSlurper and MarkupBuilder as used by the script. GPath, a powerful set of functions for querying nested data structures such as an XML document, is beyond the scope of this article but is worth further investigation if you need to perform more advanced XML handling than is required for the mapping exercise in this script.

Consumption with XmlSlurper

The Groovy XML Slurper (http://groovy.codehaus.org/Reading+XML+using+Groovy’s+XmlSlurper) can parse XML to an object tree and is namespace aware. Listing 5 shows an overview of the important fields in the Atom feed that are used in Listings 6 and 7. As this script was designed for issue migration, we parse the XML into nested objects (Listing 6), which are used to generate XML for recreating the issue in the target project (Listing 7).

<feed xmlns='http://www.w3.org/2005/Atom' ...>
<entry>
  <id>
  <title>
  <content type='html'>
  <author>
    <name>
  </author>
  <issues:id>
  <issues:label>Type-Defect</issues:label>
  <issues:label>Priority-Medium</issues:label>
  <issues:owner>
    <issues:username>
  </issues:owner>
  <issues:state>
  <issues:status>
</entry>
Listing 5: Atom entry fields

// Parse and process the atom feed
feed = new XmlSlurper().parseText(atom).declareNamespace([issues:issuesXmlns])
feed.entry.each { entry ->
  issueId = entry.'issues:id'
  println "Issue ${issueId} - ${entry.title}"

  issueCreationXml = buildIssue(entry, issuesXmlns, atomXmlns)
Listing 6: XmlSlurper

Production with MarkupBuilder

MarkupBuilder is a helper class for creating XML or HTML markup using the closure-based builder syntax. Unlike XmlSlurper groovy.xml.MarkupBuilder isn’t on the standard Groovy classpath so will need to be imported. Listing 7 shows the creation of an Atom entry with the Google Data issues API extensions.

For fine-grained control over specific elements you can use the MarkupBuilderHelper class (http://groovy.codehaus.org/api/groovy/xml/MarkupBuilderHelper.html) that is accessed as mkp and enables direct insertion of data escaped or unescaped e.g. b { mkp.yield( '3 < 5' ) } which results in the output 3 < 5.

/** Build an atom feed for an issue */
def buildIssue(entry, issuesXmlns, atomXmlns) {
  def writer = new StringWriter()
  def xml = new MarkupBuilder(writer)
    
  xml.'atom:entry'('xmlns:atom':atomXmlns,'xmlns:issues':issuesXmlns) {
    'atom:title'(entry.title)
    'atom:content'(type:'html', entry.content)
    'atom:author' {
      'atom:name'(entry.author.name)
    }
    entry.'issues:label'.each {
      'issues:label'(it)
    }
    'issues:owner' {
      'issues:username'(entry.'issues:owner'.'issues:username')
    }
    'issues:state'(entry.'issues:state')
    'issues:status'(entry.'issues:status')
  }
    
  return writer.toString()
}
Listing 7: MarkupBuilder

Groovy User Guide references

http://groovy.codehaus.org/GPath

http://groovy.codehaus.org/Processing+XML

http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper

http://groovy.codehaus.org/Creating+XML+using+Groovy%27s+MarkupBuilder

Executing the script

If you have the need to migrate your issues then the necessary steps are:

1. Create your new target project
2. Add the members from the old project (I did this manually) – this is critical to prevent creation errors
3. Grab the IssueMigrator.groovy script from GitHub gist
4. Change the project names, credentials and script source (lines 32-36)
5. If you have more than 50 issues you’ll need to increase the max-results parameter on line 50
6. Understand that the issues/comments will be created as the account running the script (and it has no warranty) – the original owners will be retained
7. Run the script (either cross your fingers or run against a guinea pig project first!)
8. Sit back and enjoy your new project

You may see some 400 ‘bad request’ responses being output from issue comments where it thinks there have been no updates. This can be ignored as the issue was created in the end state, rather than being created in the start state and then rolled forwards.

In this brief post, we’ll look at how we can monitor elasticsearch using Opsview, which is built on Nagios and thus has access to a wide range of plugins, yet provides a more approachable user interface for configuring service checks.

Opsview configuration

The rest of the article assumes that you’ve got Opsview (or the Opsview VMWare appliance) installed & have completed the Quick Start.

elasticsearch-specific Plugin

We’ll install the plugin from https://github.com/rbramley/Opsview-elasticsearch into /usr/local/nagios/libexec/

The check_elasticsearch plugin is developed using Perl, so that it can be contributed back to Opsview. It requires the CPAN JSON module (sudo cpan -i JSON).

The plugin includes usage instructions, check_elasticsearch -h which can also be viewed in Opsview by selecting the ‘Show Plugin Help‘ link beneath the Plugin drop down.

Service check setup

Figure 1 gives an overview of service check configurations.

Figure 1 – Check definitions overview

The checks in action

The check results shown in Figure 2 are visible by navigating through the host group hierarchy.

Figure 2 – service check results

Note: They’re showing as warning because the checks were run against a standalone instance rather than a cluster.

Summary

The current checks are based on the Cluster Health API, the intention is to add stats/status checks too that will take threshold criteria and output performance data. The code for the check is on GitHub at https://github.com/rbramley/Opsview-elasticsearch so feel free to fork & send pull requests.

The following assume you already have both Opsview Server and OpenStack Object Storage (Swift) configured and running.

Pre-requisite set up tasks

The machine running the check needs to have a Swift client and an Opsview Agent. If you plan to monitor from a Swift proxy server you should only need the latter; if you plan to execute the checks from your Opsview server, then you’ll need the former.

Installing the Swift client

This relies on having Python installed – grab the source from:
https://github.com/openstack/python-swiftclient.git
https://github.com/openstack/python-keystoneclient.git
sudo python setup.py install (for both)

Installing the Opsview Agent on Ubuntu

echo "deb http://downloads.opsview.com/opsview-core/latest/apt precise main" > /etc/apt/sources.list.d/opsview-core.list
apt-get update
apt-get install opsview-agent


Obtaining the check

The plugin details are here:
http://exchange.nagios.org/directory/Plugins/Clustering-and-High-2DAvailability/check_swift/details

The direct download link:
http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3589&cf_id=30

Place this into /usr/local/nagios/libexec (on the Opsview Agent) and make the file executable (chmod +x check_swift) and owned by nagios (chmod nagios:nagios check_swift).

Environment variables

If you don’t already have the ST_AUTH (tenant), ST_USER and ST_KEY environment variables set, then you may want to modify the check accordingly (as per the following diff):
diff check_swift.orig check_swift
52c52
< export OS_AUTH_URL=$OPTARG
---
> export ST_AUTH=$OPTARG
55c55
< export OS_USERNAME=$OPTARG
---
> export ST_USER=$OPTARG
58c58
< export OS_PASSWORD=$OPTARG
---
> export ST_KEY=$OPTARG


Setting up NRPE

Whilst you could run the check from your Opsview server (if you install the Swift client), it is’d more likely it would be executed on an Opsview Agent via NRPE.
Therefore we need to add a service check command to the NRPE configuration on the Opsview Agent:
echo "command[check_swift]=/usr/local/nagios/libexec/check_swift \$ARG1\$" >> /usr/local/nagios/etc/nrpe_local/override.cfg
/etc/init.d/opsview-agent restart


Configuring the check

On your Opsview server you’ll need to define a new Service Check, Figure 1 shows a completed example.

Figure 1 – Service check definition

If you like to copy & paste, the arguments to check_nrpe are:
-H $HOSTADDRESS$ -c check_swift -a '-V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete -c container'

Substitute the values as applicable or override them at the host-level.

The check in action

Figure 2 shows the host-level view of the service check (note that it appears to be ignoring the -c container value).

Figure 2 – Service check results

There you go, quick and easy basic monitoring of OpenStack Swift.

Troubleshooting

If it doesn’t work, first check you can perform an upload using the swift client: swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete upload container check_swift

The second test is to verify the Nagios plugin returns a zero exit code:
check_swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete -c container
echo $?
Note that the plugin redirects output to /dev/null so you may need to tweak a copy of the script so that you can see the swift error messages if this step fails.

Lastly test NRPE:
check_nrpe -H localhost -c check_swift -a '-V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete -c container -s 128'

TLDR: Grails Solr Plugin using 3.5.0 3.6.0 available from https://github.com/rbramley/grails-solr-plugin pending https://github.com/mbrevoort/grails-solr-plugin/pull/2

Phase one: SolrJ

I started by upgrading the plugin from Grails 1.3.4 to 2.0.0 – other than application.properties, this affected the DataSource.groovy file with the switch from hsqldb to h2.

The next step was to remove the bundled SolrJ jar + dependencies from lib and move to using Ivy dependency management by adding a BuildConfig.groovy file with the following dependency for SolrJ:
compile ('org.apache.solr:solr-solrj:3.5.0') {}

Upon running the tests I hit a few failures, I fixed up a unit test assertion in SolrUtilTests.groovy by coercing a return value to a String and changing the expected value from a GStringImpl to a String. The integration tests weren’t passing as the Start Solr script wasn’t working – it wasn’t on the critical path for the project so that was deferred to phase 2.

Phase two: Bundled Solr

1. Failing integration tests

The starting point of phase 2 was to get the integration tests working so that changes going forward were from a known good starting point.

As mentioned beforehand, the Start Solr (grails start-solr) script wasn’t working so that was the first port of call. The failure was caused by a missing log directory from ~/.grails/<project name>/solr-home which was easily rectified with an addition to the script:

def solrLogDir = "${solrHome}/logs"
if(! new File(solrLogDir)?.exists()) {
  Ant.mkdir(dir: "${solrLogDir}")
}


Alright, so now the integration tests can run, but they’re still working against Solr 1.4 – time to get on with the version upgrade.

2. Upgrading solr-local to 3.5.0

I followed the existing plugin pattern of an embedded war file and jars for speed – though it might be nicer to move this to dependencies managed from the start script.

This was simply a case of unpacking Solr 3.5.0 over the top and merging / fixing up the configuration and schema.

3. Spatial

This error message: Expected identifier at pos 87
str='sum(hsin(0.6935790722757577,-1.8323287385596856,latitude_rad_d,longitude_rad_d,3963.205))' required a change to use the Solr 3.1+ hsin syntax.

4. Assertion errors

In two cases the expected field value in the DomainMethodTests was returning an array rather than the SolrId – the quick fix was to use the first element.

Tests passing = upgrade completed so it was committed and pushed to https://github.com/rbramley/grails-solr-plugin before sending a pull request.

Usage

If you take it from my GitHub repo, you can either download the packaged plugin or grab the full source and package the plugin; the plugin zip can then be installed into your local project (this would need doing on each environment e.g. CI).
Alternatively you can use a local plugin repo (see the Plugins chapter of the Grails user guide) or lobby for the pull request to be merged in and the updated plugin to be released!

Summary

The upgrade was completed and a pull request (https://github.com/mbrevoort/grails-solr-plugin/pull/2) sent upstream to Mike Brevoort, but sadly he hasn’t had the time to merge this in and meanwhile Solr 3.6.0 was released… So I’ve upgraded it again – all the tests pass but be aware that I haven’t had the chance to test it more extensively.

This article originally appeared in the February 2012 edition of GroovyMag.

About Mahout

Mahout started off as a sub-project of Apache Lucene and the name is a Hindi word referring to an elephant driver; portions of Mahout are built on top of Hadoop which was named after a stuffed toy elephant owned by the son of Doug Cutting who started that project.

Hadoop was extracted from the Nutch crawler Lucene sub-project and provides a scalable data processing framework using Map-Reduce on top of a distributed file system (HDFS). The use of Hadoop is beyond the scope of this introductory article.

Mahout has three primary areas of machine learning functionality: classification, clustering and recommendations.

Classification can be used to determine how similar an item is to previously encountered items or patterns and whether it belongs to the same category.

For instance, Mahout supports Naive Bayes classification with the ‘hello world’ sample training a classifier and then classifying posts from 20 newsgroups (a common reference data set for machine learning research).

Clustering groups items together based on their similarity – e.g. this can be observed in Google search results.

We’re going to focus on recommendations, sometimes referred to as collaborative filtering. Amazon is a well-known example of providing suggested "other people also bought" products.

For further information on Mahout and clustering or classification I suggest you read Mahout in Action (see what I did there?).

Recommendations

Recommendations provide a discovery mechanism to introduce users to new items that may be of interest to them; it is usually associated with cross-selling tactics (e.g. ‘Also bought’) on retail e-commerce sites.

Mahout provides a set of components to enable the construction of customised recommendation engines.

Firstly there is the Recommender that will produce recommendations based on a DataModel.

A user-based recommender will look for similar preferences or behavior patterns between users (UserSimilarity), and then group these into neighbourhoods (UserNeighborhood) e.g. the nearest 10 users to the specified user. The chosen algorithm will then select the recommendations of new items from within the neighbourhood.

An item-based recommender works on similarity between items (ItemSimilarity).

The DataModel has a very simple representation of the Preference data to work with: a long user-id, a long item-id and a float preference value. This is limited to a tuple to reduce memory consumption and therefore increase scalability. DataModel implementations are available for files, MySQL, generic JDBC and Postgres.

https://cwiki.apache.org/MAHOUT/recommender-documentation.html has lots more useful information and further links.

Grails recommendations

Lim Chee Kin has been hard at work and recently released a Grails Mahout-Recommender plugin in December 2011. The plugin is intended to let you evaluate different recommenders without needing to write any code; once you have selected a recommender then it can be enabled using configuration.

We’ll start by looking at the sample packaged libimseti application based on code from chapter 5 of Mahout in Action which uses 17+ million profile ratings from a Czech dating site to recommend compatible user profiles.

Libimseti

Getting set up

I created a clean Grails 2.0.0 application and installed the plugin (version 0.5.1 at time of writing) using
the commands in Listing 1. The plugin adds some new scripts, including the ability to install a sample application that we can run using the grails install-libimseti-sample-app command.

grails create-app GroovyMagMahout
cd GroovyMagMahout
grails install-plugin mahout-recommender

Listing 1: application creation and plugin installation

Sample data

The Libimseti sample data is not redistributable, so you’ll need to download the zip from http://www.occamslab.com/petricek/data/libimseti-complete.zip and then extract the .dat files to grails-app/conf

Configuration

There are two more things we need to do before we can run the Grails application, firstly we need to adjust the plugin configuration in Config.groovy to add the settings from Listing 2 and we also need to give Grails some more memory for the hungry algorithm to prevent an "OutOfMemoryError: GC overhead limit exceeded" which is achieved by Listing 3.

mahout.recommender.hasPreference = false
mahout.recommender.data.file = 'ratings.dat'


Listing 2: Additional plugin configuration

export GRAILS_OPTS="-XX:MaxPermSize=256m -Xmx1024M -server"
Listing 3: Increasing the memory allocated to Grails

Libimseti sample usage

When we execute grails run-app and browse to http://localhost:8080/GroovyMagMahout we will see that as per Figure 1 we have a single recommender controller listed.

Figure 1: Application home page

Selecting the controller will bring us to the settings form shown in Figure 2.

Figure 2: Recommender settings

Enter user ID ’133′, submit the form and after some time (the algorithm is tuned for better matching rather than performance) you’ll see the recommendations shown in Figure 3 where a higher score means a better match.

Figure 3: Recommendations

What next?

The libimseti sample application is good to prove that the theory works on a reasonably sized dataset, but not many of us are going to want to curate our data to match an input file. More realistically we’ll have an application that has associations between users and items or allows users to rate items.

We’ll build a simple Grails implementation – the source code is available on GitHub from https://github.com/rbramley/GroovyMagMahout

The data model

As a simplification for this exercise we will use a single preference table, this will represent the link (many-to-many join) table between a user and an item as illustrated in ERD notation in Figure 4.

Figure 4: Sample ERD

This table will have a composite primary key comprising of the user and items IDs and then a value rating the strength of the preference. For the preference we’ll use a 1 to 5 range as this may be represented by a rating widget (such as that provided by the Grails Rich UI plugin).

We’ll create a domain class (using grails create-domain-class com.rbramley.mahout.Preference) and specify it as per Listing 4. Note that we’ve used a composite key to satisfy Mahout’s needs, but this exposes a view minor Grails issues with the generated default controller and views (grails generate-all com.rbramley.mahout.Preference) not being composite-key aware (this shouldn’t affect you unless you want to edit/delete preference records).


package com.rbramley.mahout
 
import org.apache.commons.lang.builder.HashCodeBuilder
 
class Preference implements Serializable {
    long userId
    long itemId
    float prefValue
 
    static constraints = {
        userId()
        itemId()
        prefValue range: 0.0f..5.0f
    }
 
    boolean equals(other) {
        if(!(other instanceof Preference)) {
           return false
        }
 
        other.userId == userId && other.itemId == itemId
    }
 
    int hashCode() {
        def builder = new HashCodeBuilder()
        builder.append userId
        builder.append itemId
        builder.toHashCode()
    }
 
    static mapping = {
        id composite: ['userId', 'itemId']
       version false
    }
}


Listing 4: Domain class

We’ll use MySQL for the database, as that Mahout DataModel provider implementation is supported by the Grails plugin (Mahout also has Postgres and generic JDBC implementations).

Firstly we need to create the target schema in MySQL (Listing 5).


mysql -u root -p
mysql> create database recommender;
mysql> grant all on recommender.* to recommender@localhost identified by 'mahoutdemo';


Listing 5: MySQL commands

With that done we can uncomment the runtime mysql-connector-java dependency in BuildConfig.groovy and then configure DataSource.groovy accordingly (Listing 6).


    development {
        dataSource {
            driverClassName = "com.mysql.jdbc.Driver"
            dbCreate = "create-drop" // one of 'create', 'create-drop', 'update', 'validate'
            url = "jdbc:mysql://localhost:3306/recommender"
            username = "recommender"
            password = "mahoutdemo"
        }
    }


Listing 6: Development data source configuration

Reconfiguring the plugin

We now need to reconfigure Config.groovy to instruct the plugin which recommender and similarity algorithms to use and where to obtain the data from, this is achieved using the settings in Listing 7.


mahout.recommender.mode = 'config'  // 'input', 'config' or 'class'
mahout.recommender.hasPreference = true
mahout.recommender.selected = 1 // user-based
mahout.recommender.similarity = 'PearsonCorrelation'
mahout.recommender.withWeighting = false
mahout.recommender.neighborhood = 2
mahout.recommender.data.model = 'mysql'
mahout.recommender.preference.table = 'preference'
mahout.recommender.preference.valueColumn = 'pref_value'


Listing 7: Plugin configuration

Providing data

We can now run the application, select the new com.rbramley.mahout.PreferenceController and enter some values for our data.

If you enter the data set shown in Figure 5, then when you use the recommendations controller to obtain recommendations for user ID 1, you should get the recommendations of 104 and 106 as shown in Figure 6.

Figure 5: Sample data values

Figure 6: Recommendations for User Id 1

Alternatively there is a SQL script within the project on GitHub that can be run to seed the preferences table with similar data (based on listing 2.1 from Mahout in Action).

Evaluating recommenders

The Grails plugin features a built in recommender evaluator based on average difference, in our case we can access it at http://localhost:8080/GroovyMagMahout/recommender/evaluator and click on the ‘Run Evaluator’ link, the sample output is shown in Figure 7.

A lower difference is better – so you may want to experiment with changing the mahout.recommender.similarity property that we set in Listing 7, valid values are ‘PearsonCorrelation’, ‘EuclideanDistance’, ‘LogLikelihood’ or ‘TanimotoCoefficient’.

Figure 7: Recommender evaluation

Likewise you may want to modify other properties such as applying weighting or adjusting the size of the neighbourhood – in any case please refer to the configuration section of the plugin manual at http://limcheekin.github.com/mahout-recommender/docs/manual/guide/configuration.html

Summary

This article has introduced Apache Mahout, an open source scalable machine learning framework, and shown how you can utilise it to provide personal recommendations within a Grails application. We’ve seen custom recommendations for the libimseti sample data files and recommendations based on user similarity on top of a Grails domain class. In practice these recommenders would ideally be invoked asynchronously particularly for large data sets, this could be achieved using AJAX techniques.

Have fun integrating stylised recommendations into your application, but remember it’s good to allow the users to give feedback on the relevancy of the recommendations!

References / further reading

The following provide valuable sources of information:

• http://mahout.apache.org
• https://cwiki.apache.org/MAHOUT/recommender-documentation.html
• http://grails.org/plugin/mahout-recommender
• http://limcheekin.github.com/mahout-recommender/docs/manual/guide/single.html
• http://www.manning.com/owen/ – Mahout in Action

The ‘As a <user type>, I want to <action to be performed>, so that <business benefit>‘ user story structure encourages good requirements but can often be abused!

If you’re tasked with writing user stories or requirements, then I suggest that you read the Open Unified Process documentation guidance on ‘Writing good requirements‘:

• Define one requirement at a time.
• Avoid conjunctions (and, or) that make multiple requirements.
• Avoid let-out clauses or words that imply options or exceptions (unless, except, if necessary, but).
• Use simple, direct sentences.
• Use a limited (500-word) vocabulary, especially if your audience is international.
• Identify the type of user who needs each requirement.
• Focus on stating what result you will provide for that type of user.
• Define verifiable criteria.

(see the OpenUP wiki link for the introduction and examples)

Numbering

Or rather: numbering schemes with respect to grouping and ordering

For traceability it is critical for a requirement to have a unique identifier. No arguments on that front, but the challenge comes when people get to choose their own numbering scheme for requirements.

e.g.

1. First requirement
2. Second requirement
3. Third requirement

All good so far you might think – it’s exactly the way they be numbered if I’d entered them in an issue tracker.
Well let’s suppose that at the first pass that the list is in a spreadsheet, was collated by functional area and contains over 50 items.

It can easily go awry on subsequent iterations (e.g. after review cycles, prioritisation meetings etc.) when people haven’t written good requirements (see above) or you have epics that need splitting. At this point a system would append a row which is given a sequentially generated primary key, whereas with a spreadsheet the natural inclination is to insert a row into the table which then introduces the numbering dilemma.

There are 3 common behaviours:

• Generations of people trained in using numbered headings in documents will typically go with the nesting instinct e.g. 2.1.3
• Information workers who’ve dealt with numbering schemes such as Dewey Decimal might have used non-contiguous numbering in the first place e.g. start each new functional area at the next 100 – which may prevent or just defer the issue
• Data modellers may opt for the foreign key approach for splits and use other columns for grouping/sorting.

I’d encourage the latter approach, append to the table then re-sort later and don’t get hung up on having beautifully ordered reference numbers. After all you’re not doing Big Requirements Up Front are you?

Final thought

“Adding power makes you faster on the straights. Subtracting weight makes you faster everywhere” – Colin Chapman

Think about the implications of this philosophy when writing and prioritising requirements!

The good news is that MarkLogic have released a Nagios plugin.

The reference manual is available from http://developer.marklogic.com/pubs/5.0/books/monitoring.pdf (see chapter 3 for Nagios specifics) and the plugin itself from http://developer.marklogic.com/download/binaries/nagios/MarkLogic-Nagios-Plugin-1.0-1.tar

Installing the plugin

You’ll only need to follow the first 3 steps of section 3.4 of the Monitoring MarkLogic Guide, in essence:

1. Unzip the plugin tar
2. Copy/move check_marklogic.pl to /usr/local/nagios/libexec
3. chmod +x check_marklogic.pl

Setting up a service check

Once the plugin has been installed we can define service checks, Figure 1 shows two simple examples (using a clean install of MarkLogic plus the Hadoop Connector – maybe a topic for another blog post?).

Figure 1 – Simple MarkLogic check definitions

You would normally want to set up finer-grained service checks with thresholds – consequently the plugin accepts additional arguments (but doesn’t support the de facto help argument) to specify keys (-k), warning (-w) and critical (-c) thresholds. Note that the thresholds can use an operator (-op) argument. These arguments are fully detailed in section 3.5.2.3 of the Monitoring MarkLogic Guide.

Checks in action

Figure 2 shows the host-level view of the service checks, with the detail of the performance data behind them shown in Figures 3 and 4.

Figure 2 – MarkLogic service check summaries

Figure 3 – Document count service check detailed results

Figure 4 – Status service check detailed results

There you go, quick and easy basic monitoring of MarkLogic.

This article originally appeared in the September 2011 edition of GroovyMag.

Lucene

Apache Lucene Core provides a Java-based indexing and search implementation. In essence, the index is made up of documents that are comprised of fields.

Indexing

When you index a document, the fields are processed through a tokenizer to break it into terms. Figure 1 shows the effect a whitespace tokenizer would have on splitting “Mary had a little lamb” into the tokens: Mary, had, a, little, lamb.

Figure 1: Whitespace tokenization

The terms may undergo further analysis through TokenFilter classes. Figure 2 shows a stop words filter removing common terms that would skew relevancy.

Figure 2: Stopwords

Figure 3 shows the PorterStemFilter applying the (English) Porter stemming algorithm to reduce tokens to their word stems so that they are equated. This TokenFilter needs to work on lower case input – so the LowerCaseFilter / Tokenizer should be used before the stemming.

Figure 3: Word stemming

Lastly, the terms are then mapped to their documents as shown in Figure 4.

Figure 4: Term index

Index updates

Updates to index documents are handled as a delete operation followed by an add operation. Over time the index segments can become fragmented – this can be cured by running an optimization operation to pack the index.

Querying

The queries in Lucene need to pass through the same analyzers as were used during indexing – otherwise identical terms might not match.
A single word query (TermQuery) requires a lookup in the term index to return the matching documents.

e.g. querying the term index shown in Figure 4 for ‘consignment’ would return documents 1, 4 and 7.

A two word query (BooleanQuery) requires Lucene to perform two lookups in the term index then filter the resulting documents on either an AND or an OR basis (from an explicit or default operator). e.g. querying the Figure 4 term index for ‘consign AND ship’ would return document 4, whereas ‘consign OR ship’ would return documents 1, 4 and 7.

A phrase query is denoted by double quotes (e.g. “new york”) and matches documents containing a particular sequence of terms. This relies on positional information in the index. Phrase slop, or proximity, is specified using the ~ operator and an integer to specify how close the terms in the phrase need to be together. e.g. “big banana”~5 would match documents containing “big banana”, “big green banana” and “big straight yellow banana”

By default results are returned in relevancy order, and the score is calculated by a formula (if you’re really interested it is in the JavaDoc for the Similarity class – http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/search/Similarity.html). The score can be influenced by boosting terms. e.g. the query ‘subject:lucene OR author:bramley^2′ would boost the score contribution of the author field two-fold for documents whose author fields contained ‘bramley’.

Tools

Before we get onto the practical application it is worth mentioning that Luke, the Lucene Index Toolbox, is an invaluable tool for allowing inspection, searching and browsing of Lucene indices.

It is available from http://code.google.com/p/luke/ – but be aware that you need to use the right version to match the version of Lucene that created your indices. This has been made easier and more obvious as the version numbers of Luke now correspond directly with Lucene versions (e.g. Luke 3.3.0 is for Lucene 3.3.0, however Luke 0.9.9.1 is based on Lucene 2.9.1).

Implementing in Grails

Rather than a Twitter-style application, we’ll build a simple To-Do list application with one domain class to represent the to-do Item, shown in Listing 1, which will use a generated controller and views (you may choose to enable scaffolding instead).

We’ll use this along with the Figure 5 test data in 3 similar applications to showcase the different Lucene-related Grails plugins. All the sample applications are available on GitHub under https://github.com/rbramley/GroovyMagLucene


package com.rbramley.todo
 
class Item {
    Date dateCreated
    String subject
    Date startDate
    Date dueDate
    String status
    String priority
    boolean completed = false
    int percentComplete = 0
    String body
 
    static constraints = {
        subject(blank:false, nullable:false)
        startDate()
        dueDate()
        status(inList:["Not Started","In Progress","Completed","Waiting on someone else","Deferred"])
        priority(inList:["Low","Normal","High"])
        completed()
        percentComplete(range:0..100)
        body(nullable:true, maxSize:1000)
    }
}

Listing 1: the Item domain class

Figure 5: Test data

Searchable plugin

The Searchable plugin makes use of Compass::GPS to index Hibernate domain objects using GORM/Hibernate lifecycle events. The plugin also provides a default search controller and view. The aim, which lives up to Marc Palmer’s recommendations, is to make full text searching of your domain objects as simple as possible.

The first step is to install the plugin using grails install-plugin searchable.

Once we’ve created the domain class (grails create-domain-class com.rbramley.todo.Item) and populated it with the code from Listing 1, we then add a static searchable property to the domain class: static searchable = [except: 'dateCreated']

Running the application, select the com.rbramley.todo.ItemController link from the home page, and enter the test data from Figure 5.

Return to the home page and then select the grails.plugin.searchable.SearchableController link.

Enter the query ‘timesheet’ in the search box then click the ‘Search’ button – this will give you the results as shown in Figure 6.

Figure 6: Searchable results

There you have it – quick and easy full text search on your domain model. Whilst the style may not match with our application, at least it gives us something to work from.

Note that the plugin stores the indices under ~/.grails/projects/<project-name>/searchable-index/<environment>

Solr plugin

Version 0.2 of the plugin was released in January 2010, is compatible with Grails 1.1+ and bundles an old 1.4 release of Solr and SolrJ. It would be nice to see a new version of this plugin with a current Solr release and updated for the newer dependency resolution mechanisms – if you’ve got time to help out you can fork it on GitHub at http://github.com/mbrevoort/grails-solr-plugin

Once you’ve installed the plugin using ‘grails install-plugin solr‘, the ‘grails start-solr‘ script will start up a default Solr instance using Jetty. This is located in ‘solr-home‘ under the project working directory (based on the Grails build settings) using the example Solr schema and configuration. Whilst this example configuration is fine for evaluation, I (and Lucid Imagination) would strongly recommend you don’t use this configuration in production. For instance, you’ll need to modify this if you want to use the dismax handler (at which point you’re probably better off with a separate installation and version controlled configuration).

The plugin makes good use of convention (leveraging Solr dynamic fields) and meta-programming to add methods to domain classes.

How does it do auto-indexing?

If you check out the plugin doWithApplicationContext closure, you will see that a listener is registered for the post- insert/update/delete events.

What about search?

This is handled by the SolrService which uses the SolrJ client and constructs a simple query (here it would be nice to leverage dismax). However the plugin author (Mike Brevoort) has also helpfully provided the ability to construct your own advanced query and supply that to the SolrService.

Now we’ve uncovered how it works out of the box – it’s time to write some code so we can take it for a test drive.

The plugin can be installed by grails install-plugin solr.

Again we’ll use the domain class from Listing 1, but this time adding the two properties, static enableSolrSearch = true and static solrAutoIndex = true

Once the domain class is completed we can generate the controllers & views:

grails generate-all com.rbramley.todo.Item

We’ll add a search box to the main.gsp layout. This is shown in Listing 2 and styling has been left as an exercise for the reader (note you can supply an image for the search button). This submits to the search controller (created using grails create-controller com.rbramley.todo.Search – and populated by Listing 3) with the search.gsp displaying the results (Listing 4 shows a fragment).


<div>
     <strong>Quick search</strong>
    <g:form url='[controller: "search", action: "search"]' id="searchForm" name="searchForm" method="get">
         <input type="text" name="query" value="${query ?: 'Keywords'}" onClick="javascript:if (this.value=='Keywords') { this.value='' }">
        <input type="image" src="${resource(dir:'images',file:'go_quick_search.png')}">
    </g:form>
</div>

Listing 2: main.gsp search box


package com.rbramley.todo
 
class SearchController {
    def solrService
 
    def search = {
        def res = solrService.search("${params.query}")
        [query:params.query, total:res.total, searchResults:res.resultList]
    }
}

Listing 3: Search controller code


<g:if test="${haveResults}">
    <g:each var="result" in="${searchResults}">
        <g:set var="className" value="${ClassUtils.getShortName(result.doctype_s)}" />
        <li><solr:resultLink result="${result}">${className}: ${result.id}</solr:resultLink></li>
        ${result.subject?.encodeAsHTML()}
    </g:each>
</g:if>

Listing 4: Results page fragment

Before you start the Grails application, you need to start Solr using grails start-solr.

Once Solr and then Grails have started, we can create an item using the Figure 5 test data, then search for it using ‘timesheet’.

Why are there no results?

The plugin doc states that it will search against the default Solr field (which by default is called ‘text’).

Trying again: subject_s:timesheet also returns no results…

So let’s try a phrase query: subject_s:”Complete timesheet” as shown in Figure 7 – this one works because we’ve supplied the whole string to match, this is due to
“The StrField type is not analyzed, but indexed/stored verbatim.”

Figure 7: Solr with fully specified query

Figure 8 shows the result of inspecting the subject field using Solr’s Luke request handler (http://localhost:8983/solr/admin/luke).

Figure 8: Solr Luke analysis of subject field

So to get the desired results we’ll need to do some Solr configuration, and we have the following options:

1. Map the fields to text type so that they are analyzed (can also be forced to text through annotations) and use copy field directives to copy them to the default text field
2. Configure a dismax handler (beyond the scope of this article) to have more flexible control over the fields that are queried by default

If we change the Solr schema, we’ll need to do a full re-index – or in our case with a test application in development mode, we can just delete the index files (typically in ~/.grails/<grails-version>/projects/GroovyMagSolr/solr-home/solr/data).

First we’ll modify Item.groovy to add import org.grails.solr.Solr and then add the Solr annotation to the String subject field e.g. @Solr(asText=true) – this will cause the field to be indexed as subject_t. We’d now be able to search for subject_t:timesheet and get a match – but this still doesn’t meet our usability requirements as it requires knowledge of the underlying document fields. We could use an explicit <copyField source="subject_t" dest="text"/> in the Solr schema.xml, however if you inspect the schema.xml you will see that the first 3000 characters of all ‘_t’ fields are copied to the ‘text’ field.

Now a search for ‘timesheet’ gives the results shown in Figure 9.

Figure 9: Solr simple query result

ElasticSearch plugin

ElasticSearch (http://www.elasticsearch.org/) is a new Lucene-based distributed, RESTful search engine. It was created by Shay Banon, who created Compass (used by the Searchable Plugin) and has worked on data grid technologies.

Version 0.2 of the Grails plugin uses ElasticSearch 0.15.2 – you can start with an embedded instance in development mode which stores the indices in the project source directory under ‘data’.

The first step (within a clean application) is to install the plugin:

grails install-plugin elasticsearch

Then create the domain class (grails create-domain-class com.rbramley.todo.Item) and fill in using the Listing 1 domain class code with the addition of Listing 5.


    static searchable = {
        except = 'dateCreated'
    }

Listing 5: ElasticSearch mapping

Once that is done and the controller and views generated (grails generate-all com.rbramley.todo.Item), we can then create our Search controller (grails create-controller com.rbramley.todo.Search) and complete it using Listing 6.


package com.rbramley.todo
 
class SearchController {
    def elasticSearchService
 
    def search = {
        def res = elasticSearchService.search("${params.query}")
        [query:params.query, total:res.total, searchResults:res.searchResults]
    }
}

Listing 6: ElasticSearch controller

Let’s re-use the main.gsp from the GroovyMagSolr application (Listing 2) and we’ll adapt the search.gsp fragment from Listing 4 to get Listing 7.


<g:if test="${haveResults}">
    <g:each var="result" in="${searchResults}">
        <g:set var="className" value="${ClassUtils.getShortName(result.class)}" />
        <g:set var="link" value="${createLink(controller: className[0].toLowerCase() + className[1..-1], action: 'show', id: result.id)}" />
        <li><a href="${link}">${className}: ${result.id}</a></li>
        ${result.subject?.encodeAsHTML()}
    </g:each>
</g:if>

Listing 7: Search results page for ElasticSearch

Having started up the application and entered the test data as shown in Figure 5, I hit a problem in that the database record was created but the index record wasn’t and the console was filling up with repeated log entries until I stopped the application:


2011-08-20 22:33:51,630 [elasticsearch[index]-pool-2-thread-1] ERROR index.Index
RequestQueue - Failed bulk item: NullPointerException[null]
2011-08-20 22:33:51,633 [elasticsearch[index]-pool-2-thread-2] ERROR index.Index
RequestQueue - Failed bulk item: NullPointerException[null]


When I looked at the IndexRequestQueue source, the JavaDoc says “If indexing fails, all failed objects are retried. Still no support for max number of retries (todo)”.

The NullPointerException itself is ElasticSearch bug 795 – but the underlying cause seems to be that the JSON document didn’t meet the expectations of ElasticSearch for that type!

I got the plugin working by changing the domain class searchable mapping to only = 'subject' – then the results look identical to Figure 9.

In the time available I didn’t manage to track down the initial issue (I also tried with an external ElasticSearch instance and upgrading the ElasticSearch dependencies to 0.16). I’ll be in communication with the plugin authors…

Plugin comparison

So how do they compare? Well this article has given a basic introduction to their usage for English text and hasn’t demonstrated advanced features or the distributed capabilities of the latter two.

The criteria for comparison is partially inspired by Marc Palmer’s views on plugins – a distilled form is “make it work, make it simple, make it magic”; we’ll also add scalability to this list.

Searchable

This is a well established plugin and works very well out of the box with simple domain classes and even relationships. It is simple to use, works as expected and provides a basic search page and controller which includes some administrative actions such as the ability to re-index all searchable domain classes.

I’ve occasionally encountered older versions throwing exceptions on start-up that could be rectified by removing the indices and restarting the application.

On the downside, due to the embedded nature of the indices, it is only really suitable for single-instance applications.

Solr

This plugin requires some configuration to get the best out of it and it could benefit from some attention to update it. However, it does have reasonable documentation and some powerful features such as faceted-search, spatial search and taglibs for facets and result links.

Also it should be possible to index domain classes that use Mongo through the use of the metaClass added indexSolr() method.

ElasticSearch

This plugin has great promise – although I encountered some issues relating to the ElasticSearch expectation of the index document structure, I should mention that the plugin documentation currently contains the warning “you should only use this plugin for testing”.

The main attraction of ElasticSearch is the real time search with a distributed and scalable nature.

As per the Solr plugin, it should also be possible to index Mongo-mapped domain classes using a metaClass added index() method.

References

For further reading the DZone Refcardz provide good overviews:

• http://refcardz.dzone.com/refcardz/lucene
• http://refcardz.dzone.com/refcardz/solr-essentials

Firstly thanks to Jeff Winkler for bringing the new GMetrics v0.5 CrapMetric to my attention and thanks to Chris Mair for his great work on GMetrics (and Codenarc).

What is Change Risk Anti-Patterns?

It is a method to analyze and predict the amount of effort, pain, and time required to maintain an existing body of code. Given a Java method m, C.R.A.P. for m is calculated as follows:
C.R.A.P.(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)
Where comp(m) is the cyclomatic complexity of method m, and cov(m) is the test code coverage provided by automated tests.
For more background information see this blog post describing the C.R.A.P. metric.

Setting up Grails

This is very fresh so you’ll need to do a little bit of tinkering until I can get the following changes incorporated into the GMetrics plugin!
Note you’ll also need to have the Code Coverage plugin installed (refer to “Grails & Hudson Part 3: Testing” for more details on that).

Install the GMetrics plugin

This is the straightforward bit:
grails install-plugin gmetrics

The hackery

With GMetrics plugin version 0.3.1 you’ll need to edit the installed plugin dependencies.groovy (e.g. ~/.grails/1.3.7/projects/foo/plugins/gmetrics-0.3.1/dependencies.groovy) to use gmetrics 0.5 instead of 0.3.
Line 27 should be changed to:

provided('org.gmetrics:GMetrics:0.5') {
}


And you’ll want to modify scripts/gmetrics.groovy to use metricSetFile on the Ant task otherwise it will just use the default metrics which doesn’t include C.R.A.P.
e.g. line 44 should become:

ant.gmetrics(metricSetFile:metricSetFilename)


Define a metric set

We now need to tell GMetrics which metrics to run – out of laziness I saved this in the root of the Grails project as test.gmetrics:

import org.gmetrics.metric.cyclomatic.CyclomaticComplexityMetric

    CRAP {
      functions = ['total']
      coverageMetric = coberturaMetric
      complexityMetric = cyclomaticComplexityMetric
    }
  }


Configure the plugin

If you want the HTML report, then your Config.groovy will need a single addition to specify the metric set:

gmetrics.metricSetfilename = 'file:test.gmetrics'


If you want an XML report you’ll also need:

gmetrics.outputFile = 'target/test-reports/GMetricsReport.xml'
gmetrics.reportType = 'org.gmetrics.report.XmlReportWriter'


Let’s go

Now it’s all configured, we just need to ensure that we have coverage data before we run the CrapMetric.

e.g.
grails test-app -unit -coverage -xml

We can now run:
grails gmetrics

The report will be generated and the plugin output will state where it has been written to. The CRAPpy threshold has been defined as 30 – so the report will help to highlight the areas of code that you need to concentrate on first.

Remember that over complex code with full test coverage can still be classed as CRAPpy.

In this post, we’ll look at how we can monitor Solr, what performance metrics we might want to gather and how we can easily achieve this with Opsview.

We’ll use Opsview as it is built on Nagios and thus has access to a wide range of plugins, yet provides a more approachable user interface for configuring service checks.

A check list for service checks

Solr is built on Lucene so follows the same layout, an index contains documents that are comprised of fields. As part of the search service value add over Lucene, Solr provides a number of useful ways of obtaining health status / monitoring metrics:

1. Health-check status using the /admin/ping handler
2. The admin statistics page /admin/stats.jsp (XML styled with XSL)
3. JMX MBeans

The list of applicable checks could be defined by whether it is a health check or a data gathering check – but we’d end up with a lot of overlap. Instead I’ve divided the list into the checks that can be performed remotely (without an installed agent on the server) and those that are best performed locally to the Solr server.

Remote (agent-less) checks

What should we look for over the network?

Firstly we can have a host-level check which may perform a network level ping.
Next we can check TCP connectivity to the servlet container port and then make an HTTP GET request to the Solr ‘front page’ and check for a known string (e.g. Welcome to Solr).

Now we’ve made it up to the application layer so can start to perform Solr specific checks. Items to monitor may include (delete as applicable):

1. Ping status
2. Number of docs
3. Number of queries / queries per second
4. Average response time
5. Number of updates
6. Cache hit ratios
7. Replication status
8. Synthetic queries

Agent-based checks

Installing an Opsview agent on the Solr server means we can run additional checks over NRPE (Nagios Remote Plugin Executor). This could be operating system level checks such as memory/disk utilisation or CPU load, or the following:

1. Java servlet container process is running
2. JMX checks e.g. heap memory or custom MBeans
3. File age
4. Log parsing for exceptions

For more detail on some of the non-Solr specific checks, see my previous post on monitoring Grails (though broadly applicable to any JVM application).

The Solr wiki describes how to configure JMX support: http://wiki.apache.org/solr/SolrJmx.

Opsview configuration

The rest of the article assumes that you’ve got Opsview (or the Opsview VMWare appliance) installed & have completed the Quick Start.

Solr-specific Plugin

We’ll install the plugin from https://github.com/rbramley/Opsview-solr-checks into /usr/local/nagios/libexec/

The check_solr plugin was developed using Perl, so that it could be contributed back to Opsview (and it would have used Nagios::Plugin had I known about it sooner). It requires the CPAN XML::XPath module (sudo cpan -i XML::XPath).

The plugin includes usage instructions, check_solr -h which can also be viewed in Opsview by selecting the ‘Show Plugin Help‘ link beneath the Plugin drop down (see Figure 1).
The -u option can be used to specify the URL path for multi-core set-ups.

Service check setup

Figure 1 gives an example of a service check configuration.

Figure 1 - Service check definition (showing plugin help)

Figure 2 shows the agentless service check group with plugins and their arguments.

Figure 2 - Service check group

Host configuration

Figure 3 shows a simplistic host setup with a ping check.

Figure 3 - Host configuration

Figure 4 is an extract from the Monitors tab, where we select the checks we want performed for the current host.

Figure 4 - Picking monitors for a host

Viewing output

The check results shown in Figure 5 are visible by navigating through the host group hierarchy.

Figure 5 - Host check results

If you click on the graph icon of Solr Cache Hit Ratios this will drill down onto the graph shown in Figure 6.
Clicking on the graph icon for Solr Avg Response Time – standard will take you to the graphs in Figure 7.

Figure 6 - Cache hit ratios

Figure 7 - Average request time

If you shutdown Solr, then the check results will start to turn critical and show in red as per Figure 8.

Figure 8 - Post shutdown alert

Alternatives

Of course I’m not the first person who’s wanted to monitor Solr from Opsview or a Nagios system, so there are a few plugins available – although the ones I found didn’t meet my personal needs (am happy to share my more detailed assessment notes if there is interest).

• http://code.google.com/p/nagios-plugins-shamil/ – provides ping, replication status and num docs
• http://code.google.com/p/solr-nagios-check/ – provides QPS, response time and num docs

Also, chapter 8 of the recently published Apache Solr 3 Enterprise Search Server book includes a section on Monitoring Solr Performance.

Summary

Using check_solr in conjunction with Opsview allows you to ensure that your Solr server is available and provides you with metrics that can help you tune your Solr configuration. This can be complemented with additional agent-based operating system and JMX checks to give you a full picture view.

Hopefully check_solr and the demonstrated agentless service checks will soon be incorporated into Opsview to join my check_hudson_job contribution.