Service Logs
This page briefly explains the different log files that will be available on the Conductor Manager host.
REST
The REST service runs using the Flask web framework on top of the Gunicorn HTTP server. Each of these layers has its own logs.
Flask Log
The Flask logger is used by the REST service to write custom logs. The information about exceptions raised by the REST service is stored in this log. Additionally, when the logging level is set to DEBUG, it records each request-response pair with their relevant parameters and information.
This log file is located at /var/log/cloudify/rest/cloudify-rest-service.log.
The logging level can be set to debug by running cfy config update rest_service_log_level=DEBUG if more information about requests and responses is required. It can then be set back to the recommended level of info by running cfy config update rest_service_log_level=INFO.
Gunicorn Logs
There are two log files Gunicorn writes to: an access log and a general log.
The access log simply logs a concise entry for each request made to the web server.
This log file is located at /var/log/cloudify/rest/gunicorn-access.log.
The general log mostly has information on Gunicorn workers. It is usually only interesting when there was a problem in starting up the REST service and Flask.
This log file is located at /var/log/cloudify/rest/gunicorn.log.
Management Worker
Starting with Studio Conductor 3.4, the management worker is responsible for all central deployment operations of all deployments.
Worker Logs
The management worker log contains top level details regarding the tasks it handles, such as task accepted, task succeeded, task failed (with a generic traceback that will always look the same), etc…
The management worker handles all of the workflow tasks, and some operation
tasks that use the central_deployment_agent as their executor. The
workflow/operation execution is done in its own subprocess.
This log file is located at /var/log/cloudify/mgmtworker/mgmtworker.log.
Deployment Logs
In the aformentioned subprocess, which is where the operation/workflow actually runs, the root logger handler is configured to send all logging of all loggers in this subprocess to a deployment specific log file. This is where the “interesting” stuff appears. Specifically, if you are looking for a traceback, this is where you should be looking.
These logs files are located at /var/log/cloudify/mgmtworker/logs/<deployment_id>.log.
System Logs
In addition, the mgmtworker/logs dir will contain an additional log file, that will include all logging from operations/workflows that are
“system wide” (e.g. snapshot, install plugin on REST upload, etc…)
This log file is located at /var/log/cloudify/mgmtworker/logs/__system__.log.
Remote hosts that have a Studio Conductor Agent running on them will have their log files located at $HOME/<compute_instance_id>/work on the remote host.
Other Components
You can find all log files for Studio Conductor related services located at /var/log/cloudify.
Log Rotation
All Studio Conductor related log files on the manager host are managed by logrotate. Log files are configured to rotate when they reach the size of 100MB.
At most, 7 rotated files are kept for each rotated log file.
Log Cleanup
You can remove Studio Conductor logs and events from the database with the delete_logs_and_events_from_db.py that is located on the Conductor Manager under /etc/cloudify. When you run the script, the logs and events that exist from after the save period configured in the script are removed.
You can change the DEFAULT_SAVE_PERIOD parameter in the script to set the number of days that are kept in the database (Default: 5). For example, if the DEFAULT_SAVE_PERIOD is 7, logs and events that are older than 7 days are deleted.