Диагностика неисправностей

Портал не стартует

Пустой или отсутствующий .env. Настройки читаются из /workdir/.env внутри контейнера. Если файла нет, том монтируется как каталог и web падает при старте:

cp env-dist .env
docker compose up --force-recreate web

Не применились миграции. djangoctl.sh run делает migrate перед gunicorn, но при конфликте миграций падает. Смотреть docker compose logs web, применять вручную:

docker compose run --rm web django-admin migrate

Порт 8000 занят. web публикует 127.0.0.1:8000:8000; освободить порт или изменить публикацию в docker-compose.yml.

Пустая страница без стилей

Статика собирается на старте web (collectstatic --clear + compress --force) в том static. Если стили пропали:

docker compose restart web

Если не помогло — собрать ассеты фронтенда, они кладутся в network/static/lib:

npm ci
npm run assets

Не приходят TLE

Нет учётных данных Space-Track. Без SPACE_TRACK_USERNAME/SPACE_TRACK_PASSWORD загрузка каталога тихо пропускается — остаются только CelesTrak и SatNOGS.

Лимиты Space-Track. Space-Track ограничивает число сессий и запросов на аккаунт. Клиент логинится один раз за вызов и делает один массовый запрос каталога, а задача fetch_tle идёт раз в 4 часа — это укладывается в лимиты. Если стенд и прод используют один аккаунт, лимит выбирается вдвое быстрее и часть запросов начинает отбиваться; для этого и заведены раздельные SPACE_TRACK_*_DEV и SPACE_TRACK_*_PROD.

Спутник пропал из /api/latesttles/. Публичная выдача отдаёт только объекты на орбите, и главный признак — возраст TLE: сошедший с орбиты объект выпадает из выборки Space-Track и перестаёт обновляться. Если источник временно сломан, живые спутники тоже начнут выпадать — поднять LATEST_TLES_MAX_AGE_DAYS. Подробнее — Орбитальные данные (TLE).

Недоступен db.satnogs.org

На части хостингов db.satnogs.org заблокирован на сетевом уровне, и задача fetch_data не может забрать спутники и передатчики. Для этого случая есть исходящий прокси только для API SatNOGS DB и SatNOGS Network (им же ходит parse_data_from_satnogs; сами файлы кадров качаются с S3 напрямую):

SATNOGS_DB_PROXY_URL=http://user:pass@proxy-host:port

Сам прокси или VPN нужно поднять отдельно — настройка только подключает приложение к уже существующему.

Наблюдения массово получают статус «failed»

Задача find_and_rate_failed_observations раз в 15 минут проставляет -1000 всем наблюдениям, у которых через OBS_NO_RESULTS_IGNORE_TIME после окончания нет ни водопада, ни аудио, ни демодулированных данных. Массовый «failed» означает, что станции не загружают результаты: проверить связность клиента с порталом, токен станции и её статус.

Если наоборот — подозрительно много «good», см. раздел про баг оценки в Оценка наблюдений.

Станция числится Offline

Состояние выводится из last_seen при каждом обращении; период сердцебиения задаётся STATION_HEARTBEAT_TIME. Уход со связи дописывает в журнал station_log_disconnect (раз в час). Проверить, что клиент ходит на портал и что у станции корректный владелец и токен. Ручная отметка последнего появления:

docker compose run --rm web django-admin update_station_last_seen <station_id>

Celery не выполняет периодические задачи

Периодические задачи регистрируются в network/celery.py при старте beat. Признаки и причины:

  • Не запущен сервис celery или в нём не поднят beat.

  • Задача зарегистрирована условно: zip_audio_files и archive_audio_zip_files включаются только при своих флагах и при выключенном USE_S3_STORAGE_FOR_AUDIO, а parse_data_from_satnogs — только при ENVIRONMENT=production.

  • Недоступен Redis (CELERY_BROKER_URL).

Не собирается документация

Сборка идёт с -W, поэтому любое предупреждение Sphinx — ошибка. Самые частые:

  • страница не включена ни в один toctree;

  • ссылка на несуществующий документ;

  • новый файл в docs/, который не является страницей, — добавить в exclude_patterns.

tox -e docs

Пины — sphinx>=8 и myst-parser>=4; потолок под Python 3.9 снят вместе с переходом образа на 3.12.