Redash на сервере: частые ошибки и решения

MAATRIX

Redash разворачивают за пятнадцать минут по официальному docker-compose.yml, и первые полчаса всё выглядит отлично — до того момента, когда запрос к базе «крутится» вечно, дашборд не открывается у коллеги по ссылке или воркер молча перестаёт выполнять запланированные обновления. Проблема в том, что Redash — это не одно приложение, а связка из пяти контейнеров, и диагностировать нужно не «Redash», а конкретное звено цепочки. Ниже — набор ошибок, с которыми реально сталкиваешься на боевом сервере, и рабочие решения без лишней воды.

Архитектура Redash и как найти сломанное звено

Прежде чем чинить, полезно держать в голове, из чего состоит установка:

• server — веб-приложение (Flask + Gunicorn), отдаёт UI и API;
• scheduler — Celery beat, раз в минуту решает, какие запросы пора обновить;
• worker (может быть несколько, с разными очередями) — Celery worker, реально выполняет запросы к источникам данных;
• redis — брокер задач для Celery и кэш;
• postgres — хранилище метаданных: пользователи, дашборды, сами тексты запросов, результаты.

Важный нюанс: PostgreSQL здесь используется как внутренняя база самого Redash, а не обязательно как источник данных, который вы визуализируете. Источники данных (data sources) — это отдельная сущность, их может быть сколько угодно: ClickHouse, MySQL, MongoDB, тот же PostgreSQL и так далее.

Быстрая диагностика всегда начинается с логов конкретного контейнера:

docker compose ps
docker compose logs --tail=100 server
docker compose logs --tail=100 worker
docker compose logs --tail=100 scheduler

Если server в статусе Restarting — проблема на старте (обычно переменные окружения или подключение к Postgres/Redis). Если сервер поднялся, а запросы висят в статусе «Query in progress» бесконечно — смотрите worker и redis.

Docker Compose: сервер не стартует

Самая частая причина падения на старте — не выполненная миграция базы данных при первом развёртывании. Официальный docker-compose.yml не создаёт схему автоматически, это нужно сделать руками один раз:

docker compose run --rm server create_db
docker compose up -d

Если пропустить этот шаг, в логах server будет что-то в духе relation "users" does not exist или ошибка при первом обращении к API.

Вторая типичная ошибка — не заданы или сгенерированы заново REDASH_COOKIE_SECRET и REDASH_SECRET_KEY в .env. Без них сессии не сохраняются, пользователей постоянно выкидывает из аккаунта, а в некоторых версиях сервер вовсе не стартует. Значения должны быть стабильными и не меняться между перезапусками:

# .env
REDASH_COOKIE_SECRET=$(openssl rand -hex 32)
REDASH_SECRET_KEY=$(openssl rand -hex 32)
REDASH_DATABASE_URL=postgresql://redash:пароль@postgres/redash
REDASH_REDIS_URL=redis://redis:6379/0

Сгенерируйте их один раз и зафиксируйте в файле — не через $(...) при каждом запуске, иначе при пересоздании контейнеров ключи будут разными и старые сессии/шаринг-ссылки на дашборды перестанут работать.

Третья грабля — недостаточно памяти. Redash плюс Postgres плюс Redis плюс минимум два воркера комфортно чувствуют себя от 4 ГБ RAM, но на 2 ГБ Gunicorn-воркеры регулярно убиваются OOM killer’ом прямо во время рендера тяжёлого дашборда. Проверить:

dmesg -T | grep -i "out of memory"
free -h

Если видите OOM-события — либо добавляйте память на сервере, либо уменьшайте число Gunicorn-воркеров через WEB_WORKERS=2 в .env.

Redis и Celery: запросы не выполняются

Это самая частая жалоба: запрос отправлен, статус «в процессе», и так навсегда. В 90% случаев дело в очередях Celery.

Redash использует несколько именованных очередей (queries, scheduled_queries, celery, а для тяжёлых источников можно завести отдельные), и воркер обязан явно их слушать. Если в docker-compose.yml у сервиса worker не указана нужная очередь через QUEUES, задачи из неё просто копятся в Redis и никогда не выполняются:

worker:
  environment:
    QUEUES: "queries,scheduled_queries,celery"
    WORKERS_COUNT: 2

Проверить, что реально копится в очереди, можно напрямую в Redis:

docker compose exec redis redis-cli
> LLEN queries
> LLEN scheduled_queries

Если числа растут и не уменьшаются — воркер либо не слушает эту очередь, либо упал. Второй вариант диагностируется просто:

docker compose logs worker | grep -i error
docker compose restart worker

Ещё одна частая причина зависших запросов — не запущен или упал scheduler (Celery beat). Он отвечает за периодическое обновление запросов по расписанию — если контейнер scheduler не поднят вторым процессом, ручные запуски запросов будут работать, а автообновление дашбордов — нет. Проверьте отдельно:

docker compose ps scheduler

Полезно почитать про настройку Redis на сервере отдельно — многие проблемы с зависшими очередями на деле оказываются проблемами самого Redis: неверный maxmemory-policy, обрыв соединения по таймауту или нехватка памяти под очередь.

PostgreSQL как метабаза Redash

Здесь легко перепутать роли: PostgreSQL внутри docker-compose.yml хранит не ваши данные для аналитики, а сами сущности Redash — пользователей, тексты запросов, кэш результатов, настройки дашбордов. Если эта база станет недоступна, упадёт весь Redash целиком, а не только один источник данных.

Типичная ошибка после миграции сервера или смены пароля — server не может подключиться к Postgres, в логах psycopg2.OperationalError: could not connect to server. Проверяется банально:

docker compose exec postgres pg_isready
docker compose exec server env | grep REDASH_DATABASE_URL

Убедитесь, что REDASH_DATABASE_URL совпадает с реальными учётными данными контейнера postgres, и что имя хоста в строке подключения — это имя сервиса в Docker-сети (postgres), а не localhost.

Со временем таблица результатов запросов (query_results) разрастается — Redash по умолчанию не чистит старые результаты автоматически. На дашборде с сотнями запросов, обновляющихся раз в 5 минут, база метаданных может вырасти до неожиданных размеров за пару месяцев. Разумная практика — периодически чистить устаревшие результаты через встроенную management-команду и следить за диском:

docker compose run --rm server manage query_results
df -h

Если у вас уже есть отдельный PostgreSQL-сервер (не в Docker) под другие нужды, общие подходы к диагностике подключения и производительности разобраны в статье про PostgreSQL на сервере — большая часть тех же приёмов актуальна и для метабазы Redash.

Nginx перед Redash: reverse proxy и вебсокеты

Redash в проде почти всегда прячут за Nginx с SSL — просто открывать наружу порт 5000 не стоит. Тут есть свои грабли.

Базовый рабочий конфиг:

server {
    listen 443 ssl;
    server_name redash.example.com;

    ssl_certificate     /etc/letsencrypt/live/redash.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/redash.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 300s;
        proxy_connect_timeout 300s;
    }
}

Два момента, которые ломают статус выполнения запросов именно через прокси:

1. Таймаут по умолчанию у Nginx — 60 секунд. Тяжёлый аналитический запрос к ClickHouse или большой join в PostgreSQL легко выполняется дольше, и прокси обрывает соединение раньше, чем Redash успевает отдать результат. Отсюда 502 Bad Gateway при длинных запросах — увеличивайте proxy_read_timeout под свои задачи.
2. Заголовок X-Forwarded-Proto обязателен, если Redash работает по HTTPS через прокси, а сам слушает по HTTP внутри контейнера — без него генерируются ссылки на дашборды с http:// вместо https://, и шаринг-ссылки с публичным доступом начинают вести на смешанный контент.

Если сертификаты выпускаете через certbot, общие проблемы с автопродлением и валидацией разобраны в статье про Let's Encrypt SSL на сервере.

Источники данных и email: подключение и алерты

Ошибка could not connect to server или timeout при добавлении источника данных почти всегда одна из трёх:

• сетевая изоляция: контейнер worker не видит нужный хост — если база данных крутится на другом сервере, проверьте, что порт открыт наружу и файрвол его пропускает именно для IP вашего Redash-сервера;
• SSL-требования: некоторые управляемые БД (например, облачные PostgreSQL) требуют sslmode=require в параметрах подключения — без этого получите отказ на этапе TLS handshake;
• таймаут воркера: по умолчанию Redash отводит на выполнение запроса ограниченное время (REDASH_ADHOC_QUERY_TIME_LIMIT для разовых запросов, REDASH_SCHEDULED_QUERY_TIME_LIMIT — для запланированных), и очень тяжёлые агрегации иногда упираются именно в этот лимит, а не в саму базу.

Отдельная головная боль — почта. Приглашения пользователей и алерты по порогам метрик идут через SMTP, и если он не настроен, письма просто теряются без явной ошибки в UI. Проверяйте переменные:

REDASH_MAIL_SERVER=smtp.example.com
REDASH_MAIL_PORT=587
REDASH_MAIL_USE_TLS=true
REDASH_MAIL_USERNAME=redash@example.com
REDASH_MAIL_PASSWORD=пароль
REDASH_MAIL_DEFAULT_SENDER=redash@example.com

Проверить фактическую отправку можно из контейнера сервера:

docker compose exec server ./manage.py shell
>>> from redash.app import mail
>>> from flask_mail import Message
>>> mail.send(Message("test", recipients=["you@example.com"], body="ok"))

Если команда падает с ошибкой аутентификации — почти наверняка нужен пароль приложения у почтового провайдера, а не обычный пароль от ящика (это касается Gmail, Yandex и большинства других сервисов с 2FA).

Если Redash в итоге кажется избыточным для ваших задач — например, нужны только дашборды без SQL-редактора для всей команды — стоит посмотреть на Metabase как альтернативу: у него другой набор проблем при разворачивании, но UI попроще для нетехнических пользователей.

Частые вопросы