All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
Page History
...
The Log Converter program converts log files from dspace.log into an intermediate format that can be inserted into Solr.
Command used: |
|
Java class: | org.dspace.statistics.util.ClassicDSpaceLogConverter |
Arguments short and long forms): | Description |
| Input file |
| Output file |
| Adds a wildcard at the end of input and output, so it would mean if |
| If the log files have been created with DSpace 1.6 or newer |
| Display verbose output (helpful for debugging) |
| Help |
The command loads the intermediate log files that have been created by the aforementioned script into Solr.
Command used: |
|
Java class: | org.dspace.statistics.util.StatisticsImporter |
Arguments (short and long forms): | Description |
| input file |
| Adds a wildcard at the end of the input, so it would mean dspace.log* would be imported |
| To skip the reverse DNS lookups that work out where a user is from. (The DNS lookup finds the information about the host from its IP address, such as geographical location, etc. This can be slow, and wouldn't work on a server not connected to the internet.) |
| Display verbose ouput (helpful for debugging) |
| For developers: allows you to import a log file from another system, so because the handles won't exist, it looks up random items in your local system to add hits to instead. |
| Help |
Although the DSpace Log Convertor applies basic spider filtering (googlebot, yahoo slurp, msnbot), it is far from complete. Please refer to Filtering and Pruning Spiders for spider removal operations, after converting your old logs.
Filtering and Pruning Spiders
Command used: |
|
Java class: | org.dspace.statistics.util.StatisticsClient |
Arguments (short and long forms): | Description |
| Reindex the bitstreams to ensure we have the bundle name |
-r or --remove-deleted-bitstreams | While indexing the bundle names remove the statistics about deleted bitstreams |
| Update Spider IP Files from internet into |
| Delete Spiders in Solr By isBot Flag. Will prune out all records that have |
| Delete Spiders in Solr By IP Address, DNS name, or Agent name. Will prune out all records that match spider identification patterns. |
| Update isBot Flag in Solr. Marks any records currently stored in statistics that have IP addresses matched in spiders files |
| Calls up this brief help table at command line. |
Notes:
The usage of these options is open for the user to choose. If you want to keep spider entries in your repository, you can just mark them using "-m" and they will be excluded from statistics queries when "solr.statistics.query.filter.isBot = true" in the dspace.cfg. If you want to keep the spiders out of the solr repository, just use the "-i" option and they will be removed immediately.
...
Export SOLR records to intermediate format for import into Elasticsearch
Command used: |
|
Java class: | org.dspace.statistics.util.StatisticsClient |
Arguments (short and long forms): | Description |
| Export SOLR view statistics data to usage statistics intermediate format |
This exports the records to [dspace]/temp/usagestats_0.csv. This will chunk the files at 10,000 records to new files. This can be imported with stats-log-importer to SOLR Statistics or stats-log-importer-elasticsearch to Elasticsearch Usage Statistics (deprecated).
Export SOLR statistics, for backup and moving to another server
Command used: |
|
Java class: | org.dspace.util.SolrImportExport |
Arguments (short and long forms): | Description |
| optionally export only integer many days worth of statistics |
-d or --directory | optional, directory to use for storing the exported files. By default, [dspace]/solr-export is used. If that is not appropriate (due to storage concerns), we recommend you use this option to specify a more appropriate location. |
Import SOLR statistics, for restoring lost data or moving to another server
Command used: |
|
Java class: | org.dspace.util.SolrImportExport |
Arguments (short and long forms): | Description |
| optional, clears the contents of the existing stats core before importing |
-d or --directory | optional, directory which contains the files for importing. By default, [dspace]/solr-export is used. If that is not appropriate (due to storage concerns), we recommend you use this option to specify a more appropriate location. |
Reindex SOLR statistics, for upgrades or whenever the Solr schema for statistics is changed
Command used: |
|
Java class: | org.dspace.util.SolrImportExport |
Arguments (short and long forms): | Description |
| optional, tells the script to keep the intermediate export files for possible later use (by default all exported files are removed at the end of the reindex process). |
-d or --directory | optional, directory to use for storing the exported files (temporarily, unless you also specify --keep, see above). By default, [dspace]/solr-export is used. If that is not appropriate (due to storage concerns), we recommend you use this option to specify a more appropriate location. Not sure about your space requirements? You can estimate the space required by looking at the current size of [dspace]/solr/statistics |
NOTE: solr-reindex-statistics is safe to run on a live site. The script stores incoming usage data in a temporary SOLR core, and then merges that new data into the reindexed data when the reindex process completes.
Routine Solr Index Maintenance
Command used: |
|
Java class: | org.dspace.statistics.util.StatisticsClient |
Arguments (short and long forms): | Description |
| Run maintenance on the SOLR index. Recommended to run daily, to prevent your servlet container from running out of memory |
Notes:
The usage of this this option is strongly recommended, you should run this script daily (from crontab or your system's scheduler), to prevent your servlet container from running out of memory.
Solr Sharding By Year
Command used: |
|
Java class: | org.dspace.statistics.util.StatisticsClient |
Arguments (short and long forms): | Description |
| Splits the data in the main core up into a separate solr core for each year, this will upgrade the performance of the solr. |
Notes:
Yearly Solr sharding is a routine that can drastically improve the performance of your DSpace SOLR statistics. It was introduced in DSpace 3.0 and is not backwards compatible. The routine decreases the load created by the logging of new usage events by reducing the size of the SOLR Core in which new usage data are being logged. By running the script, you effectively split your current SOLR core, containing all of your usage events, into different SOLR cores that each contain the data for one year. In case your DSpace has been logging usage events for less than one year, you will see no notable performance improvements until you run the script after the start of a new year. Both writing new usage events as well as read operations should be more performant over several smaller SOLR Shards instead of one monolithic one.
...
Technical implementation details
After sharding, the SOLR data cores are located in the [dspace.dir]/solr directory. There is no need to define the location of each individual core in solr.xml because they are automatically retrieved at runtime. This retrieval happens in the static method located in theorg.dspace.statistics.SolrLogger class. These cores are stored in the statisticYearCores list each time a query is made to the solr these cores are added as shards by the addAdditionalSolrYearCores method. The cores share a common configuration copied from your original statistics core. Therefore, no issues should be resulting from subsequent ant updates.
The actual sharding of the of the original solr core into individual cores by year is done in the shardSolrIndex method in the org.dspace.statistics.SolrLogger class. The sharding is done by first running a facet on the time to get the facets split by year. Once we have our years from our logs we query the main solr data server for all information on each year & download these as csv's. When we have all data for one year we upload it to the newly created core of that year by using the update csvhandler. One all data of one year has been uploaded that data is removed from the main solr (by doing it this way if our solr crashes we do not need to start from scratch).
Overview
Content Tools