Logs Overview

Customer Managed Applies to customer-managed instances of Alation

There are many processes running in the Alation application. Each of the processes writes the details of its operations into a dedicated log file. Log files include details about warnings and errors.

If users experience an issue with Alation, logs will have information about it.

For on-premises instances of Alation, each log file is marked with a date at the end of the day, and a new file is created for the next day’s logs. To optimize disk space, Alation stores a specific number of logs of each type and deletes older logs. You can access most logs from inside the Alation chroot at /opt/alation/site/logs. See below for details about the purpose and location of each specific log file.

For Alation Cloud Service instances of Alation, we store logs for one year. Contact your account manager if you have questions about logs.


Alation provides functionality to bundle and encrypt logs in the Admin Settings. See Sending Encrypted Logs to Alation.

See below for information about logs of Alation components.

Backup V2

Log files:

  • alation_backup.log

Location of logs:

  • From version 2021.3: /opt/alation/site/logs

  • Before 2021.3: /var/log/

This log documents the backup process. It will contain details about errors during the Backup V2 process.


Log files:

  • celery-alationanalytics_error.log

  • celery-alationanalytics.log

  • celery-beat_error.log

  • celery-beat.log

  • celery-cognates_error.log

  • celery-cognates.log

  • celery-default_error.log

  • celery-default.log

  • celery-fastqueue_error.log

  • celery-fastqueue.log

  • celery-ingestion_error.log

  • celery_ingestion.log

  • celery-metrics.log

  • celery-parsing_error.log

  • celery-parsing.log

  • celery-scheduling_error.log

  • celery-scheduling.log

  • celery-search_error.log

  • celery-search.log

  • celery-stewardship_error.log

  • celery-stewardship.log

  • celery-thinqueue_error.log

  • celery-thinqueue.log

Location of logs:

  • /opt/alation/site/logs

Celery is a process pool that has several different queues. Different types of background tasks run in each queue. Each queue has its own log file, and the name of the queue appears at the end of the file name. For example, celery-cognates.log and celery-cognates_error.log are the log files for the Cognates queue. As another example, celery-beat.log is the log file for the celery-beat process. celery-beat schedules Celery tasks and kicks off repeating tasks.

If your Alation software is having trouble related to data jobs or background tasks, please send all Celery logs to Alation support. Don’t try to pick and choose which Celery logs to send.

The celery-default_error.log file has information about most jobs. It’s a good place to look for information on server failures.

The celery-alationanalytics.log and celery-alationanalytics_error.log logs have information about Alation Analytics tasks. Look at these log files if there are errors in Alation Analytics processes, including ETL or metadata extraction.

If a background task fails that’s related to Compose, look at Connector logs instead of Celery logs.


Log files:

  • connector.log

  • connector_err.log

  • connector_out.log

  • connector_check.log

  • connector_check_error.log

Location of logs:

  • /opt/alation/site/logs

Connector runs Compose queries. The Connector logs will have information related to Compose, especially query execution errors.

Compose problems can also happen in the main web application (Django). Django logs can also be helpful in identifying issues with Compose.


Log files:

  • alation-debug.log

  • alation-error.log

  • alation-events.log

  • alation-info.log

Location of logs:

  • /opt/alation/site/logs

The alation-debug.log, alation-error.log, and alation-info.log files contain error messages from the main Alation web application. If you see a 500 error or a pop up informing that something is wrong, there should be a corresponding error record in these files. These logs can also be helpful in identifying issues with Compose.

The alation-error.log file has the most basic information. The alation-info.log file has a medium amount of information. The alation-debug.log file has the most detailed information. Time stamps are in Universal Common Time (UTC).

The alation-events.log file contains a record of permission changes that have occurred on table and data source objects. Any confidential data contained in the log will be masked with an asterisk. The following events will be logged:

  • Making a data source public or private

  • Granting, changing, or revoking a user’s or group’s access to a data source

  • Making a table public or private

  • Granting, changing, or revoking a user’s or group’s access to a table


Log files:

  • elasticsearch_index_indexing_slowlog.log

  • elasticsearch_index_search_slowlog.log

  • elasticsearch.log

  • elasticsearch_sh.log

Location of logs:

  • /opt/alation/site/logs

Elasticsearch powers the search functionality of Alation. You can use these logs to catch queries and indexing requests that take longer than a given amount of time. This is useful for discovering user-generated search queries that are unacceptably slow.

Alation uses a script to start Elasticsearch with certain flags. If there is an error in that startup script, the error message will be in elasticsearch_sh.log. If Elasticsearch won’t start at all, the errors will be in elasticsearch.log and supervisord.log.

Installer and Updater

Log files:

  • installer.log

Location of logs:

  • /opt/alation/site/logs

Any errors during installation or updates to Alation will appear in this log file.


Log files:

  • kvstore.log

Location of logs:

  • /opt/alation/site/logs

KVStore stores the text of ingested queries. Logs related to KVStore will be in kvstore.log.


Log file:

  • access.log

  • error.log

Location of logs:

  • /opt/alation/site/logs

Nginx routes incoming requests to uWSGI or to static files. The access.log file has an entry for every HTTP request. The error.log file has an entry for every failed HTTP request. Time stamps are in Eastern Standard Time (EST) time zone.

Both the logs are a good place to look for UI issues. A high number of HTTP/5xx status codes implies server or application instability.

You may want to check Nginx logs if you suspect that the request is somehow not getting to the web application itself. Another reason to check Nginx logs is if you’ve recently changed your Nginx configuration.


Log files:

  • pgstartup.log

  • postgresql-[DayOfWeek].log

There’s one postgresql log file for each day of the week. The file name uses the first three letters of the day of the week. For example, postgresql-Fri.log is the log for Friday.

Location of logs:

You must be the root user to access Postgres logs.


Postgres log files are located on the Postgres data disk. You can access the Postgres disk from the Alation chroot and the host system. (See Alation Architecture for more information.)

The location of pgstartup.log is:

  • On host system: /data/pgsql/[PostgresVersion]/

  • In Alation chroot: /var/lib/pgsql/[PostgresVersion]/

The postgresql-[DayOfWeek].log files are located in the pg_log subfolder:

  • On host system: /data/pgsql/[PostgresVersion]/pg_log/

  • In Alation chroot: /var/lib/pgsql/[PostgresVersion]/pg_log/

Your Postgres version depends on what version of Alation you have:

  • Alation before V R6 release: 9.3

  • Alation from V R6 to 2021.2.X: 9.6

  • Alation from 2021.3.X and newer: 13


Log File

Alation Version


Alation chroot


Before V R6


V R6 to 2021.2.X


2021.3.X and later



Before V R6


V R6 to 2021.2.X


2021.3.X and later


Host system


Before V R6


V R6 to 2021.2.X


2021.3.X and later



Before V R6


V R6 to 2021.2.X


2021.3.X and later


The log file pgstartup.log includes errors during Postgres start. postgresql-*.log has information on operational errors. You may want to look here if you see errors that mention Postgres in the Django or Celery logs.

Public API

Log files:

  • public_api.log

Location of logs:

  • /opt/alation/site/logs

From version 2020.3, Alation logs errors during the use of Alation’s public API in this file.


Log files:

  • redis.log

Location of logs:

  • /opt/alation/site/logs

If Redis fails to start or crashes, the information will be in this log.


Log files:

  • supervisord.log

Location of logs:

  • /opt/alation/site/logs

Supervisor manages starting and stopping many of the other components of Alation. This log has errors that occur while starting or stopping those processes. For example, if a component won’t start after using alation_supervisor start [component], you can look in this log for details. The Supervisor logs are also a great place to look for information about why a process crashed.

See Supervisor for details on which components Supervisor controls.


Log files:

  • taskserver_check_error.log

  • taskserver_check.log

  • taskserver_err.log

  • taskserver.log

  • taskserver_out.log

Location of logs:

  • /opt/alation/site/logs

Taskserver handles the extraction of metadata from external systems. This log will be useful if metadata extraction, profiling, or query log ingestion fail or have errors.


Log files:

  • uwsgi.log

Location of logs:

  • /opt/alation/site/logs

uWSGI is the core of front end processing. These log files are a great place to look for any UI issues caused by the Alation server. Each request from a user’s browser will get logged here. Specific details of what actually happened in a request will be in the Django logs. Time stamps are in Universal Common Time (UTC).