Налаштування парсера за розкладом (cron) для 1С-Бітрікс

Ми часто бачимо: сайт на Бітріксі з ручним оновленням цін та залишків — помилки, затримки, втрачені продажі. Одного разу до нас звернувся клієнт з каталогом з 15 000 товарів: ціни оновлювались раз на тиждень вручну через Excel. За місяць збитки від прострочених акцій склали 8% обороту. Разовий парсинг проблему не вирішує — потрібен автоматичний запуск за розкладом. Налаштування парсера за розкладом (cron) для 1С-Бітрікс — це ключове завдання для автоматизації оновлення даних. Ми підбираємо механізм (агенти Бітрікса vs системний cron), реалізуємо блокування паралельних запусків, налаштовуємо логування та алерти. Результат — дані оновлюються самі, без участі людини.

Як системний cron вирішує проблему оновлення даних?

Агенти (b_agent) — вбудований механізм Бітрікса. Вони працюють тільки коли на сайт заходить відвідувач і спрацьовує CAgent::CheckAgents(). При низькій відвідуваності агенти запізнюються. Режим точного запуску через cron вирішує проблему, але вимагає налаштування системного завдання. Наш досвід показує: для парсерів з частотою оновлення раз на 30 хвилин системний cron надійніший.

Системний cron — прямий виклик PHP-CLI. Жодної залежності від веб-сервера:

*/30 * * * * /usr/bin/php -f /var/www/site/local/scripts/parser_run.php >> /var/log/parser.log 2>&1 

Для важких парсерів (10 000+ позицій) системний cron кращий — немає лімітів PHP-FPM за часом виконання. Ми гарантуємо стабільність запуску в будь-який час, навіть якщо сайт не навантажений.

Чому ми рекомендуємо системний cron для важких парсерів?

У проєкті з 50 000 товарів і оновленням кожні 30 хвилин агенти не справлялись: при відвідуваності 200 осіб на день виконання зсувалось на 10-15 хвилин. Перехід на системний cron усунув затримки — оновлення стало точним до секунди. Вартість підтримки знизилась на 30% завдяки автоматизації.

Як захистити парсер від паралельних запусків?

Парсер виконується 25 хвилин, cron запускає наступний через 30 — два екземпляри не перетнуться. Але якщо скрипт завис на 35 хвилин? Потрібен захист. Використовуємо блокування через файл або Redis:

$lockFile = '/tmp/parser_' . md5($parserName) . '.lock'; if (file_exists($lockFile) && (time() - filemtime($lockFile)) < 3600) { exit('Already running'); } touch($lockFile); // ... робота парсера ... unlink($lockFile); 

Для розподілених систем (кілька серверів) — блокування через Redis: SET lock:parser NX EX 3600. Вартість помилки при паралельному запуску — дублікати даних і навантаження на сервер. Ми враховуємо це в кожному проєкті.

Агенти чи cron: що обрати? Порівняння

Покрокове налаштування cron для парсера

1. Визначте команду запуску — повний шлях до PHP та скрипту. Перевірте версію: which php.
2. Налаштуйте логування — перенаправте stdout та stderr у файл з датою.
3. Додайте завдання в crontab — crontab -e, вкажіть розклад і команду.
4. Реалізуйте блокування — lock-файл або Redis.
5. Протестуйте — виконайте команду вручну, перевірте логи.
6. Налаштуйте алерти — надсилання сповіщень при помилках.

Цей алгоритм ми застосовуємо в кожному проєкті — він скорочує час налагодження на 40%.

Налаштування агентів Бітрікса для парсингу

Якщо все ж використовуємо агенти — реєструємо через CAgent::AddAgent():

CAgent::AddAgent( 'MyParserAgent::Run();', // функція-агент 'mymodule', // модуль 'N', // не точний 3600, // інтервал у секундах '', // дата першого запуску 'Y', // активний date('d.m.Y H:i:s', time() + 3600) // наступний запуск ); 

Агент повинен бути зареєстрований у include.php модуля або в init.php. Для продакшену рекомендуємо комбінувати з системним cron через документацію 1С-Бітрікс. Це дає максимальну гнучкість і точність.

Що дає структуроване логування?

Парсер без логів — чорна скринька. Мінімальна схема:

file_put_contents($logFile, date('[Y-m-d H:i:s] ') . $message . PHP_EOL, FILE_APPEND); 

Для продакшену — структуровані логи з рівнями (info/warning/error) і ротацією через logrotate. Алерт при помилці: якщо в логу за останній запуск є рядки з ERROR — надсилаємо email через \Bitrix\Main\Mail\Event. Це скорочує час реакції на збої та знижує витрати на підтримку вдвічі. Згідно з рекомендаціями Bitrix, такий моніторинг обов'язковий для критичних оновлень.

Що входить в роботу

• Аудит поточного парсера або написання нового
• Вибір та налаштування механізму запуску (cron/агенти)
• Реалізація блокування паралельних запусків
• Налаштування логування та алертів
• Тестування розкладу та сценаріїв помилок
• Документація по доступах та роботі парсера
• Гарантія стабільності протягом тижня після запуску

Таймлайн робіт

Разом: 6–12 годин. Вартість розраховується індивідуально — оцінимо ваш проєкт за один робочий день.

Отримайте консультацію з налаштування парсера — пишіть, ми підберемо оптимальне рішення під ваш бюджет. Залиште заявку — розповімо, як автоматизувати оновлення даних на вашому проєкті. Зв'яжіться з нами, щоб розпочати автоматизацію вже сьогодні.