We use OJS 184.108.40.206
among the issues published there’s ONLY ONE that does not produce reports, for several months, ie both COUNTER and report generator give zero visits / pdf downloads: this is impossible…
I haven’t heard of something like a single issue failing to record statistics before, but I would start with looking at the scheduled task logs for the Usage Statistics Loader.
Perhaps there is something unique about the articles in this issue? For example, there was a known issue with custom article identifiers which were strictly numeric (and thus conflicting with OJS’ internal identifiers).
Some more information would probably be helpful.
Also, there have a been a large number bugfixes in recent releases related to the new statistics framework. You might consider cloning a development site under the latest 2.4.8 release and re-ingesting the access logs to see if they process successfully with the latest fixes.
In 2.4.5 these logs were emailed to the site administrator, probably under the subject “Usage statistics file loader task”. In more recent releases (as of 2.4.6), these logs are saved under the files_dir's scheduledTaskLogs folder, and just a notice is emailed to the administrator.
Certainly I have some wrong configuration because i don’t receive e-mail notifications despite I’ve set a correct email address as main contact in ojs Administration settings
what is the correct setting? thanks
I guess I found the reason of my problems!.. I’ve changed the name of the e-journal and, after this, counter doesn’t count views and downloads.
I’ve also noticed that the file in usageStats/processing is usage_events_20160601.log and in usageStats/stage there are a lot of log of june and july.
I don’t use cron but I’ve activate it
It is possible that your log processing was aborted and this is preventing the processing of new logs. I would expect you would be getting a regular error message via email from acron under the title “Usage Statistics Loader” or similar. Try moving the June 1 log form “processing” back to “stage”.
Thank ypu very much.
we hope we do not lose statistics data…
before to try the command line i need some informations.
actually the stage folder is empty and it seems the process is regular by some days, but surely not for augist 1st, indeed the file (usage_events_20160801.log) is always in the processing folder and it is not in archive… it is similar to the topic of the june 1st file (usage_events_20160601.log, see my last replays): this information can help?
-it may be that some log files that now belong in the archive have not been correctly processed, so if I want process them i think I first must put their in stage folder, correct?
but, important, if one of these files has already been processed previously, its data will be duplicated in report generator output files (ie counter)?
The metrics table in the database is keyed on the load_id which is the filename which was loaded.
Here is a general description of the expected process:
Moving files from the “archive” folder back to the “stage” folder will reprocess the files, and will not duplicate counts, so long and the filenames remain unchanged. (A long and the “load_id” matches in the metrics table, the existing data will be overwritten by the new data.)
You should not expect files to stay in the processing folder. This would probably indicate an error or timeout which prevents that file from completing processing and may prevent future processing. Details of an error such as this should be available in your webserver error log, or in the scheduledTaskLogs.
We continue to have the same problems: some days the usage_events _ **. Log file is not processed and it remains in stage folder.
We suspect that there are problems in those files. Perhaps they may contain spam-like requests? how can we discover this?
I can also send to you one of these logs as attached files (formatted with CRs)? how?
In 2.4.5, your Site’s Principal Contact should receive an email describing any errors encountered in the processing of the log files. You should also potentially have error messages in your cron log or in your apache log (in the case of acron runs). It is these error messages which would be most helpful.
This error reporting was changed in recent releases to record the log output to files in files_dir/scheduledTaskLog/ instead of emailing directly. Recent releases of OJS also addressed some oddities/bugs in usage statistics processing, and an upgrade to 2.4.8-1 would be recommended, if possible.