-
Notifications
You must be signed in to change notification settings - Fork 96
Proposal #3: adding auditing capabilities
The goal of this proposal is to add auditing capabilities to GeoStore. The terms auditing, monitoring and logging are often used interchangeably but they have different goals:
- auditing: allow us to understand how the external world interact with our application;
- monitoring: give us information related to the internal execution of our application;
- logging: produces very widespread information that can be very detailed about the whole execution;
That say, if we want to know which is the user that spends more time on a certain map, we will look a the auditing information. If we want to track some performance issue, we will look at the monitoring information. If I want to understand a crash or an unexpected behavior, we will look at the logging information.
In a typical system, auditing information is produced intercepting externals requests to the system. The auditing information is composed of the information contained in the request itself and the information produced during is execution, for example the result code for an HTTP request is only available after the request execution.
Auditing information is typically consumed by third-party applications that will produces reports or provide a user friendly visualization of the data. Keeping this in mind it can be useful to have a customizable output format.
It is crucial that the auditing capabilities should not have an impact on the application performance. Furthermore, it should be possible to enable or disable the auditing capabilities during runtime.
We propose to implement an auditing module for GeoStore that will be tied to the REST end points. The work to be done can be divided in five major tasks:
- intercepting the HTTP requests and extract the needed auditing information from them
- implementing a non blocking output file strategy with support for automatic rollings
- allow the customization of the output format using some kind of templating
- allow fine grained control over which REST end points should produce auditing information
- update GeoStore documentation about how to configure the auditing module and customize the output
Since GeoStore REST support is build on top of Apache CFX the existing interceptors mechanism will be used to intercept and extract the auditing information from the HTTP requests.
The non blocking file output strategy will be implemented as a simple producer\consumer architecture. The producers will be the interceptors and the consumers will be responsible to write the auditing information to the output files. The buffer between them will be implemented using a Java ConcurrentLinkedQueue.
The customization of the output format will be implemented using the Apache FreeMarker template engine.
The fine grained control over which REST end points should produce auditing information will be implemented as simple configuration properties.
No alterations will be made to the current source code.
The auditing module of GeoServer can be viewed as an example.
Implement the interceptor mechanism and the non blocking output file strategy. Write documentation about how to configure the auditing module.
Estimation 1 day.
Output customization and fine grained control over which REST end points should produce auditing information. Complete the documentation.
Estimation 1 day.
https://github.com/geosolutions-it/geostore/issues/128