Как диагностировать и восстановить работу внешнего HTTP-сервиса на Rust для интеграции с 1С при ошибке 502

← На главную

Часто в крупных организациях обмен данными между 1С и внешними системами (например, EDI-провайдерами вроде Leradata или Exite) строится через промежуточные сервисы. В нашем случае мы разберем ситуацию, когда такая «прослойка», написанная на языке Rust и работающая под управлением Linux, перестала отдавать документы в 1С, возвращая ошибку 502 Bad Gateway. Мы пройдем путь от анализа веб-сервера до восстановления работы фоновых процессов синхронизации.

Разбираемся с архитектурой решения и кодом ошибки 502

Для начала проанализируем, что означает код состояния 502. В контексте веб-технологий это сигнал о том, что ваш основной веб-сервер (чаще всего Nginx), работающий как «входная дверь» (Reverse Proxy), не получил ответа от приложения, которое находится «за ним». Простыми словами: прокси-сервер работает, а само приложение на Rust — нет.

Рассмотрим конфигурационный файл Nginx, который обычно располагается в /etc/nginx/sites-enabled/ или аналогичных папках. Выясним, куда именно перенаправляются запросы от 1С:


server {
    listen       80;
    server_name  yama.corp.local;
    access_log  /var/log/nginx/yama.log  main;
    location / {
        proxy_pass http://127.0.0.1:3369/; 
        proxy_read_timeout 300s;
        proxy_set_header Host $host;
    }
}

Из этого конфига мы видим, что Nginx ожидает работающее приложение на локальном порту 3369. Если 1С получает 502, значит, на порту 3369 в данный момент никто не «слушает» входящие соединения.

Диагностика активных процессов в Linux

Проанализируем текущее состояние портов на сервере. Для этого воспользуемся командами ss или netstat. Это позволит нам понять, запущен ли сервис вообще. Выполним команду:

ss -anp | grep '3369'

Если команда ничего не возвращает, значит, сервис упал. Чтобы выяснить причину падения, нам нужно заглянуть в системные логи или логи самого приложения. Проверим статус сервисов через systemctl, если они были добавлены в автозагрузку системы:

systemctl list-units --type service --state failed

Если же сервис запускался «вручную» (через скрипты в папках пользователя), то systemd нам не поможет. В этом случае нужно искать скрипты запуска, такие как start_service.sh или start_all_services.sh.

Работа с исходниками на Rust и компилятором Cargo

В нашем случае сервис написан на Rust. Разберем, как устроена его работа. Разработчики часто используют инструмент cargo для сборки и запуска. Посмотрим на типовой скрипт запуска, который мы нашли в папке проекта:


#!/bin/bash
RUST_LOG=info cargo run --bin xxx_service --release

Здесь cargo run пытается скомпилировать и запустить бинарный файл. Если при запуске этого скрипта вы получаете ошибку error: no override and no default toolchain set, это означает, что окружение Rust (toolchain) не настроено для текущего пользователя. Выясним причину, проверив установку rustup. Попробуем установить версию по умолчанию:

rustup default stable

После этого попробуем запустить сервис в режиме отладки, чтобы увидеть детальные сообщения об ошибках в консоли:

RUST_LOG=debug cargo run --bin xxx_service --release

Анализ внутренней логики: цепочка FTP -> PostgreSQL -> 1C

Изучив исходники main.rs и дополнительные модули, мы выяснили, что система состоит из двух частей:

Синхронизатор (ftp2db): Этот процесс по расписанию (через cron) заходит на FTP-сервер провайдера, скачивает XML-файлы и записывает их содержимое в таблицу базы данных PostgreSQL (например, в таблицу ftp_mirror).
HTTP-сервис (yama): Это приложение на Rust, которое слушает порт 3369. Когда 1С присылает запрос GET /api/v1/orders/list/today, сервис идет в PostgreSQL, достает оттуда данные и отдает их в формате JSON обратно в 1С.

Рассмотрим фрагмент кода, отвечающий за подключение к базе данных. Обратите внимание, что параметры подключения часто не захардкожены, а берутся из переменных окружения (Environment Variables):


let database_url = env::var("DATABASE_URL").expect("DATABASE_URL must be set");
let ftp_server = env::var("FTP_SERVER").expect("FTP_SERVER must be set");

Это критически важный момент: если вы запускаете скрипт start_service.sh просто из консоли, эти переменные могут быть не заданы, и программа моментально упадет с ошибкой «panic». Проверьте текущие переменные командой printenv.

Настройка планировщика Cron и перенаправление логов

Выясним, как запускается синхронизация файлов. Проанализируем содержимое crontab пользователя:


crontab -e
# Пример записи:
*/5 * * * *  cd /home/sysadmin/Development/ftp_2_db/ && ./start_service.sh > /dev/null 2>&1

Конструкция > /dev/null 2>&1 — это «черная дыра». Она подавляет все сообщения об ошибках. Чтобы понять, почему синхронизация не работает, временно заменим её на запись в файл лога:


*/5 * * * *  cd /home/sysadmin/Development/ftp_2_db/ && ./start_service.sh >> /home/sysadmin/ftp_sync.log 2>&1

Теперь мы сможем увидеть в файле ftp_sync.log реальные причины сбоев, например, неверный пароль к FTP или проблемы с доступом к базе данных PostgreSQL.