Operation processes¶
Backup management¶
Backup process
If you are using the hybrid database structure (the one with MongoDB), you should stop MySQL and Mongo services on your server before proceeding to backup, otherwise you may backup inconsistent data (cross references between MySQL and MongoDB).
But if you are using the full MySQL database structure, you can proceed to a “Hot Backup” (without blocking any user access to the application). Nevertheless, backup operations should be avoided during massive treatments such as imports or exports, to prevent any potential performance problems.
Two pieces of information should be backed up:
database data: When using a MySQL server we recommend using the mysqldump tool with the –single-transaction option.
files and media data (uploaded and archived): This data can be found in the upload_dir and archive_dir (as defined in the app/config/pim_parameters.yml file). No specific backup tool is recommended for this task.
Restoration process
Here follow the recommended steps to restore a backup:
Close temporarily all user accesses to the application
Restore uploaded and archived files and media
Restore the database data
Empty the application cache with the following commands:
cd <application_root_folder> php bin/console cache:clear --env=prodReopen access to application users
Regular backup
For data security reasons, it is recommended to set a real time database replication such as a master/slave MySQL replication for example. Regarding uploaded and archived media and files, a simple but regular rsync replication can be enough.
Monitoring¶
Monitoring Akeneo PIM application’s web interface
Basic HTTP/HTTPS monitoring
The most basic way to monitor Akeneo PIM would be to check that the application responds on the HTTP port 80 (or 443 for HTTPS depending on the web server configuration), and that it actually returns a success code (200) on the homepage.
Complete functional scenario monitoring
Besides this basic monitoring, the monitoring of a more complete functional test would guarantee the interaction between the application and its database. The execution of such a test could also ensure the quality of service by measuring the response time of the different scenarios’ steps.
Recommended scenario:
Display the application login page
Login with a basic user
Display the user dashboard
Display the product grid
Display the edition page of a product
Logout
Logs monitoring
The following log levels can be found in the production logs:
WARNING
ERROR
CRITICAL
Two types of logs can be interesting to monitor Akeneo PIM:
Application logs: var/logs/prod.log
Web server logs: the Apache logs
The web server logs are defined in the ErrorLog parameter of the VirtualHost configuration. This log file will contain all the errors the application code could not handle, therefore the most critical ones.
For the errors to be displayed in the web server logs, the PHP configuration on the server should have the log_errors to On.
Monitoring the batch processes
Using the application web interface
Every import or export process generates an execution report. This report is available on import or export history pages of PIM.
Monitoring batch processes specific logs
As for the global application logs, only the WARNING, ERROR and CRITICAL levels are logged in production environment.
Every batch process execution generates a log file stored in the folder var/logs/batch/<execution_process_number>. This execution process number is the identifier of the process in the oro_batch_job_execution table.
When running such a process using the CLI (for example when using CRON jobs) the content of this log file is also displayed on the standard output. When it is run through the application web interface an additional log file is generated to keep track of this standard output: var/logs/batch_execute.log
If an error appears during the batch process execution, the exit code of this process will be different from 0.
Logs rotation¶
Only log files generated by the Akeneo PIM application itself are listed below. Log rotation management for the web and database servers are at the hosting manager’s discretion.
Log file location |
Necessary condition to the log rotation |
Requires empty log file creation after log rotation? |
Empty file in “copy-truncate” mode required? |
var/logs/prod.log |
None |
No |
No |
var/logs/batchexecution.log |
No batch currently running |
No |
No |
var/logs/batch/<id>/*.log |
Job profile execution id <id> has to be over |
No |
No |
Found a typo or a hole in the documentation and feel like contributing?
Join us on Github!