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. If you also use MongoDB, we recommend using the mongodump tool to dump a binary file with the content of the MongoDB database.
  • 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 app/console cache:clear --env=prod

  • Reopen 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: app/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 app/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: app/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?
app/logs/prod.log None No No
app/logs/batchexecution.log No batch currently running No No
app/logs/batch/<id>/*.log Job profile execution id <id> has to be over No No