Many aspects of the monitor extension are configurable. All configuration files
are stored in the data directory under the
<data_directory> monitoring/ filter.properties monitor.properties
monitor.properties file is the main configuration file whose contents are
described in the following sections. The
allows for filtering out those requests from being monitored.
Database persistence with hibernate is described in more detail in the Database Persistence section.
How request data is persisted is configurable via the
storage property defined in the
monitor.properties file. The following values are supported for the
memory - Request data is to be persisted in memory alone.
The default value is
The “monitor hibernate” community module allows to also store the requests in a relational database.
With memory storage only the most recent 100 requests are stored. And by definition this storage is volatile in that if the GeoServer instance is restarted, shutdown, or crashes this data is lost.
The monitor extension supports different “monitoring modes” that control how request data is captured. Currently two modes are supported:
history (Default) - Request information updated post request only. No live information made available.
live - Information about a request is captured and updated in real time.
The monitor mode is set with the
mode property in the
The default value is
History mode persists information (sending it to storage) about a request after a request has completed. This mode is appropriate in cases where a user is most interested in analyzing request data after the fact and doesn’t require real time updates.
Live mode updates request data (sending it to storage) in real time as it changes. This mode is suitable for users who care about what a service is doing now.
When applicable one of the attributes the monitor extension can capture is the request bounding box. In some cases, such as WMS and WCS requests, capturing the bounding box is easy. However in other cases such as WFS it is not always possible to 100% reliably capture the bounding box. An example being a WFS request with a complex filter element.
How the bounding box is captured is controlled by the
bboxMode property in the
monitor.properties file. It can have one of the following values.
none - No bounding box information is captured.
full - Bounding box information is captured and heuristics are applied for WFS requests.
no_wfs - Bounding box information is captured except for WFS requests.
Part of a bounding box is a coordinate reference system (crs).Similar to the WFS case it
is not always straight forward to determine what the crs is. For this reason the
property is used to configure a default crs to be used. The default value for the property is
“EPSG:4326” and will be used in cases where all lookup heuristics fail to determine a crs for
the bounding box.
Request Body Size¶
The monitor extension will capture the contents of the request body when a body is specified as is common with a PUT or POST request. However since a request body can be large the extension limits the amount captured to the first 1024 bytes by default.
A value of
0 indicates that no data from the request body should be captured. A
-1 indicates that no limit should be placed on the capture and the entire
body content should be stored.
This limit is configurable with the
maxBodySize property of the
When using database persistence it is important to ensure that the size of the body
field in the database can accommodate the
Ignore Post Processors¶
The monitor passes request information through post processors which enrich the request
information with DNS lookup, Location using IP database etc. It is possible to disable
these post processors if some enrichments are not required with
property of the
This parameter takes comma separated names of known post processors.
The valid values are
By default not all requests are monitored. Those requests excluded include any web admin requests or any Monitor Query API requests. These exclusions are configured in the
These default filters can be changed or extended to filter more types of requests. For example to filter out all WFS requests the following entry is added:
How to determine the filter path¶
The contents of
filter.properties are a series of ant-style patterns that
are applied to the path of the request. Consider the following request:
The path of the above request is
/wms. In the following request:
The path is
In general, the path used in filters is comprised of the portion of the URL
/geoserver (including the preceding
/) and before the query string
For more information about ant-style pattern matching, see the Apache Ant manual.
# storage and mode storage=memory mode=history # request body capture maxBodySize=1024 # bounding box capture bboxMode=no_wfs bboxCrs=EPSG:4326
# filter out monitor query api requests /rest/monitor/** # filter out all web requests /web /web/** # filter out requests for WCS service /wcs