In this recipe, we're going to store information in an RDBMS. The monitoring extension supports different software, such as H2, PostgreSQL, or Oracle ™.

We'll use PostgreSQL, a powerful and open source software, which, with its extension PostGIS, is the most famous open spatial database. The installation is very easy; for Linux distro, the easiest way is to use binary packages from the official repository. On Debian-like distributions, you can use the apt package manager:

$ sudo apt-get install postgresql-9.1

This way you'll have the recent release up and running in a few seconds.

For Windows, a good choice is to download the binary package by Enterprise DB:

http://www.enterprisedb.com/products-services-training/pgdownload#windows

Using an RDBMS is a robust way to persist information safely. An RDBMS is also a very flexible tool to retrieve information and elaborate it in order to prepare usage reports.

The monitoring extension configuration is based on four properties files. The one called monitor.properties holds the general settings.

The mode parameter sets how the information is collected and updated. By default, it is in the history mode, that is, information is stored after the request completion. The live mode makes GeoServer collect information in real time. In this mode, you can also use a real-time monitor from the GeoServer web interface.

The storage property controls where the monitoring information is stored. It can assume two values: memory, which is the default value, and hibernate.

We selected the hibernate mode, and hence GeoServer will search for a database acting as a repository. To connect to the database, more parameters are required. They are contained in the hibernate.properties and db.properties files. GeoServer reads them and uses the contained information to connect to the RDBMS and store information inside it.

In the first file, we instruct hibernate on what kind of database we're using, shown as follows:

# hibernate dialect
databasePlatform=org.hibernate.dialect.PostgreSQLDialect
database=POSTGRESQL

In the latter, we insert the connection parameters as follows:

# sample configuration for postgres
driver=org.postgresql.Driver
url=jdbc:postgresql://localhost:5432/gisdata
username=gisuser
password=gisuser
defaultAutoCommit=false

We changed the default H2 database to PostgreSQL; you're already using it as a spatial repository for your data and it is a very powerful piece of software. It is also very interoperable with many reporting tools.

If your organization uses Oracle, you may as well be use it to monitor information storage. In hibernate.properties, insert the following code snippet:

# hibernate dialect
databasePlatform=org.hibernate.dialect.OracleDialect
database=ORACLE

Then, insert the following code snippet in the db.properties file:

driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@localhost:1521:ORCL
username=gisuser
password=gisuser

Obviously, whatever RDBMS flavor you're using, the information stored is the same. You probably noted the crs field in the request table. Along with the minx, miny, maxx, and maxy fields, it records the envelope for each request:

gisdata=> select crs, round(minx::numeric,2) as minx, round(miny::numeric,2) as miny, round(maxx::numeric,2) as maxx, round(maxy::numeric,2) as maxy from request where crs is not null;
    crs    |     minx    |    miny    |    maxx    |     maxy   
-----------+-------------+------------+------------+------------
 EPSG:4326 |     -180.00 |     -90.00 |     180.00 |       90.00
 EPSG:4326 |      -17.84 |      28.48 |      40.17 |       57.48
 EPSG:4326 |       -4.09 |      36.12 |      24.92 |       50.63
 EPSG:4326 |        2.79 |      39.95 |      17.29 |       47.20

In the monitor.properties file, you can set the CRS used to log the envelopes, by default, WGS84 Lat Long, which is EPSG:4326. You may change it to another one, of course, being careful to select one that makes sense to all your data extent.

This is the output of requests to the NaturalEarth:blueMarble layer after changing the setting to EPSG:3857 in the monitor.properties file:

gisdata=> select crs, round(minx::numeric,2) as minx, round(miny::numeric,2) as miny, round(maxx::numeric,2) as maxx, round(maxy::numeric,2) as maxy from request where crs is not null;
    crs    |     minx    |    miny    |    maxx    |     maxy   
-----------+-------------+------------+------------+-------------
 EPSG:3857 | -5126784.36 | 1967710.95 | 7788015.94 | 13111054.46
 EPSG:3857 | -1966571.86 | 3704742.20 | 4490828.29 |  8524724.33
 EPSG:3857 |  -381573.65 | 4668514.96 | 2847126.43 |  7007058.96
 EPSG:3857 |  -381573.65 | 4668514.96 | 2847126.43 |  7007058.96

The last configuration file, filter.properties, controls what requests are monitored. By default, it contains some filters to avoid monitoring some requests:

/rest/monitor/**
/web
/web/**

All requests forwarded to the GeoServer web interface and the Monitor REST API are not collected. According to your needs, you can add more filters.

The syntax is quite simple to manage; you have to specify the complete URL after /geoserver and before the key pair values.

For instance, if you want to filter out all requests to a namespace, you can use a filter such as the following one:

NaturalEarth/ows

Now, WMS, WCS, and WFS requests such as the following will be ignored by the monitoring module, but obviously they will be processed by GeoServer:

http://localhost/geoserver/NaturalEarth/ows?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=NaturalEarth:dem
http://localhost/geoserver/NaturalEarth/ows?service=WCS&version=1.0.0&request=GetCoverage&coverage=NaturalEarth:dem&crs= EPSG:4326&bbox=12.06,42.03,12.88,42.50&bands=1
http://localhost/geoserver/NaturalEarth/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=NaturalEarth:populatedplaces&bbox=-157.1484375,13.88671875,-41.1328125,71.89453125